Cloud Service Mesh com as práticas recomendadas de segurança das APIs Istio

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 aprovisionar o Cloud Service Mesh e descrevem como pode usar o Cloud Service Mesh com outros produtos e funcionalidades do Google Cloud 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 malha de serviços na nuvem e proprietários de serviços que executam serviços numa malha de serviços na nuvem. As medidas de segurança descritas aqui também são úteis para as 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 lançamento de funcionalidades da aplicação das responsabilidades dos administradores responsáveis pela segurança e 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 definições predefinidas 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 em vigor para reger as configurações da malha e as exceções de segurança.

Este documento complementa a documentação de práticas recomendadas de segurança do Istio, que inclui recomendações de configuração detalhadas para TLS mútuo (mTLS), políticas de autorização, gateways e outras configurações de segurança. Trate estas recomendações como base para usar em conjunto com as práticas recomendadas abordadas neste documento. Este documento descreve as práticas recomendadas adicionais para a Cloud Service Mesh e como as tecnologias na Google Cloud podem proteger todas as camadas, componentes e fluxos de informações numa malha.

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 parte do princípio de 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 à política de segurança para que determinado tráfego (interno ou externo) seja excluído das políticas de segurança da malha de serviços na nuvem. Para processar estes casos de forma segura, consulte o artigo Processar exceções às políticas de forma segura neste documento.
  • 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 ou 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 malha de serviços na nuvem proposta é proteger uma malha de serviços através da integração de vários mecanismos de segurança em diferentes camadas, que alcançam em conjunto a segurança geral do sistema no modelo de segurança de confiança zero. O diagrama seguinte mostra a postura de segurança proposta da 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 malha de serviços na nuvem fornece controlo de acesso para tráfego externo e protege o acesso externo às APIs expostas pelos serviços na malha.
    • A segurança de saída da malha de serviços na nuvem regula o tráfego de saída de cargas de trabalho internas.
    • A autenticação de utilizadores do 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.
    • 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) da Cloud Service Mesh aplica a encriptação e a autenticação do tráfego de carga de trabalho para carga de trabalho.
    • A autoridade de certificação do Cloud Service Mesh aprovisiona e gere em segurança os certificados usados pelas cargas de trabalho.
    • A autorização da Cloud Service Mesh aplica o controlo de acesso aos serviços de 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 das políticas de rede do Kubernetes para as cargas de trabalho.
    • Controlo de acesso a pods aplicado pela política de rede do Kubernetes com base em endereços IP, etiquetas de pods, espaços de nomes e muito mais.
  • 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 Cloud Key Management Service (Cloud KMS) protege dados confidenciais ou credenciais através de módulos de segurança de hardware (HSMs). Por exemplo, os fluxos de trabalho podem usar o Cloud KMS para armazenar credenciais ou outros dados confidenciais. O serviço de AC, que é usado para emitir certificados para cargas de trabalho de malha, suporta chaves de assinatura por cliente e baseadas em HSM geridas pelo Cloud KMS.
    • A interface de rede de contentores (CNI) do Kubernetes impede ataques de escalada de privilégios, eliminando a necessidade de um contentor de inicialização do Cloud Service Mesh com privilégios.
  • 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.
    • Os registos de auditoria do Cloud auditam as operações da malha.

O diagrama seguinte mostra os fluxos de comunicação e configuração com as soluções de segurança integradas na malha de serviços na nuvem.

fluxo de tráfego de segurança

Segurança do cluster

Esta secção descreve as práticas recomendadas relacionadas com a 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. O Cloud Service Mesh defende-se contra ataques MitM e de exfiltração de dados aplicando a autenticação e a 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.

A malha de serviços na nuvem permite-lhe configurar a versão mínima do TLS para as ligações TLS entre as suas cargas de trabalho de forma 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

Recomendamos que as políticas de segurança da Cloud Service Mesh (como políticas de autenticação e autorização) sejam aplicadas a todo o tráfego que entra e sai da malha, a menos que existam fortes justificações 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 endereços IP, por exemplo, para estabelecer ligações nativas com serviços que não são geridos pela Cloud Service Mesh. Para proteger a Cloud Service Mesh com estes exemplos de utilização, consulte o artigo Manuseie com segurança as exceções de políticas da Cloud Service Mesh.

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, rejeitando 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. A autenticação baseada em mTLS ou no símbolo da Web JSON (JWT) pode ser usada 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

