다시 생각해 보는 DB암호화

DB암호화, 잘 모르거나 알고도 귀찮아 하거나...이중투자 피해야

그 동안 국내에서는 DB 암호화가 가진 양면적 특성(보안제품이면서도 DB 제품의 성격이 강한)을 잘 이해하지 못해 많은 실패를 경험한 바 있다.

최근에는 이러한 점에 대한 인식이 많이 개선되어 제품 검토시 여러 측면에서 세밀한 검토가 이루어지고 있으나, 역시 공공 분야에서는 전문성이 부족한 관계로 아직도 단순히 스펙충족 여부와 가격에 의해서만 선정하고 있어 걱정스런 상황이다.

왜냐하면 DB 운영환경과 사용형태는 사이트마다 매우 다양하며, DB 암호제품은 이러한 DB 서버의 환경에 스며들듯 매끄럽게 작동해야만 하기 때문에 DB 암호화 제품이 제공하는 DB관련 기능들의 완성도와 숙성도가 높지 않으면 적용 후 여러가지 문제를 야기하기 때문에 결국 운영을 포기하는 상황이 빚어지기 때문이다.

DB암호화, 무엇을 중요하게 고려해야 하는가

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

BMT로 검증이 가능할까?

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

그 이유는 실제 운영환경과 같은 서버의 크기, 업무 부하, 실제와 같은 복잡한 환경 등이 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)

내년 회사에 꼭 도입하고 싶은 보안 솔루션 또는 플랫폼은 무엇인가요?
	XDR
	EDR
	AI 보안
	제로트러스트
	공급망 보안 체계(SBOM)
	클라우드 보안 솔루션
	기타(댓글로)