Vista geral da segurança do Cloud Service Mesh

A segurança da Cloud Service Mesh ajuda a mitigar ameaças internas e reduzir o risco de uma violação de dados, garantindo que todas as comunicações entre cargas de trabalho são encriptadas, autenticadas mutuamente e autorizadas.

Tradicionalmente, a microsegmentação que usa regras baseadas em IP tem sido usada para mitigar riscos internos. No entanto, a adoção de contentores, serviços partilhados e ambientes de produção distribuídos em várias nuvens torna esta abordagem mais difícil de configurar e ainda mais difícil de manter.

Com a Cloud Service Mesh, pode configurar uma camada de segurança de rede sensível ao contexto do serviço e sensível ao contexto do pedido que é independente da segurança da rede subjacente. Por este motivo, o Cloud Service Mesh permite-lhe adotar uma postura de defesa em profundidade consistente com os princípios de segurança de confiança zero. Permite-lhe alcançar esta postura através de políticas declarativas e sem modificar o código de qualquer aplicação.

TLS mútuo

O Cloud Service Mesh usa o TLS mútuo (mTLS) para a autenticação de pares. A autenticação refere-se à identidade: quem é este serviço? Quem é este utilizador final? E posso confiar que é quem diz ser?

O mTLS permite que as cargas de trabalho validem as identidades umas das outras e se autentiquem entre si. Pode conhecer o TLS simples através da sua utilização no HTTPS para permitir que os navegadores confiem nos servidores Web e encriptem os dados trocados. Quando o TLS simples é usado, o cliente estabelece que o servidor é fidedigno validando o respetivo certificado. O mTLS é uma implementação do TLS em que o cliente e o servidor apresentam certificados entre si e verificam as identidades uns dos outros.

O mTLS é o meio através do qual o Cloud Service Mesh implementa a autenticação e a encriptação entre serviços.

No Cloud Service Mesh 1.6 e posterior, o mTLS automático está ativado por predefinição. Com o mTLS automático, um proxy sidecar do lado do cliente deteta automaticamente se o servidor tem um sidecar. O contentor auxiliar do lado do cliente envia mTLS para cargas de trabalho com contentores auxiliares e envia texto simples para cargas de trabalho sem contentores auxiliares. No entanto, os serviços aceitam tráfego de texto simples e mTLS. Para proteger a sua malha de serviços, recomendamos que migre os seus serviços para aceitarem apenas tráfego mTLS.

Para mais informações sobre a aplicação apenas do mTLS, consulte o artigo Cloud Service Mesh by example: mTLS.

Configuração do conjunto de cifras

A lista seguinte inclui os conjuntos de cifras predefinidos e em conformidade com a FIPS do Cloud Service Mesh:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Para uma segurança melhorada, a versão mínima do TLS do lado do servidor suportada pelas cargas de trabalho do Cloud Service Mesh é 1.2, que suporta a personalização de conjuntos de cifras. Tenha em atenção que o Cloud Service Mesh também suporta o TLS v1.3, que codifica os conjuntos de cifras e não suporta a respetiva alteração.

Para mais informações sobre conjuntos de cifras, consulte a configuração TLS comum do Envoy e a autenticação TLS mútua do Istio.

Vantagens de segurança

