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

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

오라클은 최근 타사에서 ‘Oracle TDE 신뢰성’에 관해 제기한 다음의 네 가지 측면의 기술적 사실관계에 대해 보다 정확한 정보를 전달하고자 한다. 이를 위해 타사가 언급한 부분을 발췌하고 이에 대한 기술적 사실관계를 기술했다.

       1. 키 관리 방식의 안전성에 대한 주장

       2. 암호화 데이터의 권한 통제에 대한 주장

       3. 테이블스페이스 암호화 방식의 안전성에 관한 주장

       4. 암호화 알고리즘의 안전성에 관한 주장

1. 키 관리 방식의 안전성에 대한 타사의 주장 및 사실관계

TDE를 사용하는 대부분의 DBA들은 DB가 Restart 했을 때 wallet 파일이 open되지 않아서 서비스가 불가능한 상태에 빠지지 않도록 wallet 파일 open이 자동으로 실행되도록 script를 만들어 놓기 때문에 DBMS를 full backup 받던가 또는 TDE 관련한 파일들을 OS 명령을 이용하여 백업해서 가지고 간 경우 이 script에 의해 wallet 파일이 자동 open되는 문제점이 있을 수 있다. Wallet open을 위한 라인에 패스워드(‘oracle’)가 노출되어 있다. Manual로 Interactive하게 wallet을 open 할 때도, 화면에 패스워드가 노출된다.

오라클은 wallet을 open하기 위하여 script를 사용하는 것은 보안상 위배되는 것이므로 사용을 권고하지 않는다. 즉, 위의 제기 내용은 일부 사용자의 잘못된 이용 방식이 마치 오라클 제품의 결함처럼 제시하고 있다. 오라클이 권고하는 방식은 보안적으로 안전한 Oracle Wallet Manager를 이용하는 것이다. Oracle Wallet Manager는 Wallet을 생성하거나 Open하기 위하여 패스워드를 입력하는 경우 항상 자동으로 Masking 처리하여 화면에 패스워드가 노출되지 않도록 보호한다.

▲Oracle Wallet Manager를 통한 키 관리 → 비밀번호 입력 시 항상 Masking 처리됨

2. 암호화 데이터의 권한 통제에 대한 타사의 주장 및 사실관계

Oracle 11g의 TDE 역시 암·복호키의 사용에 대한 별도의 권한통제 기능이 없어 GRANT된 사용자 또는 DBA는 복호화된 정보를 볼 수 있었다. 결국, DB가 가동되는 동안의 보안성은 암호화 이전과 같다.

오라클은 암호화된 데이터를 접근하는 사용자 환경에 따라 암호화된 데이터에 대한 접근 여부를 선택할 수 있는 기능을 제공한다. 암호화된 값의 Display시 Null Masking 기능을 제공하며, 입력 및 수정 권한을 부여/회수할 수 있다. 또한  Database Vault와 연계함으로써 보다 강력하고 포괄적인 수준의 접근 권한 통제를 구현한다. 따라서 별도의 권한통제 기능이 없다는 주장은 사실과 다르다.

▲ Null Masking 기능을 통하여 암호화 값의 조회 권한 통제

▲ Database Vault를 통한 DBA 권한 통제

3. 테이블스페이스 암호화 방식의 안전성에 관한 타사의 주장 및 사실관계

투명한 암호화를 지향하는 TDE류의 제품 특성상 Disk에 저장된 테이블을 서비스하기 위해서는 모두 테이블 혹은 테이블스페이스 전체를 복호화하여 메모리에 로딩하게 되는데, 메모리를 덤프하면 복호화된 평문 테이블을 유출할 수 있는 위험이 있다.

이 주장 또한 암호화와 접근 통제의 역할을 정확하게 반영하고 있는 내용이다. 타사의 주장대로라면 내부자이건 해커이건 메모리 정보(SGA의 키 값 및 크기)를 알아내기 위하여 DBMS시스템에 접속한 상태이므로 이미 접근통제 시스템이 무력화되었음을 의미한다. 또한 Object 정보와 데이터의 내용을 추정할 수 있는 정보를 이미 알고 있어야 한다. 이러한 상태라면 굳이 Memory를 dump하여 개인정보를 유출할 이유가 없다. 따라서 앞서 제기한 시나리오는 현실성이 부족하다.

Oracle TDE의 테이블스페이스 암호화 방식이 이러한 메커니즘을 가지는 이유는 범위 검색 SQL 수행 시 index를 사용하여 성능을 극대화 하고 응용프로그램의 수정이 없도록 하기 위함이다.

이를 구현하기 위해 OPE(Order Preserving Encryption) 알고리즘을 사용하여 데이터 값의 대소 관계를 유지하면서 인덱스를 관리하는 기법이 있는데 이는 데이터 파일 유출 시 암호화된 내용의 역추적이 가능하다고 알려져 있다. 따라서 Oracle TDE는 OPE 알고리즘을 채택하지 않고 Oracle Kernel과 연동하여 IO시 복호화하여 성능을 극대화 하는 방법을 사용하는 것이다.

4. 암호화 알고리즘의 안전성에 관한 타사의 주장 및 사실관계

AES(128/192/256), TDES(192) 만 지원, SHA-256/384/512는 지원하지 않으며, 테이블스페이스 단위로 암호화하므로 패스워드도 복호화 가능한 AES/TDES로 암호화 됨.

Oracle Database 사용고객은 Oracle DBMS가 제공하는 기능을 이용하여 다양한 단방향(SHA-256/384/512) 암호화 알고리즘으로 어플리케이션의 모든 정보(계정, 패스워드 등)를 보호할 수 있다.

오라클은 사용자 패스워드와 같이 단방향 암호화가 필요한 데이터는 이를 사용하도록 반드시 권고하고 있으며 이미 많은 고객이 패스워드의 단방향 암호화를 구현하여 사용하고 있다. 그러나 이러한 사실이 잘못 해석되어 오라클의 안전한 암호화 체계가 패스워드 암호화 등에 취약한 것처럼 사실을 왜곡하고 있다.

결론적으로 Oracle TDE는 가장 안전한 수준으로 암호화 키와 암호화 데이터를 보호하고 있으며 오라클은 암호화된 기밀데이터를 선제적으로 보호하기 위한 강력한 접근통제 기술을 포괄적으로 제공하고 있다. 데이터베이스의 암호화 구현을 준비하는 독자들에게 가장 안전하면서도 성능을 보장할 수 있는 최적의 암호화 방법을 선택하는데 이 글이 도움이 되기를 바란다

--[댓글]--

조돈섭    2011-11-21 11:49:44

저는 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등과 같이 구축되어 보안이슈가 최대한 제거 되어 보다 안전한 암호화와 함께 관계 규정을 준수할 수 있는 좋은 솔루션이 되길 기대 합니다. 감사 합니다.