블록체인 (1)

미래 IT 기술의 기반, 블록체인

블록체인 (1)
미래 IT 기술의 핵심 기반기술은 뭘까?
그 요란한 빅데이터? 사물인터넷? 아니,

블록체인이다.

‘블록체인(Blockchain)’이란, 각 분산 노드의 운영자에 의한 임의 조작이 불가능하도록 고안된 분산 데이터베이스의 한 형태로서 대규모의 노드들 사이에서 각 노드에 분산 저장된 데이터를 항상 최신 상태로 유지할 수 있도록 하는 합의 및 수렴 알고리즘이다.

아니 이게 도대체 뭔 소린가,, 보다 간단하게는, 구글에 ‘블록체인’이라고 치면 쪼르르 같이 뜨는 ‘비트코인’이 어떻게 동작하는지를 보면 쉽게 이해할 수 있다.

‘비트코인’이라는, 말은 아주 익숙하지만 그 개념은 왠지 좀 애매한 그 무엇은, ‘암호화 화폐(Cryptocurrency)’ 그리고 그 암호화 화폐의 거래가 기록되는 ‘블록체인(Blockchain)’의 결합물이다. 비트코인을 ‘가상화폐(Virtual Currency)’라고 말하기도 하는데, 가상화폐는 현물화폐의 반대로서 개념이 좀 다른, 훨씬 더 광범위한 개념이라서 적절한 용어가 아니다. 그러니 비트코인을 대충 가상화폐라 부르면 뜻이 좀 어긋난다. 이제 구시대의 유물 된 싸이월드 도토리도 가상화폐였으니까.

‘블록체인’은 모든 비트코인 거래 내력이 기록된 일종의 장부 같은 것이다. 장부 기록 과정 그리고 장부에 기록된 값이 맞는지 검증하는 전 과정에 모든 비트코인 사용자가 참여하고 기록이 모두 남기 때문에 위변조가 불가능하고 사용자가 늘수록 안전성은 더욱 강화된다. 바로 그 점 때문에 블록체인은 미래 IT 기술의 기반으로서 각광 받고 있다.

비트코인의 망조, 그리고 부활?

한창 뜨겁던 비트코인 광풍도 시나브로 식나 싶더니 폭락 소식에 이제 드디어 망하나? 했다. 하지만 최근 중국 투자자들이 몰려들어 화려하게 부활했다. 중국의 비트코인 열풍은 어쩌면 당연하다 싶은 건, 화폐가치 급락 전망 풍문이 흉흉한데도 당장은 철철 넘치는 위안화가 현재 마땅한 투자처도 따로 없어서 갈 만한 곳이 없고, 당국의 엄격한 자본 통제 탓에 규제를 피할 수 있는 자유로운 비트코인에 몰린 것.

현재 비트코인의 중국 거래량은 전 세계 거래량의 무려 9할이 넘는다. 아무리 그렇다 해도 왜 이렇게까지나 몰리나? 좀 이상하지만, 비트코인은 세계 어느 나라에서든 마음대로 쓸 수 있기 때문에 국제범죄조직도 애용한다는 점을 떠올려 보면 아주 이상한 일은 또 아니고.

하지만 이는 단기적 그리고 비정상적 호황으로 보이니 비트코인 시장의 장밋빛 미래를 보장할 만한 증거는 아니다. 그럼에도 확실한 건,

비트코인은 망하더라도 블록체인은 살아남는다

미국의 장외주식거래시장 나스닥(NASDAQ)을 운용하는 OMX 그룹은 ‘나스닥 개인시장(Private Market)’에서 블록체인을 활용할 계획이다. 나스닥 개인시장은 일일 거래대금이 2조원에 이를 정도로 급속도로 성장했지만, 모든 거래에 변호사의 공증 절차가 필요해 거래 속도가 매우 느렸다. 이에 나스닥은 블록체인을 통해 주식을 발행하고 거래함으로써 속도 문제를 해결할 수 있으리라 기대하고 있다.

금융 분야뿐 아니라, 온두라스는 국가 토지대장을 블록체인에 기록하고 있다..고 말하니까 누가 “온두라스가 모범사례라고?” 라며 피식 웃던데, 온두라스는 지방 토호와 군벌이 농민들 토지를 강제로 뺏고 심지어 정부 자료까지 막 조작하다 보니 어쩔 수 없이 블록체인 등의 방법을 동원할 수 없는 상황이라, 오히려 가장 적절한 모범사례 아닌가? 그래도 보다 일반적인 모범사례 같아 보이는 걸 찾자면,

버클리 음악대학은 블록체인 기반으로 저작권료 지급 시스템을 구축하고 있다. 블록체인은 저작권이라는 제도의 성격에 딱 들어맞는 선택.
그 외 국내외 참으로 다양한 분야의 실용 그리고 연구 사례들이 있는데 그 모든 사례들이 함께 공유하는 공통점이 있다.

내가 누구인지 말할 수 있는 자는 누구인가

왜들 그리 블록체인에 집중하는가? 앞서 언급한 피곤하고 오래 걸리는 ‘공증’ 절차를 대체할 아주 절묘한 방법이기 때문이다. 공증이란 어떤 사실을 공적으로 증명하는 일이다. 내가 나임을 증명하고 이것이 나의 것임을 증명한다. 난 뭐 대충 살기 때문에 공증 뭐 그런 거 모르겠다? 그러든 말든 우린 모두 다 이미 공증의 엄격한 테두리 안에서 살아간다. 그 말 많은 공인인증서도 일종의 공증이니까. 공증 없이는 정말 아무 일도 못 한다.

그래도 기존의 공증이라는 거, 지금껏 그래왔듯 좀 번거롭고 느리더라도 꾹 참고 그냥 하던 대로 하면 대충 굴러가지 않아? 아니, 안 굴러간다. 어쩌다 보니 기존 방식으로는 아예 불가능한 지경에 이르고 말았다. 여러 까닭이 있지만 요즘 가장 두드러진 까닭은 바로 ‘사물인터넷(Internet of Things, “IoT”)’ 때문. 사물인터넷이란 주소의 빅뱅, 간단히 말해 사람뿐 아니라 세상 모든 사물들이 자기를 증명해야 할 필요가 생겼다는 뜻이다. 그러니 기존 방식으로는 물량 감당을 못하게 된 거다.

아니 사물까지 굳이 다 그렇게 해야 돼? 해야 된다. 아니라면 정말 무시무시한 사건사고들을 보게 될 것이다.

블록체인과 사물인터넷

IBM을 기억하는가? 요즘은 IBM이란 말을 아예 못 들어 봤다는 사람도 있던데,, 한때 세상의 거의 모든 컴퓨터는 ‘IBM 호환기종’으로 불렸다. 약간의 ‘애플’도 있었지만, 대개 IBM 호환기종. 지금도 기업 전산 환경에는 ‘메인프레임’으로 대표되는 IBM 제품들이 활약하고 있고, 덕분에 완전히 잊혀진 옛말인 듯싶은 ‘코볼’ 개발자가 고연봉 받으며 잘 살고 있다. 아무튼, 바로 그 IBM이 요즘 블록체인 이야기 나오면 절대 빠질 수 없는 큰 배역을 맡고 있다. 바로, 블록체인과 사물인터넷.

그럼 IBM이 말하는 블록체인과 사물인터넷 시나리오를 들어 보자.

“세제가 떨어지면 세탁기가 알아서 단골 가게에 주문하고 자기가 관리하는 집안 소모품 구매 계좌에서 가상화폐를 꺼내 세제 값을 계산한다. 가게 주인은 입금을 확인하고 세제 배달 도착일을 세탁기에게 알려 주면, 세탁기는 자기 주인에게 세제 떨어져서 주문했고 언제 도착한다고 알린다.”

“세탁기가 고장나면 세탁기는 자기진단 시스템을 가동해 어디가 고장났는지를 파악하고 해당 부품 보증기간 등을 확인한 뒤 수리점에 출장을 요청한다. 수리점에서 견적을 보내오면 자기 주인에게 알린 뒤 주인이 수리점과 일정을 조율할 수 있도록 서로 연결해 준다.”

사실 이 두 시나리오만 보면 먼저 드는 생각은, “세탁기가 뭘 굳이 그런 걸 다,,” 싶기도 하다,, 하지만 이는 시나리오일 뿐이니 다른 상상도 해 보자. 이를테면, 집안 물건 중 가장 많은 정보와 연결되는 물건은 뭘까? TV? 글쎄, 냉장고 아닌가 싶다. 냉장고엔 수많은 물건들을 담는데 그 모든 물건은 유통기한 영양정보 등의 정보를 가지고 있고 경우에 따라선 의사가 금지하거나 섭취량 조절을 권유한 음식이 있을 수도 있다. 결정적으로, 냉장고는 365일 24시간 가동된다. 그래서 스마트홈의 중심으로 냉장고가 가장 자주 거론되는 것. 그러니 위 시나리오도 “차라리 냉장고라고 하지 왜?” 싶다. 아무튼 중요한 점은,

세탁기든 냉장고든, ‘사물’은 어떻게 자신을 ‘인증’할까?

그래서 IBM은, 아니 IBM뿐 아니라 수많은 회사들이 사물인터넷 네트워크를 ‘P2P(Peer-to-Peer: 동등 계층간 통신망, 소수의 서버에 집중하지 않고 망 전체 구성에 참여한 기계들끼리의 통신과 계산에 의존해 구성되는 통신망)’ 방식으로 구현하려 한다. 중앙집중 네트워크에다가 수십 억에 이르는 수의 사물을 연결해 관리하는 건 비용 문제 안정성 문제 일일이 따질 수도 없이 아예 불가능하기 때문이다. 서버 하나에 연결된 기기는 서버가 고장하면 모두 못 쓴다. 네트워크 구현 비용을 낮추면서 안정성을 높이는 방법은? 그렇다, 블록체인이다. 아니라면 사실, 달리 쓸 방법도 없다. 그런데,

결정적 문제, 블록체인은 안전한가?

블록체인 관련 사고는 이미 터지고 있다. 얼마 전 한국서도 꽤 큰 껀 터졌다.

지난 5월 12일 한국의 이더리움(Ethereum, ‘에테리움’이라고 읽기도 함) 사용자가 7218이더(ether, 이더리움 화폐 단위, 당일 기준 거래가로 환산하면 $89,936)를 해킹당하는 사건이 발생했다. 해커는 이더리움 블록체인을 생성하는 어플리케이션과 이더 화폐를 저장하고 관리하는 전자지갑 어플리케이션 사이에 암호화되지 않은 통신이 일어난다는 점을 노려 어플리케이션 간 통신 중에 이더를 빼돌려 피해자의 지갑으로부터 자신의 지갑으로 전송했다.

이더리움 재단은 해당 취약점에 대해 긴급 보안 업데이트를 실시했지만 네트워크 보안에 집중한 내용이었고, 애초 문제였던 어플리케이션-어플리케이션 통신 문제는 해결되지 않았다. 사고 경위 전체의 문제 핵심은 ‘어플리케이션’과 ‘암호화’인데 엉뚱한 곳에 집중한 것이다. 시사하는 바가 아주 크고 중한 사고 그리고 잘못된 후처리의 좋은 예다.

아무튼 그래서, 블록체인은 안전한가?

블록체인은 안전하다. 아니, 블록체인만 안전하다. 위 사고를 보더라도, 블록체인 알고리즘 자체는 안전하지만 블록체인과 관계된 어플리케이션과 시스템 그리고 네트워크까지 싹 다 안전하다고 볼 수는 없다. 그렇지만 여전히 블록체인은 안전하다. 그러니 어플리케이션과 시스템 그리고 네트워크를 안전하게 잘 만들어야 한다.

블록체인 알고리즘과 그를 둘러싼 여러 환경요소들, 그리고 그 총체로서의 ‘블록체인’의 안전에 대한 이야기는, 이미 너무 길어졌고 쓰다 보니 아직 공부 부족함이 처절하다 싶어서,, 뒷 이야기는,

후일을 기약합니다. 쓰다 보니 ‘블록체인, 1편’이 됐군요,,

car security using gps or navigation

스마트카 환경에서의 보안 문제와 대응

최근 IT 분야에서 가장 많이 언급되는 용어들이 IoT와 스마트카(smart car) 혹은 커넥티드카(connected car)일 것이다. 네트워크 연결성(connectivity)이 없던 자동차가 연결성을 갖게 되었다는 측면에서 커넥티드카라는 어휘가 사용된다면, 자동차가 점점 똑똑해진다는 측면에서 스마트카를 사용하는 경향이 많은 듯하다. 우리가 스마트 디바이스(smart device)로 제일 친숙한 기기는 스마트폰(smart phone)이다. 스마트폰 이전에도 휴대전화는 있어왔고 이전의 휴대전화들도 일부 제약이 있었으나 인터넷 접속이 가능한 기기들이었다. 그렇다면 우리가 스마트폰이라고 정의하는 기기들과 그 이전에 네트워크 연결성만 갖는 휴대전화들과의 경계선은 무엇일까.

스마트폰은 통신 성능, 연산처리 성능의 증대를 넘어서 사용자가 원하는 기능을 소프트웨어만으로 임의로 설정하거나 부여하고 조절할 수 있게 되었다는 점에서 기존 휴대전화와 극명한 차이를 갖는다. 휴대전화와 스마트폰의 구분을 참고하여 커넥티드카와 스마트카를 다시 생각해보자. 커넥티드카는 기존의 자동차들이 연결성이 없었지만 이제는 다양한 연결성을 가지게 되었다는 측면의 용어이고, 기존의 자동차는 자동차 제조사가 제공해주는 기능의 범위 안에서만 사용할 수밖에 없는 기기였지만 스마트카는 사용자가 원하는 기능을 소프트웨어적으로 설정하고 조절할 수 있게 해주는 자동차 소프트웨어 플랫폼 측면이 강하다.

자동차가 기계장치들의 조합을 넘어서 커넥티드카 혹은 스마트카의 방향으로 진화하고 있고 자동차 1대에 포함되는 소프트웨어의 분량이 전투기, 항공기, 심지어는 페이스북 보다 많은 1억 라인에 달하는 코드를 포함하는 IT의 산물로서 이미 자리매김하고 있다. 매년 1월 미국 라스베가스(Las Vegas)에서 열리는 CES의 올해 행사는 이러한 점을 잘 보여주었다. ‘Consumer Electronics’가 아니라 ‘Car Electronics’가 아니냐고 우스갯소리가 나올 정도로 세계 유수의 자동차 제조사들이 다양한 기술을 선보였다. 보안기술을 개발하는 회사 입장에서 올해 행사의 주목할 만한 점을 짚어 보자면 다음과 같다.

