AWS EBS·RDS 저장 암호화 점검과 전환 우선순위

AWS 자산의 저장 암호화를 감사하던 당시 일부 레거시 EBS 볼륨에서 미암호화 설정을 확인했다.
설정만 보면 해당 자산에 모두 같은 수준의 개인정보 위험이 있는 것처럼 보였다.

하지만 암호화 설정과 실제 데이터 민감도는 서로 다른 질문이다.
설정이 꺼져 있으면 개선 대상인 것은 맞지만, 그 볼륨에 어떤 데이터가 지속적으로 저장되는지 확인해야 조치 순서를 정할 수 있다.

EBS는 EC2 서버에 붙이는 가상 디스크이고, RDS는 AWS가 운영을 관리해 주는 관계형 데이터베이스 서비스다.
저장 시 암호화는 디스크와 스냅샷처럼 저장된 데이터가 키 없이 읽히지 않도록 보호하는 통제다.

현재 운영 상태와 자산 식별 정보는 공개하지 않으며, 이 글은 당시 감사에서 얻은 점검 방법과 우선순위 결정 기준을 다룬다.

같은 미암호화 볼륨도 영향은 다르다

예를 들어 쇼핑 서비스에는 다음 저장소가 함께 있을 수 있다.

• 주문자 이름과 배송지를 보관하는 RDS
• 상품명과 가격을 빠르게 찾도록 복제한 검색 색인
• 배포 중 내려받은 파일만 잠깐 두는 캐시 볼륨

세 곳이 모두 디스크를 사용하더라도 데이터가 유출됐을 때의 영향과 다시 만들 수 있는 정도는 다르다.

주문 DB는 원본 개인정보이므로 우선순위가 높다.

검색 색인은 원본 DB에서 다시 만들 수 있어도 상품 공개 전 정보나 고객 식별자가 포함됐다면 보호가 필요하다.

캐시는 재생성 가능하더라도 Access Token이나 원본 파일이 남는지 확인해야 한다.

이 예시는 판단 방법을 보여 주기 위해 단순화한 것이며, 실제 분류는 회사의 데이터 정책과 법적 요구사항을 따라야 한다.

콘솔 화면 하나 대신 세 가지 증거를 맞췄다

먼저 AWS API로 ECS, EC2, EBS와 RDS의 감사 당시 설정을 읽었다.
그다음 코드에서 검색 색인 필드와 자동화 서버의 데이터 사용 부분을 확인했다.
마지막으로 서버에서는 실제 페이로드를 열지 않고 인스턴스 메타데이터와 영속 데이터 경로만 읽기 전용으로 확인했다.

영속 데이터는 프로세스를 재시작하거나 컨테이너를 다시 만들어도 디스크에 남아야 하는 데이터다.
임시 처리만 하는 서버와 고객 데이터 원본을 장기 보관하는 서버는 미암호화 설정이 같아도 영향도가 다르다.

사용한 조회 명령에서 자산 식별자는 공개용으로 제거했다.

aws ec2 describe-volumes \
  --query 'Volumes[].{Encrypted:Encrypted,State:State,Size:Size}'

aws rds describe-db-instances \
  --query 'DBInstances[].{Encrypted:StorageEncrypted,Public:PubliclyAccessible}'

describe-volumes는 볼륨의 암호화 여부, 상태와 크기를 읽으며 리소스를 변경하지 않는다.
--query는 전체 응답에서 감사에 필요한 필드만 골라 출력하기 위해 사용했다.

describe-db-instances의 StorageEncrypted는 RDS 저장 암호화 여부를 보여 준다.
PubliclyAccessible은 DB 인스턴스에 공개 접근 설정이 있는지를 보여 주지만 보안그룹과 경로 전체를 대신 검증하지는 않으므로 이 값 하나로 네트워크 안전을 결론내리지 않았다.

RDS와 EBS를 따로 봤다

조사 대상 RDS는 모두 저장 암호화가 활성화돼 있었고 공개 접근 설정도 꺼져 있었다.
AWS 문서에 따르면 암호화된 RDS 인스턴스는 기본 스토리지뿐 아니라 로그, 자동 백업, 읽기 복제본과 스냅샷도 암호화 범위에 포함된다.

EBS에는 암호화된 볼륨과 일부 미암호화 레거시 볼륨이 함께 있었다.
여기서 미암호화 볼륨을 곧바로 개인정보 원본 저장소라고 판정하지 않았다.

