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 os dados em Google Cloud. Este documento descreve arquiteturas para Google Cloud clientes que querem implantar um serviço de gerenciamento de chaves externas (EKM) com alta disponibilidade com o Cloud KMS e o Cloud EKM.
O uso do Cloud EKM com seu serviço de EKM envolve uma compensação de risco explícita 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 aumenta os riscos de falha, o que pode resultar na perda de acesso aos dados dos serviços Google Cloud . Para lidar com esses riscos, é necessário incorporar alta disponibilidade e tolerância a falhas à arquitetura do EKM do Cloud.
Visão geral
O Cloud EKM permite usar material de chave
que permanece fora do Google Cloud para controlar o acesso aos dados
armazenados em serviços
Google Cloudcom suporte. As chaves EKM do Cloud são chaves de criptografia gerenciadas pelo cliente (CMEKs).
O Cloud EKM permite criar e gerenciar recursos de chave 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 criticamente 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 de EKM ficar indisponível, as leituras e gravações dos planos de dados para serviços integrados Google Cloud poderão falhar. Essas falhas aparecem de forma semelhante às falhas quando a chave dependente do Cloud KMS está em um estado inutilizável, por exemplo, quando ela é desativada. A mensagem de erro descreve a origem do erro e uma forma 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 erro descritivos. Para mais informações, consulte Referência de erros do Cloud EKM.
Práticas recomendadas para arquiteturas de EKM do Cloud
O livro de Engenharia de confiabilidade de sites do Google descreve as práticas recomendadas para ajudar a orientar o desenvolvimento e a manutenção de sistemas confiáveis. Esta seção descreve algumas dessas práticas no contexto de como o serviço de EKM se integra ao Google Cloud. As práticas recomendadas a seguir se aplicam às arquiteturas de referência do EKM do Cloud:
- 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 de EKM usando uma rede de nuvem privada virtual (VPC) ou a Internet. As soluções da VPC geralmente usam a conexão 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 de Google Cloud, qualquer interrupção pode resultar na indisponibilidade do serviço do EKM e na possível incapacidade de acessar dados protegidos por EKM.
Quando o plano de dados de um Google Cloud serviço 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 a partir do serviço do Cloud KMS no Google Cloud local da chave do Cloud KMS. Se o localGoogle Cloud for multirregional, o tempo limite vai começar na região em que o Cloud KMS recebe a solicitação, que normalmente é onde a operação no recurso de dados protegido por CMEK ocorreu. Esse tempo limite é adequado para permitir que um serviço de EKM processe solicitações em uma região Google Cloud próxima de onde as solicitações são originadas.
O tempo limite ajuda a evitar falhas em cascata em serviços dependentes da chave externa. Problemas de latência de cauda que normalmente causam uma experiência do usuário ruim 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:
- Minimize a latência da comunicação de ida e volta com o Cloud KMS:configure o serviço do EKM para atender às solicitações o mais próximo possível do ponto de vista geográfico aos locais Google Cloud que correspondem às chaves do Cloud KMS configuradas para usar o serviço do EKM. Saiba mais em 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 altamente disponível e de baixa latência entre Google Cloud e seu data center usando uma rede VPC e ajuda a remover dependências da Internet.
- Implante Google Cloud soluções de rede na região mais próxima ao serviço EKM, quando necessário:o ideal é que as chaves do Cloud KMS sejam armazenadas na região mais próxima ao serviço EKM. Se houver uma Google Cloud região mais próxima do serviço EKM do que a região que contém as chaves do Cloud KMS, use Google Cloud soluções de rede, como a VPN do Cloud, 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 de nível Premium quando o tráfego do EKM transitar 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.
Ativar alta disponibilidade
A existência de um único ponto de falha no serviço EKM reduz a disponibilidade de recursos Google Cloud dependentes para o único ponto de falha. Esses pontos de falha podem estar em dependências críticas do serviço EKM, bem como na infraestrutura de computação e de rede subjacente.
Para ativar a alta disponibilidade, considere o seguinte:
- Implantar 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. Para garantir que cada réplica não
represente apenas um plano de dados replicado do serviço EKM, minimize e
reforce os vetores de falha entre réplicas. Confira os exemplos a seguir:
- Configure as mudanças de produção, incluindo o binário do servidor e os envios de configuração, para modificar apenas uma réplica por vez. Verifique se todas as mudanças são realizadas sob supervisão, com rollbacks testados disponíveis.
- Entenda e minimize os modos de falha de replicação cruzada da infraestrutura subjacente. Por exemplo, verifique se as réplicas dependem de feeds de energia redundantes e independentes.
Tornar as réplicas resilientes a falhas de máquinas individuais: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 ofereça tráfego enquanto uma máquina está inativa para atualizações ou durante uma interrupção inesperada (provisionamento N+2).
Limitar 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 de EKM para replicar a configuração ou os dados nas 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 para a usabilidade e a segurança. Configure exceções quando necessário, por exemplo, ao permitir que o acesso a uma chave seja propagado rapidamente para que um usuário desfaça um erro.
- Dividir o sistema em fragmentos:se muitos usuários compartilharem o EKM, divida-os em fragmentos lógicos que sejam completamente independentes, para que os problemas acionados por um usuário em um fragmento não afetem 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.
- Implementar a verificação de dados:primeiro envie dados apenas para um pequeno subconjunto do sistema. Se o subconjunto permanecer saudável, envie os dados para o restante do sistema.
Implementar verificações de integridade holísticas:crie verificações de integridade que avaliem 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 reflita de perto as dependências do tráfego real.
Configurar failover nas réplicas:configure o balanceamento de carga nos componentes do serviço do EKM para que ele consuma as verificações de integridade e drene ativamente o tráfego das réplicas não íntegras, fazendo failover para as réplicas íntegras com segurança.
Incluir 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 se tornam não íntegras, o tráfego redirecionado para as réplicas íntegras pode sobrecarregá-las. Quando o sistema recebe mais solicitações do que pode atender, ele tenta atender o que for possível com segurança e rapidez, rejeitando o excesso de tráfego.
Garantir uma história de durabilidade robusta:os dados em Google Cloud que são criptografados com uma chave externa no serviço do EKM não podem ser recuperados sem a chave externa. Portanto, a durabilidade da chave é um dos requisitos de design centrais do serviço de EKM. Configure o serviço EKM para fazer backup seguro de cópias redundantes de material de chave em vários locais físicos. Configure outras medidas de proteção, como backups off-line, para chaves de alto valor. Garanta que seus mecanismos de exclusão permitam tempo para recuperação em casos de acidentes e bugs.
Detectar e mitigar falhas rapidamente
A cada minuto que o serviço do EKM sofre uma interrupção, os recursos Google Clouddependentes podem ficar inacessíveis, o que pode aumentar ainda mais a probabilidade de uma falha em cascata de outros componentes dependentes da sua infraestrutura.
Para detectar e mitigar falhas rapidamente, considere o seguinte:
- Configure o serviço EKM para informar métricas que sinalizam incidentes que ameaçam a confiabilidade:configure métricas, como taxas de erro de resposta e latências de resposta, para detectar problemas rapidamente.
- Configurar práticas operacionais para notificação e mitigação de incidentes em tempo hábil:quantifique a eficácia das práticas operacionais rastreando as métricas de tempo médio de detecção (MTTD) e tempo médio de restauração (MTTR) e defina objetivos que sejam medidos por essas métricas. Usando 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 Google Cloud produtos de rede e balanceamento de carga.
Conexão direta por meio do Cloud VPN ou do Cloud Interconnect
Uma conexão direta entre Google Cloud e seu data center local é recomendada quando você executa aplicativos de alto rendimento em Google 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 por meio de conectividade híbrida na região, sem nenhum balanceamento de carga intermediário em Google Cloud.
Sempre que possível, implante a conexão de serviço do Cloud EKM a 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 a empresa exigir isolamento regional. Se a conexão com o data center local usar a Internet, use o VPN de alta disponibilidade em vez do Cloud Interconnect.
A principal vantagem dessa arquitetura é que não há etapas intermediárias 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 de EKM estiver hospedado em vários data centers, configure os 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 pela rede VPC 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.
Balanceamento de carga da Internet em Google Cloud
O uso de um balanceador de carga em Google Cloud com uma conexão de Internet é recomendado quando você precisa de chaves do Cloud KMS multirregionais. 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. A implantação 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 balance o tráfego diretamente para instâncias do serviço EKM. Não é necessário ter um balanceador de carga adicional 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
O uso de um balanceador de carga em Google Cloud com uma rede VPC é recomendado para a maioria dos serviços de EKM em que você implanta o EKM. O diagrama a seguir mostra essa arquitetura.
Nessa arquitetura, o Cloud EKM acessa o serviço EKM que é reproduzido entre dois data centers locais por meio de 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, use o VPN de alta disponibilidade em vez do Cloud Interconnect.
O balanceador de carga de rede de passagem interna oferece um único endereço IP que os recursos podem usar para enviar tráfego usando redes virtuais. O balanceador de carga falha e é transferido 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 encaminhar o tráfego diretamente para back-ends locais. É possível implantar balanceadores de carga de proxy para executar imagens do Nginx Docker do 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, você não precisa de um balanceador de carga local. Os balanceadores de carga Google Cloud podem se conectar diretamente a instâncias do serviço EKM e equilibrar 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 tentar novamente as solicitações automaticamente se uma instância do EKM retornar um erro.
Se você configurar uma rede VPC, as chaves externas acessadas pela rede VPC 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 da arquitetura de referência
A tabela a seguir compara as opções de arquitetura de referência para a EKM do Cloud. A tabela também inclui uma coluna para a arquitetura de EKM gerenciada por parceiros. Nesse cenário, o parceiro é responsável por implantar e gerenciar o EKM e oferecer o EKM como um serviço aos clientes.
| Opção | Conexão direta | Balanceamento de carga da Internet | Balanceamento de carga em uma rede VPC | EKM totalmente gerenciado fornecido pelo parceiro |
|---|---|---|---|---|
Rede VPC ou Internet |
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 (gerenciado 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.