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