Segurança do serviço

Este documento oferece uma vista geral da segurança dos serviços com o Cloud Service Mesh. Destina-se a utilizadores do Cloud Service Mesh que querem adicionar autenticação, encriptação e autorização às respetivas implementações. Este documento pressupõe que tem conhecimentos gerais sobre a malha de serviços na nuvem e sobre as aplicações gRPC sem proxy.

O Cloud Service Mesh permite-lhe proteger as comunicações de serviço para serviço na sua malha. Na malha, cada serviço tem uma identidade. As seguintes funcionalidades ajudam a suportar comunicações seguras:

  • Autenticação e encriptação que usam o Transport Layer Security (TLS) e o TLS mútuo (mTLS) para o Cloud Service Mesh com o Envoy e o Cloud Service Mesh com aplicações gRPC sem proxy. As políticas de TLS do cliente e as políticas de TLS do servidor controlam se os serviços têm de provar as respetivas identidades entre si e usar canais de comunicação encriptados.
  • Autorização, com base nas caraterísticas do cliente e do pedido. As políticas de autorização controlam se um serviço tem autorização para aceder a outro serviço e que ações são permitidas.

A utilização de certificados e chaves fornecidos por uma autoridade de certificação (AC) privada, o Certificate Authority Service da Google, facilita a manutenção da segurança do serviço. O serviço de AC fornece certificados de malha do GKE. A funcionalidade de certificados de malha do GKE e a Cloud Service Mesh permitem-lhe implementar automaticamente estes certificados e fazer com que as cargas de trabalho os usem. Modifica os seus pods para permitir que as cargas de trabalho recebam e usem credenciais mTLS. Atualmente, a segurança do serviço Cloud Service Mesh está disponível apenas para cargas de trabalho baseadas no GKE.

Nas arquiteturas modernas baseadas em microsserviços, os serviços mais pequenos e focados substituem as grandes aplicações monolíticas. As chamadas de serviço comunicam entre si através da rede. Estas chamadas, que eram chamadas em processamento em aplicações monolíticas, apresentam desafios de segurança, pelo que é melhor autenticá-las, encriptá-las e autorizá-las. Estes passos suportam o princípio de confiança zero, no qual se assume que todo o tráfego de rede está em risco, independentemente de o tráfego ter origem dentro ou fora da rede.

O padrão de design de malha de serviço separa qualquer complexidade relacionada com as comunicações de serviço para serviço da lógica empresarial. Em vez disso, o plano de dados processa esta complexidade. Além de reduzir a complexidade das aplicações, o padrão de design de malha de serviço permite padrões de segurança que, de outra forma, seriam difíceis de implementar e gerir.

Neste modelo, os sidecars do gRPC sem proxy ou do Envoy autenticam e encriptam comunicações de forma segura através da obtenção de informações de configuração do Cloud Service Mesh e certificados de um conjunto de serviços de AC.

Estas funcionalidades de segurança facilitam o processo de implementação do Cloud Service Mesh através do seguinte:

  • Aprovisionamento automático de chaves e certificados para todos os serviços na sua malha.
  • Rotação automática de chaves e certificados para oferecer segurança adicional.
  • Integração com o Google Kubernetes Engine (GKE) para usar todas as respetivas capacidades, como descritores de implementação e etiquetas.
  • Elevada disponibilidade dos serviços geridos pela Google, incluindo a malha de serviços na nuvem e os conjuntos de autoridades de certificação privadas geridas pelo serviço de AC.
  • Segurança associada à gestão de identidade e de acesso (IAM) da Google: autorização de serviços com base em contas de serviço Google autorizadas.
  • Interoperabilidade perfeita com as suas cargas de trabalho baseadas no Envoy e sem proxy. Por exemplo, um serviço pode estar atrás de um proxy Envoy, mas o cliente usa a segurança da rede de serviços sem proxy gRPC. Por outro lado, um serviço pode estar atrás da segurança da rede de serviços sem proxy gRPC, mas o cliente usa um proxy Envoy.

