Práticas recomendadas de segurança do Cloud Service Mesh

Este documento descreve as práticas recomendadas para estabelecer e reger uma configuração segura da malha de serviços na nuvem em execução no Google Kubernetes Engine (GKE). As orientações no documento vão além das definições usadas para configurar e instalar o Cloud Service Mesh e descrevem como pode usar o Cloud Service Mesh com outros produtos e funcionalidades para se proteger contra as ameaças de segurança que as aplicações numa malha podem enfrentar. Google Cloud

O público-alvo deste documento inclui administradores que gerem políticas numa Cloud Service Mesh e utilizadores que executam serviços numa Cloud Service Mesh. As medidas de segurança descritas aqui também são úteis para organizações que precisam de melhorar a segurança das respetivas malhas de serviço para cumprir os requisitos de conformidade.

O documento está organizado da seguinte forma:

Introdução

O Cloud Service Mesh oferece funcionalidades e ferramentas que ajudam a observar, gerir e proteger os serviços de forma unificada. Adota uma abordagem centrada na aplicação e usa identidades de aplicações fidedignas em vez de uma abordagem focada no IP da rede. Pode implementar uma malha de serviços de forma transparente sem necessidade de modificar o código da aplicação existente. A malha de serviços na nuvem oferece controlo declarativo sobre o comportamento da rede, o que ajuda a separar o trabalho das equipas responsáveis pela entrega e pela publicação de funcionalidades de aplicações das responsabilidades dos administradores responsáveis pela segurança e pela rede.

O Cloud Service Mesh baseia-se no Istio service mesh de código aberto, que permite configurações e topologias sofisticadas. Consoante a estrutura da sua organização, uma ou mais equipas ou funções podem ser responsáveis pela instalação e configuração de uma rede de malha. As predefinições do Cloud Service Mesh são escolhidas para proteger as aplicações, mas, em alguns casos, pode precisar de configurações personalizadas ou conceder exceções excluindo determinadas apps, portas ou endereços IP da participação numa malha. É importante ter controlos implementados para reger as configurações da malha e as exceções de segurança.

Vetores de ataque e riscos de segurança

Vetores de ataque

A segurança da Cloud Service Mesh segue o modelo de segurança de confiança zero, que assume que as ameaças de segurança têm origem no interior e no exterior do perímetro de segurança de uma organização. Seguem-se alguns exemplos de tipos de ataques de segurança que podem ameaçar as aplicações numa malha de serviços:

  • Ataques de exfiltração de dados. Por exemplo, ataques que ouvem dados confidenciais ou credenciais do tráfego de serviço para serviço.
  • Ataques do tipo man-in-the-middle. Por exemplo, um serviço malicioso que se faz passar por um serviço legítimo para obter ou modificar a comunicação entre serviços.
  • Ataques de escalamento de privilégios. Por exemplo, ataques que usam acesso ilícito a privilégios elevados para realizar operações numa rede.
  • Ataques de negação de serviço (DoS).
  • Ataques de botnets que tentam comprometer e manipular serviços para lançar ataques a outros serviços.

Os ataques também podem ser categorizados com base nos alvos dos ataques:

  • Malha de ataques de rede internos. Ataques destinados a adulterar, ouvir ou falsificar a comunicação interna de serviço a serviço ou de serviço ao plano de controlo da malha.
  • Ataques ao plano de controlo. Ataques destinados a provocar o mau funcionamento do plano de controlo (como um ataque DoS) ou a exfiltrar dados confidenciais do plano de controlo.
  • Ataques de arestas da malha. Ataques destinados a adulterar, intercetar ou roubar a identidade da comunicação na entrada ou saída da malha.
  • Ataques de operações de malha. Ataques dirigidos às operações da malha. Os atacantes podem tentar obter privilégios elevados para realizar operações maliciosas numa rede de malha, como modificar as respetivas políticas de segurança e imagens de carga de trabalho.

Riscos de segurança

