Criptografia do Cloud Key Management Service

Este conteúdo foi atualizado pela última vez em janeiro de 2025 e representa o estado do momento em que foi escrito. Os sistemas e as políticas de segurança do Google podem mudar no futuro, à medida que a proteção dos clientes é aprimorada.

Este documento descreve como o Cloud Key Management Service (Cloud KMS) fornece serviços de gerenciamento de chaves no Google Cloud para criptografia de dados em repouso. OGoogle Cloud trabalha com a premissa fundamental de que os clientes do Google Cloud são proprietários dos dados e devem controlar o uso deles.

Quando você armazena dados com o Google Cloud, eles são criptografados em repouso por padrão. Ao usar a plataforma Cloud KMS, você tem mais controle sobre como seus dados são criptografados em repouso e como suas chaves de criptografia são gerenciadas.

Este documento se concentra no funcionamento interno da plataforma Cloud KMS. Essas opções ajudam a proteger as chaves e outros dados confidenciais que você armazena em Google Cloud. Este documento destina-se a tomadores técnicos de decisões que precisam de detalhes sobre a arquitetura, a infraestrutura e os recursos do Cloud KMS. Este documento pressupõe que você tenha uma compreensão básica dos conceitos de criptografia e de arquiteturas de nuvem.

Chaves em Google Cloud

A tabela a seguir descreve os diferentes tipos de chaves em Google Cloud.

Tipo de chave	Cloud KMS Autokey	Gerenciamento manual pelo cliente do Cloud KMS	Google-owned and Google-managed encryption key (criptografia padrão do Google)
Pode ver metadados importantes	Sim	Sim	Não
Propriedade das chaves^1	Cliente	Cliente	Google
Pode gerenciar^2 e controlar^3 chaves	A criação e a atribuição de chaves são automatizadas. O controle manual do cliente é totalmente compatível.	Cliente, somente controle manual	Google
Suporte aos requisitos regulamentares para chaves gerenciadas pelo cliente	Sim	Sim	Não
Compartilhamento de chaves	Exclusivo para um cliente	Exclusivo para um cliente	Os dados de vários clientes geralmente são protegidos por chaves de criptografia de chaves (KEKs) compartilhadas.
Controle da rotação de chaves	Sim	Sim	Não
Políticas da organização de CMEK	Sim	Sim	Não
Registrar o acesso administrativo e aos dados das chaves de criptografia	Sim	Sim	Não
Separação lógica de dados por criptografia	Sim	Sim	Não
Preços	Varia	Varia	Grátis

¹ O proprietário da chave indica quem detém os direitos dela. As chaves que você possui têm acesso restrito ou nenhum acesso pelo Google.

² O gerenciamento de chaves inclui as seguintes tarefas:

• Crie chaves.
• Escolha o nível de proteção das chaves.
• Atribua autoridade para o gerenciamento das chaves.
• Controlar o acesso às chaves.
• Controlar o uso de chaves.
• Definir e modificar o período de rotação das chaves ou acionar uma rotação.
• Mudar o status da chave.
• Destruir versões de chaves.

³ O controle de chaves significa definir controles sobre o tipo de chaves e como elas são usadas, detectar variância e planejar ações corretivas, se necessário. Você pode controlar suas chaves, mas delegar o gerenciamento delas a terceiros.

Princípios do Cloud KMS

Com o Cloud KMS, o objetivo do Google é fornecer uma solução escalonável, confiável e de alto desempenho, com o conjunto mais amplo de opções de controle. O Cloud KMS é compatível com os seguintes princípios:

• Controle do cliente: o Cloud KMS permite controlar suas próprias chaves de software e hardware para criptografia e assinatura. Esse pilar inclui suporte para trazer suas próprias chaves (BYOK) e segurar as próprias chaves (HYOK).
• Controle de acesso e monitoramento: com o Cloud KMS, você pode gerenciar permissões em chaves individuais e monitorar como as chaves são usadas.
• Regionalidade: o Cloud KMS oferece regionalização pronta para uso. O serviço foi configurado para criar, armazenar e processar chaves somente no local Google Cloud selecionado.
• Backups: para proteger contra corrupção de dados e verificar se os dados podem ser descriptografados com sucesso, o Cloud KMS verifica periodicamente e faz backup de todo o material e metadados da chave.
• Segurança: o Cloud KMS oferece proteção forte contra acesso não autorizado às chaves. Além disso, ele é totalmente integrado aos controles de gerenciamento de identidade e acesso (IAM) e do Cloud Audit Logs.
• Separação lógica de dados:a criptografia do Cloud KMS oferece separação lógica de dados por criptografia. A separação lógica de dados significa que os proprietários de dados não compartilham chaves de criptografia (KEKs e DEKs).

Fontes e opções de gerenciamento de chaves criptográficas

A plataforma Cloud KMS permite gerenciar chaves criptográficas em um serviço de nuvem central para uso direto ou por outros recursos e aplicativos de nuvem.

O portfólio Google Cloud para chaves inclui o seguinte:

• Criptografia padrão: todos os dados armazenados pelo Google são criptografados na camada de armazenamento pelo algoritmo padrão de criptografia avançada (AES, na sigla em inglês), AES-256. Geramos e gerenciamos as chaves para criptografia padrão, e os clientes não têm acesso às chaves ou ao controle de rotação e gerenciamento de chaves. As chaves de criptografia padrão podem ser compartilhadas entre os clientes. Para mais informações, consulte Criptografia padrão em repouso.

• Cloud KMS com chaves protegidas por software:é possível controlar as chaves geradas no Cloud KMS. O back-end do software Cloud KMS oferece a flexibilidade de criptografar ou assinar seus dados com uma chave simétrica ou assimétrica que você controla.

• Cloud KMS com chaves protegidas por hardware (Cloud HSM): usando o Cloud KMS com o back-end do Cloud HSM, você pode ter chaves que são geradas e armazenadas em módulos de segurança de hardware (HSMs, na sigla em inglês) pertencentes e operadas pelo Google. Se você precisar de uma chave protegida por hardware, use o back-end do Cloud HSM para garantir que suas chaves sejam usadas apenas no Nível 3 do FIPS 140-2 HSMs validados. É possível provisionar chaves protegidas por hardware usando um método manual que exige um administrador do Cloud KMS ou automaticamente usando a chave automática do Cloud KMS. Com a Autokey, é possível automatizar os processos de provisionamento e atribuição de chaves de criptografia gerenciadas pelo cliente (CMEK). As chaves de HSM convencionais exigem que um administrador do KMS crie as chaves sob demanda.

• Cloud KMS com importação de chaves: para atender aos requisitos de BYOK, importe as próprias chaves criptográficas geradas por você. É possível usar e gerenciar essas chaves fora do Google Cloude usar o material da chave no Cloud KMS para criptografar ou assinar dados armazenados no Google Cloud.

• Cloud KMS com gerenciador de chaves externas (Cloud EKM): para atender aos requisitos de HYOK, é possível criar e controlar chaves armazenadas em um gerenciador de chaves externo ao Google Cloud. Em seguida, você configura a plataforma Cloud KMS para usar as chaves externas e ajudar a proteger os dados em repouso. É possível usá-las com uma chave do Cloud EKM. Para mais informações sobre o gerenciamento de chaves externas e o Cloud EKM, consulte Arquiteturas de referência para o Cloud EKM.

