Encriptação do Cloud Key Management Service

Este conteúdo foi atualizado pela última vez em janeiro de 2025 e representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança da Google podem mudar no futuro, à medida que melhoramos continuamente a proteção dos nossos clientes.

Este documento descreve como o Cloud Key Management Service (Cloud KMS) fornece serviços de gestão de chaves para a encriptação de dados em repouso. O Cloud KMS baseia-se no princípio fundamental de que os clientes são proprietários dos respetivos dados e devem controlar a forma como são utilizados. Google Cloud Google Cloud Google Cloud

Quando armazena dados com o Google Cloud, os seus dados são encriptados em repouso por predefinição. Quando usa a plataforma Cloud KMS, pode ter maior controlo sobre a forma como os seus dados são encriptados em repouso e como as suas chaves de encriptação são geridas.

Este documento foca-se no funcionamento interno da plataforma Cloud KMS. Estas opções ajudam a proteger as chaves e outros dados confidenciais que armazena no Google Cloud. Este documento destina-se a decisores técnicos que precisam de detalhes sobre a arquitetura, a infraestrutura e as funcionalidades do Cloud KMS. Este documento pressupõe que tem uma compreensão básica dos conceitos de encriptação e das arquiteturas de nuvem.

Chaves em Google Cloud

A tabela seguinte descreve os diferentes tipos de chaves no Google Cloud.

Tipo de chave	Chave automática do Cloud KMS	Gerido pelo cliente do Cloud KMS (manual)	Google-owned and Google-managed encryption key (Encriptação predefinida da Google)
Pode ver os principais metadados	Sim	Sim	Não
Propriedade das chaves^1	Cliente	Cliente	Google
Pode gerir^2 e controlar^3 chaves	A criação e a atribuição de chaves são automáticas. O controlo manual do cliente é totalmente compatível.	Cliente, apenas controlo manual	Google
Compatível com os requisitos regulamentares para chaves geridas pelo cliente	Sim	Sim	Não
Partilha de chaves	Único para um cliente	Único para um cliente	Normalmente, os dados de vários clientes são protegidos por chaves de encriptação de chaves (KEKs) de encriptação de chaves partilhadas.
Controlo da rotação de chaves	Sim	Sim	Não
Políticas de organização CMEK	Sim	Sim	Não
Registe o acesso administrativo e aos dados às chaves de encriptação	Sim	Sim	Não
Separação lógica de dados através da encriptação	Sim	Sim	Não
Preços	Varia	Varia	Grátis

¹ O proprietário da chave indica quem detém os direitos da chave. As chaves que detém têm acesso rigorosamente restrito ou nenhum acesso por parte da Google.

² A gestão de chaves inclui as seguintes tarefas:

• Crie chaves.
• Escolha o nível de proteção das chaves.
• Atribuir autoridade para a gestão das chaves.
• Controle o acesso às chaves.
• Controlar a utilização de chaves.
• Defina e modifique o período de rotação das chaves ou acione uma rotação das chaves.
• Altere o estado da chave.
• Destrua versões de chaves.

³ O controlo das teclas significa definir controlos sobre o tipo de teclas e como são usadas, detetar variações e planear ações corretivas, se necessário. Pode controlar as suas chaves, mas delegar a gestão das chaves a terceiros.

Princípios do Cloud KMS

Com o Cloud KMS, o foco da Google é oferecer uma solução escalável, fiável e de alto desempenho, com o mais amplo espetro de opções que pode controlar. O Cloud KMS é suportado pelos seguintes princípios:

• Controlo do cliente: o Cloud KMS permite-lhe controlar as suas próprias chaves de software e hardware para encriptação e assinatura. Este pilar inclui suporte para trazer as suas próprias chaves (BYOK) e manter as suas próprias chaves (HYOK).
• Controlo de acesso e monitorização: com o Cloud KMS, pode gerir as autorizações em chaves individuais e monitorizar a forma como as chaves são usadas.
• Regionalização: o Cloud KMS oferece regionalização imediata. O serviço está configurado para criar, armazenar e processar chaves apenas na localização que selecionar. Google Cloud
• Cópias de segurança: para ajudar a proteger contra a danificação de dados e verificar se os dados podem ser desencriptados com êxito, o Cloud KMS analisa e faz cópias de segurança periodicamente de todos os materiais e metadados das chaves.
• Segurança: o Cloud KMS oferece uma forte proteção contra o acesso não autorizado a chaves e está totalmente integrado com os controlos de gestão de identidade e de acesso (IAM) e Cloud Audit Logs.
• Separação lógica de dados: a encriptação do Cloud KMS oferece separação lógica de dados através da encriptação. A separação lógica de dados significa que os proprietários de dados não partilham chaves de encriptação (KEKs e DEKs).

Origens e opções de gestão para chaves criptográficas

A plataforma Cloud KMS permite-lhe gerir chaves criptográficas num serviço na nuvem central para utilização direta ou para utilização por outros recursos e aplicações na nuvem.

O Google Cloud portefólio de chaves inclui o seguinte:

• Encriptação predefinida: todos os dados armazenados pela Google são encriptados na camada de armazenamento através do algoritmo Advanced Encryption Standard (AES) , AES-256. Geramos e fazemos a gestão das chaves para a encriptação predefinida, e os clientes não têm acesso às chaves nem controlo da rotação e gestão das chaves. As chaves de encriptação predefinidas podem ser partilhadas entre clientes. Para mais informações, consulte o artigo Encriptação predefinida em repouso.

• Cloud KMS com chaves protegidas por software: pode controlar as chaves geradas no Cloud KMS. O back-end de software do Cloud KMS oferece-lhe a flexibilidade de encriptar ou assinar os seus dados com uma chave simétrica ou assimétrica que controla.

• Cloud KMS com chaves protegidas por hardware (Cloud HSM): ao usar o Cloud KMS com o back-end do Cloud HSM, pode ter chaves geradas e armazenadas em módulos de segurança de hardware (HSMs) pertencentes e operados pela Google. Se precisar de uma chave protegida por hardware, pode usar o back-end do Cloud HSM para ajudar a garantir que as suas chaves só são usadas em HSMs validados de acordo com a norma FIPS 140-2 Nível 3. Pode aprovisionar chaves protegidas por hardware através de um método manual que requer um administrador do Cloud KMS ou automaticamente através do Cloud KMS Autokey. A Autokey permite-lhe automatizar os processos de aprovisionamento e atribuição de chaves para chaves de encriptação geridas pelo cliente (CMEK). As chaves de HSM convencionais requerem que um administrador do KMS crie as chaves a pedido.

• Cloud KMS com importação de chaves: para satisfazer os requisitos de BYOK, pode importar as suas próprias chaves criptográficas que gera. Pode usar e gerir estas chaves fora do Google Cloude usar o material da chave no Cloud KMS para encriptar ou assinar dados que armazena no Google Cloud.