Além dos ataques de segurança, uma malha também enfrenta outros riscos de segurança. A seguinte lista descreve alguns possíveis riscos de segurança:

  • Proteção de segurança incompleta. Uma malha de serviços não foi configurada com políticas de autenticação e autorização para proteger a respetiva segurança. Por exemplo, não estão definidas políticas de autenticação nem autorização para serviços numa malha.
  • Exceções à política de segurança. Para dar resposta aos respetivos exemplos de utilização específicos, os utilizadores podem criar exceções de políticas de segurança para que determinado tráfego (interno ou externo) seja excluído das políticas de segurança da Cloud Service Mesh. Para tratar estes casos em segurança, consulte a secção Trate as exceções às políticas em segurança.
  • Negligência das atualizações de imagens. Podem ser descobertas vulnerabilidades nas imagens usadas numa malha. Tem de manter o componente de malha e as imagens de carga de trabalho atualizados com as correções de vulnerabilidades mais recentes.
  • Falta de manutenção (sem conhecimentos nem recursos). O software de malha e as configurações de políticas requerem manutenção regular para tirar partido dos mecanismos de proteção de segurança mais recentes.
  • Falta de visibilidade. A configuração incorreta ou as configurações não seguras das políticas de malha e o tráfego/as operações de malha anormais não são comunicados aos administradores de malha.
  • Desvio de configuração. A configuração das políticas numa malha desvia-se da fonte de informação fidedigna.

Medidas para proteger uma malha de serviços

Esta secção apresenta um manual de funcionamento para proteger as malhas de serviço.

Arquitetura de segurança

A segurança de uma malha de serviço depende da segurança dos componentes em diferentes camadas do sistema de malha e das respetivas aplicações. A intenção de alto nível da postura de segurança da Cloud Service Mesh proposta é proteger uma service mesh através da integração de vários mecanismos de segurança em diferentes camadas, que, em conjunto, alcançam a segurança geral do sistema ao abrigo do modelo de segurança de confiança zero. O diagrama seguinte mostra a postura de segurança proposta do Cloud Service Mesh.

Postura de segurança do Cloud Service Mesh

O Cloud Service Mesh oferece segurança em várias camadas, incluindo:

  • Segurança de edge da malha
    • A segurança de entrada da Cloud Service Mesh oferece controlo de acesso para o tráfego externo e protege o acesso externo às APIs expostas pelos serviços na malha.
    • A segurança de saída da Cloud Service Mesh regula o tráfego de saída de cargas de trabalho internas.
    • A autenticação de utilizadores da Cloud Service Mesh integra-se com a infraestrutura da Google para autenticar chamadas externas de navegadores de Internet para os serviços que executam aplicações Web.
    • A gestão de certificados de gateway do Cloud Service Mesh protege e roda as chaves privadas e os certificados X.509 usados pelos gateways de entrada e saída do Cloud Service Mesh através do serviço de autoridade de certificação.
    • O Cloud Armor pode defender-se contra ataques de negação de serviço distribuída (DDoS) externos e ataques de camada 7. Serve como uma firewall de aplicação Web (WAF) para proteger a malha contra ataques de rede. Por exemplo, ataques de injeção e execução remota de código.
    • VPC e VPC Service Controls protegem o limite da malha através dos controlos de acesso à rede privada.
  • Segurança do cluster
    • O TLS mútuo (mTLS) do Cloud Service Mesh aplica a encriptação e a autenticação do tráfego de carga de trabalho para carga de trabalho.
    • A AC gerida, como a autoridade de certificação da Cloud Service Mesh e o Certificate Authority Service, aprovisiona e gere de forma segura os certificados usados pelas cargas de trabalho.
    • A autorização da Cloud Service Mesh aplica o controlo de acesso aos serviços da malha com base nas respetivas identidades e noutros atributos.
    • O painel de controlo de segurança do GKE Enterprise oferece monitorização das configurações das políticas de segurança e políticas de rede do Kubernetes para as cargas de trabalho.
    • A política de rede do Kubernetes aplica o controlo de acesso de pods com base em endereços IP, etiquetas de pods, espaços de nomes e muito mais.
    • A segurança do plano de controlo defende contra ataques ao plano de controlo. Esta proteção impede que os atacantes modifiquem, explorem ou divulguem dados de configuração do serviço e da malha.
  • Segurança da carga de trabalho
    • Mantenha-se a par das versões de segurança do Cloud Service Mesh para garantir que os binários do Cloud Service Mesh em execução na sua malha estão livres de vulnerabilidades conhecidas publicamente.
    • A federação de identidades da carga de trabalho para o GKE permite que as cargas de trabalho obtenham credenciais para chamar os serviços Google de forma segura.
    • O CNI (Container Network Interface) do Kubernetes impede ataques de escalada de privilégios, eliminando a necessidade de um contentor de inicialização do Cloud Service Mesh privilegiado.
  • Segurança do operador
    • O controlo de acesso baseado em funções (CABF) do Kubernetes restringe o acesso aos recursos do Kubernetes e limita as autorizações do operador para mitigar ataques originados de operadores maliciosos ou roubo de identidade de operadores.
    • O GKE Enterprise Policy Controller valida e audita as configurações de políticas na malha para evitar configurações incorretas.
    • Google Cloud Autorização binária garante que as imagens da carga de trabalho na malha são as autorizadas pelos administradores.
    • Google Cloud O Registo de auditoria audita as operações da malha.