É possível usar chaves geradas pelo Cloud KMS com outros serviços doGoogle Cloud . Essas chaves são conhecidas como CMEKs. O recurso CMEK permite gerar, usar, rotacionar e destruir chaves de criptografia que ajudam a proteger seus dados em outros serviços do Google Cloud. Ao usar a CMEK com os serviços do Google Cloud , o acesso e o rastreamento de chaves são gerenciados para você.

Criptografia e gerenciamento de chaves no Google

Nesta seção, definimos alguns termos para o gerenciamento de chaves no contexto da infraestrutura de gerenciamento de chaves em várias camadas do Google.

Keyrings, chaves e versões de chaves

O diagrama a seguir ilustra agrupamentos de chaves e mostra keyrings e chaves com uma única versão primária e várias versões anteriores.

Os conceitos mostrados no diagrama anterior são os seguintes:

• Chave: um objeto nomeado que representa uma chave criptográfica usada para uma finalidade específica. O material de chaves (os bits reais usados para operações criptográficas) pode mudar com o tempo à medida que você cria novas versões de chaves. É possível atribuir políticas de permissão do IAM no nível da chave na hierarquia de recursos.

  A finalidade da chave e outros atributos da chave são conectados e gerenciados com a chave. Assim, a chave é o objeto mais importante para se entender o uso do KMS.

  O Cloud KMS é compatível com chaves assimétricas e simétricas. Uma chave simétrica é usada para criar ou validar assinaturas MAC ou para criptografia simétrica a fim de proteger algum corpus de dados. Por exemplo, é possível usar o AES-256 no modo GCM para criptografar um bloco de texto simples. Uma chave assimétrica pode ser usada para criptografia assimétrica ou assinatura assimétrica. Para mais informações, consulte Algoritmos e finalidades compatíveis.

• Keyring: um agrupamento de chaves para fins organizacionais. Um keyring pertence a um projeto Google Cloud e reside em um local específico. As chaves herdam as políticas de permissão do keyring. Agrupar chaves com permissões relacionadas em um keyring permite conceder, revogar ou modificar permissões no nível do keyring sem a necessidade de agir individualmente. Os keyrings oferecem conveniência e categorização, mas se o agrupamento de keyrings não for útil para você, gerencie as permissões diretamente nas chaves. As tags permitem permitir ou negar políticas condicionalmente, dependendo se o recurso tem ou não uma tag específica. É possível aplicar tags no nível do keyring na hierarquia de recursos.

  Para evitar colisões de nomes de recursos, não é possível excluir um keyring ou uma chave. Os keyrings e as chaves não têm custos faturáveis ou limitações de cotas. Portanto, a existência contínua deles não afeta os custos nem os limites de produção.

• Metadados de chave: nomes de recursos, propriedades de recursos do KMS, como políticas de permissão, tipo de chave, tamanho da chave, estado da chave e todos os dados derivados de chaves e keyrings.

• Versão da chave: o material associado a uma chave em um dado momento. A versão de chave é o recurso que contém o material real da chave. As versões são numeradas sequencialmente, começando pela versão 1. Quando uma chave é rotacionada, uma nova versão de chave é criada com um novo material de chave. A mesma chave lógica pode ter várias versões ao longo do tempo, o que significa que os dados são criptografados usando diferentes versões de chave. As chaves simétricas têm uma versão principal. Por padrão, a versão principal é usada para criptografia. Quando o Cloud KMS realiza a descriptografia usando chaves simétricas, ele identifica automaticamente qual versão de chave é necessária para executar a descriptografia.

Hierarquia de chaves

O diagrama a seguir ilustra a hierarquia de chaves e a criptografia de envelope do Cloud KMS e do keystore interno do Google. A criptografia de envelope é o processo de criptografar uma chave usando outra para armazená-la com segurança ou transmiti-la por um canal não confiável. Todas as chaves neste diagrama são simétricas.

Na hierarquia de chaves, uma chave de criptografia de dados (DEK) criptografa os blocos de dados. Uma chave de criptografia de chaves (KEK, na sigla em inglês) é usada para criptografar ou encapsular a DEK. Todas as opções de plataforma do Cloud KMS (software, hardware e back-ends externos) permitem controlar a KEK. As KEKs são armazenadas no Cloud KMS. O material da chave nunca sai do limite do sistema do Cloud KMS.

Para chaves protegidas por software, uma chave mestra do KMS específica do local criptografa a KEK. A chave mestra do KMS é armazenada no Keystore. Há uma chave mestra do KMS separada no Keystore para cada local do Cloud KMS. Cada servidor do Cloud KMS busca uma cópia da chave-mestra do KMS durante a inicialização como uma dependência forte, e uma nova cópia da chave-mestra do KMS é recuperada todos os dias. A chave mestra do KMS é criptografada novamente periodicamente usando a chave mestra do armazenamento de chaves. A chave mestra do Keystore é protegida pela chave mestra do Keystore raiz.

Para chaves protegidas por hardware, uma chave de encapsulamento de HSM específica do local criptografa a KEK, e a chave de encapsulamento de HSM é criptografada com a chave mestra do KMS. Para mais informações, consulte Como criar chaves. Para chaves externas, uma chave de encapsulamento do EKM criptografa a DEK encapsulada, e a chave de encapsulamento do EKM é criptografada com a chave mestra do KMS.

O Cloud KMS usa o Keystore, que é o serviço interno de gerenciamento de chaves do Google, para encapsular chaves criptografadas do Cloud KMS. O Cloud KMS usa a mesma raiz de confiança que o Keystore. Para mais informações sobre o Keystore, consulte Gerenciamento de chaves no artigo "Criptografia em repouso".

Restrições operacionais

O Cloud KMS opera dentro das seguintes restrições:

• Projeto:os recursos do Cloud KMS pertencem a um projeto do Google Cloud, assim como todos os outros recursos do Google Cloud. As chaves do Cloud KMS podem estar em um projeto diferente dos dados que elas protegem. Se você mantiver as chaves no mesmo projeto que os dados protegidos pelos recursos, remova a função de proprietário do projeto para seguir a prática recomendada de separação de tarefas entre os administradores de chaves e de dados.
• Locais: em um projeto, os recursos do Cloud KMS são criados em um local. Para mais informações sobre locais, consulte Geografia e regiões.
• Consistência: o Cloud KMS propaga operações em chaves, keyrings e versões de chaves usando consistência forte ou consistência eventual. Para saber mais, consulte Consistência de recursos do Cloud KMS.

Chaves de criptografia gerenciadas pelo cliente

Por padrão,o Google Cloud criptografa todos os dados do cliente armazenados em repouso, com o Google gerenciando as chaves usadas para criptografia. Para produtos Google Cloud compatíveis que armazenam seu conteúdo de cliente de forma permanente (por exemplo, o Cloud Storage), use o Cloud KMS para gerenciar chaves de criptografia gerenciadas pelo cliente (CMEKs). As CMEKs são chaves de criptografia de sua propriedade e podem ser usadas com chaves externas, protegidas por software e protegidas por hardware.

