3. DB 암호화 구축

가. 원본 데이터 삭제

DB의 암호화가 수행되면 원본 데이터는 삭제되어야 한다. 원본 데이터는 서비스가 진행 중인 DB 내에 존재했거나 백업(Backup)에 의해 테이프 등과 같은 2차 스토리지 (Storage)에 저장 된다. 따라서 암호화 후에 진행되어야 할 원본 데이터 삭제는 DB 서비 스가 진행 중인 디스크와 백업된 스토리지 모두에게 해당된다. DB 서버 내 디스크의 원본 데이터는 테이블의 컬럼 값뿐만 아니라 이에 대한 인덱스 정보까지도 포함한다.
원본 데이터의 삭제 시기는 암호화 적용방식에 따라 달라지게 되는데 기존 서비스를 유지 하는 방식과 암호화하는 시점에 서비스를 정지하는 방식으로 구분된다.
암호화 대상 테이블의 레코드 삽입·삭제·변경의 트랜잭션이 발생하는 중에 암호화를 진 행하는 경우와 암호화를 진행하기 위해 트랜잭션을 일시 중지시키는 경우가 있다. 전자의 경우 초기 암호화에 따른 시간이 다소 느리게 진행되지만 DB 서비스를 지속 시킬 수 있는 장점이 있는 반면, 후자의 경우 DB 서비스가 일시 정지 될 수 있으나 초기 암호화를 빠르 게 진행할 수 있다.

나. 제약사항 유지

기존 평문의 데이터가 암호화되면 원본 데이터와 연관관계를 가진 인덱스(Index), PK(Primary Key), UK(Unique Key), FK(Foreign Key), Trigger 및 Default Value 등 다양한 속성들이 유지되어야 한다. 이러한 속성들이 암호화 후에 유지되지 않는다면 DB 서비스가 불가능해지고 최악의 경우 이를 극복하기 위해 DB 재설계에 이르게 된다.

다. DB 암호화 키 관리

DB 암호화의 가장 중요한 요소중의 하나가 암호키 관리이다. 아무리 암호화가 잘 수행되 었다 하더라도 키 관리가 허술하면 정보유출 사고 시 대규모 사태가 벌어질 수 있다. 암호 키는 생성 이후부터 관리가 매우 중요하며, 정기적인 암호키 변경은 물론 안전한 장소에 암호키를 보관하여야 한다. 암호화된 데이터가 유출되더라도 암호키가 없으면 유출된 데 이터를 이용하기가 쉽지 않기 때문이다.
DB 암호화 솔루션의 경우 키 관리를 솔루션이 탑재된 머신(machine)에 관리하는 경우도 있고, 별도의 키 관리 장비(HSM, Hardware Security Module)에 관리하는 경우도 있 다. 후자의 HSM에 관리하는 경우 안전한 암호화 키 관리를 어느 정도 보장하지만, 전자 의 경우 암호화 솔루션 자체의 보안성 향상이 필요하다. 즉, 암호화된 키를 임의로 조회하 거나 삭제·변경하지 않도록 하는 보안정책이 별도로 요구된다.
다음은 암호키 관리에 대한 가이드라인을 제시한다.

■암호키가 생성되면 암호키에 대한 백업을 수행한다. 암호키가 변경이 되면 변경된 암호 키에 대한 백업도 포함이되며, 복구에 대한 확인과 절차도 점검하여야 한다.
■암호키에 대한 논리적 접근제어가 수행되는지를 점검한다. 물리적으로 안전하지 못한 장소에 저장된 암호키는 쉽게 유출이 가능하기 때문에 별도의 보안정책이 필요하다.
■암호키가 물리적으로 안전한 장소에 저장되어 있고 권한이 부여된 사용자에 의해서만 접근이 가능한가를 점검한다.
■암호키가 해제될 수 있는 가능성을 점검하고 기존 암호키의 폐기, 새로운 암호키의 생성 절차를 확인하여야 한다. 이 과정은 매우 중요하며 모든 이력을 관리하여야 한다.

라. 보안적용 시험 (DB 암호화 주요 기능)

DB 암호화를 구축 운영하다 보면 여러가지 환경에 대한 부분을 고려하게 된다. 다음은 이 를 고려한 DB 암호화의 주요 기능들에 대한 부분이며, 실제 적용에 충분히 고려해 볼 만한 사항들이다.

■초기 암호화 구축이나 추가 암호화 작업 시에도 DB 무정지
■최소의 암호화 대상 Table Locking시간
■테이블, 인덱스 모두 암호화 및 인덱스 검색 지원
■암호화로 인한 기존 애플리케이션의 수정 불필요
■컬럼별 사용자 접근정책을 통한 다양한 암호화 정책 지원
■암호화 알고리즘
？3DES, ARIA, SEED, AES, TDES, SHA-1, RSA(PKCS #1), RSAES-OAEP, RSASSA-PSS, RC4, HMACSHA-1
■암호화 가능 컬럼 타입
？CHAR,VARCHAR, VARCHAR2, DATE, INT, NUMBER, FLOAT, LONG, LOB (image, design-chart)
■Index column 지원
■PK/UK/FK column 지원
■Trigger 및 default values 지원
■Null Value 지원
■Partitioned table (Range, Hash, List partitioned) 지원
■암호화 후 기존 Table의 Dependency, Constraint 불변
■암호화 시 Table 및 Index의 다른 Table Space 이동 지원
■Column데이터의 부분 암호화 지원(앞뒤 N자리)
■Windows / Linux / UNIX 등 OS환경에 독립적
■OS 및 DBMS의 업그레이드에 독립적
■Clustered DB (Oracle RAC, IBM HA) 지원
■FIPS Level 2에 의거 암호키 기밀성 보장 및 DB서버 외부관리
■암호키 이중화 관리에 의한 Fail-Safe
■암복호화 서버(NE, LE)의 Load Balance 지원
■암호화 통신으로 인한 안전한 운영관리
■백업/복구, 운영자 관리, 리포트 분석 등 다양한 관리체계
■비정상 동작에 대한 Notification (SNMP, Syslog, Email) 통보

마. 환경보완(암복호화 서버의 로드밸런싱)

DB 암호화의 대상은 하나의 DB이거나 다중 DB 일 수 있고, 혹은 하나의 물리적인 서버에 여러 개의 DB 인스턴스가 운영될 수 있다. 또한, 이러한 환경의 DB들은 동시에 서비스를 제공되어야 하므로 암호화 서버의 역할이 매우 중요하게 된다.

경우에 따라서 암호화 엔진인 DB 내에서 운영되고, 반대로 외부의 별도 서버에서 암복호 화가 진행되거나 내부와 외부의 여러 암복호화 엔진이 협력하여 로드밸런싱을 수행하는 경우가 있다. 더나아가 이러한 로드밸런싱은 암호화 엔진의 다중화로 인해 하나의 암호화 엔진이 예기치 못하게 종료한 경우 다른 엔진이 이를 보완하는 역할을 할 수 있게 된다. 조 직의 규모나 DB의 운영 규모에 따라 다양하게 DB 암호화를 구성할 필요가 있다.