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

Este documento descreve as práticas recomendadas para estabelecer e controlar uma configuração segura do Cloud Service Mesh em execução no Google Kubernetes Engine (GKE). As orientações no documento vão além das configurações usadas para configurar e provisionar o Cloud Service Mesh e descrevem como usá-lo com outros Google Cloud produtos e recursos para se proteger contra as ameaças de segurança que os aplicativos em uma malha podem enfrentar.

O público-alvo deste documento inclui administradores que gerenciam políticas em um Cloud Service Mesh e proprietários de serviços que executam serviços em um Cloud Service Mesh. As medidas de segurança descritas aqui também são úteis para organizações que precisam melhorar a segurança das malhas de serviço para atender aos requisitos de conformidade.

O documento está organizado da seguinte forma:

Introdução

O Cloud Service Mesh fornece recursos e ferramentas que ajudam a observar, gerenciar e proteger serviços de maneira unificada. Ele usa uma abordagem centrada no aplicativo e usa identidades de aplicativo confiáveis em vez de uma abordagem focada em IP de rede. É possível implantar uma malha de serviço de maneira transparente, sem a necessidade de modificar o código do aplicativo atual. O Cloud Service Mesh fornece controle declarativo sobre o comportamento da rede, o que ajuda a separar o trabalho das equipes responsáveis por fornecer e liberar recursos de aplicativos das responsabilidades de administradores responsáveis por segurança e rede.

O Cloud Service Mesh é baseado na malha de serviço do Istio de código aberto, que permite configurações e topologias sofisticadas. Dependendo da estrutura da sua organização, uma ou mais equipes ou funções podem ser responsáveis por instalar e configurar uma malha. As configurações padrão do Cloud Service Mesh são escolhidas para proteger aplicativos, mas, em alguns casos, você pode precisar de configurações personalizadas ou conceder exceções excluindo determinados apps, portas ou endereços IP da participação em uma malha. Ter controles para controlar as configurações de malha e as exceções de segurança é importante.

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

Vetores de ataque e riscos de segurança

Vetores de ataque

A segurança do Cloud Service Mesh segue o modelo de segurança de confiança zero, que pressupõe que as ameaças de segurança são originadas de dentro e fora do perímetro de segurança de uma organização. Confira a seguir exemplos de tipos de ataques de segurança que podem ameaçar aplicativos em uma malha de serviço:

  • Ataques de exfiltração de dados; Por exemplo, ataques que enxergam dados confidenciais ou credenciais de tráfego entre serviços.
  • Ataques man-in-the-middle; Por exemplo, um serviço malicioso que se disfarça como um serviço legítimo para receber ou modificar a comunicação entre serviços.
  • Ataques de escalonamento de privilégios Por exemplo, ataques que usam acesso ilícito a privilégios elevados para realizar operações em uma rede.
  • ataques de negação de serviço (DoS);
  • Ataques de botnet que tentam comprometer e manipular os serviços para lançar ataques a outros serviços

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

  • Ataques internos de rede em malha. Ataques destinados a adulterar, espionar ou spoofing a comunicação interna de serviço a serviço ou de plano de controle de serviço.
  • Ataques do plano de controle Os ataques que causam o mau funcionamento do plano de controle (como um ataque de DoS) ou a exfiltração de dados confidenciais do plano de controle.
  • Ataques de borda da malha. Ataques destinados a adulterar, escutar ou spoofing da comunicação na entrada ou saída da malha.
  • Ataques de operação de malha Ataques direcionados às operações da malha. Os invasores podem tentar conseguir privilégios elevados para realizar operações maliciosas em uma malha, como a modificação de políticas de segurança e de imagens de carga de trabalho.