Com as CMEKs, você tem mais controle sobre as chaves usadas para criptografar dados em repouso nos serviços compatíveis do Google Cloud , além de fornecer um limite criptográfico para seus dados. É possível gerenciar CMEKs diretamente no Cloud KMS ou automatizar o provisionamento e a atribuição usando o Autokey. Quando um serviço usa a CMEK, suas cargas de trabalho podem acessar recursos da mesma forma que quando você usa apenas a criptografia padrão.

O Cloud KMS permite que você controle muitos aspectos das chaves (como criação, ativação/desativação, rotação e destruição das chaves) e gerencie as permissões apropriadas do IAM. Para impor uma separação recomendada de tarefas, o Cloud KMS inclui vários papéis predefinidos do IAM com privilégios e limitações específicos e que podem ser concedidos a usuários e contas de serviço específicos.

Como o Cloud KMS usa a criptografia de envelope, uma CMEK é uma KEK que criptografa as DEKs. Para mais informações, consulte Hierarquia de chaves.

A rotação da CMEK funciona de maneira diferente dependendo do tipo de recurso que a chave protege. Veja estes exemplos:

• No Spanner, uma nova versão da chave criptografa novamente a DEK.
• Para outros tipos de recursos, como buckets do Cloud Storage, apenas os recursos recém-criados são criptografados usando a nova versão da chave, o que significa que versões diferentes de uma chave protegem diferentes subconjuntos de dados.
• Em alguns cenários, o recurso da nuvem precisa ser recriado com a nova versão da chave. Por exemplo, por padrão, o BigQuery não alterna automaticamente uma chave de criptografia de tabela quando a chave do Cloud KMS associada à tabela é alternada. As tabelas atuais do BigQuery continuam usando a versão da chave com que foram criadas.

Para mais informações sobre a rotação de chaves, consulte a documentação de cada produto.

As políticas da organização de CMEK fornecem maior controle sobre como a CMEK é usada nos seus projetos. Essas políticas permitem controlar os serviços e projetos que contêm chaves permitidas para CMEK, além do nível de proteção das chaves.

Google Cloud é compatível com CMEK para vários serviços, incluindo Cloud Storage, BigQuery e Compute Engine. Consulte Integrações de CMEK para ver a lista completa de integrações de CMEK e serviços compatíveis com CMEK. O Google continua investindo na integração do CMEK com outros produtos Google Cloud .

Cloud KMS Autokey

Com a Autokey, você simplifica o processo de provisionamento de CMEK. Durante um processo manual de provisionamento de CMEK, um administrador do Cloud KMS precisa planejar os tipos de keyrings, chaves e contas de serviço antes que sejam necessários e coordenar com os desenvolvedores para provisionar as chaves. Com o Autokey, o administrador do Cloud KMS delega a autoridade ao agente de serviço do Cloud KMS no projeto. Quando você ativa o Autokey, um desenvolvedor pode solicitar uma chave do Cloud KMS, e o agente de serviço provisiona a chave certa para a intenção do desenvolvedor. Com o Autokey, as chaves estão disponíveis sob demanda, são consistentes e seguem as práticas padrão do setor.

O Autokey provisiona e atribui keyrings, chaves e contas de serviço sob demanda à medida que os desenvolvedores criam recursos de nuvem, respeitando a separação de responsabilidades. O provisionamento e a atribuição de chaves seguem práticas e recomendações padrão do setor para segurança de dados, incluindo o seguinte:

• Nível de proteção do HSM:as chaves criadas com a autokey são sempre chaves de HSM e, portanto, são armazenadas no back-end do Cloud HSM. Elas são chaves de criptografia AES-256 GCM.
• Separação de funções:para manter a separação de funções, as identidades que podem usar a chave para criptografar e descriptografar são diferentes das identidades que gerenciam a chave (incluindo rotação, destruição ou mudança de estado).
• Rotação de chaves:as chaves são alternadas anualmente.
• Colocação da chave no mesmo local que os recursos:a chave fica no mesmo local que o recurso que ela protege.
• Especificidade da chave:a especificidade da chave é adequada para o tipo de recurso que ela protege, por tipo de recurso. A especificidade significa que você não precisa analisar manualmente os tipos de recursos de cada serviço e decidir quantos de cada tipo uma única chave deve proteger.

As chaves solicitadas usando o Autokey funcionam da mesma forma que outras chaves do Cloud HSM com as mesmas configurações. O Autokey simplifica o uso do Terraform porque elimina a necessidade de executar a infraestrutura como código com privilégios elevados de criação de chaves. O Autokey está disponível em todos os locaisGoogle Cloud onde o Cloud HSM está disponível.

O Autokey está disponível apenas para recursos Google Cloud específicos. Para mais informações, consulte Visão geral das chaves automáticas.

Arquitetura e componentes da plataforma Cloud KMS

A plataforma Cloud KMS aceita vários algoritmos criptográficos e fornece métodos para criptografar e assinar digitalmente usando chaves externas, protegidas por hardware e protegidas por software. A plataforma do Cloud KMS é integrada ao gerenciamento de identidade e acesso (IAM) e aos registros de auditoria do Cloud para que você gerencie as permissões em chaves individuais e audite como elas são usadas.

O diagrama anterior mostra os principais componentes da plataforma Cloud KMS.

• Os administradores acessam os serviços de gerenciamento de chaves usando o Console do Cloud ou a Google Cloud CLI.

• Os aplicativos acessam serviços de gerenciamento de chaves implementando a API REST, o gRPC ou as bibliotecas de cliente. Os aplicativos podem usar os serviços do Google que estão ativados para usar as CMEK. O CMEK, por sua vez, usa a API Cloud Key Management Service. Se o aplicativo usa PKCS #11, é possível integrá-lo ao Cloud KMS usando a biblioteca do PKCS #11.

• A API Cloud KMS permite usar software, hardware ou chaves externas. É possível gerar e gerenciar chaves protegidas por software e hardware usando o endpoint de serviço do Cloud KMS. As chaves protegidas por software e hardware usam proteções de backup redundantes do Google.

• Se você usar chaves protegidas por hardware, os HSMs com certificação FIPS 140-2 nível 3 no Google Cloud armazenarão as chaves. Para mais informações sobre nossa certificação, consulte o certificado 4399.

• O Cloud KMS usa o armazenamento de dados interno do Google para armazenar o material criptografado da chave do cliente. Esse armazenamento de dados é altamente disponível e oferece suporte a muitos sistemas essenciais do Google. Consulte Proteção do Datastore.

• Em intervalos regulares, o sistema de backup independente faz backup de todo o armazenamento de dados para o armazenamento on-line e de arquivamento. Esse backup permite que o Cloud KMS atinja as metas de durabilidade. Consulte Proteção do Datastore.

Validação FIPS 140-2