Comunicações seguras entre serviços

O Cloud Service Mesh oferece autorização, bem como segurança de serviço a serviço com encriptação e autenticação que usam o TLS. As políticas TLS do cliente e as políticas TLS do servidor permitem que os serviços façam o seguinte:

  • Afirmar e validar as respetivas identidades.
  • Encriptar sessões de comunicação através de TLS ou mTLS.

Numa malha de serviços, o plano de dados processa este tipo de segurança para que as aplicações não tenham de tomar disposições especiais para serem seguras.

As políticas de autorização permitem-lhe negar ou conceder acesso de acordo com as regras que definir.

Use o TLS para encriptação

Quando um serviço chama outro serviço através do protocolo HTTP, HTTP/2 ou gRPC, o tráfego que transita na rede está em texto simples. Este tráfego pode estar sujeito a ataques do tipo man-in-the-middle, em que um atacante interceta o tráfego e inspeciona ou manipula o respetivo conteúdo.

Para mitigar este potencial problema, pode usar HTTP, HTTP/2 ou gRPC através de TLS com a Cloud Service Mesh. Quando usa estes protocolos através do TLS, o tráfego entre o cliente e o servidor é encriptado através do TLS baseado no certificado do servidor. O tráfego já não está em texto simples, o que reduz a probabilidade de um atacante poder intercetar e inspecionar ou manipular o respetivo conteúdo.

Use TLS para autenticação

Quando um serviço chama outro serviço, considere as seguintes perguntas:

  • Como é que um cliente sabe que está a receber uma resposta do servidor correto e não de um impostor? Por exemplo, numa interação de pedido-resposta típica baseada em HTTP, o cliente não valida a identidade do servidor.

  • O que acontece se um atacante intercetar esse tráfego? Por exemplo, o tráfego HTTP não é encriptado, pelo que qualquer pessoa que receba o tráfego pode inspecionar o respetivo conteúdo. Isto é conhecido como um ataque de pessoa no meio.

Para mitigar estes problemas, pode usar HTTP, HTTP/2 e gRPC através de TLS. Nestas trocas entre um cliente e um servidor, o servidor tem de usar um certificado de servidor para provar a sua identidade ao cliente. Em seguida, os pedidos e as respostas são encriptados através de TLS.

Autenticação TLS mútua

Quando o Cloud Service Mesh configura a rede de aplicações para o cliente e o servidor, por exemplo, configurando um proxy Envoy do lado do cliente e outro proxy Envoy do lado do servidor, pode tirar partido de padrões de autenticação avançados, como a autenticação mútua.

Numa troca HTTP sobre TLS típica, que não se baseia na autenticação mútua, o servidor tem um certificado que usa para encriptar as comunicações entre o cliente e o servidor. O cliente pode validar a identidade do servidor verificando a assinatura que o servidor envia de volta durante a negociação de TLS. No entanto, o servidor não valida a identidade do cliente.

Quando a autenticação mútua está ativada, o cliente também tem um certificado. O cliente valida a identidade do servidor, conforme descrito no parágrafo anterior, e o servidor também pode validar a identidade do cliente. Os certificados do cliente e do servidor são usados para encriptar o canal de comunicação. Isto também permite ao servidor autorizar clientes com base na identidade do cliente validada.

Autenticação TLS mútua (mTLS) numa malha de serviços.
Autenticação TLS mútua (mTLS) numa malha de serviços (clique para aumentar)

Autorize chamadas de serviço

Pode optar por permitir ou recusar o acesso ao serviço através de políticas de autorização. Com a malha de serviços na nuvem, pode definir regras de permissão e negação para autorizar o acesso com base nos parâmetros do pedido. Pode basear estas regras em parâmetros da camada 3 e da camada 7, incluindo o ID do cliente, que é derivado do client-cert numa ligação mTLS, o endereço IP de origem, a correspondência de anfitriões, a correspondência de métodos e a correspondência de cabeçalhos. O diagrama seguinte mostra a autorização com proxies Envoy. O processo é semelhante com os clientes gRPC.

