DB 암호화 설계와 키 관리 전략

암호화 범위가 데이터베이스 보호 수준을 결정한다

DB 암호화는 데이터베이스에 저장하는 정보를 암호화 알고리즘으로 변환해 허가되지 않은 접근으로부터 보호하는 기술이다. 데이터 유출이나 내부자 위협이 발생했을 때 노출 범위를 줄이고, 개인정보보호법, GDPR, HIPAA 같은 데이터 보호 규제의 요구사항에 대응하는 데 쓰인다.

보호 대상은 주민등록번호와 여권번호 같은 개인식별정보(PII), 신용카드 번호와 계좌 정보 같은 금융 정보, 진료 기록과 처방전 같은 의료 정보, 영업 비밀과 연구 데이터 같은 기업 기밀 정보까지 넓다. 어떤 데이터를 어디에서 암호화할지는 데이터의 민감도와 시스템 운영 방식에 따라 달라진다.

저장 계층과 애플리케이션 사이의 선택지

데이터베이스 파일을 보호하는 TDE

Transparent Data Encryption(TDE)는 데이터베이스 파일 전체를 암호화하는 방식이다. 애플리케이션 변경 없이 적용할 수 있고 스토리지 레벨에서 데이터를 보호하며, 데이터베이스 백업 파일도 자동으로 암호화한다.

⤢✕

민감한 컬럼만 암호화하는 방식

컬럼 레벨 암호화는 특정 컬럼을 골라 암호화한다. 중요한 데이터만 보호 대상으로 삼을 수 있어 성능 영향을 줄이기 좋고, 데이터 항목별로 세밀한 보안 정책을 적용할 수 있다.

애플리케이션 레벨 암호화는 데이터를 데이터베이스에 저장하기 전에 애플리케이션에서 암호화한다. DBA에게도 데이터가 노출되지 않게 할 수 있고 데이터베이스 자체의 성능에는 영향을 덜 주지만, 구현 복잡성은 커진다.

암호화 기술은 처리 목적에 맞춰 고른다

대칭키 암호화는 같은 키로 암호화와 복호화를 수행한다. AES, DES, 3DES가 예이며 처리 속도가 빠른 대신 키 관리가 복잡하다.

비대칭키 암호화는 공개키와 개인키 쌍을 사용한다. RSA와 ECC가 대표적이며 안전한 키 교환에 적합하지만 처리 속도는 느리다.

해시 함수는 원본을 복원할 수 없는 단방향 암호화다. SHA-256, MD5(보안 취약점 있음)가 예이며 패스워드 저장과 데이터 무결성 검증에 사용한다.

⤢✕

DBMS 기능, 게이트웨이, 애플리케이션으로 구현하기

DBMS 자체 기능을 이용하면 Oracle TDE는 테이블스페이스 또는 컬럼 레벨 암호화를 지원하고, 마스터 암호화 키로 키를 관리한다. 예시는 ALTER TABLE customers MODIFY (credit_card ENCRYPT USING 'AES256')이다.

MS SQL Server TDE는 데이터베이스 파일 레벨 암호화와 인증서 기반 키 관리를 제공한다. 예시는 CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE MyCertificate다.

MySQL/MariaDB는 플러그인 기반 암호화와 키링 서비스를 활용한다. 예시는 CREATE TABLE t1 (c1 INT, c2 VARCHAR(100) ENCRYPTED WITH (ENCRYPTION_KEY_ID = 1, ALGORITHM = 'AES_256_CBC'))다.

암호화 게이트웨이는 애플리케이션과 데이터베이스 사이에서 암호화와 복호화를 투명하게 수행한다. 키 관리 시스템(KMS)은 키 생성, 저장, 순환을 담당하며, HSM(Hardware Security Module)은 물리적 장치로 암호화 키를 보호한다.

⤢✕

애플리케이션 내부에서 구현할 때는 Hibernate, JPA 등의 ORM 레벨 암호화 기능을 활용하거나 자체 암호화 라이브러리를 API로 구성할 수 있다.

// AES 암호화 예시
public String encrypt(String data, String key) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
    SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), "AES");
    cipher.init(Cipher.ENCRYPT_MODE, keySpec);
    byte[] encrypted = cipher.doFinal(data.getBytes());
    return Base64.getEncoder().encodeToString(encrypted);
}

운영 설계에서 검토할 제약

암호화와 복호화에는 오버헤드가 있으며, 특히 대용량 데이터를 처리할 때 성능 저하가 생길 수 있다. 암호화된 컬럼은 인덱싱 효율도 낮아질 수 있다. 일부만 암호화하고, 함수 기반 인덱스를 활용하거나, 컬럼 레벨 암호화와 TDE를 병행하는 방법을 검토할 수 있다.

키는 충분한 엔트로피(무작위성)를 갖도록 생성해야 하며 HSM 또는 안전한 키 관리 시스템에 보관해야 한다. 정기적인 키 교체 정책과 키 분실 시 복구할 수 있는 백업 방안도 필요하다.

검색 요구사항도 설계에 영향을 준다. 동형 암호화(Homomorphic Encryption)는 암호화된 상태에서 연산할 수 있고, 결정적 암호화(Deterministic Encryption)는 같은 평문에서 같은 암호문을 만든다. 형태 보존 암호화(Format-Preserving Encryption)는 원본과 같은 형식을 유지한다.

규제 측면에서는 개인정보보호법의 주민등록번호 등 고유식별정보 암호화 의무, 금융권 보안 지침의 금융 데이터 암호화 요구사항, GDPR과 HIPAA 등의 해외 규제를 함께 확인해야 한다.

금융과 의료 시스템에서의 적용 형태

금융권에서는 고객 금융정보와 개인식별정보를 보호하기 위해 주요 식별정보에 컬럼 레벨 암호화(AES-256)를 적용하고, 전체 DB에는 TDE를 적용하며, HSM 기반으로 키를 관리할 수 있다. 성능을 고려해 앞 6자리와 뒤 4자리만 평문으로 유지하고, 인덱싱을 위한 해시값을 별도로 저장하는 방식도 사용한다.

의료정보시스템에서는 환자 식별정보를 애플리케이션 레벨에서 암호화하고, 진료기록에는 파일 레벨 암호화를 적용할 수 있다. 접근 통제와 암호화를 결합하고, 응급 상황에 대비한 비상 접근 프로세스와 강화된 감사 로그를 구성한다.

⤢✕

암호화 기술이 향하는 방향

양자 내성 암호화(Post-Quantum Cryptography)는 양자 컴퓨팅 위협에 대응하는 방향으로 논의된다. 동형 암호화는 암호화 상태의 연산 기능을 발전시키고 있으며, AI 기반 이상 탐지는 암호화와 이상 탐지 기술을 결합한다. 제로 트러스트 아키텍처에서는 지속적 인증과 암호화를 통합하는 접근이 이어진다.

DB 암호화는 단일 기능을 켜는 작업으로 끝나지 않는다. 암호화 범위, 성능, 검색 기능, 키 관리, 접근 통제를 함께 설계해야 데이터 보호와 운영 요구사항을 모두 다룰 수 있다.