As operações criptográficas do Cloud KMS são realizadas por módulos validados pelo FIPS 140-2. As chaves com nível de proteção SOFTWARE e as operações criptográficas executadas com elas estão em conformidade com o Nível 1 do FIPS 140-2. Essas operações usam BoringCrypto, uma biblioteca de código aberto mantida pelo Google. As chaves com nível de proteção HSM e as operações criptográficas executadas com elas estão em conformidade com o Nível 3 do FIPS 140-2.

Segurança dos materiais das chaves

No Cloud KMS, o material da chave é sempre criptografado em repouso e em trânsito. O material da chave é descriptografado apenas nos seguintes casos:

• Quando o cliente estiver usando esse recurso.
• Quando a chave interna do Google usada para proteger o material da chave do cliente é rotacionada ou verificada quanto à integridade.

As solicitações do cliente para o Cloud KMS são criptografadas em trânsito usando o TLS entre o cliente e o Google Front End (GFE).

A autenticação ocorre entre todos os jobs do Cloud KMS nos data centers do Google.

A política do Google é garantir que os jobs usem apenas códigos-fonte criados, testados e revisados de maneira verificável. A autorização binária para o Borg (BAB, na sigla em inglês) aplica essa política no nível operacional.

Os jobs da API Cloud KMS podem acessar metadados de chave, como a política de permissão ou o período de rotação. Um funcionário do Google com uma justificativa comercial válida e documentada (como um bug ou um problema do cliente) também pode acessar os principais metadados. Esses eventos de acesso são registrados internamente, e os registros pertencentes aos dados cobertos pela Transparência no acesso também estão disponíveis para clientes qualificados.

O material da chave descriptografada não pode ser exportado ou visualizado pela interface da API ou por outra interface do usuário. Nenhum funcionário do Google tem acesso aos materiais não criptografados da chave do cliente. Além disso, o material da chave também é criptografado com uma chave-mestra no keystore, que não pode ser acessada diretamente por qualquer pessoa. Em um HSM, o material de chave nunca é acessado em um estado descriptografado por jobs da API Cloud KMS.

Proteção do armazenamento de dados

O armazenamento de dados do Cloud KMS é altamente disponível, durável e protegido.

Disponibilidade. O Cloud KMS usa o armazenamento de dados interno do Google, que está altamente disponível e é compatível com vários sistemas essenciais do Google.

Durabilidade. O Cloud KMS usa criptografia autenticada para armazenar o material da chave do cliente no armazenamento de dados. Além disso, todos os metadados são autenticados usando um código de autenticação de mensagem baseado em hash (HMAC) para garantir que ele não seja alterado ou corrompido em repouso. A cada hora, um job em lote verifica todos os materiais e metadados da chave e verifica se os HMACs são válidos e se o material da chave pode ser descriptografado. Se algum dado estiver corrompido, os engenheiros do Cloud KMS serão alertados imediatamente para que possam tomar as medidas necessárias.

O Cloud KMS usa vários tipos de backups para o armazenamento de dados:

• Por padrão, o armazenamento de dados mantém um histórico de alterações de cada linha por quatro dias. Em uma emergência, essa vida útil pode ser ampliada para fornecer mais tempo para corrigir problemas.
• A cada hora, o armazenamento de dados registra um snapshot. O snapshot pode ser validado e usado para restauração, se necessário. Esses snapshots são mantidos por quatro dias.
• Todos os dias, um backup completo é copiado para o disco e para o armazenamento do arquivo.

A equipe do Cloud KMS documentou procedimentos para restaurar backups para reduzir a perda de dados quando ocorre uma emergência no lado do serviço.

Backups. Os backups do armazenamento de dados do Cloud KMS estão na região Google Cloud associada. Todos esses backups são criptografados em repouso. O acesso a dados em backups é limitado com base em justificativas de acesso (como um número de tíquete que você registrou com o suporte do Google), e o acesso humano é gravado nos registros de transparência no acesso.

Proteção. Na camada de aplicativo do Cloud KMS, o material da sua chave é criptografado antes de ser armazenado. Os engenheiros com acesso ao armazenamento de dados não têm acesso ao material de chave de cliente em texto simples. Além disso, o armazenamento de dados criptografa todos os dados que gerencia antes de gravar no armazenamento permanente. Portanto, o acesso a camadas de armazenamento subjacentes, incluindo discos ou armazenamento de arquivos, não permite acesso mesmo aos dados criptografados do Cloud KMS sem acesso às chaves de criptografia do armazenamento de dados, que são armazenadas no Keystore.

Política de rotação. A rotação de chaves faz parte das práticas recomendadas geralmente aceitas para o gerenciamento dos materiais das chaves. Existe uma política de rotação das chaves usadas para proteger os armazenamentos de dados do Cloud KMS. Uma política de rotação de chaves também é aplicada às chaves mestras do Keystore que unem as chaves mestras do Cloud KMS. A chave-mestra do keystore tem um período máximo programado de 90 dias para texto criptografado e um período máximo de um dia para chaves em cache do cliente. O Cloud KMS atualiza as chaves-mestras KMS nas tarefas do KMS a cada 24 horas e criptografa de novo todas as chaves do cliente mensalmente.

Residência dos dados. Os dados subjacentes a cada armazenamento do Cloud KMS permanecem exclusivamente na região Google Cloud a que estão associados. Isso também se aplica a locais que são multirregiões, como, por exemplo, a multirregião us.

Disponibilidade das chaves após a criação

O Cloud KMS permite que uma chave seja usada imediatamente após o armazenamento de dados do Cloud KMS confirmar a transação que cria a chave e depois que a camada de armazenamento confirmar a criação.

Principais back-ends e níveis de proteção

Ao criar uma chave com o Cloud KMS, é possível escolher um nível de proteção para determinar qual back-end cria a chave e executa todas as futuras operações criptográficas nela. Os back-ends são expostos na API Cloud KMS como os seguintes níveis de proteção:

• SOFTWARE: aplica-se a chaves que podem ser desencapsuladas por um módulo de segurança de software para realizar operações criptográficas.
• HSM: aplica-se a chaves que só podem ser separadas por HSMs que executam todas as operações criptográficas com as chaves.
• EXTERNAL ou EXTERNAL-VPC: aplicar ao gerenciador de chaves externo (EKM). EXTERNAL-VPC permite conectar o EKM ao Google Cloud em uma rede VPC.

Back-end de software do Cloud KMS: nível de proteção de SOFTWARE

O nível de proteção SOFTWARE se aplica a chaves com operações criptográficas que são executadas no software. Esta seção descreve os detalhes de como esse nível é implementado.

Implementações de algoritmos

No caso das chaves de software, o Cloud KMS usa o módulo BoringCrypto na implementação BoringSSL do Google para todo o trabalho criptográfico relacionado. O módulo BoringCrypto é validado pelo FIPS 140-2. O binário do Cloud KMS é criado em relação ao FIPS 140-2 Nível 1, que são os primitivos criptográficos validados deste módulo. Os algoritmos mais atuais abordados neste módulo estão listados nos algoritmos e propostas da chave e incluem operações de criptografia, descriptografia e assinatura com AES256-GCM simétrica e RSA 2048, RSA 3072, RSA 4096, EC P256 e chaves criptográficas assimétricas do EC P384.