Riscos de segurança

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

  • Proteção de segurança incompleta. Uma malha de serviço não foi configurada com políticas de autenticação e autorização para proteger a segurança. Por exemplo, nenhuma política de autenticação ou autorização é definida para serviços em uma malha.
  • Exceções à política de segurança. Para acomodar os casos de uso específicos, os usuários podem criar exceções da política de segurança para determinado tráfego (interno ou externo) a ser excluído das políticas de segurança do Cloud Service Mesh. Para lidar com esses casos com segurança, consulte Gerenciar exceções às políticas com segurança neste documento.
  • Negligência nos upgrades de imagem. É possível descobrir vulnerabilidades para as imagens usadas em uma malha. É necessário manter o componente da malha e as imagens da carga de trabalho atualizados com as correções de vulnerabilidades mais recentes.
  • Falta de manutenção (sem experiência ou recursos); O software da malha e as configurações da política precisam de manutenção regular para aproveitar os mecanismos de proteção de segurança mais recentes.
  • Falta de visibilidade. Configuração incorreta ou não segura de políticas de malha e tráfego ou operações de malha anormal não são atraídas pelos administradores da malha.
  • Deslocamento de configuração. A configuração das políticas em uma malha é diferente da fonte de verdade.

Medidas para proteger uma malha de serviço

Esta seção apresenta um manual operacional para proteger as malhas de serviço.

Arquitetura de segurança

A segurança da malha de serviço depende da segurança dos componentes em diferentes camadas do sistema da malha e dos aplicativos dela. A intenção de alto nível da postura de segurança proposta pelo Cloud Service Mesh é proteger uma malha de serviço pela integração de vários mecanismos de segurança em diferentes camadas, o que junta a segurança geral do sistema com a segurança de confiança zero. O diagrama a seguir 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 borda da malha
    • A segurança de entrada do Cloud Service Mesh fornece controle 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 do Cloud Service Mesh regula o tráfego de saída de cargas de trabalho internas.
    • A autenticação de usuário do Cloud Service Mesh é integrada à infraestrutura do Google para autenticar chamadas externas de navegadores da Web para os serviços que executam aplicativos da Web.
    • O gerenciamento de certificados de gateway do Cloud Service Mesh protege e alterna as chaves privadas e os certificados X.509 usados pelos gateways de entrada e saída do Cloud Service Mesh usando o Certificate Authority Service.
    • A VPC e o VPC Service Controls protegem a borda da malha por meio dos controles de acesso à rede privada.
  • Segurança do cluster
    • O TLS mútuo (mTLS) do Cloud Service Mesh aplica a criptografia e a autenticação de tráfego de carga de trabalho para carga de trabalho.
    • A autoridade certificadora do Cloud Service Mesh provisiona e gerencia com segurança os certificados usados pelas cargas de trabalho.
    • A autorização do Cloud Service Mesh aplica o controle de acesso para serviços de malha com base em identidades e outros atributos.
    • O painel de segurança do GKE Enterprise oferece monitoramento das configurações de políticas de segurança e políticas de rede do Kubernetes para as cargas de trabalho.
    • Controle de acesso do pod aplicado pela política de rede do Kubernetes com base em endereços IP, rótulos de pod, namespaces e muito mais.
  • Segurança da carga de trabalho
    • Mantenha-se atualizado com as versões de segurança do Cloud Service Mesh para garantir que os binários do Cloud Service Mesh em execução na malha não tenham vulnerabilidades conhecidas publicamente.
    • A federação de identidade da carga de trabalho para o GKE permite que as cargas de trabalho recebam credenciais para chamar os serviços do Google com segurança.
    • O Cloud Key Management Service (Cloud KMS) protege dados confidenciais ou credenciais usando módulos de segurança de hardware (HSMs). Por exemplo, as cargas 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 da malha, é compatível com chaves de assinatura por cliente e HSM gerenciadas pelo Cloud KMS.
    • A interface de rede de contêiner (CNI, na sigla em inglês) do Kubernetes evita ataques de escalonamento de privilégios, eliminando a necessidade de um contêiner iniciado privilegiado do Cloud Service Mesh.
  • Segurança do operador
    • O controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes restringe o acesso aos recursos do Kubernetes e limita as permissões do operador para reduzir ataques causados por operadores mal-intencionados ou falsificação de identidade.
    • O GKE Enterprise Policy Controller valida e audita configurações de política na malha para evitar configurações incorretas.
    • A Google Cloud autorização binária garante que as imagens de carga de trabalho na malha sejam as autorizadas pelos administradores.
    • Os Registros de auditoria do Cloud auditam as operações da malha.

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

fluxo de tráfego de segurança

Segurança do cluster

Esta seção descreve as práticas recomendadas relacionadas à segurança do cluster.