첫째, 자동차 제조사들이 클라우드를 들고 나왔다. 특히, BMW는 Open Mobility Cloud를 제시하여 자동차를 비롯한 다양한 기기들의 중심에 서고자 하는 의지를 보였다.

둘째, 자동차와 홈네트워크의 연결이다. 폭스바겐은 LG 냉장고와의 연결을 선보였다. 왜 하필 냉장고인가 하는 사람들도 있을 것이다. 근래에 삼성전자와 LG전자가 선보인 냉장고들은 family hub를 표방하고 있다. 냉장고로 홈네트워크의 중심에 서겠다는 것이다. 일 년 내 전원을 끄지 않는 냉장고의 특성을 감안하면 이러한 접근은 탁월한 전략이다.

셋째, 지도가 서비스 플랫폼으로서 중요함을 인식하고 있음을 보여줬다. 몇몇의 제조사들은 공동으로 지도 회사를 사들이고, 어떤 회사들은 실시간으로 지도를 생성하고 갱신할 수 있는 기술을 선보였다. 이들의 행보는 차량에 탑재되는 내비게이션 장비가 지도를 사용하기 위해 내는 라이센스 비용을 절감하는 차원이 아니다. 차량에게 온라인 서비스를 제공하고자 할 때 제일 먼저 자연스럽게 떠오르는 것이 위치기반서비스다. 위치기반서비스를 구축하자면 지도를 기본 플랫폼으로 밑에 깔고 가야하는 것은 너무나 당연하다. 마지막으로, 자동차의 소프트웨어에 플랫폼화를 추진하고 있다는 점이다. 휴대전화들이 점점 플랫폼화 되고 그 이후에는 표준적인 운영체계가 등장했다는 점을 떠올리면 이 역시도 당연한 수순이다.

자동차의 연결성이 증대되고, 네트워크를 통한 클라우드 접속이나 온라인서비스의 제공이 가능해지면서 많은 우려를 낳고 있는 것이 보안이다. 지난해, 지프(Jeep)의 체로키(Cherokee) 모델을 해킹한 사건은 이러한 우려가 현실임을 보여준 사건이었다. 커넥티드카라는 용어가 정립되기 이전에도 일부의 자동차들은 텔레매틱스(telematics) 기능을 가지고 있었고, 지프 체로키에 대한 해킹은 텔레매틱스 통신 채널을 해킹한 사건이었다.

각 제조사들은 각사가 비밀스럽게 정의한 프로토콜에 따라 서비스를 제공하고 있다. 우리가 일상으로 사용하는 스마트폰이나 개인컴퓨터가 표준화되고 공개된 규격의 프로토콜을 사용하고, 안전한 키관리 체계를 적용함으로써 보안을 확보하는 방향으로 접근하는 것과는 대조되는 방향이다. 이 해킹 사건이 일깨워주는 또 다른 측면은 방화벽 내지는 침입탐지의 부재이다. 해킹으로 비밀스럽게 유지되던 외부 통신 채널에 접근하고 프로토콜을 분석해냈다 하더라도 차량의 내부 네트워크에 접근하여 차량의 속도와 주행방향 등을 제어할 수 있었다는 점이 더 큰 문제이다.

차량 내부에는 많은 ECU들이 들어가고, ECU들 간의 통신에 의해서 자동차는 다양한 기능을 실현할 수 있다. 차량 내부 ECU들 간의 네트워크는 기업 내부의 내부망을 축소한 듯이 닮아 있다. 기업 내부에는 중요한 역할을 하는 서버들도 있고 서버 보다는 덜 중요한 개인컴퓨터들도 있다. 서버들 중에는 기업 내부에 존재하지만 외부와 통신이 가능한 서버도 있고 외부에서 접근 가능하면 안되는 서버들도 있다. 기업 내부의 전산자원을 보호하기 위해 기업들은 오래 전부터 방화벽을 구축하여 외부 네트워크에서 내부망으로 곧장 들어오는 것을 통제하고 있다.

외부와 통신이 가능해야 하는 서버의 경우에는 외부 방화벽과 내부 방화벽 사이에 DMZ를 설정하여 보호하는 방법을 적용하고 있다. 차량의 경우에도 이와 같은 접근법이 필요하다. 외부와 통신이 가능하면서도 내부 네트워크의 ECU와도 통신이 가능해야 하는 Head Unit들은 외부 방화벽과 내부 방화벽으로 차폐되는 DMZ 영역에 두어야 한다. 이렇게 된다면, 체로키 사례처럼 외부 통신 채널이 해킹되어 외부 방화벽이 무력화되더라도 한층 보안 정책이 강력하게 적용되는 내부방화벽에 의해서 차량 내부의 네트워크가 보호될 수 있다.

차량 내부에 방화벽을 두는 것만으로는 부족하다. 네트워크 레벨에서 동작하는 일반적인 방화벽들은 통신의 송신자, 수신자, 사용하는 통신 포트의 조합으로 연결을 허용할지 결정한다. 차량에서는 송신자, 수신자, 통신 포트 등을 한정하거나 규정짓는 것이 쉬운 상황은 아니므로 일반의 네트워크 방화벽이 큰 역할을 하지 못하고 해커는 이를 우회할 가능성이 있다. 이러한 문제에 착안하여 Argus Cyber Security, Symantec, Penta Security 등의 회사는 어플리케이션 레벨에서 통신 내용을 분석하여 공격 여부를 탐지하는 기술을 내놓았다.

이들 회사의 기술은 어디에서 유입된 통신이 어디로 전달되어야 하는지의 경로를 제어하는 것에 그치지 않고, 외부에서 차량 내부로 유입되는 통신 내용을 분석하여 공격여부를 판단한다. 기업 내부의 네트워크 보호를 위해 방화벽 외에도 침입탐지시스템(Intrusion Detection System; IDS)이나 침입방지시스템(Intrusion Prevention System; IPS), 그 외에도 웹방화벽(Web Application Firewall; WAF)이 추가로 필요한 것과 동일한 개념이다.

해외를 비롯하여 국내에서 진행되고 있는 V2X 테스트베드 프로젝트는 V2V와 V2I 통신을 사용하는 시나리오를 구축해 나가고 있다. 이들 프로젝트는 V2V와 V2I의 통신을 보호하기 위해 타원곡선 암호시스템에 기반한 공개키인증서를 채용하여 통신보안을 확보하고 있다. 자동차가 Connected Car로의 진화를 거듭해 나가면 차량이 가지는 연결성은 더욱 다양해질 것이고, 해커들은 차량에 연결할 수 있는 다양한 수단과 방법을 갖게 될 것이다. 자동차를 해커들의 위협으로부터 보호하기 위해서는 차량 내부에서 차량을 보호할 수 있는 방화벽, 특히 어플리케이션 레벨에서 통신의 내용을 분석하여 공격을 탐지할 수 있는 방화벽을 채용하는 것이 통신보안의 확보 차원에서 우선적으로 병행되어야 한다.

자동차 뿐만 아니라 다른 IT의 환경에서도 보안 기술 한 두 가지를 적용한다고 완벽하게 안전해질 수는 없다. 앞으로 더욱 복잡다단해질 자동차의 보안을 위해서는 설계 단계에서부터 보안을 철저하게 고려하는 것이 반드시 필요한 일이다.

-심상규 펜타시큐리티시스템 loT 융합보안연구소장