Geração de números aleatórios e entropias

Ao gerar chaves de criptografia, o Cloud KMS usa o BoringSSL. O FIPS 140-2 exige que seus próprios PRNGs sejam usados (também conhecidos como DRBGs). No BoringCrypto, o Cloud KMS usa exclusivamente CTR-DRBG com AES-256. Isso fornece saída para RAND_bytes, a interface principal em que o restante do sistema recebe dados aleatórios. Esse PRNG é propagado usando o RNG do kernel do Linux, que é propagado de várias fontes de entropias independentes. Essa propagação inclui eventos entrópicos do ambiente de data center, como medições refinadas de buscas de disco e horários de chegada entre pacotes, e a instrução RDRAND da Intel, quando disponível. Para mais informações sobre o comportamento do gerador de números aleatórios para o BoringSSL (modo compatível com FIPS), consulte o design do RNG.

Back-end do Cloud HSM: nível de proteção de HARDWARE

O Cloud HSM fornece chaves protegidas por hardware para o Cloud KMS. Ele permite usar chaves criptográficas protegidas por HSMs com certificação FIPS 140-2 de nível 3 totalmente gerenciados nos data centers do Google. O Cloud HSM é altamente disponível e fornece escala elástica, exatamente como o Cloud KMS. É possível acessar o back-end do Cloud HSM usando a mesma API e as mesmas bibliotecas de cliente do Cloud KMS. Para saber mais sobre o serviço Cloud HSM, consulte Arquitetura do Cloud HSM.

Cloud EKM: nível de proteção EXTERNO

O Cloud EKM permite criptografar dados usando chaves de criptografia fora da nuvem que permanecem no seu controle.

As chaves com os níveis de proteção EXTERNAL e EXTERNAL_VPC são armazenadas e gerenciadas em um sistema de gerenciamento de chaves externas. Para mais informações, consulte Arquiteturas de referência para o Cloud EKM.

Processo de criação de chaves

O diagrama a seguir ilustra o processo de criação de chaves para os diferentes back-ends e níveis de proteção.

O processo de criação de chaves inclui o seguinte:

1. Usando a API Cloud KMS, um usuário pede ao Cloud KMS para criar uma chave. Essa solicitação inclui o nível de proteção (se a chave é protegida por software, por hardware ou externa).
2. O Cloud KMS verifica a identidade do usuário e se ele tem permissão para criar a chave.
3. A chave é gerada da seguinte forma:
   • Para chaves protegidas por software, o Cloud KMS gera a chave do cliente.
   • Para chaves protegidas por hardware, o Cloud KMS envia uma solicitação ao Cloud HSM. O Cloud HSM envia a solicitação ao HSM para gerar uma nova chave. O HSM gera uma chave do cliente e a criptografa (encapsula) com a chave de encapsulamento regional do HSM. O Cloud HSM envia a chave encapsulada de volta ao Cloud KMS.
   • Para chaves externas, o Cloud KMS envia uma solicitação ao Cloud EKM. O Cloud EKM envia a solicitação ao gerenciador de chaves externas para gerar uma nova chave. O EKM gera uma nova chave e a criptografa com a chave de encapsulamento do EKM. O Cloud EKM envia a chave encapsulada de volta ao Cloud KMS.
4. O Cloud KMS criptografa a chave do cliente encapsulada com a chave mestra do KMS e a envia para o armazenamento de dados do KMS.
5. O Cloud KMS envia uma resposta de sucesso com o URI completo da versão da chave para o usuário.

Importação de chave

Convém importar suas próprias chaves criadas no local ou em um EKM para o ambiente de nuvem. Por exemplo, é possível ter um requisito regulamentar de que as chaves usadas para criptografar os dados da nuvem sejam geradas de uma forma ou ambiente específicos. A importação de chaves permite importar essas chaves e atender às suas obrigações regulatórias. Para estender os recursos de assinatura para a nuvem, também é possível importar chaves assimétricas.

Como parte da importação de chaves, o Cloud KMS gera uma chave de união pública, que é um par de chaves públicas/privadas, usando um dos métodos de importação compatíveis. A criptografia do material de chave com essa chave de união protege o material da chave em trânsito.

Use a chave de união pública para criptografar a chave a ser importada no cliente. A chave privada que corresponde à chave pública é armazenada em Google Cloud e usada para desencapsular a chave pública depois de chegar ao projetoGoogle Cloud . O método de importação escolhido determina o algoritmo usado para criar a chave de união. Depois que o material da chave é reunido, é possível importá-lo para uma nova chave ou versão de chave no Cloud KMS.

É possível usar chaves importadas com o nível de proteção HSM ou SOFTWARE. Quanto ao Cloud HSM, a parte de chave privada da chave de união fica disponível somente no Cloud HSM. Se você restringi-la ao Cloud HSM, o Google não poderá desencapsular o material de chave fora dele.

Ciclo de vida de uma solicitação do Cloud KMS

Nesta seção, descrevemos o ciclo de vida de uma solicitação do Cloud KMS, incluindo uma discussão sobre a destruição do material da chave. O diagrama a seguir mostra um cliente solicitando acesso a instâncias de serviço do Cloud KMS em us-east1 e us-west1 e como as solicitações são roteadas usando o Google Front End (GFE).

As etapas desse ciclo de vida incluem:

1. O pessoal da sua organização ou um job em execução em nome dela cria uma solicitação para o serviço do Cloud KMS, https://cloudkms.googleapis.com. O DNS resolve esse endereço para um endereço IP Anycast do GFE.
2. O GFE fornece hospedagem de IP público do nome DNS público, proteção contra negação de serviço (DoS) e encerramento de TLS. Quando você envia sua solicitação, ela geralmente é encaminhada para um GFE próximo a você, independente do local para onde a solicitação é direcionada. Os GFEs processam a negociação TLS e, usando o URL de solicitação e os parâmetros, determinam qual balanceador de carga de software global (GSLB, na sigla em inglês) encaminha a solicitação.
3. Há uma meta de GSLB separada para cada região do Cloud KMS. Se a solicitação chegar a um GFE em us-east1 e for destinada a us-west1, ela será encaminhada entre os data centers us-east1 e us-west1. Toda a comunicação entre data centers é criptografada em trânsito usando o ALTS, que autentica mutuamente os jobs do GFE e do Cloud KMS.
4. Quando a solicitação chega ao job do Cloud KMS, ela é processada primeiro por um framework que lida com grande parte do trabalho comum a todos os serviços doGoogle Cloud . Esse framework autentica a conta e realiza várias verificações para confirmar se:
   • A conta tem uma credencial válida e pode ser autenticada.
   • A API Cloud KMS está ativada no projeto e tem uma conta de faturamento válida.
   • A cota é suficiente para executar a solicitação.
   • A conta está na lista de permissões para usar a região relevante doGoogle Cloud .
   • A solicitação não é rejeitada pelo VPC Service Controls.