• Cloud KMS com gestor de chaves externo (Cloud EKM): para satisfazer os requisitos de HYOK, pode criar e controlar chaves que são armazenadas num gestor de chaves externo ao Google Cloud. Em seguida, configura a plataforma Cloud KMS para usar as chaves externas para ajudar a proteger os seus dados em repouso. Pode usar estas chaves de encriptação com uma chave do EKM da Cloud. Para mais informações sobre a gestão de chaves externas e o Cloud EKM, consulte Arquiteturas de referência para o Cloud EKM.

Pode optar por usar chaves geradas pelo Cloud KMS com outros Google Cloud serviços. Estas chaves são conhecidas como CMEKs. A funcionalidade CMEK permite-lhe gerar, usar, rodar e destruir chaves de encriptação que ajudam a proteger os seus dados noutros serviços Google Cloud. Quando usa a CMEK com os Google Cloud serviços, o acesso às chaves e a monitorização são geridos por si.

Encriptação e gestão de chaves na Google

Esta secção define alguns termos para a gestão de chaves no contexto da infraestrutura de gestão de chaves de várias camadas da Google.

Porta-chaves, chaves e versões de chaves

O diagrama seguinte ilustra os agrupamentos principais e mostra os anéis de chaves e as chaves com uma única versão principal e várias versões anteriores.

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

• Chave: um objeto com nome que representa uma chave criptográfica usada para um objetivo específico. O material da chave, ou seja, os bits reais usados para operações criptográficas, pode mudar ao longo do tempo à medida que cria novas versões da chave. Pode atribuir políticas de permissão da IAM ao nível da chave na hierarquia de recursos.

  A finalidade principal e outros atributos da chave estão associados e são geridos através da chave. Assim, a chave é o objeto mais importante para compreender a utilização do KMS.

  O Cloud KMS suporta chaves assimétricas e chaves simétricas. É usada uma chave simétrica para criar ou validar assinaturas MAC ou para encriptação simétrica para proteger um conjunto de dados. Por exemplo, pode usar o AES-256 no modo GCM para encriptar um bloco de texto simples. Uma chave assimétrica pode ser usada para encriptação assimétrica ou assinatura assimétrica. Para mais informações, consulte Finalidades e algoritmos suportados.

• Conjunto de chaves: um agrupamento de chaves para fins organizacionais. Um porta-chaves pertence a um Google Cloud projeto e reside numa localização específica. As chaves herdam as políticas de permissão do respetivo porta-chaves. Agrupar chaves com autorizações relacionadas num conjunto de chaves permite-lhe conceder, revogar ou modificar autorizações para essas chaves ao nível do conjunto de chaves sem ter de agir em cada chave individualmente. Os porta-chaves oferecem conveniência e categorização, mas se o agrupamento de porta-chaves não for útil para si, pode gerir as autorizações diretamente nas chaves. As etiquetas permitem permitir ou recusar condicionalmente políticas com base no facto de um recurso ter uma etiqueta específica. Pode aplicar etiquetas ao nível do conjunto de chaves na hierarquia de recursos.

  Para evitar colisões de nomes de recursos, não pode eliminar um anel de chaves nem uma chave. Os porta-chaves e as chaves não têm custos faturáveis nem limitações de quota, pelo que a sua existência contínua não afeta os custos nem os limites de produção.

• Metadados das chaves: nomes dos recursos, propriedades dos recursos do KMS, como políticas de autorização, tipo de chave, tamanho da chave, estado da chave e quaisquer dados derivados de chaves e conjuntos de chaves.

• Versão da chave: o material da chave associado a uma chave num determinado momento. A versão da chave é o recurso que contém o material da chave real. As versões são numeradas sequencialmente, começando pela versão 1. Quando uma chave é rodada, é criada uma nova versão da chave com novo material da chave. A mesma chave lógica pode ter várias versões ao longo do tempo, o que significa que os seus dados são encriptados com diferentes versões de chaves. As chaves simétricas têm uma versão principal. Por predefinição, a versão principal é usada para encriptação. Quando o Cloud KMS realiza a desencriptação com chaves simétricas, identifica automaticamente a versão da chave necessária para realizar a desencriptação.

Hierarquia de chaves

O diagrama seguinte ilustra a hierarquia de chaves e a encriptação de envelopes para o Cloud KMS e o Keystore interno da Google. A encriptação de envelope é o processo de encriptação de uma chave com outra chave para a armazenar ou transmitir em segurança através de um canal não fidedigno. Todas as chaves neste diagrama são chaves simétricas.

Na hierarquia de chaves, uma chave de encriptação de dados (DEK) encripta as porções de dados. É usada uma chave de encriptação de chaves (KEK) para encriptar ou envolver a DEK. Todas as opções da plataforma Cloud KMS (software, hardware e back-ends externos) permitem-lhe 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 principal do KMS específica da localização encripta a KEK. A chave principal do KMS está armazenada na keystore. Existe uma chave principal do KMS separada no keystore para cada localização do Cloud KMS. Cada servidor do Cloud KMS obtém uma cópia da chave principal do KMS durante o arranque como uma dependência rígida, e é obtida uma nova cópia da chave principal do KMS todos os dias. A chave principal do KMS é encriptada novamente periodicamente através da chave principal do Keystore no Keystore. A chave principal do Keystore está protegida pela chave principal do Keystore de raiz.

Para chaves protegidas por hardware, uma chave de envolvimento do HSM específica da localização encripta a KEK, e a chave de envolvimento do HSM é, em seguida, encriptada com a chave principal do KMS. Para mais informações, consulte Criar chaves. Para chaves externas, uma chave de envolvimento do EKM encripta a DEK envolvida e, em seguida, a chave de envolvimento do EKM é encriptada com a chave principal do KMS.

O Cloud KMS usa o Keystore, que é o serviço de gestão de chaves interno da Google, para encapsular as chaves encriptadas pelo Cloud KMS. O Cloud KMS usa a mesma raiz de confiança que o Keystore. Para mais informações sobre o Keystore, consulte a secção Gestão de chaves no artigo sobre a encriptação em repouso.

Restrições operacionais

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

• Projeto: os recursos do Cloud KMS pertencem a um Google Cloudprojeto, tal como todos os outros Google Cloud>recursos. As suas chaves do Cloud KMS podem residir num projeto diferente dos dados que as chaves protegem. Se mantiver as chaves no mesmo projeto que os dados que os recursos protegem, para suportar a prática recomendada de separação de funções entre os administradores de chaves e os administradores de dados, pode remover a função de proprietário do projeto.
• Localizações: num projeto, os recursos do Cloud KMS são criados numa localização. Para mais informações sobre localizações, consulte o artigo Geografia e regiões.
• Consistência: o Cloud KMS propaga operações em chaves, conjuntos de chaves e versões de chaves através de uma consistência forte ou de uma consistência eventual. Para mais informações, consulte o artigo Consistência dos recursos do Cloud KMS.

Chaves de encriptação geridas do cliente

Por predefinição, Google Cloud encripta todos os dados de clientes armazenados em repouso, com a Google a gerir as chaves usadas para a encriptação. Para os produtos compatíveis Google Cloudque armazenam persistentemente o seu conteúdo do cliente (por exemplo, o Cloud Storage), pode usar o Cloud KMS para gerir chaves de encriptação geridas pelo cliente (CMEKs). As CMEKs são chaves de encriptação que lhe pertencem e podem ser usadas com chaves externas, chaves protegidas por software e chaves protegidas por hardware.

As CMEKs permitem-lhe ter maior controlo sobre as chaves usadas para encriptar dados em repouso nos serviços Google Cloud compatíveis e oferecem um limite criptográfico em torno dos seus dados. Pode gerir CMEKs diretamente no Cloud KMS ou automatizar o aprovisionamento e a atribuição através do Autokey. Quando um serviço usa a CMEK, as suas cargas de trabalho podem aceder aos recursos da mesma forma que quando usa apenas a encriptação predefinida.

O Cloud KMS permite-lhe controlar muitos aspetos das chaves (como a criação, a ativação, a desativação, a alternância e a destruição de chaves) e gerir as autorizações de IAM adequadas nas mesmas. Para aplicar uma separação de funções recomendada, o Cloud KMS inclui várias funções de IAM predefinidas que têm privilégios e limitações específicos e podem ser concedidas a utilizadores e contas de serviço específicos.

Uma vez que o Cloud KMS usa a encriptação em envelope, uma CMEK é uma KEK que encripta as DEKs. Para mais informações, consulte o artigo Hierarquia de chaves.

A rotação de CMEK funciona de forma diferente consoante o tipo de recurso que a chave protege. Considere os seguintes exemplos:

• No Spanner, uma nova versão da chave volta a encriptar a DEK.
• Para outros tipos de recursos, como contentores do Cloud Storage, apenas os recursos criados recentemente são encriptados com a nova versão da chave, o que significa que diferentes versões de uma chave protegem diferentes subconjuntos de dados.
• Em alguns cenários, o recurso na nuvem tem de ser recriado com a nova versão da chave. Por exemplo, por predefinição, o BigQuery não alterna automaticamente uma chave de encriptação de tabelas quando a chave do Cloud KMS associada à tabela é alternada. As tabelas do BigQuery existentes continuam a usar a versão da chave com a qual 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 CMEK oferecem um maior controlo sobre a forma como a CMEK é usada nos seus projetos. Estas políticas permitem-lhe controlar os serviços e os projetos que contêm chaves permitidas para CMEK e o nível de proteção das chaves.

Google Cloud suporta CMEK para muitos serviços, incluindo o Cloud Storage, o BigQuery e o Compute Engine. Consulte as integrações de CMEK para ver a lista completa de integrações de CMEK e serviços em conformidade com a CMEK. A Google continua a investir na integração da CMEK para outros Google Cloud produtos.

Chave automática do Cloud KMS

A funcionalidade Autokey permite-lhe simplificar o processo de aprovisionamento de CMEK. Durante um processo de aprovisionamento manual de CMEK, um administrador do Cloud KMS tem de planear os tipos de conjuntos de chaves, chaves e contas de serviço antes de serem necessários e coordenar com os programadores o aprovisionamento de chaves. Com a Autokey, o administrador do Cloud KMS delega a respetiva autoridade no agente de serviço do Cloud KMS no projeto. Quando ativa a chave automática, um programador pode pedir uma chave ao Cloud KMS, e o agente de serviço aprovisiona a chave certa para a intenção do programador. Com a Autokey, as chaves estão disponíveis a pedido, são consistentes e seguem as práticas normais da indústria.

O Autokey aprovisiona e atribui conjuntos de chaves, chaves e contas de serviço a pedido à medida que os programadores criam esses recursos da nuvem, respeitando a separação de funções. O aprovisionamento e a atribuição de chaves seguem as práticas e as recomendações padrão da indústria para a segurança de dados, incluindo o seguinte:

• Nível de proteção do HSM: as chaves criadas com o Autokey são sempre chaves de HSM e, por isso, são armazenadas no back-end do Cloud HSM. São chaves de encriptação AES-256 GCM.
• Separação de funções: para manter a separação de funções, as identidades que podem usar a chave para encriptar e desencriptar são diferentes das identidades que gerem a chave (incluindo a respetiva rotação, destruição ou alteração de estado).
• Rotação de chaves: as chaves são rodadas anualmente.
• Co-localização de chaves com recursos: a chave reside na mesma localização que o recurso que a chave protege.
• Especificidade da chave: a especificidade da chave é adequada para o tipo de recurso que a chave protege, com base no tipo de recurso. A especificidade significa que não tem de rever manualmente os tipos de recursos de cada serviço e decidir quantos de cada tipo de recurso uma única chave deve proteger.

As chaves pedidas através do Autokey funcionam de forma idêntica a outras chaves do HSM na nuvem com as mesmas definições. A chave automática simplifica a utilização do Terraform porque elimina a necessidade de executar a infraestrutura como código com privilégios de criação de chaves elevados. A funcionalidade Autokey está disponível em todas as Google Cloud localizações onde o Cloud HSM está disponível.

A chave automática está disponível apenas para recursos Google Cloud específicos. Para mais informações, consulte o artigo Vista geral do Autokey.

Arquitetura e componentes da plataforma Cloud KMS

A plataforma Cloud KMS suporta vários algoritmos criptográficos e oferece métodos para encriptar e assinar digitalmente através de chaves externas, chaves protegidas por hardware e chaves protegidas por software. A plataforma do Cloud KMS está integrada com a Identity and Access Management (IAM) e os Cloud Audit Logs para que possa gerir as autorizações de acesso a chaves individuais e auditar a forma como são usadas.

O diagrama anterior mostra os seguintes componentes principais da plataforma Cloud KMS:

• Os administradores acedem aos serviços de gestão de chaves através da Cloud Console ou da Google Cloud CLI.

• As aplicações acedem aos serviços de gestão de chaves através da implementação da API REST, gRPC, ou bibliotecas de cliente. As aplicações podem usar os serviços Google ativados para usar a CMEK. Por sua vez, a CMEK usa a API Cloud Key Management Service. Se a sua aplicação usar PKCS #11, pode integrá-la com o Cloud KMS através da biblioteca para PKCS #11.

• A API Cloud KMS permite-lhe usar software, hardware ou chaves externas. Pode gerar e gerir chaves protegidas por software e por hardware através do ponto final do serviço Cloud KMS. As chaves protegidas por software e as chaves protegidas por hardware usam as proteções de cópias de segurança redundantes da Google.

• Se usar chaves protegidas por hardware, os HSMs certificados ao nível 3 da FIPS 140-2 Google Cloud armazenam as chaves. Para mais informações acerca da nossa certificação, consulte o certificado n.º 4399.

• O Cloud KMS usa o arquivo de dados interno da Google para armazenar o material das chaves do cliente encriptado. Este repositório de dados está altamente disponível e suporta muitos dos sistemas críticos da Google. Consulte a secção Proteção do armazeno de dados.

