CMEK 사용 권장사항

이 페이지에서는 리소스에서 고객 관리 암호화 키 (CMEK)를 사용하여 저장 데이터 암호화를 구성하는 방법에 대한 권장사항을 설명합니다. Google Cloud 이 가이드는 클라우드 설계자와 보안팀을 대상으로 하며 CMEK 아키텍처를 설계하면서 따라야 하는 권장사항과 의사결정에 대해 설명합니다.

이 가이드에서는 사용자가 Cloud Key Management Service(Cloud KMS) 및 고객 관리 암호화 키에 익숙하고 Cloud KMS 심층 분석을 읽었다고 가정합니다.

사전 결정 사항

이 페이지의 권장사항은 데이터 암호화를 위해 CMEK를 사용하는 고객을 대상으로 합니다. 보안 전략에 따라 수동 또는 자동으로 생성된 CMEK를 사용할지 여부가 확실하지 않으면 이 섹션을 통해 다음과 같은 사전 결정 사항에 대한 안내를 얻을 수 있습니다.

CMEK 사용 여부 결정

다음 기능이 필요하면 Google Cloud서비스에서 저장 데이터 암호화를 위해 CMEK를 사용하는 것이 좋습니다.

• 암호화 키를 소유합니다.

• 암호화 키의 위치 선택, 보호 수준, 생성, 액세스 제어, 순환, 사용, 폐기 등을 제어하고 관리합니다.

• Cloud KMS에서 키 자료를 생성하거나 Google Cloud외부에서 유지보수되는 키 자료를 가져옵니다.

• 키를 사용해야 하는 위치와 관련된 정책을 설정합니다.

• 오프보딩 시 키로 보호되는 데이터를 선택적으로 삭제하거나 보안 이벤트(암호화 파쇄)를 해결합니다.

• 고객별로 고유한 키를 만들어서 사용하고 데이터에 대한 암호화 경계를 설정합니다.

• 암호화 키에 대한 관리 및 데이터 액세스를 로깅합니다.

• 이러한 목표를 요구하는 현재 또는 미래의 규정을 준수합니다.

이러한 기능이 필요하지 않으면 Google-owned and managed keys를 사용한 기본적인 저장 데이터 암호화가 해당 사용 사례에 적합한지 평가합니다. 기본 암호화만 사용하도록 선택한 경우 이 가이드 읽기를 중지해도 좋습니다.

수동 또는 자동 키 생성 선택

이 가이드에서는 CMEK를 직접 프로비저닝할 때 수행해야 하는 의사 결정에 대한 권장사항을 설명합니다. Cloud KMS Autokey는 이러한 일부 결정을 자동으로 수행하고 이 가이드에서 설명하는 많은 권장사항을 자동화합니다. Autokey 사용은 직접 키를 프로비저닝하는 것보다 간단하며 Autokey로 생성된 키가 모든 요구사항을 충족할 경우에 권장되는 방법입니다.

Autokey는 CMEK를 자동으로 프로비저닝합니다. Autokey로 프로비저닝된 CMEK에는 다음과 같은 특성이 있습니다.

• 보호 수준: HSM.
• 알고리즘: AES-256 GCM.

• 순환 기간: 1년.

  Autokey로 키가 생성되면 Cloud KMS 관리자가 기본값에서 순환 기간을 수정할 수 있습니다.

• 책임 구분:
  • 서비스의 서비스 계정에는 키에 대한 암호화 및 복호화 권한이 자동으로 부여됩니다.
  • Cloud KMS 관리자 권한은 평소와 같이 Autokey로 생성된 키에 적용됩니다. Cloud KMS 관리자는 Autokey에서 생성된 키를 보고, 업데이트하고, 사용 설정 또는 사용 중지하고, 폐기할 수 있습니다. Cloud KMS 관리자에게는 암호화 및 복호화 권한이 부여되지 않습니다.
  • Autokey 개발자는 키 생성 및 할당만 요청할 수 있습니다. 키를 보거나 관리할 수 없습니다.
• 키 특이성 또는 세분성: Autokey로 생성된 키는 리소스 유형에 따라 달라지는 세분성을 갖습니다. 서비스별로 키 세분성에 대한 자세한 내용은 호환 서비스를 참조하세요.

• 위치: Autokey는 보호할 리소스와 동일한 위치에 키를 만듭니다.

  Cloud HSM을 사용할 수 없는 위치에 CMEK로 보호되는 리소스를 만들어야 하는 경우에는 CMEK를 수동으로 만들어야 합니다.