[[원문 보기 – KAMA웹진 http://www.kama.or.kr/jsp/webzine/201607/main.jsp 2016. 07]

2016-05-24-1464067939-6536383-40_00-thumb (1)

“이 데이터가 네 데이터냐?”

2016-05-24-1464067939-6536383-40_00.jpg
대한민국 정부청사가 털렸다. 사건 전모를 보자면,

정부청사 침입 사건

너무나도 공무원이 되고팠던 26세 송모씨는 지난 2월 28일 정부서울청사 경비대 의무경찰들 틈에 섞여 청사 본관에 몰래 들어가 체력단련실에서 공무원 신분증을 훔쳤다. 인사혁신처 사무실에 들어가 공무원 시험 문제지를 훔치려 했지만 출입문 비밀번호를 몰라서 실패했다. 시험지를 미리 못 챙기면 시험을 망치는 딱한 버릇을 가진 송씨는 역시나 시험을 망쳤고, 3월 24일 성적을 조작하기 위해 훔쳐 둔 신분증으로 다시 청사에 들어갔다. 이번엔 누가 문 옆 벽에다 써놓은 출입문 비밀번호를 발견하고 사무실 문 따기에 성공, 컴퓨터를 켰지만 이번엔 컴퓨터 비밀번호를 몰라서 또 실패했다. 이틀 뒤 3월 26일, 미리 비밀번호 제거 프로그램을 준비해 간 송씨는 마침내 자기 성적을 조작하고 합격자 명단에 자기 이름을 올리는 데 성공했다.

아무리 청소년 장래희망 1위가 공무원인 나라라지만 이런 집요함은 좀,,

그리고, 발칵 뒤집어졌다. 이게 무슨 일인가! 다른 곳도 아닌 살벌할 정도로 삼엄해 마땅한 정부청사 본관을 풀방구리 쥐 드나들듯 막 들락날락거리다니! 청사보안 매뉴얼은 왜 만들었나! 것도 무려 7단계씩이나! 언론의 호들갑도 굉장했다. 여기서 1차로 막았어야 했고 혹시 뚫리면 저기서 2차로 막았어야 했고 그것도 또 뚫리면 거긴 마지노선이라 기필코 막았어야 했다! 연일 군사작전지도처럼 그린 지도 그림이 뉴스를 장식했다. 그래,

 철통방어의 맹점: “있어도 없다고 본다.”

당연히 막아야 한다. 그러나, 위 사건으로 이미 충분히 증명되었듯, 암만 막더라도 못 막을 수도 있고 또 못 막을 경우도 대비해야 한다. 하지만 외벽 철통방어의 지나친 강조는 곧 내부는 안전하다는 잘못된 인식으로 이어지게 마련이다. 무조건 막는다는 전제는 즉 침입자의 존재를 부정하는 것과 마찬가지라, 완벽하게 막았으니 내부엔 없는 게 당연하다 여긴다. 물리보안 철통방어 주장의 근본적 맹점이다. 내부 침입자 존재의 인정은 즉 철통방어에 대한 부정이기 때문에 인정할 수가 없는 것이다. 그러니 데이터 암호화 등 근본적 조치 없이 하나 마나 마찬가지인 컴퓨터 운영체제 비밀번호만 덜렁 걸어 놓고 아무렇게나 방치한 컴퓨터는 시중에 나도는 간단한 해킹 툴로도 그냥 막 뚫리고 그런다.

문득 오늘 본 기사 문장이 떠오른다. “계파 존재를 부정하니까 청산할 수도 없다.”

관련 기사를 쭉 훑어 종합해 보자니, 내부 공모자가 있었을 거라는 (아마도 보안 담당자의) 주장과 청사보안 시스템 자체가 허술했다는 (아마도 털린 사무실 근무자의) 주장이 내부에서 서로 대치했다는 징후가 농후하다. 이 방어막은 절대 뚫을 수 없다! 그런데도 뚫리고 나면 늘 그런 주장들이 대립하는 법이라 별 뜻은 없다만, 그 와글와글 소란 와중에 진짜 중요한 핵심을 간과하게 되는 게 진짜 문제인데,

 “만약 내부자가 데이터 털겠다고 작정했다면?”

그 중에서도 가장 치명적이고 결정적인 허점은, 가장 빈번히 사고를 치는 내부자의 존재다. 좀처럼 발각되지도 않아 실제 사고는 드러난 것보다 훨씬 더 많을 것이다. 그런데도 이후 대책이라고 내미는 것들은 모두 다 철통방어를 보다 철통답게 만들어야 한다는 주장뿐이다. 현관 게이트 통과 시 신분증과 신분 일치를 일일이 확인하라! 출입문 옆에 비밀번호 제발 좀 적지 마라! 온통 물리보안 이야기뿐이다. 그런데, 만약 청사에서 일하는 내부자가 성적을 조작하려 든다면 도대체 어쩔 작정인 걸까? 내부자는 게이트로 막든 뭐로 막든 그냥 통과하잖은가? 게다가 그 내부자가 만약 해당 데이터 담당자라면?

결국 지켜야 할 게 뭔지 모른다고 볼 수밖에 없다. 결국 지켜야 할 것? 두말할 것 없이 데이터다. 송씨의 목적 또한 청사 침입이 아니라 데이터의 조작이었잖은가. 상황은 조작 이후까지도 예상하고 대책을 마련해야 한다.

그래서, 데이터 무결성을 확인하는 장치가 필요하다.

데이터 무결성 확인 장치?

데이터 무결성(Data Integrity)이란, 말의 뜻 그대로 데이터가 무결(無缺)하다 즉 결함이나 흠이 없다, 데이터 생성 이후 위변조 없이 그대로의 상태를 유지하고 있음을 뜻한다. 무결성을 확인하기 위해서는 원본 외 따로 대조본을 저장해 두고 둘을 놓고 오류나 조작이 없는 완벽한 문서인지 비교해 보면 된다. 만약 다르다면 그 문서는 잘못되었다고 판단하고 다름의 까닭을 추적할 수 있다.

하지만 그게 그리 간단한 일은 아니다. 그러려면 문서 원본을 여기에 저장하고 대조본을 저기에 따로 저장하고 대조 위해 둘을 통신망 통해 주거니 받거니 아주 복잡해지는데, 복잡한 시스템은 무조건 지양함이 옳다. 게다가 만약 암호화가 필요한 중요문서라면 원본과 대조본 그리고 통신구간 전체를 암호화하고 각각 암복호화 키 관리 등의 조치를 모두 다 취해야 한다. 문서 보안등급에 따라서는 사본 저장 자체가 불가능할 수도 있다. 나는 단지 문서 무결성 확인만 하고 싶었을 뿐인데,, 일이 너무 커진다. 암호화 시스템이든 뭐든 무관하게 따로 정보 무결성 확인만 딱 하는 방법이 있으면 좋겠는데?

같은지 다른지 ‘확인’만을 위한 암호화

그래서 있는 게 단방향 암호화다. 단방향 암호화란, 평문을 암호화하는 것은 가능하지만 암호문을 평문으로 복호화하는 것은 불가능한 방법이다. 그게 무슨 암호화냐? 복호화도 못하는데 암호화를 왜 하냐? 싶지만, 다 쓸모가 있다. 바로, ‘확인’.

평문을 평문 상태로 여기저기 들고 다니며 옳은 값인지 확인하고 그러면 당연히 유출 등의 위험이 있다. 그리고 이것저것 다 신경 쓰자니 시스템이 엄청나게 복잡해진다. 그럴 때, 키 관리 등의 기술적 부담이 없는 단방향 암호화를 이용한다. 실제로 어떤 경우에 사용될까? 그래, 사용자 비밀번호 확인 용도로 가장 자주 쓴다. 웹사이트 회원정보 중 비밀번호는 단방향으로 암호화되어 저장된다. 암호화된 비밀번호는 다시 복호화할 수 없기 때문에 만약의 경우 유출되더라도 원래 값을 알 수 없으니 안전하고, 회원이 사이트 접속 위해서 비밀번호를 입력하면 입력한 비밀번호를 또 암호화해 저장된 비밀번호의 암호화 값과 일치하는지를 통해 본인 여부를 확인할 수 있다. 구조 간단하고 목적 및 효과 충분하다.

모름지기 전자정부라면 이러한 무결성 검증 장치는 당연히 갖춰야 하니까 이미 해당 기능이 준비되어 있지만 특수 목적에만 제한적으로 사용하게끔 만들어진 장치라서 보다 일반적인 방법론이 필요하다. 데이터 관리자뿐 아니라 일반 열람자까지 모두 다 간편하게 이용할 수 있는. 특히 요즘 세계적 대세인 공공문서 공개 시스템이 제대로 가동되려면 정말이지 꼭 필요한 장치다.

공공문서만? 아니, 그렇지 않다. 민간 영역에서 발생한 데이터 조작 사건을 살펴보자.

쇼핑몰 가격정보 조작 사건

너무나도 부자가 되고 싶었던 24세 이모씨는 지난 4월 26일 한 인터넷 쇼핑몰에 접속해 6회에 걸쳐 고가의 카메라와 렌즈 등 17개 상품 구매 버튼을 눌렀다. 물건값은 5천577만원이었지만 이씨는 이를 조작해 1만779원만 결제하고 물건을 챙겼다. 쇼핑몰에서 물건값을 결제할 때 결제대행사 서버로 전송되는 인증값을 알아내 가격정보를 임의로 조작했고, 판매자는 주문내역서와 결제내역서에 각각 ‘완료’라고 뜨는 것만 보고 속았던 것이다. 이씨는 받은 물건을 중고장터에서 되팔아 돈을 챙겼다.

이건 사건이 크다 보니 지면에까지 오른 것이고, 규모 사소해서 그냥 조용히 묻히는 쇼핑몰 데이터 조작은 흔히 일어나는 일이다. 쇼핑몰 주인이 너무 싫거나 아니면 무조건 남 괴롭히는 짓이 그냥 막 즐거운 자들이 쇼핑몰 웹사이트를 공격해 가격정보 등 웹사이트 내용을 자기 맘대로 바꿔 훼손한다. 100만원짜리를 10만원짜리로 바꾸고 싼 값에 깜짝 놀란 사람들이 막 몰려들어 주문 폭주하면, 쇼핑몰 운영자의 혼은 저멀리 안드로메다로 날아간다,,

그래서, 데이터 무결성 확인 장치는 민관공 불문 누구나 쉽게 사용 가능한 ‘서비스’ 형태로 만들어야 한다. 그러니 암호화 자체보다는 직관적이고 편리한 사용자 인터페이스가 핵심이어야. 쭉 둘러보니 아직은 그런 물건이 없는 듯하니, 글은 이만 쓰고 어서 만들어야겠다,,

암호화

“아니 그래서 도대체 PCI DSS가 뭔데?”

정보보안 제품들 광고를 보면 제품 도입 결정의 기준이라며 여러가지 ‘표준’들을 쪼르르 나열하곤 한다. 그중에서도 ‘PCI DSS’는 유독 자주 등장하는 주인공이다. “자사의 웹방화벽 OOO은 PCI DSS 요구사항을 충족하며 PCI DSS 기준 적합 인증을 보유하고 있습니다!” “오픈소스 데이터베이스 암호화 플랫폼 OOO는 신용카드번호 마스킹 기능 등 PCI DSS 요구사항을 모두 준수합니다!” 말이 어째 좀, 무슨 소리를 하는 건지, 어렵다. 그렇게나 강조하는 걸 보면 뭔가 아주 중요하긴 중요한 것인가 본데,

“아니 그래서 도대체 PCI DSS가 뭔데?”

‘PCI DSS’란, 신용카드 회원의 카드정보 및 거래정보를 안전하게 관리하기 위해서 신용카드 결제 전 과정에 걸쳐 관련된 자 모두가 준수해야 하는 신용업계 보안표준이다.

PCI DSS가 등장하기 전에는 신용카드 회사마다 제각각 다른 보안기준을 요구했기 때문에 일반사업자들은 이것저것 서로 다른 수많은 기준을 모두 다 맞추자니 비용도 많이 들고 너무나 불편했다. 그러한 불편을 해소하기 위해 JCB, 아메리칸 익스프레스, Discover, MasterCard, VISA 등 국제적 신용카드 대기업들이 공동으로 위원회를 조직하여 ‘PCI DSS’라는 사실상 표준을 책정했다.

“우리와 거래를 하려면 이 표준에 따라야 한다!”

그런데 워낙 큰 회사들의 연합이라서 따르지 않을 수가 없다. 거부하면 아예 장사를 못하니까.

그런데 NIST, ANSI, ASA, ISO 등 국제적으로 통용되는 표준제정기관이 아닌 민간기업들이 모여 만든 규격을 ‘표준’이라 할 수 있을까? 표준이란 어떤 사물을 판단하기 위한 근거나 기준인데 그런 걸 민간인이 출자해 영리적으로 운영하는 사기업이 결정해도 되는 걸까? 의심이 들 수도 있다. 하지만 ‘PCI DSS’ 내용을 자세히 들여다보면 이건 충분히 표준이라 할 만하다. 꽤 훌륭하게 잘 만든 상세하고 치밀한 규격이다.

전반적 그리고 세부적 보안상태 진단 및 심사 과정, 어플리케이션과 시스템 그리고 네트워크 등 영역마다실시하는 침투 테스트 횟수 및 시기 등 큼직한 보안정책뿐 아니라 부정한 로그인 시도를 몇 번 반복하면 잠금 처리할지, 클라이언트 PC에 개인 방화벽 설치 여부는 확인하는지 등 세세한 기준까지 고루 완비했다. 이렇듯 구체적이고 엄격한 내용을 정량적으로 제시하기 때문에 신용카드 거래와 무관한 기업이나 조직도 PCI DSS를 정보보안 기준으로 채택하는 경우도 많다.

PCI DSS 인증 구조

그럼 PCI DSS가 도대체 뭔지 그 내용을 보다 자세히 살펴보자. 그게 뭐든 정체를 제대로 파악하려면 주변에서 이러쿵저러쿵 참견하는 말을 듣는 것보다 당사자들이 직접 “이것은 무엇이다.” 설명한 것을 보는 게 좋다. 그러니 ‘PCI 보안 표준 위원회(PCI Security Standards Council)’이 말하는 PCI DSS의 인증 구조를 보면,

PCI DSS의 인증 구조는 ‘PTS’, ‘PA-DSS’, ‘DSS’, ‘P2PE’ 등 4가지 범주로 분류되어 있다. 하나하나 살펴보기에 앞서 짚어둘 점은, PCI DSS가 궁극적으로 목적하는 일은 2종의 정보를 안전하게 지키는 일이다. 2종의 정보란 신용카드 소유자의 개인정보와 신용카드번호 및 추가정보를 포함한 거래정보인데, 이를 합해 ‘민감정보’라 하자. PCI DSS의 모든 사양은 바로 그 민감정보를 어떻게 다룰지에 대한 내용이다.

1) PCI PTS (PIN Transaction Security)
신용카드 리더기 등 하드웨어 설계 및 검증 기준이다. 물리적 장비와 네트워크 트랜잭션을 통해 민감정보가 유출되는 것을 막기 위한 통신보안 및 데이터 암호화 등 보안표준 준수 여부를 확인한다.

2) PCI PA-DSS (Payment Application Data Security Standard)
어플리케이션 개발업체를 대상으로 하는 인증 기준이다. 카드사 및 회원사 그리고 신용카드 회원이 사용하는 업무용 소프트웨어에서 민감정보가 전송, 처리, 저장되는 과정에서의 통신보안 및 암호화 여부 등을 확인한다.

3) PCI DSS (Data Security Standard)
신용카드 인프라 총체적으로 안전한 네트워크와 시스템 구성 여부 등을 종합적으로 판단하는 기준이다. 계정통제 및 접근통제를 통해 업무환경의 엄격한 관리는 물론이고 정기적 보안감사 시행 여부 등 보안정책까지 포함하는 아주 넓은 개념이다. 하지만 기술적으로는 역시나 주로 어플리케이션 내부와 통신구간에서의 민감정보의 안전성 및 암호화 여부 등을 따져서 안전성을 판단한다.

4) PCI P2PE (Point to Point Encryption)
PCI DSS 전체의 밑바탕은 다름아닌 암호화다. 그냥 암호화가 아니라 P2P 암호화, 즉 신용카드 단말기에서부터 카드사 어플리케이션을 지나 데이터베이스에 저장될 때까지, 데이터가 이동하는 전 과정에 걸친 종단간 암호화다. 민감정보는 처음부터 끝까지 무조건 암호화되어 있어야 한다.

뭐가 막 복잡하니까 보다 간단히 정리해 보면,

1) PCI PTS = 하드웨어 설계자가 주의할 점
2) PCI PA-DSS = 소프트웨어 개발자가 주의할 점
3) PCI DSS = 민감정보 취급하는 모든 사람이 주의할 점
4) PCI P2PE = 민감정보는 처음부터 끝까지 무조건 암호화

이렇게 볼 수도 있다. 즉, 밑바탕인 4)를 빼고 보면 모두 다 업무 분야에 따른 분류다.

그럼 분야가 아니라 내용 자체만 놓고 보면 어떨까?

PCI DSS, 핵심은 웹 보안과 데이터 암호화

우선 ‘PCI PTS’를 보면 신용카드 단말기와 네크워크 등 주로 하드웨어 관련 분류인데 그 내용을 들여다보면, 순수 하드웨어설계 외 내용의 대부분이 데이터 암호화 그리고 트랜잭션 통신보안 관련 내용이다. 제대로 암호화하는지, 암호화한 데이터를 안전하게 주고받는지 등. 그런데 아직 통신망으로 전화선을 이용하는 경우가 남아 있긴 하지만 데이터가 이동해 어플리케이션에 도달한 이후엔 모두 다 어플리케이션이 다루는 대상이 된다.

그런데 요즘 어플리케이션은 절대다수가 웹 어플리케이션이다. 실제로 일어나는 어플리케이션 관련 보안침해 사고 대부분이 웹 보안 사고다. 따라서 웹 어플리케이션 개발 과정의 기준이 되는 ‘PCI PA-DSS’의 내용 대부분은 웹 보안 관련 내용이고, 집중하는 바 내용의 핵심은 데이터 암호화다.

민감정보를 다루는 전반적 보안정책이라 할 수 있는 ‘PCI DSS’ 또한 내용을 들여다보면 대부분이 웹 보안과 데이터 암호화 관련 내용이다. 그리고 ‘PCI P2PE’는 따로 말할 것도 없이 용어 자체가 구간 전체에 걸친 암호화라는 뜻이니까 역시나 웹 보안과 데이터 암호화가 주된 내용이다.

그런데, 왜 이렇게 웹 보안과 데이터 암호화 내용이 대부분인 걸까?

본격 웹 시대의 데이터 보안

요즘 통신은 거의 전부가 웹이고 요즘 어플리케이션은 거의 전부가 웹 어플리케이션이다. 바야흐로 본격 웹 시대인 것이다. IoT, 핀테크 등 환경을 보다 복잡하게 만드는 기술의 등장으로 인해 웹은 점점 더 우리 일상에 가까워질 것이다. 데이터는 어플리케이션을 통해 이동한다. 그리고 어플리케이션의 주요 환경은 웹이다. 통신기술뿐 아니라 시스템 환경에서부터 사용자 인터페이스에 이르기까지, 모든 IT 기술이 웹으로 통합되고 있다. 앞으로는 모든 어플리케이션이 웹 환경에서 개발되고 운용될 것이다. 따라서 분야를 어떻게 나누든 분류를 어떻게 정의하든 상관 없이 가장 중요한 보안은 ‘웹 보안’일 수밖에 없다.

그리고 앞서 말했듯, PCI DSS의 궁극적 목적은 민감정보를 안전하게 지키는 일이다. 용어도 복잡하고 하라는 일도 엄청 많고 그렇지만 결국엔 데이터를 지키자는 소리다. 이는 몇 번이고 거듭 되새겨 볼 만한 매우 중요한 핵심이다. 오늘날 정보보안의 중심은 과거에 집중했던 네트워크와 서버 등 인프라를 보호하는 보안으로부터 데이터와 어플리케이션을 보호하는 보안으로 이동하고 있다. 이는 끝내 지켜야 할 진짜 중요한 가치가 무엇인지 깨닫는 과정이다. 정말 지켜야 할 가치는? 당연히 데이터다. 그리고 데이터를 가장 안전하게 지키는 유일한 방법은 ‘암호화’다.

왜? 암호화 말고는 달리 방법이 없으니까,,

그럼 다시 처음으로 되돌아가, “자사의 웹방화벽 OOO은 PCI DSS 요구사항을 충족하며 PCI DSS 기준 적합 인증을 보유하고 있습니다!” “오픈소스 데이터베이스 암호화 플랫폼 OOO는 신용카드번호 마스킹 기능 등 PCI DSS 요구사항을 모두 준수합니다!” 이런 문장이 조금은 달리 보이지 않는가. 어렵고 복잡해 어지러운 용어도 그 용어의 핵심이 뭔지 파악하고 나면 쉽고 간단해진다.

