Esta página foi traduzida pela API Cloud Translation.
Switch to English

Análise detalhada do Cloud Key Management Service

Autores: Sonal Shah, Il-Sung Lee, Walter Poupore, Hunter Freyer, Honna Segel, Dwight Worley

Agradecimentos: Adrian Sears, John Randolph, Tim Dierks, Chris Rezek, Stanley McKenzie, Kevin Plybon, David Hale, Sergey Simakov, David U. Lee, Carrie McDaniel, Anton Chuvakin, Dave Tonisson

Última atualização: abril de 2020

1. Introdução

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 plataforma Cloud KMS permite que os clientes do Google Cloud gerenciem chaves criptográficas em um serviço de nuvem central para uso direto ou por outros recursos e aplicativos na nuvem. Para a origem das chaves, o Cloud KMS fornece as seguintes opções:

  • O back-end do software do Cloud KMS oferece a flexibilidade de criptografar seus dados com uma chave simétrica ou assimétrica controlada por você (Cloud KMS).
  • Caso precise de uma chave de hardware, é possível usar o Cloud HSM para garantir que suas chaves simétricas e assimétricas sejam usadas apenas nos módulos de segurança de hardware (HSM, na sigla em inglês) validados pelo FIPS 140-2 Nível 3.
  • O Cloud KMS permite importar suas próprias chaves criptográficas caso seja necessário usar chaves geradas por você mesmo.
  • É possível usar chaves geradas pelo Cloud KMS com outros serviços do Google Cloud. Elas 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 proteger dados em outros serviços do Google Cloud.
  • O Cloud External Key Manager (Cloud EKM) permite criar e gerenciar chaves em um ambiente externo ao Google Cloud, além de configurar a plataforma Cloud KMS para usar as chaves externas e proteger dados em repouso. É possível usar chaves de criptografia gerenciadas pelo cliente com uma chave do Cloud EKM. No momento, o Cloud EKM não faz parte do escopo deste whitepaper.

O Google também oferece suporte a chaves de criptografia fornecidas pelo cliente (CSEK) para o Compute Engine e o Cloud Storage. Dessa forma, os dados são descriptografados e criptografados usando-se uma chave fornecida na chamada de API. A CSEK não faz parte do escopo deste documento. Para mais informações, consulte a documentação on-line.

"Diagrama do portfólio do 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, em uma plataforma simples de usar. O Cloud KMS tem como base cinco alicerces fundamentais:

  • Controle do cliente. O Cloud KMS permite gerenciar chaves de criptografia de software e hardware ou fornecer suas próprias chaves.
  • Controle de acesso e monitoramento. O Cloud KMS permite gerenciar permissões em chaves individuais e monitorar como as chaves são usadas.
  • Região. O Cloud KMS oferece regionalização pronta para uso. O serviço foi configurado para criar, armazenar e processar chaves de software somente na região selecionada do Google Cloud.
  • Durabilidade. O Cloud KMS corresponde aos padrões de durabilidade mais altos do Google Cloud. 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ções duradouras contra o acesso não autorizado a chaves e é totalmente integrado aos controles do gerenciamento de identidade e acesso (IAM, na sigla em inglês) e dos registros de auditoria do Cloud.

Este documento aborda o funcionamento interno da plataforma Cloud KMS, que está na versão de disponibilidade geral (GA). 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.

2. Conceitos de criptografia e de gerenciamento de chaves no Google

Esta seção define alguns dos termos e definições para o gerenciamento de chaves no contexto da infraestrutura de gerenciamento de chaves em várias camadas do Google.

2.1. Chaves, versões de chaves e keyrings

Esta seção descreve chaves, versões de chaves e o agrupamento de chaves em keyrings. O diagrama a seguir ilustra os agrupamentos de chaves. As definições relacionadas estão descritas abaixo do diagrama.

