AWS KMS 완전 이해: S3 버킷 암호화에 AWS 관리형 키 vs CMK, 어떤 걸 써야 할까?

S3 버킷에 암호화를 적용하려고 콘솔을 열었을 때, 'AWS 관리형 키(aws/s3)'와 '고객 관리형 키(CMK)' 두 가지 선택지 앞에서 멈춰본 경험이 있을 것이다. 단순히 '암호화만 되면 되는 거 아닌가?'라고 생각했다가, 나중에 KMS API 호출 비용 청구서를 받고 당황하거나, 감사 요건을 충족하지 못해 다시 설계를 뒤집는 상황이 실제로 발생한다. AWS KMS 키 유형 선택은 보안 정책, 운영 복잡도, 비용 모두에 직접적인 영향을 미친다.

TL;DR: AWS 관리형 키 vs 고객 관리형 키 (CMK) 핵심 비교

항목 AWS 관리형 키 (aws/s3) 고객 관리형 키 (CMK)
키 생성 주체 AWS가 자동 생성 사용자가 직접 생성
키 정책 제어 불가 (AWS 관리) 완전 제어 가능
키 로테이션 제어 AWS 자동 관리 (1년) 사용자 설정 가능
교차 계정 접근 불가 키 정책으로 허용 가능
월 키 관리 비용 무료 키당 월 $1 (대칭 키 기준)
API 호출 비용 발생 (요청당 과금) 발생 (요청당 과금)
CloudTrail 감사 제한적 모든 키 사용 이벤트 기록
Bucket Key 지원 지원 지원

AWS KMS가 S3 암호화에서 동작하는 방식

S3의 SSE-KMS 암호화는 봉투 암호화(envelope encryption) 구조로 동작한다. S3가 객체를 저장할 때 KMS에 데이터 키(data key) 생성을 요청하고, 반환된 평문 데이터 키로 객체를 암호화한 뒤, 암호화된 데이터 키만 객체 메타데이터에 함께 저장한다. 복호화 시에는 KMS를 다시 호출해 암호화된 데이터 키를 복호화한 후 객체를 읽는다. 즉, S3 객체 PUT/GET마다 KMS API 호출이 발생하며, 이것이 비용과 직결된다.

sequenceDiagram participant Client as 클라이언트 participant S3 as Amazon S3 participant KMS as AWS KMS Client->>S3: PUT Object 요청 S3->>KMS: GenerateDataKey (CMK ARN 지정) KMS-->>S3: 평문 데이터 키 + 암호화된 데이터 키 반환 S3->>S3: 평문 키로 객체 암호화 후 평문 키 폐기 S3->>S3: 암호화된 데이터 키를 객체 메타데이터에 저장 S3-->>Client: 200 OK Client->>S3: GET Object 요청 S3->>KMS: Decrypt (암호화된 데이터 키 전달) KMS-->>S3: 평문 데이터 키 반환 S3->>S3: 평문 키로 객체 복호화 S3-->>Client: 복호화된 객체 반환
  1. PUT 요청: S3가 KMS에 GenerateDataKey 호출 → KMS가 평문 키 + 암호화된 키 반환
  2. 암호화 저장: S3가 평문 키로 객체 암호화 후, 암호화된 데이터 키를 메타데이터에 저장. 평문 키는 즉시 폐기.
  3. GET 요청: S3가 KMS에 Decrypt 호출 → 복호화된 데이터 키로 객체 복호화 후 반환
  4. Bucket Key 활성화 시: 버킷 수준 데이터 키를 캐싱해 KMS 호출 횟수를 대폭 줄임

AWS 관리형 키 (aws/s3): 언제 충분한가

AWS 관리형 키는 AWS가 해당 서비스 전용으로 자동 생성하고 관리하는 키다. S3의 경우 aws/s3라는 별칭으로 계정당 리전별로 하나씩 존재한다. 키 정책을 수정하거나 삭제할 수 없고, 로테이션 주기도 AWS가 결정한다.

규정 준수 요건이 없고, 교차 계정 접근이 필요 없으며, 키 사용에 대한 세밀한 감사 로그가 필요하지 않은 경우라면 AWS 관리형 키로 충분하다. 별도의 키 관리 오버헤드 없이 저장 데이터 암호화 요건을 빠르게 충족할 수 있다.

단, AWS 관리형 키도 KMS API 호출 비용은 발생한다. '무료'라는 인식은 키 관리 비용(월 $1)이 없다는 의미이지, API 호출 비용까지 면제되는 게 아니다.

고객 관리형 키 (CMK): 언제 반드시 필요한가

