Day 2 - 암호화: KMS와 서비스별 암호화

KMS 키의 세 종류

데이터는 저장돼 있을 때와 이동할 때 모두 보호돼야 한다. AWS 에서 암호화의 중심에는 KMS(Key Management Service)가 있고, S3·Redshift·Glue 같은 데이터 서비스가 KMS 와 통합돼 키를 쓴다.

• 오래된 자료의 CMK(Customer Master Key) 는 지금의 "KMS 키"를 가리키는 옛 용어다. 시험 지문에는 두 표현이 섞여 나올 수 있다.
• AWS 관리형 키의 자동 교체 주기는 2022년 5월에 3년에서 1년으로 바뀌었다. 옛 자료에는 3년으로 적혀 있다.

봉투 암호화는 실제로 어떻게 도는가

쓰기
 ① 서비스가 KMS 에 GenerateDataKey 요청
 ② KMS 가 데이터 키를 두 형태로 돌려줌: 평문 데이터 키 + KMS 키로 암호화된 데이터 키
 ③ 서비스가 평문 데이터 키로 데이터를 암호화하고, 평문 키는 메모리에서 버림
 ④ 암호문 데이터 + 암호화된 데이터 키를 함께 저장
 
읽기
 ⑤ 서비스가 암호화된 데이터 키를 KMS 에 보내 Decrypt 요청
 ⑥ KMS 가 키 정책을 확인하고 평문 데이터 키를 돌려줌
 ⑦ 서비스가 그 키로 데이터를 복호화

• KMS 키 자체는 KMS 밖으로 나오지 않는다. 밖을 오가는 것은 데이터 키뿐이다.
• 대용량 데이터는 서비스 쪽에서 데이터 키로 암호화하므로, 데이터 전체를 KMS 로 보내는 지연과 비용이 없다.
• 읽는 쪽에 필요한 KMS 권한은 kms:Decrypt, 쓰는 쪽은 kms:GenerateDataKey 다. "S3 권한은 있는데 SSE-KMS 객체를 못 읽는다"는 거의 항상 ⑥에서 막힌 것이다.

💡 관련 이론: KMS 는 데이터 자체를 암호화하지 않고 데이터 키를 관리한다. 그래서 KMS 키를 교체해도 이미 저장된 데이터가 다시 암호화되지 않는다. 바뀌는 것은 앞으로 데이터 키를 감쌀 때 쓰는 키 자료다.

키 정책: KMS 접근의 중심

• 키 정책(Key Policy) 은 KMS 키의 리소스 기반 정책이다. 다른 리소스 정책과 달리, 키 정책은 계정이나 계정 안의 주체에게 자동으로 권한을 주지 않는다.
• 기본 키 정책에는 계정 루트 주체에 kms:* 를 허용하는 문장이 들어 있다. 이 문장이 있어야 IAM 정책으로 키 접근을 허용할 수 있다. 이 문장이 없으면 IAM 정책의 Allow 는 효력이 없다(Deny 는 여전히 효력이 있다).
• 교차 계정은 키를 가진 계정의 키 정책이 상대 계정을 허용하고, 상대 계정의 IAM 정책이 그 키 사용을 허용해야 한다. 양쪽 모두다.
• Grant 는 특정 주체에게 한정된 작업만 위임하는 수단이다. AWS 서비스가 사용자 대신 키를 쓸 때 주로 만든다.

{
  "Sid": "AllowGlueRoleUseOfKey",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/GlueETLRole" },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*"
}

• 키 정책에서 Resource 가 * 인 것은 "이 정책이 붙은 바로 이 키"를 뜻한다. 모든 키가 아니다.
• 특정 서비스를 거친 사용만 허용하려면 kms:ViaService 조건을 쓴다. 예를 들어 S3 를 통해서만 복호화되게 하면, 같은 역할이 KMS API 를 직접 불러 키를 쓰는 길이 막힌다.

교체와 삭제

• 키가 삭제되면 그 키로 암호화한 데이터는 복구할 수 없다. 확신이 없으면 삭제 대신 비활성화한다. 비활성화는 되돌릴 수 있다.
• 대기 기간 중인 키는 암호화 작업에 쓸 수 없다. 누가 아직 그 키를 쓰는지 이 기간에 CloudTrail 과 알람으로 확인한다.
• 교체는 유출된 데이터 키의 피해를 줄여 주지 않는다. 교체가 필요한 이유는 대개 규정·계약이다.

S3 저장 암호화 다섯 가지

• 기본 암호화를 SSE-KMS 로 바꿔도 이미 있는 객체는 그대로다. 기존 객체를 바꾸려면 복사(S3 Batch Operations 등)로 다시 써야 한다.
• SSE-C 는 2026년 4월부터 새 범용 버킷에서 기본으로 차단된다. 쓰려면 버킷의 암호화 설정에서 직접 허용해야 한다. 옛 자료는 SSE-C 를 조건 없이 쓸 수 있는 선택지로 설명한다.
• SSE-C 와 클라이언트 측 암호화 객체는 AWS 서비스가 열어 볼 수 없다. Macie 는 이런 객체의 메타데이터만 보고하고, Athena 같은 서비스로 바로 분석하기도 어렵다.
• 서버 측 암호화(SSE)는 S3 가 받은 뒤 암호화한다. 수신 순간에는 평문이 S3 를 거친다. "AWS 가 평문을 절대 볼 수 없어야 한다"는 요건은 클라이언트 측 암호화만 충족한다.

{
  "ServerSideEncryptionConfiguration": {
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:ap-northeast-2:111122223333:key/abcd-1234"
      },
      "BucketKeyEnabled": true
    }]
  }
}

S3 Bucket Key 의 동작과 부작용

• 버킷 키가 없으면 S3 는 객체마다 KMS 에 데이터 키를 요청한다. 객체 수백만 개를 읽는 ETL 은 KMS 요청 요금과 요청 한도에 걸린다.
• 버킷 키를 켜면 S3 가 KMS 에서 수명이 짧은 버킷 수준 키를 받아 두고, 그 키로 객체별 데이터 키를 만든다. KMS 로 가는 요청이 크게 줄어 요청 비용을 최대 99% 줄일 수 있다.
• KMS 키에 대한 제어는 그대로다. 그래서 "비용은 줄이되 키 통제는 유지"라는 요건에 SSE-S3 전환이 아니라 버킷 키가 답이 된다.

서비스별 암호화 설정 위치

• Redshift: 암호화되지 않은 기존 클러스터도 설정을 바꿔 암호화할 수 있다. 이때 Redshift 가 데이터를 새 암호화 클러스터로 옮긴다. RA3 계열은 진행 중에도 읽기·쓰기가 되지만 DC2 는 읽기만 된다. 옛 자료의 "생성 시에만 가능", "HSM 으로 키 관리"는 현행과 다르다. HSM 연동은 구형 CloudHSM Classic 전용이고 DC2·RA3 노드에서는 지원되지 않는다.
• Redshift 의 고객 관리형 키를 비활성화하면 웨어하우스가 접근 불가 상태가 되고, 14일 안에 키를 복구하지 않으면 삭제된다. 키 운영 실수가 데이터 유실로 이어지는 경로다.
• KMS 키는 리전에 묶인다. Redshift 스냅샷을 다른 리전으로 복사하면서 대상 리전에서 내 키를 쓰려면 대상 리전에 스냅샷 복사 권한 부여(snapshot copy grant) 를 먼저 만든다.
• Glue 보안 구성: CloudWatch 로그를 KMS 로 암호화하려면 키 정책이 로그 서비스 주체를 허용해야 하고, 잡 역할에 logs:AssociateKmsKey 가 있어야 한다. 빠지면 실시간 로깅이 꺼진다. VPC 안에서 도는 잡은 KMS 로 가는 경로(KMS VPC 엔드포인트 또는 NAT)가 없으면 KMS 타임아웃으로 실패한다.
• 보안 구성을 붙이면 잡 파라미터로 넘긴 SSE-S3 설정은 무시된다. 둘이 겹치면 보안 구성이 이긴다.

전송 중 암호화

• AWS API 엔드포인트는 TLS 를 지원한다. 문제는 평문 HTTP 를 허용하느냐다. 버킷 정책에서 aws:SecureTransport 가 false 인 요청을 거부해 강제한다.
• Redshift 는 파라미터 그룹의 require_ssl 로 SSL 연결을 강제한다.

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::lake-curated", "arn:aws:s3:::lake-curated/*"],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}

💡 관련 이론: 저장 중 암호화와 전송 중 암호화는 별개의 보호 계층이다. SSE-KMS 로 저장은 암호화돼도 평문 HTTP 로 전송되면 중간자 공격에 노출된다. 보안 검토 문제에서 "암호화돼 있는데 지적받았다"면 빠진 쪽 계층을 찾는다.

클라이언트 측 암호화

• 데이터가 AWS 로 가기 전에 애플리케이션이 직접 암호화한다. AWS Encryption SDK 나 S3 암호화 클라이언트로 구현한다.
• 데이터 키를 KMS 키로 감쌀 수도 있고(키는 KMS, 암·복호화는 클라이언트), 자체 키를 쓸 수도 있다.
• AWS 는 암호문만 받는다. 가장 강한 기밀성이지만 서버 쪽 기능(서비스의 직접 분석, 민감 데이터 탐지)을 쓰기 어렵고 운영 복잡도가 올라간다.

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 암호화와 권한으로도 막지 못하는 문제, 어디에 민감 데이터가 있는지 찾고(Macie) 노출을 줄이는(마스킹·토큰화) 방법을 다룬다.

📖 용어

• KMS 키 : KMS 안에 머물며 데이터 키를 감싸는 최상위 키. 옛 자료의 CMK 와 같은 것이다.
• 데이터 키 : 실제 데이터를 암호화하는 키. KMS 키로 암호화된 형태로 데이터 옆에 저장된다.
• 봉투 암호화 : 데이터는 데이터 키로, 데이터 키는 KMS 키로 암호화하는 2단 구조.
• 키 정책 : KMS 키에 붙는 리소스 기반 정책. 누가 이 키를 쓰고 관리할 수 있는지 정한다.
• Grant : 특정 주체에게 키의 일부 작업만 위임하는 수단. 주로 AWS 서비스가 대신 쓸 때 만들어진다.
• S3 Bucket Key : S3 가 KMS 에서 받아 잠시 보관하며 객체별 데이터 키를 만드는 버킷 수준 키. KMS 호출을 줄인다.
• 암호화 컨텍스트 : 암호화할 때 함께 묶는 부가 정보. 복호화할 때 같은 값이 있어야 하고 정책 조건으로도 쓴다.
• SSE : 서버 측 암호화. 서비스가 데이터를 받은 뒤 저장하기 전에 암호화한다.
• 보안 구성 : Glue 잡이 쓰는 S3 데이터·로그·북마크의 암호화 방식을 묶어 둔 설정.
• 키 교체 : 키 ID 는 그대로 두고 암호화에 쓰는 키 자료만 새로 만드는 일.