보안·암호화·거버넌스

AWS KMS — 키를 누가 쥐는가 SAA 빈출

AWS Key Management Service(KMS)는 암호화 키를 만들고 보관하고 사용을 통제하는 서비스입니다. SAA에서 KMS가 중요한 이유는 암호 알고리즘 때문이 아닙니다. 키에 대한 접근 권한이 곧 데이터에 대한 접근 권한이 되므로, KMS 키 하나가 버킷 정책이나 보안 그룹과 같은 수준의 접근 통제 장치가 되기 때문입니다.

키 종류 세 가지

KMS API는 키의 관리 주체를 KeyManager 값으로 AWS와 CUSTOMER 두 가지로만 표현합니다. 실무와 시험에서 쓰는 구분은 여기에 AWS 소유 키를 더한 세 가지입니다. 차이는 하나입니다 — 키 정책을 우리가 편집할 수 있는가입니다.

봉투 암호화와 데이터 키

KMS는 큰 데이터를 직접 암호화하지 않습니다. KMS의 Encrypt 작업은 API 문서에 명시된 대로 최대 4,096바이트까지만 처리합니다. 데이터베이스 비밀번호나 식별자 정도가 그 크기입니다.

그래서 실제 암호화는 두 겹으로 이뤄집니다. KMS에게 데이터 키(data key)를 만들어 달라고 하면 GenerateDataKey가 평문 데이터 키와 KMS 키로 암호화된 데이터 키를 함께 돌려줍니다. 애플리케이션은 평문 데이터 키로 데이터를 암호화한 뒤 평문 키를 메모리에서 지우고 암호문 키를 데이터 옆에 저장합니다. 이 구조가 봉투 암호화(envelope encryption)입니다.

# 1) 평문 데이터 키와 암호화된 데이터 키를 함께 받습니다.
aws kms generate-data-key \
  --key-id alias/app-data \
  --key-spec AES_256 \
  --encryption-context purpose=invoice-archive \
  --query '{plaintext:Plaintext,wrapped:CiphertextBlob}'

# 2) Plaintext 로 파일을 암호화하고, 그 값은 즉시 버립니다.
# 3) CiphertextBlob 만 암호문 옆에 보관합니다.

# 복호화할 때는 보관해 둔 CiphertextBlob 을 KMS 에 되돌려 평문 키를 받습니다.
aws kms decrypt \
  --ciphertext-blob fileb://wrapped-data-key.bin \
  --encryption-context purpose=invoice-archive \
  --query 'Plaintext'

예제의 --encryption-context는 암호화할 때 지정한 값과 대소문자까지 정확히 같은 값을 복호화할 때 다시 줘야 합니다. 다르면 요청이 거부됩니다. 키 정책의 조건 키로도 쓸 수 있어서 "이 컨텍스트로만 복호화를 허용한다"는 통제를 만들 수 있습니다.

키 정책과 IAM 정책 — 두 개가 함께 결정한다

KMS 키에는 키 정책(key policy)이라는 리소스 기반 정책이 반드시 하나 붙어 있습니다. 여기가 2장에서 다룬 리소스 기반 정책과 다른 점이 하나 있습니다. 키 정책이 비어 있으면 IAM 정책만으로는 키를 쓸 수 없습니다. 키 정책이 먼저 계정이나 주체에게 권한 위임을 열어 줘야 IAM 정책이 의미를 갖습니다.

접근을 결정하는 장치는 실제로 세 겹입니다.

• 키 정책 — 키에 붙는 정본. 누가 이 키를 쓸 수 있는지의 출발점입니다.
• IAM 정책 — 키 정책이 계정에 위임한 범위 안에서 주체별로 좁힙니다.
• 권한 부여(grant) — API 문서가 "키 정책 · IAM 정책과 함께 고려된다"고 명시하는 임시 권한 수단입니다. AWS 서비스가 우리 대신 키를 쓸 때 주로 만들어지며, 만들고 쓰고 지우는 동안 키 정책을 건드리지 않아도 됩니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMPoliciesForAdmins",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowApplicationRoleToUseTheKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/InvoiceServiceRole"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:purpose": "invoice-archive"
        }
      }
    }
  ]
}