Ativar o TLS mútuo rigoroso

Um ataque "man-in-the-middle" (MitM) tenta inserir uma entidade mal-intencionada entre duas partes que se comunicam para espionar ou manipular a comunicação. O Cloud Service Mesh protege contra ataques de MitM e exfiltração de dados aplicando a autenticação e criptografia mTLS para todas as partes que estão se comunicando. O modo permissivo usa mTLS quando os dois lados são compatíveis, mas permite conexões sem mTLS. Já o mTLS rigoroso exige que o tráfego seja criptografado e autenticado com mTLS, mas não permite o uso de texto simples.

O Cloud Service Mesh permite que você configure a versão mínima do TLS para as conexões TLS entre as cargas de trabalho para atender aos requisitos de segurança e compliance.

Para mais informações, consulte Cloud Service Mesh por exemplo: mTLS | Aplicação de mTLS na malha inteira.

Ativar controles de acesso

Recomendamos que as políticas de segurança do Cloud Service Mesh (como políticas de autenticação e autorização) sejam aplicadas em todo o tráfego dentro e fora da malha, a menos que haja fortes justificativas para excluir um serviço ou pod das políticas de segurança do Cloud Service Mesh. Em alguns casos, os usuários podem ter motivos legítimos para ignorar as políticas de segurança do Cloud Service Mesh para algumas portas e intervalos de endereços IP, por exemplo, para estabelecer conexões nativas com serviços que não são gerenciados pelo Cloud Service Mesh. Para proteger o Cloud Service Mesh com esses casos de uso, consulte Gerenciar as exceções de política do Cloud Service Mesh com segurança.

O controle de acesso aos serviços é fundamental para impedir o acesso não autorizado a serviços. A aplicação de mTLS criptografa e autentica uma solicitação, mas uma malha ainda precisa de políticas de autorização do Cloud Service Mesh para aplicar o controle de acesso aos serviços, por exemplo, rejeitando uma solicitação não autorizada de um cliente autenticado.

As políticas de autorização do Cloud Service Mesh oferecem uma maneira flexível de configurar controles de acesso para proteger seus serviços contra acesso não autorizado. As políticas de autorização do Cloud Service Mesh precisam ser aplicadas com base nas identidades autenticadas derivadas dos resultados da autenticação. A autenticação baseada em mTLS ou JSON Web Token (JWT) pode ser usada em conjunto como parte das políticas de autorização do Cloud Service Mesh.

Aplicar políticas de autenticação do Cloud Service Mesh

Ao considerar as políticas de autenticação do Cloud Service Mesh, considere os seguintes pontos.

JSON Web Token (JWT)

Além da autenticação mTLS, os administradores da malha podem exigir que um serviço autentique e autorize solicitações com base no JWT. O Cloud Service Mesh não atua como um provedor JWT, mas autentica JWTs com base nos endpoints configurados do conjunto de chaves da Web JSON (JWKS, na sigla em inglês). 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 solicitado exige prova de que ele está sendo chamado em nome do autor da chamada final. A aplicação da autenticação JWT protege contra ataques que acessam um serviço sem credenciais válidas e em nome de um usuário final real.

Autenticação de usuários do Cloud Service Mesh

A autenticação do usuário do Cloud Service Mesh é uma solução integrada para autenticação e controle de acesso do usuário final baseada em navegador para as cargas de trabalho. Ele integra uma malha de serviço aos provedores de identidade (IdP) existentes para implementar um fluxo padrão de login e consentimento do OpenID Connect (OIDC) e usa políticas de autorização do Cloud Service Mesh para controle de acesso.

Aplicar políticas de autorização

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

  • Quem ou o que tem permissão para acessar um serviço.
  • Quais recursos podem ser acessados.
  • Quais operações podem ser realizadas nos recursos permitidos.

As políticas de autorização são uma forma versátil de configurar o controle de acesso com base nas identidades reais usadas pelos serviços, nas propriedades de camada de aplicativo (camada 7) do tráfego (por exemplo, cabeçalhos de solicitação) e na camada de rede (camada 3 e camada 4), como intervalos de IP e portas.

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

Por padrão, negue o acesso a um serviço, a menos que uma política de autorização seja explicitamente definida para permitir o acesso ao serviço. Consulte Práticas recomendadas da política de autorização para ver exemplos de políticas de autorização que negam solicitações de acesso.

