이 페이지에서는 Cloud de Confiance 리소스에서 고객 관리 암호화 키 (CMEK)를 사용하여 저장 데이터 암호화를 구성하는 방법에 대한 권장사항을 설명합니다. 이 가이드는 클라우드 설계자와 보안팀을 대상으로 하며 CMEK 아키텍처를 설계하면서 따라야 하는 권장사항과 의사결정에 대해 설명합니다.
이 가이드에서는 사용자가 Cloud Key Management Service(Cloud KMS) 및 고객 관리 암호화 키에 익숙하다고 가정합니다.CMEK 사용 위치 선택
클라우드에서 내 데이터 또는 고객 데이터 주위에 암호화 경계를 설정하려면 고객 관리 암호화 키를 사용하는 것이 좋습니다. 자세한 내용은 고객 관리 암호화 키 (CMEK)를 참고하세요.
호환되는 서비스에서 CMEK를 사용하여 다음 목표를 구현할 수 있습니다.암호화 키를 소유합니다.
암호화 키의 위치 선택, 보호 수준, 생성, 액세스 제어, 순환, 사용, 폐기 등을 제어하고 관리합니다.
Cloud KMS에서 키 자료를 생성하거나 Cloud de Confiance외부에서 유지보수되는 키 자료를 가져옵니다.
키를 사용해야 하는 위치와 관련된 정책을 설정합니다.
오프보딩 시 키로 보호되는 데이터를 선택적으로 삭제하거나 보안 이벤트(암호화 파쇄)를 해결합니다.
고객별로 고유한 키를 만들어서 사용하고 데이터에 대한 암호화 경계를 설정합니다.
암호화 키에 대한 관리 및 데이터 액세스를 로깅합니다.
이러한 목표를 요구하는 현재 또는 미래의 규정을 준수합니다.
또한 비즈니스 요구사항에 적용되는 규정 준수 프레임워크를 고려하는 것이 좋습니다. 각 규정 준수 프레임워크에는 암호화 및 키 관리에 대해 서로 다른 요구사항이 포함되어 있습니다. 규정 준수 프레임워크에는 일반적으로 대략적인 원칙과 암호화 키 관리 목표가 기술되어 있지만 규정 준수를 달성하기 위한 특정 제품 또는 구성이 명시되지 않습니다. 규정 준수 프레임워크의 요구사항을 파악하고 키 관리를 포함하여 이러한 요구사항을 충족하는 방법은 사용자가 선택해야 합니다.
Cloud de Confiance 서비스를 사용하여 다양한 규정 준수 프레임워크의 요구사항을 충족하는 방법에 관한 안내는 다음 리소스를 참고하세요.
키 자료의 소스 선택
키를 만들 때는 Cloud KMS가 키 자료를 자동으로 생성하도록 허용하거나 Cloud de Confiance외부에서 생성된 키 자료를 수동으로 가져와야 합니다. 가능한 경우 Cloud KMS에서 키 자료를 생성하는 것이 좋습니다. 이 옵션은 Cloud KMS 외부에 원시 키 자료를 노출할 위험이 없으며 사용자가 선택한 키 순환 기간에 따라 새로운 키 버전을 자동으로 만듭니다. 자체 키 자료를 가져와야 하는 경우 키 자체 조달(BYOK) 방법을 사용할 때의 위험과 다음과 같은 운영 고려사항을 평가하는 것이 좋습니다.
새 키 버전을 일관되게 가져오도록 자동화를 구현할 수 있나요? 여기에는 키 버전을 가져오기만 하도록 제한하는 Cloud KMS 설정과 키 자료를 일관되게 생성하고 가져오는 Cloud KMS 외부의 자동화가 모두 포함됩니다. 자동화로 예상한 시간에 새 키 버전 만들기가 실패할 때의 영향은 무엇인가요?
원래 키 자료를 안전하게 보관하거나 에스크로하기 위한 방법은 무엇인가요?
키 가져오기 프로세스 중 원시 키 자료가 누출될 위험은 어떻게 해결할 수 있나요?
원시 키 자료가 Cloud de Confiance외부에서 보관된 경우 이전에 삭제된 키를 다시 가져온다면 어떻게 될까요?
키 자료를 직접 가져오는 이점이 운영 오버헤드 및 위험 증가보다 더 큰가요?
키 관리 및 키 스토리지 모델 선택
CMEK 아키텍처를 설계할 때는 키를 관리할 위치와 방법을 결정해야 합니다. 이상적으로는 키 관리 모델과 키 저장 모델을 일치시켜야 합니다. 선택한 거버넌스 모델과 스토리지 모델은 직무 분리 시행과 같은 중요한 구성에 영향을 미칩니다.
주요 거버넌스
키 거버넌스는 조직에서 Cloud KMS 리소스의 수명 주기를 관리하고 Cloud KMS 사용 방식을 제어하는 가이드라인을 유지하는 담당자를 설명합니다. 중앙 집중식 거버넌스부터 위임된 거버넌스까지 스펙트럼에 주요 거버넌스 접근 방식이 있습니다.
- 중앙화된 거버넌스: 전담 보안팀 또는 플랫폼팀이 조직 전체의 모든 암호화 키 수명 주기를 관리합니다. 이 모델은 규제가 엄격하고 규정 준수 요구사항이 까다로운 기업에서 주로 선택합니다.
- 위임된 거버넌스: 중앙 보안팀은 가드레일을 사용하여 암호화 표준을 의무화하지만 키 수명 주기 작업의 책임은 프로젝트 내 애플리케이션 소유자에게 위임합니다. 이러한 가드레일에는 관리 제약 조건과 맞춤 제약 조건을 사용하는 조직 정책, IAM 부여 및 거부 정책이 포함될 수 있습니다. 이렇게 하면 중앙 운영 병목 현상이 제거됩니다.
키 저장
키 스토리지는 조직 내에서 Cloud KMS 리소스가 생성되는 위치를 설명합니다. 키 저장에는 전용 프로젝트 키 저장과 동일 프로젝트 키 저장이라는 두 가지 주요 접근 방식이 있습니다.
전용 프로젝트 키 저장: 전용 키 프로젝트에는 여러 애플리케이션에 사용되는 키가 포함됩니다. 일반적으로 각 환경 폴더에는 자체 키 프로젝트가 있습니다. 전용 프로젝트 키 저장소와 함께 Autokey를 사용할 수 있습니다. 전용 프로젝트 키 스토리지 모델에 대한 자세한 내용은 전용 프로젝트 키 스토리지를 참고하세요.
동일 프로젝트 키 저장: 키는 키가 보호하는 리소스와 동일한Cloud de Confiance 프로젝트에 저장됩니다. 이를 '키가 데이터를 따름'이라고 설명하기도 합니다. 동일 프로젝트 키 저장과 함께 Autokey를 사용할 수 있습니다. 동일 프로젝트 키 저장 모델에 대한 자세한 내용은 동일 프로젝트 키 저장을 참고하세요.
거버넌스 및 스토리지 정렬
다음 표에는 다양한 조직의 요구사항을 충족하기 위해 이러한 거버넌스 및 스토리지 모델을 결합하는 방법의 예가 나와 있습니다.
| 거버넌스 모델 | 전용 프로젝트 키 저장 | 동일 프로젝트 키 저장 |
|---|---|---|
| 중앙 집중식 거버넌스 | 완전 중앙 집중식 접근 방식 권장 사용: 프로젝트 경계 격리가 필요한 엄격한 규제 요구사항이 있는 조직 운영 영향: 설정 복잡성이 높습니다. 개발팀의 운영 지연을 방지하기 위해 강력한 자동화('프로젝트 팩토리' 등)가 필요합니다. |
관리형 소유권 권장 사용: 중앙 보안 감독이 필요하지만 개발자 속도를 극대화하려는 조직 운영 영향: 설정 복잡성이 낮습니다. 중앙 보안은 가드레일을 사용하여 정책을 시행하고, 키는 관리의 용이성을 위해 보호하는 리소스와 공동 배치됩니다. |
| 위임된 거버넌스 | 권장하지 않음 프로젝트 간 IAM 복잡성을 도입하면 애플리케이션 팀에 키 관리를 위임하는 목적이 무산됩니다. |
Autonomous DevOps 권장 사용: 강력한 DevOps 문화가 있는 고속의 분산형 조직 운영 영향: 설정 복잡성이 최소화됩니다. 애플리케이션팀은 프로젝트 경계 내의 리소스와 키를 모두 완전히 자율적으로 관리할 수 있습니다. |
여러 환경에서 일관된 아키텍처 사용
모든 애플리케이션에서 개발, 테스트, 프로덕션 환경에 동일한 키 저장소 패턴을 사용하는 것이 좋습니다. 이러한 아키텍처 일관성을 통해 IAM 권한, 배포 파이프라인, 보안 제어가 프로덕션에 배포되기 전에 하위 환경에서 철저히 테스트됩니다. 환경에 다른 아키텍처를 선택하면 배포 실패를 유발할 수 있는 구성 드리프트 위험이 발생합니다.
전용 프로젝트 키 저장
전용 프로젝트 키 저장 모델에서는 특정 환경 폴더 (예: 프로덕션)의 모든 키가 중앙 집중식 공유 키 프로젝트에 저장됩니다. 키 관리 권한은 공유 보안팀에 부여되며, 이 팀은 일반적으로 키 수명 주기 작업과 CMEK 조직 정책, IAM 정책, 역할 부여와 같은 가드레일도 관리합니다.
사용 사례
조직에서 규제 요건에 따라 암호화 키에 대한 엄격한 중앙 제어를 우선시하거나 키가 외부 HSM에서 호스팅되는 경우 전용 프로젝트 키 스토리지 모델을 사용하는 것이 좋습니다.
조직이 PCI DSS 또는 BSI C5와 같이 암호화 담당자 또는 키 관리자가 필요한 규정 준수 프레임워크의 적용을 받는 경우 이 모델이 적합합니다. 단일 전용 키 프로젝트에 애플리케이션의 모든 키를 격리하면 감사된 소규모 보안 관리자 그룹에만 Cloud KMS 관리자 역할을 부여할 수 있습니다. 이렇게 하면 주요 관리 액세스 정책을 검토해야 하는 프로젝트 수를 제한하여 규정 준수 감사를 간소화할 수 있습니다.
고려사항
이 접근 방식은 교차 프로젝트 IAM 복잡성과 개발팀의 잠재적인 병목 현상을 야기할 수 있습니다. 이러한 문제를 완화하려면 주요 생성 및 권한 할당을 자동화하는 자동 프로젝트 프로비저닝('프로젝트 팩토리'라고도 함)을 구현하면 됩니다.
예
다음 다이어그램은 전용 프로젝트 키 스토리지 모델을 사용하는 프로덕션 환경의 리소스 계층 구조 예를 보여줍니다.
- Prod 폴더에는 다양한 애플리케이션의 개별 폴더와 프로젝트, Shared 폴더가 포함되어 있습니다.
- 애플리케이션 프로젝트에는 Compute Engine 인스턴스, Cloud Storage 버킷 등 다양한 리소스가 포함되어 있지만 Cloud KMS 키는 포함되어 있지 않습니다.
- 공유 폴더에는 여러 애플리케이션 간에 공유되는 리소스가 포함됩니다.
- 공유 폴더 내에 Cloud KMS API가 사용 설정된 전용 키 프로젝트가 있습니다. 이 프로젝트에는 Prod 폴더 내 리소스를 보호하는 데 사용되는 모든 키가 포함되어 있습니다.
- 조직 정책 제약 조건 및 IAM 정책과 같은 조직 수준 및 폴더 수준 가드레일은 직무 분리 및 기타 관행을 시행합니다.
- 개발자는 키 프로젝트에 권한을 부여하지 않고도 개별 애플리케이션 폴더 또는 프로젝트 내에서 프로젝트 소유자 역할과 같은 승격된 권한을 가질 수 있습니다.
동일 프로젝트 키 저장
이 모델에서는 키가 보호하는 리소스와 동일한 프로젝트에 저장됩니다. 개발자가 자체 애플리케이션의 키 수명 주기를 관리하는 경우에도 핵심 보안팀에서 키 관리 가이드라인을 구현하는 경우가 많습니다.
사용 사례
개발자 속도, 민첩성, 명확한 책임이 우선이라면 동일 프로젝트 키 스토리지 모델을 사용하는 것이 좋습니다. 키를 보호하는 리소스와 함께 배치하면 키 소유권이 데이터 소유권과 일치합니다. 즉, 키가 데이터를 따릅니다. 이 모델을 사용하면 CMEK 조직 정책을 준수하고 프로젝트 내에서 키 수명 주기 작업을 관리하는 책임을 맡을 수 있는 워크로드 소유자에게 주요 관리 책임을 위임할 수 있습니다.
고려사항
이 모델은 애플리케이션 팀에 권한을 부여하지만 최소 권한을 적용하려면 각 프로젝트 내에서 IAM 역할을 부지런히 감사해야 합니다. 이 모델은 시스템 간 조율 오버헤드로 인해 자체 키 사용 (BYOK)을 구현하거나 Cloud EKM 키를 사용하는 조직의 운영 복잡성을 높일 수 있습니다.
예
다음 다이어그램은 동일한 프로젝트 키 스토리지 모델을 사용하는 프로덕션 환경의 리소스 계층 구조 예를 보여줍니다.
- Prod 폴더에는 여러 애플리케이션의 개별 폴더와 프로젝트가 포함되어 있습니다.
- 애플리케이션 프로젝트에는 이러한 리소스를 보호하는 Cloud KMS 키를 비롯해 Compute Engine 인스턴스, Cloud Storage 버킷 등 다양한 리소스가 포함됩니다.
- 조직 정책 제약 조건 및 IAM 정책과 같은 조직 수준 및 폴더 수준 가드레일은 직무 분리 및 기타 관행을 시행하지만 직무 분리를 시행하려면 더 신중한 구성이 필요할 수 있습니다.
- 개발자가 키를 만들고 관리하려면 리소스 프로젝트에 대한 Cloud KMS 권한이 상승되어야 합니다.
업무 분장 적용
스토리지 모델과 관계없이 암호화 키를 관리하는 사람과 이를 사용하는 사람에 대해 주 구성원과 권한을 구분해야 합니다. 최소 권한의 원칙과 엄격한 업무 분리를 적용하려면 특정 운영 책임을 기반으로 IAM 역할을 부여하세요.
다음 표는 Cloud KMS에 권장되는 역할 분리를 요약한 것입니다.
| 책임 | 권장 역할 | 권한 요약 |
|---|---|---|
키 관리(예: 키 수명 주기 및 거버넌스) 여기에는 승격된 권한이 필요한 사람 관리자와 IaC 보안 주체가 포함될 수 있습니다. |
Cloud KMS 관리자(roles/cloudkms.admin) |
|
리소스 프로비저닝(예: CMEK로 보호되는 리소스 만들기) 여기에는 권한이 상승되지 않은 인간 개발자와 IaC 주체가 포함될 수 있습니다. |
다음과 같은 서비스별 관리 또는 편집자 역할
|
리소스 생성 중에 키를 선택합니다. |
키 사용(예: 암호화 및 복호화) 서비스 에이전트에게만 이 역할을 부여합니다. CMEK 통합에 사용되는 키의 경우 인간 주체에게 이러한 권한이 필요하지 않습니다. |
Cloud KMS CryptoKey 암호화/복호화
(roles/cloudkms.cryptoKeyEncrypterDecrypter) |
키를 사용하여 데이터를 암호화하고 복호화합니다. |
IaC 파이프라인에 최소 권한 에스컬레이션 적용
많은 조직이 Terraform 러너와 같은 코드형 인프라(IaC) 파이프라인을 사용하여 리소스 프로비저닝을 자동화합니다. 키 스토리지를 설계하는 방식은 이러한 파이프라인의 보안 상황에 직접적인 영향을 미칩니다.
Cloud KMS 키 프로비저닝을 자동화하려면 키를 생성하고 IAM 정책을 수정할 수 있는 높은 권한의 관리 역할이 IaC 파이프라인에 부여되어야 합니다. 공격자가 IaC 파이프라인을 손상시키면 키 관리 플레인을 완전히 관리할 수 있습니다.
- 전용 프로젝트 키 스토리지를 사용하는 경우 파이프라인에 중앙 Cloud KMS 프로젝트에 대한 관리 액세스 권한이 필요합니다. 파이프라인이 손상되면 전체 조직의 키 관리 플레인이 노출될 수 있습니다.
- 동일한 프로젝트 키 스토리지를 사용하는 경우 파이프라인에는 리소스 프로젝트에 대한 관리 액세스 권한만 필요합니다. 이렇게 하면 잠재적 위험의 범위가 특정 애플리케이션으로 제한되지만 프로젝트 내에서 상승된 권한을 관리해야 합니다.
Cloud KMS Autokey는 키 프로비저닝을 안전한 Google 관리형 서비스 에이전트에 위임하여 이 위험을 해결하므로 지속적인 키 프로비저닝을 위한 최소 권한 파이프라인을 구현할 수 있습니다.
- 권한이 낮은 파이프라인: IaC 파이프라인은
KeyHandle리소스를 만들어 키를 요청하는 데 권한이 낮은 Cloud KMS Autokey 사용자 역할 (roles/cloudkms.autokeyUser)만 필요합니다. - 자동 프로비저닝: 실제 키 생성 및 IAM 정책 업데이트는 Google에서 관리하는 Cloud KMS 서비스 에이전트가 백그라운드에서 처리합니다.
- 제한된 위험 범위: 파이프라인에 부여된 권한을 최소화하면 이 설계에서는 배포 파이프라인에 향상된 키 생성 또는 보안 관리자 권한이나 도우미 역할을 할당하는 기능을 부여하지 않으므로 파이프라인 보안 침해 위험이 크게 줄어듭니다.
Autokey를 사용 설정하는 IaC 파이프라인에는 Cloud KMS Autokey 관리자 (roles/cloudkms.autokeyAdmin)와 같은 더 허용적인 역할이 필요하므로 IaC 파이프라인을 사용하여 Autokey 사용 설정을 관리하는 경우 개별 IaC 보안 주체에도 직무 분리를 적용해야 합니다.
권장 키 관리 관행에 따라 조정
Google에서는 키 위치, 보호 수준, 순환 일정, 세분성, 권한에 관한 권장사항을 제공합니다. 암호화 측정항목 대시보드를 사용하여 키가 이러한 관행에 얼마나 잘 부합하는지 확인할 수 있습니다. Security Command Center 취약점 발견 항목을 사용하여 직무 분리 위반을 감지할 수 있습니다.
키 위치
Cloud KMS 키링은 CMEK로 암호화된 리소스를 배포할 위치에 만들어야 합니다. Cloud de Confiance 키를 만들기 전에 이 작업을 실행해야 합니다.- 리전 및 영역별 리소스는 리소스와 동일한 리전에서 또는
global위치에서 키링과 키를 사용해야 합니다. - 전역 리소스는
global위치에서 키링과 키를 사용해야 합니다.
대부분의 경우 이러한 제한사항은 Cloud de Confiance서비스에 의해 적용됩니다.
리전별 키 사용을 강제하는 것은 성공적인 데이터 리전화 전략의 일부입니다. 정의된 리전에서 키링 및 키 사용을 강제함으로써 리소스가 키링의 리전과 일치하도록 강제됩니다.
키 세분성 전략 선택
세분성은 각 키에 의도한 사용 규모 및 범위를 나타냅니다. 예를 들어 여러 리소스를 보호하는 키는 리소스를 하나만 보호하는 키보다 세분성이 낮다라고 말할 수 있습니다. 적절한 키 세분성 전략을 선택하면 각 키에 특정 용도가 있어야 한다는 NIST 권장사항을 준수하는 데 도움이 됩니다.
일반적으로 각 키는 다음과 같이 사용하는 것이 좋습니다.
- 단일 Cloud de Confiance 프로젝트에 사용됩니다.
- 단일 위치에서 사용됩니다(예:
us-central1). - 단일 서비스 또는 제품(예: BigQuery)에서 사용됩니다.
- 가능한 경우 단일 리소스(예: 단일 Cloud Storage 버킷)에 사용됩니다.
대부분의 조직에서 이 전략은 세분화된 키를 많이 유지하는 오버헤드와 여러 프로젝트, 서비스 또는 리소스 간에 공유되는 세분화되지 않은 키를 사용할 때 발생할 수 있는 위험 사이에서 적절한 균형을 제공합니다.
이러한 세부사항 가이드라인을 따르면 키 버전을 안전하게 사용 중지하거나 폐기하기가 더 쉬워지고 실수로 또는 악의적으로 키가 폐기될 위험이 제한됩니다.
키의 보호 수준 선택
키를 만들 때는 CMEK로 암호화되는 데이터 및 워크로드의 요구사항에 따라 각 키에 적합한 보호 수준을 사용자가 직접 선택해야 합니다.
* 키 자료를 Cloud de Confiance외부에 저장해야 하는 경우 Cloud EKM 키를 사용하세요. 가용성을 높이려면 EXTERNAL_VPC 보호 수준을 사용하는 것이 좋습니다.
* Cloud de Confiance외부에서 키 자료를 저장할 필요가 없는 경우 소프트웨어 지원 키를 사용하는 것이 좋습니다.
순환 주기 선택
Cloud KMS는 CMEK에 사용되는 키와 같은 소프트웨어 지원 및 하드웨어 기반의 대칭 키의 자동 키 순환을 지원합니다. 소프트웨어 지원 키의 경우 업계 표준 순환 기간인 90일을 사용하는 것이 좋습니다. Cloud HSM 키의 경우 업계 표준 순환 기간인 365일을 사용하는 것이 좋습니다. 외부 키는 선택한 일정에 따라 수동으로 순환해야 합니다.
필요에 따라 적합한 키 순환 기간을 평가하는 것이 좋습니다. 키 순환 빈도는 민감도 및 규정 준수 기반의 워크로드 요구사항에 따라 달라집니다. 예를 들어 특정 규정 준수 표준을 충족하기 위해 1년에 최소 한 번 이상의 키 순환이 필요할 수도 있고 중요도가 높은 워크로드의 경우 더 짧은 순환 기간을 선택할 수도 있습니다.
키 순환 기간이 짧으면 동일한 키 버전으로 암호화되는 메시지 수가 제한되어 키 손상 시 위험과 효과를 줄이는 데 도움이 됩니다.
최소 권한의 원칙 적용
IAM 역할을 부여할 때는 최소 권한의 원칙을 따르세요.
소유자, 편집자, 뷰어와 같은 기본 역할은 사용하지 않는 것이 좋습니다. 대신 초과 권한 액세스와 관련된 보안 사고 위험을 줄이기 위해 사전 정의된 Cloud KMS 역할을 부여하세요. 예를 들어 주 구성원이 키 자료만 가져와야 하는 경우 권한이 더 많은 Cloud KMS 관리자 역할 (roles/cloudkms.admin) 대신 Cloud KMS 가져오기 작업자 역할 (roles/cloudkms.importer)을 부여합니다.
운영 가드레일 설정
다음 섹션에서는 일관적이지 않은 키 사용 또는 사고로 인한 삭제 또는 파괴와 같은 위험을 해결하는 데 도움이 되는 제어 수단에 대해 설명합니다.
프로젝트 선취권 적용
Cloud KMS 프로젝트와 포함된 키가 실수로 삭제되지 않도록 선취권을 통해 프로젝트를 보호(미리보기)하는 것이 좋습니다. 프로젝트 선취권이 적용된 경우 선취권이 삭제될 때까지 프로젝트의 삭제가 차단됩니다. Cloud KMS 키가 포함된 프로젝트의 경우 실수로 키가 삭제될 수 있는 한 가지 원인을 방지할 수 있습니다.
CMEK 키 요구
조직 정책 제약 조건을 사용하여 환경 전체에 CMEK 사용을 적용하는 것이 좋습니다.
CMEK 키를 지정하지 않고 constraints/gcp.restrictNonCmekServices를 사용하여 특정 리소스 유형 만들기 요청을 차단합니다.
최소 폐기 예약 기간 필요
최소 폐기 예약 기간을 설정하는 것이 좋습니다. 키 폐기는 데이터가 영구적으로 손실될 수 있는 되돌릴 수 없는 작업입니다. 기본적으로 Cloud KMS는 키 자료가 되돌릴 수 없게 삭제되기 전 30일의 폐기 예약 기간(소프트 삭제 기간이라고도 함)을 사용합니다. 이렇게 하면 사고로 인한 폐기 시 키를 복원할 수 있는 시간이 확보됩니다. 하지만 Cloud KMS 관리자 역할이 있는 사람이 폐기 예약 기간을 24시간 정도로 낮게 설정해서 키를 만들 수도 있습니다. 이렇게 하면 문제를 감지하고 키를 복원하기에 시간이 충분하지 않을 수 있습니다. 폐기 예약 기간은 키 생성 중에만 설정할 수 있습니다.
키가 폐기되도록 예약되면 암호화 작업에 사용할 수 없으며 키를 사용하려는 모든 요청이 실패합니다. 이 기간 동안 감사 로그를 모니터링하여 키가 사용되지 않는지 확인합니다. 키를 다시 사용하려면 폐기 예약된 기간이 끝나기 전에 키를 복원해야 합니다.
생성된 모든 키가 최소 폐기 예약 기간을 준수하도록 하려면 최소 30일 또는 원하는 기간에 따라 조직 정책 제약 조건 constraints/cloudkms.minimumDestroyScheduledDuration를 구성하는 것이 좋습니다. 이 조직 정책은 사용자가 정책에 지정된 값보다 낮은 폐기 예약 기간을 사용해서 키를 만들지 못하도록 방지합니다.
CMEK의 허용되는 보호 수준 적용
전체 환경에 조직 정책 제약 조건을 사용하여 일관적으로 키 보호 수준 요구사항을 적용하는 것이 좋습니다.
constraints/cloudkms.allowedProtectionLevels를 사용하여 새로운 키, 키 버전, 가져오기 작업에 사용자가 허용하는 보호 수준이 사용되도록 강제할 수 있습니다.
CMEK의 감지 제어 구성
Cloud de Confiance 는 CMEK에 대해 다양한 감지 제어를 제공합니다. 다음 섹션에서는 Cloud KMS와 관련된 제어를 사용 설정하고 사용하는 방법을 설명합니다.
감사 로깅 사용 설정 및 집계
조직 내 모든 리소스에 대해 중앙 위치에서 Cloud KMS 관리자 활동 감사 로그를 집계하는 것이 좋습니다. 이렇게 하면 보안팀 또는 감사자가 Cloud KMS 리소스 만들기 또는 수정과 관련된 모든 활동을 한 번에 검토할 수 있습니다. 집계된 로그 싱크 구성에 대한 자세한 내용은 조직 로그 집계 및 저장을 참고하세요.
선택적으로 암호화 및 복호화 작업을 포함하여 키를 사용하는 작업을 로깅하도록 사용 데이터 액세스 로그를 사용 설정할 수 있습니다. 이렇게 하면 CMEK를 사용하는 모든 서비스의 모든 작업에 따라 데이터 액세스 로그가 생성되기 때문에 CMEK를 사용할 때 상당한 로그 볼륨이 생성되고 비용에 영향을 줄 수 있습니다. 데이터 액세스 로그를 사용 설정하기 전에 추가 로그에 대해 명확한 사용 사례를 정의하고 증가하는 로깅 비용을 평가하는 것이 좋습니다.
권장사항 요약
다음 표에서는 이 문서에 설명된 권장사항을 요약해서 보여줍니다.
| 주제 | 작업 |
|---|---|
| Cloud KMS 키 프로젝트 | 각 환경에 하나의 중앙 집중식 키 프로젝트를 사용합니다. 키로 보호되는 Cloud de Confiance 리소스와 동일한 프로젝트에 Cloud KMS 리소스를 만들지 마세요. |
| Cloud KMS 키링 | Cloud de Confiance리소스를 보호하려는 각 위치에 Cloud KMS 키링을 만듭니다. |
| 키 세분성 | 위험 허용 범위, 비용, 운영 오버헤드에 대한 요구사항을 충족하는 키 세분성 패턴을 선택합니다. |
| 보호 수준 | 키 자료를 Cloud de Confiance 외부에 저장해야 하거나 2단계 또는 3단계의 FIPS 140-2 인증이 필요한 경우 Cloud EKM을 선택합니다. 그렇지 않으면 소프트웨어 키를 선택합니다. 보호 수준 선택 안내를 검토합니다. |
| 키 자료 | Cloud de Confiance에 호스팅된 키 자료의 경우 가능하면 Cloud de Confiance에서 생성된 키 자료를 사용합니다. 가져온 키 자료를 사용할 경우 위험 완화를 위한 자동화 및 절차를 구현합니다. |
| 키 용도 및 알고리즘 | 모든 CMEK 키는 대칭 ENCRYPT_DECRYPT 키 목적과 GOOGLE_SYMMETRIC_ENCRYPTION 알고리즘을 사용해야 합니다. |
| 순환 주기 | 자동 키 순환을 사용해서 키가 일정에 따라 순환되도록 합니다. 요구 사항에 따라 순환 기간을 선택하고 적용합니다. 가급적이면 1년에 한 번 이상 키를 순환합니다. 민감한 워크로드의 경우 키를 더 자주 순환합니다. |
| 최소 권한 | 주 구성원이 태스크를 완료하는 데 필요한 가장 제한적인 사전 정의된 역할을 부여합니다. 기본 역할은 사용하지 마세요. |
| 업무 분장 | 키 관리자 및 키를 사용하는 주 구성원에 대해 권한을 별개로 유지합니다. |
| 프로젝트 선취권 | 프로젝트 선취권을 사용하여 키 프로젝트가 사고로 삭제되지 않도록 방지합니다. |
| CMEK 필요 | constraints/gcp.restrictNonCmekServices 제약 조건을 사용합니다. |
| 최소 폐기 예약 기간 필요 | constraints/cloudkms.minimumDestroyScheduledDuration 제약 조건을 사용합니다. |
| CMEK의 허용되는 보호 수준 적용 | constraints/cloudkms.allowedProtectionLevels 제약 조건을 사용합니다. |
| 감사 로깅 사용 설정 및 집계 | 조직의 모든 리소스에 대해 관리 활동 감사 로그를 집계합니다. 키를 사용하여 작업 로깅을 사용 설정할지 여부를 고려합니다. |
| 규정 준수 요구사항 평가 | Cloud KMS 아키텍처를 검토하고 준수해야 하는 규정 준수 요구사항과 비교합니다. |