Amazon SCS-C02: 암호화, KMS 및 시크릿 — 학습 가이드

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

AWS KMS 키 유형, 정책 및 액세스 제어

AWS KMS는 크게 세 가지 키 카테고리를 지원하며, 어떤 키를 선택하느냐에 따라 누가 키 물질(key material)을 제어하고, 어디에 저장되며, 어떻게 교체할 수 있는지가 결정됩니다. AWS 소유 키는 사용자에게 보이지 않고 비용이 들지 않으며, SSE-S3를 활성화할 때 S3와 같은 서비스에서 사용됩니다. AWS 관리형 키(별칭 aws/<service>)는 서비스가 사용자를 대신하여 암호화하도록 허용하지만, 키 정책을 수정할 수 없어 교차 계정 액세스나 세분화된 거버넌스에는 적합하지 않습니다. 고객 관리형 키(CMK)는 핵심적인 역할을 합니다. 사용자가 키 정책, (연간 자동 또는 온디맨드) 교체, 권한 부여(grant), 별칭, 삭제 대기 기간을 모두 제어할 수 있습니다.

두 가지 특수한 변형이 중요합니다. 가져온 키 물질은 규제 또는 BYOK(Bring Your Own Key) 요구 사항으로 인해 AWS 외부에서 키 물질을 생성하여 KMS 키로 가져와야 할 때 사용됩니다. 가져온 키 물질은 키 물질의 명시적 만료를 구성할 수 있는 유일한 방법입니다. AWS에서 생성된 CMK는 만료되지 않습니다. 가져온 키에는 AWS 연간 자동 교체를 활성화할 수 없으며, 사용자가 직접 키 물질을 다시 가져와야 합니다. 다중 리전 키는 복제본 키를 통해 여러 리전에서 동일한 키 ID와 키 물질을 공유하므로, us-east-1에서 생성된 암호문(ciphertext)을 재암호화 없이 us-west-1에서 복호화할 수 있습니다. 각 복제본은 독립적인 키 정책과 별칭을 가지지만, 암호화 물질은 동기화됩니다.

가장 많이 오해받는 제어 기능은 KMS 키 정책입니다. IAM 정책만으로 액세스 권한을 부여하는 대부분의 AWS 리소스와 달리, KMS 키는 키 정책을 루트 권한 부여 수단으로 사용합니다. 키에 대한 kms:Decrypt 권한을 부여하는 IAM 정책은 키 정책이 (계정 루트를 Principal로 지정하고 적절한 구문을 추가하거나, principal을 직접 명시하여) IAM에 액세스 권한을 위임하지 않는 한 효력이 없습니다. 이것이 AdministratorAccess 권한을 가진 엔지니어도 계정을 신뢰하지 않는 CMK 정책에 대해 Decrypt를 호출할 때 AccessDenied를 받을 수 있는 이유입니다. 표준적인 위임 구문은 다음과 같습니다.

{
  "Sid": "EnableIAMPermissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Grant와 ViaService 조건은 계층적인 제약을 추가합니다. 예를 들어, kms:ViaService: s3.us-east-1.amazonaws.com을 사용하여 특정 리전의 S3를 통해서만 키를 사용하도록 강제할 수 있습니다.

서버 측 및 클라이언트 측 암호화

S3의 경우, 두 가지 일반적인 서버 측 옵션은 주로 제어 및 감사 가능성에서 차이가 있습니다.

SSE-S3 (AES-256): S3가 키를 완전히 관리합니다. 고객에게 보이는 키 정책, 키별 CloudTrail 복호화 이벤트, 교차 계정 거버넌스가 없습니다. 유휴 데이터에 대한 기본 암호화에는 적합하지만, 누가 데이터를 복호화했는지 증명해야 하는 규정 준수 요구 사항에는 불충분합니다.
SSE-KMS: 사용자가 제어하는 CMK를 사용합니다. 모든 복호화 호출이 기록되고, 키 정책이 액세스를 강제하며, 암호화 컨텍스트(encryption context)로 제한할 수 있습니다. 요청당 비용이 더 비싸고 KMS TPS 할당량을 소모하므로, KMS 호출을 크게 줄이려면 버킷 키(BucketKeyEnabled: true)를 활성화해야 합니다.

AWS Encryption SDK를 사용한 클라이언트 측 암호화는 데이터가 애플리케이션을 떠나기 전에 암호화되어야 하거나, 스토리지 서비스가 평문(plaintext)을 절대 볼 수 없어야 할 때 적합합니다. 처리량이 많은 워크로드에서는 SDK를 캐싱 암호화 자료 관리자(CachingCryptoMaterialsManager)로 래핑해야 합니다. 이는 구성 가능한 바이트, 메시지, TTL 한도 내에서 여러 메시지에 걸쳐 데이터 키를 재사용합니다. 캐싱이 없으면 모든 encrypt 호출이 GenerateDataKey 요청을 유발하여 KMS 요청 할당량을 빠르게 소진시키고 비용을 증가시킵니다.

from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
    master_key_provider=mkp, cache=cache,
    max_age=600.0, max_messages_encrypted=10000)

