이를 위해 많은 기업 및 기관들이 암호화 구축을 하고 있는데, 일부에서는 암호화를 하는 근본적인 목적과 의미가 축소 또는 무시되는 경향이 꽤 많다. 이렇게 되면 암호화가 주는 데이터 유출 위험제거 효과를 기대하기 어렵고 결국 유출될 수밖에 없는 구조적인 문제점을 안게 된다. DB에 저장된 개인정보를 암호화하는 근본적인 목적은 행정안전부 고시해설서에도 나와 있듯이 통상적인 운영/관리상의 허점 또는 해킹에 의해 유출됐을 때 평문으로 볼 수 없도록 해 2차 피해가 발생하지 않도록 하는데 목적이 있다.

행정안전부, ‘개인정보의안전성확보조치기준고시및해설서(20110930 제정)’
제7조 (개인정보의 암호화) 의 취지 해설(33쪽) 및 ‘개인정보 보호법령 및 지침.고시 해설서(2011.12.15- 208쪽) 의 정의

※ “암호화”는 개인정보취급자의 실수 또는 해커의 공격 등으로 인해 개인정보가 비인가자에게 유·노출되더라도 그 주요 내용을 확인할 수 없게 하는 보안기술임.

이를 위해서는 현실적으로 흔히 있을 수 있는 실수(관리상의 허점 포함) 및 현재까지 알려진 해커의 공격 유형에 대한 방어가 가능한 제품을 적용해야 한다.
그동안의 개인정보 유출 사례들을 살펴보면, 암호화를 했음에도 불구하고 고도의 기법과 기술을 요하는 해킹(암호키 유추, 알고리즘 해킹, 암호모듈의 통제정책 위변조 등)을 통한 경우는 SK컴즈 외에는 없었던 것 같고, 나머지 사례들은 대부분 암호화가 안되어 있었거나 돼있었던 경우라 하더라도 필수 보안 기능/구조의 미비로 인해 빚어진 사고들로 볼 수 있다. 즉, 표준 OS 명령어와 DB명령어를 이용하는 통상적이고 흔히 있을 수밖에 없는 파일/시스템 백업 및 DB백업 등의 관리작업을 통해 아주 간단히 유출될 수 있도록 구축되는 경우에는 암호화 효과를 전혀 기대할 수 없게 된다.

그림 1은 각종 DB 암호화 제품의 형태별로 유출과 밀접한 필수 보안 기능의 제공 여부를 정리한 표이다. 일부 사실과 다를 수도 있지만 파일 암호화 형태의 제품인 경우는 일반 파일을 암호화했을 경우는 이러한 문제점이 발생하지 않지만, DB 파일을 암호화하게 되면 DB 사용자에 대한 통제를 전혀 할 수 없게 된다. 또, DB 파일은 24시간 365일, 항상 오픈돼 운영된다는 점에서 평문상태의 파일이 전부 또는 일부가 항상 메모리에 로드되기 때문에 더욱 취약해 진다.

그림 2는 유출 위험의 형태 및 발생 빈도를 도식화했다.

유출 위험은 해킹보다는 보안 요건이 미비한 형태의 제품으로 암호화했을 때 필연적인 위험 즉, 관리/운영상 발생할 수밖에 없는 위험이 비교할 수 없을 만큼 크기 때문에 이 위험요인은 반드시 제거해야만 한다.

지금까지 알려진, 그리고 예측이 가능한 해킹에 의한 위험 요소에 대해서는 ‘국정원의 DB 암호화 제품의 보안 요건’ 문서와 이를 토대로 국가용 암호제품 검증제도가 테스트를 통해 검증하므로 ‘검증 필’ 제품이라면 구조상 문제가 없다고 봐도 될 터이나, 외산 등의 미검증 제품들인 경우는 이 부분에 있어서 전혀 확인이 불가능하므로 고객의 입장에서 보면 제품 선택에 대한 책임이 부담스러울 수 있다.

최근 한 교육기관의 유출사고에서도 볼 수 있듯이 암호화 대상 데이터가 저장된 곳은 어느 서버이든지 DMZ건 내부망이건 암호화 대상으로 삼는 것이 바람직하며, 이 정보들을 암호화하는 제품은 지금까지 살펴본 취약성이 없는 제품 형태로 선정해야 유출 사고 발생시 보호 노력을 최대로 인정받을 수 있고 그래야만 책임을 최소화 할 수 있기 때문이다.

법규는 최소한의 규정에 지나지 않는다는 점과 입법의 근본 취지를 상기하고, 기업/기관의 안정적인 사업을 영위하는데 개인정보 유출사고가 발목을 잡지 않도록 개인정보보호 담당 조직은 철저한 보안기능 요건을 충족할 수 있도록 해야 한다.

설령 주무 부처의 보호조치 가이드라인이 키 기밀성 요건과 키 사용권한의 통제 요건을 상세히 다루지 않고 있다 할지라도, 이것들은 DB 암호화의 보안효과를 담보하는 필수기능인 동시에 해킹에 의하지 않고도 유출과 직결되게 되는 중요기능들이므로 이 기능이 미비한 것을 알면서도 적용해서는 안된다. 암호화 구축은 쉽게 할 수 있겠지만 유출은 피할 수 없기 때문이다. 예를 들어, 어느 기업에서 DB 암호화를 구축하고 약 1년쯤 지난 후에 유출사고가 발생하게 되면, 발생 당시의 보안담당자와 CEO, 또는 기관장이 형사처벌을 피할 수 없게 된다. 이러한 일을 사전에 방지하려면 귀찮더라도 구축 당시에 제대로 하는 것이 필요하다.