O Cloud Service Mesh oferece as seguintes vantagens de segurança:

  • Mitiga o risco de ataques de repetição ou roubo de identidade que usam credenciais roubadas. O Cloud Service Mesh baseia-se em certificados mTLS para autenticar pares, em vez de tokens de portador, como tokens da Web JSON (JWT). Como os certificados mTLS estão associados ao canal TLS, não é possível que uma entidade no seu ambiente de produção roube a identidade de outra simplesmente reproduzindo o token de autenticação sem acesso às chaves privadas.

  • Garante a encriptação em trânsito. A utilização do mTLS para autenticação também garante que todas as comunicações TCP são encriptadas em trânsito.

  • Garante que apenas os clientes autorizados podem aceder a um serviço com dados confidenciais. Apenas os clientes autorizados podem aceder a um serviço com dados confidenciais, independentemente da localização de rede do cliente e das credenciais ao nível da aplicação. Pode especificar que apenas os clientes com identidades de serviço autorizadas ou em espaços de nomes Kubernetes autorizados podem aceder a um serviço. Também pode usar políticas de acesso baseadas em IP para conceder acesso a clientes implementados fora do ambiente do GKE Enterprise.

  • Mitiga o risco de violação de dados do utilizador na sua rede de produção. Pode garantir que os intervenientes internos só podem aceder a dados confidenciais através de clientes autorizados. Além disso, pode garantir que determinados clientes só podem obter acesso aos dados do utilizador se puderem apresentar um token de utilizador válido e de curta duração. Isto mitiga o risco de que a comprometimento de uma única credencial de cliente conceda a um atacante acesso a todos os dados do utilizador.

  • Identifica os clientes que acederam a um serviço com dados confidenciais. O registo de acesso da malha de serviços na nuvem captura a identidade mTLS do cliente, além do endereço IP. Deste modo, pode compreender facilmente que carga de trabalho acedeu a um serviço, mesmo que a carga de trabalho seja efémera e implementada dinamicamente, e esteja num cluster ou numa rede da nuvem virtual privada (VPC) diferente.

Funcionalidades

Esta secção descreve as funcionalidades que o Cloud Service Mesh oferece para concretizar as suas vantagens de segurança.

Rotação automática de chaves e certificados

A utilização do mTLS baseado em identidades de serviço permite encriptar todas as comunicações TCP e fornece uma credencial não repetível mais segura para o controlo de acesso. Um dos principais desafios da utilização do mTLS em grande escala é a gestão das chaves e dos certificados para todas as cargas de trabalho de destino. A malha de serviços na nuvem encarrega-se da rotação das chaves e dos certificados mTLS para as cargas de trabalho do GKE Enterprise sem interromper as comunicações. É possível configurar intervalos de atualização de certificados mais pequenos para reduzir o risco.

Autoridade de certificação do Cloud Service Mesh

O Cloud Service Mesh inclui uma autoridade de certificação privada multirregional gerida, a autoridade de certificação do Cloud Service Mesh, para emitir certificados para mTLS. A autoridade de certificação do Cloud Service Mesh é um serviço altamente fiável e escalável que está otimizado para cargas de trabalho dimensionadas dinamicamente numa plataforma de nuvem. Com a autoridade de certificação do Cloud Service Mesh, a Google gere a segurança e a disponibilidade do back-end da AC. A autoridade de certificação do Cloud Service Mesh permite-lhe confiar numa única raiz de confiança em todos os clusters do GKE Enterprise. Quando usa a autoridade de certificação do Cloud Service Mesh, pode confiar nos conjuntos do Workload Identity para fornecer isolamento detalhado. Por predefinição, a autenticação falha se o cliente e o servidor não estiverem no mesmo conjunto do Workload Identity.

Os certificados da autoridade de certificação do Cloud Service Mesh incluem os seguintes dados acerca dos serviços da sua aplicação:

  • O Google Cloud ID do projeto
  • O espaço de nomes do GKE
  • O nome da conta de serviço do GKE

Certificate Authority Service

Como alternativa à autoridade de certificação do Cloud Service Mesh, pode configurar o Cloud Service Mesh para usar o Certificate Authority Service, que é adequado para os seguintes exemplos de utilização:

  • Se precisar de diferentes autoridades de certificação para assinar certificados de carga de trabalho em diferentes clusters.
  • Se quiser usar certificados do plug-in da AC personalizada do Istiod.
  • Se precisar de fazer uma cópia de segurança das suas chaves de assinatura num HSM gerido.
  • Se estiver num setor altamente regulamentado e estiver sujeito a conformidade.
  • Se quiser encadear a sua AC do Cloud Service Mesh a um certificado de raiz empresarial personalizado para assinar certificados de carga de trabalho.

