DB 암호화의 현재 기술을 총망라하여 정리한 김광열 상무(컨설팅 본부장)의 기사 내용입니다.

---------------------------------------------------------------------------------

개인정보보호법에 대응하기 위하여 많은 공공기관 및 민간회사에서 다양한 기술적 조치가 취해지고 있고, 그 중에 핵심적인 역할을 하고 있는 분야인 DB암호화 적용을 위해 현재 많은 프로젝트가 진행 중에 있다.

DB 암호화 적용에 앞서 살펴봐야 할 DB 보안

개인정보의 중요성이 부각되면서 내부 사용자 및 외부 해커의 주된 목표도 개인정보의 불법적인 탈취에 있는 경우가 많다. 이런 상황에서 개인정보를 체계적으로 저장하고 있는 DB에 대한 보안은 절대적으로 중요하며, DB보안을 위해서는 DB접근통제 및 DB암호화 시스템을 구축해야 한다.

1) DB접근제어 솔루션

국내 제품의 경우 대부분 게이트웨이(Gateway), 스니핑(Sniffing), 에이전트(Agent) 방식을 지원하고 있으며, 각 방식을 조합한 하이브리드 방식도 지원하고 있다.

2) DB암호화 솔루션

컬럼 암호화의 경우에는 DB 서버에 설치하는 플러그인(Plug-In) 방식, AP 서버에 설치하는 API 방식으로 크게 구분되며, 이외에 Secure Proxy 방식, 대체키(PIN, Ticket, Coupon) 방식 등으로 세분화된다.

DB 암호화 구축 시 고려사항

1) 성능 점검

DB암호화와 관련하여 가장 많이 고려하는 구성 방식이 플러그인(Plug-In) 방식이다. 플러그인 방식은 지원하는 솔루션들이 거의 모두 필요한 인증을 획득했고, 기존 프로그램에 대한 수정이 API 방식에 비해 훨씬 적어 구축이 용이한 방식이다. 다만 DB서버에 암·복호화 모듈이 설치되므로 DB서버에 미치는 영향이 크고, 성능저하가 발생한다.

현재 암호화 대상 컬럼을 사용하는 SQL 패턴을 분석해보면, 대부분의 사이트에서 SELECT 문장이 90% 이상 점유하고, 나머지를 INSERT 문장이 차지한다. UPDATE, DELETE는 상대적으로 매우 적다.

이런 이유로, 플러그인 제품을 고려할 때, SELECT 성능이 가장 좋은 제품을 도입해야 한다. 플러그인 방식은 암·복호화 라이브러리를 수행하기 전에 각종의 키 관리 로직이나, 권한 체크하는 로직 등이 필요하다. 여기서 해당 로직을 어떻게 구성했느냐에 따라 성능차이가 많이 나는데, 경우에 따라서는 2~3배 이상의 차이를 보이기도 한다. 성능이 매우 중요한 요소가 되는 환경에서 플러그인 방식을 고려하는 경우에는 반드시 조회 성능을 점검하는 BMT 등을 수행하여, 최적을 솔루션을 선택하는 것이 바람직하다.

2) 개인정보 사용 이력 로깅

행정안전부에서 고시한 ‘개인정보의 안정성 확보조치 기준(이하 확보조치 기준)’의 8조 1항에 아래와 같은 조항이 있다.

① 개인정보처리자는 개인정보취급자가 개인정보처리시스템에 접속한 기록을 최소 6개월 이상 보관 관리하여야 한다.

이를 상세히 해설한 해설서에 따르면, ‘개인정보취급자가 개인정보처리시스템에 접속하여 개인정보를 처리한 경우, 수행한 업무 내역에 대하여 식별자, 접속일시, 접속자를 알 수 있는 정보, 수행업무 등의 접속기록을 최소 6개월 이상 저장하고 정기적으로 확인·감독해야 한다’라고 되어 있고, 로그를 남겨야 하는 항목으로는 다음과 같이 예시하고 있다.

암호화 대상이 되는 고유식별 정보는 개인정보 중에서도 특별히 관리되어야 하는 핵심 정보에 해당하므로, 고유식별 정보를 이용한 내역(개인정보 처리 내역)에 대해 접속기록을 저장해야 한다.

DBMS와 같은 개인정보처리 시스템에 접속하는 방식은 2가지가 존재한다. 즉, 직접 DBMS에 접근하는 방식이 있고, 애플리케이션 서버의 서비스를 이용해 접근하는 방식이 있다.

직접 접속하여 수행하는 내역은 일반적으로 DB접근제어 시스템을 통하여 수행한 SQL 및 수행자의 IP, ID, 수행시각 등의 정보를 저장한다. 그렇지만 애플리케이션 서버의 서비스를 이용하여 접근한 경우에 대해 기록을 남기지 않는 경우가 많은데, 이는 기술적인 한계에 기인한다.

DB접근제어 시스템에서 스니핑(Sniffing) 방식으로 SQL 수행 정보를 수집하거나, 플러그인(Plug-In) 방식으로 암호화를 한 경우에, 애플리케이션에서 오는 정보는 모두 애플리케이션 서버의 IP 기준으로 로그가 남게 되어 실질적으로 해당 행위를 한 사람에 대한 식별이 불가능하다.

그렇지만 API 방식으로 암호화를 수행하는 경우에는, 애플리케이션 서버에 암·복호화 모듈이 설치되어 연동되므로, 실제 접속한 사람의 ID 혹은 IP 정보를 개개인 단위로 식별할 수 있다. 그러므로 암호화된 고유식별 정보에 접근한 접속기록을 저장할 때, 개개인을 식별할 수 있는 IP/ID 정보를 같이 저장하는 것이 바람직하다.

