[기고] Oracle TDE 보안문제 제기에 대한 오라클 입장

"개인정보 암호화에 관련해서 두 분의 글 덕에 많은 것을 배웠습니다.
저 역시 오라클 TDE의 종류에 대해 궁금해서 11g 11.2 매뉴얼을 뒤져보니 암호화 종류가
? 3DES168
? AES128
? AES192
? AES256
만 기재되어 있어서 의아했습니다.
별도로 구하는 거 였군요. ^^;

좋은 정보 감사합니다."

저는 Oracle사가 DBMS제품을 제공함에 있어서 사용자들의 요구와 편의성 및 운용성을 극대화 할 수 있도록 많은 노력을 하였으며 그 결과 많은 고객들로부터 사랑 받는 제품이 된 것으로 알고 있습니다. 이러한 측면에서 기본적으로 존경하고 있습니다.

제가 기고문에서 언급했던 내용들도 Oracle사의 다큐멘트를 충실하게 따라 실제로 구현해 보면서 보안상의 문제점들을 조명해 본 것입니다.

귀사의 기고문에서 4가지 점에 대해 답변을 주셨는데, 기본적인 시각차이가 큰 것 같습니다.
보안의 입장에서는, 보안을 위한 기능이 복수로 있을 수 있고, 그 각각의 방법마다 특이한 보안취약성을 갖는다면, 그건 문제점으로 인식하는 것이 타당합니다. 보안성이 약한 방법으로 구축.운영되게 될 가능성이 있기 때문이지요.
그래서 보안전문 제품들은 인증기관으로부터 제품 인증테스트 시에 현실적으로 거의 없을 것 같은 상황에 대해서 까지도 까다롭게 검증을 받습니다.

그런 측면에서 보면, 답변해 주신 내용으로는 충분한 설명이 되지 않는 것 같습니다.

첫 번째, 키관리 방식의 문제에 있어서 기고내용대로 OWM을 사용하면 화면상에는 비밀 번호가 노출 되지는 않지만 OWM을 사용하지 않아도 (제가 기고문에서 지적했던 방식) 작동하기 때문에 여전히 문제가 됩니다. 또한 OWM을 쓴다고 하여도 매번 수동으로 OWM에서 패스워드를 입력할 고객은 많지 않을 것으로 생각됩니다. OWM이 제공하는 ‘Auto Login’을 사용하길 원합니다. (제가 만나 본 고객들 거의 모두가 수동으로 입력하는 것은 어렵다고 합니다.) – ※ 출처 : Oracle® Database Advanced Security Administrators Guide, 11g Release 1 (11.1) Part Number B28530-03

Auto Login을 사용하게 되면 Oracle의 문서에, wallet의 obfuscated copy (키로 암호화 하는 것이 아닌 난독성 복사본, 키에 기반하지 않으며 다른 곳에서 읽혀질 수 있음을 의미 함.)를 생성한다고 되어 있으며, ‘Auto login Wallet은 파일시스템의 permission에 의해서 보호된다. Auto Login이 enable되면 OS 계정(즉, oracle이나 root 정도가 권한을 가지겠지요) 사용자가 OWM을 통하여 관리하게 된다.’ 라고 되어 있습니다.
Auto Login을 사용하는 경우에는 tar와 같은 OS명령으로 Oracle 디렉토리 전체 (또는 일부와 wallet 파일이)가 다른 서버로 가져가서 사용될 수 있다는 보안상의 치명적인 약점을 제거할 수는 없습니다.

두 번째, 암호화 데이터의 권한 통제에 대한 문제점에 관하여 답변 주신 내용은 DB암호화 제품의 접근 통제(엄밀히 말해서는 암.복호 키 사용 권한의 통제)의 필요성에 대한 이해가 조금 부족한 것 같습니다.
DB암호화는 기업/기관의 자산인 정보의 보호에 있어 최종 단계의 보안이고, 가장 강력한 보안 방법이라는 것은 다들 인정 하실 것입니다.
네트웍을 통해 시도되는 다양한 침투 유형과 이를 막기 위한 방법은 계속 진화 할 것입니다. DB암호화는 이러한 네트웍을 통한 위험 통제가 불가능하여 해커 등 위협 세력에 의해 시스템이 완전히 장악된 상황에서도 핵심 정보 자산을 지켜내야만 합니다.
이때에 필요한 것이 키 기밀성과 키 사용 권한에 대한 강력한 통제 기능 입니다.
마치 정말 귀중한 물건을 은행 대여금고에 넣었을 때 은행 입구만 보안검색에 통과하여도 모두가 다 대여금고에 접근할 수는 없고, 2차로 본인 확인과 금고 열쇠를 맞추어야만 열 수 있도록 허락하는 개념과도 같은 것이겠지요.

세 번째, 테이블스페이스 암호화 방식의 안전성과 관련한 부분 입니다.
앞서 말씀 드린 바와 같이 보안은 외부의 해커만이아닌 내부의 관리자도 통제할 수 있어야 하기 때문에 현실적인 위협이냐의 여부를 불문하고, 보안 제품은 그러한 취약성의 존재 자체가 불허 됩니다.
귀사의 기고문에서 말씀하신 것 처럼 TDE Tablespace Encryption으로 암호화된 데이터들은 unix에서 ipcs 명령어로 간단히 SGA의 공유메모리상의 위치와 크기를 확인할 수 있으며, OS명령어 들을 몇 개만 이용하면 내용을 떠서 평문으로 볼 수가 있습니다.
내용을 전혀 모르는 데이터 테이블이라 하더라도 일단 dump를 뜨면 내용을 확인하는 것은 불과 수 시간 이내에 가능 하겠지요. DBMS가 통제할 수 없는 OS계정 사용자에게 무방비로 노출되어 있는 것이 큰 문제라는 것입니다.

그리고, 국내든 외국이든 에서 OPE 알고리즘을 사용하는 DB암호화 제품은 없는 것으로 압니다. ^^

네 번째, 암호화 알고리즘의 안전성에 대한 문제 입니다.
Oracle TDE가 충분한 강도의 민간용 블록 알고리즘을 지원 하고 있습니다. 따라서 공공기관이 아닌 민간 기업에서 사용하는 데는 문제가 없습니다만, 비밀번호 암호화용 알고리즘인 SHA-256/384/512가 지원되지 않고 있어서 이 부분은 적용하려는 고객들이 별도로 SHA-256/394/512 알고리즘을 구해서 적용해야만 현행 법규를 충족할 수 있습니다.

방법상으로는 문제가 없지만, TDE방식을 선택하려는 고객들의 이유가 어플리케이션 변경을 전혀 하지 않는다는 점 때문이라면, SHA 알고리즘을 사용하기 위해서는 반드시 어플리케이션 소스가 변경될 수 밖에 없는 상황이라서 이의 적용을 생략 할 우려가 있는 것 또한 사실입니다. 다만 이러한 점이 우려가 되기 때문에 적용 시에 정확히 가이드가 되면 될 것 같습니다.


이슈 사항에 대해 자세히 답변 주신 점 감사 드리며, TDE가 HSM, Data Vault, Audit Vault등과 같이 구축되어 보안이슈가 최대한 제거 되어 보다 안전한 암호화와 함께 관계 규정을 준수할 수 있는 좋은 솔루션이 되길 기대 합니다.

감사 합니다.