Oracle 암호화에 관련된 궁금한점이 있어서 질문드립니다 0 6 7,683

by 하형욱 [DB 기타] 오라클 암호화 [2017.05.16 15:37:53]


고객정보가 포함될수 있는 특정 칼럼에 대해 암호화를 해달라는 요구사항을 받았습니다.

오라클 버젼은 11g 구요 찾아보니 다음 4가지 방법이 나오는데 여러가지 의문점이 있어서 글을 용기내서 올려봅니다

1. CRYPTO 를 이용한 PACKAGE 생성 및 사용

2. TDE  - 칼럼 단위 암호화

3. TDE -  테이블 스페이스 단위 암호화

4. DB 전문 보안 솔루션 적용

 

1번 패키지 생성 방법은 SQL및 데이터를 전부 수정해야해서 현실적으로 불가능하구요 ( SQL 수정만 200 개정도해야하고 운영시스템에 반영하려면 고객사 결재를  '각각' 받아야합니다..)

2번,3번 TDE를 사용하는 방법은 WALLET을 생성하고 OPEN 하면 암호화된 칼럼이나 암호화된 테이블스페이스의 테이블을 조회할수 되어있다고 합니다.

4번 방법은 현재는 예산을 집행을 고려하지 않고 있어 일단제외하였습니다.

첫번째궁금한점 *  TDE 사용시  SYS권한을 가진 사용자가 instance scope에서 alter system set encryption wallet open 를 해주면, 해당 instance에 접속하는 모든 사용자가 session scope에서 별도의 권한획득을 위한 sql등을 사용하지 않고도 , 바로 모든 데이터를 조회할수 있는건가요?

두번째궁금한점 *  SYS권한이 아닌 일반 사용자도 비밀번호를 알면 WALLET을 OPEN(상태로 변경) 할수 있나요?

세번째궁금한점 *  TDE 사용시 웹서비스 어플리케이션에서 기존의 SQL을 그대로 사용할수 있도록 WALLET이 OPEN되어있는 상태라면, 이 사용자로 접속하는 Orange나 TOAD같은 프로그램 사람도 당연히 조회가 될텐데 ( DBMS입장에서는 웹 서비스어플리케이션에서 접속하는지, TOAD에서 접속하는지 구분 불가능하므로) 이런 상황에서 암호화의 의미가 있다고 할수 있는 것인지요?

네번째궁금한점 *  세번째 질문과 중복됩니다만  기존의 SQL 수정을 최소화하여 수정하면서 웹서비스 어플리케이션은 그대로 동작하고, Orange나 TOAD로 접속했을때는 칼럼이 암호화되거나, 조회자체가 안되게 하려면 어떻게 해야하나요? ( 기존 웹서비스 어플리케이션이 사용하던 계정에만 복호화할수 있는 권한을 부여하고<-이게 가능한지도 조차도 모르겠습니다..., '암호화된 칼럼'은 조회할수 없는 별도의 사용자를 추가하여 TOAD나 Orange 접속시에 사용 하라고 하면 되는것인지요? .. )

by 신이만든짝퉁 [2017.05.16 16:08:52]

세번째궁금한점 에 제가 알고 있는 바를 말씀드립니다.

TDE는 데이터 파일이 암호화 되어 저장되므로, 데이터 파일이 해킹등에 의해 탈취 당했을 경우 복호화 할 수 없으므로 도난에 안전하다는 것입니다.

그러므로 지갑이 열려 있는 상태이고, 오라클 계정과 비밀번호를 아는 경우 사용자는 Transparent하게(투명하게) 데이터를 조회해 볼 수 있습니다. 여기서 오라클은 접속한 사용자가 해커인지, 정상적인 웹 서비스인지, 토드로 접속한 DBA인지 인증을 통과했다면 상관하지 않습니다. 하지만, 해커가 OS의 취약점을 파고들어 데이터 파일을 탈취해 간 경우라면 이를 복구하여 데이터를 조회 할 수 없다는 말입니다. TDE를 적용 한 상태라면 해커의 컴퓨터에 탈취한 데이터 파일을 복호화 키 없이는 복구(recovery)하여 사용할 수 없기 때문입니다.