• 키 버전 상태: Autokey를 사용해서 요청된 새로 생성된 키는 사용 설정된 상태의 기본 키 버전으로 생성됩니다.
• 키링 이름 지정: Autokey에서 만든 모든 키는 선택한 위치의 Autokey 프로젝트에 있는 autokey라는 키링에 생성됩니다. Autokey 프로젝트의 키링은 Autokey 개발자가 지정된 위치의 첫 번째 키를 요청하면 생성됩니다.
• 키 이름 지정: Autokey에서 생성된 키는 다음 이름 지정 규칙을 따릅니다. PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
• 키 내보내기: 모든 Cloud KMS 키와 마찬가지로 Autokey로 생성된 키는 내보낼 수 없습니다.
• 키 추적: 키 추적과 호환되는 CMEK 통합 서비스에 사용되는 모든 Cloud KMS 키와 마찬가지로 Autokey에서 생성된 키는 Cloud KMS 대시보드에서 추적됩니다.

HSM과 다른 보호 수준이 필요하거나 Autokey와 호환되지 않는 서비스를 사용하는 등 Autokey로 생성된 키로 요구사항을 충족할 수 없으면 Autokey 대신 수동으로 생성된 CMEK를 사용하는 것이 좋습니다.

CMEK 아키텍처 설계

CMEK 아키텍처를 설계할 때는 사용할 키의 구성과 이러한 키의 관리 방법을 고려해야 합니다. 이러한 결정에 따라 비용과 운영 오버헤드, 그리고 암호화 파쇄와 같은 기능 구현의 난이도가 달라집니다.

다음 섹션에서는 각 설계 옵션의 권장사항에 대해 설명합니다.

각 환경에 중앙화된 CMEK 키 프로젝트 사용

각 환경 폴더에 중앙화된 CMEK 키 프로젝트를 사용하는 것이 좋습니다. CMEK로 암호화된 리소스를 Cloud KMS 키를 관리하는 것과 동일한 프로젝트에 만들지 마세요. 이러한 방식은 각 환경에 암호화 키가 공유되는 것을 방지하고 책임을 구분하는 데 도움이 됩니다.

다음 다이어그램은 이러한 개념을 권장 설계로 설명합니다.

• 각 환경 폴더에는 애플리케이션 프로젝트와 별개로 관리되는 Cloud KMS 키 프로젝트가 있습니다.
• Cloud KMS 키링과 키는 Cloud KMS 키 프로젝트에 프로비정되며 이러한 키는 애플리케이션 프로젝트에서 리소스를 암호화하기 위해 사용됩니다.
• Identity and Access Management(IAM) 정책은 책임 구분을 위해 프로젝트 또는 폴더에 적용됩니다. Cloud KMS 키 프로젝트에서 Cloud KMS 키를 관리하는 주 구성원은 애플리케이션 프로젝트에서 암호화된 키를 사용하는 주 구성원과 동일하지 않습니다.

Cloud KMS Autokey를 사용하는 경우 Autokey가 사용 설정된 각 폴더에 전용 Cloud KMS 키 프로젝트가 있어야 합니다.

각 위치의 Cloud KMS 키링 만들기

Cloud KMS 키링은 CMEK로 암호화된Google Cloud 리소스를 배포하는 위치에 만들어야 합니다.

• 리전 및 영역별 리소스는 리소스와 동일한 리전에서 또는 global 위치에서 키링과 CMEK를 사용해야 합니다. 단일 리전 및 영역별 리소스는 global 이외의 멀티 리전 키링을 사용할 수 없습니다.
• 멀티 리전 리소스 (예: us 멀티 리전의 BigQuery 데이터 세트)는 동일한 멀티 리전 또는 이중 리전에서 키링과 CMEK를 사용해야 합니다. 멀티 리전 리소스는 리전별 키링을 사용할 수 없습니다.
• 전역 리소스는 global 위치에서 키링과 CMEK를 사용해야 합니다.

리전별 키를 적용하는 방법은 데이터 리전화 전략의 일부입니다. 정의된 리전에서 키링 및 키 사용을 강제함으로써 리소스가 키링의 리전과 일치하도록 강제됩니다. 데이터 상주에 관한 안내는 데이터 상주 제어를 참고하세요.

