Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Visão geral do Autokey

O Autokey do Cloud KMS simplifica a criação e o uso de chaves de criptografia gerenciadas pelo cliente (CMEKs) automatizando o provisionamento e a atribuição. Com o Autokey, keyrings e chaves são gerados sob demanda. As contas de serviço que usam as chaves para criptografar e descriptografar recursos são criadas e recebem papéis do Identity and Access Management (IAM) quando necessário. Os administradores do Cloud KMS mantêm controle e visibilidade total das chaves criadas pelo Autokey, sem precisar planejar e criar cada recurso. Usar a Autokey é mais simples do que provisionar chaves por conta própria e é a opção recomendada se as chaves criadas pela Autokey atendem a todos os seus requisitos.

O uso das chaves geradas pelo Autokey pode ajudar você a se alinhar de maneira consistente aos padrões do setor e às práticas recomendadas de segurança de dados, incluindo o nível de proteção do Cloud HSM multitenant, a segregação de funções, a rotação de chaves, a localização e a especificidade da chave. O Autokey cria chaves que seguem diretrizes gerais e específicas do tipo de recurso para serviçosCloud de Confiance que se integram ao Autokey do Cloud KMS. Depois de criadas, as chaves solicitadas usando a função Autokey funcionam de maneira idêntica a outras chaves do Cloud HSM com as mesmas configurações.

O Autokey também pode simplificar o uso do Terraform para gerenciamento de chaves, removendo a necessidade de executar infraestrutura como código com privilégios elevados de criação de chaves.

É possível usar o Autokey com armazenamento de chaves em projeto dedicado (antes conhecido como gerenciamento centralizado de chaves) ou com armazenamento de chaves no mesmo projeto (antes conhecido como gerenciamento delegado de chaves). Para usar o Autokey com armazenamento de chaves de projeto dedicado, você precisa ter um recurso de organização que contenha um recurso de pasta. Ao usar o armazenamento de chaves em projetos dedicados, você ativa o Autokey para projetos em uma pasta, e as chaves criadas pelo Autokey são criadas no projeto de chave designado para essa pasta. Ao usar o armazenamento de chaves no mesmo projeto, você ativa o Autokey em uma pasta ou projeto para que ele crie chaves no mesmo projeto dos recursos que elas protegem.

Para mais informações sobre recursos de organização e pasta, consulte Hierarquia de recursos.

O Autokey do Cloud KMS está disponível em todos os locais Cloud de Confiance em que o Cloud HSM está disponível. Para mais informações sobre os locais do Cloud KMS, consulte Locais do Cloud KMS. Não há custo adicional para usar o Autokey do Cloud KMS. As chaves criadas com a chave automática têm o mesmo preço que qualquer outra chave do Cloud HSM. Para mais informações sobre preços, consulte Preços do Cloud Key Management Service.

Como o Autokey funciona

Esta seção explica como o Autokey do Cloud KMS funciona. As seguintes funções de usuário participam desse processo:

Administrador: O administrador é um usuário responsável por gerenciar a segurança no nível da pasta ou da organização.nk
Desenvolvedor do Autokey: O desenvolvedor do Autokey é um usuário responsável por criar recursos usando o Autokey do Cloud KMS.
Administrador do Cloud KMS: O administrador do Cloud KMS é um usuário responsável por gerenciar recursos do Cloud KMS. Essa função tem menos responsabilidades ao usar o Autokey do que ao usar chaves criadas manualmente.

Os seguintes agentes de serviço também participam desse processo:

Agente de serviço do Cloud KMS: O agente de serviço do Cloud KMS em um projeto de chave específico. O Autokey depende de que esse agente de serviço tenha privilégios elevados para criar chaves e keyrings do Cloud KMS e definir a política do IAM nas chaves, concedendo permissões de criptografia e descriptografia para cada agente de serviço de recurso.
Agente de serviço de recursos: O agente de serviço de um determinado serviço em um determinado projeto de recurso. Esse agente de serviço precisa ter permissões de criptografia e descriptografia em qualquer chave do Cloud KMS antes de poder usar essa chave para proteção de CMEK em um recurso. O Autokey cria o agente de serviço de recursos quando necessário e concede a ele as permissões necessárias para usar a chave do Cloud KMS.

O administrador ativa o Autokey do Cloud KMS

Para ativar o Autokey, escolha um dos seguintes caminhos com base no modelo de armazenamento de chaves escolhido:

Armazenamento de chaves em projeto dedicado: ative o armazenamento de chaves em projeto dedicado em uma pasta. Você designa um projeto de chave dedicado para armazenar as chaves que protegem os recursos criados em outros projetos na pasta.
Armazenamento de chaves no mesmo projeto: ative o armazenamento de chaves no mesmo projeto em projetos individuais ou em todos os projetos de uma pasta para criar chaves no mesmo projeto que os recursos protegidos.

Ativar o armazenamento de chaves em projeto dedicado

Antes de usar o Autokey com armazenamento de chaves de projeto dedicado em uma pasta, um administrador precisa concluir as seguintes tarefas de configuração única:

Ative o Autokey com armazenamento de chaves em um projeto dedicado na pasta e identifique o projeto do Cloud KMS que vai conter os recursos do Autokey para essa pasta.
Crie o agente de serviço do Cloud KMS e conceda a ele privilégios de criação e atribuição de chaves.

Depois que essa configuração for concluída, os desenvolvedores que puderem criar recursos compatíveis com o Autokey em qualquer projeto nessa pasta poderão acionar a criação de chaves do Cloud HSM multitenant sob demanda. Para conferir as instruções completas de configuração do Autokey do Cloud KMS, consulte Habilitar o Autokey do Cloud KMS.

Ativar o Autokey com armazenamento de chaves no mesmo projeto

Antes de usar o Autokey com o armazenamento de chaves no mesmo projeto, um administrador precisa concluir as seguintes tarefas de configuração única:

Ative o Autokey com armazenamento de chaves no mesmo projeto em um projeto ou pasta.
Ative a API Cloud KMS no projeto ou nos projetos da pasta.

Quando você ativa o Autokey com armazenamento de chaves no mesmo projeto, o agente de serviço do Cloud KMS é criado para você quando necessário. Não é necessário criar o agente de serviço manualmente. Qualquer usuário com permissões para criar um recurso compatível com Autokey pode solicitar uma nova chave sob demanda. Para conferir as instruções completas de configuração do Autokey do Cloud KMS, consulte Habilitar o Autokey do Cloud KMS.

Os desenvolvedores do Autokey usam o Autokey do Cloud KMS

Depois que o Autokey é ativado em um projeto, os desenvolvedores podem criar recursos protegidos usando chaves criadas para eles sob demanda. Isso se aplica a projetos em uma pasta em que o Autokey com armazenamento de chaves em projeto dedicado está ativado e a projetos em que o Autokey com armazenamento de chaves no mesmo projeto está ativado. Os detalhes do processo de criação de recursos dependem do recurso que você está criando, mas o processo segue este fluxo:

O desenvolvedor do Autokey começa a criar um recurso em um Cloud de Confiance service compatível. Durante a criação de recursos, o desenvolvedor solicita uma nova chave do agente de serviço do Autokey.
O agente de serviço do Autokey recebe a solicitação do desenvolvedor e conclui as seguintes etapas:
1. Crie um keyring no projeto no local selecionado, a menos que ele já exista.
2. Crie uma chave no keyring com a granularidade adequada para o tipo de recurso, a menos que ela já exista.
3. Crie a conta de serviço por projeto e por serviço, a menos que ela já exista.
4. Conceda as permissões de criptografia e descriptografia por projeto e por serviço à conta de serviço na chave.
5. Forneça os detalhes principais ao desenvolvedor para que ele possa concluir a criação do recurso.
Com os detalhes da chave retornados pelo agente do serviço Autokey, o desenvolvedor pode concluir imediatamente a criação do recurso protegido.

O Autokey do Cloud KMS cria chaves com os atributos descritos na próxima seção. Esse fluxo de criação de chaves preserva a segregação de funções. O administrador do Cloud KMS continua tendo total visibilidade e controle sobre as chaves criadas pelo Autokey.

Para começar a usar o Autokey depois de ativá-lo, consulte Criar recursos protegidos usando o Autokey do Cloud KMS.

Sobre as chaves criadas pelo Autokey

As chaves criadas pelo Autokey do Cloud KMS têm os seguintes atributos:

Nível de proteção:HSM.
Algoritmo:AES-256 GCM.
Período de rotação:um ano.