"Diagrama de agrupamentos de chaves."

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

    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 criptografia simétrica a fim de proteger alguns corpus de dados. Por exemplo, usando AES-256 no modo GCM para criptografar um bloco de texto simples. Uma chave assimétrica pode ser usada para criptografia assimétrica ou para criar assinaturas digitais. As finalidades e os algoritmos compatíveis estão descritos na documentação do Cloud KMS.

  • 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 do IAM diretamente do keyring que as contém. 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 keyring fornecem conveniência e categorização, mas, se o agrupamento de keyrings não for útil para você, gerencie as permissões diretamente nas chaves.

    Para evitar conflitos de nome de recurso, um keyring não pode ser excluído. 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. Para mais detalhes sobre a exclusão de chaves e materiais de chaves, consulte a seção sobre exclusão mais adiante neste artigo.

  • Metadados de chaves: nomes de recursos, propriedades de recursos do KMS, como políticas do IAM, tipo de chave, tamanho da chave, estado da chave e quaisquer dados derivados dos itens citados. Os metadados das chaves podem ser gerenciados de maneira diferente do material delas.

  • Versão da chave: representa 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, limitando o uso de qualquer versão única. As chaves simétricas sempre apresentam uma versão principal. Essa versão é usada para criptografia por padrão. 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.

2.2. Hierarquia de chaves

O diagrama a seguir ilustra a hierarquia de chaves do serviço de gerenciamento de chaves interno do Google. O Cloud KMS aproveita o KMS interno do Google porque as chaves criptografadas do Cloud KMS são unidas pelo Google KMS. O Cloud KMS usa a mesma raiz de confiança que o Google KMS. As definições relacionadas estão descritas abaixo do diagrama.

"Diagrama da hierarquia interna de chaves"

  • Chave de criptografia de dados (DEK, na sigla em inglês): chave usada para criptografar dados.
  • Chave de criptografia de chaves (KEK, na sigla em inglês): chave usada para criptografar ou unir uma chave de criptografia de dados. Todas as opções da plataforma Cloud KMS (software, hardware e back-ends externos) permitem controlar a chave de criptografia de chaves.
  • Chave-mestra do KMS: a chave usada para criptografar as chaves de criptografia de chaves (KEK). Essa chave é distribuída na memória. O backup da chave-mestra do KMS é feito em dispositivos de hardware. Essa chave é responsável por criptografar suas chaves.
  • KMS raiz: serviço interno de gerenciamento de chaves do Google.

2.3. Operaçõ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. Esse recurso é compatível com práticas recomendadas de separação de deveres entre os principais administradores e administradores de dados.
  • Locais: em um projeto, os recursos do Cloud KMS são criados em um local. Para mais informações, consulte Geografia e regiões.

3. 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. A plataforma do Cloud KMS é integrada ao gerenciamento de identidade e acesso (IAM, na sigla em inglês) 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.

"Diagrama de arquitetura do Cloud KMS."

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 Google Cloud ou a ferramenta de linha de comando gcloud, ou por meio de aplicativos que implementam as APIs REST ou gRPC. Os aplicativos acessam serviços de gerenciamento de chaves usando uma API REST ou gRPC. Os aplicativos podem usar os Serviços do Google que usam chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês). O CMEK, por sua vez, usa a API Cloud KMS. A API Cloud KMS permite usar chaves de software (Cloud KMS) ou de hardware (Cloud HSM). As chaves baseadas em software e em hardware utilizam as proteções de backup redundantes do Google.

A plataforma Cloud KMS permite escolher um nível de proteção ao criar uma chave para determinar qual back-end cria a chave e realiza todas as futuras operações criptográficas nela. A plataforma Cloud KMS fornece dois back-ends (exceto o Cloud EKM), que são expostos na API Cloud KMS como os níveis de proteção SOFTWARE e HSM. O nível de proteção SOFTWARE se aplica a chaves que podem ser separadas por um módulo de segurança de software para executar operações criptográficas. O nível de proteção HSM se aplica a chaves que só podem ser separadas por módulos de segurança de hardware que executam todas as operações criptográficas com as chaves.

