카드사 고객정보 유출 사건을 보면서 기업 내부에서 이제는 필요로 하는 내부 보안 시스템은 어떤 것이 있을까? (1부)

최근 카드사 고객정보 유출로 인해 수많은 사람들이 피해를 보고 있다는 생각이 듭니다. 저 역시도 예전보다 더 많은 스팸문자들이 들어오는 것을 보고 내 정보도 유출되었구나 하는 생각을 했습니다(참고로 저는 이번에 문제가 되었던 농협카드, 롯데카드, 국민카드 사용자가 아닙니다만 유출된 듯 싶더라고요). 왜 이런 상황이 벌어졌는지, 그리고 이런 상황을 어떻게 해결할 것인지 깊이 생각해봐야 할 필요가 있습니다. 일단 이런 상황이 연출된 원인은 유출한 사람의 도덕적, 불법적 행위, 즉 사람의 행위가 문제가 되고 그 행위를 하지 못하도록 도덕적, 윤리적, 보안적 인식을 갖도록 지속적인 교육을 하는 것이 우선시 되겠지만 그 교육, 계도와 병행으로 현재의 상황에서 어떻게 대처하는 것이 좋은지를 살펴보는 것도 중요하다고 보여집니다.

어떤 경로로 정보 유출이 진행되었나?

먼저 고객정보가 어떤 경로를 통해서 유출되었는지를 확인할 필요가 있습니다. 원인을 파악해야 그에 대한 대비책도 마련할 수 있을 테니까 말이죠. 일단 언론에 공개된 내용을 비춰봤을 때 언급한 3개 카드사의 FDS(부정사용방지시스템) 업그레이드 사업을 진행하고 있던 KCB(코리아 크레딧 뷰로)의 프로젝트 메니저(PM)가 고객정보를 빼돌려 대출광고업자에게 판매한 것이 이번 사건의 흐름입니다. 여기서 중요한 것은 해당 PM이 어떻게 고객정보를 빼서 다른 사람에게 넘겼나에 대한 흐름과 그것에 대한 대비책을 마련하는 것이겠죠.

금융권이든 기업이든 내부 시스템이나 외부 시스템을 업그레이드하거나 새로 만들 때 보통 외주업체에 아웃소싱을 줘서 많이들 개발합니다. 일단 내부에 전문 개발인력이나 프로젝트 관리 인력이 없는 경우가 많고 있다고 해도 프로젝트 관리 인력만 있고 개발자들은 아웃소싱해서 개발하는 경우가 많습니다. 내부의 기밀자료를 건드리는 시스템을 만들 때도 보통은 이렇게 합니다. 이런 상황이기에 국내 IT 환경의 기반이 SI라고 하는 이유가 되지요. 왜 이렇게 되었나를 얘기하려면 이야기가 길어지고 한국 IT 문화를 성토하는 자리가 될 수 있기 때문에 나중에 다시 한번 얘기할 기회를 갖도록 하고요. 여기서 핵심은 외부 개발자나 PM이 기업의, 혹은 금융권의 내부 민감 정보에 쉽게 접근할 수 있는 환경이라는 것입니다. 그렇다면 1차 핵심은 이런 민감 정보에 접근할 수 있는 권리나 자격, 방식을 강화함으로 외부 유출로의 원인 차단을 하는 것이라 하겠습니다.

데이터베이스 암호화 및 DRM을 통한 정보유출 방지

보통 민감 정보는 데이터베이스(DB)에 데이터로 저장되어 있던지 아니면 파일로 저장되어 있습니다. 여기서 2가지 방식으로 이들 데이터를 보호할 수 있는데 DB에 저장된 기밀자료의 경우 최근 개인정보보호를 위해 많이 도입하고 있는 DB 암호화를 이용할 수 있습니다. DB 암호화는 DB에 저장되는 데이터를 암호화 하는 솔루션으로 DB의 각 테이블에 있는 원하는 필드에 들어가는 값을 암호화하여 외부에서 권한 없는 사용자가 접근할 때에는 제대로 된 값이 보이지 않게 만드는 방법입니다. 여기에는 2가지 방식이 있는데 플러그인 방식과 API 방식이 있습니다.