As políticas de autorização têm como objetivo 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 somente o serviço A possa acessar o caminho /admin do serviço B.

As políticas de autorização podem ser usadas com as Políticas de rede do Kubernetes, que operam apenas na camada de rede (camada 3 e 4) e controlam o acesso à rede para endereços IP e portas nos pods e namespaces do Kubernetes.

Aplicar a troca de tokens para acessar serviços de malha

Para se proteger contra ataques de repetição de token, que roubam tokens e reutilizam os tokens roubados para acessar serviços de malha, verifique se um token em uma solicitação de fora da malha é trocado por um token interno de curta duração na borda da malha.

Uma solicitação de fora da malha para acessar um serviço de malha precisa 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 longa duração. Para se proteger contra ataques de repetição de token, troque um token de fora da malha por um token interno de curta duração com escopo limitado na entrada da malha. O serviço de malha autentica um token interno da malha e autoriza a solicitação de acesso com base no token interno da malha.

O Cloud Service Mesh oferece suporte à integração com o Identity-Aware Proxy (IAP), que gera um RequestContextToken (um token interno da malha de curta duração trocado de um token externo) usado no Cloud Service Mesh para autorização. Com a troca de tokens, os invasores não podem usar um token roubado na malha para acessar os serviços. O escopo e a vida útil limitados do token trocado reduzem muito a chance de um ataque de repetição do token.

Lidar com segurança com exceções de política do Cloud Service Mesh

Talvez você tenha casos de uso especiais para a malha de serviço. Por exemplo, talvez seja necessário expor uma determinada porta de rede para o tráfego de texto simples. Para acomodar cenários de uso específicos, às vezes pode ser necessário criar exceções para permitir que determinado tráfego interno ou externo seja excluído das políticas de segurança do Cloud Service Mesh, o que cria preocupações de segurança.

Você pode ter motivos legítimos para ignorar as políticas de segurança do Cloud Service Mesh em algumas portas e intervalos de IP. É possível adicionar anotações, como excludeInboundPorts, excludeOutboundPorts e excludeOutboundIPRanges, aos pods para excluir o tráfego do processamento do arquivo secundário do Envoy. Além das anotações para excluir o tráfego, é possível ignorar a malha ao implantar um aplicativo com a injeção de sidecar desativada, por exemplo, adicionando um rótulo sidecar.istio.io/inject="false" ao pod do aplicativo.

Ignorar as políticas de segurança do Cloud Service Mesh tem um impacto negativo na segurança geral do sistema. Por exemplo, se as políticas de autorização e mTLS do Cloud Service Mesh forem ignoradas por uma porta de rede por meio de anotações, não haverá controle de acesso para o tráfego na porta e a espionagem ou modificação do tráfego poderá ser possível. Além disso, ignorar as políticas do Cloud Service Mesh também afeta políticas que não são de segurança, como as políticas de rede.

Quando a política de segurança do Cloud Service Mesh é ignorada para uma porta ou endereço IP (intencionalmente ou não), é recomendável implementar outras medidas de segurança para proteger a malha e monitorar exceções de segurança, possíveis brechas de segurança e o status geral da aplicação da segurança. Para proteger sua malha nesses cenários, faça o seguinte:

  • Verifique se o tráfego que ignora os sidecars é criptografado e autenticado nativamente para evitar ataques de MitM.
  • Aplicar políticas de rede do Kubernetes para limitar a conectividade de portas com exceções de políticas. Por exemplo, limite uma porta com exceções de políticas para permitir apenas o tráfego de outro serviço no mesmo namespace ou para permitir apenas o tráfego que passa por portas com a política de segurança do Cloud Service Mesh aplicada.

Usar uma abordagem de GitOps com o Config Sync para evitar desvios de configuração

O deslocamento de configuração ocorre quando a configuração de políticas em uma malha se desvia da fonte de verdade. Você pode usar o Config Sync para evitar desvios de configuração.

Aplicar registros de auditoria do Cloud e monitoramento

Recomendamos que os administradores da malha monitorem o seguinte:

