길리랩blog

DB 암호화 설계: 저장 데이터 보호 방식과 키 관리

DB 암호화 방식별 특성과 색인·무중단 전환·성능 영향을 살피고, 키 관리와 산업별 적용 관점을 정리한다.

2026-08-14 · 최초 발행 2025-08-10

저장 데이터를 보호하는 암호화 설계

데이터베이스는 기업이 보유한 핵심 자산이자 공격과 유출의 직접적인 표적이다. 저장 데이터(Data at Rest)를 보호하려면 내부 유출과 외부 침입 모두를 고려해야 하며, 암호화는 그 방어 체계의 중심에 놓인다. 기밀성, 무결성, 가용성, 인증을 유지하는 관점에서 DB 암호화를 설계해야 한다.

데이터베이스 보안이 지키려는 대상은 다음과 같다.

  • 기밀성(Confidentiality): 허가된 사용자만 데이터에 접근할 수 있어야 한다.
  • 무결성(Integrity): 데이터의 정확성과 일관성을 보장해야 한다.
  • 가용성(Availability): 필요한 시점에 데이터를 사용할 수 있어야 한다.
  • 인증(Authentication): 정당한 사용자인지 확인해야 한다.
  • 부인방지(Non-repudiation): 데이터 처리 행위를 증명할 수 있어야 한다.

개인정보보호법과 GDPR 등 데이터 보호 관련 법규가 강화되면서, DB 암호화는 컴플라이언스 준수를 위한 요소로도 다뤄진다.

적용 위치에 따라 달라지는 암호화 방식

암호화와 복호화를 어느 계층에서 처리하는지에 따라 운영 범위와 제약이 달라진다.

애플리케이션이 직접 처리하는 API 방식

⤢✕암호화 API 호출암호화된 데이터 저장응용 프로그램암호화 모듈데이터베이스암호화된 DB

API 방식은 애플리케이션 레벨에서 데이터를 암호화하고 복호화한다. 구현이 상대적으로 간단하고 비용 효율적이며, DBMS나 스토리지와 독립적으로 동작할 수 있다. 반면 애플리케이션 코드를 수정해야 하고 성능 오버헤드가 발생할 수 있다. 시스템 규모가 커질수록 일관성을 유지하기도 어렵다.

소규모 애플리케이션이나 특정 필드만 암호화해야 하는 경우에 활용할 수 있다.

DBMS에 결합하는 플러그인 방식

⤢✕암/복호화응용 프로그램DBMS암호화 플러그인암호화된 DB

플러그인 방식은 암호화 모듈을 DBMS 내부에 통합한다. 애플리케이션 코드 변경을 최소화하면서 DBMS 기능과 결합하기 쉽고, 투명한 암호화를 제공한다.

대신 DBMS 종속성이 생기며 성능에 영향을 줄 수 있다. 플러그인 호환성도 운영 단계에서 확인할 대상이다. Oracle TDE(Transparent Data Encryption), MS SQL Server TDE가 이 방식의 활용 사례다.

운영체제 계층에서 처리하는 커널 방식

⤢✕암/복호화응용 프로그램DBMS운영체제 커널암호화 모듈암호화된 DB

커널 방식은 OS 커널 레벨에서 데이터를 암호화하고 복호화한다. DBMS와 애플리케이션에 투명하며, 여러 애플리케이션에 일관된 암호화를 제공할 수 있고 보안성이 높다.

구현 복잡성, OS 종속성, 관리의 어려움은 함께 감수해야 한다. 파일시스템 암호화와 전체 디스크 암호화(FDE)가 활용 사례다.

검색과 전환 과정에서 생기는 제약

암호화된 데이터는 원본 데이터의 패턴을 숨기므로 인덱스 기반 검색이 어려워진다. 검색 요구가 있는 컬럼은 암호화 범위와 검색 방식을 함께 설계해야 한다.

검색 문제에 대응하는 방법으로는 검색 필드를 암호화하지 않거나 일부만 암호화하는 부분 암호화, Order-Preserving Encryption 같은 검색 가능한 암호화 기법을 쓰는 암호화 인덱스, 실제 데이터 대신 토큰과 별도 매핑 테이블을 두는 토큰화가 있다.

