[기고] DB암호화 제품(TDE)의 보안 문제점 분석-4

검증 2: 접근통제가 안 되는 취약성 검증

DB암호화 제품에 요구되는 기본 통제기능(국정원 요건)으로는, DBA 또는 다른 일반 사용자들이 암호화된 데이터를 볼 수 없도록 접근(권한)통제할 수 있어야 한다. 비록 DBMS에서 DBA는 모든 사용자의 테이블을 조회할 수 있으며 일반 사용자들 간에 조회 권한을 GRANT(허가)해 준 상태이더라도 암호화된 정보에 대해서는 DB보안관리자가 정의해 놓은 별도의 보안 정책에 의해 DBA 조차도 조회할 수 없도록 통제가 가능해야 한다.

그렇지 않으면 암호화가 되어 있더라도, DBA권한을 가지고 있는 사용자가 아무런 제약 없이 악의적 행위로 데이터를 유출해 갈 수 있기 때문이다.

데이터 유출사고는 대부분은 내부자에 의한 행위로 인하여 발생되므로 전지전능한 DBA의 악의적 또는 불법 행위에 의한 접근통제는 당연히 필수 요구사항이다.

기준 : 보안관리자에 의해 통제정책을 설정하는 기능이 없는 TDE는 암호화된 테이블의 정보가 다른 일반 사용자 또는 DBA에 의해 조회되지 않아야 한다.

검증 방법 : TDE로 암호화된 테이블에 일반사용자 또는 DBA로 접근하여 조회하였을 때 복호화 되어 평문으로 보이는지를 확인.

[MSSQL 2008의 TDE]

TDE로 암호화된 테이블의 소유자(‘sa’, DBA)가 조회 했을 때의 결과와 다른 사용자(‘WEB_ADMIN’)가 접속하여 조회 했을 때의 결과를 비교한다.

소유자(‘sa’)가 조회 했을때는 평문으로 조회 되지만 다른 일반 사용자(‘WEB_ADMIN’)가 조회 했을 때는 평문으로 조회가 되면 안 된다(DB가 운영되고 있는 동안에는 암호화를 안 한 것과 같은 결과이기 때문).

① 먼저 소유자 계정(‘sa’)으로 조회 한 결과 화면이다.

주민번호를 포함한 모든 데이터가 평문으로 복호화되어 조회 된다.

이제 일반사용자인 ‘WEB_ADMIN’에게 조회 권한을 준다.

② ‘WEB_ADMIN’ 사용자로 로그인 한다.

③ 일반 사용자인 ‘WEB_ADMIN’ 으로 테이블을 조회 한다.

소유자가 아님에도 주민번호를 포함한 모든 정보가 평문으로 조회 된다.

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

[Oracle 11g의 TDE]

TDE로 암호화된 테이블의 소유자(‘DEMO’, 일반 사용자)가 조회 했을 때의 결과와 다른 사용자(‘SYS’, DBA)가 접속하여 조회 했을 때의 결과를 비교한다.

소유자(‘DEMO’)가 조회 했을 때는 평문으로 조회 되지만 다른 일반 사용자(‘SYS’)가 조회 했을 때는 평문으로 조회가 되면 안 된다(DB가 운영되고 있는 동안에는 암호화를 안 한 것과 같은 결과이기 때문).

① 소유자 계정(‘DEMO’)으로 조회해 보고, 시스템 관리자 계정(‘SYS’)으로도 조회해 본다.

아래가 소유자인 ‘DEMO’ 계정으로 조회한 화면이고, 위의 것이 DBA인 시스템관리자(‘SYS’) 계정으로 조회 한 화면이다.

두 경우 모두 평문으로 조회가 되고 있음을 확인할 수 있다.

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

[글_조돈섭 이글로벌시스템 이사(alex@cubeone.co.kr)]

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