데이터베이스 암호화에서 주기적으로 키를 변경할 때 고려사항

일정한 양의 암호문이 쌓이면 COA에 취약할 수 있으므로 주기적으로 키를 변경하면 좋다고 앞서 이야기했습니다. 하지만 현실적인 데이터베이스 환경에서 이는 큰 도전입니다. 컬럼 하나에 서로 다른 암호화 키로 암호화된 행이 있다면 데이터베이스 검색 속도에 직접적인 영향을 미칠 수 있기 때문입니다. 테이블을 일정한 기간이나 데이터양 단위로 나누도록 설계했다면 적용하기가 어렵지 않지만, 모든 데이터를 통째로 보관하는 구조라면 키 변경은 쉽지 않은 선택입니다.

이런 이유 때문에 데이터 암호화 키와 키를 암호화하는 키(Key Encryption Key, KEK)로 키 구조를 분리하여 키를 주기적으로 변경하기도 합니다. 하지만 KEK만 변경해서는 보안성을 높이려는 취지에 어긋나는 면이 있습니다.

또 다른 방안으로 데이터 암호화 키를 적절히 구조화하여 키 히스토리(Key History) 관리를 수행해서 암호화를 쉽게 구현하는 방법도 있습니다. 일반적인 데이터 암호화에서는 좋은 방안이지만, 성능이 중요한 데이터베이스를 운영할 때는 성능에 미칠 영향을 고려해야 합니다.

인덱스 컬럼을 암호화한 경우(인덱스가 설정된 칼럼을 암호화한 경우) 인덱스 암호화도 도전이지만, 키를 주기적으로 교체하는 측면에서도 큰 도전입니다. 인덱스가 필요한 컬럼은 테이블 설계 단계에서 암호화를 하지 않아도 되는 정보로 구분하거나 데이터베이스 설계 단계에서 기간 단위로 테이블을 분리하는 방법이 가장 좋습니다. 이미 고정된 데이터베이스에서는 운영 모드를 잘 선택하고 초기화 벡터(IV)를 활용하는 방식으로 이 문제를 해결하는 것이 바람직합니다. COA 문제는 비정상적인 대량 데이터 쿼리 같은 특수 상황을 제어할 수 있는 보안 기능을 마련하여 보완할 것을 추천합니다.