첫 번째 문장이 계정 루트를 주체로 쓰는 것은 루트 사용자에게 권한을 준다는 뜻이 아니라, 이 계정의 IAM 정책이 키에 대해 발언권을 갖도록 위임한다는 관용 표현입니다. 이 문장을 빼면 키를 만든 사람 외에는 아무도 키를 관리할 수 없게 되고, 키 정책을 잘못 저장하면 되돌릴 방법이 사라집니다.

키 교체

KMS의 자동 교체는 키 재료(key material)를 새로 만들고 이전 재료를 보관하는 방식입니다. 키 ID와 ARN, 별칭은 그대로이므로 애플리케이션은 아무것도 바꾸지 않아도 되고, 예전 재료로 암호화된 데이터도 계속 복호화됩니다.

자동 교체에는 범위 제한이 있습니다. API 문서는 대칭 암호화 KMS 키에서만 지원되며 비대칭 키 · HMAC 키 · 키 재료를 가져온(imported) 키 · 사용자 지정 키 스토어의 키에는 자동 교체를 켤 수 없다고 명시합니다. 키 재료를 직접 가져온 키는 새 재료를 다시 가져오는 방식으로 교체합니다.

키 삭제는 되돌릴 수 없다

ScheduleKeyDeletion은 즉시 삭제하지 않고 대기 기간을 둡니다. API 문서 기준으로 기본 30일이며 7일에서 30일 사이로 지정할 수 있습니다. 대기 중에는 키 상태가 PendingDeletion이 되어 어떤 암호화 작업에도 쓸 수 없고, 기간이 끝나기 전이면 취소할 수 있습니다.

기간이 지나 실제로 삭제되면 그 키로 암호화된 데이터는 복구할 수 없습니다. 그래서 "키를 지워 데이터를 무력화한다"는 것이 규정 준수 시나리오의 정답이 되기도 하고, 반대로 사고의 원인이 되기도 합니다. 단순히 쓰지 못하게 막는 것이 목적이라면 삭제가 아니라 DisableKey가 맞습니다.

다중 리전 키와 별칭

기본적으로 KMS 키는 단일 리전 자원이며 리전 밖으로 나가지 않습니다. 그래서 리전 A에서 암호화한 데이터를 리전 B에서 읽으려면 보통 복호화 후 재암호화가 필요합니다. 다중 리전 키(multi-Region key)는 이 왕복을 없애기 위한 예외입니다.

• 기본 키를 MultiRegion=true로 만들고 ReplicateKey로 다른 리전에 복제본을 만듭니다. 같은 파티션 안에서만 복제됩니다.
• 기본 키와 복제본은 키 ID와 키 재료가 같습니다. 그래서 한 리전에서 암호화한 데이터를 재암호화나 리전 간 호출 없이 다른 리전에서 복호화할 수 있습니다.
• 키 정책은 리전마다 따로 둘 수 있습니다. 공유되는 것은 키 ID · 키 재료 · 키 스펙 · 용도 · 재료 출처 · 자동 교체 상태입니다.
• 이 값은 생성 후 바꿀 수 없습니다. 단일 리전 키를 나중에 다중 리전 키로 승격할 수 없습니다.

별칭(alias)은 키에 붙이는 사람이 읽을 수 있는 이름입니다. 계정과 리전 안에서 고유하고, 키 하나에 여러 별칭을 붙일 수 있으며, 별칭이 가리키는 키를 나중에 바꿀 수도 있습니다. 코드에 키 ID 대신 alias/app-data를 쓰면 키를 교체해도 코드를 고치지 않아도 됩니다.

AWS CloudHSM과의 차이

