DB 암호화 방식 한눈에 정리
| 방식 | 동작/설명(핵심) | 장점 | 한계/주의 | 권장 사례 |
|---|---|---|---|---|
| Plug-in 방식 | DB 엔진(또는 드라이버)에 플러그인/프로시저를 붙여 쿼리 과정에서 자동 암·복호화. 애플리케이션은 거의 그대로 사용 | 앱 수정 최소, 도입 빠름, 표준 SQL 유지 | DB/플러그인 종속성, 특정 함수/인덱스 제약, 버전 업그레이드 시 호환성 점검 필요 | 상용 DB(Oracle/MySQL 등)에서 빠른 규제 대응이 필요할 때 |
| In-Places 방식 | DB 내부(컬럼/테이블) 값을 제자리(In-Place)에서 암호문으로 교체. 보통 UDF/트리거로 처리 | 데이터가 DB에 들어오는 즉시 보호, 백업 유출 대응 용이 | 기존 인덱스/정렬/LIKE 검색 제약, 마이그레이션/재인덱싱 작업 필요 | 민감 컬럼 선택 암호화, 운영 DB에 단계적 적용 |
| API 방식 | 애플리케이션에서 API/라이브러리로 직접 암호화 후 DB에 저장(앱 레벨 암호화) | DB/운영자도 평문 미접근(권한 분리), 세밀한 정책/포맷(FPE) 적용 가능 | 앱 수정·테스트 비용↑, 다수 서비스 간 키·정책 일관성 관리 필요 | 보안 요구가 높은 서비스, 마이크로서비스·외부 연동 시스템 |
| 하이브리드 | 둘 이상 방식 병행: 예) TDE(파일/백업) + 컬럼 암호화/Plug-in + 일부 API | 다층 방어, 성능·보안 균형 설계 가능, 규제/실무 요구 모두 충족 | 설계 복잡도↑, 키·운영 절차 복합화(모니터링·장애대응 체계 필요) | 대규모/규제 산업(금융·의료), 이기종 DB·다양한 워크로드 환경 |
빠른 선택 가이드
-
개발 변경 최소·신속 도입 → Plug-in
-
특정 컬럼만 강력 보호 → In-Places(컬럼 단위)
-
DB/운영자도 평문 접근 차단 → API(앱 레벨)
-
광범위·고보안 요구 → 하이브리드(TDE+컬럼/Plug-in+API 조합)
설계 체크포인트
-
키 관리: KMS/HSM 연동, DEK/KEK 계층화, 주기적 키 회전
-
성능/검색성: 결정적 암호화(=동치 비교) vs 비결정적(보안↑, 검색성↓)
-
운영성: 백업/덤프 별도 암호화, 장애 시 복구/재암호화 절차 사전 검증