• A intervalos regulares, o sistema de cópia de segurança independente faz uma cópia de segurança de todo o repositório de dados para o armazenamento online e de arquivo. Esta cópia de segurança permite que o Cloud KMS alcance os respetivos objetivos de durabilidade. Consulte a secção Proteção do Datastore.

Validação FIPS 140-2

As operações criptográficas do Cloud KMS são realizadas pelos nossos módulos validados pela FIPS 140-2. As chaves com o nível de proteção SOFTWARE e as operações criptográficas realizadas com as mesmas estão em conformidade com o nível 1 da FIPS 140-2. Estas operações de criptografia usam o BoringCrypto, que é uma biblioteca criptográfica de código aberto mantida pela Google. As chaves com o nível de proteção HSM e as operações criptográficas realizadas com as mesmas estão em conformidade com o FIPS 140-2 Nível 3.

Segurança dos materiais de chaves

No Cloud KMS, o material da chave está sempre encriptado em repouso e em trânsito. O material essencial só é desencriptado nos seguintes casos:

• Quando o cliente o está a usar.
• Quando a chave interna da Google usada para proteger o material das chaves do cliente está a ser rodada ou verificada quanto à integridade.

Os pedidos de clientes ao Cloud KMS são encriptados em trânsito através de TLS entre o cliente e o Google Front End (GFE).

A autenticação ocorre entre todas as tarefas do Cloud KMS, tanto dentro como entre os centros de dados da Google.

A política da Google é garantir que os trabalhos usam apenas código-fonte criado, testado e revisto de forma validável. A autorização binária para o Borg (BAB) aplica esta política ao nível operacional.

As tarefas da API Cloud KMS podem aceder aos metadados das chaves (por exemplo, a política de autorização ou o período de rotação). Um funcionário da Google com uma justificação empresarial válida e documentada (como um erro ou um problema do cliente) também pode aceder a metadados importantes. Estes eventos de acesso são registados internamente, e os registos relativos aos dados abrangidos pela Transparência de acesso também estão disponíveis para clientes qualificados.

Não é possível exportar nem ver o material de chaves descifrado através da interface da API ou de outra interface do utilizador. Nenhum funcionário da Google tem acesso ao material da chave do cliente não encriptado. Além disso, o material da chave é encriptado com uma chave principal no Keystore, ao qual nenhum indivíduo pode aceder diretamente. Num HSM, os materiais das chaves nunca são acedidos num estado desencriptado pelos trabalhos da API Cloud KMS.

Proteção do armazenamento de dados

O arquivo de dados do Cloud KMS está altamente disponível, é duradouro e está protegido.

Disponibilidade. O Cloud KMS usa o banco de dados interno da Google, que está altamente disponível e suporta vários sistemas críticos da Google.

Durabilidade. O Cloud KMS usa a encriptação autenticada para armazenar o material das chaves do cliente no arquivo de dados. Além disso, todos os metadados são autenticados através de um código de autenticação de mensagens baseado em hash (HMAC) para garantir que não foram alterados nem danificados em repouso. De hora em hora, um trabalho em lote analisa todo o material e os metadados das chaves e verifica se os HMACs são válidos e se o material das chaves pode ser desencriptado com êxito. Se algum dado estiver danificado, os engenheiros do Cloud KMS são imediatamente alertados para que possam tomar medidas.

O Cloud KMS usa vários tipos de cópias de segurança para o armazenamento de dados:

• Por predefinição, o arquivo de dados mantém um histórico de alterações de cada linha durante quatro dias. Em caso de emergência, este período pode ser prolongado para dar mais tempo para corrigir problemas.
• A cada hora, o arquivo de dados regista um instantâneo. A captura de ecrã pode ser validada e usada para restauro, se necessário. Estes instantâneos são mantidos durante quatro dias.
• Todos os dias, é copiada uma cópia de segurança completa para o disco e para o armazenamento de arquivo.

A equipa do Cloud KMS documentou procedimentos para restaurar cópias de segurança de forma a mitigar a perda de dados quando ocorre uma emergência no lado do serviço.

Cópias de segurança. As cópias de segurança do arquivo de dados do Cloud KMS estão localizadas na região Google Cloud associada. Todas estas cópias de segurança são encriptadas em repouso. O acesso aos dados nas cópias de segurança é restrito com base nas justificações de acesso (como um número de pedido que apresentou ao Apoio técnico da Google), e o acesso humano é registado nos registos da Transparência de acesso.

Proteção. Na camada de aplicação do Cloud KMS, o seu material de chave é encriptado antes de ser armazenado. Os engenheiros com acesso ao repositório de dados não têm acesso a material de chave de cliente de texto simples. Além disso, o arquivo de dados encripta todos os dados que gere antes de escrever no armazenamento permanente. Por conseguinte, o acesso às camadas de armazenamento subjacentes, incluindo discos ou armazenamento de arquivo, não permite o acesso aos dados encriptados do Cloud KMS sem acesso às chaves de encriptação do repositório de dados, que estão armazenadas no repositório de chaves.

Política de rotação. A rotação de chaves faz parte das práticas recomendadas geralmente aceites para o processamento de material de chaves. Existe uma política de rotação para as chaves usadas para proteger os arquivos de dados do Cloud KMS. Também é aplicada uma política de rotação de chaves às chaves principais do keystore que envolvem as chaves principais do Cloud KMS. A chave principal do keystore tem uma idade máxima agendada do texto cifrado de 90 dias com uma idade máxima da chave em cache do cliente de um dia. O Cloud KMS atualiza as chaves principais do KMS nas tarefas do KMS a cada 24 horas e reencripta todas as chaves dos clientes mensalmente.

Residência dos dados. Os dados subjacentes a cada arquivo de dados do Cloud KMS permanecem exclusivamente na região à qual os dados estão associados. Google Cloud Isto também se aplica a localizações que abrangem várias regiões, por exemplo, a us região múltipla.

Disponibilidade da chave 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 de a camada de armazenamento confirmar a respetiva criação.

Back-ends de chaves e níveis de proteção

Quando cria uma chave com o Cloud KMS, pode escolher um nível de proteção para determinar que back-end de chaves cria a chave e executa todas as futuras operações criptográficas nessa chave. Os backends são expostos na API Cloud KMS como os seguintes níveis de proteção:

• SOFTWARE: aplica-se a chaves que podem ser desembrulhadas por um módulo de segurança de software para realizar operações criptográficas.
• HSM: aplica-se a chaves que só podem ser desembrulhadas por HSMs que realizam todas as operações criptográficas com as chaves.
• EXTERNAL ou EXTERNAL-VPC: aplicar ao gestor de chaves externo (EKM). O EXTERNAL-VPC permite-lhe ligar o EKM à Google Cloud através de uma rede VPC.

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

O nível de proteção SOFTWARE aplica-se a chaves cujas operações criptográficas são realizadas em software. Esta secção descreve os detalhes de como este nível é implementado.

Implementações algorítmicas