O diagrama abaixo mostra os fluxos de comunicação e configuração com as soluções de segurança integradas no Cloud Service Mesh.

Diagrama de segurança do fluxo de tráfego

Segurança do cluster

Ative o TLS mútuo rigoroso

Um ataque do tipo man-in-the-middle (MitM) tenta inserir uma entidade maliciosa entre duas partes que estão a comunicar para intercetar ou manipular a comunicação. A malha de serviços na nuvem defende-se contra ataques de roubo de identidade e exfiltração de dados através da aplicação da autenticação e encriptação mTLS para todas as partes que comunicam. O modo permissivo usa mTLS quando ambos os lados o suportam, mas permite ligações sem mTLS. Por outro lado, o mTLS rigoroso requer que o tráfego seja encriptado e autenticado com mTLS e não permite tráfego de texto simples.

O Cloud Service Mesh permite-lhe configurar a versão mínima do TLS para as ligações TLS entre as suas cargas de trabalho de modo a cumprir os seus requisitos de segurança e conformidade.

Para mais informações, consulte o artigo Cloud Service Mesh by example: mTLS | Enforcing mesh-wide mTLS (Cloud Service Mesh por exemplo: mTLS | Aplicação de mTLS em toda a malha).

Ative os controlos de acesso

As políticas de segurança da Cloud Service Mesh (como políticas de autenticação e autorização) devem ser aplicadas a todo o tráfego que entra e sai da malha, a menos que existam justificações fortes para excluir um serviço ou um pod das políticas de segurança da Cloud Service Mesh. Em alguns casos, os utilizadores podem ter motivos legítimos para ignorar as políticas de segurança da Cloud Service Mesh para algumas portas e intervalos de IP. Por exemplo, para estabelecer ligações nativas com serviços não geridos pela Cloud Service Mesh. Para proteger a Cloud Service Mesh nestes exemplos de utilização, consulte o artigo Como processar exceções de políticas da Cloud Service Mesh em segurança.

O controlo de acesso ao serviço é fundamental para impedir o acesso não autorizado aos serviços. A aplicação do mTLS encripta e autentica um pedido, mas uma malha continua a precisar de políticas de autorização da Cloud Service Mesh para aplicar o controlo de acesso aos serviços. Por exemplo, rejeitar um pedido não autorizado proveniente de um cliente autenticado.