다음 조건 중 하나라도 해당된다면 CMK를 써야 한다.

  • 교차 계정 접근: 다른 AWS 계정의 IAM 엔티티가 이 버킷의 객체를 읽어야 하는 경우. AWS 관리형 키는 키 정책 수정이 불가능해 교차 계정 접근을 허용할 수 없다.
  • 세밀한 접근 제어: 특정 IAM 역할만 복호화를 허용하거나, 특정 조건(예: VPC 엔드포인트 경유)에서만 키 사용을 허용해야 하는 경우.
  • 감사 및 규정 준수: CloudTrail에서 누가 언제 어떤 키로 어떤 작업을 했는지 추적해야 하는 규정(예: PCI-DSS, HIPAA) 환경.
  • 키 비활성화 또는 삭제 제어: 특정 사고 발생 시 즉시 키를 비활성화해 데이터 접근을 차단해야 하는 경우.
  • 가져온 키 자료(Imported Key Material): 조직 내부 HSM에서 생성한 키 자료를 사용해야 하는 경우.
CMK는 '더 강한 암호화'가 아니라 '더 많은 제어권'을 의미한다. 암호화 강도 자체는 AWS 관리형 키와 동일하게 AES-256이다.

AWS KMS 비용 구조 이해

KMS 비용은 크게 두 가지로 나뉜다. 정확한 수치는 리전과 시점에 따라 변동되므로, 반드시 AWS KMS 공식 요금 페이지에서 확인해야 한다.

1. 키 관리 비용

  • AWS 관리형 키: 무료
  • 고객 관리형 키 (대칭): 키당 월 $1 (AWS 공식 문서 기준, 리전별 상이할 수 있음)
  • 고객 관리형 키 (비대칭): 키 유형에 따라 상이 — 공식 요금 페이지 확인 필수

2. API 호출 비용

S3 SSE-KMS에서 발생하는 주요 KMS API 호출은 GenerateDataKey(PUT 시)와 Decrypt(GET 시)다. 두 API 모두 요청 건수 기준으로 과금된다. 트래픽이 높은 S3 버킷에서 Bucket Key를 활성화하지 않으면 KMS 호출 비용이 예상보다 크게 발생할 수 있다.

graph TD A["S3 SSE-KMS 비용 구조"] --> B["키 관리 비용"] A --> C["API 호출 비용"] B --> D["AWS 관리형 키
월 $0 (무료)"] B --> E["CMK (대칭 키)
키당 월 $1"] C --> F["GenerateDataKey
(PUT 요청마다)"] C --> G["Decrypt
(GET 요청마다)"] F --> H["Bucket Key 비활성화
객체 수 = KMS 호출 수"] F --> I["Bucket Key 활성화
KMS 호출 수 대폭 감소"] G --> H G --> I

S3 Bucket Key 활성화 확인 및 비용 최적화

S3 Bucket Key는 버킷 수준에서 단기 데이터 키를 캐싱해 KMS API 호출 횟수를 줄이는 기능이다. 객체마다 KMS를 호출하는 대신, 버킷 키를 통해 로컬에서 데이터 키를 생성하므로 KMS 요청 수가 대폭 감소한다. AWS 관리형 키와 CMK 모두에서 사용할 수 있다.

현재 버킷의 Bucket Key 활성화 여부를 확인하려면:

aws s3api get-bucket-encryption \
  --bucket my-example-bucket

CMK를 사용해 Bucket Key를 활성화하며 버킷 암호화를 설정하는 예시:

🔽 CMK + Bucket Key 활성화 CLI 예시 (클릭하여 펼치기) 
aws s3api put-bucket-encryption \
  --bucket my-example-bucket \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/your-cmk-key-id"
        },
        "BucketKeyEnabled": true
      }
    ]
  }'

AWS 관리형 키(aws/s3)에 Bucket Key를 적용하려면, 먼저 아래 명령으로 해당 키의 ARN을 조회한 후, 그 ARN을 KMSMasterKeyID 값으로 명시해야 한다.

aws kms describe-key \
  --key-id alias/aws/s3 \
  --query 'KeyMetadata.Arn' \
  --output text

반환된 ARN을 put-bucket-encryption의 KMSMasterKeyID에 지정하고 BucketKeyEnabled: true를 함께 설정하면 된다.

CMK 생성 및 S3 버킷 암호화 적용 실전 절차

CMK를 직접 생성하고 S3 버킷에 적용하는 전체 흐름이다. 각 단계는 독립적으로 검증 가능하도록 구성했다.

Step 1: CMK 생성

키 정책 없이 기본값으로 생성하면 키 생성자(루트 계정)만 키를 관리할 수 있다. 실제 운영 환경에서는 반드시 키 정책을 명시적으로 정의해야 한다.

aws kms create-key \
  --description "S3 encryption key for my-example-bucket" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS

반환된 KeyMetadata.KeyId 값을 메모해 둔다.

Step 2: 키 별칭 생성 (선택 사항이지만 강력 권장)

ARN 대신 별칭으로 키를 참조하면 키 로테이션이나 교체 시 애플리케이션 코드 변경 없이 별칭만 업데이트할 수 있다.

aws kms create-alias \
  --alias-name alias/my-s3-bucket-key \
  --target-key-id YOUR_KEY_ID

Step 3: S3 버킷에 CMK 암호화 적용

aws s3api put-bucket-encryption \
  --bucket my-example-bucket \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/YOUR_KEY_ID"
        },
        "BucketKeyEnabled": true
      }
    ]
  }'