Depois que uma chave é criada pelo Autokey, um administrador do Cloud KMS pode editar o período de rotação do padrão.
Segregação de funções:
- A conta de serviço do serviço recebe automaticamente permissões de criptografia e descriptografia na chave.
- As permissões de administrador do Cloud KMS se aplicam normalmente às chaves criadas pelo Autokey. Os administradores do Cloud KMS podem visualizar, atualizar, ativar ou desativar e destruir chaves criadas pelo Autokey. Os administradores do Cloud KMS não recebem permissões de criptografia e descriptografia.
- Os desenvolvedores da Autokey só podem solicitar a criação e atribuição de chaves. Não é possível ver nem gerenciar chaves.
Especificidade ou granularidade da chave:as chaves criadas pelo Autokey têm uma granularidade que varia de acordo com o tipo de recurso. Para detalhes específicos do serviço sobre a granularidade da chave, consulte Serviços compatíveis nesta página.
Local:o Autokey cria chaves no mesmo local que o recurso a ser protegido.

Se você precisar criar recursos protegidos por CMEK em locais onde o Cloud HSM não está disponível, crie a CMEK manualmente.
Estado da versão da chave:as chaves recém-criadas solicitadas usando o Autokey são criadas como a versão chave primária no estado ativado.
Nomeação de keyring:todas as chaves criadas pelo Autokey são criadas em um keyring chamado autokey. Os keyrings no seu projeto do Autokey são criados quando um desenvolvedor do Autokey solicita a primeira chave em um determinado local. O keyring autokey é criado no projeto de chave designado se você estiver usando o armazenamento de chaves em projeto dedicado ou no projeto de recurso se estiver usando o armazenamento de chaves no mesmo projeto.
Nomenclatura de chaves:as chaves criadas pelo Autokey seguem esta convenção de nomenclatura: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
Exportação de chaves:assim como todas as chaves do Cloud KMS, as chaves criadas pelo Autokey não podem ser exportadas.
Rastreamento de chaves:como todas as chaves do Cloud KMS usadas em serviços integrados à CMEK compatíveis com o rastreamento de chaves, as chaves criadas pela chave automática são rastreadas no painel do Cloud KMS.

Controlar o uso do Autokey

Você controla como o Autokey é usado na sua organização com os seguintes controles:

Configuração do Autokey: ative o Autokey em pastas ou projetos em que você quer usar o recurso. As configurações de Autokey são herdadas pelos recursos filhos, mas podem ser substituídas por configurações definidas em um nível inferior. Por exemplo, a configuração de Autokey definida em um projeto tem precedência sobre a configuração da pasta mãe. Isso dá a você controle de baixo para cima do Autokey. Para mais informações sobre como ativar e desativar o Autokey, consulte Ativar o Autokey do Cloud KMS.
IAM: você controla quem pode criar e atualizar configurações do Autokey e quem pode criar recursos protegidos usando o Autokey com concessões de função e políticas de negação do IAM. Esses controles do IAM podem ser definidos no nível da organização, da pasta ou do projeto. Com as concessões de papéis do IAM, os principais podem realizar ações permitidas pelo papel deles. As políticas de negação do IAM bloqueiam permissões individuais, mesmo que elas estejam incluídas em um papel concedido ao principal. As políticas de negação do IAM definidas em um recurso pai não podem ser substituídas por políticas mais permissivas definidas em um nível inferior. Isso oferece controle de cima para baixo sobre quem pode ativar e usar o Autokey. Para mais informações sobre como usar políticas de negação do IAM para controlar o uso do Autokey na sua organização, consulte Usar políticas de negação do IAM para controlar o Autokey.
Política da organização: você controla onde e como o Autokey pode ser configurado usando restrições personalizadas da política da organização. É possível aplicar restrições da política da organização no nível da organização, da pasta ou do projeto. As políticas da organização são herdadas pelos recursos filhos, mas podem ser substituídas por políticas aplicadas em um nível inferior. Para mais informações sobre como usar restrições personalizadas de política da organização para controlar o uso do Autokey na sua organização, consulte Usar restrições personalizadas de política da organização para controlar o Autokey .

Serviços compatíveis

A tabela a seguir lista os serviços compatíveis com a chave automática do Cloud KMS:

