Autokey 개요

Cloud KMS Autokey는 프로비저닝 및 할당을 자동화하여 고객 관리 암호화 키(CMEK)를 만들고 사용하는 것을 간소화합니다. Autokey를 사용하면 키링과 키가 필요에 따라 생성됩니다. 키를 사용하여 리소스를 암호화 및 복호화하는 서비스 계정이 생성되고 필요한 경우 Identity and Access Management(IAM) 역할이 부여됩니다. Cloud KMS 관리자는 각 리소스를 미리 계획하고 만들 필요 없이 Autokey로 생성된 키에 대한 완전한 제어 및 가시성을 유지할 수 있습니다. Autokey 사용은 직접 키를 프로비저닝하는 것보다 간단하며 Autokey로 생성된 키가 모든 요구사항을 충족할 경우에 권장되는 방법입니다.

Autokey에서 생성된 키를 사용하면 멀티 테넌트 Cloud HSM 보호 수준, 업무 분장, 키 순환, 위치, 키 특이성을 포함한 데이터 보안의 업계 표준 및 권장사항을 일관되게 조정할 수 있습니다. Autokey는 Cloud KMS Autokey와 통합되는Google Cloud 서비스의 리소스 유형과 관련된 일반 가이드라인과 가이드라인을 모두 따르는 키를 만듭니다. 키가 생성된 후 Autokey를 사용하여 요청된 키는 동일한 설정을 사용하는 다른 Cloud HSM 키와 동일하게 작동합니다.

Autokey는 승격된 키 생성 권한으로 코드형 인프라를 실행할 필요가 없어 관리를 위한 Terraform 사용을 간소화합니다.

전용 프로젝트 키 저장소 (이전 명칭: 중앙 집중식 키 관리) 또는 동일 프로젝트 키 저장소(이전 명칭: 위임된 키 관리)와 함께 Autokey를 사용할 수 있습니다. 전용 프로젝트 키 스토리지와 함께 Autokey를 사용하려면 폴더 리소스가 포함된 조직 리소스가 있어야 합니다. 전용 프로젝트 키 스토리지를 사용하면 폴더 내 프로젝트에 Autokey가 사용 설정되고 Autokey로 생성된 키가 해당 폴더의 지정된 키 프로젝트에 생성됩니다. 동일 프로젝트 키 저장소를 사용하는 경우 폴더 또는 프로젝트에서 Autokey를 사용 설정하여 Autokey가 보호하는 리소스와 동일한 프로젝트에 키를 만들 수 있습니다.

조직 및 폴더 리소스에 대한 자세한 내용은 리소스 계층 구조를 참조하세요.

Cloud KMS Autokey는 Cloud HSM을 사용할 수 있는 모든 Google Cloud 위치에서 사용할 수 있습니다. Cloud KMS 위치에 대한 자세한 내용은 Cloud KMS 위치를 참고하세요. Cloud KMS Autokey를 사용하는 데 추가 비용이 들지 않습니다. Autokey를 사용하여 생성된 키에는 다른 Cloud HSM 키와 동일한 가격이 책정됩니다. 가격 책정에 대한 자세한 내용은 Cloud Key Management Service 가격 책정을 참고하세요.

Autokey 작동 방식

이 섹션에서는 Cloud KMS Autokey의 작동 방식을 설명합니다. 다음 사용자 역할이 이 프로세스에 참여합니다.

관리자
관리자는 폴더 또는 조직 수준에서 보안을 관리할 책임이 있는 사용자입니다.nk
Autokey 개발자
Autokey 개발자는 Cloud KMS Autokey를 사용하여 리소스를 만들어야 하는 사용자입니다.
Cloud KMS 관리자
Cloud KMS 관리자는 Cloud KMS 리소스를 관리하는 사용자입니다. 이 역할은 수동으로 생성된 키를 사용할 때보다 Autokey를 사용할 때의 책임이 더 적습니다.

다음 서비스 에이전트도 이 프로세스에 참여합니다.