Ao considerar as políticas de autenticação da Cloud Service Mesh, tenha em atenção os seguintes pontos.

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 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 Cloud Service Mesh para 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 que os serviços executam como propriedades da camada de aplicação (camada 7), propriedades do tráfego (por exemplo, cabeçalhos de pedidos) e propriedades da camada de rede (camada 3 e camada 4), como intervalos de IP e portas.

Recomendamos que as políticas de autorização da Cloud Service Mesh sejam aplicadas com base em identidades autenticadas derivadas dos resultados da autenticação para se defender contra o acesso não autorizado a serviços ou dados.

Por predefinição, negue o acesso a um serviço, 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 destinam-se a 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, para que apenas o serviço A possa aceder ao caminho /admin do 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, certifique-se de que um token num pedido proveniente de fora da malha é 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 um JWT ou um 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, troque um token de fora da malha 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 Cloud Service Mesh suporta a integração com o Identity-Aware Proxy (IAP), que gera um RequestContextToken (um token interno da malha de curta duração trocado a partir de um token externo) usado no Cloud Service Mesh para autorização. Com a troca de tokens, os atacantes não podem usar um token roubado na malha para aceder a serviços. O âmbito e a duração limitados do token trocado reduzem significativamente a probabilidade de um ataque de repetição de token.

Processar em segurança as exceções de políticas da malha de serviços na nuvem

Pode ter exemplos de utilização especiais para a sua malha de serviços. Por exemplo, pode ter de expor uma determinada porta de rede ao tráfego de texto simples. Para dar resposta a cenários de utilização específicos, por vezes, pode ter de criar exceções para permitir que determinado tráfego interno ou externo seja excluído das políticas de segurança da Cloud Service Mesh, o que cria preocupações de segurança.

Pode ter motivos legítimos para ignorar as políticas de segurança da Cloud Service Mesh para alguns intervalos de IP e portas. Pode adicionar anotações, como excludeInboundPorts, excludeOutboundPorts e excludeOutboundIPRanges aos pods para excluir o processamento do tráfego pelo sidecar do Envoy. Além das anotações para excluir tráfego, pode ignorar a malha completamente implementando uma aplicação com a injeção de sidecar desativada. Por exemplo, adicionando uma etiqueta sidecar.istio.io/inject="false" ao pod da aplicação.

A ignorância das políticas de segurança da malha de serviços na nuvem tem um impacto negativo na segurança geral do sistema. Por exemplo, se o mTLS do Cloud Service Mesh e as políticas de autorização forem ignorados para uma porta de rede através de anotações, não existe controlo de acesso para o tráfego na porta, e a escuta ou a modificação do tráfego podem ser possíveis. Além disso, ignorar as políticas da Cloud Service Mesh também afeta as políticas não relacionadas com a segurança, como as políticas de rede.

Quando a política de segurança da Cloud Service Mesh é ignorada para uma porta ou um endereço IP (intencionalmente ou não), recomendamos vivamente que implemente outras medidas de segurança para proteger a malha e monitorizar exceções de segurança, potenciais falhas de segurança e o estado geral da aplicação da segurança. Para proteger a sua rede de malha nestes cenários, pode:

  • Certifique-se de que o tráfego que ignora os sidecars está encriptado nativamente e autenticado para evitar ataques MitM.
  • Aplique políticas de rede do Kubernetes para limitar a conetividade de portas com exceções de políticas. Por exemplo, limite uma porta com exceções de políticas para permitir apenas tráfego de outro serviço no mesmo espaço de nomes ou para permitir apenas que o tráfego passe pelas portas que têm a política de segurança do Cloud Service Mesh aplicada.

Use uma abordagem GitOps com o Config Sync para evitar a deriva da configuração

A mudança de configuração ocorre quando a configuração das políticas numa malha se desvia da respetiva fonte de verdade. Pode usar a sincronização de configuração para evitar a deriva da configuração.

Aplique os registos de auditoria do Cloud e a monitorização

Recomendamos que os administradores da malha monitorizem o seguinte:

Os administradores podem usar estes recursos de observabilidade para verificar se a configuração de segurança está a funcionar conforme esperado e para monitorizar quaisquer exceções à aplicação da política de segurança. Por exemplo, acesso que não passou por sidecars, acesso que não tinha credenciais válidas, mas alcançou um serviço.

Embora o software de observabilidade de código aberto (por exemplo, o Prometheus) possa ser usado com a Cloud Service Mesh, recomendamos vivamente que use a Google Cloud Observability. Esta solução de observabilidade integrada para o Google Cloud oferece registo, recolha de métricas, monitorização e alertas, que são totalmente geridos.