AWS CloudHSM은 전용 하드웨어 보안 모듈을 우리 VPC 안에 배치하는 서비스입니다. KMS와 겹쳐 보이지만 판단 기준은 명확합니다 — 규정이 "단독 점유 HSM"이나 "AWS도 접근할 수 없는 키"를 요구하는가입니다.

KMS 키의 재료 출처(Origin)에 AWS_CLOUDHSM과 EXTERNAL_KEY_STORE가 있는 것이 이 연결 관계를 보여 줍니다. 즉 둘은 대체재라기보다, CloudHSM을 KMS 뒤에 두는 조합이 실제 구성입니다.

저장 데이터 암호화 — 서비스별 선택지

"저장 데이터를 암호화한다"는 요구는 거의 모든 서비스에서 만족시킬 수 있습니다. 그래서 문항은 암호화 여부가 아니라 어떤 방식으로 암호화하는가를 갈림길로 씁니다. 기준은 두 가지입니다 — 키를 누가 쥐는가와 키 사용 증적이 남는가입니다.

Amazon S3의 네 가지 서버 측 암호화

다른 서비스의 암호화 옵션

AWS Certificate Manager — 인증서를 어디에 붙이는가

AWS Certificate Manager(ACM)는 퍼블릭 TLS 인증서를 발급하고 자동으로 갱신합니다. SAA에서 ACM이 나오는 자리는 거의 언제나 전송 중 암호화와 TLS 종료 지점입니다.

발급과 검증

퍼블릭 인증서를 요청하면 도메인 소유를 증명해야 합니다. API 문서가 인정하는 방법은 DNS 검증과 이메일 검증이며, AWS는 DNS 검증을 권장합니다. DNS 검증은 지정된 CNAME 레코드를 도메인에 한 번 넣어 두면 이후 갱신도 자동으로 이뤄지기 때문입니다. Amazon Route 53을 쓰면 레코드 생성까지 콘솔에서 처리됩니다. 프라이빗 CA로 발급하는 프라이빗 인증서는 도메인 검증이 필요하지 않습니다.

aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names '*.example.com' \
  --validation-method DNS \
  --query 'CertificateArn'

# 검증에 필요한 CNAME 레코드를 확인합니다.
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-2:123456789012:certificate/EXAMPLE \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'

TLS 종료 지점과 CloudFront의 리전 제약

인증서는 요청을 받는 지점에 붙습니다. 이 지점에서 TLS가 종료되고, 그 뒤 구간은 별도로 설계합니다.

Secrets Manager와 Parameter Store — 자동 교체가 기준이다

두 서비스는 겹치는 부분이 넓습니다. 둘 다 값을 KMS로 암호화해 저장하고, 둘 다 IAM으로 접근을 통제하며, 둘 다 애플리케이션이 런타임에 값을 가져오게 합니다. 그래서 시험은 겹치지 않는 지점 하나로 갈림길을 만듭니다.

# 교체가 필요한 자격 증명 — Secrets Manager
aws secretsmanager create-secret \
  --name prod/orders/db \
  --secret-string '{"username":"app","password":"REPLACE_ME"}'

aws secretsmanager rotate-secret \
  --secret-id prod/orders/db \
  --rotation-lambda-arn arn:aws:lambda:ap-northeast-2:123456789012:function:RotateDbSecret \
  --rotation-rules AutomaticallyAfterDays=30

# 교체가 필요 없는 설정값 — Parameter Store
aws ssm put-parameter \
  --name /prod/orders/feature-flags/new-checkout \
  --type String \
  --value enabled \
  --tier Standard

위협 탐지 서비스 — 무엇을 입력으로 읽는가 SAA 빈출

네 서비스는 이름이 비슷해서 외우려 들면 계속 헷갈립니다. 구분하는 확실한 방법은 각 서비스가 무엇을 입력으로 읽는가를 보는 것입니다. 입력이 다르면 답할 수 있는 질문도 다릅니다.