O Google Cloud é compatível com CMEK para vários serviços, incluindo Cloud Storage, BigQuery e Compute Engine. A CMEK permite que você use a plataforma Cloud KMS para gerenciar as chaves de criptografia que esses serviços usam para proteger seus dados.

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

3.1. Ambiente e dependências

Nesta seção, você verá detalhes sobre a infraestrutura do Google em que a plataforma Cloud KMS é executada e sobre os protocolos de comunicação usados pela infraestrutura.

3.1.1. Jobs do Borg do Cloud KMS

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 detalhes sobre a segurança da nossa infraestrutura física e de produção, consulte Visão geral do design de segurança da infraestrutura do Google.

3.1.1.1. 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. 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. Para mais informações sobre a residência das chaves, consulte Regionalidade posteriormente neste documento.

3.1.1.2. 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:

  • Contagem de chaves ativas para o faturamento dos clientes.
  • Agregação de recursos da API de buffer de protocolo público do Cloud KMS e encaminhamento dos 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.
  • Agregação de todos os recursos e geração de informações para análises de negócios.
  • Captura de dados de snapshot para alta disponibilidade.
  • Validação de 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.
3.1.1.3. Capturador de snapshot da chave do Cloud KMS

Para manter a alta disponibilidade, a plataforma Cloud KMS mantém um armazenamento de dados redundante em cada instância de um serviço compartilhado que hospeda as tarefas do servidor da API Cloud KMS. Cada serviço 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. A API Cloud KMS usa o job que concluir a solicitação primeiro. Para evitar um atraso no pipeline de captura de snapshot, que pode resultar na exibição de dados excessivamente desatualizados, o servidor da API não usa os resultados dos jobs do capturador de snapshot quando eles têm 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.

3.1.2. Comunicações entre servidores e clientes

O Google usa o Application Layer Transport Security (ALTS) para oferecer segurança a comunicações entre servidores e clientes (criptografia em trânsito) que usam o mecanismo de chamada de procedimento remoto (RPC) do Google. O ALTS fornece o seguinte:

  • um protocolo de autenticação ponto a ponto para aplicativos;
  • um protocolo de criptografia de registros;
  • uma API que expõe o usuário autenticado para autorização.

Os protocolos de handshake e criptografia de registros do ALTS são semelhantes aos protocolos de handshake e de registro da Transport Layer Security (TLS). O ALTS faz diferentes compensações para otimizar o ambiente de produção do Google e está totalmente integrado a todo o hardware de produção e pilha de software. Para mais detalhes, consulte Ambiente operacional da plataforma Cloud KMS posteriormente neste documento.

4. Detalhes da arquitetura da plataforma Cloud KMS

Esta seção é dividida em detalhes da arquitetura, começando pela segurança do material da chave e pela proteção do armazenamento de dados. Em seguida, detalhamos as opções da fonte do material da chave:

Esta seção também descreve as opções de chaves de criptografia gerenciadas pelo cliente (CMEK).

Para fornecer uma visualização dinâmica de como as estruturas arquitetônicas introduzidas até o momento são usadas, descrevemos neste documento o ciclo de vida de uma solicitação do Cloud KMS, incluindo uma discussão sobre a destruição do material da chave.

4.1. 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 for 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). O Application Layer Transport Security (ALTS), descrito anteriormente na seção sobre comunicações entre servidores e clientes, é usada para criptografia entre jobs do Cloud KMS e seus back-ends em diferentes data centers. O ALTS e a criptografia em trânsito são descritos mais detalhadamente em Ciclo de vida de uma solicitação do Cloud KMS, mais adiante neste documento.

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

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

Os jobs da API Cloud KMS podem acessar metadados de chave, como a política do IAM 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. Os acessos 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.

No entanto, o material de chave não pode ser acessado por jobs da API Cloud KMS e não pode ser exportado nem 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. O material da chave também é criptografado com uma chave-mestra no KMS raiz, que não pode ser acessada diretamente por qualquer pessoa.

4.2. Proteção do armazenamento de dados

Esta seção descreve como os dados principais são protegidos pelo Google KMS.

4.2.1. Chaves-mestras