5. Após a aprovação dessas verificações, o framework encaminha a solicitação e a credencial para o Cloud KMS. O Cloud KMS analisa a solicitação para determinar quais recursos estão sendo acessados e, em seguida, verifica com o IAM se o autor da chamada está autorizado a fazer a solicitação. O IAM também indica se a ocorrência da solicitação precisa ser gravada nos registros de auditoria. Se as Justificativas de acesso às chaves estiverem ativadas, será enviada uma notificação de justificativa que você precisa aprovar.
6. Depois que a solicitação é autenticada e autorizada, o Cloud KMS chama os back-ends de armazenamento de dados na região para buscar o recurso solicitado. Depois que o recurso é buscado, o material da chave é descriptografado para uso.
7. Com o material da chave, o Cloud KMS executa a operação criptográfica, encaminhando a versão encapsulada da chave para o back-end do software Cloud KMS, o back-end do Cloud HSM ou o back-end do Cloud EKM, dependendo do nível de proteção da chave.
8. Depois que a operação criptográfica é concluída, a resposta é enviada de volta a você com o mesmo tipo de canal de GFE para KMS da solicitação.
9. À medida que a resposta é retornada, o Cloud KMS também aciona os seguintes eventos de maneira assíncrona:
   • Os registros de auditoria e solicitação são preenchidos e enfileirados para gravação.
   • Os relatórios são enviados para fins de faturamento e gerenciamento de cotas.
   • Se a solicitação atualizar os metadados de um recurso, a alteração será enviada ao Inventário de recursos do Cloud por meio de atualizações de jobs em lote.

Integridade de dados de ponta a ponta

O Cloud KMS permite calcular checksums para chaves e materiais de chave para ajudar a garantir que elas não sejam corrompidas. Essas checksums ajudam a proteger você contra a perda de dados que pode ser causada por corrupção de hardware ou software. As bibliotecas auxiliares permitem verificar a integridade da chave. É possível usar bibliotecas auxiliares para verificar a integridade da chave fornecendo checksums para o Cloud KMS, que são verificadas pelo servidor. Além disso, essas bibliotecas permitem que você receba checksums para verificar os dados das respostas no cliente.

A integridade de dados de ponta a ponta ajuda a proteger seu ambiente contra ameaças como as seguintes:

• Corrupção durante o transporte; como na pilha entre o envio dos dados e a proteção do TLS.
• Problemas em qualquer proxy intermediário entre o endpoint e o KMS (por exemplo, para solicitações recebidas).
• Operações de criptografia com falha, corrupção de memória da máquina ou corrupção do HSM na arquitetura do Cloud KMS.
• Corrupção durante a comunicação com um EKM externo.

Para mais informações, consulte Como verificar a integridade dos dados de ponta a ponta.

Destruição de materiais das chaves

O material da chave é considerado como dados do cliente, portanto, a abordagem descrita em Exclusão de dados no Google Cloud também se aplica ao Cloud KMS. O material da chave é destruído na solicitação, quando o período Programado para destruição é concluído e os backups expiram. O material de chave que ainda está presente nos backups (após o término do período de destruição programado) só pode ser usado para recuperação de desastres regionais, e não para restaurar chaves individuais. Esse processo não é garantido para cópias de chaves importadas que existem fora do controle do Cloud KMS.

Por padrão, as chaves no Cloud KMS passam 30 dias no estado Programado para destruição (com exclusão reversível) antes que o material da chave seja logicamente excluído do sistema. Você pode alterar essa duração. Para mais informações, consulte Duração variável do estado Programado para destruição.

Embora o material da chave seja destruído, as chaves e os keyrings não podem ser excluídos. Isso também se aplica às versões de chave, mas o material delas pode ser destruído para que os recursos não sejam mais usados. Os keyrings e as chaves não têm custos faturáveis ou limitações de cotas. Portanto, a existência contínua deles não afeta os custos nem os limites de produção.

Depois que uma versão de chave é programada para destruição, ela não fica mais disponível para operações criptográficas. Dentro do período de exclusão pendente, é possível restaurar a versão da chave para que ela não seja destruída.

Se você excluir uma chave importada por engano, será possível importá-la novamente. Para mais informações, consulte Como importar novamente uma chave destruída.

Para evitar a exclusão acidental de uma chave, considere as seguintes práticas recomendadas:

• Defina a restrição Duração mínima programada de destruição por chave para um período mais longo. Essa restrição define o período mínimo de programação para destruição de novas chaves.
• Aplique a restrição Destruição de chave restrita para chaves desativadas para que apenas chaves desativadas possam ser destruídas. Para mais informações, consulte Exigir que as chaves sejam desativadas antes da destruição.
• Crie um papel personalizado do KMS que não inclua a permissão cloudkms.cryptoKeyVersions.destroy.
• Altere o campo destroy_scheduled_duration para um período mais longo.

• Monitore e adicione alertas para os principais eventos de destruição. Por exemplo, crie o seguinte filtro do Cloud Logging:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Crie processos que desativem a chave por alguns dias antes de ela ser excluída.

Dependências da infraestrutura do Google

Os elementos da plataforma Cloud KMS são executados como jobs de produção do Borg. O Borg é o gerenciador de clusters em grande escala do Google para lidar com jobs de exibição de API e jobs em lote.

Para informações sobre a segurança da nossa infraestrutura física e de produção, consulte a visão geral do design de segurança da infraestrutura do Google.

Jobs de exibição da API Cloud KMS

Os jobs de exibição da API Cloud KMS são jobs de produção do Borg para atender às solicitações de clientes sobre gerenciamento e uso das chaves. Os jobs de disponibilização da API Cloud KMS também processam ações adiadas a partir de solicitações de clientes, como rotação de chaves na programação, criação de chaves assimétricas e importação de chaves. Esses jobs de exibição são executados em todas as Google Cloud regiões em que o Cloud KMS está disponível. Cada job é associado a uma única região e é configurado para acessar apenas dados de sistemas localizados geograficamente na região associada do Google Cloud .

Jobs em lote do Cloud KMS

A plataforma Cloud KMS também mantém vários jobs em lote executados como jobs de produção do Borg em várias programações. Os jobs em lote são específicos à região. Eles apenas agregam dados (e são executados) na região associada Google Cloud. Veja abaixo algumas das tarefas que esses jobs realizam:

• Contar chaves ativas para o faturamento do cliente.
• Agregue recursos da API pública de buffer de protocolo do Cloud KMS e encaminhe os metadados para o Inventário de recursos do Cloud. Recursos, neste contexto, são quaisquer recursos gerenciados pelo Cloud KMS, por exemplo, chaves e keyrings.
• Agregue todos os recursos e geração de informações para análises de negócios.
• Dados de snapshots para alta disponibilidade.
• Valide todos os dados mantidos no armazenamento de dados subjacente para confirmar que não estão corrompidos.
• Nova realização da criptografia do material da chave do cliente quando a chave-mestra do KMS for rotacionada.

Capturador de snapshots de chaves do Cloud KMS

