Vista geral da segurança do Cloud Service Mesh

A segurança da Cloud Service Mesh com APIs Istio 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 que é 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? 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, 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 sidecar do cliente envia mTLS para cargas de trabalho com sidecars e envia texto simples para cargas de trabalho sem sidecars. 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.

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. A malha de serviços na nuvem baseia-se em certificados mTLS para autenticar pares, em vez de tokens de portador, como símbolos da Web JSON (JWT). Uma vez que 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 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 da malha.

  • 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 Cloud Service Mesh captura a identidade mTLS do cliente, além do endereço IP. Deste modo, pode compreender 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 realizar 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 Cloud Service Mesh cuida da rotação das chaves e dos certificados mTLS para cargas de trabalho de malha 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 o 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 na 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. Quando usa a autoridade de certificação do Cloud Service Mesh, pode confiar nos conjuntos de identidades de carga de trabalho para fornecer isolamento detalhado. Por predefinição, a autenticação falha se o cliente e o servidor não estiverem no mesmo Workload Identity Pool.

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 serviço de autoridade de certificação, 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 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 custo do 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 com base 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. 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 corresponder a um valor especificado.

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

Autentica 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 a Cloud Service Mesh para fornecer autenticação de utilizadores finais 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.

Em conformidade com a FIPS

O componente do plano de dados usa módulos de encriptação validados pela FIPS 140-2.

Limitações

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?