개인정보보호법에서 가장 이슈가 되고 있는 분야가 바로 암호화 부분이다. 많은 사업장에서 암호화 대상과 방법에 대해 고민을 하고 있다. 개인정보보호법 대응전략 세미나에서 조돈섭 이글로벌시스템 이사는 안전한 DB암호화에 대해 설명했다.
 
우선 암호화 범위와 적용기준에 대한 내용이다. 조돈섭 이사는 순차적 암호화 일정 계획을 세우라고 강조했다. 우선 법규에서 정한 DMZ 서버들은 1차 암호화 대상으로 선정한다. 제품의 기능은 향후 업무에도 충분히 적용할 수 있는 제품으로 선정해야 하고 정보통신망법 적용 사업장은 전체 시스템이 암호화 대상이 된다.
 
2차 대상으로 인트라넷 내의 기간계 DB서버들에 대한 암호화 계획을 수립하고 마지막으로 데이터 연동이 필요한 ERP 서버들에 대한 암호화 계획을 수립하면 된다. 더 나아가서는 APP. 로그파일도 암호화해야 한다.
 
조 이사는 안전한 암호화 요건을 말하면서 “암호화는 개인정보 취급자의 실수 또는 해커의 공격 등으로 인해 개인정보가 비인가자에게 유-노출되더라도 그 주요 내용을 확인할 수 없게 하는 보안기술을 의미한다”며 “그럼에도 불구하고 암호화의 3가지 보안요건인 권한통제, 알고리즘, 키기밀성중 권한통제와 키 기밀성을 충족시키기 못하는 경우가 많다”고 지적했다.
 
DB암호화의 운영필수 요건으로는 운영성, 고성능, 대용량을 들 수 있다. 운영성은 제품의 장애시에도 서비스 장애가 발행하지 않아야 하고 고성능은 빠른 암복호 엔진성능과 기존 배치 성능 보장이 돼야 한다. 대용량은 동시 처리 능력과 무중단 구축능력을 말한다.
 
조 이사는 또 DB암호화 제품의 형태별 장단점을 비교해 설명해 주었다. 그는 “데이터 유출과 직결되는 핵심 보안요구인 알고리즘의 비도, 키 접근통제, 키 기밀성 중 하나라도 미비한 경우에는 보안요건 불충족으로 판단해야 한다”고 강조했다.
 
◇DB암호화 제품형태중 보안요건을 충족시키는 3가지
DB암호화 제품의 형태는 Plug-In, API, Hybrid(API+Plug-In), Kernel방식의 Function, TDE, Appliance
방식, 자체 개발(API 형태), 파일암호화 등이 있다.
 
조 이사는 이들 제품중 3가지만 보안요건을 충족시킨다고 전했다. 이 3가지 제품형태는 바로 Plug-In, API, Hybrid(API+Plug-In) 뿐이다. 제품형태의 장단점을 살펴보면 이렇다.
 
우선 보안요건을 충족하는 3가지 형태를 살펴보자. Plug-In 형태는 DB서버에서 작동한다. 장점은 키 기밀성 충족, 애플리케이션 무수정, 가장 뛰어난 권한통제 등이다. 단점은 키 기밀성이 취약한 경우만 아니면 거의 없다.
 
API 형태는 WAS 서버에서 작동한다. 장점은 성능이 우수하고 서버간 암호화된 정보 전송이다. 단점은 약한 접근통제(통제요건 중 일부 불충분)와 APP. 전체 수정이 필요하다는 점이다.
 
Hybrid(API+Plug-In) 형태는 DB서버와 WAS 서버에서 작동한다. API와 Plug-In 형태의 장점을 모두 포함하고 있으며 성능과 보안성 극대화가 가능하다. 단점은 조합된 각 방식의 단점은 존재한다.
 
다음은 보안요건을 충족시키지 못하는 제품형태들이다. 커널방식의 Function은 DB서버에서 작동하며 장점은 모든 DB에 내장된 기능으로서 무료라는 점이다. 단점은 권한분리가 안되고 통제기능이 없다. DBA 및 일반 계정 통제가 불가하다는 것. 또 키 기밀성이 없다. HSM 적용이 필요하다. APP. 모두 수정해야 하고 감사기능도 없다는 것이 단점이다.
 
TDE 형태는 DB서버에서 작동한다. 장점은 APP. 수정이 거의 없고 초기 암호화 시간이 빠르다. 하지만 단점은 권한분리가 안되고 통제기능이 없다. 키 기밀성이 없으며 감사기능도 없다. 또 SGA에 평문 테이블 로딩에 의해 유출이 가능하고 데일블 전체 암호화 방식은 일방향 알고리즘 적용이 불가하다는 것이 단점이다.
 
Appliance 방식은 Appliance에서 작동한다. 장점은 DB서버에 암복호 부하가 없다. 단점은 접근통제 기준이 불충족하다. 또 대량 처리시 성능이 느리고 색인검색이 불가하다는 점이다. 주로 외산이며 필수 알고리즘 및 통제요건을 충족할 수 없다는 것이다.  
 
자체개발 API형태는 WAS 서버에서 작동한다. 장점은 성능이 우수하고 서버간 암호화된 정보 전송이다. 단점은 색인검색이 안되고 접근통제가 안된다. 키 기밀성이 없다. 또 APP. 전체를 수정해야 한다.
 
파일암호화는 DB서버 & Appliance에서 작동한다. 장점은 APP. 수정이 거의 없다는 점. 단점은 OS 메모리 캐시영역에 평문으로 로딩돼 유출이 가능하다. 또 접근통제가 안되고 일방향 알고리즘 적용이 안된다. 그리고 Raw Device DB 지원이 불가하다는 점이다.
 
조 이사는 “파일암호화 제품은 원래 OS 상에서 파일을 암호화할 목적으로 만들어진 제품으로서 이 용도로 사용할 경우에는 문제가 없다. 하지만 데이터베이스 파일을 암호화하는 경우에는 많은 보안상의 문제점이 있다. 즉 DB사용자들에게 있어서는 암호화를 안 한 것과 동일한 결과가 생긴다”며 “결국 제품은 개발 목적에 맞도록 적용해야 할 것”이라고 강조했다. 다시말해 일반 파일을 암호화할 경우에는 적합하지만 DB를 암호화할 경우에는 유출위험이 있기 때문에 부적합하다는 것이다.
 
DB암호화는 일반 파일 또는 통신 암호화와 많이 다르다. 따라서 간단히 적용만 하면 되는 방식은 보안성이 없고, 보안성을 유지하는 방식은 적용이 간단치만은 않다.
 
조 이사는 “근본 목적이 유출 위험성이 없도록 하는 것이기 때문에 다소 번거롭더라도 안전하면서도 완벽히 끝낼 수 있는 방식과 제품으로 확실히 암호화를 구축하겠다는 적극적 자세가 중요하다”며 “비록 관련 규정에서 상세한 규정이 빠져 있더라도 근본 취지와 목적에 부합할 수 있도록해야 유출사고를 막을 수 있다”고 강조했다.  
 
또 “대충 구축해서 현재의 규정만 피해가겠다는 생각은 장기적으로 회사 및 조직에 큰 피해를 입힐 수 있음을 직시해야 하며, DB암호화는 개인정보를 가진 모든 처리자가 함께 보호 노력을 해야 하는 것”이라며 “공들여 제대로 암호화하고 있는 다른 기업들의 노력에 찬물을 끼얹지 않도록 하는 책임감도 요구된다”고 덧붙였다.
[데일리시큐=길민권 기자]