암호화

“암호화해도 데이터 형태가 변하면 안 돼!”

“이 정보는 민감하다.”

2016년 9월부터 모든 ‘민감정보’의 안전성 확보조치가 의무화된다. 전엔 지문∙얼굴∙홍채∙정맥∙음성∙서명 등 소위 ‘바이오 정보’ 암호화만 의무였는데 이제 암호화 대상이 대폭 늘어난 것. ‘민감정보’란? 참 많다. 바이오 정보, 유전자검사 등의 결과로서 얻는 유전정보, 범죄경력 등 뻔한 내용 외에도 사상과 신념, 노조 및 정당 가입 탈퇴, 정치적 견해, 건강 및 성생활 등에 대한 정보, 그리고 그 밖에 사생활을 침해할 우려가 있는 온갖 개인정보 등등등 정말 많다. 왜 그것들을 모두 다 암호화하자는 걸까? 그 이유는,

첫째, 개인정보 유출사고가 너무 자주 일어난다. 특히 우리나라는 다 까발려졌으니 이미 늦은 일 아닌가 싶을 정도로 하도 많이 당해, 외양간 고치라니 고치긴 고친다만 더 훔쳐갈 소도 없는데,, 그런 생각마저 든다. 하지만 어쩌랴, 뒤늦게라도 고칠 수밖에.

둘째, 개인정보 보호조치는 빅데이터 등 최신 데이터 기술 연구개발의 필수조건이다. 아니라면 해당 산업은 활성화될 수 없고 또 활성화되어서도 안 된다. 개인정보가 막 노출된 데이터로는 뭔 짓을 하든 무모한 짓이다. 지금도 이미 중요정보는 알아볼 수 없게끔 처리하지 않나? 물론 그러고 있다. 하지만 문제는 “이 정도는 뭐, 괜찮아!” 대수롭지 않게 여겼던 정보들의 교차편집을 통한 ‘재식별화’의 위험, 그러니까 드러난 정보들을 이리저리 끼워 맞추다 보면 그 관계를 통해 감춰진 내용까지도 유추해 알아낼 수 있어서 비식별화 조치는 아예 헛된 노력이 되고 만다.

“암호화해도 데이터 형태가 변하면 안 돼!”

그래, 민감정보를 모두 암호화하자! 그럼, 끝인가? 아니, 끝 아니다. 업무처리를 위해 어떤 데이터의 값은 특정한 형태를 요구한다. 그러니까, 주민등록번호 값은 ‘000000-0000000’와 같은 형태의 값이어야 하는 경우가 있다. 다른 형태의 값도 인식하게끔 어플리케이션을 수정하면 되잖아? 그게 그리 간단한 일은 아니다. 특히 SAP로 대표되는 기업용 어플리케이션들은 수정이 매우 까다롭다. 그러니 데이터 내용을 알아볼 수 없게끔 비식별화 조치를 취하더라도 ‘000000-0000000’ 형태를 유지해야 한다. 그런데 암호화란 건 원래 암호화하고 나면 형태뿐 아니라 길이까지도 막 달라진다. 그래야 안전하니까. 암호화의 대표선수 AES만 보더라도 원본과 암호문의 형태는 완전히 다르다.

그래서, 문제를 해결할 해법은 없나? 아니, 있다. 크게 두 가지,

첫째, ‘랜덤 토큰’

비식별화가 필수인 데이터만 따로 뽑아내 보안용 데이터베이스에 따로 저장하고, 업무용 데이터베이스에는 실제 데이터를 대신해 원본 데이터와 형태만 동일한 임의의 ‘랜덤 토큰’ 값으로 대체해 사용하는 방법이 있다. 중요한 데이터만 따로 안전하게 보관하니까 편리하고 안전해 보이지만, 그렇지 않다. 업무용 데이터베이스와 보관용 데이터베이스 사이 통신이 필수라 통신구간 보안문제가 심각하고, 애초에 “이 토큰은 이 데이터, 저 토큰은 저 데이터” 1:1로 매칭한 테이블의 존재 자체가 이미 위험하다고 볼 수 있고, 일단 이 DB 저 DB 섞여서 시스템이 복잡한데 복잡한 시스템은 이래저래 좋을 게 없다.

둘째, ‘FPE’

데이터 형태를 그대로 유지한 채 암호화하는 ‘FPE(Format Preserving Encryption, 형태 보존 암호화)’가 있다. 랜덤 토큰과는 달리 원본 데이터를 따로 보관하는 게 아니라 데이터 자체를 암호화해버리기 때문에 보관용 데이터베이스가 따로 필요하지 않아서 전체 시스템 구조가 복잡하지 않고, 불필요한 통신구간 등 보안허점이 적다는 장점이 크다. 하지만 근거 없는 불신이 있다. “암호화는 AES처럼 형태까지도 싹 변해야 제대로 된 암호화지!” FPE의 안전성에 대한 의심은 FPE가 NIST(National Institute of Standards and Technology, 미국 국립표준기술연구소)의 표준 지정을 받지 못했기 때문에 더욱 증폭되었다. 그런데 궁금한 건,

암호화란 도대체 뭘까? 뭘 어떻게 하면 “암호화했다”고 할까?

암호화의 세 가지 조건

암호화란, 아래 세 가지 조건을 갖추면 안전한 암호화라 할 수 있다.1. 원문을 키로 암호화할 때, 원문과 암호문의 관계는 그 키에 대해 유일하다.
2. 원문과 암호문 모두 가져도 모든 키를 다 써 보기 전엔 어떤 키인지 모른다.
3. 원문과 암호문 모두 가져도 원문과 암호문의 관계는 알 수 없다.

괜히 복잡해 보이는데 달리 말하면, 조건2는 암호화의 필수요소인 ‘혼돈(Confusion)’, 조건3은 ‘확산(Diffusion)’을 뜻하고, 조건1은 암호화의 근본인 ‘경우의 수’를 뜻한다. 그래도 복잡해 보이는데,, 다시 말해, 원문을 통해 암호문을 알 수 없어야 하고, 암호문을 통해 원문을 알 수 없어야 하고, 어떤 암호문의 원문은 어떤 건지 알아낼 수 없어야 한다는 뜻으로 이해해도 무방하다.

이 조건을 모두 다 제대로 갖추면 “암호화했다”고 할 수 있다. 자 그럼, FPE는 제대로 된 암호화라 할 수 있을까? FPE에 대해 아주 조금만 더 알아보자.

안전한 FPE 알고리즘을 만드는 방법

먼저 생각해 볼 건 ‘그냥 막 완벽한 암호화’다. 신용카드 번호를 예로 들어, 16자리 십진수 원문을 무작위 16자리 십진수 암호문으로 각각 매칭해 가능한 모든 경우의 수를 생성하면 완벽하다. 그러나, 제대로 안전하려면, 즉 위 암호화의 세 가지 조건을 모두 갖추려면 동원해야 할 모든 경우의 수는 약 60,000GB 용량에 이른다,, 그러니, 완벽하지만 완벽하기 때문에 실용성은 아예 없는 것이다.

따라서 어느 정도 절충이 필요하다. 절충의 기준은 ‘충분한 안전성’이다. 보다 구체적으로 말해, “안전성이 이미 충분히 검증된 AES 알고리즘 이상의 안전성”을 확보하는 것이다. 그럼 가장 기초적인 알고리즘 세 가지를 간단히 훑어보자. 알고리즘 이야기는 왠지 그냥 막 싫지만 대충 포기하고 읽으면 나름 재밌다. 직접 구현하겠다고 덤비지 않는다면 말이지.. -_-

첫째, ‘Prefix Method’

원문의 인풋값, 십진수니까 0~9까지의 값을 AES 등 일반적인 암호화 알고리즘으로 암호화하고, 그렇게 생성된 암호문을 내림차순으로 나열한다. 그럼 순서가 달라져서 인풋값 0~9 값이 무작위로 재배치되는데, 그걸 다시 원래 순서에 따라 교체한다. 그러면 0~9 값은 다른 값으로 바뀌게 된다. 그러면 애초 목적은 훌륭히 달성하지만 ‘완벽한 암호화’와 마찬가지로 너무 큰 용량의 테이블이 형성되기 때문에 실용성은 높지 않은 방법이다.

둘째, ‘Cycle Walking Method’

이건 일단, 간단하다. 원문을 AES 등 암호화 알고리즘으로 암호화하되 원문과 같은 형태가 나올 때까지 계속 돌린다. 안 나오면 나올 때까지 계속 돌린다. 몇 번을 돌려야 할지 해 보기 전에는 알 수 없다. 역시 목적은 달성하지만 실용적이라 할 수는 없다.

셋째, ‘Feistel Network’

가장 적절한 방법이다. 우선 원문을 이진수 형태로 바꾼다. 변환된 이진수 값을 DES 알고리즘의 일종인 Feistel Network로 암호화하고, 암호화된 이진수를 다시 원문과 같은 형태로 변환한다. 알고리즘의 라운드 함수로서 AES 알고리즘을 사용하고 암호화를 여러 번 반복해 수행하기 때문에 AES 이상으로 안전하다고 할 수 있다.

살펴본 바 Prefix Method와 Cycle Walking Method의 경우 데이터 용량과 이용상의 불편함으로 인해 실용성은 떨어지지만 어쨌든, 흔히 걱정하듯 FPE가 “안전하지 않은 방법”은 아닌 것이다. 그중에서도 Feistel Network 방식은 시스템 성능에 영향을 미치지 않는 범위 내에서 적용이 가능하므로 안전성과 실용성을 모두 가졌다고 볼 수 있다.

“FPE 드디어 표준화!”

FPE는 사실상 대안이 없기 때문에 학계와 업계에서 연구개발이 매우 활발히 이루어졌다. 그런데도 NIST가 인정한 표준은 아니었기 때문에 근거 없는 불신이 팽배했다. 특히 랜덤 토큰 방식을 주장하는 측에서는 늘 “FPE는 안전하지 않기 때문에 표준이 아닌 것이다!” 열심히 떠들었다. 그 상황은 뭐랄까, 지적이지 않아서 안타까웠다,,

그러다 마침내 2016년 3월 29일, NIST는 FPE 표준화를 선언했다. FPE는 ‘랜덤 토큰’에 비해 단 하나 찝찝하게 남아 있던 약점마저도 모두 사라진 셈이다. 기술의 성격 상 시스템 적용이 간단하니 도입도 순조롭게 이루어질 것이다. 내심 민감정보 안전성 확보조치 의무화를 앞두고 시스템 복잡도 때문에라도 제대로 시행될 수 있을까 걱정했는데, NIST발 FPE 표준화 뉴스는 정말 반가운 소식이다. 이렇게 사회적으로 그리고 국가적으로 정말 중요한 상황 변화를 나 혼자 반가워 하는 것 같아 좀 쓸쓸하긴 하지만,, T_T

알파고

알파고, 시큐리티

인공지능 보안
알파고 충격의 허와 실

‘알파고 충격’이란 말이 이리도 널리 회자된다는 게 오히려 충격이다,, 기계는 원래 계산을 사람보다 잘한다. 지금껏 엑셀보다 계산 잘하는 사람 본 적 없다. 물론 바둑은 여러 게임들 중에서 경우의 수가 압도적으로 많은 편이라 당분간은 사람이 이기지 않을까 예상했지만 그래 봤자 결국엔 지게 되어 있는 일이라, 내심 기대했고 또 실망했다만 아주 이상한 일이 벌어진 건 아닌 것. 이제 바둑은 끝났다? 체스는 이미 옛날에 기계한테 졌다. 그래서 체스가 끝났나?

유일한 인간 승리자는 “이건 불공정 사기극!” 주장했던 모 변호사뿐이라는 말도 돌던데,, 비전문가의 발언이니 굳이 따질 만한 건도 아니겠다만, 직접 목격한 SNS 링크 공유가 수십 회가 넘고 해당 발언에 기반해 작성된 기사도 너무 많이 유포되다 보니 “이세돌 혼자서 프로기사 수천 명과 맞붙은 아주 비겁한 판이었다!” 식의 말도 흔히 볼 수 있다. 역시 대응 가치 없다 싶지만 떠도는 풍문의 오류 중 몇 가지는 중요하니까, 짚어 두자.

우선, 알파고의 작동은 “브루트 포스” 방식이 아니다. 오히려 브루트 포스 방법론으로는 바둑을 이길 수 없기 때문에 인공지능, 아니 머신러닝, 아니 ‘딥러닝(Deep Learning)’을 시도한 것으로 보는 게 옳다. 필터링 없이 모든 경우의 수를 싹 다 계산하는 브루트 포스 방식으로는 경우의 수가 우주적 스케일에 이르는 바둑 문제를 현재 해결할 수 없다. 그런데도 구글이 그렇게 했다? 그렇다면 구글한테 노벨슈퍼컴퓨팅상이라도 줘야 한다. -_-

“알파고는 KGS 바둑 서버의 기보 수십만 개를 때려박고 대국 중에 컨닝했다”는 말도 사실이 아니다. 머신러닝의 학습을 간단히 나눠 보면 1)인간이 가르쳐서 배운다, 2)바둑판과 돌만 쥐어 주고 기계가 시행착오를 통해 학습한다, 3)게임의 룰 파악을 위한 데이터를 던져 주면 그걸로 일단 좀 배운 뒤 시행착오 통해 학습한다.. 정도로 나눌 수 있는데, 알파고는 그 중 3)에 해당한다. 다시 말해, ‘교사학습(Supervised Learning)’을 통해 학습된 정책망들끼리 서로 대전하며 그 결과에 따라 정책망과 가치망의 성능을 개선하는 ‘강화학습(Reinforcement Learning)’을 반복함으로써 점차 강력해진다. KGS 기보는 학습 초반의 교사학습(Supervised Learning) 과정에만 사용되었다. 따라서 전문가들은 알파고의 강화학습 이후 기존 정석과 다른 정석이 나타나리라 예상했고, 실제로도 그리 되었다.

“컴퓨터 수천 대를 한꺼번에 동원했기 때문에 비겁하다!” 이건 뭐,, 여타 바둑 프로그램에 비해 알파고의 가장 큰 차별성은 하드웨어가 아니라 소프트웨어 알고리즘이다. 이세돌 9단과의 대국에 투입된 CPU 1920개와 GPU 280개로 중무장한 알파고가 CPU 1개짜리 싱글 알파고를 이길 확률은 77% 정도에 불과한데 향후 알고리즘 개선에 따라 그마저도 점차 낮아질 것이다.

