Quando ativa o Cloud Key Management Service (Cloud KMS) com o Cloud External Key Manager (Cloud EKM), pode usar chaves que gere com um parceiro de gestão de chaves externo para ajudar a proteger os dados no Google Cloud. Este documento descreve as arquiteturas para Google Cloud clientes que querem implementar um serviço de gestor de chaves externo (EKM) de elevada disponibilidade com o Cloud KMS e o Cloud EKM.
A utilização do EKM na nuvem com o seu serviço EKM envolve uma compensação de risco explícita entre a fiabilidade da carga de trabalho na nuvem e os controlos de proteção de dados. A encriptação de dados em repouso na nuvem com chaves de encriptação fora da nuvem adiciona novos riscos de falha que podem resultar na inacessibilidade dos dados dos serviços. Google Cloud Para resolver estes riscos, tem de incorporar a elevada disponibilidade e a tolerância a falhas na arquitetura do EKM da nuvem.
Vista geral
O EKM do Google Cloud permite-lhe usar material de chaves que permanece fora do Google Cloud para controlar o acesso aos seus dados armazenados em serviços suportados Google Cloud. Google Cloud As chaves do Cloud EKM são chaves de encriptação geridas pelo cliente (CMEKs).
O Cloud EKM permite-lhe criar e gerir recursos de chaves do Cloud KMS
usando os níveis de proteção EXTERNAL e EXTERNAL_VPC. Quando ativa o
EKM na nuvem, cada pedido de operação criptográfica resulta numa
operação criptográfica na chave externa. O sucesso da operação de pedido inicial depende criticamente do resultado da operação criptográfica na chave externa.
O Cloud KMS pede operações em chaves externas através de uma API de fins especiais que se integra com o seu sistema de gestão de chaves externas. Este documento refere-se a um serviço que fornece esta API como um serviço EKM.
Se um serviço EKM ficar indisponível, as leituras e as escritas dos planos de dados para os serviços Google Cloud integrados podem falhar. Estas falhas são apresentadas de forma semelhante às falhas quando a chave do Cloud KMS dependente se encontra num estado inutilizável, por exemplo, quando está desativada. A mensagem de erro descreve a origem do erro e um curso de ação. Além disso, os registos de auditoria de acesso aos dados do Cloud KMS incluem um registo destas mensagens de erro juntamente com tipos de erros descritivos. Para mais informações, consulte a referência de erros do EKM na nuvem.
Práticas recomendadas para arquiteturas de EKM na nuvem
O livro Site Reliability Engineering da Google descreve as práticas recomendadas para ajudar a orientar o desenvolvimento e a manutenção de sistemas fiáveis. Esta secção descreve algumas destas práticas no contexto da forma como o seu serviço de GCE se integra com o Google Cloud. As seguintes práticas recomendadas aplicam-se às arquiteturas de referência do EKM na nuvem:
- Configure uma conetividade de rede fiável e de baixa latência
- Ative a alta disponibilidade
- Detete e mitigue falhas rapidamente
Configure uma conetividade de rede fiável e de baixa latência
O Cloud KMS liga-se aos serviços EKM através de uma rede da nuvem virtual privada (VPC) ou da Internet. As soluções de VPC usam frequentemente a conetividade híbrida para alojar o serviço EKM num centro de dados no local. A ligação entreGoogle Cloud e o centro de dados tem de ser rápida e fiável. Quando usa a Internet, precisa de acessibilidade estável e ininterrupta, bem como de uma resolução de DNS rápida e fiável. Do ponto de vista do Google Cloud, qualquer interrupção pode resultar na indisponibilidade do serviço EKM e na potencial incapacidade de aceder a dados protegidos pelo EKM.
Quando o plano de dados de um Google Cloud serviço comunica com o serviço EKM, cada chamada associada ao serviço EKM tem um período de limite de tempo definido (150 milissegundos). O limite de tempo é medido a partir do serviço Cloud KMS na Google Cloud localização da chave do Cloud KMS. Se a localização for uma multirregião, o tempo limite começa na região onde o Cloud KMS recebe o pedido, que é normalmente onde ocorreu a operação no recurso de dados protegido por CMEK.Google Cloud Este limite de tempo é adequado para permitir que um serviço EKM processe pedidos numa Google Cloud região próxima da origem dos pedidos.
O limite de tempo ajuda a evitar falhas em cascata nos serviços a jusante que dependem da chave externa. Os problemas de latência final que normalmente podem causar uma má experiência do utilizador em aplicações de nível superior podem manifestar-se como acessos falhados à chave externa, o que resulta na falha da operação lógica de nível superior.
Para minimizar a latência e criar redes fiáveis, considere o seguinte:
- Minimize a latência da comunicação de ida e volta com o Cloud KMS: configure o serviço EKM para servir pedidos o mais próximo possível das Google Cloud localizações que correspondem às chaves do Cloud KMS configuradas para usar o serviço EKM. Para mais informações, consulte as práticas recomendadas para a seleção de regiões do Compute Engine e as regiões e zonas.
- Use o Cloud Interconnect sempre que possível: o Cloud Interconnect cria uma ligação de baixa latência e elevada disponibilidade entre Google Cloud e o seu centro de dados através de uma rede VPC e ajuda a remover as dependências da Internet.
- Implemente Google Cloud soluções de rede na região mais próxima do serviço EKM, quando necessário: idealmente, as chaves do Cloud KMS são armazenadas na região mais próxima do serviço EKM. Se existir 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 soluções de Google Cloud rede, como a Cloud VPN, na região mais próxima do serviço EKM. Esta opção ajuda a garantir que o tráfego de rede usa a infraestrutura da Google sempre que possível, o que reduz a dependência da Internet.
- Use redes de nível Premium quando o tráfego de EKM transitar pela Internet: O nível Premium encaminha o tráfego através da Internet usando a infraestrutura da Google sempre que possível para melhorar a fiabilidade e reduzir a latência.
Ative a alta disponibilidade
A existência de um ponto único de falha no serviço EKM reduz a disponibilidade de recursos dependentes à do ponto único de falha. Google Cloud Estes pontos de falha podem existir 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:
- Implemente réplicas em domínios de falhas independentes: implemente, pelo menos, duas réplicas do serviço EKM. Se estiver a usar localizações Google Cloud
multirregionais, implemente a GCE em, pelo menos, duas localizações geográficas separadas com, pelo menos, duas réplicas cada. Certifique-se de que cada réplica não representa apenas um plano de dados replicado do serviço EKM, minimizando e reforçando os vetores de falhas entre réplicas. Considere os seguintes exemplos:
- Configure as alterações de produção, incluindo as implementações binárias e de configuração do servidor, para modificar apenas uma réplica de cada vez. Verifique se todas as alterações são realizadas sob supervisão, com reversões testadas facilmente disponíveis.
- Compreenda e minimize os modos de falha de várias réplicas da infraestrutura subjacente. Por exemplo, certifique-se de que as réplicas dependem de fontes de alimentação independentes e redundantes.
Torne as réplicas resilientes a falhas de máquinas únicas: verifique se cada réplica do serviço consiste em, pelo menos, três aparelhos, máquinas ou anfitriões de VMs. Esta configuração permite que o sistema sirva tráfego enquanto uma máquina está indisponível para atualizações ou durante uma indisponibilidade inesperada (aprovisionamento N+2).
Limite a área afetada de problemas do plano de controlo: configure o plano de controlo (por exemplo, a criação ou a eliminação de chaves) do serviço EKM para replicar a configuração ou os dados entre réplicas. Geralmente, estas operações são mais complexas porque requerem sincronização e afetam todas as réplicas. Os problemas podem propagar-se rapidamente e afetar todo o sistema. Seguem-se algumas estratégias para reduzir o impacto dos problemas:
- Controlar a velocidade de propagação: por predefinição, certifique-se de que as alterações são propagadas o mais lentamente possível, de acordo com a usabilidade e a segurança. Configure exceções quando necessário, por exemplo, quando permite o acesso a uma chave para propagar rapidamente para permitir que um utilizador desfaça um erro.
- Divida o sistema em fragmentos: se muitos utilizadores partilharem o EKM, divida-os em fragmentos lógicos que sejam completamente independentes, para que os problemas acionados por um utilizador num fragmento não possam afetar os utilizadores noutro.
- Pré-visualize o efeito das alterações: se possível, permita que os utilizadores vejam o efeito das alterações antes de as aplicar. Por exemplo, ao modificar uma política de acesso à chave, o EKM pode confirmar o número de pedidos recentes que teriam sido rejeitados ao abrigo da nova política.
- Implemente a análise prévia de dados: envie primeiro dados apenas para um pequeno subconjunto do sistema. Se o subconjunto permanecer em bom estado, envie os dados para o resto do sistema.
Implemente verificações de funcionamento holísticas: crie verificações de funcionamento que meçam se o sistema completo está a funcionar. Por exemplo, as verificações de estado que apenas validam a conetividade de rede não são úteis para responder a muitos problemas ao nível da aplicação. Idealmente, a verificação de funcionamento reflete de perto as dependências do tráfego real.
Configure a comutação por falha entre réplicas: configure o equilíbrio de carga nos componentes do serviço EKM de forma que consuma as verificações de funcionamento e drene ativamente o tráfego das réplicas não íntegras e comute por falha em segurança para réplicas íntegras.
Inclua mecanismos de segurança para gerir a sobrecarga e evitar falhas em cascata: Os sistemas podem ficar sobrecarregados por vários motivos. Por exemplo, quando algumas réplicas ficam em mau estado de funcionamento, o tráfego redirecionado para as réplicas em bom estado de funcionamento pode sobrecarregá-las. Quando confrontado com mais pedidos do que consegue processar, o sistema deve tentar processar o que consegue de forma segura e rápida, ao mesmo tempo que rejeita o tráfego excessivo.
Garantir uma história de durabilidade robusta: os dados no Google Cloud que estão encriptados com uma chave externa no serviço EKM são irrecuperáveis sem a chave externa. Por conseguinte, a durabilidade das chaves é um dos requisitos de design centrais do serviço EKM. Configure o serviço EKM para fazer cópias de segurança seguras de material de chaves redundantes em várias localizações físicas. Configurar medidas de proteção adicionais, como cópias de segurança offline, para chaves de elevado valor. Certifique-se de que os seus mecanismos de eliminação permitem tempo para recuperação em casos de acidentes e erros.
Detete e mitigue falhas rapidamente
Por cada minuto em que o serviço EKM sofre uma indisponibilidade, os recursos Google Cloud dependentes 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 detetar e mitigar falhas rapidamente, considere o seguinte:
- Configure o serviço EKM para comunicar métricas que sinalizam incidentes que ameaçam a fiabilidade: configure métricas como taxas de erros de resposta e latências de resposta para detetar problemas rapidamente.
- Configure práticas operacionais para a notificação e a mitigação atempadas de incidentes: quantifique a eficácia das práticas operacionais acompanhando as métricas de tempo médio de deteção (MTTD) e tempo médio de recuperação (MTTR), e defina objetivos que são medidos por estas métricas. Com estas métricas, pode encontrar padrões e deficiências nos processos e sistemas atuais para poder responder rapidamente a incidentes.
Arquiteturas de referência para o Cloud EKM
As arquiteturas seguintes descrevem algumas formas de implementar o serviço EKM através de Google Cloud produtos de rede e balanceamento de carga.
Ligação direta através do Cloud VPN ou Cloud Interconnect
Recomendamos uma ligação direta entre a Google Cloud e o seu centro de dados no local quando estiver a executar aplicações de elevado débito no Google Cloud e o serviço EKM for executado num único centro de dados. O diagrama seguinte mostra esta arquitetura.
Nesta arquitetura, o Cloud EKM acede ao serviço EKM localizado num centro de dados no local através da conetividade híbrida na região sem qualquer equilíbrio de carga intermédio no Google Cloud.
Quando possível, implemente a ligação do serviço EKM ao EKM na nuvem através da configuração de disponibilidade de 99,9% para aplicações de região única. A configuração de disponibilidade de 99,99% requer a utilização do Cloud Interconnect em várias Google Cloud regiões, o que pode não satisfazer as suas necessidades se a sua empresa exigir isolamento regional. Se a ligação ao centro de dados nas instalações usar a Internet, use a VPN de alta disponibilidade em vez da Interligação de nuvem.
A principal vantagem desta arquitetura é que não existem saltos intermédios, o que reduz a latência e os potenciais gargalos. Google CloudSe quiser configurar uma ligação direta quando o seu serviço de GCE estiver alojado em vários centros de dados, tem de configurar equilibradores de carga em todos os centros de dados que usam o mesmo endereço IP (anycast). Se usar esta configuração, o equilíbrio de carga e a comutação por falha entre centros de dados estão limitados apenas à disponibilidade de rotas.
Se configurar uma rede VPC, as chaves externas acedidas através da rede VPC têm de usar uma localização regional no Cloud KMS. As chaves não podem usar uma localização multirregional. Para mais informações, consulte o artigo Gestores de chaves externos e regiões.
Equilibrado de carga a partir da Internet em Google Cloud
Recomendamos a utilização de um equilibrador de carga com uma ligação à Internet quando precisar de chaves do Cloud KMS multirregionais. Google Cloud O diagrama seguinte mostra esta arquitetura.
Nesta arquitetura, o EKM tem réplicas em dois sites no local. Cada servidor de back-end é representado no Google Cloud usando um grupo de pontos finais de rede (NEG) de conetividade híbrida. A implementação usa um equilibrador 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 é proveniente da Internet.
Cada NEG de conetividade híbrida pode conter vários endereços IP, o que permite que o balanceador de carga de rede de proxy externo equilibre o tráfego diretamente para instâncias do serviço EKM. Não é necessário um equilibrador de carga adicional no centro de dados nas instalações.
O Network Load Balancer de proxy externo não está associado a uma região específica. Pode direcionar o tráfego de entrada para a região saudável mais próxima, o que o torna adequado para chaves do Cloud KMS multirregionais. No entanto, o balanceador de carga não permite a configuração de back-ends principais e de alternativa. O tráfego é distribuído uniformemente por vários back-ends numa região.
Equilibrado de carga numa rede VPC em Google Cloud
Recomendamos a utilização de um equilibrador de carga Google Cloud com uma rede VPC para a maioria dos serviços de GCE onde implementa o seu GCE. O diagrama seguinte mostra esta arquitetura.
Nesta arquitetura, o EKM da nuvem acede ao serviço EKM replicado entre dois centros de dados no local através da conetividade híbrida com camadas de balanceamento de carga intermédio na Google Cloud região. Se a ligação ao centro de dados nas instalações usar a Internet, pode usar a VPN de HA em vez do Cloud Interconnect.
O balanceador de carga de encaminhamento interno fornece um único endereço IP que os recursos podem usar para enviar tráfego através de redes virtuais. O balanceador de carga muda para o centro de dados de cópia de segurança com base no funcionamento dos back-ends.
O grupo de instâncias de VM é necessário para encaminhar o tráfego, porque o equilibrador de carga interno não pode encaminhar o tráfego diretamente para back-ends no local. Pode implementar proxies de balanceamento de carga para executar imagens do Docker do Nginx a partir do Cloud Marketplace em grupos de instâncias. Pode usar o Nginx como um equilibrador de carga TCP.
Uma vez que esta abordagem usa balanceadores de carga no Google Cloud, não precisa de um balanceador de carga nas instalações. Os balanceadores de carga podem ligar-se diretamente a instâncias do serviço EKM e equilibrar a carga entre elas. Google Cloud A eliminação do equilibrador de carga no local resulta numa configuração mais simples, mas reduz a flexibilidade disponível no serviço EKM. Por exemplo, um balanceador de carga de camada 7 no local pode tentar novamente os pedidos automaticamente se uma instância do EKM devolver um erro.
Se configurar uma rede VPC, as chaves externas acedidas através da rede VPC têm de usar uma localização regional no Cloud KMS. As chaves não podem usar uma localização multirregional. Para mais informações, consulte o artigo Gestores de chaves externos e regiões.
Comparação de arquiteturas de referência
A tabela seguinte compara as opções de arquitetura de referência para o Cloud EKM. A tabela também inclui uma coluna para a arquitetura de EKM gerida pelo parceiro. Neste cenário, o parceiro é responsável pela implementação e gestão do GCE e fornece o GCE como um serviço aos clientes.
| Opção | Ligação direta | Balanceamento de carga a partir da Internet | Com balanceamento de carga numa rede VPC | EKM totalmente gerido fornecido pelo parceiro |
|---|---|---|---|---|
Internet ou rede da VPC |
VPC |
Internet |
VPC |
Internet |
Balanceador de carga em Google Cloud |
Não |
Sim |
Sim |
Não |
É necessário um balanceador de carga no local |
Sim |
Não |
Não |
Sim (gerido por parceiro) |
Suporta localizações multirregionais do Cloud KMS |
Não |
Sim |
Não |
Sim |
Recomendado para |
Aplicações de alto rendimento em que o serviço EKM é executado num único site. |
Quando são necessárias chaves do Cloud KMS multirregionais. |
A maioria dos serviços de GCE em que implementa o seu próprio GCE. |
Pode usar a GCE de um parceiro em vez de implementar a sua própria. |
O que se segue?
- Leia mais sobre a segurança do Cloud KMS.
- Crie uma ligação EKM através de uma rede VPC.
- Configure o Cloud EKM através da Internet.