여러 위치에서 고가용성 또는 재해 복구 기능이 필요한 워크로드의 경우에는 특정 리전에서 Cloud KMS를 사용할 수 없게 되었을 때도 워크로드에 복원력이 있는지 사용자가 직접 평가해야 합니다. 예를 들어 리전 A의 Cloud KMS 키로 암호화된 Compute Engine 영구 디스크는 리전 A를 사용할 수 없는 재해 복구 시나리오에서 리전 B에서 다시 만들 수 없습니다. 이러한 시나리오의 위험을 완화하려면 global 키를 사용하여 리소스를 암호화할 수 있습니다.

자세한 내용은 최적의 위치 유형 선택을 참고하세요.

Cloud KMS Autokey를 사용하는 경우 보호 대상 리소스와 동일한 위치에 키링이 자동으로 생성됩니다.

키 세분성 전략 선택

세분성은 각 키에 의도한 사용 규모 및 범위를 나타냅니다. 예를 들어 여러 리소스를 보호하는 키는 리소스를 하나만 보호하는 키보다 세분성이 낮다라고 말할 수 있습니다.

CMEK용으로 수동으로 프로비저닝된 Cloud KMS 키는 Compute Engine 영구 디스크와 같이 키로 암호화되는 리소스를 만들기 전에 미리 프로비저닝되어야 합니다. 개별 리소스에 대해 세분성이 매우 높은 키를 만들거나 리소스 간 재사용을 위해 보다 포괄적으로 세분성이 낮은 키를 만들도록 선택할 수 있습니다.

보편적으로 올바른 패턴이란 존재하지 않지만 다음과 같이 여러 패턴 간의 장단점을 고려해야 합니다.

세분성이 높은 키(예: 각 리소스당 하나의 키 사용)

• 키 버전을 안전하게 사용 중지할 수 있는 추가 제어 기능: 좁은 범위에 사용되는 키 버전은 공유 키와 달리 사용 중지하거나 삭제하더라도 다른 리소스에 영향을 미칠 위험이 낮습니다. 또한 세분성이 높은 키를 사용하면 세분성이 낮은 키를 사용할 때와 비교해서 키 손상에 따른 잠재적 영향을 줄이는 데 도움이 됩니다.
• 비용: 세분성이 낮은 키를 사용하는 전략과 비교해서 세분성이 높은 키를 사용하기 위해서는 더 많은 활성 키 버전에 대한 유지보수가 필요합니다. Cloud KMS 가격 책정은 활성 키 버전 수를 기반으로 하기 때문에 세분성이 높은 키를 선택하면 비용이 높아집니다.
• 운영 오버헤드: 세분성이 높은 키를 사용하면 서비스 에이전트가 적합한 키만 사용할 수 있도록 많은 수의 Cloud KMS 리소스를 프로비저닝하고 서비스 에이전트의 액세스 제어 관리를 위한 관리 작업 또는 추가 자동화 도구 사용이 필요할 수 있습니다. 세분성이 높은 키가 필요하면 프로비저닝 자동화를 위해 Autokey가 적절한 옵션이 될 수 있습니다. 각 서비스의 Autokey 키 세분성에 대한 자세한 내용은 호환 서비스를 참고하세요.

세분성이 낮은 키(예: 각 애플리케이션, 각 리전, 각 환경에 하나의 키 사용)

• 키 버전을 안전하게 사용 중지하기 위한 주의 요구: 넓은 범위에 사용되는 키 버전을 사용 중지하거나 삭제하기 위해서는 세분성이 높은 키를 사용 중지하거나 삭제할 때보다 많은 주의가 필요합니다. 이전 키 버전을 사용 중지하기 전에 먼저 해당 키 버전으로 암호화된 모든 리소스가 새로운 키 버전으로 안전하게 다시 암호화되는지 확인해야 합니다. 대부분의 리소스 유형에서는 키 사용을 확인하여 키가 사용된 위치를 식별할 수 있습니다. 또한 세분성이 낮은 키를 사용하면 세분성이 높은 키를 사용할 때와 비교해서 키 손상으로 인한 잠재적 영향이 증가할 수 있습니다.
• 비용: 세분성이 낮은 키를 사용할 때는 만들어야 하는 키 버전 수가 감소합니다. Cloud KMS 가격 책정은 활성 키 버전 수를 기반으로 합니다.
• 운영 오버헤드: 알려진 개수의 키를 정의 및 사전 프로비저닝하고 적합한 액세스 제어를 보장하기 위해 필요한 노력을 줄일 수 있습니다.