Para manter a alta disponibilidade, a plataforma Cloud KMS mantém um armazenamento de dados redundante em cada instância do serviço compartilhado que hospeda as tarefas do servidor da API Cloud KMS. Cada serviço compartilhado implanta a própria instância do serviço do capturador de snapshot. Essa redundância torna os serviços altamente independentes para que uma falha em uma zona tenha um efeito limitado em outras zonas. Quando o job da API Cloud KMS precisa executar uma operação criptográfica, ele consulta o armazenamento de dados primário e os jobs locais do capturador de snapshot paralelamente. Se o armazenamento de dados primário estiver lento ou indisponível, a resposta poderá ser exibida por um snapshot, se ele não tiver mais de duas horas. Os snapshots são criados como a saída de um job em lote que é executado continuamente para cada região. Os snapshots são mantidos na região da nuvem associada ao material da chave.

Comunicações entre servidores e clientes

O Google usa o Application Layer Transport Security (ALTS) para fornecer segurança às comunicações entre servidores e clientes que usam o mecanismo de chamada de procedimento remoto (RPC, na sigla em inglês) do Google.

Para mais informações, consulte Autenticação, integridade e criptografia de serviço a serviço.

Ambiente operacional da plataforma Cloud KMS

O ambiente operacional da plataforma Cloud KMS inclui políticas de armazenamento e segurança de dados, restrições de acesso e estratégias de redução de riscos projetadas para otimizar a confiabilidade, a durabilidade e a disponibilidade, protegendo o material das chaves. Esta seção discute a estrutura operacional do serviço, as responsabilidades dos membros da equipe de operações, os mecanismos de autenticação e os protocolos de auditoria e registro. Esta seção se aplica aos recursos de chave protegidos por software e hardware.

Engenheiros de software, engenheiros de confiabilidade do site e operadores do sistema

Os engenheiros de software são responsáveis por contribuir com outras partes interessadas, como gerentes de produto e engenheiros de confiabilidade do site (SREs), para projetar o sistema e escrever grande parte do código e dos testes do serviço Cloud KMS. O código inclui o job principal que atende às solicitações do cliente, bem como jobs secundários para algumas atividades, como replicação de dados e faturamento. Os SREs também podem escrever código. No entanto, os engenheiros de software e as tarefas de SRE são separados. Os SREs são responsáveis principalmente por manter o ambiente de produção dos jobs do Cloud KMS. Os SREs medem e alcançam a confiabilidade com o trabalho de engenharia e de operações.

Os operadores do sistema são responsáveis pelo processo de criação e lançamento, monitoramento, geração de alertas e planejamento de capacidade para o Cloud KMS. Eles são os primeiros a responder a problemas de clientes e falhas no Cloud KMS. Como exemplo, os operadores do sistema aproveitam as ferramentas e a automação para minimizar o trabalho dos sistemas manuais para que eles possam se concentrar nos esforços que agregam valor a longo prazo.

Os deveres dos operadores do sistema são definidos nos procedimentos operacionais padrão. Os operadores do sistema não acessam o material de chave do cliente ao realizar as tarefas deles.

Regionalidade dos recursos do Cloud KMS

Para atender a qualquer requisito importante de residência, crie recursos do Cloud KMS em um dos quatro tipos de locais doGoogle Cloud :

• Um local de região consiste em zonas em uma localização geográfica específica, como Iowa.
• Um local birregional consiste em zonas em dois locais geográficos específicos, como Iowa e Carolina do Sul.
• Um local multirregional consiste em zonas espalhadas por uma área geográfica geral, como os Estados Unidos.
• O local global consiste em zonas espalhadas por todo o mundo. Quando você cria seus recursos do Cloud KMS no local global, eles ficam disponíveis em zonas do mundo todo.

Os locais representam as regiões geográficas em que são processadas as solicitações para o Cloud KMS relativas a um determinado recurso e em que as chaves criptográficas correspondentes são armazenadas.

Para mais informações sobre os locais disponíveis do Cloud KMS, consulte Locais do Cloud KMS.

Regiões e data centers do Cloud

Uma região do Google Cloud contém um data center específico ou um conjunto especificado de data centers, determinados pela designação como local único, birregional, multirregional ou global. Para mais informações sobre Google Cloud regiões, consulte locais doGoogle Cloud .

Cada data center contém racks de máquinas para computação, rede ou armazenamento de dados. Elas executam a infraestrutura do Borg do Google.

Os data centers do Google têm requisitos de segurança física rigorosos. Qualquer espaço físico que possa conter dados do usuário requer entradas com leitores de crachás e verificadores de íris usados para autenticar participantes. As portas não estão abertas para várias pessoas, cada uma precisa se autenticar individualmente. As malas não podem ser levadas para dentro ou para fora dessas áreas, a menos que sejam malas permitidas e explicitamente autorizadas após a inspeção da equipe de segurança. É necessário ter permissão especial para levar ou remover qualquer dispositivo eletrônico que possa transmitir ou gravar dados.

Residência de chave

Alguns setores exigem que as chaves criptográficas residam em um local específico. O Cloud KMS tem termos de localização de dados com garantias de residência de dados. Conforme mencionado em Regionalidade dos recursos do Cloud KMS, o Cloud KMS oferece quatro tipos de locais regionais para atender a esses requisitos.

Para locais simples, duplos ou multirregionais, o Cloud KMS cria, armazena e processa as chaves protegidas por software e hardware e o material da chave somente nesse local. Os sistemas de processamento de dados e armazenamento que o Cloud KMS usa são configurados para usar apenas recursos na regiãoGoogle Cloud associada ao material da chave. O material de chave criado em locais birregionais ou multirregionais não sai dos limites dos locais selecionados.

Para a região global, não há garantias de regionalidade especificadas.

O Cloud KMS não garante a residência para metadados de chave, registros de uso ou para material de chave em trânsito. Os metadados da chave incluem nomes de recursos, propriedades dos recursos do Cloud KMS, como tipo de chave, tamanho e estado da chave, políticas do IAM e quaisquer dados derivados de metadados.

Ao usar a CMEK, as seguintes restrições geográficas do Cloud KMS se aplicam às suas chaves, independentemente dos locais personalizados, birregionais ou multirregionais que você escolher em outros produtos do Google Cloud que oferecem suporte à CMEK:

• Para uma região específica:como a região de uma chave KMS gerenciada pelo cliente precisa sempre estar correlacionada à região do recurso que ela protege em determinado Google Cloud serviço, as restrições de residência para chaves e recursos de uma única região têm compatibilidade e aplicabilidade garantidas.
• Para locais birregionais ou multirregionais:os usuários podem selecionar multirregiões definidas pelo Google como chaves e recursos do Google Cloud para garantir conformidade com residências. Para garantir essa residência geográfica, verifique se suas regiões em outros produtos estão alinhadas com o local regional do Cloud KMS escolhido.

A tabela a seguir resume a residência do material das chaves do Cloud KMS.

Tipo de região	Em repouso, em uso
Região única	Residente
Birregional ou multirregional	Residente nas regiões que formam a birregião ou multirregião.

Monitoramento de regionalidade

Os serviços de monitoramento de dados internos do Google monitoram ativamente a residência da chave. O Cloud KMS envia alertas aos membros da equipe de SRE se detectar configurações incorretas ou se o material da chave deixar os limites da região configurada, se estiver armazenado na região errada ou se for acessado da região errada.

