Análise detalhada do Cloud Key Management Service

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

O Google Cloud trabalha com o princípio fundamental de que os clientes são proprietários dos dados e devem controlar o uso deles.

Quando você armazena dados usando o Google Cloud, eles são criptografados em repouso por padrão. Ao usar a plataforma Cloud Key Management Service (Cloud KMS), você tem mais controle sobre como criptografar seus dados em repouso e como gerenciar suas chaves de criptografia.

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

Tipo de chave	Gerenciamento de chaves	Compartilhamento de chaves	Rotação automática	Preços
Chave de criptografia padrão	Essas chaves são gerenciadas somente pelo Google.	Os dados de vários clientes podem usar a mesma chave de criptografia de chaves (KEK, na sigla em inglês).	Sim, consulte Criptografia padrão em repouso.	Grátis.
Chaves do Cloud KMS	Essas chaves são controladas pelo cliente.	Exclusivo para um cliente.	Sim para criptografia simétrica, não para chaves assimétricas. Consulte Rotação de chave.	Consulte os preços do Cloud Key Management Service.

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 no 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.

Pilares do design 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 cinco pilares de design a seguir:

• 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 na região selecionada do Google Cloud.
• 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.

Fontes e opções de gerenciamento dos principais materiais

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 diagrama a seguir mostra o portfólio de chaves do Google Cloud, organizado do material de chaves controlado pelo Google para o material de chaves controlado pelo cliente.

As opções mostradas no diagrama anterior são as seguintes:

• 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 geradas por software: com o Cloud KMS, é possível controlar as chaves geradas pelo Google. 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 geradas 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 simétricas e assimétricas sejam usadas apenas no Nível 3 do FIPS 140-2 HSMs validados.

• 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 Cloud e 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 implantação confiável dos serviços do Cloud EKM.

É possível usar chaves geradas pelo Cloud KMS com outros serviços do Google Cloud. Essas chaves são conhecidas como chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês). O recurso CMEK permite gerar, usar, rotacionar e destruir chaves de criptografia usadas para ajudar a proteger dados em outros serviços do Google Cloud.

Conceitos de criptografia e de 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 principais 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 do Google Cloud e permanece 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 te deixam 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 de software

O diagrama a seguir ilustra a hierarquia de chaves do Cloud KMS e do keystore interno do Google. O Cloud KMS usa o Keystore, que é o serviço interno de gerenciamento de chaves do Google, para encapsular chaves criptografadas do Cloud KMS. Criptografia de envelopes é o processo de criptografar uma chave usando outra para armazená-la com segurança ou transmiti-la por um canal não confiável. O Cloud KMS usa a mesma raiz de confiança que o Keystore.

A hierarquia de chaves mostrada no diagrama anterior é a seguinte:

1. Uma chave de criptografia de dados (DEK) criptografa os blocos de dados.
2. 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.
3. Uma chave mestra do KMS 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. As KEKs no Cloud KMS são protegidas pela chave mestra do KMS do local. Cada servidor do Cloud KMS busca uma cópia da chave-mestra KMS durante a inicialização como uma dependência forte, e uma nova cópia da chave-mestra KMS é recuperada todos os dias. A chave-mestra KMS passa por nova criptografia periodicamente.
4. A chave mestra do KMS é protegida pela chave mestra do armazenamento de chaves.
5. A chave mestra do armazenamento de chaves é protegida pela chave mestra do repositório de chaves.

Para mais informações sobre o Keystore, acesse Gerenciamento de chaves no artigo Criptografia em repouso.

Principais 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. É possível hospedar dados em um projeto diferente do projeto em que as chaves do Cloud KMS estão. Para dar suporte à prática recomendada de separação de deveres entre os administradores de chave e administradores de dados, remova o papel de proprietário do projeto principal.
• 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.

Visão geral da plataforma Cloud KMS

A plataforma Cloud KMS aceita vários algoritmos criptográficos e fornece métodos para criptografar e assiná-los digitalmente usando chaves compatíveis com hardware e software e externas. 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 o modo 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. As chaves baseadas em software e em hardware usam proteções de backup redundantes do Google.

• Se você usar chaves de 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 suporta muitos dos sistemas críticos 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.

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 regiões do Google Cloud 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 do 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) do Google.

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

Arquitetura da plataforma Cloud KMS

Nesta seção, você verá detalhes da arquitetura sobre a Segurança dos materiais da chave e a proteção do repositório de dados.

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) 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 associada do Google Cloud. 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 do Google Cloud à qual 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.

Back-end da chave

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 nessa chave. 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 (BCM) na implementação BoringSSL do Google para todo o trabalho criptográfico relacionado. O BCM é validado por 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. Os clientes atuais do Cloud KMS não precisam fazer alterações em aplicativos porque podem acessar o back-end Cloud HSM usando a mesma API e as mesmas bibliotecas de cliente que o 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 externo. Para mais informações, consulte Arquiteturas de referência para implantação confiável dos serviços do Cloud EKM.

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 no Google Cloud e usada para desencapsular a chave pública depois de chegar ao projeto do Google 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.

Chaves de criptografia gerenciadas pelo cliente (CMEK)

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 alguns produtos do Google Cloud, você pode usar o Cloud KMS para gerenciar as chaves usadas para criptografia. O CMEK pode ser usado para chaves externas, com software e hardware. 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.

A rotação da chave não criptografa novamente os dados no serviço CMEK associado. Em vez disso, 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. Por exemplo, o BigQuery não rotaciona automaticamente a chave criptográfica de uma tabela quando a chave do Cloud KMS associada à tabela é rotacionada. As tabelas atuais do BigQuery continuam usando a versão da chave com que foram criadas. As novas tabelas do BigQuery usam a versão atual da chave. Para mais informações, 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.

O 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 do Google Cloud.

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. Um cliente, ou um job em execução em nome de um cliente, 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 o cliente envia a solicitação, ele geralmente é encaminhado para um GFE próximo ao cliente, independentemente do local para onde a solicitação do cliente é 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 ao Google em us-east1 e a solicitação 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 do Google Cloud. Esse framework autentica o usuário e realiza várias verificações para confirmar se:
   • O cliente tem uma credencial válida e pode ser autenticado.
   • A API Cloud KMS está ativada no projeto e tem uma conta de faturamento válida.
   • A cota é suficiente para executar a solicitação.
   • O cliente está na lista de permissões para usar a região relevante do Google 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 informa ao Cloud KMS se a ocorrência da solicitação precisa ser gravada nos registros de auditoria.
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 do cliente é 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 ao cliente 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 alguns 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 esteja 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:

• 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.

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 do Google 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 específico de data centers, determinados pela designação como local único, birregional, multirregional ou global. Para mais informações sobre as regiões do Google Cloud, consulte Locais do Google 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 para configurar apenas os recursos na região do Google Cloud associada ao material da chave. O material de chave criado em locais birregionais ou multirregionais não deixa os 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 compatíveis com 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 serviço do Google Cloud, 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 e 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 do Google 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 no Google Cloud, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).
• Saiba como o Google está se preparando para um mundo pós-quântico.
• Para saber mais sobre a segurança da infraestrutura do Google, consulte Visão geral do design de segurança da infraestrutura do Google.
• Para mais informações sobre a segurança do Google Cloud, acesse esta seção no site do Google Cloud.