Cloud KMS 서비스 에이전트
특정 키 프로젝트의 Cloud KMS용 서비스 에이전트입니다. Autokey는 승격된 권한을 가진 이러한 서비스 에이전트를 사용하여 Cloud KMS 키 및 키링을 만들고 키에 IAM 정책을 설정하여 각 리소스 서비스 에이전트에 암호화 및 복호화 권한을 부여합니다.
리소스 서비스 에이전트
특정 리소스 프로젝트의 특정 서비스에 대한 서비스 에이전트입니다. 이 서비스 에이전트는 Cloud KMS 키에 대한 암호화 및 복호화 권한이 있어야 리소스에서 CMEK 보호에 해당 키를 사용할 수 있습니다. Autokey는 리소스 서비스 에이전트를 만들고 필요 시 Cloud KMS 키를 사용하는 데 필요한 권한을 부여합니다.

관리자의 Cloud KMS Autokey 사용 설정

Autokey를 사용 설정하려면 선택한 키 저장 모델에 따라 다음 경로 중 하나를 선택하세요.

  1. 전용 프로젝트 키 저장: 폴더에서 전용 프로젝트 키 저장을 사용 설정합니다. 폴더 내 다른 프로젝트에서 생성된 리소스를 보호하는 키를 보유할 전용 키 프로젝트를 지정합니다.
  2. 동일 프로젝트 키 저장: 개별 프로젝트 또는 폴더 내 모든 프로젝트에서 동일 프로젝트 키 저장을 사용 설정하여 보호하는 리소스와 동일한 프로젝트에 키를 만듭니다.

전용 프로젝트 키 저장 사용 설정

폴더에서 전용 프로젝트 키 스토리지를 사용하여 Autokey를 사용하려면 먼저 관리자가 다음 일회성 설정 작업을 완료해야 합니다.

  1. 폴더에서 전용 프로젝트 키 스토리지를 사용하여 Autokey를 사용 설정하고 해당 폴더의 Autokey 리소스가 포함될 Cloud KMS 프로젝트를 식별합니다.

  2. Cloud KMS 서비스 에이전트를 만든 후 서비스 에이전트에 키 생성 및 할당 권한을 부여합니다.

이 구성이 완료되면 해당 폴더의 모든 프로젝트에서 Autokey 호환 리소스를 만들 수 있는 개발자가 이제 주문형으로 멀티 테넌트 Cloud HSM 키 생성을 트리거할 수 있습니다. Cloud KMS Autokey의 전체 설정 안내를 보려면 Cloud KMS Autokey 사용 설정을 참고하세요.

동일 프로젝트 키 저장으로 Autokey 사용 설정

동일한 프로젝트 키 저장소와 함께 Autokey를 사용하려면 먼저 관리자가 다음 일회성 설정 작업을 완료해야 합니다.

  1. 프로젝트 또는 폴더에서 동일 프로젝트 키 저장소를 사용하여 Autokey를 사용 설정합니다.
  2. 해당 프로젝트 또는 폴더의 프로젝트에서 Cloud KMS API를 사용 설정합니다.

프로젝트에서 동일 프로젝트 키 저장소로 Autokey를 사용 설정하면 필요할 때 Cloud KMS 서비스 에이전트가 생성됩니다. 서비스 에이전트를 수동으로 만들 필요가 없습니다. Autokey 호환 리소스를 만들 권한이 있는 사용자는 주문형으로 새 키를 요청할 수 있습니다. Cloud KMS Autokey의 전체 설정 안내를 보려면 Cloud KMS Autokey 사용 설정을 참고하세요.

Autokey 개발자의 Cloud KMS Autokey 사용

프로젝트에 Autokey가 사용 설정되면 Autokey 개발자가 주문형으로 생성된 키를 사용하여 보호되는 리소스를 만들 수 있습니다. 이는 전용 프로젝트 키 스토리지가 사용 설정된 Autokey가 있는 폴더의 프로젝트와 동일 프로젝트 키 스토리지가 사용 설정된 Autokey가 있는 프로젝트 모두에 적용됩니다. 리소스 생성 프로세스의 세부정보는 만들려는 리소스에 따라 다르지만 프로세스는 다음 흐름을 따릅니다.

  1. Autokey 개발자가 호환되는Google Cloud 서비스에서 리소스를 만들기 시작합니다. 리소스를 생성하는 동안 개발자는 Autokey 서비스 에이전트에 새 키를 요청합니다.

  2. Autokey 서비스 에이전트는 개발자의 요청을 수신하고 다음 단계를 완료합니다.

    1. 선택한 위치의 프로젝트에 키링을 만듭니다(아직 키링이 없는 경우).
    2. 리소스 유형에 적합한 세분성으로 키링에 키를 만듭니다(아직 키가 없는 경우).
    3. 프로젝트별, 서비스별 서비스 계정을 만듭니다(아직 서비스 계정이 없는 경우).
    4. 프로젝트별, 서비스별 서비스 계정에 키에 대한 암호화 및 복호화 권한을 부여합니다.
    5. 개발자가 리소스 만들기를 완료할 수 있도록 주요 세부정보를 개발자에게 제공합니다.

  3. Autokey 서비스 에이전트가 키 세부정보를 성공적으로 반환하면 개발자는 보호된 리소스 만들기를 즉시 완료할 수 있습니다.