Step 4: IAM 정책 — 최소 권한 원칙 적용

S3 버킷에 객체를 쓰는 IAM 역할에는 KMS GenerateDataKey 권한이, 읽는 역할에는 Decrypt 권한이 필요하다. 두 권한을 모든 역할에 부여하지 말고 역할별로 분리하는 것이 원칙이다.

🔽 S3 쓰기 역할용 IAM 정책 예시 (클릭하여 펼치기) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3KMSEncrypt",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKey",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/YOUR_KEY_ID"
    }
  ]
}
🔽 S3 읽기 역할용 IAM 정책 예시 (클릭하여 펼치기) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3KMSDecrypt",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/YOUR_KEY_ID"
    }
  ]
}

실제 운영에서 마주치는 함정: 'AccessDenied' 오류의 진짜 원인

CMK로 암호화된 S3 버킷에서 AccessDenied가 발생했을 때, 대부분의 엔지니어는 S3 버킷 정책부터 확인한다. 버킷 정책에 해당 역할의 s3:GetObject가 명시되어 있으면 '왜 안 되지?'라는 생각이 든다.

실제 원인은 KMS 키 정책에 있는 경우가 많다. S3 버킷 정책과 IAM 정책 모두 올바르게 설정되어 있어도, KMS 키 정책에 해당 IAM 역할의 kms:Decrypt가 허용되어 있지 않으면 S3는 복호화 단계에서 실패하고 AccessDenied를 반환한다. 오류 메시지만 봐서는 KMS 문제인지 S3 문제인지 구분이 안 된다.

CloudTrail에서 eventSource: kms.amazonaws.com, eventName: Decrypt, errorCode: AccessDenied 로그를 확인하는 것이 가장 빠른 진단 방법이다.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --query 'Events[?contains(CloudTrailEvent, `AccessDenied`)].CloudTrailEvent'

KMS 키 정책은 IAM 정책과 독립적으로 평가된다. IAM 정책에서 허용하더라도 키 정책에서 명시적으로 허용하지 않으면 접근이 거부된다 — 이것이 KMS 키 정책의 기본 동작 방식이다.

키 유형 선택 의사결정 가이드

graph TD Start(["S3 버킷 암호화 키 선택"]) --> Q1{"교차 계정 접근
필요?"} Q1 -->|예| CMK["CMK 필수"] Q1 -->|아니오| Q2{"키 정책
커스터마이징 필요?"} Q2 -->|예| CMK Q2 -->|아니오| Q3{"규정 준수 감사
(PCI-DSS, HIPAA 등)?"} Q3 -->|예| CMK Q3 -->|아니오| Q4{"키 비활성화/삭제
즉시 제어 필요?"} Q4 -->|예| CMK Q4 -->|아니오| AWS_Managed["AWS 관리형 키 (aws/s3)
충분"] CMK --> BucketKey1["Bucket Key 활성화 권장"] AWS_Managed --> BucketKey2["Bucket Key 활성화 권장"]

AWS KMS와 S3 암호화: 마무리 및 다음 단계

AWS KMS를 활용한 S3 버킷 암호화에서 키 유형 선택의 핵심은 '제어 필요성'이다. 교차 계정 접근, 세밀한 감사, 키 정책 커스터마이징이 필요하다면 CMK를 선택하고, 그렇지 않다면 AWS 관리형 키로 충분하다. 어떤 키 유형을 선택하든 Bucket Key 활성화는 비용 최적화를 위해 기본으로 적용하는 것이 좋다.

다음 단계로 고려할 사항:

  • 기존 S3 버킷의 암호화 설정 현황을 AWS S3 암호화 공식 문서를 참고해 점검한다.
  • KMS 키 로테이션 정책을 조직의 보안 정책에 맞게 설정한다.
  • CloudTrail과 AWS Config를 연동해 키 사용 패턴과 규정 준수 여부를 지속적으로 모니터링한다.
  • 비용 최적화를 위해 AWS Cost Explorer에서 KMS API 호출 비용을 주기적으로 검토한다.

핵심 용어 정리

용어 설명
SSE-KMS AWS KMS 키를 사용하는 S3 서버 측 암호화 방식. SSE-S3(S3 관리 키)와 구분된다.
봉투 암호화 (Envelope Encryption) 데이터를 데이터 키로 암호화하고, 데이터 키 자체를 마스터 키로 암호화하는 이중 구조.
Bucket Key S3 버킷 수준에서 단기 데이터 키를 캐싱해 KMS API 호출 횟수를 줄이는 S3 기능.
키 정책 (Key Policy) KMS CMK에 대한 접근을 제어하는 리소스 기반 정책. IAM 정책과 독립적으로 평가된다.
GenerateDataKey KMS가 평문 데이터 키와 암호화된 데이터 키 쌍을 생성해 반환하는 API. S3 PUT 시 호출된다.

Related Posts

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...
자세한 내용 보기

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...
자세한 내용 보기