플러그인 방식은 DB의 콘솔을 허가 받은 사용자가 로그인하면 안에 있는 내용을 다 보여줍니다. 즉, 개발할 때 정당한 로그인 절차를 앞서 거치게 하면 그 이후부터는 기존에 사용하던 SQL 문장을 그대로 사용할 수 있기 때문에 개발 편의성이 높아집니다. 하지만 단점은 그 허가 받은 사용자 정보가 유출되면 무방비 상태가 된다는 점이지요. API 방식은 DB를 이용해서 프로그래밍을 할 때 암호화된 DB에 접근할 때 특정한 API를 사용하도록 해서 쓰게 만드는 방법입니다. 이 방식은 DB 콘솔에서는 사용이 불가능하고 프로그램에서 사용해야 하며 기존에 사용하던 SQL 문장을 그대로 사용할 수 없기 때문에 개발 편의성이나 생산성은 좀 떨어집니다. 하지만 플러그인 방식보다는 속도가 빠르고 상황에 따라서는 DB 콘솔을 이용할 수 없기 때문에 더 보안성이 높다고 할 수 있습니다. 최근 DB 암호화 제품의 핵심은 플러그인 방식을 얼마나 잘 지원하는가 인데 이유는 개발 편의성과 생산성 때문입니다.

하지만 이번 사태와 같이 PM이 직접 개입했다면 플러그인 방식은 위험합니다. API 방식이 완벽하지는 않지만 그나마 덜 위험하다고 할 수 있지요. 왜냐하면 PM이 직접 해당 DB를 접근해서 값을 뽑아오는 프로그램을 만들어서 돌려야 하기 때문입니다. 그런데 일단 이번 사태에서 보면 이런 DB 암호화가 제대로 적용이 되어있는지 조차가 불투명합니다(확인이 되지 않습니다). 보통은 개인정보보호를 위한 데이터만 DB 암호화를 적용하는데 이 기회에 기업의 내부 민감 정보에도 다 적용해야 하는 게 아닐까 싶습니다(물론 기업들이나 금융권들은 내부 기간망 시스템에는 DB 암호화 도입을 아직은 꺼리고 있습니다. 안정성 문제와 더불어 속도 이슈도 있기 때문입니다. 하지만 이제는 속도보다는 보안이 우선시되어야 하는 상황이 되었습니다).

기밀자료가 DB 형태가 아닌 파일 형태로 저장되어 있다면 파일 자체를 암호화해야 합니다. 여기서도 전에 소개했던 DRM 시스템이 여기에 도입되어야 할 듯 싶습니다. 허가 받은 사용자만이 해당 파일을 열 수 있고 복사하거나 밖에서 사용할 수 없게 만들어야 할 필요가 있기 때문입니다. 물론 마냥 DRM을 도입한다고 다 되는 것은 아닙니다. 권한 관리를 철저하게 해야 문제의 소지가 줄어듭니다. 지금의 DRM을 도입한 기업들을 보면 그냥 암호화만 하고 권한 관리를 제대로 못하는 경우가 많습니다. 물론 파일 자체를 암호화 함으로 파일의 보호 효과는 있을지 모르지만 권한 관리까지 합쳐서 2, 3중의 방어체계를 갖춰야 합니다. DRM에 대해서는 이전 포스팅에서 소개했으니 이 정도로 넘어갈까 합니다.

이 외에도 다양한 방법으로 민감 정보의 외부 유출을 막을 수 있을 듯 싶습니다. 쓰다보니 내용이 좀 많아진 듯 싶어서 나머지 내용은 다음 포스트 때 이어서 할까 합니다.

To be continue...

이 글은 LG CNS 블로그에 기고했던 글의 원본입니다. 기고한 글은 [여기]에서 보실 수 있습니다.