Secrets Manager 및 Parameter Store

Secrets Manager는 KMS CMK로 암호화된 자격 증명을 저장하며, Lambda 함수를 통해 자동 교체를 지원합니다. AWS는 RDS, Redshift, DocumentDB용 템플릿을 제공하며, 사용자 지정 Lambda로 그 외 모든 것을 처리할 수 있습니다. 교체는 4단계 상태 머신(createSecret, setSecret, testSecret, finishSecret)을 실행하여 새 자격 증명을 AWSCURRENT로 승격하기 전에 AWSPENDING 레이블 아래에 준비(stage)합니다. 애플리케이션은 인증 실패를 감지하고, 보안 암호를 새로 고친 후 재시도해야 합니다. 이 패턴은 이전 자격 증명이 AWSPREVIOUS를 통해 잠시 동안 유효하게 유지되기 때문에 다운타임을 없애줍니다.

교체 Lambda가 VPC 내부에서 실행될 때(일반적으로 프라이빗 RDS 인스턴스에 접근하기 위해), Secrets Manager 서비스 엔드포인트에 대한 아웃바운드 네트워크 액세스가 필요합니다. NAT가 없는 프라이빗 VPC에서는 인터페이스 VPC 엔드포인트(com.amazonaws.<region>.secretsmanager)를 배포하고 Lambda의 보안 그룹이 443 포트를 통해 엔드포인트에 도달하도록 허용해야 합니다. 이를 잊는 것은 전형적인 실패 사례입니다. 교체가 구성된 것처럼 보이지만 모든 호출이 시간 초과됩니다.

리전 간 복원력을 위해서는 다중 리전 KMS 키와 Secrets Manager의 보안 암호 복제본 기능을 사용하세요. us-east-1의 기본 보안 암호는 기본 CMK로 암호화되고, us-west-1의 복제본은 복제본 CMK를 사용하여 복호화됩니다. alias/prod-db와 같은 별칭은 애플리케이션 코드를 변경하지 않고도 신속한 키 교체를 위해 온디맨드로 새 키 ID를 가리키도록 할 수 있습니다.

Parameter Store의 SecureString 타입은 교체가 필요 없을 때 사용할 수 있는 가벼운 대안입니다. 두 서비스 모두 CloudFormation에서 동적 참조({{resolve:secretsmanager:MySecret:SecretString:password}})를 제공하므로 스택 템플릿에 평문(plaintext)이 포함되지 않도록 합니다.

EBS, RDS, Aurora 및 스냅샷 암호화

유휴 데이터 암호화는 생성 시 볼륨 또는 인스턴스별로 활성화되며, 기존 리소스에 바로 적용하거나 해제할 수 없습니다. 규정을 준수하지 않는 미암호화 리소스에 대한 해결 패턴은 암호화를 적용한 스냅샷 복사입니다.

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region us-east-1 --encrypted \
  --kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...

RDS 및 Aurora의 경우, 암호화된 스냅샷을 새 인스턴스로 복원한 후 전환합니다. 교차 계정 복구를 위해서는 스냅샷을 공유하고 또한 키 정책을 통해 대상 계정에 CMK에 대한 kms:CreateGrant 및 kms:Decrypt 권한을 부여해야 합니다. 대상 계정이 데이터 키를 복호화할 수 없으므로 스냅샷만 공유하면 실패합니다. 계정 수준 EBS 기본 암호화를 활성화하여 호출자의 동작과 관계없이 새로 생성되는 볼륨이 항상 암호화되도록 해야 합니다.

TLS: ACM 및 ALB 정책

ACM은 ALB, CloudFront, API Gateway와 같은 통합 서비스에 연결될 때 공개 인증서를 무료로 발급하고 자동 갱신합니다. 인증서는 내보낼 수 없으므로, EC2에서 TLS를 종료하려면 내보낼 수 있는 사설 인증서를 위한 ACM Private CA 또는 **가져온 인증서(imported certificate)**가 필요합니다. 실용적인 패턴은 ACM 인증서를 사용하여 ALB에서 퍼블릭 TLS를 종료하고, 종단 간 암호화가 필요한 경우 ALB-EC2 구간에는 자체 서명 인증서나 사설 CA 인증서를 사용하는 것입니다. ELBSecurityPolicy-TLS13-1-2-2021-06과 같은 보안 정책을 사용하여 클라이언트가 최신 암호화 스위트를 사용하도록 강제할 수 있습니다. 이 정책은 TLS 1.0/1.1 및 취약한 스위트를 비활성화합니다.

일반적인 함정

키 정책 없는 IAM. CMK의 키 정책에서 계정 보안 주체(account principal)를 생략한 채 IAM 정책에서 kms:Decrypt 권한을 부여하면 AccessDenied 오류가 발생합니다. KMS는 키 정책을 신뢰의 기준으로 삼으며, IAM 권한은 키 정책이 허용하는 범위를 더 제한하는 것만 가능합니다.

VPC 엔드포인트 없는 교체 Lambda. Lambda가 프라이빗 서브넷에서 실행되고 VPC에 NAT 및 secretsmanager 인터페이스 엔드포인트가 없는 경우, secretsmanager.<region>.amazonaws.com으로의 교체 호출은 주소를 확인하거나 연결할 수 없습니다. 또한 엔드포인트의 보안 그룹은 Lambda의 보안 그룹으로부터의 443 포트 인바운드를 허용해야 합니다.

SSE-S3와 SSE-KMS의 혼동. SSE-S3는 고객이 편집할 수 있는 정책이 없고, CloudTrail에 객체별 복호화 로깅이 남지 않으며, 계정 간 키 공유가 불가능한 AWS 소유 키를 사용합니다. 이는 “저장 시 암호화(encrypt at rest)” 요구사항은 충족하지만, 어떤 보안 주체가 특정 객체를 복호화할 수 있는지 강제할 수는 없습니다. 오직 CMK를 사용하는 SSE-KMS만이 그러한 거버넌스를 제공합니다.

실제 문제: 사용 사례 시나리오

시나리오: Meridian Financial은 보안 계정, 별도의 Prod/NonProd 계정, ECS/EKS의 ALB 기반 마이크로서비스, RDS/Aurora 클러스터, EBS 기반 EC2 인스턴스, S3 데이터 레이크를 갖춘 다중 계정 AWS Organization을 운영하고 있습니다. 현재 개발자와 자동화 시스템은 AWS 관리형 키, 평문 SSM 파라미터, 그리고 계정 간 수동 스냅샷 공유를 혼용하여 사용하고 있습니다.

과제: 한 엔지니어가 실수로 암호화되지 않은 RDS 스냅샷을 서드파티 계정에 공유했고, 여러 API 자격 증명이 평문 SecureString 파라미터로 저장된 것이 발견되어 데이터 유출 및 무단 복원 액세스의 위험이 발생했습니다.

권장 접근 방식:

보안 계정에 조직 범위의 고객 관리형 AWS KMS 대칭 CMK를 생성하고, aws:PrincipalOrgID를 통해 멤버 계정에 사용 권한을 부여하는 키 정책을 설정하며, 자동 교체를 활성화합니다. 단기적인 계정 간 작업에는 권한 부여(grant)를 사용합니다.
암호화되지 않은 RDS 스냅샷과 모든 EBS 스냅샷을 복사할 때 새 CMK를 선택하여 암호화된 사본을 생성한 후, 원본 암호화되지 않은 스냅샷을 삭제하여 기존 아티팩트를 개선합니다. 계정 기본값을 설정하여 새로운 RDS 및 EBS가 기본적으로 암호화된 리소스를 생성하도록 합니다.
보안 정보를 CMK로 암호화하여 AWS Secrets Manager(또는 SSM Parameter Store SecureString)로 마이그레이션하고, Lambda를 통해 DB 자격 증명에 대한 Secrets Manager 자동 교체를 활성화하며, 리소스 기반 정책과 최소 권한 IAM 역할을 사용하여 액세스를 제한합니다.
ACM 관리형 TLS 인증서를 프로비저닝하고 최신 TLS 정책(TLS 1.2/1.3)과 함께 ALB에 연결하여 전송 중 암호화를 강제하고, 데이터베이스와 클라이언트가 TLS 연결을 요구하도록 구성합니다.
가드레일을 통해 재발을 방지합니다: 서비스 제어 정책(SCP)을 적용하여 암호화되지 않은 스냅샷의 생성/공유 및 암호화되지 않은 S3 객체 생성을 거부하고, 암호화된 리소스에 대한 AWS Config 규칙을 활성화하며, CloudTrail 및 CloudWatch 경보를 통해 KMS 및 Secrets Manager 사용량을 모니터링합니다.

근거: 조직 수준 정책을 갖춘 중앙 CMK, 자동화된 재암호화, 보안 정보 라이프사이클 관리를 위한 Secrets Manager, TLS 강제 적용, 예방적 가드레일은 AWS의 최소 권한 및 심층 방어(defense-in-depth) 모범 사례를 따르는 것으로, 평문 보안 정보와 무단 스냅샷 액세스를 제거합니다.

고객 관리형 CMK: 다중 리전, 가져온 키 구성 요소, 그리고 키 정책

고객 관리형 CMK는 AWS에 있는 사용자 소유 데이터에 대한 모든 암호화 작업의 제어 플레인입니다. 설계의 성공 또는 장애 발생 여부를 결정하는 가장 일반적인 세 가지 속성은 키의 리전 토폴로지, 키 구성 요소의 원본, 그리고 키에 연결된 정책입니다.

다중 리전 키는 서로 다른 리전에 있는 KMS 키들의 집합으로, 동일한 키 ID와, 결정적으로 동일한 기본 키 구성 요소를 공유합니다. 이 키들은 DynamoDB 글로벌 테이블처럼 자동으로 복제되지 않으며, ReplicateKey를 사용하여 기본 키로부터 명시적으로 복제본을 생성해야 합니다. 키 구성 요소가 모든 복제본에서 동일하기 때문에, us-east-1에서 생성된 암호문은 리전 간 KMS 호출 없이 us-west-1에서 복호화할 수 있습니다. 이는 Secrets Manager 보안 암호를 여러 리전에 복제할 때 필요한 바로 그 속성입니다. 즉, 장애 조치 리전의 복제본 보안 암호는 모든 GetSecretValue 호출 시 리전 간 지연 시간을 없애고 기본 리전의 장애로부터 살아남기 위해 로컬에서 복호화가 가능해야 합니다. 단일 리전 CMK는 다른 리전의 Secrets Manager 복제본을 지원할 수 없으므로, 올바른 패턴은 다중 리전 CMK로 기본 보안 암호를 암호화하고, 대상 리전으로 키를 복제한 다음, 복제본 CMK를 가리키도록 하여 보안 암호를 복제하는 것입니다.

aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
  --replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
  --secret-id prod/db \
  --add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123

가져온 키 구성 요소(외부 원본, Origin=EXTERNAL)는 원시 AES-256 구성 요소를 AWS 외부에서 생성하여 KMS 키 셸로 가져올 때 존재합니다. AWS는 HSM의 보호된 메모리 외부에는 해당 구성 요소의 복사본을 절대 가지지 않으며, 백업도 없습니다. 만약 DeleteImportedKeyMaterial을 통하거나 만료일이 지나 가져온 키 구성 요소를 삭제하면, 키는 PendingImport 상태가 되고 해당 키로 생성된 모든 암호문은 정확히 동일한 바이트를 다시 가져오지 않는 한 복구할 수 없습니다. 이것이 예를 들어, 암호화된 데이터 키를 복호화할 수 없어 EBS 볼륨 연결에 실패했을 때의 복구 경로입니다. 오프라인 에스크로에서 동일한 키 구성 요소를 다시 가져오면 볼륨을 다시 사용할 수 있게 됩니다. 삭제된 가져온 키 구성 요소를 복구할 수 있는 AWS 측 복원, 교체 트릭, 또는 지원 티켓은 없습니다. 오프라인 복사본을 티어-제로 인프라로 취급해야 합니다.

키 정책은 모든 KMS 키에 대한 신뢰의 루트입니다. IAM만 사용하는 것과 달리, KMS는 키 정책 자체에 명시적인 허용을 요구합니다. kms:Decrypt를 부여하는 IAM 정책은 키 정책이 IAM에 위임하지 않는 한("Principal": {"AWS": "arn:aws:iam::111122223333:root"}와 조건문 결합) 효과가 없습니다. 교차 계정 사용의 경우, 키의 정책은 외부 계정이나 보안 주체를 명시적으로 지정해야 하며, 그 다음 외부 계정은 IAM을 통해 자신의 사용자에게 권한을 부여해야 합니다. 키 정책 측면을 잊는 것은 교차 계정 Secrets Manager 실패의 가장 흔한 단일 원인입니다. 즉, Secrets Manager 리소스 정책은 외부 보안 주체가 GetSecretValue를 호출하도록 허용하지만, CMK가 여전히 호출자를 거부하기 때문에 기본 Decrypt 작업이 실패합니다.

Secrets Manager 및 Parameter Store SecureString 패턴

Secrets Manager와 SSM Parameter Store SecureString은 모두 암호화를 KMS에 위임하지만, 비용, 교체 시맨틱, 그리고 교차 리전 동작에서 차이가 있습니다. Secrets Manager는 네이티브 다중 리전 복제, 스테이징 레이블(AWSCURRENT, AWSPENDING)을 사용한 버전 관리, 그리고 Lambda 기반 교체를 지원합니다. Parameter Store SecureString은 더 저렴하고, 계층적 경로와 잘 통합되며, 자주 교체되지 않는 설정 스타일의 보안 암호에 적합합니다.

교차 계정 액세스를 위해서는 보안 암호의 리소스 정책(또는 Parameter Store 소비자 계정의 IAM 정책) 과 암호화 CMK의 KMS 키 정책을 모두 업데이트해야 합니다. Secrets Manager 권한만으로 충분하다고 가정하는 것은 잘못입니다. 왜냐하면 검색 워크플로는 항상 CMK에 대해 암시적인 kms:Decrypt를 수행하기 때문입니다. 외부 계정에 대한 키 정책의 허용이 없으면, 보안 암호 자체의 정책이 충족되더라도 호출자는 Decrypt 단계에서 AccessDeniedException을 받게 됩니다.

Secrets Manager: 관리형 교체, JSON 구조, 보안 암호당 월 ~$0.40, 다중 리전 복제 내장
Parameter Store SecureString (고급): 많은 값에 대해 더 저렴, 파라미터당 8KB, 내장된 교차 리전 복제 기능 없음
Parameter Store SecureString (표준): 최대 4KB의 KMS 암호화 파라미터에 대한 프리 티어, 교체 프레임워크 없음

봉투 암호화(Envelope Encryption), 버킷 키, 그리고 권한 부여 토큰(Grant Token)

봉투 암호화(Envelope Encryption)는 KMS가 대량의 데이터를 직접 다루지 않음을 의미합니다. GenerateDataKey를 호출하면 평문 데이터 키(로컬에서 AES-GCM으로 페이로드를 암호화하는 데 사용)와 암호화된 데이터 키 사본(암호문과 함께 저장)이 모두 반환됩니다. 복호화하려면 래핑된(wrapped) 데이터 키에 대해 Decrypt를 호출하고 로컬에서 평문 키를 다시 생성합니다. 이 패턴은 KMS가 API 호출당 과금되고 리전별, 키별 요청 할당량을 가지고 있기 때문에 필수적입니다. 만약 각 4KB 레코드를 직접 Encrypt 호출로 암호화하면 쓰로틀링과 비용 급증에 직면하게 됩니다. 배치당 또는 파일당 하나의 데이터 키를 생성하면 처리량은 로컬 암호화 라이브러리에 따라 선형적으로 확장됩니다.

S3 버킷 키는 SSE-KMS를 위해 S3 내부에서 동일한 원칙을 적용합니다. 버킷 키가 없으면 SSE-KMS 객체에 대한 모든 PUT 및 GET 요청이 GenerateDataKey 또는 Decrypt 호출을 생성합니다. 초당 수천 개의 객체를 수신하는 버킷에서는 이로 인해 KMS 쓰로틀링과 예상치 못한 KMS 요금이 발생할 수 있습니다. 버킷 키를 활성화하면 S3가 버킷 수준에서 수명이 짧은 키를 하나 생성하고 이를 여러 객체에 재사용하여 KMS 요청량을 수십 배 이상 줄일 수 있습니다:

aws s3api put-bucket-encryption --bucket app-data \
  --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
      "BucketKeyEnabled":true}]}'