AWS WAF와 AWS Shield — 규칙인가 디도스인가

둘 다 "웹을 보호한다"고 설명되지만 막는 대상이 다릅니다. AWS WAF는 요청 하나하나의 내용을 보고, AWS Shield는 트래픽의 양과 형태를 봅니다.

WAF와 CloudFront·Route 53을 엮은 엣지 계층 전체 구성은 14장 엣지와 DNS에서 다룹니다. 이 장에서는 어느 계층의 무엇을 막는 장치인가만 확실히 해 둡니다.

애플리케이션 사용자와 디렉터리

2장에서 정리한 세 갈래 — 직원이면 AWS IAM Identity Center, 앱 사용자면 Amazon Cognito, 사람이 아니면 IAM 역할 — 중 두 번째와 그 주변을 여기서 마무리합니다.

Amazon Cognito — 사용자 풀과 자격 증명 풀

Cognito는 이름이 하나지만 서로 다른 일을 하는 두 개의 구성 요소입니다. 이 둘을 뭉뚱그려 이해하면 문항에서 반드시 걸립니다.

AWS Directory Service

Microsoft Active Directory가 관련된 요구는 Cognito도 IAM Identity Center도 아닌 AWS Directory Service로 갑니다. 대표 선택지는 세 가지입니다.

여기서 갈림길은 사용자를 어디에 두는가입니다. AWS 안에 디렉터리를 두면 Managed Microsoft AD, 온프레미스에 그대로 두고 참조만 하면 AD Connector입니다.

흔한 오해

시험 포인트 정리

이 장의 주제는 전부 보안 아키텍처 설계(30%)에 속합니다.

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 이 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 2장 · IAM과 자격 증명 키 정책이 왜 리소스 기반 정책의 예외처럼 동작하는지는 정책 평가 로직과 결합 규칙을 알아야 이해됩니다. 기본개념 · SAA 최우선
• 17장 · 모니터링·운영·계정 관리 이 장에서 예고한 CloudTrail과 AWS Config의 구분, 그리고 조직 단위 거버넌스를 정면으로 다룹니다. 기본개념
• 8장 · S3와 오브젝트 스토리지 버킷 정책, 퍼블릭 액세스 차단, Object Lock까지 포함한 S3 쪽 데이터 보안 제어의 본체입니다. 기본개념
• 14장 · 엣지와 DNS WAF와 Shield가 붙는 CloudFront와 Route 53 계층을 구성 단위로 봅니다. 오리진 보호(OAC)도 여기서. 기본개념
• 도메인 1 · 보안 아키텍처 설계 (30%) 과제 진술 1.1~1.3의 판단 지점 18개와 이 장의 대응 관계를 한눈에 확인합니다. 시험 대비 · 최우선
• 실습 11 · KMS 고객 관리형 키로 암호화 키 정책을 직접 쓰고 봉투 암호화를 손으로 한 번 돌려 보면 이 장의 절반이 정리됩니다. 실습
• 케이스 10 · 규정 준수 감사에 대응하라 CloudTrail, Config, Object Lock, KMS, 데이터 레지던시를 하나의 요구사항 묶음으로 설계합니다. 아키텍처 케이스
• 보안 빠른참조 IAM 정책 패턴과 암호화 옵션 매트릭스를 표 한 장으로 모았습니다. 시험 직전 복습용입니다. 빠른참조

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