Cloud KMS Autokey는 다음 섹션에서 설명하는 속성이 포함된 키를 만듭니다. 이 키 만들기 흐름을 통해 업무 분장을 유지할 수 있습니다. Cloud KMS 관리자는 Autokey로 생성된 키를 계속 완벽하게 파악하고 제어할 수 있습니다.

Autokey를 사용 설정한 후 사용하려면 Cloud KMS Autokey를 사용하여 보호되는 리소스 만들기를 참고하세요.

Autokey로 생성되는 키 정보

Cloud KMS Autokey에서 만든 키에는 다음과 같은 속성이 있습니다.

  • 보호 수준: 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 대시보드에서 추적됩니다.

Autokey 사용 제어

다음 제어를 사용하여 조직에서 Autokey가 사용되는 방식을 관리할 수 있습니다.

  • Autokey 구성: Autokey를 사용하려는 폴더 또는 프로젝트에서 Autokey를 사용 설정합니다. Autokey 구성은 하위 리소스에 상속되지만 하위 수준에서 설정된 구성으로 재정의될 수 있습니다. 예를 들어 프로젝트에 설정된 Autokey 구성이 상위 폴더의 구성보다 우선합니다. 이렇게 하면 Autokey를 하향식으로 제어할 수 있습니다. Autokey 사용 설정 및 사용 중지에 대한 자세한 내용은 Cloud KMS Autokey 사용 설정을 참고하세요.
  • IAM: IAM 역할 부여 및 거부 정책을 사용하여 Autokey 구성을 만들고 업데이트할 수 있는 사용자와 Autokey를 사용하여 보호되는 리소스를 만들 수 있는 사용자를 제어합니다. 이러한 IAM 제어는 조직, 폴더 또는 프로젝트 수준에서 설정할 수 있습니다. IAM 역할 부여를 통해 주 구성원은 역할에서 허용하는 작업을 수행할 수 있습니다. IAM 거부 정책은 주 구성원에게 부여된 역할에 포함되어 있더라도 개별 권한을 차단합니다. 상위 리소스에 설정된 IAM 거부 정책은 하위 수준에 설정된 더 허용적인 정책으로 재정의할 수 없습니다. 따라서 자동 키를 사용 설정하고 사용할 수 있는 사용자를 하향식으로 제어할 수 있습니다. IAM 거부 정책을 사용하여 조직에서 자동 키 사용을 제어하는 방법에 대한 자세한 내용은 IAM 거부 정책을 사용하여 자동 키 제어를 참고하세요.
  • 조직 정책: 커스텀 조직 정책 제약 조건을 사용하여 Autokey를 구성할 수 있는 위치와 방법을 제어합니다. 조직, 폴더 또는 프로젝트 수준에서 조직 정책 제약 조건을 적용할 수 있습니다. 조직 정책은 하위 리소스에 의해 상속되지만 하위 수준에서 적용되는 정책에 의해 재정의될 수 있습니다. 커스텀 조직 정책 제약 조건을 사용하여 조직에서 자동 키 사용을 제어하는 방법에 대한 자세한 내용은 커스텀 조직 정책 제약 조건을 사용하여 자동 키 제어 를 참고하세요.

호환 서비스

다음 표에는 Cloud KMS Autokey와 호환되는 서비스가 나와 있습니다.

서비스 보호되는 리소스 키 세분성
PostgreSQL용 AlloyDB
  • alloydb.googleapis.com/Cluster
  • alloydb.googleapis.com/Backup

PostgreSQL용 AlloyDB와 Cloud KMS Autokey 간 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 리소스당 키 1개
Apigee
  • apigee.googleapis.com/Organization
  • apigee.googleapis.com/Instance