O Cloud KMS usa uma chave-mestra para unir todas as chaves do cliente em repouso. Cada servidor do Cloud KMS busca uma cópia da chave-mestra durante a inicialização como uma dependência forte, e uma nova cópia da chave-mestra é recuperada todos os dias. A chave-mestra passa por nova criptografia periodicamente.

4.2.2. 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 internas do KMS que unem as chaves do Cloud KMS. A chave-mestra do KMS 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 nas tarefas do KMS a cada 24 horas e criptografa de novo todas as chaves do cliente mensalmente.

4.2.3. 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. Para mais detalhes sobre residência de dados, consulte Regionalidade ao longo deste artigo.

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

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

4.4.1. 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 na página de documentação 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.

4.4.2. 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 a saída para RAND_bytes, a interface principal usada pelo restante do sistema para recebimento de 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úmero aleatório para o BoringSSL (modo compatível com FIPS), consulte o design do RNG.

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

O serviço do Cloud HSM fornece chaves protegidas por hardware para o Cloud KMS. Ele oferece aos clientes a capacidade de gerenciar e usar chaves criptográficas protegidas por módulos de segurança de hardware (HSMs, na sigla em inglês) totalmente gerenciados nos data centers do Google. O serviço é altamente disponível e faz escalonamento automático horizontalmente. As chaves são criptograficamente vinculadas à região do KMS em que o keyring foi definido. Ao usar o Cloud HSM, as chaves que você cria e usa não podem ser materializadas fora do cluster de HSMs na região especificada no momento da criação da chave. O Cloud HSM permite atestar que suas chaves criptográficas são criadas e usadas exclusivamente em um dispositivo de hardware. Não é necessária nenhuma alteração de aplicativo para que os clientes atuais do Cloud KMS usem o Cloud HSM. Os serviços desse produto são acessados com a mesma API e as mesmas bibliotecas de cliente do back-end de software do Cloud KMS.

O Cloud HSM usa HSMs validados por FIPS 140-2 Nível 3 e estão sempre em execução no modo FIPS. O padrão do FIPS especifica os algoritmos criptográficos e a geração de números aleatórios usados pelos HSMs.

4.5.1. HSMs do Cavium

O cartão HSM PCIe do Cavium é validado pelo fornecedor para ser compatível com o Nível 3 do FIPS 140-2. O certificado atual está disponível mediante solicitação.

4.5.2. Hierarquia de chaves do HSM

No diagrama a seguir, vemos o Cloud KMS na metade superior do diagrama. O Cloud HSM une as chaves do cliente e, em seguida, o Cloud KMS une as chaves do HSM que são passadas para o armazenamento de dados do Google.

"Diagrama da hierarquia de chaves do HSM"

O Cloud HSM tem uma chave (não mostrada) que controla a migração de material dentro do domínio administrativo do Cloud HSM. Uma região pode ter vários domínios administrativos de HSM.

A chave raiz do HSM tem duas características:

  1. É gerada em um HSM e, durante todo o ciclo de vida, nunca deixa os limites bem definidos dos HSMs. Pode ser replicada em outros HSMs ou em HSMs de backup.
  2. Ela pode ser usada como uma chave de criptografia de chaves para unir direta ou indiretamente as chaves do cliente que os HSMs usam.

As chaves do cliente unidas por chaves raiz do HSM podem ser usadas no HSM, mas o HSM nunca retorna o texto simples da chave do cliente. O HSM só usa a chave do cliente para operações.

4.5.3. Proteção do armazenamento de dados

Os HSMs não são usados como armazenamento permanente para chaves. Eles realizam essa função somente enquanto elas estão em uso. Como o armazenamento do HSM é restrito, as chaves do HSM são criptografadas e mantidas no armazenamento de dados de chaves do Cloud KMS. Este assunto é descrito em detalhes no back-end do Datastore, mais adiante neste documento.

4.5.4. Política de rotação

Vários tipos de chaves estão envolvidos na estratégia de proteção de chaves do Cloud HSM. Os clientes rotacionam as próprias chaves e confiam no Cloud KMS para rotacionar as chaves do HSM.