Alta disponibilidade

O Cloud KMS pode ajudar a simplificar os requisitos de disponibilidade com base nas regiões selecionadas. Quanto mais granular for o local, mais redundância você precisará criar. Para aplicativos com níveis mais altos de disponibilidade, use locais multirregionais, em vez de tentar criar seu próprio sistema de replicação de chaves. Você precisa equilibrar os recursos de redundância integrados com suas necessidades de regionalização de dados.

Autenticação e autorização

O Cloud KMS aceita vários mecanismos de autenticação, como OAuth2, JWT e ALTS. Seja qual for o mecanismo, o Cloud KMS resolve a credencial fornecida para identificar a principal (a entidade autenticada que autoriza a solicitação) e chama o IAM para confirmar se ela está autorizada a fazer a solicitação e se um registro de auditoria foi gravado.

O Cloud KMS usa uma versão interna da API Service Control pública para muitos aspectos do gerenciamento de serviços. Antes de um job do Cloud KMS processar uma solicitação, primeiro ele envia uma solicitação de verificação para a API Service Control, que impõe muitos controles comuns a todos os serviços do Google Cloud , como os seguintes:

• Verificar se você ativou a API Cloud KMS e tem uma conta de faturamento ativa.
• Verificar se você não excedeu sua cota e relatar o uso da cota.
• Aplicar o VPC Service Controls.
• Verificar se você está na lista de permissões para regiões de nuvem privada aplicáveis.

Gerenciamento de cotas

O Cloud KMS tem limites de uso, chamados de cotas, em solicitações feitas ao serviço. O Cloud KMS contém as seguintes cotas:

• Solicitações criptográficas de cotas para operações como criptografia, descriptografia ou assinatura.
• solicitações de leitura para operações como receber metadados de chaves ou receber uma política do IAM.
• Cotas de solicitações de gravação para operações como a criação de uma chave ou a configuração de uma política do IAM.

Essas cotas são cobradas do projeto associado ao autor da chamada. Essas cotas também são globais, o que significa que elas são aplicadas para o uso do KMS do autor da chamada em todas as regiões e multirregiões. Essas cotas são avaliadas para todos os níveis de proteção.

O Cloud HSM e o Cloud EKM têm cotas adicionais para operações criptográficas. Essas cotas precisam ser atendidas além da cota de solicitações criptográficas. As cotas do Cloud HSM e do Cloud EKM são cobradas no projeto em que a chave reside e são aplicadas a cada local.

Veja estes exemplos:

• Chamar a descriptografia com uma chave de software em asia-northeast1 requer uma unidade de cota de solicitações criptográficas (global).
• A criação de uma chave HSM em us-central1 requer uma unidade de cota de solicitações de gravação e nenhuma cota de HSM.
• Chamar a criptografia com uma chave EKM em europe exige uma unidade de cota de solicitações criptográficas (global) e uma unidade de cota de solicitações externas do KMS em europe.

Para mais informações sobre o tipo de cotas disponíveis, consulte Cotas sobre o uso de recursos do Cloud KMS. É possível ver o limite da cota no Console do Cloud. Os limites de cotas iniciais são flexíveis que podem ser ajustados com base nas necessidades da carga de trabalho.

Geração de registros

Três tipos de registros estão associados ao Cloud KMS: registros de auditoria do Cloud, registros de transparência no acesso e registros de solicitação internos.

Registros de auditoria do Cloud

O Cloud KMS registra sua atividade nos registros de auditoria do Cloud. Você pode ver esses registros no Console do Cloud. Todas as atividades do administrador, como criar ou destruir uma chave, são gravadas nesses registros. Você também pode ativar a geração de registros para todas as outras ações que usam uma chave, por exemplo, que serviria para criptografar ou descriptografar dados. Você controla por quanto tempo quer manter os registros e quem pode visualizá-los.

Registros de transparência no acesso

Os clientes qualificados podem ativar os registros de Transparência no acesso para saber as ações que os funcionários do Google realizam na sua organização doGoogle Cloud . Os registros de transparência no acesso junto com os registros de auditoria do Cloud podem ajudar você a responder a perguntas sobre quem fez o quê, onde e quando.

É possível integrar os registros da transparência no acesso às suas ferramentas de gerenciamento de eventos (SIEM, na sigla em inglês) e informações de segurança atuais para automatizar as auditorias dessas ações. Esses registros estão disponíveis no Console do Cloud junto com os registros de auditoria do Cloud.

As entradas de registro da transparência no acesso incluem os seguintes tipos de detalhes:

• o recurso e a ação afetados;
• a hora da ação;
• Os motivos da ação. Como exemplo de motivos podemos citar o suporte iniciado pelo cliente (com um número de caso), o suporte iniciado pelo Google, solicitações de dados de terceiros e solicitações de revisão iniciadas pelo Google.
• Dados sobre quem está atuando nos dados (exemplo: a localização do funcionário da equipe do Google)

Registros de solicitações internas

Os registros de solicitação armazenam um registro para cada solicitação enviada à plataforma Cloud KMS. Esse registro contém detalhes sobre o tipo de solicitação (como método ou protocolo de API) e o recurso que está sendo acessado (como nome do recurso, algoritmo de chave ou nível de proteção de chave). Esses registros não armazenam texto simples e texto criptografado do cliente ou material da chave. Antes que novos tipos de dados sejam adicionados a esses registros, uma equipe especializada em revisões de privacidade precisa aprovar alterações nos dados registrados.

As entradas de registro serão excluídas permanentemente quando o time to live (TTL) configurado expirar.

Os SREs e os engenheiros do Cloud KMS na rotação de chamada podem acessar os registros de solicitação. O acesso humano a registros e qualquer acesso que retorne dados de clientes exigem uma justificativa de negócios válida e documentada. Contando com algumas exceções específicas, o acesso humano é registrado e fica acessível a clientes qualificados nos registros de transparência no acesso.

Monitoramento

O Cloud KMS se integra ao Cloud Monitoring Essa integração permite monitorar, criar painéis e criar alertas em muitas operações do Cloud KMS. Por exemplo, é possível monitorar quando as chaves estão programadas para destruição ou monitorar e ajustar as cotas do Cloud KMS quando as operações criptográficas ultrapassam um limite definido por você. Para mais informações sobre as métricas disponíveis do Cloud KMS, consulte Como usar o Cloud Monitoring com o Cloud KMS.

Além disso, o Security Command Center tem detectores de vulnerabilidade KMS integrados. Esses detectores ajudam a garantir que os projetos que incluem chaves sigam nossas práticas recomendadas. Para mais informações sobre o detector de vulnerabilidades do KMS, consulte Descobertas de vulnerabilidades do Cloud KMS.

A seguir

• Para saber mais sobre o Cloud KMS, veja os recursos a seguir:
  • Documentação do Cloud KMS
  • Documentação do Cloud HSM
• Para informações sobre o uso das suas próprias chaves de criptografia noGoogle Cloud, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK).
• Para saber mais sobre a segurança da infraestrutura do Google, consulte Visão geral do design de segurança da infraestrutura do Google.