다시 못 올 것에 대하여, 낭만에 대하여

“알파고는 바둑을 둔 게 아니다.” 이 말은 옳기도 하고 그르기도 하다. 알파고는 오로지 이세돌 타도를 노려 소위 ‘도장 깨기’ 하려고 만든 프로그램은 아니다. 오직 바둑을 위해 만든 게 아니란 뜻이니, 해당 방식의 딥러닝은 이후 정말 많은 분야에서 두루 쓰일 것이다. 상황을 노골적으로 적나라하게 말하자면, 지금껏 너무 많은 돈을 썼는데 앞으로는 훨씬 더 많이 써야 하니까 모종의 ‘흥행쑈’가 필요했을 뿐.

반면 달리 보면, 알파고는 너무나 바둑만을 둔 것이다. 대국 중 오로지 판과 돌만을 본 것. 우리네 인간들은 바둑판 위에서 참 많은 것들을 읽는다. 대국장에 당연히 있어야 할 게 없어서 이세돌 9단을 괴롭혔던 기세, 상대의 기분을 살피는 눈치 등 인간적인 게임 요소들 외에도, 사람들은 바둑판 위에서 세상만사 흥망성쇠의 알레고리를 읽기도 하고 통찰과 교훈 그리고 처세의 길을 발견했다고 느끼기도 한다. 포석과 전투, 정석과 변칙, 미생과 완생, 판세와 국면 등 바둑의 여러 면면은 그 자체로 대단히 흥미롭다. 바둑이 어마어마하게 위대한 그 무엇이라 여기는 지나친 정신주의는 사실 좀 웃기지만,, 그럼에도 그 나무판 위에 인간정신을 그려내는 뭔가, 말하자면 ‘유리알유희’가 있음은 부정할 수 없다. 그러니 이세돌 9단이 말했던 “바둑의 낭만”은 여전히 인간의 몫이다. 기계는 기계가 잘할 수 있는 일을 잘할 것이고.

이런 이야기를 패배한 인간의 ‘정신승리’일 뿐이라 하더라도 뭐, 할 말 없다. 사실이 그러하니까,, 아무튼, 그래서, 괜히 물 드니까 배 띄우는구나 싶은 빈 수레 호사가들 말고 보다 적확한 근거를 가지고 기계의 승리를 점쳤던 전문가들은 인간의 패배 이후 호들갑 떨지 않고 오히려 조용했던 것 아닌가 싶기도 하다. 아마도 만감이 교차했으리라..

인공지능의 강습, 어떤 직업의 종말

하지만 이거 하나만큼은 무조건 옳다. 어떤 직업들은 사라질 것이다. 왜 무조건 옳아? 애초 인공지능 연구개발에 그 어마어마한 돈을 쏟아붓는 까닭이 어떤 직업들을 없애기 위해서니까. 일도 하지만 퇴근도 하고 놀기도 하고 밥도 먹고 잠도 자고 불평불만도 많은 인간 노동자는 막 다루기 영 피곤하다. 24시간 일만 하는 기계로 대체한다면, 아 그 얼마나 편하겠나? 그래서 그 방향 연구개발에 그렇게 많은 돈이 투입되는 것이다. 반면 기술적으로 더 유의미한 명실상부한 인공지능, 그러니까 ‘강-AI’는 돈이 없어서 연구를 아예 못하고 있다. 피곤한 인간이 싫어서 기계 쓰려고 돈 투자하는 건데 인간 비슷한 걸 만들 까닭이 없기 때문.

요 며칠 ‘인공지능에게 뺏길 일자리 목록’이란 제목의 기사를 스무 개쯤 봤다. 아마도 그 목록에 ‘기자’가 들어 있어서 그런가 보다,, 로봇 기자는 지금도 활발히 활동하고 있다. 스포츠 경기 스코어 중계, 일기예보, 증권동향 등 데이터를 단순히 텍스트로 전환하는 작업과 페이지 클릭 수 등 독자반응에 따라 기사 배치 순서를 결정하는 편집 작업 등에 쓰인다. 어쨌든 지금껏 기자들이 하던 일이긴 하지만 기자라는 직업을 ‘대체’하리라는 전망은 지나친 비약이고, 목록에 오른 대부분의 직업들도 마찬가지. 지나치게 과장된 공포다.

하지만 어떤 직업들은 확실히 사라질 것이다. 그러니까, 기계적 단순동작을 반복하고 사회적 커뮤니케이션이 일에 미치는 영향이 적고 작업환경이 유해한 직업들. 일단 목록 상위에 오른 건 콘크리트공, 정육도축사, 고무 및 플라스틱 제품 조립원, 청원경찰, 조세행정 공무원 등이다. 하지만 딱 그 직업이 사라질 것이다..라기보다는 바탕에 깔린 맥락에 집중해 볼 일이다.

배운 게 도둑질이라, ICT 보안 관련 직업 중 인공지능 때문에 사라질 일이 뭘지 생각해 본다. 우선, ‘보안관제’. 보안관제란 어떤 기업에서 지속적으로 수행해야 하는 정보보안 업무를 위탁받아 제공하는 일종의 서비스업이다. 24시간 모니터링, 정책실정 및 침입시도 탐지, 분석 및 대응 등의 일을 한다. 딱, 인공지능이 할 만한 일들 아닌가? 인공지능은 잠도 안 자고 밥도 안 먹고 놀지도 않고 퇴근도 안 하며 온 종일 성실하게 그 일들을 훌륭히 해낼 것이다. 달리 보면, 해커들도 인공지능을 이용할 것이고 지금도 그러하니, 창과 방패의 기계적 진화에 따라 지금도 치열한 정보보안 전쟁터는 앞으로 점점 더 치열해질 것이다.

물론 모든 보안관제 직업이 사라진다는 말은 지나치다. 어떤 주제든 “모두 다” 그러면 대개 오류 아니던가. 인간적인, 즉 기계적으로 대체하기 힘든 역량이 뛰어난 소수는 살아남겠지. 인간적인 역량? 비판적 사고와 문제해결 능력, 네트워크 협업 및 사회적 영향력 통한 리더쉽, 호기심과 상상력, 순발력과 적응력, 효과적 구술/문서 커뮤니케이션, 자기주도적 사고 및 기업가 정신, 정보 분석 및 통찰 능력 등, 함축적으로 말하자면 ’21세기 생존기술’들이다.

인공지능을 이용한 정보보안의 미래

어차피 벌어질 일, “아 이제 우린 어떡해,,” 괜한 불안은 저만치 구석에 접어 두고 한 걸음 더 내딛어, 인공지능을 이용한 정보보안이 앞으로 나아가야 할 방향성에 대해 생각해 보자. 한창 연구가 진행되고 있는 분야라 아직 구체성 논하기엔 이르다 싶으니 대략의 뼈대만 간추려 보자.

지금까지의 보안기술 연구개발의 양상은 제약회사 연구소와 닮았다. 어떤 질병이 발견되면 그 병을 치료할 약을 만드는 식이다. 약 만들기 전에 당하는 게 그 유명한 ‘제로데이’ 공격이다. 근데 모든 사람의 체질이 하나 같진 않으니 사람마다 걸리는 병이 서로 다르고 병균 그리고 약제 성분에 노출되었을 때의 반응 또한 다르다. 그럼에도 그 모든 특수성을 총망라해 ‘일반적으로 병으로 볼 만한 것들의 목록과 그 치료제’를 연구하는 것이 오늘날 정보보안의 방법론이다. 여기서, 두 가지 문제가 발생한다. 방패의 한계 그리고 일반성의 오류.

우선, 방패의 한계

질병의 수가 늘면? 그만큼 치료약의 수도 늘어야 한다. 창이 커지면 방패도 커지고 창이 많아지면 방패도 많아져야 하는 것. 근데 질병 수가 갑자기 엄청나게 확 늘면? 즉, 창이 너무 커지면? 방패도 그만큼 커져야 하는데, 그러질 못한다. 전 지구의 악당들이 우루루 떼로 몰려들어도 그 수만큼 연구인력을 투입해 치료제를 만들어낼 수 없다. 그래서 위협 하나를 해법 하나로 막는 1:1 대응전략은 결국 질 수밖에 없는 전략이다. 해법을 찾기 위한 공격 패턴 분석 작업도 공격이 폭발적으로 늘어나면 인력을 초월한다. 그 와중에, 웹은 정말이지 말뜻 그대로 폭.발.적.으로 팽창하고 있다.

이 문제를 해결하기 위해 공격의 수법을 프로파일링해서 위협의 논리를 파악해 역시 논리로써 대응하는 전략이 ‘로지컬 보안’이다. 로지컬 보안은 기존 ‘시그니처’ 즉 질명 목록 뒤지면서 치료제를 찾지 않고 공격의 위험성 자체를 논리적으로 탐지해 대응한다. 아직까지 알려지지 않아 치료제도 개발되지 않은 공격까지 논리 통해 탐지해 차단하는 ‘COCEP(Contents Classification and Evaluation Processing)’ 논리연산탐지 엔진 등이 대표적인 예다.

그리고, 일반성의 오류

앞서 말했듯 오늘날의 보안은 ‘일반적으로 병으로 볼 만한 것들의 목록’을 살핀다. 하지만 실제 현장에서의 가장 큰 위험은 사이트마다 제각각 다른 비즈니스 로직의 허점을 노리는 공격이다. 정상적인 접근으로 가장해 웹 어플리케이션의 허점을 노리는 공격이 전체 공격의 무려 9할을 차지한다.

해커 입장에서 보자면 무지 편한 일이다. 마치 정상적인 접근인 것처럼 위장해 네트워크와 시스템 계층의 보호막을 뚫고 들어와 서버와 인터랙티브하게 대화를 주고받으며 다 털어먹는다. 대표적 수법이 SQL 인젝션, 작년에 ‘뽐뿌’ 사이트 회원 196만 명의 개인정보를 털었다. 이런 공격은 그 자체로는 정상적 접근과 다를 바 없기 때문에 기존에 하듯 질병 찾듯 찾으면 찾을 수 없다. 해당 사이트의 허점을 노리는 거라 해당 사이트의 논리에 따라 찾아내야 하는데, 아니 그걸 어떻게 일일이 사람 손으로 하나,, 자본력과 기술력 차고 넘치는 대기업 아니면 못 해낼 일이다. 그래서, 기계에게 시키자는 전략이 ‘머신러닝 보안’이다.

로지컬 + 머신러닝, 인공지능 보안

공격 수법을 논리적으로 분석해서 얻은 대응논리로써 공격을 막고, 사이트마다 서로 다른 환경에 각각 최적화된 맞춤형 대응논리로써 정상으로 위장한 비정상 접근을 막는, 로지컬 + 머신러닝 보안, 이게 답이다. 근데,

그게 정말 답일까? 그렇다기엔 인공지능은 아직 너무 비싼 기술이다. 일단 데이터는 다다익선이라 제대로 써먹으려면 어마어마하게 많은 데이터를 가지고 있어야 하고 이를 모두 분석하고 가공할 기술력도 필요한데 데이터 사이언티스트 등 인력의 값이 유행 틈타 너무 비싸졌다. 그마저도 거의 모두 다 미국 독식. 그러니 뻔히 뭐가 문제고 뭘 어떻게 해야 할지도 알지만, 못한다.

그래서, 일반 개발자를 위한 머신러닝 툴킷이 절실하다. 공구 세트 구성품들 이리저리 짜맞춰 초대기업의 인하우스 머신러닝 툴에 준하는 기능성을 갖출 수 있는 툴킷. 그렇게 구현한 기능을 로지컬 보안 방법론에 더하면, 그것이 당장 생각해 볼 수 있는 인공지능을 이용한 정보보안의 미래 아닌가 싶다.

원래 알파고 이야기와 인공지능 보안의 필요에 대해 짧게 쓰려 했던 게 자판 또각또각 두드리다 보니 쓸데없이 너무 길어졌는데,, 간단히 정리하자면,

기존 ‘질병 찾아 치료하기’ 방법으로는 해결할 수 없는 각 사이트 맞춤형 보안,
로지컬 + 머신러닝, 인공지능 보안을 통해 해결할 수 있다.

파일 암호화 이미지

“간편하려고 암호화하는 건 아니잖아요?”

파일 암호화 VS 데이터 암호화

암호화 세일즈 현장은 난처함의 전쟁터다. 암호화 제품 소개에 앞서 ‘IT란 도대체 무엇인가?’ 강의부터 시작해야 하는 난감한 상황에도 이젠 꽤 익숙해지긴 했지만 여전히 힘든 일이고, 고대 그리스부터 시작해 오늘날에 이르는 ‘암호의 역사’를 들려 달라는 요청도 종종 듣는다. 그래서 이야기를 풀어 봐도 제2차세계대전 독일 암호기계 ‘이니그마’ 이후엔 흥미가 급속히 떨어진다. 거기서부터가 진짜 중요한 내용인데! 일반적으로 사람들이 ‘암호’란 말에 대해 가지는 호기심과 기대감 수준은 아무래도 어릴 적 첩보영화 보면서 비밀정보요원 활동을 상상하던 소년기 시절에 머물러 있는 듯싶다.

물론 그런 ‘암호’와 암호화가 아주 무관한 건 아니다. 현대 암호화 또한 치환과 이동 등 고전적 암호이론에 기반해 구축된 체계니까. 하지만 학교가 아닌 실무 현장에서는 그런 교양상식은 전혀(!) 중요하지 않다. ‘암호화’는 고전적 암호 이론보다는 안전한 IT 시스템의 ‘설계’ 및 ‘구축’을 위한 기술인데, 그런 사실에 관심을 보이는 고객은 매우 적다. 세일즈의 곤란함을 호소하기에 앞서, 정보보안의 근본 중 근본인 암호화에 대한 오해는 정말 심각한 문제 아닌가? 그러니 아래와 같은 애매한 질문도 아주 자주 듣는다.

“파일을 통째로, 아니 하드디스크를 통째로 암호화 해버리면 되잖아요?”

물론 그런 조치가 필요한 때도 있다. 세상의 어떤 존재든 쓸모가 아주 없지는 않으니. 하지만 대부분의 경우 ‘디스크 암호화’는 정보보안적으로 적절한 조치가 아니고, ‘파일 암호화’가 아니라 ‘데이터 암호화’가 훨씬 더 중요한 개념이다. 이해를 위해 우선 ‘파일 암호화’란 무엇인지부터 알아보자.

