Ao ativar o Cloud Key Management Service (Cloud KMS) com o Cloud External Key Manager (Cloud EKM), é possível usar chaves gerenciadas com um parceiro externo de gerenciamento de chaves para proteger dados em Google Cloud. Este documento descreve arquiteturas para clientes do Google Cloud que querem implantar um serviço de gerenciamento de chaves externas (EKM) altamente disponível com o Cloud KMS e o Cloud EKM.
Usar o Cloud EKM com seu serviço de EKM envolve uma troca explícita de riscos entre a confiabilidade da carga de trabalho na nuvem e os controles de proteção de dados. A criptografia de dados em repouso na nuvem com chaves de criptografia fora da nuvem adiciona novos riscos de falha que podem resultar na inacessibilidade dos dados dos serviços do Google Cloud . Para lidar com esses riscos, incorpore alta disponibilidade e tolerância a falhas na arquitetura do Cloud EKM.
Visão geral
Com o Cloud EKM, você usa material de chaves
que permanece fora do Google Cloud para controlar o acesso aos seus dados
armazenados em serviços Google Cloud
compatíveis. As chaves do Cloud EKM são chaves de criptografia gerenciadas pelo cliente (CMEKs).
Com o Cloud EKM, é possível criar e gerenciar recursos de chaves do Cloud KMS
usando os níveis de proteção EXTERNAL e EXTERNAL_VPC. Quando você ativa o
Cloud EKM, cada solicitação de operação criptográfica resulta em uma
operação criptográfica na chave externa. O sucesso da operação de solicitação inicial depende muito do resultado da operação criptográfica na chave externa.
O Cloud KMS solicita operações em chaves externas usando uma API de finalidade especial que se integra ao seu sistema de gerenciamento de chaves externas. Este documento se refere a um serviço que fornece essa API como um serviço de EKM.
Se um serviço do EKM ficar indisponível, as leituras e gravações dos planos de dados para serviços Google Cloud integrados poderão falhar. Essas falhas aparecem de maneira semelhante às falhas que ocorrem quando a chave dependente do Cloud KMS está em um estado inutilizável, por exemplo, quando ela está desativada. A mensagem de erro descreve a origem do erro e um curso de ação. Além disso, os registros de auditoria de acesso a dados do Cloud KMS incluem um registro dessas mensagens de erro com tipos de erros descritivos. Para mais informações, consulte a referência de erros do Cloud EKM.
Práticas recomendadas para arquiteturas do Cloud EKM
O livro de engenharia de confiabilidade do site do Google descreve as práticas recomendadas para orientar o desenvolvimento e a manutenção de sistemas confiáveis. Esta seção descreve algumas dessas práticas no contexto de como seu serviço EKM se integra ao Google Cloud. As práticas recomendadas a seguir se aplicam às arquiteturas de referência do Cloud EKM:
- Configurar conectividade de rede confiável e de baixa latência
- Ativar alta disponibilidade
- Detectar e mitigar falhas rapidamente
Configurar conectividade de rede confiável e de baixa latência
O Cloud KMS se conecta aos serviços do EKM usando uma rede de nuvem privada virtual (VPC) ou a Internet. As soluções de VPC costumam usar conectividade híbrida para hospedar o serviço EKM em um data center local. A conexão entre Google Cloud e o data center precisa ser rápida e confiável. Ao usar a Internet, você precisa de acessibilidade estável e ininterrupta e de resolução de DNS rápida e confiável. Do ponto de vista do Google Cloud, qualquer interrupção pode resultar na indisponibilidade do serviço EKM e na possível incapacidade de acessar dados protegidos pelo EKM.
Quando o plano de dados de um serviço Google Cloud se comunica com o serviço EKM, cada chamada vinculada ao serviço EKM tem um período de tempo limite definido (150 milissegundos). O tempo limite é medido pelo serviço do Cloud KMS no local Google Cloud da chave do Cloud KMS. Se o Google Cloud local for multirregional, o tempo limite vai começar na região em que o Cloud KMS recebe a solicitação, que geralmente é onde a operação no recurso de dados protegidos por CMEK ocorreu. Esse tempo limite é adequado para permitir que um serviço do EKM processe solicitações em uma regiãoGoogle Cloud próxima de onde elas são originadas.
O tempo limite ajuda a evitar falhas em cascata em serviços downstream que dependem da chave externa. Problemas de latência de cauda que normalmente causam uma experiência ruim do usuário em aplicativos de nível mais alto podem se manifestar como falhas de acesso à chave externa, resultando na falha da operação lógica de nível mais alto.
Para minimizar a latência e criar redes confiáveis, considere o seguinte:
- Minimizar a latência da comunicação de ida e volta com o Cloud KMS:configure o serviço EKM para atender solicitações o mais próximo possível das Google Cloud localidades que correspondem às chaves do Cloud KMS configuradas para usar o serviço EKM. Para mais informações, consulte Práticas recomendadas para a seleção de regiões do Compute Engine e Regiões e zonas.
- Use o Cloud Interconnect sempre que possível:o Cloud Interconnect cria uma conexão de alta disponibilidade e baixa latência entre Google Cloud e seu data center usando uma rede VPC e ajuda a remover dependências da Internet.
- Implante soluções de rede Google Cloud na região mais próxima do serviço EKM, quando necessário:o ideal é que as chaves do Cloud KMS sejam armazenadas na região mais próxima do serviço EKM. Se houver umaGoogle Cloud região mais próxima do serviço EKM do que a região que contém as chaves do Cloud KMS, use soluções de rede Google Cloud , como a Cloud VPN, na região mais próxima do serviço EKM. Essa opção ajuda a garantir que o tráfego de rede use a infraestrutura do Google sempre que possível, o que reduz a dependência da Internet.
- Use redes do nível Premium quando o tráfego da EKM passar pela Internet:o nível Premium roteia o tráfego pela Internet usando a infraestrutura do Google sempre que possível para melhorar a confiabilidade e reduzir a latência.
- Use um prazo adequado para o cliente:se você chamar a API Cloud KMS diretamente para chaves do Cloud EKM, configure um prazo de pelo menos 10 segundos para permitir tempo suficiente para que as operações de chaves externas sejam concluídas.
Ativar alta disponibilidade
A existência de um único ponto de falha no serviço EKM reduz a disponibilidade de recursos Google Cloud dependentes a esse ponto. Esses pontos de falha podem estar em dependências críticas do serviço EKM, bem como na infraestrutura de rede e computação subjacente.
Para ativar a alta disponibilidade, considere o seguinte:
- Implante réplicas em domínios de falha independentes:implante pelo menos duas réplicas do serviço EKM. Se você estiver usando locais Google Cloud
multirregionais, implante o EKM em pelo menos dois locais geográficos separados com
pelo menos duas réplicas cada. Verifique se cada réplica não representa apenas um plano de dados replicado do serviço EKM, minimizando e reforçando os vetores de falha entre réplicas. Confira estes exemplos:
- Configure as mudanças de produção, incluindo pushes de binários e configurações do servidor, para modificar apenas uma réplica por vez. Verifique se todas as mudanças são realizadas sob supervisão, com reversões testadas disponíveis.
- Entenda e minimize os modos de falha entre réplicas da infraestrutura subjacente. Por exemplo, verifique se as réplicas dependem de fontes de alimentação independentes e redundantes.
Tornar as réplicas resilientes a falhas de uma única máquina:verifique se cada réplica do serviço consiste em pelo menos três dispositivos, máquinas ou hosts de VM. Essa configuração permite que o sistema veicule tráfego enquanto uma máquina está inativa para atualizações ou durante uma interrupção inesperada (provisionamento N+2).
Limite a área afetada de problemas do plano de controle:configure o plano de controle (por exemplo, criação ou exclusão de chaves) do serviço EKM para replicar a configuração ou os dados em todas as réplicas. Essas operações geralmente são mais complexas porque exigem sincronização e afetam todas as réplicas. Os problemas podem se propagar rapidamente e afetar todo o sistema. Algumas estratégias para reduzir o impacto dos problemas incluem:
- Controle a velocidade de propagação:por padrão, garanta que as mudanças sejam propagadas o mais lentamente possível, sem prejudicar a usabilidade e a segurança. Configure exceções quando necessário, por exemplo, ao permitir o acesso a uma chave para propagação rápida e para que um usuário possa desfazer um erro.
- Divida o sistema em fragmentos:se muitos usuários compartilharem o EKM, divida-os em fragmentos lógicos completamente independentes. Assim, os problemas causados por um usuário em um fragmento não vão afetar os usuários em outro.
- Visualizar o efeito das mudanças:se possível, deixe que os usuários vejam o efeito das mudanças antes de aplicá-las. Por exemplo, ao modificar uma política de acesso à chave, o EKM pode confirmar o número de solicitações recentes que teriam sido rejeitadas de acordo com a nova política.
- Implemente o canarying de dados:primeiro, envie dados apenas para um pequeno subconjunto do sistema. Se o subconjunto permanecer íntegro, envie os dados para o restante do sistema.
Implemente verificações de integridade holísticas:crie verificações de integridade que medem se o sistema completo está funcionando. Por exemplo, as verificações de integridade que apenas validam a conectividade de rede não são úteis para responder a muitos problemas no nível do aplicativo. O ideal é que a verificação de integridade espelhe de perto as dependências do tráfego real.
Configurar failover entre réplicas:configure o balanceamento de carga nos componentes do serviço EKM para que ele consuma as verificações de integridade e drene ativamente o tráfego de réplicas não íntegras, fazendo failover com segurança para réplicas íntegras.
Inclua mecanismos de segurança para gerenciar a sobrecarga e evitar falhas em cascata:Os sistemas podem ficar sobrecarregados por vários motivos. Por exemplo, quando algumas réplicas ficam inativas, o tráfego redirecionado para as réplicas ativas pode sobrecarregá-las. Quando o sistema recebe mais solicitações do que pode atender, ele tenta atender o que pode com segurança e rapidez, rejeitando o tráfego excessivo.
Garanta uma história de durabilidade robusta:os dados em Google Cloud criptografados com uma chave externa no serviço EKM não podem ser recuperados sem a chave externa. Portanto, a durabilidade da chave é um dos requisitos de design centrais do serviço EKM. Configure o serviço EKM para fazer backup seguro de cópias redundantes de material de chaves em vários locais físicos. Configure medidas de proteção adicionais, como backups off-line, para chaves de alto valor. Verifique se os mecanismos de exclusão permitem tempo para recuperação em casos de acidentes e bugs.
Detectar e mitigar falhas rapidamente
A cada minuto de interrupção do serviço EKM, os recursos Google Clouddependentes podem ficar inacessíveis, o que aumenta ainda mais a probabilidade de uma falha em cascata de outros componentes dependentes da sua infraestrutura.
Para detectar e reduzir falhas rapidamente, considere o seguinte:
- Configure o serviço EKM para gerar relatórios de métricas que sinalizam incidentes que ameaçam a confiabilidade:configure métricas como taxas de erros de resposta e latências de resposta para detectar problemas rapidamente.
- Estabeleça práticas operacionais para notificação e mitigação oportunas de incidentes:quantifique a eficácia das práticas operacionais rastreando o tempo médio de detecção (MTTD) e o tempo médio de recuperação (MTTR) e defina objetivos medidos por essas métricas. Com essas métricas, é possível encontrar padrões e deficiências nos processos e sistemas atuais para responder rapidamente a incidentes.
Arquiteturas de referência para o Cloud EKM
As arquiteturas a seguir descrevem algumas maneiras de implantar o serviço EKM usando produtos de rede e balanceamento de carga doGoogle Cloud .
Conexão direta pelo Cloud VPN ou Cloud Interconnect
Uma conexão direta entre Google Cloud e seu data center local é recomendada quando você executa aplicativos de alta capacidade emGoogle Cloud e o serviço EKM é executado em um único data center. O diagrama a seguir mostra essa arquitetura.
Nessa arquitetura, o Cloud EKM acessa o serviço EKM localizado em um data center local usando a conectividade híbrida na região sem balanceamento de carga intermediário em Google Cloud.
Quando possível, implante a conexão de serviço do Cloud EKM para EKM usando a configuração de disponibilidade de 99,9% para aplicativos de região única. A configuração de disponibilidade de 99,99% exige o uso do Cloud Interconnect em várias regiões Google Cloud, o que pode não atender às suas necessidades se sua empresa exigir isolamento regional. Se a conexão com o data center local usar a Internet, use a VPN de alta disponibilidade em vez do Cloud Interconnect.
A principal vantagem dessa arquitetura é que não há saltos intermediários em Google Cloud, o que reduz a latência e possíveis gargalos. Se você quiser configurar uma conexão direta quando o serviço EKM estiver hospedado em vários data centers, configure balanceadores de carga em todos os data centers que usam o mesmo endereço IP (anycast). Se você usar essa configuração, o balanceamento de carga e o failover entre data centers serão limitados apenas à disponibilidade de rotas.
Se você configurar uma rede VPC, as chaves externas acessadas por ela precisarão usar um local regional no Cloud KMS. As chaves não podem usar um local multirregional. Para mais informações, consulte Administradores e regiões de chave externos.
Carga balanceada da Internet em Google Cloud
Recomendamos usar um balanceador de carga em Google Cloud com uma conexão de Internet quando você precisa de chaves multirregionais do Cloud KMS. O diagrama a seguir mostra essa arquitetura.
Nesta arquitetura, o EKM tem réplicas em dois sites locais. Cada back-end é representado em Google Cloud usando um grupo de endpoints de rede (NEG) de conectividade híbrida. O implante usa um balanceador de carga de rede de proxy externo para encaminhar o tráfego diretamente para uma das réplicas. Ao contrário das outras abordagens, que dependem da rede VPC, o balanceador de carga de rede de proxy externo tem um endereço IP externo, e o tráfego vem da Internet.
Cada NEG de conectividade híbrida pode conter vários endereços IP, o que permite que o balanceador de carga de rede de proxy externo faça o balanceamento de tráfego diretamente para instâncias do serviço EKM. Não é necessário ter outro balanceador de carga no data center local.
O balanceador de carga de rede de proxy externo não está vinculado a uma região específica. Ele pode direcionar o tráfego de entrada para a região íntegra mais próxima, o que o torna adequado para chaves multirregionais do Cloud KMS. No entanto, o balanceador de carga não permite a configuração de back-ends principais e de failover. O tráfego é distribuído de maneira uniforme entre vários back-ends em uma região.
Balanceamento de carga em uma rede VPC em Google Cloud
Recomendamos usar um balanceador de carga em Google Cloud com uma rede VPC para a maioria dos serviços do EKM em que você implanta o EKM. O diagrama a seguir mostra essa arquitetura.
Nessa arquitetura, o Cloud EKM acessa o serviço EKM replicado entre dois data centers locais por conectividade híbrida com camadas de balanceamento de carga intermediário na região Google Cloud . Se a conexão com o data center local usar a Internet, você poderá usar a VPN de alta disponibilidade em vez do Cloud Interconnect.
O balanceador de carga de rede de passagem interna fornece um único endereço IP que os recursos podem usar para enviar tráfego usando redes virtuais. O balanceador de carga faz failover para o data center de backup com base na integridade dos back-ends.
O grupo de instâncias de VM é necessário para fazer proxy do tráfego, porque o balanceador de carga interno não pode rotear o tráfego diretamente para back-ends locais. É possível implantar proxies de balanceador de carga para executar imagens do Docker do Nginx no Cloud Marketplace em grupos de instâncias. É possível usar o Nginx como um balanceador de carga TCP.
Como essa abordagem usa balanceadores de carga em Google Cloud, não é necessário um balanceador de carga local. Os balanceadores de carga Google Cloud podem se conectar diretamente às instâncias do serviço EKM e balancear a carga entre elas. A eliminação do balanceador de carga local resulta em uma configuração mais simples, mas reduz a flexibilidade disponível no serviço EKM. Por exemplo, um balanceador de carga L7 local pode repetir automaticamente as solicitações se uma instância do EKM retornar um erro.
Se você configurar uma rede VPC, as chaves externas acessadas por ela precisarão usar um local regional no Cloud KMS. As chaves não podem usar um local multirregional. Para mais informações, consulte Administradores e regiões de chave externos.
Comparação de arquiteturas de referência
A tabela a seguir compara as opções de arquitetura de referência para o Cloud EKM. A tabela também inclui uma coluna para arquitetura de EKM gerenciada por parceiros. Nesse cenário, o parceiro é responsável por implantar e gerenciar o EKM e fornece o EKM como um serviço aos clientes.
| Opção | Conexão direta | Carga balanceada da Internet | Balanceamento de carga em uma rede VPC | EKM totalmente gerenciado fornecido pelo parceiro |
|---|---|---|---|---|
Internet ou rede VPC |
VPC |
Internet |
VPC |
Internet |
Balanceador de carga em Google Cloud |
Não |
Sim |
Sim |
Não |
Balanceador de carga local obrigatório |
Sim |
Não |
Não |
Sim (gerenciada por um parceiro) |
Suporte a locais multirregionais do Cloud KMS |
Não |
Sim |
Não |
Sim |
Recomendado para |
Aplicativos de alta capacidade de processamento em que o serviço EKM é executado em um único site. |
Quando chaves multirregionais do Cloud KMS são necessárias. |
A maioria dos serviços de EKM em que você implanta seu próprio EKM. |
Você pode usar o EKM de um parceiro em vez de implantar o seu. |
A seguir
- Leia mais sobre a segurança do Cloud KMS.
- Crie uma conexão EKM em uma rede VPC.
- Configure o Cloud EKM pela Internet.