As políticas de autorização da Cloud Service Mesh oferecem uma forma flexível de configurar os controlos de acesso para defender os seus serviços contra o acesso não autorizado. As políticas de autorização da Cloud Service Mesh devem ser aplicadas com base nas identidades autenticadas derivadas dos resultados da autenticação. As autenticações baseadas em mTLS ou JSON Web Token (JWT) devem ser usadas em conjunto como parte das políticas de autorização da Cloud Service Mesh.

Aplique políticas de autenticação da malha de serviços na nuvem

Símbolo da Web JSON (JWT)

Além da autenticação mTLS, os administradores da malha podem exigir que um serviço autentique e autorize pedidos com base no JWT. O Cloud Service Mesh não atua como um fornecedor de JWT, mas autentica JWTs com base nos pontos finais do conjunto de chaves Web JSON (JWKS) configurados. A autenticação JWT pode ser aplicada a gateways de entrada para tráfego externo ou a serviços internos para tráfego na malha. A autenticação JWT pode ser combinada com a autenticação mTLS quando um JWT é usado como uma credencial para representar o autor da chamada final e o serviço pedido requer uma prova de que está a ser chamado em nome do autor da chamada final. A aplicação da autenticação JWT defende contra ataques que acedem a um serviço sem credenciais válidas e em nome de um utilizador final real.

Autenticação de utilizadores do Cloud Service Mesh

A autenticação de utilizadores do Cloud Service Mesh é uma solução integrada para a autenticação de utilizadores finais baseada no navegador e o controlo de acesso às suas cargas de trabalho. Integra uma malha de serviços com os Fornecedores de identidade (IdP) existentes para implementar um fluxo de consentimento e início de sessão OpenID Connect (OIDC) padrão baseado na Web e usa políticas de autorização da malha de serviços na nuvem para o controlo de acesso.

Aplique políticas de autorização

As políticas de autorização do Cloud Service Mesh controlam:

  • Quem ou o quê tem autorização para aceder a um serviço.
  • Aos recursos aos quais se pode aceder.
  • Que operações podem ser realizadas nos recursos permitidos.

As políticas de autorização são uma forma versátil de configurar o controlo de acesso com base nas identidades reais com que os serviços são executados, nas propriedades da camada de aplicação (camada 7) do tráfego (por exemplo, cabeçalhos de pedidos) e nas propriedades da camada de rede (camada 3 e camada 4), como intervalos de IP e portas.

As políticas de autorização da Cloud Service Mesh devem ser aplicadas com base nas identidades autenticadas derivadas dos resultados da autenticação para se defenderem contra o acesso não autorizado a serviços ou dados.

Por predefinição, o acesso a um serviço deve ser negado, a menos que seja definida explicitamente uma política de autorização para permitir o acesso ao serviço. Consulte as práticas recomendadas da política de autorização para ver exemplos de políticas de autorização que negam pedidos de acesso.

As políticas de autorização devem restringir a confiança o máximo possível. Por exemplo, o acesso a um serviço pode ser definido com base em caminhos de URL individuais expostos por um serviço, de modo que apenas um serviço A possa aceder ao caminho /admin de um serviço B.

As políticas de autorização podem ser usadas em conjunto com as políticas de rede do Kubernetes, que só funcionam na camada de rede (camada 3 e camada 4) e controlam o acesso à rede para endereços IP e portas em pods do Kubernetes e espaços de nomes do Kubernetes.

Aplique a troca de tokens para aceder aos serviços de malha

Para se defender contra ataques de repetição de tokens que roubam tokens e reutilizam os tokens roubados para aceder a serviços de malha, um token num pedido proveniente de fora da malha deve ser trocado por um token interno da malha de curta duração no limite da malha.

Um pedido de fora da malha para aceder a um serviço de malha tem de incluir um token, como JWT ou cookie, para ser autenticado e autorizado pelo serviço de malha. Um token de fora da malha pode ter uma duração longa. Para se defender contra ataques de repetição de tokens, um token de fora da malha deve ser trocado por um token interno da malha de curta duração com um âmbito limitado na entrada da malha. O serviço de malha autentica um token interno da malha e autoriza o pedido de acesso com base no token interno da malha.

O que se segue?