코드와 영속 경로를 확인한 결과 이 볼륨들은 상품 카탈로그용 검색 데이터, 암호화된 RDS를 원본으로 사용하는 애플리케이션과 터널 데몬 등에 연결돼 있었다.
당시 조사 범위에서 미암호화 레거시 EBS는 개인정보 원본 저장소로 분류되지 않았다.

검색 색인도 데이터이므로 보호가 필요 없다는 뜻은 아니다.
원본이 아니어도 재생성 비용, 포함 필드의 민감도와 접근 경로에 따라 암호화 우선순위가 달라질 수 있다.

자동화 서버는 실행 이력을 짧은 기간만 보존하도록 제한한 보완통제도 확인했다.
보존기간 제한은 데이터가 남는 시간을 줄이지만 저장 암호화를 대체하지는 않는다.

신규 자산부터 같은 문제가 반복되지 않게 했다

기존 볼륨을 조사하기 전에 계정과 리전 수준의 EBS 기본 암호화를 활성화한 기록이 있었다.
이 설정은 이후 생성되는 EBS 볼륨과 스냅샷 복사본이 기본 KMS 키로 암호화되게 한다.

KMS는 Key Management Service의 약자로 AWS 서비스가 암호화에 사용할 키를 만들고 권한과 사용 기록을 관리하는 서비스다.
기본 키 대신 별도의 고객 관리형 키를 지정할 수도 있지만 키 정책, 비용과 운영 책임도 함께 생긴다.

어떤 키를 쓸지는 “더 강한 암호화”의 문제가 아니라 누가 키의 수명과 권한을 관리해야 하는지의 문제다.

특정 규정이나 계정 분리 요구가 없다면 고객 관리형 키를 무조건 늘리는 것이 답은 아니다.

키를 잃거나 정책을 잘못 좁히면 암호화된 데이터도 읽지 못할 수 있으므로 복구 책임까지 감당할 수 있는지 보고 선택한다.

aws ec2 enable-ebs-encryption-by-default
aws ec2 get-ebs-encryption-by-default

첫 번째 명령은 현재 계정의 현재 리전에서 EBS 기본 암호화를 켠다.
리전별 설정이므로 여러 리전을 사용한다면 각 리전에서 별도로 확인해야 한다.

두 번째 명령은 설정 상태를 읽어 변경이 유지되는지 검증한다.
실제 작업에서는 활성화 후 상태를 다시 조회해 예방 통제가 적용됐는지 확인했다.

AWS 문서가 명확히 밝히듯 이 설정은 기존 미암호화 볼륨을 자동으로 바꾸지 않는다.
예방 통제가 켜졌다는 사실과 과거 자산의 개선이 끝났다는 사실을 같은 완료 조건으로 쓰면 안 된다.

기존 볼륨은 스위치 하나로 바뀌지 않았다

기존 미암호화 EBS 볼륨은 암호화 상태를 그 자리에서 바꿀 수 없다.
스냅샷을 만들고 암호화된 복사본에서 새 볼륨을 생성한 뒤 애플리케이션을 새 볼륨으로 전환해야 한다.

이 과정에는 쓰기 중지 시점, 파일시스템 일관성, 마운트 경로, 부팅 설정, 롤백과 서비스 중단 시간을 검토해야 한다.
모든 볼륨을 같은 날 일괄 교체하지 않고 데이터 민감도와 중단 영향을 기준으로 일정을 나눈 이유다.

RDS도 생성된 미암호화 DB 인스턴스의 암호화를 바로 켤 수는 없다.
공식 문서는 스냅샷을 만든 뒤 암호화된 사본을 생성하고 그 스냅샷에서 새 DB 인스턴스를 복원하는 방법을 안내한다.

위 절차는 공식적으로 가능한 일반 경로다.
이번 작업은 조사 대상의 암호화 상태와 데이터 경로를 감사하고, 신규 기본 암호화라는 예방 통제를 확인한 뒤 레거시 자산의 우선순위와 종료 조건을 확정하는 데서 닫았다.

위험수용은 아무것도 하지 않는다는 문서가 아니었다

위험수용은 당장 변경할 때 생기는 서비스 영향과 현재 데이터 위험을 비교해 일정 기간 남은 위험을 받아들이는 결정이다.
책임자, 근거, 보완통제, 재검토 시점과 종료 조건이 없으면 단순한 미조치 목록과 다르지 않다.

이번에는 신규 볼륨의 재발을 기본 암호화로 막고, 기존 미암호화 볼륨은 데이터 분류와 다운타임을 기준으로 별도 관리했다.
미암호화 볼륨이 개인정보 원본 저장소가 아니라는 근거와 실제 영속 경로도 함께 남겼다.

증적에는 다음을 분리해 적었다.

1. 특정 날짜에 API로 확인한 EBS와 RDS의 설정 상태를 남겼다.
2. 코드와 서버 메타데이터로 실제 저장 데이터의 종류를 분류했다.
3. 기본 암호화가 신규 자산에만 적용된다는 범위를 적었다.
4. 기존 자산마다 즉시 전환하지 않는 이유와 보완통제를 적었다.
5. 후속 조치의 책임자, 검토 시점과 암호화 전환 완료 조건을 남겼다.

로그 보존도 같은 방식으로 설정과 목적을 함께 봐야 한다.
관련 사례는 CloudWatch 로그를 같은 기간으로 지우지 않은 이유에 정리했다.

감사 결과와 완료 범위

조사 대상 RDS는 모두 저장 암호화 상태였고 공개 접근 설정이 꺼져 있었다.
EBS에는 암호화된 볼륨과 일부 미암호화 레거시 볼륨이 함께 있었다.

미암호화 레거시 EBS는 코드와 영속 경로를 교차 확인해 데이터 성격과 전환 영향을 분류했다.
신규 EBS 기본 암호화와 자동화 실행 이력의 짧은 보존기간은 재발과 잔존 데이터 위험을 줄이는 예방·보완 통제로 확인했다.

데이터 흐름이 바뀌면 분류도 달라질 수 있으므로 자산 목록과 데이터 소유자를 주기적으로 다시 확인해야 한다.
레거시 자산은 소유자, 전환 순서, 롤백 조건과 재검토 시점을 갖춰야 하며 암호화된 대체 볼륨으로 전환하고 원본을 안전하게 폐기했을 때 종료한다.

암호화된 저장소라는 사실도 애플리케이션 권한 오남용, 공개된 자격 증명과 전송 중 노출을 막아 주지는 않는다.
파일 업로드 권한의 다른 경계는 S3 직접 업로드의 보안 범위에서 다뤘다.

저장 암호화는 디스크나 스냅샷이 별도로 노출됐을 때 내용을 보호하는 계층이다.

정상 권한으로 접속한 애플리케이션은 데이터를 복호화해 읽을 수 있으므로 IAM 최소 권한, 네트워크 제한, 전송 구간 암호화와 애플리케이션 감사 로그를 별도로 유지해야 한다.

저장 암호화 감사를 다시 할 때 확인할 목록

1. 모든 사용 리전에서 RDS, EBS, 스냅샷과 연결된 인스턴스 목록을 수집한다.
2. 암호화 설정과 KMS 키 식별자는 원본 증적에 남기되 공개 문서에서는 가린다.
3. 애플리케이션 코드, 마운트와 데이터 디렉터리로 실제 영속 경로를 확인한다.
4. 개인정보 원본, 파생 데이터, 재생성 가능한 색인과 임시 데이터를 구분한다.
5. 백업, 스냅샷, 로그와 읽기 복제본까지 암호화 범위에 포함되는지 확인한다.
6. 신규 기본 암호화를 리전별로 켜고 상태를 다시 조회한다.
7. 기존 미암호화 볼륨은 스냅샷, 새 볼륨, 전환과 롤백 계획을 서비스별로 세운다.
8. 위험수용에는 보완통제, 책임자, 만료일과 종료 조건을 적는다.
9. 데이터 흐름이 바뀌면 이전의 “민감정보 없음” 판정을 다시 검토한다.

설정표에서 데이터 흐름으로 내려가야 우선순위가 보였다

미암호화 레거시 EBS가 있다는 사실은 중요한 시작점이었지만 최종 위험 판정은 아니었다.
RDS와 EBS 설정, 코드와 실제 영속 경로를 맞춰 보니 어떤 자산이 원본을 보관하고 어떤 자산이 재생성 가능한 데이터를 다루는지 나눌 수 있었다.

감사는 자산의 설정과 데이터 흐름을 확인하는 데서 끝내지 않고, 신규 기본 암호화라는 예방 통제와 레거시 자산의 전환 우선순위·소유자·종료 조건까지 확정했다.
컴플라이언스에서 필요한 것은 초록색 설정 화면 하나가 아니라 적용 범위, 남은 예외와 끝낼 방법을 함께 설명하는 증거였다.

참고 자료

• Amazon EBS 암호화
• EBS 기본 암호화 활성화 API
• 기존 미암호화 EBS 리소스를 암호화하는 방법
• Amazon RDS 리소스 암호화
• Amazon RDS DB 스냅샷 복사와 암호화
• AWS KMS 키 유형과 선택