다시 생각해 보는 DB 암호화

무엇을 중요하게 고려해야 하는 가

필자가 여러 번 칼럼이나 세미나를 통해 주장한 것처럼, DB 암호화에서 가장 중요한 것은 보안 측면에서는 암호화 한 데이터가 유출되어 노출이 될 수 있는 취약성을 없애기 위해 보안 필수요건 즉, 안전한 알고리즘, 키 사용 권한 통제 및 키 기밀성 유지를 들 수 있으며, DB 운영 필수요건으로는 고성능, 대용량 처리능력 그리고 내장애성(운영성) 이라고 볼 수 있다.

BMT로 검증이 가능할까?

대체적으로 보안요소들에 대한 검증은 BMT 환경에서도 검증이 가능할 수 있지만, DB 관련 기능·성능 요소들은 BMT 환경에서 검증이 불가능하다.

그 이유는 실제 운영환경과 같은 서버의 크기, 업무 부하, 실제와 같은 복잡한 환경 등이 BMT 환경에서는 구현이 안 되기 때문이다. 따라서 대부분의 제품들이 가볍게 통과 할 테지만 문제는 실 환경, 실 서버에 적용했을 때에야 발생하게 되지만, 이미 제품은 선정된 후일 테니까 후회해도 이미 늦었다.

모름지기 좋은 재료에 요리사의 노력이 더해졌을 때 비로소 최고의 음식이 탄생하는 법이다.

그럼 어떻게 검증할 수 있을까? 도입 담당자들이 노력해야 한다. 사실과 진실성을 확인하기 힘든 자료나 SI 사 또는 공급업체의 말에만 의존해서는 곤란하다. 그들은 이해 관계자이기 때문에 공정하고 객관적인 사실을 전하지 않기 때문이다. 어떤 제품이건 간에 객관적인 위치에 있는 사람들의 입소문이 가장 정확할 것이다. 입소문으로 알게 된 제품이 있다면 그 제품을 실제 사용하는 사람들의 이야기를 듣고 확인함으로써 검증을 할 수 있다.

즉, DB 암호화에 대해 공부하여야 하고 제품마다 복수의 레퍼런스 방문 조사를 통해 실제 암호화한 구축 내용을 세밀히 알아보고 또한 운영되고 있는 상태를 확인해 보는 노력이 필요하다. 암호화 한 칼럼의 종류, PK 사용 여부, 암호화 한 테이블 수 및 크기, 성능변화율, CPU 사용율, 구축시의 특이사항 및 만족도 등을 반드시 자세히 알아봐야 의미있는 조사결과를 얻을 수 있다. 즉, BMT와는 별도로 레퍼런스 확인이 중요하다는 결론이다.

보안성과 간편한 적용의 동시 충족이 가능할까?

DB 암호화에 사용될 수 있는 솔루션들은 Plug-In, API, DB Kernel 방식, 파일 암호화 및 Appliance 방식 등이 있으며, 각각의 방식 별 특징 및 장단점은 다음의 표와 같다

Application의 수정이 전혀 없는 방식인 파일 암호화와 TDE(DB 커널 방식)방식은 유출 방지를 위한 필수 보안 3요소 가운데 암·복호키 사용권한 통제 기능 및 키 기밀성의 유지에 문제가 있는 구조를 가지고 있다.

아무것도 수정하지도 않고 적용이 간편한 방법 중, 유출에 안심할 만큼 충분한 보안성을 제공하는 방식은 없다. 즉, 완전한 보안을 달성하려면 어느 정도의 노력과 시간은 들여야 한다.

주)

암·복호키에 대한 통제를 실시하기 위해 필요한 접속자정보(DB 계정, IP/MAC 주소 등)와 API 호출시 입력해야만 통제가 되는 경우 또는 작동 위치로 인해 접속 App. 명에 대한 통제가 안 될 수도 있다.
TDE 방식이 모두 이러한 문제가 있는 것은 아니나, Tablespace 단위의 암호화 방식에서는 메모리내의 DB 사용 영역(SGA)내에 Clear Text로 존재하게 된다.
통상의 TDE들은 AES128/192/256과 TDES192를 지원하지만, 본인 인증을 위한 패스워드 또는 바이오정보 등을 암호화하기 위한 SHA-256/384/512를 지원하지 않고 있다.
TDE는 DBMS에서 제공되는 기능들로, 적용·관리등과 관련한 모든 작업을 보안 관리자가 수행할 수 없고 DB관리자에 의해 이뤄진다.
현재 국내에 소개된 일부 Appliance는 DBA에 대한 통제가 불가능하다.
암·복호 처리는 Clock에 민감한 특성을 가지고 있어, 데이터의 처리를 네트워크를 통해 외부 시스템(Appliance)에서 처리해 오는 구조는 SSL 암호화 통신을 하기 때문에 배치와 같은 대량의 데이터 처리 시 느릴 수밖에 없다.
파일은 OS Level의 Object로써, OS사용자와 DB Level의 사용자는 같지 않다. 따라서 DB 파일의 소유자는 DBMS 자체가 되므로 DBMS의 운영을 위해서는 항상 허용할 수밖에 없어 DB계정에 대한 통제가 이루어질 수 없다. IP/MAC, App명 등에 대한 통제도 이루어지지 않는 경우가 대부분이다.

아직도 일선 실무자들과 이야기를 나누다 보면 DB암호화에 대해 뭐가 뭔지를 잘 모르고 있어서 일을 그르칠 가능성이 농후한 경우와, 암호화의 중요성과 예상 가능한 보안 위협에 대해서도 비교적 잘 알고 있지만 제대로 구축을 하려니 귀찮고 힘들 것 같아 애써 모른척하며 대충 하려는 사람들이 종종 있다.

현재로서는 매우 우려가 된다. 분명히 하나마나 한 구축 프로젝트가 될 것이 뻔하며 요행히 유출사고가 안 발생하지 않더라도 2~3년 후에는 ‘고도화’라는 명목으로 재도입을 하게 되므로 결국 이중 투자가 발생하게 되기 때문이다.

이런 현상은 DB암호화에 대한 바른 이해가 일반화 되면 거의 사라지게 되겠지만 일반화에는 2~3년 이상의 긴 시간이 소요되는데, 법에 따라서 DB암호화 구축 또한 이 시기에 집중적으로 이루어질 것이기 때문에 주의가 요망된다.

<글 : 조 돈 섭 │ 이글로벌시스템 이사(alex@cubeone.co.kr)>

[월간 시큐리티월드 통권 제181호(sw@infothe.com)]

SK텔레콤 해킹 사태로 최근 잇슈가 되고 있는 ‘BPF도어’ 관련, 어떤 솔루션을 사용중인가요?
	안랩 V3 Net for Linux
	소만사 Server-i
	파이오링크 점검 도구
	잉카인터넷 전용 백신
	트렌드 마이크로 백신
	기타 국산(솔루션명은 댓글로)
	기타 외산(솔루션명은 댓글로)
	사용하지 않는다