파일 암호화란?

너무나 당연한 말이지만, ‘파일 암호화’는 파일을 암호화하는 것이다. 그런데, ‘파일’은 뭐지? 매일 입에 담는 익숙한 말이지만 이리 물어 보면 왠지 모르게 생소하게 느껴진다. ‘파일’은 의미 있는 정보를 담는 논리적인 단위다. 그래서 우리는 컴퓨터를 사용할 때 파일을 단위 삼아 대화한다. “파일이 몇 개지?” “이 파일의 크기는 얼마야?” “그 파일은 이 폴더 안에 들어 있어.” 그런 식으로 파일을 기준으로 정보를 저장하고 분류하고 관리한다. 그래서 파일이란 말에 너무나 익숙하다. 그러다 보니 ‘파일 암호화’란 말도 원래 익숙했던 말처럼 들린다. 말만 듣고도 그게 뭔지 전부 다 이해한 듯한 기분이 든다. 하지만 ‘파일 암호화’는 그리 간단한 개념이 아니다.

우리는 파일 단위로 묶고 이름을 붙여 열람과 검색을 위해 어디에 저장할지 등을 결정함으로써 정보를 관리한다. 그러면 컴퓨터 내부에서는 1)물리적 저장장치, 2)운영체제 커널, 3)어플리케이션 등 3개 영역에서 각각 다른 방식을 통해 파일을 처리한다. 따라서 우리가 흔히 말하는 ‘파일 암호화’ 또한 그 3개 영역에서 각각 다른 방식으로 이루어진다. 이에 대한 보다 상세한 설명은 따로 책 한 권 분량 정도가 필요하기 때문에 지금은 간단히 개요만 살펴보자.

하지만 1)물리적 저장장치, 주로 하드디스크를 통째로 암호화하는 ‘디스크 암호화’는 현재 논점으로부터 멀리 떨어져 있기 때문에 일단 논외로 하겠다. 물론 하드웨어 암호화가 필요한 경우도 있다. 정보보안이 아주 치명적인 곳에서는 상상할 수 있는 모든 보안조치를 하나도 빠짐없이 모두 다 적용해야 하니까 그런 경우엔 하드웨어 암호화 조치까지도 필요하다. 예를 들자면, 핵발전소라든지. 하지만 그런 경우에도 추가 및 보완 조치일뿐 정보보안의 바탕은 ‘데이터 암호화’여야 한다.

아주 단순히 말해서, 2)운영체제 커널 영역에서 3)어플리케이션 영역으로 갈수록 관리 부담이 커지는 대신 보안성이 높아진다. 이는 여타 모든 정보보안 기술 전체에 걸쳐 고루 적용되는 일종의 원리다. 보안성을 높이면 아무래도 사용이 불편해진다. 다시 말해, 간편함을 추구하면 보안성이 낮아질 수밖에 없다. 그럼에도 간편함은 너무나 강력한 매력이라서 ‘파일 암호화’와 ‘디스크 암호화’ 제품을 판매하는 사람들들은 흔히들 이리 말한다.

“파일과 디스크를 통째로 암호화해버리니까 정말 간편합니다!”

정말 매력적인 호소 아닌가? 간편하다는 건 무조건 좋은 일이니까. 하지만 그냥 대충 넘어가지 말고 이렇게 다시 되물어야 한다.

“간편하기 위해 암호화하는 건 아니잖아요?”

그렇다. 암호화는 보안성을 높이기 위해서 하는 것이다.

실제 업무현장에서의, 파일 암호화의 위험성

이렇게 단순하게 생각해 보자. 지나친 단순화 같긴 하지만 일단,

– 파일은 데이터를 담는 통이다.
– 파일에 든 각각의 데이터들이 모두 똑같은 위험성을 가지고 있진 않다.

실제로는 보다 복잡한 차이가 있지만 일단, 간단히 말해 ‘파일 암호화’란 데이터가 든 통을 통째로 암호화해버리는 것이고, ‘데이터 암호화’란 통 안에든 데이터 중에서 꼭 감춰야 할 위험한 데이터만 따로 골라 암호화하는 것이다 두 방식은 각각의 장단점이 있지만, 위 “관리 부담이 커지는 대신 보안성이 높아진다”는 원리는 그대로 적용된다. 파일 암호화는 관리가 간편하다. 하지만 보안성은 낮다. 왜?

어떤 회사에 고객 정보가 저장된 데이터베이스 파일이 있다고 하자. ‘파일 암호화’ 방식은 그 데이터베이스 파일을 통째로 암호화한다. 다시 말해, 파일을 사용하기 위해서는 암호화된 파일 전체를 복호화해야 하고 작업이 끝나면 다시 파일 전체를 암호화해 저장하는 것이다. 그런 경우의 위험은 아래와 같다.

1. 사용자 실수 또는 고의로 암호화 하지 않는 경우 : 사용자의 실수로 암호화하지 않는 상황이 빈번히 발생한다. 암호화해야 한다는 걸 잊거나 그냥 암호화 절차가 번거롭고 귀찮아서 그냥 평문 상태로 저장해버리는 경우가 많다. 보안사고의 대부분은 사용자 실수 때문이라는 사실을 잊지 말자. 사용자 실수를 미연에 방지하고 감시하는 장치가 필요하다.

2. 파일의 전체 내용이 평문 상태로 메모리에 존재 : 파일 통째로 암호화되어 있다면 파일에 든 정보 내용을 읽을 때 불가피하게 파일 전체를 복호화할 수밖에 없다. 그러면 암호화되지 않은 전체 평문이 메모리에 존재하게 되어서, 메모리 덤프 등의 수법을 통한 데이터 유출 위험이 있다. 평문 노출은 무조건 최소한도로 줄이는 게 좋다.

3. 키 관리 및 접근제어, 보안감사 등 추가 도구 필요 : 암호화란 암호화 단독으로는 쓸데없는 기술이다. 암호화 및 복호화 작업을 위한 키 관리 및 접근제어, 보안감사 등 다른 보안도구들이 함께 동작해야 한다. 하지만 이것저것 다 붙이고 나면 ‘파일 암호화’의 가장 큰 장점인 단순성으로부터 멀어진다. 간편함을 강조하지만 결국 똑같이 복잡해지는 것이다. 게다가 그렇게 성질이 서로 다른 도구들을 하나의 시스템 안에 통합하는 기술적 위험도 있다. 사실 암호화란 그 자체로는 어려운 기술이 아니다. 앞서 말했듯 안전한 IT 시스템의 ‘설계’ 및 ‘구축’을 위한 기술이라서 어려운 것이다.

이 중 특히 눈여겨볼 점은 “2. 파일 전체 내용이 평문 상태로 메모리에 존재”하기 때문에 발생하는 위험이다. 하지만 이는 어떠한 암호화 방식에도 그대로 해당되는 위험이다. 정보를 읽기 위해서는 메모리에 평문이 존재해야만 하니까. 하지만 얼마나 많은 정보를 얼마나 오랫동안 노출할 것인지 차이가 매우 크다. 실제 업무현장에서의 상황을 그려 보자.

파일 전체를 하루 종일 평문 상태로 노출하는 암호화?

고객 정보가 저장된 데이터베이스 파일 전체를 통째로 ‘파일 암호화’ 했다 치자. 그러면 파일 속에 든 어떤 정보든 열람하려면 파일 전체를 복호화해야 한다. 찾는 데이터가 주민등록번호 등 중요한 개인정보가 아닌 경우에도 전체 내용을 모두 다 노출하는 것이다. 그러면 검색, 열람, 처리 등의 작업을 마치고 다시 암호화할 때까지 모든 정보가 메모리 상에 평문 상태로 방치된다. 고객관리 업무가 많은 회사라면 직원이 출근하자마자 암호화 데이터를 복호화해서 하루 종일 전체 데이터를 평문 상태로 노출했다가 퇴근할 때 다시 암호화한다고 해도 결코 지나친 과장이 아니다.

반대로, 중요한 데이터만 따로 암호화한 경우에는 어떨까? ‘데이터 암호화’는 중요 데이터를 따로 암호화해서 해당 정보가 필요할 때에만 복호화해 처리하고 다시 암호화한다. 노출하더라도 특별히 위험하지 않은 일반 정보만 열어서 작업하다가 특정 암호화 데이터가 꼭 필요한 순간에 일정한 절차를 거쳐 복호화해서 일을 마치고 다시 암호화한다. 위 ‘파일 암호화’에 비하면 위험성 노출 시간부터 현저히 짧다. 그리고 암호화 외 따로 필요한 키 관리 및 접근제어, 보안감사 등의 도구들도 모두 한 제품으로 통합되어 제공되므로 이종기술 결합에 따른 불안정성도 매우 적다.

하지만 개인이 쓰는 컴퓨터에서, 그리고 기업에서도 어떤 특수한 필요 때문에 정보를 파일 단위로 구별해 관리하는 경우가 있다. 그럴 때는 ‘파일 암호화’도 선택할 만한 방법일 수 있다. 하지만 ‘파일 암호화’는 ‘데이터 암호화’에 포함되는 일부분이라고 봐야 한다. 다시 말해, ‘파일 암호화’는 일부 데이터를 따로 암호화할 방법이 없지만, ‘데이터 암호화’는 파일 내용의 부분 또는 전체를 선택하여 암호화함으로써 파일 암호화와 동일한 효과를 얻을 수 있다.

“파일과 폴더를 통째로 암호화해버리니까 정말 간편합니다!”

그렇다. 간편하다. 그러나,

“간편하려고 암호화하는 건 아니잖아요?”

34_0 (1)

넷플릭스 대이동, 클라우드는 믿을 만한가?

“넷플릭스, 마지막 데이터센터 문 닫다.”

딱 한 줄, 하지만 그 함의는 광대하다.

먼저, 최근 한국 서비스 개시에 따라 종종 기사로 뜨는 ‘넷플릭스(NETFLIX)’란 회사에 대해 알아보자. ‘넷플릭스’는 1997년 비디오 대여 사업부터 시작해 DVD를 거쳐 현재는 온라인 스트리밍 서비스 사업을 주로 하는 회사다. 역시 딱 한 줄, 간단하다. 하지만 어마어마하다.

스트리밍 서비스 이용자 수가 무려 7천5백만 명인데 그딴 건 아예 무의미한 숫자에 불과한 건, 지금도 자기가 보유한 성장세 기록을 스스로 막 갱신하고 있는 명실상부 단독선두. 이는 단순 시장 확장에 따른 결과가 아니라 ‘하우스 오브 카드’, ‘마르코 폴로’ 등 자체 제작 컨텐츠 확충을 통해 이룬 성취라 더욱 튼실하다. 미국 내 인터넷 접속자가 가장 많은 시간대에 트래픽의 3분의 1을 넷플릭스가 사용한다는 이야기도 있으니, 방송산업 역사를 그냥 막 처음부터 다시 쓰고 있다 해도 과언이 아니다.

그런 초거대 공룡 IT기업이 자체 데이터센터를 완전히 폐쇄하고 모든 시스템을 ‘AWS(Amazon Web Services, 아마존 웹 서비스)’ 클라우드 환경으로 옮겼다. 그 이유는 무엇이고, 대이동에 왜 7년씩이나 걸렸으며, 클라우드는 넷플릭스마저 감당할 정도로 진짜 대세가 된 게 확실한 건지, 차례차례 알아보자.

“서비스가 사흘째 먹통이야!”

지난 2008년, ‘넷플릭스’는 데이터센터의 DB가 손상되어 3일간 DVD 배송을 못했다. 서비스 회사가 서비스를 못한 것이다. 고객이 원하면 언제든 지체 없이 서비스를 제공하는 ‘가용성’은 서비스 회사에겐 가장 중요한 핵심역량인데, 바로 그 가용성에 위기가 닥친 것. 이를 어쩌나, ‘넥플릭스’ 플랫폼 엔지니어링 부문 부사장은 장애 발생 즉시 클라우드 이전 작업 준비에 착수했다. 그만큼 가용성은 치명적으로 중요한 요소란 뜻이다.

‘넥플릭스’는 ‘AWS’를 클라우드 업체로 결정했다. 사실 대안이라 할 만한 게 그때도 없었고 지금도 없으니 오래 고민할 문제도 아니었다. 작업은 착착 진행되어 기존 데이터센터에서 가동되던 서비스를 클라우드 환경으로 옮겼다. 하지만 회사 규모만 보더라도 짐작할 수 있듯, 쉬운 일은 아니었다. “동영상 파는 회사니까 동영상만 옮기면 되는 거 아닌가?” 어, 아니다.

짐짝들 대충 나열해 보자면 우선 상품인 컨텐츠 데이터, 요즘은 너무나 당연해 대세란 말 붙이기도 민망한 분산 데이터베이스, 돈 받고 팔아야 하니까 과금 시스템, 전설적 성공의 핵심요소였던 사용자 취향 분석 시스템, 그걸 뒷받침하는 빅 데이터 컴퓨팅, 그 모두를 종합한 이른바 비즈니스 로직 총체 등, 대충 보더라도 단기간 내에 쉽게 처리할 수 있는 일이 아니다. 결국, 무려 7년이나 걸렸다.

“뭐? 7년이나 걸린다고,, 왜!”

그러고 보면 그 회사 경영진도 참 독하다,, 7년씩이나 기다렸으니. 한 명쯤은 이리 따졌으리라. “그냥, 옮기면 되는 거 아냐? 왜 그리 오래 걸려?” 물론 그렇게 할 수도 있다. 모든 시스템을 변경 없이 그대로 들어서 AWS 환경에다 톡 떨어뜨려도 될 일이니까. 하지만 앞서 언급했던 엔지니어링 부사장은 “그렇게 하면 기존 데이터센터 시절의 문제까지도 모두 옮기는 셈”이라며 거부했다.

즉, ‘클라우드 네이티브 전략’을 택했다. 느리고 비효율적으로 보이지만 불가피한 선택. 기존 기술 전체를 전면적으로 재구축하고, IT기업인만큼 기술과 직결될 수밖에 없는 사업의 방법론까지 근본부터 싹 다 뜯어고쳤다. 그 고생을 감수해도 될 정도로 클라우드 환경의 매력은 아주 컸다. 돈 꼴레오네 식으로 말하자면 ‘거절할 수 없는 제안’인 것이다. 왜?

