2014년 1월 또 한번의 초 대형 보안사고가 발생했다. 이번엔 신용카드사에서 보유하고 있는 신용카드 발급 고객의 개인신상정보와 신용등급, 결제계좌정보 등의 비교적 고급정보 그리고 심지어 일부 고객의 경우 카드번호와 발급일자까지 유출된 것으로 보인다.
내 경우도 다음과 같이 “나도 알지 못하는” 나에 대한 정보가 유출되었다고 나온다. 과연 계속 이 금융사를 “주거래” 은행과 카드사로 이용해야할지를 심각하게 고민하게 만든다.
본격적으로 카드3사의 개인정보 유출사고를 살펴보기 전에 과거의 개인정보유출 보안사고 이력(?)을 한번 보고 넘어가자. 인터넷에서 대충 검색해도 아래 그림처럼 엄청난 양의 개인정보 유출사고 사례를 접할 수 있다.
출처 : http://zalhae.blog.me/30183768858
하지만 이런 많은 개인정보유출사건 중에서도 이번 신용카드3사의 개인정보 유출사고가 심각하게 다루어져야 하는 이유는 단순 개인정보 뿐만 아니라 금융정보까지 함께 유출되었다는 점에 있다. 게다가 이번 개인정보 및 금융정보의 유출이 소위 말하는 해커의 “해킹”에 의한 것이 아니라는 것은 금융사 내부의 모든 구성원이 마음만 먹는다면 얼마든지 개인의 금융정보에 접근하여 “계좌 조작”까지도 가능하다는 매우 치명적인 “위협 시나리오”가 현실로 나타날 수 있다는 것을 의미한다는 점에서 과거처럼 조용히 넘어가서는 안된다는 것을 시사한다. 하지만 사고 이후 금융당국과 정부의 대처는 호들갑만 떨 뿐 소문난 잔치에 먹을 것 없다는 속담을 떠올리게 하고 있어 안타깝기만 하다.
신용카드3사 개인정보/금융정보 유출 시나리오
이번 신용카드3사의 개인/금융정보 유출사고는 모든 금융기관 아니 모든 기업/공공기관의 공통적인 보안 위협인 “개발/운용의 외주”가 불러온 사고라고 볼 수 있다. 신용카드사들은 금융당국의 요구로 “신용카드 불법사용 탐지”를 위해 KCB라는 회사에 외주를 주어 시스템을 개발하고 있다.
그 과정에서 필수적으로 테스트가 필요한데 이때는 실제 신용카드 거래정보를 이용해 테스트를 진행할 수 밖에 없다. 당연히 KCB의 개발담당자는 “당당하게” 테스트를 위해 실제 고객 정보를 요구했고 카드사 IT담당부서에서는 데이터의 접그을 허용해주었다.
이를 바탕으로 아래 그림에 이번 사고 시나리오를 재구성해 보았다.
하지만 여러 금융사의 전산실을 드나들어 본 경험을 바탕으로 할 때 의구심이 드는 것은 과연 KCB의 개발자가 어떻게 개인의 노트북을 소지하고 게다가 USB를 연결하여 개인정보를 유출했는가 하는 점이다. 솔직하게 이 점은 현재까지도 이해가 되지 않는다.
그 이유는 다음과 같다. 매우 기본적인 보안 수칙이다.
1. 대부분의 금융사는 이미 개인의 업무용 노트북을 어떠한 경우에도 금융전산네트워크에 접속하도록 허용하지 않는다.
2. 설사 접속하도록 하더라도 USB차단/블루투스 차단, 와이파이차단 등의 기능을 하는 보안SW를 노트북에 설치하여 USB사용을 차단한다.
1번과 2번의 규칙을 준수하지 않았다는 것은 사실 상상하기 힘들다. 이 보안규칙을 지키지 않았다면 이는 책임소재가 분명하기 때문에 대부분의 금융기관에서 비교적 철저하게 준수하고 있기 때문이다.
만약 위의 보안정책을 따르고 있었다면 어떠한 경로를 통해 데이터가 유출될 수 있을까? 이경우의 정보유출 경로는 바로 “서버”다.
요즘의 서버들은 대부분 USB포트를 갖고 있다. 윈도서버는 물론이고 리눅스, Unix 서버도 USB 포트를 갖고 있는 경우가 대부분이다. 서버 운영체제의 지식을 조금만 갖고 있다면 1. 서버에 USB 메모리를 꼽고 2. 마운트를 한 뒤 3. 서버의 DB에 있는 데이터를 파일로 저장한 뒤 4. USB로 복사하면 쉽게 유출이 가능하다. 그리고 이러한 방법은 엔지니어나 내부자에 의해 종종 사용되고 있다.
서버에서의 정보유출 차단을 위한 방안
앞에서 언급한 것 처럼 “개발”이나 “운용”을 위해 내부 IT 부서 직원이나 오퍼레이터 혹은 외부 업체의 직원에게 서버에 Telnet, FTP 등의 방법으로 로그온할 수 있는 권한을 부여하는 경우가 많다. 하지만 Unix/Linux/Windows 서버는 어떠한 계정으로라도 서버에 로그온만 할 수 있다면 해킹이라고 하기에도 유치한 쉬운 방법으로 수퍼유저(root, Administrator) 권한을 얻을 수 있다.
그렇기 때문에 RedCastle과 같은 SecureOS 솔루션을 설치하여 보안대책을 수립해야 한다.
1. IP , 계정, 시간, 서비스종류(telnet,ftp)조합에 의해 로그온을 통제.
2. 로그온통제에 추가하여 AuthCastle 등을 통한 2중인증(ID/Password + OTP/PKI/ARS) 적용
3. DBA 계정 및 root 계정 등 으로 로그온했다 하더라도 데이터베이스에 접근할 수 있는 명령어 및 실제 데이터가
저장된 데이터파일에 접근을 차단.
4. root 계정에서 db관리자 계정(oracle, db2)으로 패스워드 없이 Switch User 하지 못하도록 차단
5. setuid 및 간단한 코딩을 이용해 db관리자 권한 및 수퍼유저 권한 획득 차단
6. 백도어 등 설치를 통한 Bind Shell 등의 차단 (사용하지 않는 통신포트 Bind 차단)
7. 서버내에서의 Race Condition, FIFO Attack, 스니핑 등을 탐지하거나 차단할 수 있는 보호대책 적용
8. 운영체제의 설정파일, 응용프로그램의 설정파일 및 바이너리 파일에 대한 위변조 차단
9. 임시디렉토리에서의 실행(execute) 통제 및 크론탭 파일 등에 대한 무단 위변조 차단
10. 응용프로그램 네에 하드코딩된 ID, 비밀번호에 대한 유출 방지 대책
몇몇 보안대책만 나열해 보았지만 이러한 보안대책을 권고하고 구현해주는 보안컨설팅업체는 아직까지 보지를 못했다. 그만큼 서버내에서의 내부자 및 외부용역업체 개발자/엔지니어에 대한 행위 통제를 수행하는 경우는 아직까지 거의 없다. 그리고 이러한 보안대책을 “제대로~” 구현할 수 있는 솔루션도 RedCastle과 같은 SecureOS 외에는 없다고 봐도 무방하다.
일부 게이트웨이 방식의 제품이나 보안쉘 방식 혹은 PAM에서 가로채는 형태의 제품이 있기는 하나 사실 반쪽자리 솔루션일 뿐이다. 관리자 권한(root)을 얻는다면 간단하게 우회가 가능하기 때문이다.
10년 가까이 서버보안 업무를 하고 있지만 서버에 대한 제대로된 보안 정책을 수립하고 구현한 기업이나 공공기관은 손가락에 꼽을 만큼 찾아보기 어려운 것이 현실이다. 그나마 몇 안되는 고객사의 보안정책 수립과 구현에 기여했다는 것이 소중한 기억으로 느껴지는 것이 현실이다.
내가 서버보안업계에서 은퇴(?)하기 전에 과연 “제대로 된” 서버의 보안대책을 구현하는 것이 보편화될 지 궁금하다.