Segurança da carga de trabalho

A segurança da carga de trabalho protege contra ataques que comprometem os pods de carga de trabalho e, em seguida, usam os pods comprometidos para lançar ataques contra o cluster (por exemplo, ataques de botnets).

Restrinja os privilégios do pod

Um pod do Kubernetes pode ter privilégios que afetam outros pods no nó ou no cluster. É importante aplicar restrições de segurança aos pods de carga de trabalho para impedir que um pod comprometido lance ataques contra o cluster.

Para aplicar o princípio do menor privilégio aos cargas de trabalho num pod:

  • Os serviços implementados numa malha devem ser executados com o menor número possível de privilégios.
  • Pode configurar a Cloud Service Mesh para usar um contentor init para configurar o redirecionamento de tráfego de iptables para o sidecar. Isto requer que o utilizador crie implementações de cargas de trabalho que tenham privilégios para implementar contentores com capacidades NET_ADMIN e NET_RAW. Para evitar o risco de executar contentores com privilégios elevados, os administradores da malha podem, em alternativa, ativar o plug-in CNI do Istio para configurar o redirecionamento de tráfego para sidecars.

Proteja imagens de contentores

Os atacantes podem lançar ataques explorando imagens de contentores vulneráveis. Os administradores devem aplicar a autorização binária para validar a integridade das imagens de contentores e garantir que apenas as imagens de contentores fidedignas são implementadas na malha.

Mitigue as vulnerabilidades da malha

  • A análise de artefactos pode analisar e apresentar vulnerabilidades em cargas de trabalho do GKE.
  • Processamento de vulnerabilidades e exposições comuns (CVE). Depois de ser descoberta uma vulnerabilidade numa imagem de contentor, os administradores da malha podem corrigir a vulnerabilidade assim que possível. A Google processa automaticamente a aplicação de patches a CVEs que afetam as imagens de malha.

Use a federação de identidade da carga de trabalho para o GKE para aceder de forma segura aos serviços Google

A federação de identidades da carga de trabalho para o GKE é a forma recomendada para as cargas de trabalho da malha acederem de forma segura aos serviços Google. A alternativa de armazenar uma chave de conta de serviço num segredo do Kubernetes e usar a chave de conta de serviço para aceder aos serviços Google não é tão segura devido aos riscos de roubo de credenciais, escalada de privilégios, divulgação de informações e não repúdio.

Monitorize o estado de segurança através do painel de controlo de segurança e da telemetria

Uma malha de serviços pode ter exceções de segurança e potenciais lacunas. É fundamental apresentar e monitorizar o estado de segurança de uma malha, que inclui as políticas de segurança aplicadas, as exceções de segurança e as potenciais lacunas de segurança na malha. Pode usar o painel de controlo de segurança do GKE Enterprise e a telemetria para apresentar e monitorizar o estado de segurança da malha.

A telemetria monitoriza o estado e o desempenho dos serviços numa malha, o que permite aos administradores da malha observar os comportamentos dos serviços (como SLOs, tráfego anormal, interrupção de serviço e topologia).

O painel de controlo de segurança do GKE Enterprise mostra as políticas de segurança aplicadas a uma carga de trabalho numa malha de serviços, incluindo políticas de controlo de acesso (políticas de rede do Kubernetes, políticas de autorização binária e políticas de controlo de acesso a serviços) e políticas de autenticação (mTLS).

Segurança para dados e credenciais de utilizadores confidenciais

Se armazenar dados ou credenciais de utilizadores confidenciais no armazenamento persistente do cluster, como segredos do Kubernetes ou diretamente em pods, os dados ou as credenciais podem ficar vulneráveis a ataques originários de pods ou operações maliciosas. Os dados também são vulneráveis a ataques de rede se forem transferidos através da rede para autenticação em serviços.

  • Se possível, armazene dados e credenciais de utilizadores sensíveis num armazenamento protegido, como o Secret Manager e o Cloud KMS.
  • Designar espaços de nomes separados para os pods do Kubernetes que acedem a dados confidenciais e definir políticas do Kubernetes para os tornar inacessíveis a partir de outros espaços de nomes. Segmente as funções usadas para operações e aplique limites de espaço de nomes.
  • Aplique a troca de tokens para impedir a exfiltração de tokens de longa duração e com privilégios elevados.