클라우드가 대세 된 결정적 이유, 탄력성

클라우드의 가장 큰 장점은, ‘탄력성’이다. 애초에 컨텐츠 사업이란 폭발적으로 확장하는 급속도 성장에 대한 기대를 연료 삼아 돌아가는 사업이다. 그러니 언제든 서비스 요구를 충족할 준비가 되어 있어야 하는데, 기존 데이터센터 시절엔 그게 쉽지 않은 일이었다. 수백, 아니 수천 대의 서버를 어떻게 순간적으로 설치하나,, 불가능한 일이다.

하지만 클라우드의 탄력성은 그 치명적 문제를 클릭 몇 번만으로도 쓱삭 해결할 수 있게 해 준다. 가상적으로는 무한한 수의 서버 확장과 10의 15승 페타바이트(Petabyte, PB, 1,000,000,000,000,000 바이트)급 스토리지를 그냥 단추 띡 누르면 추가할 수 있는 것이다. 그리고 클라우드 대기업 AWS가 이미 전 세계에 쫙 깔아 둔 ‘인프라’를 그냥 이용하기만 하면 된다. 그러니 이런 달달한 제안을 누가 감히 거절한단 말인가,,

거대한 성공사례, “그럼 나도 클라우드로 가도 돼?”

‘넷플릭스’ 이민은 클라우드 사업 역사상 가장 큰 성공사례인 듯싶다. 일단 그만큼 큰 규모 사례가 없으니. 아마존은 넷플릭스에게 사용료 얼마를 깎아 줬을까? 궁금할 정도로 광고 효과도 크다. 어쩌면 지나치게 크다. “아니, 그냥 크면 크지 왜 왜 지나치게 커?”

그건 아무나 할 수 있는 일이 아니기 때문이다. 생각해 보자. 위 이민을 결정하고 실제 이민을 감행한 과정에서 슬그머니 드러나는, 그 초거대공룡 자체가 보유한 기술력과 무려 7년이라는 장기간을 견뎌내는 자금력을. 그런 규모가 뒤를 받쳐 줬기 때문에 이룰 수 있는 성취로 해석해도 무방하다. 즉 아무나 할 수 있는 일은 아닌 것이다.

하지만 반면, 그런 대규모의 그리고 고도의 기술력과 자본력은 그게 무려 ‘넷플릭스’이기 때문에 필요했던 요소, 다시 말해 넷플릭스 규모가 아닌 회사라면 꼭 필요한 요소는 아니라고 볼 수도 있다. “난 아주 작고 소소한 서비스를 하고 있을 뿐인데, 나도 클라우드로 가도 될까?” 이거 아주 중요한 질문이다. 그래서,

AWS 포함, 여러 클라우드 업체의 서비스를 이모저모 검토해 봤다.

서비스 이전은 간단, “걱정하실 것 없어요!”

먼저 감탄부터 하자. 모든 ‘대세’는 대세가 된 까닭이 다 있다더니 역시나, 정말 세세한 부분까지 철저히 준비해 둔 친절함에 감탄했다. 앞서 말했듯 ‘넷플릭스’는 넷플릭스이기 때문에 그렇게나 오래 걸렸던 일이지, 우리네 평범한 사람들 수준을 천문학적으로 막 초월해버리지 않는 규모의 사업이라면 당장 클라우드로 옮겨도 특별히 문제 될 것은 단 하나도 없어 보일 정도로 전산환경을 참 잘도 만들어 놨다. 가히 ‘인프라’라 할 만하다.

위 ‘인프라’라 함은, 마치 정상적인 국가에서의 수도나 전기처럼 당연히 존재하는 환경인 것처럼 자연스럽게 느껴지는 서비스라는 뜻으로 쓴 말이다. 말하자면, ‘보편기술’이다. 그럼 AWS 등 클라우드 환경을 보편기술로 봐도 될까? 아니 그 전에, 보편기술이 뭔데?

보편기술과 특수기술, 핵심은 “불안!”

어디서 들어 본 말은 아니고 그냥 대충 막 붙인 말이긴 하나, ‘보편기술’은 말의 뜻 그대로 두로 널리 미쳐 모든 것에 들어맞는 기술을 의미한다. 꼭지를 돌리면 나오는 수돗물처럼, 이 물은 어디서 나타나 어디를 거쳐 여기까지 온 걸까 호기심 일지 않고, 마치 공기처럼 당연하게 느껴지는 기술. 사실 생각해 보면 당연한 일은 아니다. 만약 국가 시스템이 붕괴된 상황을 상상하면 수도꼭지를 돌려도 물은 나오지 않을 테니까.

보편기술로 두루 퍼지기 전의 기술은 ‘특수기술’이라 부르기로 하자. 특수기술이 보편기술이 되는 과정을 지배하는 주된 정서는 불안과 공포다. 그게 뭔지 몰라 당연히 발생하는 불안 외, 의도적으로 유포되는 불안도 있다. 이를테면, 테슬라가 주장하는 교류 전기 사업을 방해하기 위해 직류 파의 독점자였던 에디슨이 악의적으로 퍼뜨렸던 “교류는 위험하다!” 광고처럼. 그러고 보면 에디슨도 참, 비겁했지.

보편기술이 되고 싶은 특수기술

그럼 현재 보편기술이 되려 애쓰는 대표적인 특수기술은 뭐가 있을까? 자율주행 자동차, 3D 프린터 등 여러가지 물건들이 떠오르지만 가장 압도적인 건, 로봇. 로봇 기술 발전을 우려하는 불안도 흔하다. 과거 러다이트 기계파괴 운동을 다시 벌여야 한다는 주장도 들릴 정도니. 아주 틀려먹은 불안은 아니다. 빌 게이츠마저 “AI가 발달하면 인류에 위협이 된다. 인공지능을 걱정하지 않는 사람들을 이해할 수 없다”고 말한다.

간단히 말해, 지금은 값이 싸지만 노사갈등의 위험이 있는 인간을 주로 쓰지만, 로봇 기술이 보다 발전해 값이 싸지면? 값도 싸고 갈등도 없는 로봇을 주로 쓰게 되리라는 건 너무나 뻔한 일 아닌가. 물론 그럼에도 인간은 어떻게든 생존할 거라 믿어야지, 지금껏 늘 그래 왔으니까. 아무튼,

특수기술은 그러한 사회적 불안을 제거함으로써 보편기술이 되고, 세상은 달라진다. 직류 전기 시절, 멀리 가지 못하는 전기를 공급하기 위해 큰 건물마다 따로 운영하던 발전소에서 일하던 민간 기술자들은 교류 전기가 대세가 된 이후엔 대개 국가가 운영하는 전기 관련 인프라 곳곳에 재배치되었다. 보라, 신기술의 위협에도 인간은 어떻게든 생존한다.

그럼 다시, 넷플릭스쯤 되는 회사도 이동했으니, 클라우드 환경을 이제 완전한 보편기술로 봐도 될까? 이 불안은 정말 쓸데없는 괜한 기우인가?

IT보안 = 어플리케이션+시스템+네트워크 보안 = 데이터 보안

IT보안은 기술적으로 어플리케이션, 시스템, 네트워크 보안의 범주로 나눠 볼 수 있다. 모든 IT 시스템이 그 3개의 계층으로 구성되기 때문이니, 다시 말해 그 모두를 만족해야 비로소 “안전한 IT 시스템을 이루었다”고 말할 수 있다.

그리고, 오늘날 IT 보안의 중심은 네트워크와 서버 등 IT 인프라를 보호하는 보안으로부터 데이터와 어플리케이션을 보호하는 보안으로 이동하고 있다. 이는 지켜야 할 진짜 가치가 무엇인지 깨닫는 과정이다. 정말 지켜야 할 가치는? 데이터다.

그런 맥락에 따라 현재 클라우드 환경을 살펴보면,

클라우드 환경은 “대체로” 안전하다.

앞서도 말했듯, 감탄할 정도로 잘 만들었더라. 정말 꼼꼼하게. 대표적인, 사실상 독점으로 봐도 무방하다 싶은 ‘AWS’를 보면, 이것저것 참 잘도 만들어 놨다.

어플리케이션 부문은, 이건 좀, 글쎄,, 하지만 어플리케이션 보안은 인프라 시설 제공자의 책임보다 인프라 사용자, 즉 클라우드 환경에 입주한 사업자 각자의 책임이 더욱 크다. 어플리케이션은 사업자의 것이니까. 시스템 부문과 네트워크 부문은, 기존 데이터센터 시절(?)에 적용하던 기술들은 웬만큼, 아니 웬만하다고 말하기 좀 미안할 정도로 구색을 제대로 갖추고 수준 또한 충분해 보인다. 게다가 예전엔 밤에 잠도 못 자고 낑낑대며 겨우 해결하던 문제들이 이제 버튼만 띡 누르면 알아서 해결해 주니 일단 너무 고맙다. 어, 근데,

패턴 매칭 방식 WAF

고전적 패턴 매칭 방식의 WAF(Web Application Firewall, 웹 어플리케이션 방화벽)을 쓰는구나,, 물론 아주 이해 못할 방식은 아니다. 패턴 매칭 방식의 WAF로도 충분히 안전함을 보장할 수 있다. 패턴 매칭 수준 이상으로 웹 컨텐츠를 검토한다면 클라우드 입주자들이 오히려 불안하게 여길지도 몰라 그런 결정을 내렸을 수도 있다. 하지만 패턴 매칭 방식 WAF를 통해 제대로 안전하기 위해서는 패턴을 위협 수준과 물량만큼 늘여야만 하는데 이는 또 시스템 성능 저하 문제로 이어지는 등의 손해가 있다. 즉, 권장할 만한 방식은 아니다.

WAF는 웹을 통해 오가는 각종 컨텐츠의 안전성을 점검하는 장치다. 모든 데이터는 어플리케이션을 통해 이동하고, 현재 어플리케이션의 주요 환경은 웹이다. 통신기술뿐 아니라 시스템 환경에서부터 사용자 인터페이스에 이르기까지, 모든 IT 기술이 웹으로 통합되고 있다. 앞으로는 모든(!) 어플리케이션이 웹 환경에서 개발되고 운용될 것이다. 이거 어째 좀 찝찝하게 남는 좀 쓴 뒷맛이 있다는 뜻이다. 그런 점에서,

현재 클라우드 환경은 대.체.로. 안전하다고 평가할 수 있겠다.

안전한데, 대체로 안전해,, 이거 생각이 좀 복잡해진다. 기존 데이터센터에서는 웹 컨텐츠 보안이 불안하면 그냥 WAF 하드웨어를 사다가 설치하면 그만이었는데, 클라우드 환경에서는? 클라우드 인프라 사업자가 제공하지 않는 WAF 기능을 꼭 쓰고 싶다면, 그 이유 때문에 클라우드 환경으로 이동하지 말라는 말인가? 그렇지는 않다.

WAF “서비스”

클라우드 환경이 일종의 ‘서비스’라서, 기존에 직접 처리해야 했던 문제 해결을 서비스 형태로 제공 받듯이, WAF 기능 또한 ‘서비스’ 형태로 제공된다. 클릭 몇 번만으로 기존에 엄청 오랜 시간을 투자해 직접 처리해야 했던 온갖 문제들을 즉시 해결할 수 있다는 것이 클라우드 환경의 가장 큰 장점이듯, 과거 하드웨어 설치하고 사용법 교육받고 세팅하고 그러던 WAF 기능 또한 클릭 몇 번만 하면 하드웨어 WAF 기능 그대로 동작한다. 그럼으로써 클라우드 환경은 비로소,

IT보안 = 어플리케이션+시스템+네트워크 보안 = 데이터 보안

이 조건 모두를 충족해 완전하게 ‘안전한 IT 시스템’을 이루게 된다. 결론은,

“넷플릭스쯤 되는 회사도 클라우드로 갔는데, 우리도 가도 돼?”

네, 가도 됩니다. WAF 관련 약간의 조치만 취한다면, 충분히 안전합니다.

ces2016

CES 2016 단상, “IoT는 이미 현실입니다.”

“IoT는 미래의 것이 아닙니다. 이미 현실입니다.”

지난 1월 7일 미국 라스베이거스에서 열린 세계 최대 가전전시회 ‘CES 2016’의 기조연설자로 나선 홍원표 삼성 SDS 사장의 선언이다. 홍 사장은 이어서 “IoT는 우리 일상에 다양한 형태로 적용되고 있다. 플랫폼 개방성을 더욱 확대하고 산업 간 협력을 통해 무한한 가치를 창출하기 위해서는 1)스마트 제품과 핵심부품, 2)플랫폼, 3)정보보안 솔루션이 핵심”이라고 말했다.

여기서 잠깐, SDS 사장이 어째서 CES라는 초거대 박람회 기조연설자로 등장한 걸까. 그건 CES의 최대 스폰서가 삼성이기 때문이다. 말로만 글로벌 대기업이 아닌 거라. 하지만 각국 기자들이 고른 CES 2016 4대 키워드가 ‘IoT’, ‘중국’, ‘스마트카’, ‘VR’인 걸 보더라도 그 한창 요란한 “차이나 광풍” 호들갑은 절대 괜한 빈말이 아니니, 향후 기술 및 산업 주도권 약화 우려 또한 괜한 기우가 아니다. 이미 국가적 차원의 심각한 문제다. 이거 생각하면 후일 걱정에 밤에 잠이 안 올 지경이다,,

CES는 가전제품 전시회?

해마다 이맘때 되면 온갖 지면을 화려하게 장식하는 ‘CES(Consumer Electronics Show)’는 1967년 뉴욕에서 시작해 라스베이거스와 시카고에서 번갈아 격년 열리다가 1998년 연 1회 라스베이거스 개최로 굳어진 세계 최대 규모의 가전제품 박람회다. CES 박람회를 통해 지금껏 첫선 보인 물건들은 비디오 레코더, 레이저디스크, 캠코더, CD 플레이어, DVD, HDTV, Xbox, 블루레이 등 모두 다 한 시대를 풍미하던 역사적 가전제품들이다.

