[ORACLE] 19c·23ai TDE란? 개념, 적용 방법, 활용 범위

오라클 19c·23ai TDE란? 데이터베이스 암호화 개념과 적용 방법, 활용 범위 정리

오라클 데이터베이스를 운영하다 보면 “디스크나 백업 파일이 유출되면 어떻게 하지?”, “DBA가 전체 데이터를 볼 수 있는데 이건 괜찮은가?” 같은 고민을 한 번쯤 하게 됩니다. 이런 데이터 저장 영역(디스크·백업)의 유출 위험을 줄이는 핵심 기능이 바로 오라클의 Transparent Data Encryption, 즉 TDE입니다.

TDE(Transparent Data Encryption)는 Oracle Database의 기능으로, 테이블/테이블스페이스/백업 파일을 저장 시점에 암호화해 두고, 정상 권한을 가진 세션에는 자동으로 복호화된 평문을 보여 주는 “투명” 암호화 기술입니다.

이 글에서는 Oracle 19c와 23ai 기준으로 TDE가 무엇인지, 어떤 구조로 동작하는지, 어떻게 적용·운영해야 하는지, 그리고 실제 활용 범위와 한계까지 단계별로 정리합니다.

1. 오라클 TDE의 기본 개념

오라클 공식 문서에 따르면 TDE는 테이블이나 테이블스페이스에 저장된 민감 데이터, 그리고 백업 파일을 암호화하고, 이를 권한 있는 사용자에게는 투명하게 복호화해 주는 기능입니다.

1-1. “Transparent(투명)”의 의미

• 애플리케이션 입장에서는 추가 개발 없이 기존 SQL 그대로 사용할 수 있습니다.
• 암호화/복호화는 스토리지 I/O 경계에서 DB 엔진이 처리합니다.
• DB에 정상 접속하여 SELECT하는 권한이 있으면 평문 데이터가 보이고, 디스크·백업 파일만 탈취한 공격자는 키 없이 복호화 불가합니다.

1-2. TDE가 보호하는 영역

• 데이터 파일(테이블스페이스)
• UNDO·REDO·TEMP 영역 내의 민감 데이터
• RMAN 백업, Data Pump 덤프 등 데이터 파일 기반 아티팩트

1-3. TDE의 핵심 구성 요소

• TDE 마스터 키(TDE Master Encryption Key) - 실제 데이터 키를 암호화하는 상위 키 - 외부 키스토어(소프트웨어 키스토어·Oracle Key Vault·HSM 등)에 저장
• 테이블 키·테이블스페이스 키 - 실제 데이터 암·복호화에 사용되는 키 - 마스터 키로 암호화되어 저장
• 키스토어(Keystore) - 예전 용어로 ‘Wallet’ - TDE 마스터 키를 보관하는 안전한 저장소 - 소프트웨어 키스토어, Oracle Key Vault, 클라우드 키 매니저, HSM 등과 연동 가능

2. 컬럼 레벨 vs 테이블스페이스 레벨 TDE

Oracle TDE는 크게 컬럼 단위 암호화와 테이블스페이스 단위 암호화 두 가지 방식이 있습니다.

2-1. 컬럼 레벨 TDE

• 민감 정보가 들어 있는 특정 컬럼(예: 주민번호, 카드번호)에만 암호화 적용.
• ALTER TABLE ... MODIFY (컬럼 ENCRYPT ...) 형태로 적용.
• 장점
  • 정말 필요한 컬럼만 선별적으로 암호화 가능
  • 컬럼별로 다른 알고리즘/키 길이 설정 가능
• 단점
  • 어떤 컬럼이 민감한지 사전 분석이 필요
  • 인덱스, 조건절, 정렬/조인 시 고려 사항이 많음

2-2. 테이블스페이스 레벨 TDE

• 특정 테이블스페이스 전체를 암호화하면, 그 안에 생성되는 모든 세그먼트(테이블, 인덱스 등)가 자동 암호화.
• 암호화된 테이블스페이스에 있는 데이터는 항상 암호화된 상태로 디스크에 저장.
• 장점
  • 민감 컬럼을 일일이 분석하지 않아도 됨
  • EHCC, Advanced Compression, RMAN 압축 기능과도 호환
  • 운영/관리 관점에서 단순·직관적
• 단점
  • 해당 테이블스페이스 전체 I/O에 암호화 오버헤드가 추가

실무 권장 패턴

• 신규 시스템: 테이블스페이스 레벨 TDE를 기본으로 설계.
• 기존 시스템:
  • 우선 민감도가 아주 높은 컬럼에만 컬럼 레벨 TDE 적용
  • 성능·운영 범위를 검증한 뒤, 단계적으로 테이블스페이스 레벨 암호화 확대

3. Oracle 19c TDE의 특징