Para chaves de software, o Cloud KMS usa o módulo BoringCrypto na implementação do BoringSSL da Google para todo o trabalho criptográfico relacionado. O módulo BoringCrypto é validado pela FIPS 140-2. O binário do Cloud KMS é criado com base nas primitivas criptográficas validadas ao nível 1 da norma FIPS 140-2 deste módulo. Os algoritmos mais atuais abordados neste módulo estão listados em Objetivos e algoritmos das chaves, e incluem operações de encriptação, desencriptação e assinatura com chaves criptográficas simétricas AES256-GCM e assimétricas RSA 2048, RSA 3072, RSA 4096, EC P256 e EC P384.

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

Ao gerar chaves de encriptação, o Cloud KMS usa o BoringSSL. A norma FIPS 140-2 requer que sejam usados os seus próprios PRNGs (também conhecidos como DRBGs). No BoringCrypto, o Cloud KMS usa exclusivamente CTR-DRBG com AES-256. Isto fornece resultados para RAND_bytes, a interface principal através da qual o resto do sistema recebe dados aleatórios. Este PRNG é iniciado a partir do RNG do kernel do Linux, que, por sua vez, é iniciado a partir de várias origens de entropia independentes. Esta inicialização inclui eventos entrópicos do ambiente do centro de dados, como medições detalhadas de procuras de disco e tempos 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 a estrutura de RNG.

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

O Cloud HSM fornece chaves protegidas por hardware ao Cloud KMS. Permite-lhe usar chaves criptográficas protegidas por HSMs totalmente geridos e com certificação FIPS 140-2 Nível 3 nos centros de dados da Google. O Cloud HSM está altamente disponível e oferece uma escala elástica, tal como o Cloud KMS. Pode aceder ao back-end do Cloud HSM através da mesma API e bibliotecas de clientes que o Cloud KMS. Para mais informações sobre o back-end do Cloud HSM, consulte o artigo Arquitetura do Cloud HSM.

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

O Cloud EKM permite-lhe encriptar dados através de chaves de encriptação fora da nuvem que permanecem sob o seu controlo.

As chaves com os níveis de proteção EXTERNAL e EXTERNAL_VPC são armazenadas e geridas num sistema de gestão de chaves externo. Para mais informações, consulte o artigo Arquiteturas de referência para o EKM da nuvem.

Processo de criação de chaves

O diagrama seguinte ilustra o processo de criação de chaves para os diferentes backends de chaves e níveis de proteção.

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

1. Através da API Cloud KMS, um utilizador pede ao Cloud KMS para criar uma chave. Este pedido inclui o nível de proteção (se a chave está protegida por software, por hardware ou externamente).
2. O Cloud KMS valida a identidade do utilizador e se este tem autorizaçã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 um pedido para o Cloud HSM. O HSM na nuvem envia o pedido ao HSM para gerar uma nova chave. O HSM gera uma chave de cliente e encripta (envolve) esta chave com a chave de envolvimento regional do HSM. O Cloud HSM envia a chave com encapsulamento de volta para o Cloud KMS.
   • Para chaves externas, o Cloud KMS envia um pedido ao Cloud EKM. O Cloud EKM envia o pedido ao gestor de chaves externo para gerar uma nova chave. O EKM gera uma nova chave e encripta esta chave com a chave de envolvimento do EKM. O Cloud EKM envia a chave com encapsulamento de volta para o Cloud KMS.
4. O Cloud KMS encripta a chave do cliente envolvida com a chave principal do KMS e envia-a para o repositório de dados do KMS para armazenamento.
5. O Cloud KMS envia uma resposta de êxito com o URI completo da versão da chave ao utilizador.

Importação de chaves

Pode querer importar as suas próprias chaves que criou no local ou num EKM para o seu ambiente na nuvem. Por exemplo, pode ter um requisito regulamentar que as chaves usadas para encriptar os seus dados na nuvem sejam geradas de uma forma ou num ambiente específico. A importação de chaves permite-lhe importar estas chaves e cumprir as suas obrigações regulamentares. Para estender as suas capacidades de assinatura à nuvem, também pode 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 suportados. A encriptação do seu material de chaves com esta chave de encapsulamento protege o material de chaves em trânsito.

Usa a chave de encapsulamento pública para encriptar a chave a importar no cliente. A chave privada que corresponde à chave pública é armazenada no Google Cloud e é usada para desembrulhar a chave pública depois de chegar ao projetoGoogle Cloud . O método de importação que escolher determina o algoritmo usado para criar a chave de união. Depois de o material da chave ser encapsulado, pode importá-lo para uma nova chave ou versão da chave no Cloud KMS.

Pode usar chaves importadas com o nível de proteção HSM ou SOFTWARE. Para o Cloud HSM, a parte da chave privada da chave de envolvimento está disponível apenas no Cloud HSM. A restrição da parte da chave privada ao Cloud HSM impede que a Google desembrulhe o seu material de chave fora do Cloud HSM.

Ciclo de vida de um pedido do Cloud KMS

Esta secção descreve o ciclo de vida de um pedido do Cloud KMS, incluindo uma discussão sobre a destruição do material da chave. O diagrama seguinte mostra um cliente a pedir acesso a instâncias do serviço Cloud KMS em us-east1 e us-west1, e como os pedidos são encaminhados através do Google Front End (GFE).

Os passos neste ciclo de vida incluem o seguinte:

1. O pessoal da sua organização ou uma tarefa em execução em nome da sua organização compõe um pedido ao serviço Cloud KMS, https://cloudkms.googleapis.com. O DNS resolve este endereço para um endereço IP de anycast do GFE.
2. O GFE fornece alojamento de IP público do respetivo nome DNS público, proteção contra negação de serviço (DoS) e terminação de TLS. Quando envia o seu pedido, este é geralmente encaminhado para um GFE perto de si, independentemente da localização para a qual o pedido é segmentado. Os GFEs processam a negociação de TLS e, através do URL e dos parâmetros do pedido, determinam que equilibrador de carga de software global (GSLB) encaminha o pedido.
3. Existe um destino GSLB separado para cada região do Cloud KMS. Se o pedido chegar a um GFE em us-east1 e se destinar a us-west1, o pedido é encaminhado entre os centros de dados de us-east1 e us-west1. Toda a comunicação entre centros de dados é encriptada em trânsito através do ALTS, que autentica mutuamente o GFE e as tarefas do Cloud KMS.
4. Quando o pedido chega à tarefa do Cloud KMS, é processado primeiro por uma framework que processa grande parte do trabalho comum a todos osGoogle Cloud serviços. Esta estrutura autentica a conta e realiza várias verificações para validar o seguinte:
   • A conta tem uma credencial válida e pode ser autenticada.
   • O projeto tem a API Cloud KMS ativada e tem uma conta de faturação válida.
   • A quota é suficiente para executar o pedido.
   • A conta está na lista de autorizações para usar a regiãoGoogle Cloud relevante.
   • O pedido não é rejeitado pelos VPC Service Controls.