하지만 승승장구하던 가전업체들의 위상이 어째 좀 초라해졌다. 나이 먹어 더 이상 청춘물 주인공 노릇 못하게 된 퇴물 배우 같은 느낌마저 든다. CES는 흔히 ‘국제 소비자 가전제품 전시회’ 정도로 번역되는데, 이제 흘러간 뽕짝 옛말 같은 느낌이다. 가전업체들의 빈 자리를 지금은 일단 자동차 회사들이 대신 채우고 있지만 그 또한 언제까지 갈지 모른다. 이제 그만 박람회 이름을 바꿔야 하지 않을까? ‘가전제품 전시회’란 말은 영 안 어울린다 싶은데?

행사장에서 가장 먼저 눈에 들어오는 것도 가전제품이 아니라 각종 탈것이다. 스마트카 전시장의 열기가 가장 뜨거웠고, 뜻밖에 “사람이 타는 드론”이 화제였다. 어, 이상한데?

드론의 핵심은 ‘무인’ 아닌가? “사람이 타는 드론”은, 헬리콥터잖아,, 날개가 4개 사방으로 뻗었다고 드론인 건 아니고, 그건 그냥 쿼드콥터. 탑승자가 직접 조종하지 않으니까 드론인 것도 아닌 까닭은, 해당 부문의 사실상 국제표준으로 통하는 미국 ‘연방항공청 FAA(Federal Aviation Administration)’은 “사람을 실어 나르는 운송용 항공기는 드론의 범주에 포함하지 않는다”라고 명백히 밝히고 있다.

어떤 용어의 뜻이야 언제든 바뀔 수 있는 것인데 너무 쩨쩨하게 따지는 거 아니냐 싶기도 하지만, 이런 건 본래 뜻을 정확히 말하고 그래야 개념이 제대로 정립된다. 그러니 “사람이 타는 드론”이라고 요란하던 그 물건은 ‘자율주행 쿼드콥터 프로토타입’이다. 이러한 ‘자율(Autonomous)’과 ‘무인(Unmanned)’의 개념 혼동은 요즘 여기저기서 참 흔한 일이긴 하나, 이런 거 자꾸 헷갈리고 그러면 감히 말하건대, 미래창조과학은 없다. 진짜로.

융합은 시시하다?

혹자들은 “아니, 명색이 CES인데 발명도 없고 혁신도 없고 융합만 있어? 그거 전부 다 이미 있던 기술 그냥 섞은 거 아녀?!” 불만을 토로하기도 한다. 아주 틀린 말은 아니다. 스마트카 V2X 기술은 말 나온 지 한참 옛날이고 자율주행도 예전부터 언론에 심심찮게 등장하는 소재, 자동주차는 이미 제품화까지 끝난 기술이고 HUD(Head-Up Display) 제품도 이미 흔하다. 그.러.나.

그런 불만은 산업공학적 무지일 뿐이다. 진짜 신기술을 소비자 가전제품에 그대로 박아 넣으면 위험성 때문에라도 못 쓴다. 지금 기준으로도 부족해 보완이 필요하다. 의약품 개발 및 허가 절차 수준의 안정성 검증이 필수다. 그러니 이런 데서 말하는 ‘프로토타입’은 ‘제품 출시 전 일단 무조건 멋지게 만들어 본 컨셉 모형’이 아니라 ‘아직 소비자 앞에 내놓을 준비가 덜 된 물건’의 뜻으로 읽어야 한다.

그럼에도, 이미 다 있던 기술 그냥 섞기만 한 거, 맞다. ‘CES 2016’ 전체를 관통하는 추상적 키워드 딱 하나만 고르라면 ‘융합’이다. 그리고 그 융합의 바탕은 행사 기조연설이 선언했듯 이미 현실이 된 IoT다. 경계가 사라진 또는 흐릿해진 이종 산업 간의 뒤섞임이 다시 전 산업분야로 영역을 확장해 전체 판을 크게 넓히고 있는 형국이다. 얼핏 보기엔 “왜 이런 게 가전제품 전시회에 나왔지?” 싶은 것들이 대다수라 주객이 전도된 듯싶기도 하지만, 그 애매해 보이는 것들도 얼마 지나지 않아 ‘가전’의 영역으로 들어오게 될 것이다. 다시 말해,

IoT로 대동단결!

그러니 결국 데이터 허브 주도권 쟁탈전이다. 집 안에서는 냉장고와 TV, 그리고 벽면 부착형 센서 등 다양한 장치들이 소위 ‘스마트홈’의 중심 자리를 두고 경쟁한다. 자동차회사들은 이미 예전에 “이제 우리는 IT 회사다. 자동차는 움직이는 데이터 센터”임을 선언했다. 그 결과 치열한 혼전 양상이 계속되어 무지 어지러운데, 시각을 달리해 관찰해 보면 뜻밖에 아주 간단한 판이다. 그러니까 눈을 어지럽히는 온갖 물건들을 빼고 그 핵심이 뭔지 생각해 볼 필요가 있다.

다시 위 기조연설로 돌아가 보자. “1)스마트 제품과 핵심부품, 2)플랫폼, 3)정보보안 솔루션”. 그렇다. 이 일견 완전한 혼돈 상태로 보이는 어지러움도 결국 위 세 가지를 선점하기 위한 노력일 뿐이다. 본격 IoT 시대가 도래하면 세상 모든 물건에 1)의 적용이 필요하니 수요와 공급 대세도 이에 집중될 것이고, 그것들이 모두 2)를 통해 연결되니 역으로 2)가 1을 결정하게 되는데, 3)이 없으면 1)이든 2)든 뭐든 모든 게 싹 다 와르르 무너진다. 그런데 그 쟁탈전 각 판의 승자가 아직 결정되지 않았으니, 이 ‘가전제품 전시회’가 이토록 혼란스러워 보이는 것이고 행사 이름마저도 어색하게 들리는 것.

전투가 끝나고 승패가 어느 정도 결정되면, CES는 머잖아 다시 이름에 어울리는 ‘소비자 가전제품 전시회’로 돌아가게 되리라 예상한다. 앞서 걱정했던 향후 기술 및 산업 주도권의 향방 또한 그 전투 결과에 따라 결정될 것이고.

IoT, “Information of Things”

어쩌면 혼동의 까닭은 ‘IoT’란 말을 곧이곧대로 “Internet of Things” 즉 ‘사물인터넷’으로 이해하기 때문 아닐까 하는 생각도 든다. 원래 그 뜻이긴 하지만,, 해당 용어를 상징하는 대표적 장면이 “스마트폰으로 집에 있는 TV를 켜고 끌 수 있다” 식의 단순화는 확실히 문제다. 지나친 친절함이 본질을 감춘다.

그러니 요즘 일각에서는 개념 정립을 위해 ‘IoT’란 말을 “Information of Things”으로 해석하기도 한다. 사물의 정보, 즉 세상 모든 것들의 정보가 거대한 웹망(Web Mesh) 속으로 들어오는 것을 뜻한다. 이런 개념으로 본다면 ‘CES 2016’도 “이것저것 많긴 한데 왠지 산만하기만 하고 뭔가 좀 이상해,,” 반응도 대폭 줄지 않을까 싶다. ‘Information of Things’ 개념은 보다 긴 말이 필요하다 싶어, 후일을 기약한다. 아무튼,

혼란 와중에 개념의 핵심을 읽어내려는 노력이 절실한 시절이다.

헬로 키티 해킹

헬로 키티, 너마저

헬로 키티 해킹
키티가 털렸다. “Hello Kitty?” 아니, 나 전혀 헬로하지 않아,, T_T

초월적 인기 캐릭터 ‘헬로 키티(Hello Kitty)’의 팬 커뮤니티 사이트 ‘산리오타운닷컴(Sanriotown.com)’의 이용자 330만 명의 정보가 유출되었다. 범죄 발견 경위도 예사롭지 않다. 인터넷상에 그냥 아무렇게나 덜렁 노출되어 있었던 것이다. 키티의 주인 ‘산리오닷컴(Sanrio.com)’의 안전에 대한 의혹도 있지만, 이에 대해 회사는 아무 대답도 하지 않았다.

키티는 대충 막 흔한 그런 고양이가 아니다. (고양이가 아니라 고양이처럼 표현한 사람이라는 주장이 전 세계 키티 팬들의 아름다운 마음을 박살냈지만, 산리오 본사는 “고양이의 의인화일 뿐”이라며 공식 부정했다.) 단독 캐릭터의 자산가치가 무려 20조 원이 넘는 걸로 평가되고 시장규모 또한 연간 3,500억 원에 이른다. 세계 70여 개 나라에서 팔리는 상품 종류도 5만 종이 넘는다. 무기와 마약 빼곤 모든 물건에 키티가 붙어 있다 해도 과언이 아니다. 빌 게이츠가 6조 원을 내밀며 디지털 판권을 인수하려 했지만 산리오는 거절했다. 만약 제안을 받아들였다면 윈도우즈 바탕화면이 보다 화사해졌을텐데..

쓸데없는 여담 계속하자면, 키티가 일본 극우파의 첨병이라는 설이 파다하다. 심지어 확실한 팩트로 여기는 사람들도 많다. 근거랍시고 욱일승천기를 든 키티 그림을 내민다. 아니, 유럽에 가면 하켄크로이츠 철십자훈장을 단 키티도 있는데 뭐,, 근거 없는 낭설일뿐더러, 오히려 반대다. 산리오 창립자 쓰지 신타로(辻信太郎) 회장은 평화주의자다. 자사가 발간하는 잡지의 ‘딸기 임금님’ 칼럼을 통해 “지난 전쟁을 잊어서는 절대 안 된다. 전쟁 통에 많은 친구들이 죽었다. 지금의 평화를 꼭 지켜야 한다”고 호소하고, 이에 공감한 팬들이 아베 신조가 추진하는 안보법에 반대하는 집회를 벌이기도 했다. 산리오는 ‘키티는 무조건(!) 사랑과 우정 등 평화적 가치를 전달해야만 한다’는 결벽증 수준의 정책을 바꿀 생각이 아예 없다. 오히려 일본 우익 집단은 한복 입은 키티를 팔았다는 이유로 친한(親韓) 기업이라며 욕한다.

뭐 어쨌거나, 바로 그 키티가 털린 것이다. 사이트 이용자 개인정보가 언제 털렸는지는 알 수 없고, 2015년 11월 22일에 처음 온라인상에 노출된 걸로 파악된다. 그리고 1개월 넘도록 330만 명의 개인정보가 완전히 무방비로 까발려져 있었다. 굳이 해킹이라고 말할 것도 없는 단순 검색만으로 찾을 수 있는 상태로. 여기서 개인정보라 함은 사용자 이름과 아이디, 생년월일, 성별, 거주지역, 이메일 주소, 비밀번호 힌트 등의 내용이다. 비밀번호 유출 가능성도 제기되고 있지만 이에 대해서도 회사는 묵묵부답. 늘 그렇지 뭐.

사고 발생 후 산리오 본사는 아래와 같은 공식 입장을 발표했다.

– 완전히 새로운 보안정책을 적용했다.
– 내부조사 및 보안검토를 실시하고 있다.
– 데이터가 도난되었다는 건 어쨌든 확실한 듯하다.

뭐, 그런가 보다. 할 것 같던 말을, 했네, 대충.

헬로 키티
키티를 ‘장난감’으로 분류하는 게 적당한지는 잘 모르겠지만 아무튼, 장난감 회사 웹사이트가 털린 게 이번이 처음은 아니다. 키티 사고 1달 전에도 홍콩의 장난감 회사 ‘VTECH’의 회원 중 485만 부모와 636만 아이들, 총 1,121만 명의 개인정보가 유출되었던 적이 있다. 어린이 가입자 정보를 주로 노리는 어떤 세력의 존재도 의심되지만 정황 근거가 아직 부족해 뭐라 단정적으로 말할 수는 없겠고.

범행 동기가 뭘까? 범인은 왜 결제능력 없는 18세 미만 회원 정보를 홀라당 다 털어서 인질 삼아 회사를 협박하거나 정보 매매를 시도하는 등 일반적인 범죄 수법 절차에 따르지 않고 그냥 막 공개해버린 걸까? (어린이 대상 범죄와의 연결도 생각해 볼 수는 있겠으나, 아니, 그건 너무 끔찍하니까 아, 그러지 말자,,) 그렇다면 이는 늘 주장하는 바 ‘해커는 돈이 될 만한 정보를 노린다’는 이른바 정보보안 경제학에 위배되는 일 아닌가?

아니다. 유명세란 말도 있듯, 유명함 자체가 충분히 노릴 만한 재화적 가치로 인식되는 것이 해커 세계다. “나, 무려 키티를 털었던 사람이야!” 일단 좀, 멋있어,,

여긴 돈이 돌지 않는 곳이라서 평화롭다..는, 헛된 믿음.

키티 해킹 사건에 있어 가장 중요한 핵심 문제는 뭘까? 바로 무모한 웹사이트들의 존재. 돈 거래가 일어나지 않기 때문에 안전하다고 자신하고 허술하게 관리했기 때문이다. 사고가 벌어진 곳도 ‘산리오닷컴’이 아니라 ‘산리오타운닷컴’이다. 실제로 웹사이트를 구축한 도구와 기술을 비교해 보더라도 둘은 구축 및 관리 정책이 아예 다르다. 산리오닷컴은 J2EE에 기반해 중무장으로 분류할 만한 장치들을 집적해 구축한 반면, 산리오타운닷컴은 아파치 PHP 등 비교적 가벼운 도구들로 가볍게 만들었다. 아마도 팬 커뮤니티 사이트니까 대수롭잖게 여겼기 때문으로 짐작한다.

하지만 앞서 말했듯 유명하다는 건 그 자체로 노릴 만한 가치다. 세상에 키티만큼 유명한 고양이가 어디 또 있겠어? 그럼 노리는 자들은 많다. 엄청 많다. 실제 돈으로 바꿀 수 있는 가치가 없기 때문에 안심해도 괜찮아, 매우 흔한 믿음이다. 하지만 무모한 상태를 유지하는 까닭은 순전히 게으름 때문이다.

“게으름이 아니라,, 그냥 커뮤니티 사이트일 뿐이라서 오픈소스 소프트웨어로 가볍게 만든 건데,, 오픈소스 소프트웨어는 방어할 방법도 따로 특별한 게 없잖아!?” 아니, 있다. 찾아보면 오픈소스 데이터베이스 전용 데이터 암호화 솔루션도 있고 무거운 하드웨어 없이도 오픈소스 웹 어플리케이션을 방어해 주는 웹 보안 서비스도 있고, 다 있다. 그러니 무모함의 이유는 순전히 게으름 때문인 거라.