Apigee와 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 리소스당 키 1개
Apigee API 허브
  • apihub.googleapis.com/ApiHubInstance

Apigee API 허브와 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 리소스당 키 1개
Artifact Registry
  • artifactregistry.googleapis.com/Repository

Autokey는 저장된 모든 아티팩트에 사용되는 저장소 생성 중에 키를 만듭니다.

 리소스당 키 1개
BigQuery
  • bigquery.googleapis.com/Dataset

Autokey는 데이터 세트의 기본 키를 만듭니다. 데이터 세트 내의 테이블, 모델, 쿼리, 임시 테이블은 데이터 세트 기본 키를 사용합니다.

Autokey는 데이터 세트가 아닌 BigQuery 리소스의 키를 만들지 않습니다. 데이터 세트에 포함되지 않은 리소스를 보호하려면 프로젝트 또는 조직 수준에서 자체 기본 키를 만들어야 합니다.

 리소스당 키 1개
Bigtable
  • bigtableadmin.googleapis.com/Cluster

Autokey는 클러스터의 키를 만듭니다.

Autokey는 클러스터가 아닌 Bigtable 리소스의 키를 만들지 않습니다.

Bigtable과 Cloud KMS Autokey 간의 통합은 Terraform 또는 Google Cloud SDK를 사용하여 만든 리소스에만 사용할 수 있습니다.

 클러스터당 키 1개
Cloud Run
  • run.googleapis.com/Service
  • run.googleapis.com/Job
 프로젝트 내 위치당 키 1개
Cloud SQL
  • sqladmin.googleapis.com/Instance

Autokey는 Cloud SQL BackupRun 리소스의 키를 만들지 않습니다. Cloud SQL 인스턴스의 백업을 만들면 기본 인스턴스의 고객 관리 키로 백업이 암호화됩니다.

Cloud SQL과 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 리소스당 키 1개
Cloud Storage
  • storage.googleapis.com/Bucket

스토리지 버킷 내의 객체는 버킷 기본 키를 사용합니다. Autokey는 storage.object 리소스의 키를 만들지 않습니다.

 버킷당 키 1개
Compute Engine
  • compute.googleapis.com/Disk
  • compute.googleapis.com/Image
  • compute.googleapis.com/Instance
  • compute.googleapis.com/MachineImage

스냅샷은 스냅샷을 만들 디스크의 키를 사용합니다. Autokey는 compute.snapshot 리소스의 키를 만들지 않습니다.

 리소스당 키 1개
Google Kubernetes Engine
  • container.googleapis.com/Cluster

Google Kubernetes Engine과 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 클러스터당 키 1개
Dataflow
  • dataflow.googleapis.com/Job
 리소스당 키 1개
Apache Airflow용 관리형 서비스
  • composer.googleapis.com/Environment

Managed Service for Apache Airflow와 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 리소스당 키 1개
Managed Service for Apache Spark
  • dataproc.googleapis.com/Cluster
  • dataproc.googleapis.com/SessionTemplate
  • dataproc.googleapis.com/WorkflowTemplate
  • dataproc.googleapis.com/Batch
  • dataproc.googleapis.com/Session

클러스터, SessionTemplate, WorkflowTemplate 리소스의 경우: 리소스당 키 1개

일괄 및 세션 리소스: 프로젝트 내 위치당 키 1개
Memorystore for Redis
  • redis.googleapis.com/Instance
  • redis.googleapis.com/Cluster

Redis용 Memorystore와 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 리소스당 키 1개
Pub/Sub
  • pubsub.googleapis.com/Topic
 리소스당 키 1개
Secret Manager
  • secretmanager.googleapis.com/Secret

Secret Manager와 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 프로젝트 내 위치당 키 1개
Secure Source Manager
  • securesourcemanager.googleapis.com/Instance
 리소스당 키 1개
Spanner
  • spanner.googleapis.com/Database

Spanner와 Cloud KMS Autokey 간의 통합은 Terraform 또는 REST API를 사용하여 만든 리소스에만 사용할 수 있습니다.

 리소스당 키 1개
Filestore
  • file.googleapis.com/Instance
  • file.googleapis.com/Backup
 리소스당 키 1개

제한사항

다음 단계