Oracle 19c는 장기 지원(LTS) 버전으로, TDE 기능이 이미 성숙 단계에 들어온 버전입니다. 특히 ADMINISTER KEY MANAGEMENT 구문으로 통합 키 관리가 가능하며, 소프트웨어 키스토어, Oracle Key Vault, HSM 등 다양한 키 관리 솔루션과 연동할 수 있습니다.

3-1. 19c TDE의 대표적인 포인트

• 다중 테넌트(CDB/PDB) 구조에서의 TDE
  • 컨테이너 DB(CDB)와 플러그인 DB(PDB) 각각에 대해 키 관리 정책을 설계해야 함.
  • Oracle Key Vault를 활용하면 여러 노드·PDB의 키를 중앙에서 관리 가능.
• ADMINISTER KEY MANAGEMENT로 키스토어/키 통합 관리
  • 키스토어 생성/오픈/클로즈
  • TDE 마스터 키 생성/회전(rotate)
  • 외부 키 매니저(OKV/HSM) 연동
• RMAN·Data Pump·Data Guard와의 통합
  • RMAN 백업 시 TDE 키를 활용해 백업 파일도 암호화 가능.
  • Data Pump는 ENCRYPTION_PASSWORD 또는 ENCRYPTION_MODE=TRANSPARENT로 TDE와 연계.

4. Oracle 23ai에서의 TDE·보안 강화 포인트

Oracle 23ai는 “AI Database”라는 이름답게 전체 플랫폼 보안이 강화되었고, TDE 역시 최신 암호화 알고리즘·모드, 키 관리, Data Guard 연동 측면에서 개선이 이루어졌습니다.

4-1. 향상된 암호화 알고리즘 및 모드

• Oracle Transparent Data Encryption Guide(23ai/AI DB 전용)에서는 지원 암호화/무결성 알고리즘 업데이트와 관련된 변경 사항을 안내합니다.
• 최신 안전 기준을 충족하는 알고리즘, 모드, 키 길이를 사용할 수 있도록 지속 개선.

4-2. 로컬 자동 로그인 키스토어(Local auto-login keystore) 개선

• 23ai에서는 로컬 자동 로그인 키스토어의 보안성과 배포 편의성이 강화되었습니다.
• 베어메탈·가상 환경 모두에서 더 안전하게 자동 로그인 지갑을 활용할 수 있도록 구조 개선.
• 재부팅 후에도 키스토어 자동 오픈이 필요한 환경(예: 무인 재시작)에서 특히 유용.

4-3. Data Guard와 TDE 재키(rekey) 자동화

• DB_RECOVERY_AUTO_REKEY 파라미터를 통해 TDE 재키 작업이 Data Guard 환경에서 자동으로 동기화되도록 제어할 수 있습니다.
• 대용량 TDE 테이블스페이스를 온라인으로 암호화/재암호화하는 환경에서 운영 부담을 낮춰 줍니다.

5. TDE 적용 절차(19c·23ai 공통 개념)

실제로 19c나 23ai에서 TDE를 도입할 때는 기술 기능만 보는 것이 아니라, 보안 정책·규제 요구·장애 대응·백업·복제 전략까지 함께 설계해야 합니다.

5-1. 도입 전 사전 설계

• 규제·컴플라이언스 요구 확인
  • 개인정보보호법, 신용정보법, 전자금융감독규정 등에서 요구하는 암호화 범위 확인.
• 암호화 대상 정의
  • 전체 DB를 암호화할지, 특정 테이블스페이스/스키마/컬럼만 암호화할지 결정.
  • 거래량이 매우 많은 핵심 테이블에 대한 성능 영향도 사전 검토.
• 키 관리 전략 수립
  • 소프트웨어 키스토어만 사용할지, Oracle Key Vault·HSM 등 외부 키 관리자까지 사용할지 결정.
  • 키 백업, 키 로테이션 주기, DR/HA 환경에서의 키 동기화 전략 설계.

5-2. 키스토어 생성 및 오픈

아주 단순화하면 다음 흐름으로 진행됩니다(예시는 개념 설명용):

1. 키스토어용 디렉터리 생성(서버 OS 레벨).
2. ADMINISTER KEY MANAGEMENT 구문으로 소프트웨어 키스토어 생성.
3. 키스토어 패스워드를 안전하게 관리(비밀관리 시스템에 보관).
4. DB 기동 시점에 키스토어를 OPEN 할 수 있도록 운영 절차 또는 자동로그인 정책 구성.

-- 개념 예시: 키스토어 오픈
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
  IDENTIFIED BY "키스토어_패스워드";

외부 키 관리자(Oracle Key Vault, 클라우드 KMS, HSM 등)를 사용하는 경우에는 TDE_CONFIGURATION 파라미터를 통해 해당 키스토어 타입을 지정하고, DB가 외부 키 관리자와 연결되도록 설정합니다.

5-3. TDE 마스터 키 생성/회전

• 키스토어가 OPEN 상태가 되면, TDE 마스터 암호화 키를 생성합니다.
• 이 키는 컬럼/테이블스페이스 키를 암호화하는 상위 키로, 주기적으로 회전(rotate)하는 것이 권장됩니다.
• 키 회전 시에도 TDE는 내부적으로 재암호화 과정을 관리하므로, 애플리케이션 변경은 필요하지 않지만, 작업 시간·성능 영향은 사전에 검토해야 합니다.

5-4. 컬럼/테이블스페이스 TDE 적용

암호화 전략에 따라 컬럼 레벨 또는 테이블스페이스 레벨로 적용합니다.

• 컬럼 레벨
  • 중요 식별자 컬럼(주민번호, 계좌번호 등)에 ENCRYPT 옵션 적용.
  • 이미 운영 중인 테이블은 ALTER TABLE ... MODIFY로 변경.
• 테이블스페이스 레벨
  • 신규 테이블스페이스를 ENCRYPTION USING 'AES256' 옵션과 함께 생성.
  • 기존 테이블스페이스는 온라인/오프라인 암호화 기능을 이용하여 점진적 변환.

5-5. 백업·복구·복제 연동

• RMAN
  • TDE 키를 활용해 백업 세트를 암호화할 수 있음.
  • 백업 복구 시 키스토어가 복구 환경에도 존재하고, OPEN 가능한지 반드시 검증해야 함.
• Data Pump
  • ENCRYPTION_PASSWORD 또는 ENCRYPTION_MODE=TRANSPARENT 옵션으로 TDE와 연계.
• Data Guard
  • 스탠바이 DB에도 동일 키스토어/마스터 키가 배포되어야 함.
  • 23ai에서는 DB_RECOVERY_AUTO_REKEY를 통해 재키 작업을 자동화하여 운영 부담을 줄일 수 있음.

6. TDE의 활용 범위와 한계

6-1. TDE가 잘 해결해 주는 영역

• 스토리지·백업 유출 사고
  • 디스크가 분실·도난되어도, 데이터 파일은 암호화된 상태라 키 없이 복호화 불가.
• 운영 위탁·백업 업체 등 외부 위협
  • 스토리지·백업 레벨만 접근 가능한 외부 인력은 데이터를 평문으로 볼 수 없음.
• 규제 및 심사 대응
  • “데이터 저장 매체 암호화” 요구 사항을 TDE로 충족할 수 있음.

6-2. TDE만으로는 부족한 부분

• DB 권한이 있는 사용자의 오남용
  • TDE는 저장 시점 암호화(data-at-rest) 기술이라, SELECT 권한을 가진 사용자는 평문 데이터를 그대로 조회할 수 있습니다.
  • 따라서 접속 제어, 최소 권한, SQL 감사(감사 로그)가 함께 필요합니다.
• 네트워크 구간 암호화
  • TDE는 디스크·백업 보호에 초점이 있고, 클라이언트 ↔ DB 사이 네트워크는 별도의 SSL/TLS 설정으로 보호해야 합니다.
• 애플리케이션 레벨 공격
  • XSS, SQL 인젝션, 세션 하이재킹 같은 공격은 TDE만으로 막을 수 없습니다.

7. Oracle 19c·23ai TDE 운영 시 베스트 프랙티스

7-1. 키 관리·키 백업

• 키스토어 파일은 DB 파일과 별도의 안전한 저장소(예: 보안 파일 시스템, 전용 키 관리 서버)에 보관.
• TDE 마스터 키와 키스토어 패스워드는 비밀관리 시스템에 저장하고, 개인 메모·이메일 등에는 절대 남기지 않도록 정책화.
• Oracle Key Vault, HSM 등과 연계해 키 중앙 관리 및 이중화를 설계하는 것이 권장됩니다.

7-2. 성능·설계 관점

• 암호화 적용 전·후에 TPS, 응답시간, CPU 사용량을 측정하고 baseline을 확보.
• I/O가 특히 많은 테이블스페이스는 스토리지·캐시 정책과 함께 튜닝.
• CPU 리소스가 부족한 서버에서는 단계적으로 암호화 범위를 확대하는 전략 사용.

7-3. 재난 복구·테스트

• DR 센터, 스탠바이 DB에서 실제 복구 테스트를 수행하여 키스토어·마스터 키 동기화 상태를 검증.
• 키 손실 시 데이터 복구가 불가능해지므로, 키 백업·복구 절차를 문서화하고 정기적으로 리허설하는 것이 필수입니다.

정리: 19c·23ai TDE 활용 전략

• 규제·보안 요구가 있는 환경에서는 테이블스페이스 레벨 TDE를 기본으로 고려.
• 특히 민감도가 높은 항목은 컬럼 레벨 TDE + 추가 접근 통제를 병행.
• 23ai를 도입한다면, 향상된 암호화 알고리즘·키스토어·Data Guard 연동 기능까지 활용해 전체 보안 아키텍처를 한 단계 업그레이드하는 것이 좋습니다.

#Oracle19c #Oracle23ai #TDE #데이터베이스암호화 #오라클보안 #데이터보호