-- 부분 암호화 인덱스 예시
CREATE TABLE customers (
  id INT PRIMARY KEY,
  name VARCHAR(100) ENCRYPTED,
  ssn_last4 VARCHAR(4), -- 검색용 비암호화 필드
  ssn VARCHAR(100) ENCRYPTED -- 전체 암호화 필드
);

CREATE INDEX idx_ssn_last4 ON customers(ssn_last4);

대규모 데이터베이스를 암호화할 때는 처리 시간이 길어질 수 있으므로 서비스 중단을 최소화해야 한다. 테이블 단위로 순차 전환하는 점진적 암호화, 암호화된 데이터베이스와 기존 데이터베이스를 함께 운영하는 이중 운영, 온라인 마이그레이션 도구 활용이 선택지다.

금융권 A사는 3TB 고객 데이터베이스를 암호화하면서 주말 4시간 업무 중단이 허용되는 상황에서 테이블 복제와 암호화 처리, 변경 데이터 추적 및 동기화, 암호화 DB 전환을 진행했고 4시간 내 완료했다.

성능 영향은 방식별로 다르다

암호화는 CPU 자원을 소모하고 I/O 패턴을 바꾸므로 성능에 영향을 준다. 중요 데이터만 대상으로 삼는 선택적 암호화, HSM(Hardware Security Module) 활용, AES-NI와 같은 하드웨어 가속 알고리즘, 자주 쓰이는 암호화 결과의 캐싱, 암호화 작업의 병렬 처리가 최적화 방안이 될 수 있다.

암호화 방식 쿼리 성능 저하율 스토리지 증가율
API 방식 20-30% 5-10%
플러그인 방식 10-20% 8-15%
커널 방식 5-15% 10-20%

키가 보호되지 않으면 암호화도 완성되지 않는다

키 관리는 DB 암호화에서 가장 중요한 요소 중 하나다. 마스터 키에서 키 암호화 키(KEK), 데이터 암호화 키(DEK)로 이어지는 계층을 두고, 데이터는 DEK로 보호하는 구조를 사용한다.

⤢✕마스터 키키 암호화 키KEK데이터 암호화 키DEK암호화된 데이터HSM

키 계층화 외에도 정기적인 키 교체(Rotation), 키 손실에 대비한 백업 및 복구, 키 접근에 대한 강력한 인증과 승인, 키 사용 감사 로그가 필요하다.

1. 마스터 키: HSM 내부에 보관
2. KEK: 마스터 키로 암호화하여 보관
3. DEK: KEK로 암호화하여 메타데이터 저장소에 보관
4. 데이터: DEK로 암호화하여 DB에 저장

보호 대상에 맞춰 달라지는 적용 관점

금융권에서는 고객 금융정보와 거래데이터를 보호해야 하므로 플러그인 방식과 HSM을 주로 적용한다. 계좌번호, 카드정보, 주민번호, 거래내역이 암호화 대상이며 강력한 감사 추적과 키 관리 체계가 요구된다.

의료분야는 환자 의료정보 보호(HIPAA 준수)를 요구사항으로 둔다. API 방식과 플러그인 방식을 혼합해 환자식별정보, 진료기록, 처방정보를 보호하면서 데이터 공유와 분석 용이성을 확보한다.

소매와 이커머스에서는 고객 결제정보와 배송정보를 지켜야 한다. 카드정보, 배송주소, 구매이력을 암호화 대상으로 두고 API 방식을 주로 사용하며 성능과 확장성을 중시한다.

암호화 기술이 향하는 방향

동형 암호화(Homomorphic Encryption)는 암호화된 상태에서 연산하는 방식을 다룬다. 양자 내성 암호화(Quantum-Resistant Encryption)는 양자컴퓨팅 공격에 대비하며, 제로 지식 증명(Zero-Knowledge Proofs)은 데이터 노출 없이 검증하는 데 초점을 둔다.

암호화된 데이터로 기계학습을 수행하는 연합 학습(Federated Learning), 정책 기반으로 암호화 관리를 자동화하는 흐름도 DB 암호화와 연결된다.

DB 암호화는 단일 기술을 적용하는 일이 아니라 데이터 보호 전략을 구성하는 일이다. 구현 위치, 색인 검색, 서비스 연속성, 성능, 키 관리를 함께 검토해 환경에 맞는 방식을 선택해야 한다.

DB 보안데이터 암호화키 관리HSM정보보안