5. Depois de estas verificações serem aprovadas, a framework encaminha o pedido e a credencial para o Cloud KMS. O Cloud KMS analisa o pedido para determinar a que recursos está a aceder e, em seguida, verifica com o IAM se o autor da chamada tem autorização para fazer o pedido. O IAM também indica se a ocorrência do pedido deve ser escrita nos registos de auditoria. Se a opção Justificações de acesso a chaves estiver ativada, é enviada uma notificação de justificação que tem de aprovar.
6. Depois de o pedido ser autenticado e autorizado, o Cloud KMS chama os respetivos backends de armazenamento de dados na região para obter o recurso pedido. Depois de o recurso ser obtido, o material da chave é desencriptado para utilização.
7. Com o material da chave, o Cloud KMS executa a operação criptográfica, encaminhando a versão envolvida da chave para o back-end de software do Cloud KMS, o back-end do Cloud HSM ou o back-end do Cloud EKM, consoante o nível de proteção da chave.
8. Após a conclusão da operação criptográfica, a resposta é enviada de volta para si através do mesmo tipo de canal GFE para KMS que o pedido.
9. À medida que a resposta é devolvida, o Cloud KMS também aciona os seguintes eventos de forma assíncrona:
   • Os registos de auditoria e pedidos são preenchidos e colocados em fila para serem escritos.
   • Os relatórios são enviados para fins de faturação e gestão de quotas.
   • Se o pedido tiver atualizado os metadados de um recurso, a alteração é enviada para o Cloud Asset Inventory através de atualizações de tarefas em lote.

Integridade de dados de ponta a ponta

O Cloud KMS permite-lhe calcular somas de verificação para chaves e materiais de chaves para ajudar a garantir que não estão danificados. Estas somas de verificação ajudam a proteger-se contra a perda de dados que pode ser causada por danos no hardware ou no software. As bibliotecas auxiliares permitem-lhe validar a integridade das chaves. Pode usar bibliotecas auxiliares para validar a integridade das chaves fornecendo somas de verificação ao Cloud KMS, que são validadas pelo servidor. Além disso, estas bibliotecas permitem-lhe receber somas de verificação para validar os dados de resposta no cliente.

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

• Corrupção durante o trânsito, como na pilha entre o momento em que os dados são enviados e o momento em que são protegidos pelo TLS.
• Problemas em quaisquer proxies intermédios entre o seu ponto final e o KMS (por exemplo, para pedidos recebidos).
• Operações criptográficas defeituosas, corrupção da 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 o artigo Validar a integridade dos dados ponto a ponto.

Destruição do material da chave

O material das chaves é considerado dados do cliente, pelo que a abordagem descrita em Eliminação de dados no Google Cloud também se aplica ao Cloud KMS. O material das chaves é destruído mediante pedido quando o período Agendado para destruição estiver concluído e as cópias de segurança expirarem. O material da chave que ainda está presente nas cópias de segurança (após o período agendado para destruição ) só pode ser usado para recuperação de desastres regional e não para restaurar chaves individuais. Este processo não é garantido para cópias de chaves importadas que existam fora do controlo do Cloud KMS.

Por predefinição, as chaves no Cloud KMS permanecem 30 dias no estado Agendado para destruição (eliminado temporariamente) antes de o material da chave ser eliminado logicamente do sistema. Pode alterar esta duração. Para mais informações, consulte o artigo Duração variável do estado Agendado para destruição.

Embora o material da chave seja destruído, não é possível eliminar as chaves nem os conjuntos de chaves. Também não é possível eliminar as versões das chaves, mas é possível destruir o material das versões das chaves para que os recursos deixem de poder ser usados. Os porta-chaves e as chaves não têm custos faturáveis nem limitações de quota, pelo que a respetiva existência contínua não afeta os custos nem os limites de produção.

Depois de uma versão da chave ser agendada para destruição, a versão da chave não está disponível para operações criptográficas. Durante o período de eliminação pendente, pode restaurar a versão da chave para que não seja destruída.

Se eliminar uma chave importada por engano, pode importá-la novamente. Para mais informações, consulte Reimportar uma chave destruída.

Para evitar eliminar acidentalmente uma chave, considere as seguintes práticas recomendadas:

• Defina a restrição Minimum destroy scheduled duration per key para uma duração mais longa. Esta restrição define o período mínimo agendado para destruição para novas chaves.
• Aplique a restrição Restringir a destruição de chaves a chaves desativadas para que só seja possível destruir chaves desativadas. Para mais informações, consulte o artigo Exija que as chaves sejam desativadas antes da destruição.
• Crie uma função do KMS personalizada que não inclua a autorização cloudkms.cryptoKeyVersions.destroy.
• Altere o campo destroy_scheduled_duration para um período de tempo mais longo.

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

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

• Crie processos que desativem a chave durante alguns dias antes de a chave ser eliminada.

Dependências da infraestrutura da Google

Os elementos da plataforma do Cloud KMS são executados como tarefas de produção do Borg. Borg é o gestor de clusters de grande escala da Google para processar tarefas de publicação de APIs e tarefas em lote.

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

Tarefas de publicação da API Cloud KMS

Os trabalhos de publicação da API Cloud KMS são trabalhos de produção do Borg que atendem aos pedidos dos clientes para gerir e usar as respetivas chaves. As tarefas de publicação da API Cloud KMS também processam ações diferidas de pedidos de clientes, como a alternância de chaves de acordo com um horário, a criação de chaves assimétricas e a importação de chaves. Estes trabalhos de publicação são executados em todas as Google Cloud regiões onde o Cloud KMS está disponível. Cada tarefa está associada a uma única região e está configurada para aceder apenas a dados de sistemas localizados geograficamente naGoogle Cloud região associada.

Tarefas em lote do Cloud KMS

A plataforma Cloud KMS também mantém vários trabalhos em lote que são executados como trabalhos de produção do Borg em vários horários. As tarefas em lote são específicas da região e agregam apenas dados da região associada e são executadas na mesma. Google CloudAs tarefas que estes trabalhos realizam incluem o seguinte:

• Contagem de chaves ativas para a faturação do cliente.
• Agregue recursos da API de buffer de protocolo público para o Cloud KMS e encaminhe os metadados para o Cloud Asset Inventory. Os recursos neste contexto são todos os recursos que o Cloud KMS gere, por exemplo, chaves e conjuntos de chaves.
• Agregue todos os recursos e informações de relatórios para estatísticas empresariais.
• Dados de instantâneos para alta disponibilidade.
• Validar se todos os dados armazenados no arquivo de dados subjacente não estão danificados.
• Voltar a encriptar o material da chave do cliente quando a chave principal do KMS está a ser alternada.

Gerador de instantâneos de chaves do Cloud KMS

Para manter a elevada disponibilidade, a plataforma Cloud KMS mantém um arquivo de dados redundante em cada instância do serviço partilhado que aloja as tarefas do servidor da API Cloud KMS. Cada serviço partilhado implementa a sua própria instância do serviço de captura de ecrã. Esta redundância torna os serviços altamente independentes, pelo que uma falha numa zona tem um efeito limitado noutras zonas. Quando a tarefa da API Cloud KMS precisa de realizar uma operação criptográfica, consulta o banco de dados principal juntamente com as tarefas do snapshotter local em paralelo. Se o arquivo de dados principal estiver lento ou indisponível, a resposta pode ser fornecida a partir de um instantâneo, se o instantâneo tiver uma antiguidade máxima de duas horas. Os resumos são criados como resultado de uma tarefa em lote que é executada continuamente para cada região. As capturas de ecrã residem na região da nuvem associada ao material da chave.