O custo da autoridade de certificação do Cloud Service Mesh está incluído nos preços do Cloud Service Mesh. O serviço de CA não está incluído no preço base do Cloud Service Mesh e é cobrado separadamente. Além disso, o serviço de AC inclui um SLA explícito, mas a autoridade de certificação da Cloud Service Mesh não.

Para esta integração, todas as cargas de trabalho na Cloud Service Mesh recebem duas funções do IAM:

Políticas de controlo de acesso (firewall) com reconhecimento de identidade

Com a Cloud Service Mesh, pode configurar políticas de segurança de rede baseadas na identidade mTLS em vez do endereço IP do par. Isto permite-lhe criar políticas independentes da localização de rede da carga de trabalho. Atualmente, apenas são suportadas comunicações entre clusters no mesmo Google Cloud projeto.

Peça políticas de controlo de acesso (firewall) sensíveis a reivindicações

Além da identidade mTLS, pode conceder acesso com base nas reivindicações de pedidos no cabeçalho JWT de pedidos HTTP ou gRPC. O Cloud Service Mesh permite-lhe afirmar que um JWT é assinado por uma entidade fidedigna. Isto significa que pode configurar políticas que permitem o acesso de determinados clientes apenas se existir uma reivindicação de pedido ou se esta corresponder a um valor especificado.

Autenticação de utilizadores com o Identity-Aware Proxy

Autentique os utilizadores que estão a aceder a qualquer serviço exposto num gateway de entrada do Cloud Service Mesh através do Identity-Aware Proxy (IAP). O IAP pode autenticar utilizadores que estão a iniciar sessão a partir de um navegador, integrar-se com fornecedores de identidade personalizados e emitir um token JWT de curta duração ou um RCToken que pode ser usado para conceder acesso no gateway de entrada ou num serviço a jusante (através de um side-car). Para mais informações, consulte o artigo Integrar a IAP com a Cloud Service Mesh.

Autenticação do utilizador com o seu fornecedor de identidade existente

Pode integrar o seu fornecedor de identidade existente com o Cloud Service Mesh para fornecer autenticação de utilizador final baseada no navegador e controlo de acesso às suas cargas de trabalho implementadas. Para mais informações, consulte o artigo Configurar a autenticação de utilizadores da malha de serviços na nuvem.

Registo e monitorização de acesso

O Cloud Service Mesh garante que os registos de acesso e as métricas estão disponíveis no Google Cloud Observability e fornece um painel de controlo integrado para compreender os padrões de acesso de um serviço ou uma carga de trabalho com base nestes dados. Também pode optar por configurar um destino privado. A Cloud Service Mesh permite-lhe reduzir o ruído nos registos de acesso registando apenas os acessos bem-sucedidos uma vez numa janela de tempo configurável. Os pedidos que são recusados por uma política de segurança ou resultam num erro são sempre registados. Isto permite-lhe reduzir significativamente os custos associados ao carregamento, armazenamento e processamento de registos, sem perder sinais de segurança importantes.

Em conformidade com a FIPS

Todos os componentes do plano de controlo no cluster e os proxies na arquitetura x86 usam módulos de encriptação validados pela FIPS 140-2.

Limitações

Atualmente, a segurança do Cloud Service Mesh tem a seguinte limitação:

  • A autenticação de utilizadores que usa o IAP requer que um serviço seja publicado na Internet. A IAP e a Cloud Service Mesh permitem-lhe configurar políticas que podem restringir o acesso a utilizadores e clientes autorizados num intervalo de IPs permitido. Se optar por expor o serviço apenas a clientes na mesma rede, tem de configurar um motor de políticas personalizado para a autenticação de utilizadores e a emissão de tokens.

O que se segue?