**권한 부여(Grant)**는 임시적이고 세분화된 위임을 위한 키 정책의 대안입니다. 최종 일관성 때문에 운영상 중요합니다. CreateGrant가 반환된 후, 권한 부여가 리전 내 모든 KMS 엔드포인트에 즉시 보이지 않을 수 있습니다. 클라이언트가 몇 밀리초 후에 Encrypt를 시도하면 AccessDeniedException을 받을 수 있습니다. CreateGrant의 응답 본문에는 GrantToken 문자열이 포함되어 있으며, 이 토큰을 후속 KMS 호출 시 --grant-tokens 파라미터를 통해 전달하면 KMS가 전파 상태와 관계없이 즉시 해당 권한 부여를 적용하도록 강제할 수 있습니다.

TOKEN=$(aws kms create-grant --key-id $KEY \
  --grantee-principal arn:aws:iam::111122223333:role/worker \
  --operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
  --grant-tokens "$TOKEN"

권한 부여 토큰 대신 백오프를 사용한 재시도에 의존하는 것은 유효하지만 차선책입니다. 이는 지연 시간을 낭비하고 부하가 높을 때 여전히 실패할 수 있습니다. 가장 정석적인 해답은 항상 다음과 같습니다: 권한 부여를 생성하는 서비스에서 권한 부여 토큰을 반환하고, 호출자가 첫 번째 작업에서 이 토큰을 제시하도록 요구하는 것입니다.

실전 문제: 사용 사례 시나리오

시나리오: Meridian Financial은 다중 계정 AWS 환경을 운영하며, S3에 고객 PII(개인 식별 정보)를, RDS에 트랜잭션 데이터베이스를, Lambda를 통해 서버리스 처리를 호스팅하고 있습니다. 이들은 지역별 키 보관 규칙을 충족하기 위해 가져온 키 구성 요소를 사용하는 고객 관리형 CMK를 사용하며, 재해 복구(DR)를 위해 키를 두 번째 리전으로 복제합니다.

과제: 최근 감사에서 교차 계정 복호화를 허용하는 잘못 구성된 KMS 키 정책이 발견되었으며, 외부 감사인이 S3 객체의 일부를 복호화하기 위한 임시 액세스 권한이 필요합니다. 또한 Meridian은 KMS 요청 비용을 제어하기 위해 안전한 보안 암호 순환과 대용량 객체의 효율적인 암호화가 필요합니다.

권장 접근 방식:

AWS KMS에서 잘못 구성된 CMK 정책을 필요한 IAM 보안 주체 및 역할에만 명시적으로 권한을 부여하는 최소 권한 정책으로 교체하고, KMS 다중 리전 키를 사용하여 DR을 위한 다중 리전 복제 CMK를 생성합니다.
규정 준수 기간에 따라 가져온 키 구성 요소에 대한 수명 주기 관리를 재가져오거나 예약하고, AWS Config와 EventBridge를 사용하여 자동 키 구성 요소 만료/순환 알림을 활성화합니다.
감사인을 위해 짧은 TTL을 가진 KMS 권한 부여를 생성하고, 감사인의 assume-role 세션에서 즉시 권한 부여 토큰을 사용하여 키 정책을 변경하지 않고 임시 복호화 작업을 허용합니다.
수명이 긴 자격 증명은 기본 서비스(RDS 또는 API 키)에 연결된 Lambda 기반 순환 기능을 갖춘 AWS Secrets Manager로 이전하고, 순환되지 않는 항목에 대한 인프라 파라미터는 Systems Manager Parameter Store SecureString으로 저장하며, CMK를 사용한 암호화와 엄격한 리소스 기반 정책을 강제합니다.
애플리케이션 코드나 AWS SDK를 통해 KMS GenerateDataKey(Encrypt/Decrypt)를 호출하여 대용량 S3 객체에 대한 봉투 암호화를 구현하고, S3 버킷 키를 활성화하여 대용량 객체의 서버 측 암호화에 대한 KMS 요청 및 비용을 줄입니다.
CloudTrail 로깅 및 KMS 키 사용량 로깅을 활성화하고, CloudWatch 경보/GuardDuty 규칙을 생성하여 예상치 못한 복호화 또는 권한 부여 생성 시 경고하도록 합니다.

근거: 이 접근 방식은 최소 권한의 키 액세스를 강제하고, 가져온 키 구성 요소에 대한 규정 준수와 다중 리전 연속성을 보존하며, 안전한 서드파티 액세스를 위해 임시 권한 부여를 사용하고, 순환 기능을 통해 보안 암호를 중앙에서 관리하며, AWS 모범 사례에 따라 KMS 사용량과 비용을 최적화합니다.

← 로깅 · 모든 도메인 · 데이터 보호 및 S3 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

시험 합격하기 →

Amazon 찾아보기 →