Comunicações cliente-servidor

A Google usa a segurança de transporte da camada de aplicação (ALTS) para ajudar a fornecer segurança para comunicações cliente-servidor que usam o mecanismo de chamada de procedimento remoto (RPC) da Google.

Para mais informações, consulte o artigo Autenticação, integridade e encriptação 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 mitigação de riscos concebidas para otimizar a fiabilidade, a durabilidade e a disponibilidade, ao mesmo tempo que salvaguarda o material das chaves. Esta secção aborda a estrutura de funcionamento do serviço, as responsabilidades dos membros da equipa de operações, os mecanismos de autenticação e os protocolos de auditoria e registo. Esta secção aplica-se às capacidades de chaves protegidas por software e por hardware.

Engenheiros de software, engenheiros de fiabilidade de sites e operadores de sistemas

Os engenheiros de software são responsáveis por estabelecer parcerias com outros intervenientes, como gestores de produtos e engenheiros de fiabilidade do site (SREs), para conceber o sistema e escrever grande parte do código e dos testes para o serviço Cloud KMS. O código inclui a tarefa principal que processa os pedidos dos clientes, bem como tarefas secundárias para atividades como a replicação de dados e a faturação. Os SREs também podem escrever código. No entanto, as funções de engenheiros de software e SRE estão separadas. Os SREs são principalmente responsáveis pela manutenção do ambiente de produção para tarefas do Cloud KMS. Os SREs medem e alcançam a fiabilidade através do trabalho de engenharia e operações.

Os operadores de sistemas são responsáveis pelo processo de compilação e lançamento, pela monitorização, pelos alertas e pelo planeamento da capacidade do Cloud KMS. São os primeiros a responder a problemas e interrupções dos clientes do Cloud KMS. Por exemplo, os operadores de sistemas tiram partido das ferramentas e da automatização para minimizar o trabalho manual dos sistemas, de modo a poderem concentrar-se nos esforços que trazem valor a longo prazo.

As funções dos operadores de sistemas estão definidas em procedimentos operacionais padrão. Os operadores do sistema não acedem ao material das chaves dos clientes enquanto desempenham as suas funções.

Regionalidade dos recursos do Cloud KMS

Para ajudar a cumprir os principais requisitos de residência, pode criar recursos do Cloud KMS num de quatro tipos de Google Cloud localizações:

• Uma localização regional consiste em zonas num local geográfico específico, como o Iowa.
• Uma localização de região dupla consiste em zonas em dois locais geográficos específicos, como Iowa e Carolina do Sul.
• Uma localização multirregional consiste em zonas distribuídas por uma área geográfica geral, como os Estados Unidos.
• A localização global consiste em zonas espalhadas por todo o mundo. Quando cria os recursos do Cloud KMS na localização global, estes estão disponíveis a partir de zonas em todo o mundo.

As localizações representam as regiões geográficas onde os pedidos ao Cloud KMS para um determinado recurso são processados e onde as chaves criptográficas correspondentes são armazenadas.

Para mais informações sobre as localizações do Cloud KMS disponíveis, consulte o artigo Localizações do Cloud KMS.

Regiões da nuvem e centros de dados

Uma Google Cloud região contém um centro de dados específico ou um conjunto especificado de centros de dados, determinado pela respetiva designação como região única, região dupla, multirregião ou global. Para mais informações sobre Google Cloud regiões, consulte Google Cloud localizações.

Cada centro de dados contém racks de máquinas para computação, rede ou armazenamento de dados.Estas máquinas executam a infraestrutura Borg da Google.

Os centros de dados da Google têm requisitos de segurança física rigorosos. Qualquer espaço físico que possa conter dados do utilizador requer entradas com leitores de cartões e scanners de íris que são usados para autenticar os participantes. As portas não são mantidas abertas para várias pessoas. Cada pessoa tem de se autenticar individualmente. Não é permitido entrar nem sair destas áreas com sacos, a menos que sejam sacos transparentes explicitamente autorizados após inspeção pelo pessoal de segurança. É necessária uma autorização especial para introduzir ou retirar qualquer dispositivo eletrónico que possa transmitir ou registar dados.

Residência de chaves

Alguns setores exigem que as chaves criptográficas residam numa localização específica. O Cloud KMS tem termos de localização de dados com garantias sobre a residência dos dados. Conforme introduzido no artigo Regionalidade dos recursos do Cloud KMS, o Cloud KMS oferece quatro tipos de localizações regionais para ajudar a cumprir esses requisitos.

Para localizações únicas, duplas ou multirregionais, o Cloud KMS cria, armazena e processa as suas chaves protegidas por software e protegidas por hardware, bem como o material das chaves, apenas nessa localização. Os sistemas de armazenamento e processamento de dados que o Cloud KMS usa estão configurados para usar apenas recursos naGoogle Cloud região associada ao material da chave. O material essencial criado em localizações de duas regiões ou várias regiões não sai dos limites das localizações selecionadas.

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

O Cloud KMS não garante a residência dos metadados das chaves, dos registos de utilização nem do material das chaves em trânsito. Os metadados das chaves incluem nomes de recursos; propriedades de recursos do Cloud KMS, como o tipo de chave, o tamanho da chave e o estado da chave; políticas do IAM; e quaisquer dados derivados de metadados.

Quando usa CMEK, as seguintes restrições geográficas do Cloud KMS aplicam-se às suas chaves, independentemente das localizações personalizadas, de região dupla ou multirregião que escolher noutros Google Cloud produtos que suportam CMEK:

• Para uma região específica: uma vez que a região de uma chave do KMS gerida pelo cliente tem sempre de estar correlacionada com a região do recurso que protege num determinado serviço, as restrições de residência para chaves e recursos de região única são garantidas como compatíveis e aplicadas. Google Cloud
• Para localizações em duas regiões ou multirregionais: os utilizadores podem selecionar regiões múltiplas definidas pela Google para as respetivas chaves e Google Cloud recursos para garantir a conformidade com a residência. Para garantir esta residência geográfica, certifique-se de que as suas regiões noutros produtos correspondem à localização regional do Cloud KMS escolhida.

A tabela seguinte resume a residência do material essencial para o Cloud KMS.

Tipo de região	Em repouso, em utilização
Região única	Residente
Duas regiões ou várias regiões	Residir nas regiões que constituem a região dupla ou multirregião

Monitorização da regionalidade

Os serviços de monitorização de dados internos da Google monitorizam ativamente a residência de dados chave. O Cloud KMS envia alertas aos membros da equipa de SRE se detetar configurações incorretas acidentais ou se o material da chave sair dos limites da respetiva região configurada, for armazenado na região errada ou for acedido a partir da região errada.

Alta disponibilidade