Os administradores podem usar esses recursos de observabilidade para verificar se a configuração de segurança está funcionando conforme o esperado e monitorar quaisquer exceções à aplicação da política de segurança. Por exemplo, acesso que não passou por arquivos secundários, 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, Prometheus) possa ser usado com o Cloud Service Mesh, é altamente recomendável usar a Observabilidade do Google Cloud. Essa solução de observabilidade integrada do Google Cloud oferece geração de registros, coleta de métricas, monitoramento e alertas, que é totalmente gerenciada.

Segurança de cargas de trabalho

A segurança da carga de trabalho protege contra ataques que comprometem os pods da carga de trabalho e usam os pods comprometidos para iniciar ataques ao cluster (por exemplo, ataques de botnet).

Restringir 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 evitar que um pod comprometido inicie ataques no cluster.

Para aplicar o princípio de privilégio mínimo às cargas de trabalho em um pod, faça o seguinte:

  • Os serviços implantados em uma malha precisam ser executados com o mínimo de privilégios possível.
  • É possível configurar o Cloud Service Mesh para usar um contêiner de inicialização para configurar o redirecionamento de tráfego do iptables para o sidecar. Isso exige que o usuário crie implantações de carga de trabalho com privilégios para implantar contêineres com os recursos NET_ADMIN e NET_RAW. Para evitar o risco de executar contêineres com privilégios elevados, os administradores da malha podem ativar o plug-in CNI do Istio para configurar o redirecionamento de tráfego para sidecars.

Imagens seguras de contêiner

Os invasores podem lançar ataques explorando imagens vulneráveis de contêineres. Os administradores devem aplicar a autorização binária para verificar a integridade das imagens de contêiner e garantir que apenas imagens de contêiner confiáveis sejam implantadas na malha.

Reduza as vulnerabilidades da malha

  • O Artifact Analysis pode verificar e mostrar vulnerabilidades nas cargas de trabalho do GKE.
  • Gerenciamento de vulnerabilidades e exposições comuns (CVEs, na sigla em inglês). Depois que uma vulnerabilidade é descoberta em uma imagem de contêiner, os administradores da malha podem corrigir a vulnerabilidade o mais rápido possível. O Google processa automaticamente as CVEs que corrigem as imagens que afetam as imagens da malha.

Usar a federação de identidade da carga de trabalho do GKE para acessar os serviços do Google com segurança

A federação de identidade da carga de trabalho para GKE é a maneira recomendada para que as cargas de trabalho da malha acessem com segurança os serviços do Google. A alternativa de armazenar uma chave de conta de serviço em um secret do Kubernetes e usar essa chave para acessar os serviços do Google não é tão segura devido aos riscos de vazamento de credenciais, escalonamento de privilégios, divulgação de informações e não repúdio.

Monitorar o status de segurança com o painel de segurança e a telemetria

Uma malha de serviço pode ter exceções de segurança e possíveis brechas. É importante mostrar e monitorar o status de segurança de uma malha, o que inclui as políticas de segurança aplicadas, exceções de segurança e possíveis brechas de segurança na malha. É possível usar o painel de segurança do GKE Enterprise e a telemetria para mostrar e monitorar o status de segurança da malha.

A telemetria monitora a integridade e o desempenho de serviços em uma malha. Isso permite que os administradores da malha observem os comportamentos dos serviços (como SLOs, tráfego anormal, interrupção de serviço e topologia).

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

Segurança para dados e credenciais confidenciais do usuário

Se você armazenar dados ou credenciais sensíveis do usuário no armazenamento permanente do cluster, como secrets do Kubernetes ou diretamente em pods, os dados ou credenciais poderão estar vulneráveis a ataques de pods ou operações maliciosas. Os dados também ficam vulneráveis a ataques de rede se forem transferidos pela rede para autenticação em serviços.

  • Se possível, armazene dados e credenciais confidenciais do usuário em um armazenamento protegido, como o Secret Manager e o Cloud KMS.
  • Designe namespaces separados para pods do Kubernetes que acessam dados confidenciais e definir políticas do Kubernetes para torná-los inacessíveis a partir de outros namespaces. Segmente os papéis usados para operações e aplique limites de namespace.
  • Aplique a troca de tokens para evitar a exfiltração de tokens de longa duração e altamente privilegiados.