4.5.5. Processo de provisionamento e processamento

O provisionamento de HSMs é realizado em um laboratório preparado com várias proteções físicas e lógicas, incluindo, por exemplo, controles de autorização de várias partes para evitar o comprometimento de um único ator.

Veja a seguir as invariantes do nível do sistema do Cloud HSM:

  1. As chaves do cliente não podem ser extraídas como texto simples.
  2. As chaves do cliente não podem ser movidas fora da região de origem.
  3. Todas as alterações de configuração em HSMs provisionados são protegidas por vários sistemas de segurança.
  4. As operações administrativas são registradas, adotando a separação de tarefas entre os administradores do Cloud HSM e os administradores de geração de registros.
  5. Os HSMs são projetados para receber proteção contra adulterações (como a inserção de modificações de hardware ou software maliciosos ou extração não autorizada de secrets) durante todo o ciclo de vida operacional.

4.5.6. Firmware controlado pelo fornecedor

O firmware do HSM é assinado digitalmente pelo fornecedor do HSM. O Google não pode criar nem atualizar o firmware do HSM. Todo firmware do fornecedor é assinado, incluindo o firmware de desenvolvimento usado para testes.

4.5.7. Regionalidade

As chaves de cliente são atribuídas a regiões geográficas específicas como resultado da vinculação a uma chave raiz específica do HSM. Por exemplo, uma chave criada especificamente na região us-west1 não pode migrar para a região us-east1 ou para uma multirregião us. Da mesma forma, uma chave criada na multirregião us não pode migrar para dentro ou fora da região us-west1.

4.6. Cloud KMS: importação de chaves

É recomendável importar suas próprias chaves 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. O Cloud KMS permite importar as próprias chaves criptográficas criadas no local ou em um gerenciador de chaves externo. A importação de chaves permite importar essas chaves e atender a essas obrigações regulatórias. Também é possível importar chaves assimétricas para estender os recursos de assinatura até a nuvem.

Como parte da importação de chaves, o Cloud KMS gera uma chave de união, 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.

Essa chave de união pública do Cloud KMS é usada para criptografar, no cliente, a chave a ser importada. A chave privada correspondente a essa chave pública é armazenada no Google Cloud e é usada para separar a chave depois que ela chega 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.

As chaves importadas podem ser usadas 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.

4.7. 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, os clientes podem usar o Cloud KMS para gerenciar as chaves usadas para criptografia. O CMEK pode ser usado para chaves com software e hardware. O Cloud KMS permite que o cliente 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. O Cloud KMS inclui vários papéis predefinidos do IAM que têm privilégios e limitações específicos e podem ser concedidos a usuários e contas de serviço específicos para aplicar uma separação recomendada de tarefas.

Os tópicos a seguir contêm detalhes sobre produtos integrados à plataforma Cloud KMS compatíveis com CMEK:

O impacto da rotação de chaves na versão de chave usada depende de como um produto implementa as CMEKs. Em geral, a rotação da chave do Cloud KMS não criptografa novamente os dados no serviço CMEK associado. 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.

Consulte esta documentação para ver a lista completa de integrações com CMEK e serviços compatíveis com esse recurso. O Google continua investindo na integração do CMEK com outros produtos do Google Cloud.

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

Para fornecer uma visualização dinâmica de como as estruturas arquitetônicas introduzidas até o momento são usadas, esta seção descreve o ciclo de vida de uma solicitação do Cloud KMS, incluindo uma discussão sobre a destruição do material da chave.