Serviço	Recursos protegidos	Granularidade da chave
AlloyDB para PostgreSQL	`alloydb.googleapis.com/Cluster` `alloydb.googleapis.com/Backup` A integração entre o AlloyDB para PostgreSQL e o Autokey do Cloud KMS está disponível apenas para recursos criados usando Terraform ou a API REST.	Uma chave por recurso
Apigee	`apigee.googleapis.com/Organization` `apigee.googleapis.com/Instance` A integração entre o Apigee e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por recurso
Hub de APIs da Apigee	`apihub.googleapis.com/ApiHubInstance` A integração entre o hub de APIs da Apigee e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por recurso
Artifact Registry	`artifactregistry.googleapis.com/Repository` O Autokey cria chaves durante a criação do repositório, que são usadas para todos os artefatos armazenados.	Uma chave por recurso
BigQuery	`bigquery.googleapis.com/Dataset` O Autokey cria chaves padrão para conjuntos de dados. Tabelas, modelos, consultas e tabelas temporárias em um conjunto de dados usam a chave padrão do conjunto de dados. O Autokey não cria chaves para recursos do BigQuery que não sejam conjuntos de dados. Para proteger recursos que não fazem parte de um conjunto de dados, crie suas próprias chaves padrão no nível do projeto ou da organização.	Uma chave por recurso
Bigtable	`bigtableadmin.googleapis.com/Cluster` O Autokey cria chaves para clusters. O Autokey não cria chaves para recursos do Bigtable que não sejam clusters. A integração entre o Bigtable e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou o SDK Google Cloud.	Uma chave por cluster
Cloud Run	`run.googleapis.com/Service` `run.googleapis.com/Job`	Uma chave por local em um projeto
Cloud SQL	`sqladmin.googleapis.com/Instance` O Autokey não cria chaves para recursos do Cloud SQL `BackupRun`. Quando você cria um backup de uma instância do Cloud SQL, ele é criptografado com a chave gerenciada pelo cliente da instância principal. A integração entre o Cloud SQL e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por recurso
Cloud Storage	`storage.googleapis.com/Bucket` Os objetos em um bucket de armazenamento usam a chave padrão do bucket. O Autokey não cria chaves para recursos `storage.object`.	Uma chave por bucket
Compute Engine	`compute.googleapis.com/Disk` `compute.googleapis.com/Image` `compute.googleapis.com/Instance` `compute.googleapis.com/MachineImage` Os snapshots usam a chave do disco de que você está criando um snapshot. O Autokey não cria chaves para recursos `compute.snapshot`.	Uma chave por recurso
Google Kubernetes Engine	`container.googleapis.com/Cluster` A integração entre o Google Kubernetes Engine e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por cluster
Dataflow	`dataflow.googleapis.com/Job`	Uma chave por recurso
Serviço gerenciado para Apache Airflow	`composer.googleapis.com/Environment` A integração entre o Serviço Gerenciado para Apache Airflow e a autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por recurso
Serviço Gerenciado para Apache Spark	`dataproc.googleapis.com/Cluster` `dataproc.googleapis.com/SessionTemplate` `dataproc.googleapis.com/WorkflowTemplate` `dataproc.googleapis.com/Batch` `dataproc.googleapis.com/Session`	Para recursos Cluster, SessionTemplate e WorkflowTemplate:uma chave por recurso Para recursos de lote e sessão:uma chave por local em um projeto
Memorystore for Redis	`redis.googleapis.com/Instance` `redis.googleapis.com/Cluster` A integração entre o Memorystore para Redis e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por recurso
Pub/Sub	`pubsub.googleapis.com/Topic`	Uma chave por recurso
Secret Manager	`secretmanager.googleapis.com/Secret` A integração entre o Secret Manager e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por local em um projeto
Secure Source Manager	`securesourcemanager.googleapis.com/Instance`	Uma chave por recurso
Spanner	`spanner.googleapis.com/Database` A integração entre o Spanner e o Autokey do Cloud KMS está disponível apenas para recursos criados usando o Terraform ou a API REST.	Uma chave por recurso
Filestore	`file.googleapis.com/Instance` `file.googleapis.com/Backup`	Uma chave por recurso

Limitações

A CLI gcloud não está disponível para recursos do Autokey.
Os identificadores de chaves não estão no Inventário de recursos do Cloud.

A seguir

Para começar a usar o Autokey do Cloud KMS, um administrador precisa ativar o Autokey do Cloud KMS.
Para usar a chave automática do Cloud KMS depois que ela for ativada, um desenvolvedor pode criar recursos protegidos por CMEK usando a chave automática.
Saiba mais sobre as práticas recomendadas da CMEK.