O Cloud KMS pode ajudar a simplificar os seus requisitos de disponibilidade com base nas regiões que selecionar. Quanto mais detalhada for a localização, mais redundância tem de criar. Para aplicações com níveis de disponibilidade mais elevados, use localizações multirregionais em vez de tentar criar o seu próprio sistema de replicação de chaves. Tem de equilibrar as capacidades de redundância incorporadas com as suas necessidades de regionalização de dados.

Autenticação e autorização

O Cloud KMS aceita vários mecanismos de autenticação, como o OAuth2, o JWT e o ALTS. Qualquer que seja o mecanismo, o Cloud KMS resolve a credencial fornecida para identificar o principal (a entidade que está autenticada e a autorizar o pedido) e chama o IAM para ver se o principal está autorizado a fazer o pedido e se é escrito um registo de auditoria.

O Cloud KMS usa uma versão interna da Service Control API para muitos aspetos da gestão de serviços. Antes de uma tarefa do Cloud KMS processar um pedido, envia primeiro um pedido de verificação para a API Service Control, que aplica muitos controlos comuns a todos os serviços, como os seguintes: Google Cloud

• Verificar se ativou a API Cloud KMS e se tem uma conta de faturação ativa.
• Verificar se não excedeu a sua quota e comunicar a utilização da quota.
• Aplicação dos VPC Service Controls.
• Verificar se está na lista de autorizações para regiões de nuvem privada aplicáveis.

Gestão de quotas

O Cloud KMS tem limites de utilização, denominados quotas, em pedidos feitos ao serviço. O Cloud KMS contém as seguintes quotas:

• Quotas de pedidos criptográficos para operações como encriptar, desencriptar ou assinar.
• Quotas de pedidos de leitura para operações como obter metadados de chaves ou obter uma política de IAM.
• Quotas de pedidos de escrita para operações como criar uma chave ou definir uma política do IAM.

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

O Cloud HSM e o Cloud EKM têm quotas adicionais para operações criptográficas. Estas quotas têm de ser satisfeitas além da quota de pedidos criptográficos. As quotas do Cloud HSM e do Cloud EKM são cobradas ao projeto onde a chave reside e as quotas são aplicadas para cada localização.

Considere os seguintes exemplos:

• A descodificação de chamadas com uma chave de software em asia-northeast1 requer uma unidade da quota de pedidos criptográficos (globais).
• A criação de uma chave de HSM no us-central1 requer uma unidade de quota de pedidos de gravação e nenhuma quota de HSM.
• A chamada de encriptação com uma chave EKM em europe requer uma unidade da quota de pedidos criptográficos (global) e uma unidade da quota de pedidos de KMS externo em europe.

Para mais informações acerca do tipo de quotas disponíveis, consulte o artigo Quotas na utilização de recursos do Cloud KMS. Pode ver o seu limite de quota na Cloud Console. Os limites de quotas iniciais são limites flexíveis que pode pedir para serem ajustados com base nas necessidades da sua carga de trabalho.

Registo

Existem três tipos de registos associados ao Cloud KMS: registos de auditoria do Cloud, registos da Transparência de acesso e registos de pedidos internos.

Cloud Audit Logs

O Cloud KMS regista a sua atividade nos registos de auditoria do Cloud. Pode ver estes registos na consola do Google Cloud. Toda a atividade de administrador, por exemplo, a criação ou a destruição de uma chave, é registada nestes registos. Também pode optar por ativar o registo para todas as outras ações que usam uma chave, por exemplo, usar uma chave para encriptar ou desencriptar dados. Controla por quanto tempo quer reter os registos e quem pode vê-los.

Registos da Transparência de acesso

Os clientes elegíveis podem optar por ativar os registos da Transparência de acesso, que lhes fornecem registos de ações que os funcionários da Google realizam na sua Google Cloud organização. Os registos de transparência de acesso, juntamente com os registos do Cloud Audit Logs, podem ajudar a responder a perguntas sobre quem fez o quê, onde e quando.

Pode integrar os registos da Transparência de acesso com as suas ferramentas de gestão de eventos e informações de segurança (SIEM) existentes para automatizar as suas auditorias destas ações. Estes registos estão disponíveis na Cloud Console juntamente com os seus registos de auditoria do Cloud.

As entradas do registo da Transparência de acesso incluem os seguintes tipos de detalhes:

• O recurso e a ação afetados.
• A hora da ação.
• Os motivos da ação. Alguns exemplos de motivos incluem apoio técnico iniciado pelo cliente (com um número do registo), apoio técnico iniciado pela Google, pedidos de dados de terceiros e pedidos de revisão iniciados pela Google.
• Dados sobre quem está a agir sobre os dados (por exemplo, a localização do membro do pessoal da Google).

Registos de pedidos internos

Os registos de pedidos armazenam um registo para cada pedido enviado para a plataforma Cloud KMS. Este registo contém detalhes sobre o tipo de pedido (como o método ou o protocolo da API) e o recurso acedido (como o nome do recurso, o algoritmo da chave ou o nível de proteção da chave). Estes registos não armazenam texto simples, texto cifrado nem material de chaves dos clientes. Antes de serem adicionados novos tipos de dados a estes registos, uma equipa especializada em revisões de privacidade tem de aprovar as alterações aos dados que são registados.

As entradas de registo são eliminadas permanentemente quando o tempo de vida (TTL) configurado expira.

Os engenheiros e os SREs do Cloud KMS em rotação de disponibilidade podem aceder aos registos de pedidos. O acesso humano aos registos e qualquer acesso que devolva dados de clientes requer uma justificação empresarial válida e documentada. Com algumas exceções> específicas, o acesso humano é registado e acessível aos clientes elegíveis nos registos da Transparência de acesso.

Monitorização

O Cloud KMS integra-se com o Cloud Monitoring. Esta integração permite-lhe monitorizar, criar painéis de controlo e criar alertas em muitas operações do Cloud KMS. Por exemplo, pode monitorizar quando as chaves estão agendadas para destruição ou monitorizar e ajustar as quotas do Cloud KMS quando as operações criptográficas ultrapassam um limite que define. Para mais informações sobre as métricas do Cloud KMS disponíveis, consulte o artigo Usar o Cloud Monitoring com o Cloud KMS.

Além disso, o Security Command Center tem detetores de vulnerabilidades do KMS incorporados. Estes detetores ajudam a garantir que os seus projetos que incluem chaves seguem as nossas práticas recomendadas. Para mais informações sobre o detetor de vulnerabilidades do KMS, consulte o artigo Resultados de vulnerabilidades para o Cloud KMS.

O que se segue?

• Para saber mais sobre o Cloud KMS, explore os seguintes recursos:
  • Documentação do Cloud KMS
  • Documentação do Cloud HSM
• Para obter informações sobre a utilização das suas próprias chaves de encriptação no Google Cloud, consulte o artigo Chaves de encriptação geridas pelo cliente (CMEK).
• Para saber mais sobre a segurança da infraestrutura da Google, consulte a vista geral do design de segurança da infraestrutura da Google.