• AWS KMS API 레퍼런스 — GenerateDataKey — 평문 데이터 키와 암호화된 데이터 키를 함께 반환한다는 서술, 봉투 암호화의 근거
• AWS KMS API 레퍼런스 — Encrypt — 최대 4,096바이트 제한과 암호화 컨텍스트의 동작
• AWS KMS API 레퍼런스 — EnableKeyRotation — 고객 관리형 키의 기본 1년 주기와 RotationPeriodInDays, AWS 관리형 키의 연 1회 교체, 자동 교체가 지원되지 않는 키 종류
• AWS KMS API 레퍼런스 — ScheduleKeyDeletion — 대기 기간 기본 30일, 7~30일 지정 가능, 삭제 후 복구 불가
• AWS KMS API 레퍼런스 — ReplicateKey — 다중 리전 키가 같은 키 ID와 키 재료를 공유하며 재암호화 없이 다른 리전에서 복호화된다는 서술
• AWS KMS API 레퍼런스 — CreateGrant — 권한 부여가 키 정책·IAM 정책과 함께 고려된다는 서술
• AWS KMS API 레퍼런스 — CreateAlias — 별칭의 고유성 범위와 키 하나에 여러 별칭을 붙일 수 있다는 서술
• AWS KMS API 레퍼런스 — CreateKey — MultiRegion의 기본값과 변경 불가 성질, 키 재료 출처(Origin) 값
• AWS Key Management Service 개발자 안내서 — 개요 — 키 종류와 키 정책의 개념
• AWS Certificate Manager API 레퍼런스 — RequestCertificate — DNS 검증과 이메일 검증, DNS 검증 권장, 프라이빗 인증서의 검증 면제
• AWS Certificate Manager API 레퍼런스 — ExportCertificate — 퍼블릭 인증서 내보내기 지원과 2025년 6월 17일 기준 제약
• Amazon CloudFront API 레퍼런스 — ViewerCertificate — CloudFront가 us-east-1의 ACM 인증서만 지원한다는 서술
• AWS Secrets Manager API 레퍼런스 — RotateSecret — 자동 교체의 동작과 AWSCURRENT·AWSPENDING 준비 라벨
• AWS Systems Manager API 레퍼런스 — PutParameter — 파라미터 유형(String·StringList·SecureString)과 계층
• Amazon GuardDuty 사용 설명서 — GuardDuty란 — VPC 플로우 로그·CloudTrail·DNS 로그 등 기반 데이터 소스 목록
• Amazon Inspector 사용 설명서 — Inspector란 — EC2·ECR·Lambda를 대상으로 하는 취약점 검색 서비스라는 정의
• Amazon Macie 사용 설명서 — Macie란 — Amazon S3의 민감 데이터 발견과 분류
• AWS Security Hub 사용 설명서 — Security Hub란 — 여러 계정·서비스·서드파티 제품의 결과를 모아 표준에 대조한다는 서술
• AWS WAF API 레퍼런스 — CreateWebACL — 웹 ACL 범위 CLOUDFRONT·REGIONAL과 CloudFront 범위의 us-east-1 제약
• AWS WAF API 레퍼런스 — AssociateWebACL — CloudFront 외의 리소스에 웹 ACL을 연결하는 방식
• AWS WAF 및 AWS Shield 개발자 안내서 — AWS Shield — Shield Standard와 Shield Advanced의 구분
• AWS Network Firewall 개발자 안내서 — Network Firewall이란 — VPC 수준 트래픽 검사의 위치
• Amazon Cognito 개발자 안내서 — Amazon Cognito란 — 사용자 풀과 자격 증명 풀의 역할 구분
• Amazon Cognito Identity API 레퍼런스 — 자격 증명 풀이 신뢰할 수 없는 환경에 범위가 제한된 임시 자격 증명을 전달한다는 서술
• AWS Directory Service 관리 안내서 — Directory Service란 — Managed Microsoft AD · AD Connector · Simple AD의 구분
• AWS CloudHSM 사용 설명서 — 소개 — 전용 HSM 클러스터의 성격과 KMS 사용자 지정 키 스토어 연동
• Amazon S3 사용 설명서 — 서버 측 암호화 — SSE-S3 · SSE-KMS · DSSE-KMS · SSE-C의 구분
• Amazon S3 사용 설명서 — 기본 암호화 FAQ — 모든 신규 객체가 SSE-S3로 자동 암호화된다는 서술