키의 보호 수준 선택

키를 만들 때는 CMEK로 암호화되는 데이터 및 워크로드의 요구사항에 따라 각 키에 적합한 보호 수준을 사용자가 직접 선택해야 합니다. 다음 질문은 이러한 평가를 수행하는 데 도움이 될 수 있습니다.

1. CMEK 기능이 필요한가요? 이 페이지의 CMEK 사용 여부 결정에 나열된 기능을 검토할 수 있습니다.

   • 그렇다면 다음 질문으로 진행합니다.
   • 그렇지 않으면 Google 기본 암호화를 사용하는 것이 좋습니다.

2. 키 자료가 하드웨어 보안 모듈(HSM)의 물리적 경계 내에 있어야 하나요?

   • 그렇다면 다음 질문으로 진행합니다.
   • 그렇지 않으면 소프트웨어 지원 키와 함께 CMEK를 사용하는 것이 좋습니다.

3. 키 자료를 Google Cloud외부에 저장해야 하나요?

   • 그렇다면 Cloud 외부 키 관리자와 함께 CMEK가 권장됩니다.
   • 그렇지 않으면 Cloud HSM(하드웨어 지원 키)과 함께 CMEK가 권장됩니다.

Autokey는 HSM 보호 수준만 지원합니다. 다른 보호 수준이 필요하면 키를 직접 프로비저닝해야 합니다.

가능한 경우 Google Cloud에서 생성된 키 자료 사용

이 섹션은 Cloud EKM 키에 적용되지 않습니다.

키를 만들 때는 Cloud KMS가 키 자료를 자동으로 생성하도록 허용하거나 Google Cloud외부에서 생성된 키 자료를 수동으로 가져와야 합니다. 가능하면 생성된 옵션을 선택하는 것이 좋습니다. 이 옵션은 Cloud KMS 외부에 원시 키 자료를 노출하지 않고 사용자가 선택한 키 보관 기간에 따라 새로운 키 버전을 자동으로 만듭니다. 자체 키 자료를 가져오는 옵션이 필요하면 키 자체 조달(BYOK) 방법을 사용할 때의 위험과 다음과 같은 운영 고려사항을 평가하는 것이 좋습니다.

• 새 키 버전을 일관되게 가져오도록 자동화를 구현할 수 있나요? 여기에는 키 버전을 가져오기만 하도록 제한하는 Cloud KMS 설정과 키 자료를 일관되게 생성하고 가져오는 Cloud KMS 외부의 자동화가 모두 포함됩니다. 자동화로 예상한 시간에 새 키 버전 만들기가 실패할 때의 영향은 무엇인가요?
• 원래 키 자료를 안전하게 보관하거나 에스크로하기 위한 방법은 무엇인가요?
• 키 가져오기 프로세스 중 원시 키 자료가 누출될 위험은 어떻게 해결할 수 있나요?
• 원시 키 자료가 Google Cloud외부에서 보관된 경우 이전에 삭제된 키를 다시 가져온다면 어떻게 될까요?
• 키 자료를 직접 가져오는 이점이 운영 오버헤드 및 위험 증가보다 더 큰가요?

필요에 맞는 키 목적과 알고리즘 선택

키를 만들 때는 키의 목적과 기본 알고리즘을 선택해야 합니다. CMEK 사용 사례의 경우 대칭 ENCRYPT_DECRYPT 목적의 키만 사용할 수 있습니다. 이러한 키 목적에는 항상 Galois Counter Mode(GCM)에서 Cloud KMS 내부 메타데이터로 채워진 256비트 고급 암호화 표준(AES-256) 키를 사용하는 GOOGLE_SYMMETRIC_ENCRYPTION 알고리즘이 사용됩니다. Autokey를 사용할 때는 이러한 설정이 자동으로 적용됩니다.

클라이언트 측 암호화와 같은 다른 사용 사례에서는 사용 가능한 키 목적과 알고리즘을 검토하여 사용 사례에 가장 적합한 옵션을 선택합니다.

순환 주기 선택

필요에 따라 적합한 키 순환 기간을 평가하는 것이 좋습니다. 키 순환 빈도는 민감도 및 규정 준수 기반의 워크로드 요구사항에 따라 달라집니다. 예를 들어 특정 규정 준수 표준을 충족하기 위해 1년에 최소 한 번 이상의 키 순환이 필요할 수도 있고 중요도가 높은 워크로드의 경우 더 짧은 순환 기간을 선택할 수도 있습니다.