그러므로 일반적으로 기업에서 요구하는 사용자 DB접근제어는 TDE만으로는 어렵다고 봐야합니다.


by 하형욱 [2017.05.16 16:12:57]

그럼 결국은 TDE가 파일 자체가 OS 레벨에서 탈취되었을때의 방지를 말하는거로군요..

생각해보니 어차피 어플리케이션에서 사용하는 id /pwd가 탈취된거라면 막을수 있는 방법이 없네요..

같은 id를 사용하고 있는 사용자라고 해도 막을수 있는 방법이 없구요..

제가 하려고하는 것은 접근 제어로 이해해야겠네요. 답변 감사드립니다.


by 하형욱 [2017.05.16 16:38:02]

결국 그럼 WALLET이 DB Instance 레벨에서 상태가 공유되는거라면,  웹 어플리케이션에서 접근할때는 당연히 WALLET이 OPEN된 상태로 유지되어야하고, 기존 DB user의 id/pwd를 알고 있는 사람이 봤을때는, TOAD나 ORANGE등에서 접속했을때는 아무 차이가 없어보이게 되겠네요..( WALLET이 OPEN 되어있을테니까요 )


by 미생 [2017.05.16 17:05:56]

TDE는 원하시는 내용이 아닐겁니다.  고객들이 원하는건 패스워드, 주민번호, 계좌번호 암호화일테니까요

고객 요청 사항 중에 어떤 상황에서 복호화가 필요한지 그리고 어떤 상황 에서는 암호화 된 상태여야 하는 지 확인이 필요합니다.

DB 에선 무조건 해당 컬럼이 암호화 되있어야 하는지, 복호화 함수가 적용되어있는 뷰를 만들어도 되는지.

아마 데이터베이스의 해당 컬럼을 암호화 함수를 사용하여 update 를 한 후 어플리케이션에서 해당값에 복호화 함수를 적용하여 필요한 상황에서만 복호화된 값을 확인할 수 있게 제어하셔야 할 것 같습니다. 물론 백업은 반드시 하시고 작업하시길 바랍니다.


by 하형욱 [2017.05.16 17:09:50]

네.. 고객개인정보에 대한 암호화를 원하고 있어요.. 단순 SQL 조회했을때는 암호화된 데이터가 보이면서, 웹서비스어플리케이션이 접근할때는 복호화된 데이터를 사용해야할것같아요... TDE 로 해결하려고 했더니 해결할수 있는 작업이 아닌것 같습니다..

그런데 갑자기 또 궁금한것은 복호화 함수가 적용되어있는 뷰를 만들면 어차피 그 뷰에 접근 권한을 가진 (, 즉 웹서비스어플리케이션이 사용하는 DB user) 사용자로 접근하여 그 뷰를 봤을때 똑같이 복호화된 데이터가 그대로 보이는것 아닌가요?.. 

요구사항에 대한 정리가 필요한 시점같습니다.. 혼란스럽네요


by 임상준 [2017.05.16 18:56:38]

접근 자격을 가진 대상에게는 당연히 복호화 되어서 보여야 하고, 그 유저가 아니라면 암호화 되어서 보이는게 맞겠죠... 예를들어 웹 어플리케이션 유저로 조회하면 보이는게 정상인거고요. 그래서 암호화 데이터 조회 자격을 가진 db 계정으로 아무나 쉽게 접근하지 못하게 하는 방법도 함께 고려 하셔야 할거구요. 접근제어 솔루션을 쓰거나 다른 방법을 고려 하시거나...

전문 암호화 솔루션도 아마 쿼리 수정이나 튜닝이 상당히 많이 들어갈 것 같습니다. TDE 도 유료 옵션이고요. 예산만으로 따지면 국산 암호화 솔루션이  TDE 보다 더 쌀 수도 있을 것 같아요..

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입