Autorização numa malha de serviços.
Autorização numa malha de serviços através do Envoy (clique para aumentar)

Restrinja o acesso através da autorização

Uma prática recomendada numa malha de serviços é seguir o princípio do menor privilégio. Pode aderir a este princípio restringindo o acesso ao serviço apenas aos autores de chamadas que dependem do serviço. Quando um autor da chamada tenta aceder a um serviço para o qual não tem autorização, a tentativa é rejeitada.

Com a malha de serviços na nuvem, pode configurar políticas de autorização que permitem que o seu plano de dados permita ou negue o acesso ao serviço com base nas regras que definir. Estas políticas são compostas por dois componentes:

  • Uma ação: permitir ou recusar
  • Uma lista de regras

Quando é enviado um pedido ou um RPC, o cliente do Cloud Service Mesh no serviço chamado determina se existe uma correspondência de regra. Se for encontrada uma correspondência, o pedido ou o RPC é permitido ou recusado. Pode definir uma regra para corresponder a atributos como os seguintes:

  • Quando o mTLS é usado, a conta de serviço do Kubernetes do serviço de chamada
  • O endereço IP (ou o intervalo de endereços) do serviço de chamadas
  • As portas do serviço de destino
  • Os atributos HTTP do pedido, incluindo nomes de anfitrião, métodos e cabeçalhos HTTP definidos pelo utilizador.

Nomenclatura segura

Como um mecanismo de segurança adicional, pode configurar a atribuição de nomes seguros com a Cloud Service Mesh. Isto permite-lhe definir uma lista de nomes permitidos ou identidades SPIFFE (Secure Production Identity Framework for Everyone) para um serviço específico ao qual um cliente está a tentar estabelecer ligação. Durante a troca de TLS, o back-end do serviço devolve um certificado X.509 ao cliente. Em seguida, o cliente inspeciona o certificado para confirmar se o certificado X.509 corresponde a um dos nomes ou identidades SPIFFE. Para mais informações sobre as identidades SPIFFE, consulte o artigo Secure Production Identity Framework for Everyone.

Proteja o tráfego num gateway

Para configurar as suas passarelas, pode usar a Cloud Service Mesh. Um gateway é um proxy Envoy autónomo que, normalmente, funciona como um dos seguintes:

  • Um gateway de entrada que processa o tráfego que está a entrar numa malha ou noutro domínio
  • Um gateway de saída que processa o tráfego que está a sair de uma malha ou de outro domínio
  • Um proxy reverso ou um proxy intermédio que distribui o tráfego de entrada entre um ou mais serviços

Os clientes que querem enviar tráfego para a malha ou para fora da malha enviam tráfego para o gateway. Em seguida, o gateway processa os pedidos de acordo com as regras que configurou com a Cloud Service Mesh. Por exemplo, pode aplicar que o tráfego que entra na sua malha (através do gateway de entrada) tem de ser encriptado através do TLS.

Componentes de segurança

A segurança do serviço Cloud Service Mesh suporta políticas TLS de cliente, políticas TLS de servidor e políticas de autorização. Cria estas políticas para que o Cloud Service Mesh possa configurar o seu plano de dados e ativar capacidades de segurança. Para criar ou atualizar estas políticas, não tem de fazer alterações às suas aplicações.

Encriptação e modos de autenticação suportados

Quando um serviço chama outro serviço, o primeiro passo para estabelecer comunicações seguras é que cada serviço prove a sua identidade ao outro serviço. O grau em que um serviço tem de comprovar a sua identidade baseia-se no modo TLS que configura.

Pode configurar os seguintes níveis de segurança:

  • Sem encriptação/não autenticado
  • TLS
  • TLS mútuo (mTLS)
  • Permissivo: mTLS ou não encriptado/não autenticado, consoante a forma como o cliente inicia a ligação

Certificados e autoridades de certificação

Os certificados e uma autoridade de certificação (AC) fidedigna fornecem a base para a confiança num sistema distribuído, como uma malha de serviços. Através de certificados, os serviços podem provar as respetivas identidades e validar as identidades apresentadas das seguintes formas:

  • Um serviço que quer comprovar a sua identidade a outro serviço apresenta o respetivo certificado ao outro serviço. Uma AC em que ambos os serviços confiam assina e emite criptograficamente este certificado.
  • O serviço que recebe este certificado pode verificar se o certificado foi emitido por uma AC fidedigna.

O Cloud Service Mesh não é uma autoridade de certificação. Para ativar as comunicações seguras, tem de configurar um mecanismo que faça o seguinte:

  • Aprovisiona identidades e certificados
  • Disponibiliza os certificados aos clientes do Cloud Service Mesh, como os proxies Envoy, que o Cloud Service Mesh configura

O Cloud Service Mesh suporta o serviço de AC da Google. Os guias de configuração do Envoy e do gRPC sem proxy incluem instruções para configurar esta opção (para detalhes, consulte O que fazer a seguir).

Arquitetura e recursos

O Cloud Service Mesh inclui o espaço de nomes da API Network Security, que consiste em três Google Cloud recursos da API que lhe permitem especificar as políticas de segurança que devem ser aplicadas ao seu plano de dados.

Dois Google Cloud recursos da API suportam a autenticação na malha: políticas TLS do cliente e políticas TLS do servidor. Um terceiro recurso, a política de autorização, suporta a autorização.

O espaço de nomes da API Network Services inclui o recurso de política de endpoint, que permite à Cloud Service Mesh fornecer configuração (TLS do servidor, TLS do cliente e políticas de autorização) aos endpoints. Os pontos finais são os clientes do Cloud Service Mesh que terminam uma comunicação de entrada de outro cliente do Cloud Service Mesh.

Política de TLS do cliente

Uma política de TLS do cliente permite-lhe especificar o modo TLS do lado do cliente e as informações do fornecedor de certificados a aplicar ao seu plano de dados. As políticas de TLS do cliente suportam a autenticação TLS e mTLS. As políticas de TLS do cliente têm de ser anexadas a um recurso de serviço de back-end global.

Quando configura o TLS, tem de fornecer um mecanismo através do qual o cliente valida o certificado que recebe do servidor durante a troca de TLS através do campo da API serverValidationCa. O cliente usa estas informações para obter um certificado de validação que pode usar para validar o certificado do servidor.

Quando configura o mTLS, também tem de fornecer um mecanismo através do qual o cliente obtém o respetivo certificado e chave privada através do campo da API clientCertificate. O cliente usa estas informações para apresentar um certificado ao servidor durante o handshake TLS.

Nesta versão, o Cloud Service Mesh suporta uma autoridade de certificação gerida, o CA Service. A configuração é simples: especifica o google_cloud_private_spiffe nome do plug-in quando configura o fornecedor de certificados. Isto faz com que os clientes xDS carreguem certificados e chaves a partir de uma localização estática. Como pré-requisitos, tem de configurar pools do serviço de AC e ativar certificados de malha no cluster do GKE.

Política de TLS do servidor

Uma política de TLS do servidor (recurso ServerTlsPolicy) permite-lhe especificar o modo TLS do lado do servidor e as informações do fornecedor de certificados a aplicar ao seu plano de dados. As políticas de TLS do servidor suportam TLS, mTLS e, apenas com o Envoy, autenticação Open_or_mTLS. Anexa políticas TLS do servidor a um recurso de política de ponto final.

Nomes alternativos de assunto

Quando configura o campo securitySettings de um serviço de back-end global, pode fornecer uma lista de nomes alternativos do assunto no campo subjectAltNames. Quando um cliente inicia um handshake TLS com um dos backends do serviço, o servidor apresenta o respetivo certificado X.509. O cliente inspeciona o campo subjectAltName do certificado. Se o campo contiver um dos valores especificados, a comunicação continua. Este mecanismo é descrito anteriormente em Nomenclatura segura.

Política de autorização

Uma política de autorização (recurso AuthorizationPolicy) especifica como um servidor autoriza pedidos ou RPCs recebidos. Pode ser configurado para permitir ou recusar um pedido ou um RPC recebido com base em vários parâmetros, como a identidade do cliente que enviou o pedido, o anfitrião, os cabeçalhos e outros atributos HTTP. Anexa políticas de autorização a um recurso de política de endpoint.

Uma regra da política de autorização tem os seguintes componentes:

  • from: especifica a identidade do cliente permitida pela regra. A identidade pode ser derivada de um certificado de cliente numa ligação TLS mútua ou pode ser a identidade ambiente associada à VM do cliente, como a de uma conta de serviço ou uma etiqueta segura.
  • to: especifica as operações permitidas pela regra, como os URLs que podem ser acedidos ou os métodos HTTP permitidos.
  • when: permite-lhe definir restrições adicionais que têm de ser cumpridas. Pode usar expressões do Idioma de expressão comum (IEC) para definir as restrições.
  • action: especifica a ação da regra. Pode ser um dos seguintes: ALLOW, DENY ou CUSTOM.

Limitações

A segurança do serviço Cloud Service Mesh só é suportada com o GKE. Não pode implementar a segurança de serviços com o Compute Engine.

Quando avalia um pedido, uma política de autorização toma qualquer uma das seguintes ações:

  • ALLOW: concede acesso ao recurso pedido se o pedido corresponder às regras definidas na política de autorização. A política de autorização bloqueia o acesso ao recurso pedido se o pedido não corresponder a nenhuma regra definida na política de autorização. Um pedido é recusado se não corresponder a uma política ALLOW, mesmo que outras políticas o permitam.

  • DENY: bloqueia o acesso ao recurso se um pedido corresponder a qualquer uma das regras especificadas numa política de DENY. A política de autorização concede acesso ao recurso pedido se o pedido não corresponder a nenhuma regra definida na política de autorização. Um pedido é recusado se corresponder a uma política DENY, mesmo que outras políticas o permitam.

  • CUSTOM (Não suportado na malha de serviços na nuvem): permite a integração com sistemas de autorização externos para decisões de autorização complexas. As ações CUSTOM são usadas para políticas que usam extensões de serviços para decisões de autorização.

Ordem de avaliação da política de autorização

Quando várias políticas de autorização estão associadas a um único recurso, são avaliadas pela seguinte ordem para determinar se um pedido é permitido ou recusado.

  1. Políticas com CUSTOMações: se a política CUSTOM negar o pedido, o pedido é rejeitado imediatamente. As políticas DENY ou ALLOW não são avaliadas, mesmo que alguma esteja configurada.

  2. Políticas com DENY ações: se alguma política DENY corresponder ao pedido, o pedido é recusado. As políticas ALLOW não são avaliadas, mesmo que estejam configuradas.

  3. Políticas com ações ALLOW: se não existirem políticas ALLOW ou se qualquer política ALLOW corresponder ao pedido, o pedido é permitido. No entanto, se não existirem políticas ALLOW que correspondam ao pedido, o pedido é recusado.

Limitações com aplicações gRPC sem proxy

A segurança do serviço para serviços gRPC sem proxy tem as seguintes limitações:

  • Esta versão está limitada a Java, Python, C++ e Go.

Quotas da AuthzPolicy

  • Está limitado a um total de 5 políticas de autorização por gateway.
  • Está limitado(a) a 20 recursos AuthzPolicy por projeto.
  • Uma única AuthzPolicy pode apontar para até 100 gateways.

O que se segue?