대칭 키 순환 후에는 새 버전이 기본 키 버전으로 표시되고 정보 보호를 위한 모든 신규 요청에 사용됩니다. 이전의 키 버전은 해당 버전으로 보호되는 이전에 암호화된 데이터를 복호화하는 데 사용할 수 있도록 제공됩니다. 키를 순환해도 이전 키 버전으로 암호화된 데이터는 자동으로 다시 암호화되지 않습니다.

키 순환 기간이 짧으면 동일한 키 버전으로 암호화되는 메시지 수가 제한되어 키 손상 시 위험과 효과를 줄이는 데 도움이 됩니다.

Autokey를 사용할 경우 기본 키 순환 기간 1년에 따라 키가 생성됩니다. 키를 만든 후 키의 순환 기간을 변경할 수 있습니다.

적절한 액세스 제어 적용

액세스 제어를 계획할 때는 최소 권한의 원칙과 책임 구분을 고려하는 것이 좋습니다. 다음 섹션에서는 이러한 권장사항에 대해 설명합니다.

최소 권한의 원칙 적용

CMEK 관리 권한을 할당할 때는 최소 권한의 원칙을 고려해서 태스크 수행에 필요한 최소 권한을 부여해야 합니다. 기본 역할은 사용하지 않는 것이 좋습니다. 대신 초과 권한 액세스와 관련된 보안 사고 위험을 줄이기 위해 사전 정의된 Cloud KMS 역할을 부여하세요.

이러한 원칙의 위반 사례 및 관련 문제는 IAM에 대한 Security Command Center 취약성 발견 항목에서 자동으로 감지할 수 있습니다.

책임 구분 계획

암호화 키를 관리하는 사람과 이를 사용하는 사람에 대해 ID와 권한을 구분해야 합니다. NIST SP 800-152에서는 암호화 키 관리 시스템의 서비스를 사용 설정 및 관리하는 암호화 관리자와 이러한 키를 사용해서 리소스를 암호화 또는 복호화하는 사용자 사이의 책임 구분을 정의합니다.

CMEK를 사용하여 Google Cloud 서비스에서 저장 데이터 암호화를 관리할 때 암호화 키를 사용하는 IAM 역할은 개별 사용자가 아닌 Google Cloud 서비스의 서비스 에이전트에 할당됩니다. 예를 들어 암호화된 Cloud Storage 버킷에서 객체를 만들려면 사용자에게 IAM 역할 roles/storage.objectCreator만 필요하고 동일 프로젝트의 Cloud Storage 서비스 에이전트 (예: service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)에게는 IAM 역할 roles/cloudkms.cryptoKeyEncrypterDecrypter가 필요합니다.

다음 표에서는 직무 기능과 IAM 역할의 일반적인 연결 관계를 보여줍니다.

IAM 역할	설명	NIST SP 800-152 지정
roles/cloudkms.admin	제한된 리소스 유형 및 암호화 작업에 대한 액세스를 제외하고 Cloud KMS 리소스에 대한 액세스를 제공합니다.	암호화 담당자
roles/cloudkms.cryptoKeyEncrypterDecrypter	encrypt 및 decrypt 작업에 대해서만 Cloud KMS 리소스를 사용할 수 있는 기능을 제공합니다.	암호화 키 관리 시스템 사용자
roles/cloudkms.viewer	get 및 list 작업을 사용 설정합니다.	감사 관리자

이러한 원칙의 위반 사례 및 관련 문제는 Cloud KMS에 대한 Security Command 취약점 발견 항목에서 자동으로 감지할 수 있습니다.

일관적인 CMEK 적용

다음 섹션에서는 일관적이지 않은 키 사용 또는 사고로 인한 삭제 또는 파괴와 같은 위험을 해결하는 데 도움이 되는 추가적인 제어 수단에 대해 설명합니다.

프로젝트 선취권 적용

실수로 인한 삭제를 방지하기 위해 선취권을 통해 프로젝트를 보호하는 것이 좋습니다. 프로젝트 선취권이 적용된 경우 선취권이 삭제될 때까지 Cloud KMS 키 프로젝트의 삭제가 차단됩니다.

CMEK 키 요구

조직 정책 제약 조건을 사용하여 환경 전체에 CMEK 사용을 적용하는 것이 좋습니다.