결론적으로 API 방식으로 고유식별 정보, 바이오정보, 비밀번호 등을 암호화하여 처리하는 경우, 개인정보보호법에서 요구하는 접속기록 저장의 의무를 완벽하게 수행하기 위하여 개개인을 식별할 수 있는 정보와 수행 내역을 같이 저장해야 한다.

3) DB접근제어와 DB암호화 연동

DB접근제어는 게이트웨이, 스니핑, 에이전트 등 다양한 방식으로 구성할 수 있다. 이때 게이트웨이, 에이전트 방식을 사용하는 경우에 DB접근제어 시스템을 경유하여 DB서버에 로그인 하는 경우, DBMS 서버에서 획득하는 IP 주소는 모두 DB접근제어 시스템 IP로 치환되게 된다.

2명의 서로 다른 내부 사용자가 192.168.1.101, 192.168.1.102 IP를 부여받은 노트북에서 DB접근제어 시스템을 거쳐 DB서버에 로그인 하는 경우, DB 서버에서는 모두 DB접근제어 시스템의 IP인 192.168.1.33 IP로 보인다. 그러므로 DB 서버단에 설치된 DB암호화 시스템에서는 IP를 식별할 수 없으므로 IP별 암·복호화 통제가 불가능하게 된다. DB접근제어와 DB암호화를 도입한 많은 기관과 회사에서 이런 경우에 DB암호화에서는 DB접근제어를 경유한 모든 사용자에게 암·복호화 권한을 허용하도록 설정한다.

그러나 이렇게 설정하는 경우, DB암호화 시스템 설치가 거의 무의미하게 된다. Data File 단위로 유출되는 경우에는 암호화되어 있어서 보호되지만, DBMS에 로그인 한 후에 SQL을 통하여 데이터를 유출하는 경우에는 아무런 보호장치가 되지 못하기 때문이다.

이와 달리 DB접근제어와 DB암호화가 서로 연동하도록 구성된 제품을 사용하는 경우에는 DB접근제어 시스템을 경유하더라도 DB암호화 시스템에서 실제 사용자 IP 단위로 통제가 가능하다.

불가피하게 DB접근제어와 DB암호화가 서로 연동하지 않는 제품을 설치한 경우에는, DB암호화 시스템에서 사용자를 식별할 수 있도록 개인별로 DB계정을 만들어 DB계정 단위로 통제한다든가 하는 등의 별도의 방법을 추가하여 DB암호화 시스템이 DB접근제어 시스템에 의해 무력화되는 것을 방지해야 한다.

4) 블록단위 암호화 제품 설치 시 고려사항

DB암호화 솔루션은 크게 컬럼 단위로 데이터를 암호화하여 저장하는 방식과 DBMS 블록, 혹은 파일 블록 단위로 암호화하여 저장하는 방식으로 구분할 수 있으며 아래와 같은 특징이 있다.

블록단위 암호화 제품은 설치가 용이하고, 성능 저하가 적으며 관리가 편리하다는 장점이 있어서 금융권, 병원 등에서 많이 고려하고 있는 방식이다. 하지만 DB Kernel 방식이나 파일단위 암호화 제품 모두, DBMS에 로그인 한 후에 해당 암호화된 블록의 내용을 조회하면, 평문을 볼 수 있어서 DB사용자별로 암·복호화 통제가 불가능한 한계가 있다.

이를 보완하기 DB 접근제어 시스템, 특히 강력한 마스킹 기능을 가진 솔루션과 같이 결합하여 구축하는 것이 일반적이다. 즉, 파일단위 유출에 대해서는 블록단위 암호화 기능에 의해서 보호가 되고, DBMS 내부에서 정보 유출은 마스킹 기능을 이용하여 대응하는 구성이다. 이외에도 몇 가지 추가적인 고려사항이 있다.

① 파일 단위 암호화 제품의 경우, File Volume Manager를 모두 지원하지 못하는 것으로 알려져 있다. 해당 제품 도입 시 이를 우회할 수 있는 방법을 같이 고려하여야 한다. 또한 서버보안 제품이 도입된 경우 호환성 여부도 점검해야 한다.

② DBMS Kernel 방식의 암호화 제품 사용 시, 아카이브 로그 정보도 같이 암호화 되어 저장되기도 하는데, 이럴 경우 3rd Party CDC(Change Data Capture) 툴을 사용할 수 없는 문제가 발생할 수 있다. 이런 경우에 DB암호화 구축비용이 많이 상승하게 되므로, 해당 제품을 도입하고자 하는 경우 계획 수립 시 반영해야 한다.

③ 블록단위 암호화 제품의 경우, 제품 구성상 비밀번호 단방향 암호화 기능을 제공할 수 없다. 물론 해당 회사의 다른 옵션에서 비밀번호를 암호화할 수 있는 별도의 API를 제공하는 경우도 있다. 보호조치 기준에 따르면, 비밀번호는 단방향 암호화하여 저장하도록 되어 있으므로 이에 대한 보완대책이 필요하다.

DB암호화는 여러 가지 방식이 있고, 또한 성능에 미치는 영향이 매우 크다. 각 기관 및 회사의 시스템 상황과 법적 규제에 따라 암호화 요구에 대응해야 하는데, 각 솔루션별 장단점 및 제약사항 등이 있으므로 이를 고려하여 DB암호화 시스템을 구축해야 한다.

[글 _ 김 광 열 신시웨이 상무(jeffkim@sinsiway.com)/한국DB진흥원 DB보안인증(DQC-S) 심사원]

[원본기사 http://www.boannews.com/media/view.asp?idx=32485&kind=1 ]