"Diagrama do ciclo de vida da solicitação do KMS"

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 Google Front End (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.
    • O projeto do Google Cloud tem a API Cloud KMS ativada 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 será 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. Após a busca, 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 unida da chave para o back-end do software do Cloud KMS ou para o Cloud HSM, 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.

4.9. Destruição de materiais das chaves

A exclusão de dados no Google Cloud é descrita neste whitepaper. O material da chave é considerado como dados do cliente. Portanto, a abordagem descrita no whitepaper se aplica ao Cloud KMS. Além disso, como o Google nunca compartilha o material da chave fora do Cloud KMS, o material da chave é destruído na solicitação quando o período de exclusão pendente de 24 horas é concluído e os backups expiram. Esse processo não tem garantia de cópias de chaves importadas que existem fora do controle do Cloud KMS.

Enquanto o material da chave é destruído conforme descrito acima, 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 ela é programada para destruição, uma versão de chave não fica disponível para operações criptográficas. Dentro do período de 24 horas, o usuário pode restaurar a versão da chave para que ela não seja destruída.

5. 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. A discussão a seguir se aplica aos principais recursos de software e hardware.

5.1. 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, por fim, 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.

5.2. Regionalidade dos recursos do Cloud KMS

É possível criar recursos do Cloud KMS em um dos quatro tipos de locais do Google Cloud:

  • Locais regionais: um local regional consiste em zonas em um ponto geográfico específico, como Iowa.
  • Locais birregionais: um local birregional consiste em zonas em dois lugares geográficos específicos, como Iowa e Carolina do Sul.
  • Locais multirregionais: um local multirregional consiste em zonas espalhadas por uma área geográfica geral, como os Estados Unidos.
  • O local global. 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 a documentação do produto.

5.2.1. 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/ou verificadores de íris usados para autenticar participantes. As portas não devem ser abertas para várias pessoas. Cada um 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.

5.2.2. Regionalidade

Alguns setores exigem que as chaves criptográficas residam em um local específico. Conforme mencionado acima, 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 do cliente 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 da chave criado em locais birregionais ou multirregionais não sai dos limites dos locais selecionados.

Para a região global, não há garantia especificada de regionalidade.

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, escolhidos em outros produtos do Google Cloud que você quer usar com a 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 correlações multirregionais definidas pelo Google para as chaves e recursos do Google Cloud para garantir a conformidade com a residência. 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.

Residência de dados do Cloud KMS Em repouso, em uso
(região única)
Em repouso, em uso
(birregional/multirregional)
Material da chave de software Residente Residente nas regiões que formam a birregião/multirregião.
Material da chave de hardware (HSM) Residente Residente nas regiões que formam a birregião/multirregião.

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

5.3. 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 o cliente ativou a API Cloud KMS e se tem uma conta de faturamento ativa.
  • Verificar se o cliente não excedeu a cota e informar o uso atual.
  • Aplicar o VPC Service Controls.
  • Verificar se o cliente está na lista de permissões para regiões de nuvem privada aplicáveis.

5.4. Logging

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.

5.4.1. Registros de auditoria do Cloud

O Cloud KMS registra a atividade do cliente nos registros de auditoria do Cloud. Os clientes podem ver esses registros no Console do Cloud. Todas as atividades do administrador, como criar ou destruir uma chave, são gravadas nesses registros. Os clientes também podem optar por 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. Os clientes controlam por quanto tempo desejam manter os registros e quem pode visualizá-los.

5.4.2. Registros de transparência no acesso

Os clientes qualificados podem optar por ativar os registros de transparência no acesso para saber sobre as ações que os funcionários do Google realizam na organização deles no 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)

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

5.5. Back-end 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 várias horas. 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 a fita.

A equipe do Cloud KMS documentou procedimentos para restaurar backups em emergências.

Residência. Os backups do armazenamento de dados do Cloud KMS residem 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 chave do cliente é criptografado antes de ser armazenado. Os engenheiros do Datastore não têm acesso ao material de chave do cliente em texto simples. Além disso, o armazenamento de dados criptografa todos os dados gerenciados antes de gravar no armazenamento permanente. Portanto, o acesso a camadas de armazenamento subjacentes, incluindo discos ou fitas, não inclui acesso a dados criptografados do Cloud KMS sem acessar as chaves de criptografia do armazenamento de dados, mantidas no KMS interno do Google.

6. Leitura adicional

Acesse estes recursos para saber mais:

Whitepapers:

Outra documentação: