설명
Aurora 같은 클러스터형 데이터베이스는 핵심 애플리케이션 데이터를 저장하므로 저장 데이터와 백업을 암호화해야 합니다. 실제로 암호화되지 않은 클러스터는 이 보호 계층이 부족합니다.
다만 storage_encrypted를 생략했다는 사실만으로 비암호화라고 판단할 수는 없습니다. 현재 새 Aurora 클러스터는 기본 암호화를 사용하며, 이전에 생성하거나 복원·복제한 클러스터는 실제 상태를 확인해야 합니다. 암호화는 데이터베이스 권한과 네트워크 통제를 대신하지 않습니다.
잠재적 영향
권한 없는 주체가 비암호화 스토리지나 백업을 확보하면 고객 데이터와 서비스 데이터가 노출될 수 있습니다. 조직의 암호화 요구사항도 충족하지 못할 수 있습니다. 사용 중인 키가 사용 불가능해지면 데이터 접근과 복구에 장애가 생길 수 있습니다.
해결 방법
- 실제 클러스터와 백업의 암호화 상태를 확인하고 필요한
storage_encrypted = true와 KMS 키를 명시하세요. - 기존 비암호화 클러스터는 설정만 바꾸어 암호화할 수 없습니다. 지원되는 스냅샷 암호화 복사·복원 등을 이용한 새 클러스터 이전을 계획하세요.
- Terraform 교체 계획, 데이터 일관성, 애플리케이션 전환과 복구를 검증하고 원본과 필요한 키를 보존하세요.
예시
암호화 설정을 비교하는 발췌이며 필요한 인스턴스·네트워크 설정은 별도로 구성하세요. 비밀번호는 요구사항을 만족하는 값을 안전하게 공급하고 Terraform 상태 접근도 제한하세요.
암호화 설정 생략
hcl
resource "aws_rds_cluster" "rds_cluster" {
cluster_identifier = "aurora-cluster-demo"
engine = "aurora-mysql"
master_username = "foo"
master_password = var.db_password
}
암호화를 명시하지 않았습니다. 현재 새 Aurora 클러스터의 기본 암호화를 고려하면, 이 발췌만으로 평문 저장을 의미하지는 않습니다.
암호화 명시
hcl
resource "aws_rds_cluster" "rds_cluster" {
cluster_identifier = "cloudrail-test-non-encrypted"
engine = "aurora-mysql"
master_username = "administrator"
master_password = var.db_password
storage_encrypted = true
}
저장 암호화를 명시합니다. 이 예시는 기존 데이터나 클러스터를 안전하게 이전하는 전체 절차가 아닙니다.