CMEK 키를 지정하지 않고 constraints/gcp.restrictNonCmekServices를 사용하여 특정 리소스 유형 만들기 요청을 차단합니다.

최소 폐기 예약 기간 필요

최소 폐기 예약 기간을 설정하는 것이 좋습니다. 키 폐기는 데이터 손실을 유발할 수 있는 되돌릴 수 없는 작업입니다. 기본적으로 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 인벤토리 API를 사용하여 키 사용을 확인하여 조직에서 Cloud KMS 키에 종속되고 보호되는 리소스를 식별할 수 있습니다. Google Cloud 이 대시보드를 사용하여 키 버전의 상태, 사용, 가용성과 보호되는 해당 리소스를 모니터링할 수 있습니다. 또한 이 대시보드에서 사용 중지 또는 삭제된 키로 인해 액세스할 수 없는 데이터를 식별하여 액세스할 수 없는 데이터를 삭제하거나 키를 다시 사용 설정하는 등의 작업을 수행할 수 있습니다.

Cloud KMS와 함께 Cloud Monitoring을 사용하여 키 폐기 예약과 같은 중요 이벤트의 알림을 설정할 수 있습니다. Cloud Monitoring을 사용하면 특정 작업이 수행된 이유를 분석하고 필요에 따라 키를 복원하기 위한 선택적인 다운스트림 프로세스를 트리거할 수 있습니다.

중요한 이벤트를 자동으로 감지하는 운영 계획을 설정하고 키 사용 대시보드를 주기적으로 검토하는 것이 좋습니다.

Cloud KMS 취약성 발견 항목에 대한 Security Command Center 사용 설정

Security Command Center는 Cloud KMS 및 기타 리소스와 관련된 구성 오류를 강조 표시하는 취약성 발견 항목을 생성합니다. Security Command Center를 사용 설정하고 이러한 발견 항목을 기존 보안 운영에 통합하는 것이 좋습니다. 이러한 발견 항목에는 공개적으로 액세스 가능한 Cloud KMS 키, Cloud KMS 프로젝트와 초과 권한이 부여된 owner 역할 또는 책임 구분을 위반하는 IAM 역할과 같은 문제가 포함됩니다.

규정 준수 요구사항 평가

각 규정 준수 프레임워크에는 암호화 및 키 관리에 대해 서로 다른 요구사항이 포함되어 있습니다. 규정 준수 프레임워크에는 일반적으로 대략적인 원칙과 암호화 키 관리 목표가 기술되어 있지만 규정 준수를 달성하기 위한 특정 제품 또는 구성이 명시되지 않습니다. 규정 준수 프레임워크의 요구사항을 파악하고 키 관리를 포함하여 이러한 요구사항을 충족하는 방법은 사용자가 선택해야 합니다.

서비스가 다양한 규정 준수 프레임워크의 요구사항을 충족하는 데 어떻게 도움이 되는지 알아보려면 Google Cloud 다음 리소스를 참고하세요.

• Google Cloud에서 의료 데이터 보호하기
• 클라우드 규정 준수 및 규제 관련 리소스
• Google Cloud FedRAMP 구현 가이드
• PCI 데이터 보안 표준 규정 준수

권장사항 요약

다음 표에서는 이 문서에 설명된 권장사항을 요약해서 보여줍니다.

주제	작업
CMEK 사용 여부 결정	CMEK로 사용 설정된 기능이 필요하면 CMEK를 사용합니다.
수동 또는 자동 키 생성 선택	Autokey로 생성된 키 특성으로 요구가 충족될 경우 Cloud KMS Autokey를 사용합니다.
Cloud KMS 키 프로젝트	각 환경에 하나의 중앙화된 키 프로젝트를 사용합니다. 키로 보호되는 리소스와 동일한 프로젝트에 Cloud KMS 리소스를 만들지 마세요. Google Cloud
Cloud KMS 키링	Google Cloud리소스를 보호하려는 각 위치에 Cloud KMS 키링을 만듭니다.
키 세분성	필요에 맞는 키 세분성 패턴을 선택하거나 Autokey를 사용해서 각 서비스의 권장 세분성으로 키를 자동으로 프로비저닝합니다.
보호 수준	키 자료를 Google Cloud외부에 저장해야 하는 경우 Cloud EKM을 선택합니다. 키 자료를 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 사용 프로세스 지원 방법 알아보기