개정 개인정보보호법으로 DB암호화와 접근제어 시장의 성장 기대가 높다. 2011년 개인정보보호법 시행 당시 이 시장이 폭발적인 성장을 거뒀던 것처럼 올해도 많은 사업이 생기면서 성장을 이끌 것으로 전망된다. 올해 DB암호화, 접근제어 시장을 전망해본다.<편집자>
DB·녹취파일 보호 위한 암호화 사업 진행
강력한 규제준수 요건과 사회적인 분위기로 기업/기관들은 개인정보 보호를 위한 대책 마련에 나섰으며, 데이터가 유출된다 해도 불법적으로 사용할 수 없도록 하는 ‘암호화’에 관심을 모으고 있다.
특히 금융권에서 DB암호화에 가장 높은 관심을 보이고 있다. 금융기관의 대규모 개인정보 유출 사고로 개인정보보호법이 지속적으로 강화되고 있으며, 핀테크가 활성화되면서 개인정보의 활용이 많아질 것으로 예상되기 때문에 금융기관은 보안에 더 많은 투자를 진행한다.
DB 암호화는 보험, 증권 등 제2금융권에서 활발하게 도입돼 왔으나, 제1금융권은 CRM, ERP 등 내부 업무시스템과 정보계 일부에만 적용했을 뿐이다. 2016년에는 보관하고 있는 모든 주민번호를 암호화해야 하므로 대규모 수요가 발생하고 있다. 또한 금융권에서는 로그 데이터, 콜센터 녹취파일 등에 대한 보호 사업도 진행되고 있다.
다양한 암호화 기술 중 적합한 것 찾아야
암호화는 표준 암호화 알고리즘을 이용하기 때문에 암호화 솔루션을 제공하는 벤더간의 기술적인 차이는 없다고 봐도 무방하다. 공개된 표준 암호화 알고리즘을 이용하더라도, 업무의 성격, 데이터의 특징, 시스템 환경, 암호화 목적 등 여러 상황에 맞게 상용화 하는 방법의 차이는 분명히 존재한다.
데이터를 암호화하고 복호화하는 과정에서 장애가 발생하지 않아야 하며, 업무 시스템 성능 영향이나 시스템 변경도 최소화 할 수 있어야 한다. 반드시 보호해야 할 데이터만 한정적으로 진행하며, 다양한 암호화 기술과 암호화 방법 중 해당 데이터에 적합한 방식을 찾아 암호화해야 한다.
DB 암호화 솔루션은 컬럼 암호화 방식과 블록 암호화 방식으로 나뉘며, 컬럼 암호화는 플러그인, API, 하이브리드 방식으로 구성된다. 플러그인은 애플리케이션 수정을 최소화 할 수 있으며, API 방식은 애플리케이션 수정이 필요하지만 대규모·대용량 DB 암호화가 가능하다. 하이브리드 방식은 플러그인과 API를 결합한 방식이다.
블록 암호화는 애플리케이션 수정 없이 암호화 할 수 있으며, TDE(Transparent Data Encryption) 방식과 파일 암호화 방식이 있다. TDE는 DB를 시작할 때에만 키 사용권한 통제가 이뤄지며 일반 DB 계정은 통제하지 못하는 문제가 있으며, 파일 암호화는 애플리케이션을 통하지 않고 DB서버로 바로 접근하는 DBA 등 사용자는 암호화되지 않은 데이터에 직접 접근한다는 한계가 있다.
이외에 원본데이터는 별도로 보관한 상태로 다른 문자로 치환해 보여주는 토큰화(Tokenization)와 화면상에 나타나는 데이터를 다른 문자나 기호로 보여주는 마스킹(Masking), 로그관리, 테스트 데이터 변환 등 여러 기술이 추가로 제안된다.
암호화, 키관리가 핵심
DB암호화는 DBMS에서 기본적으로 제공하고 있다. 오라클 ‘트랜스패런트 데이터 인크립션(TDE: Transparent Data Encryption)’ 솔루션은 데이터베이스의 커널(Kernel)에서 암호화와 복호화를 수행해 보안 효과를 극대화하고 성능저하를 최소화한다.
마스킹 기술과 접근제어, 키관리 기능도 데이터 보호 포트폴리오에 포함돼 있으며, 계정·접근권한 관리와 인증, 감사 기술 등과 함께 포괄적인 데이터 보호 전략을 수립할 수 있도록 제안한다. 특히 이는 데이터베이스 커널에서 수행돼 암호화 솔루션의 도입에 따른 성능 저하 및 기존 DB 기능에 대한 사용 제약을 최소화 한다.
그러나 앞서 설명했듯이 TDE는 키관리와 접근통제가 이뤄지지 않는 구간이 있기 때문에 이 구간에 대한 기술이 추가로 필요하다. 오라클은 데이터 보호 포트폴리오를 통해 보안홀을 제거할 수 있다고 강조하지만, 전문적인 보안 솔루션으로 암호화 데이터를 안전하게 운영하는 방법이 보편적으로 사용된다.
암호화 데이터는 키가 있어야 복호화되기 때문에 키관리가 매우 중요하다. 공격자는 암호화 데이터만 빼가지 않으며 반드시 복호화 키를 함께 가져가기 때문에 키를 유출당하지 않도록 관리해야 한다. 초기에 구축한 DB 암호화는 암호화 키를 암호화 서버에 함께 저장했다. 이는 비싼 금고를 사서 돈을 넣은 후 열쇠를 금고 옆에 두고 있는 것이나 마찬가지로, 도둑에게 금고와 열쇠를 함께 가져가도록 방치하는 셈이다.
일부 암호화 솔루션은 DB 서버 내에서 암호화와 키관리가 함께 이뤄지도록 해 보안 취약성을 더욱 높였다. 이 방식은 권한 있는 사용자가 DB 서버에 접근해서 암호화된 데이터와 키를 제한 없이 유출할 수 있다.
안전한 DB 암호화를 위해서는 DB서버와 암호화 서버, 키관리 서버를 분리해 운영해야 하며, 키관리 서버는 전용 하드웨어 어플라이언스에 높은 수준의 암호화 기술로 관리돼야 한다. DB 서버 메모리에 키를 보관하는 경우도 종종 있는데, 공격자가 DB 서버를 장악하면 메모리에 저장된 키에 자유롭게 접근할 수 있기 때문에 결코 안전한 방법이 아니다.
더불어 DB 관리자와 암호화 키 관리자 계정을 분리해 운영해 관리자 계정을 탈취당해도 키관리 계정을 보호해 키관리 서버에 접근하지 못하도록 해야 하며, CC인증, FIPS 인증 등 공인 인증을 획득한 안전한 제품을 사용하는 것이 좋다.
