
서비스가 지원하는 키 종류를 먼저 확인한 뒤, 정책과 키 수명주기를 직접 통제해야 하는지로 선택하세요. 고객 관리형 키는 통제 범위가 넓어지는 만큼 비용과 운영 책임도 생깁니다. 암호화를 켰다는 사실만으로 복구 가능한지까지 확인된 것은 아닙니다.
원인: 키의 소유와 운영 책임을 구분하지 않는다
AWS 문서는 고객 관리형, AWS 관리형, AWS 소유 키를 구분합니다. 고객 관리형은 계정에서 만들고 관리하는 키입니다. AWS 관리형은 연동 서비스가 계정에서 생성·관리하며, AWS 소유 키는 계정의 키 목록에서 직접 관리하는 유형이 아닙니다. 선택 가능한 조합은 사용하는 서비스에서 다시 확인해야 합니다.
| 검토 질문 | 관리형부터 검토 | 고객 관리형 검토 |
| 서비스 기본 운영으로 충분한가 | 지원 옵션 확인 | 추가 통제 필요성 확인 |
| 키 정책을 직접 설계해야 하나 | 제약 확인 | 권한 설계·검토 필요 |
| 키 수명주기를 통제해야 하나 | 서비스 관리 범위 확인 | 담당자·복구 절차 지정 |
1. 데이터와 키를 함께 찾을 수 있는 표를 만든다
새 저장소를 검토할 때 데이터 위치, 서비스, 리전, 실제 키 식별자, 읽는 역할을 한 표에 적어 보세요. 이 표는 권장 검토 형식이며 실제 계정에서 추출한 목록은 아닙니다. “기본 키 사용”이라는 문장만 남기면 담당자가 바뀌었을 때 어느 설정을 확인할지 알기 어렵습니다.
현재 연결이 정상이어도 복구 환경의 역할과 접근 조건이 다르면 같은 결과를 기대할 수 없습니다. 따라서 도입 승인에는 쓰기 경로뿐 아니라 복구 후 읽기 경로의 담당자도 포함합니다. 이 글은 특정 규정 충족이나 보안 인증을 판정하지 않습니다.
2. 회전과 새 키 교체를 구분한다
기존 KMS 키의 키 재료를 회전하는 것과 새 키를 만든 뒤 애플리케이션이 그 키를 사용하도록 바꾸는 것은 다른 작업입니다. AWS 문서에서 자동·온디맨드 회전의 지원 유형과 조건을 확인하세요. 모든 키가 같은 회전 방식을 지원한다고 일반화하지 않습니다.
검토 문서에는 “무엇이 바뀌는가”, “이전 데이터는 어떻게 읽는가”, “변경을 어떻게 확인하는가”를 따로 적습니다. 운영 키에 회전·비활성화·삭제 명령을 시험 삼아 실행하지 마세요.
3. 도입 전 복호화 확인 범위를 합의한다
승인된 시험 데이터로 정상 쓰기·읽기와 복구 경로를 검증하는 계획을 세우세요. 담당 역할이 바뀌거나 복구 환경이 달라질 때도 필요한 접근을 설명할 수 있어야 합니다. 실패 결과를 권한 부족 하나로 단정하기 전에 대상 데이터와 키를 정확히 지정했는지부터 확인합니다.
비용과 복구 시 주의
고객 관리형 키는 보유와 요청 사용에 비용이 생길 수 있습니다. 정확한 금액은 적용 리전·키 유형·요청량에 맞춰 공식 요금에서 별도로 산정하세요. 가격을 이유로 기존 키를 바로 정리하지 말고 어떤 데이터가 그 키에 의존하는지 먼저 파악합니다.
변경 전 키 식별자와 정책·연결 설정을 승인된 보관소에 기록하고, 수정 권한과 검토자를 정합니다. 저장된 정책 사본이 있다는 이유만으로 모든 데이터 복구가 보장된다고 표현해서도 안 됩니다. 실제 복구 시험은 이 글에서 수행하지 않았습니다.
FAQ
고객 관리형이 항상 필요한가요? 서비스 지원 범위와 필요한 통제 수준·운영 역량에 따라 판단합니다.
회전은 새 키로 설정을 옮기는 것과 같나요? 서로 다른 변경이므로 계획과 검증을 구분합니다.
키 목록만 있으면 복구가 되나요? 데이터·역할·접근 조건을 함께 확인해야 합니다.
공식 출처와 관련 글
자료 확인일: 2026년 10월 21일. 문서 기반 설계 안내이며 AWS 배포·성능·요금 실측은 수행하지 않았습니다.
'소프트웨어개발' 카테고리의 다른 글
| gitignore가 적용되지 않을 때: 추적 파일과 규칙 일치를 따로 확인 (0) | 2026.10.22 |
|---|---|
| SNS와 EventBridge 선택: 구독 알림과 이벤트 라우팅을 구분하는 순서 (0) | 2026.10.22 |
| Git unrelated histories 해결: 원격 주소와 공통 조상부터 확인 (0) | 2026.10.21 |