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

Este documento descreve as práticas recomendadas para estabelecer e governar Malha de serviço do Cloud em execução no Google Kubernetes Engine (GKE). As orientações na vai além das configurações usadas para configurar e provisionar o Cloud Service Mesh e descreve como é possível usar o Cloud Service Mesh com outros e recursos para se proteger contra as ameaças de segurança que os aplicativos em uma malha.

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 uma do Cloud Service Mesh. As medidas de segurança descritas aqui também são úteis para organizações que precisam reforçar a segurança dos serviços para atender aos requisitos de conformidade.

O documento está organizado da seguinte forma:

Introdução

O Cloud Service Mesh oferece recursos e ferramentas que ajudam a observar, gerenciar e serviços seguros 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 oferece controle declarativo o comportamento da rede, o que ajuda a separar o trabalho das equipes responsáveis por entregar e lançar recursos de aplicativos das responsabilidades administradores responsáveis pela segurança e pela 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. O Cloud Service Mesh padrão são escolhidas para proteger os aplicativos, mas, em alguns casos, pode ser configurações personalizadas ou pode ser necessário conceder exceções excluindo determinados que apps, portas ou endereços IP participem de uma malha. Ter controles em para controlar as configurações da malha e exceções de segurança.

Este documento complementa Documentação das 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. Tratar recomendações como base para uso com as práticas recomendadas discutidos 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 de política de segurança para determinados tráfegos (internos ou externas) sejam excluídas 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 operações ou tráfego 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 análise de alto nível da postura de segurança proposta do Cloud Service Mesh é proteger um serviço malha por meio da integração de vários mecanismos de segurança em diferentes camadas, o que para atingir a segurança geral do sistema no modelo de segurança de confiança zero. O diagrama a seguir mostra a postura de segurança proposta do Cloud Service Mesh.

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 do tráfego de rede 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 do Cloud Service Mesh (mTLS) aplica o tráfego entre cargas de trabalho criptografia e autenticação.
    • 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.
    • Painel de segurança do GKE Enterprise monitora as configurações de políticas de segurança e NetworkPolicies do Kubernetes para as cargas de trabalho.
    • Controle de acesso do pod aplicado pela política de rede do Kubernetes com base em IP de pods, rótulos de pods, 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.
    • Federação de identidade da carga de trabalho para GKE permite que as cargas de trabalho consigam 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êineres (CNI, na sigla em inglês) do Kubernetes impede ataques de escalonamento de privilégios, eliminando a necessidade de um sistema Contêiner init 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 autorização binária do Google Cloud 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

Nesta seção, descrevemos 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 exfiltração de dados e MitM aplicando Autenticação e criptografia mTLS para todas as partes que se comunicam. O modo permissivo usa mTLS quando ambos os lados oferecem suporte 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 Políticas de segurança do Cloud Service Mesh para algumas portas e endereços IP de destino, por exemplo, para estabelecer conexões nativas com serviços 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. Malha de serviço do Cloud as políticas de autorização sejam aplicadas com base nas identidades autenticadas dos resultados da autenticação. Com base em mTLS ou JSON Web Token (JWT) a autenticação pode ser usada em conjunto como parte do Cloud Service Mesh políticas de autorização.

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 em identidades autenticadas, derivadas de resultados de autenticação, para defender contra 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 visam restringir ao máximo a confiança. 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 Políticas de rede do Kubernetes que só operam na camada da rede (camadas 3 e camadas 4) e controlam o acesso à rede para endereços IP e portas em pods do Kubernetes e no Kubernetes os namespaces.

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 que ela seja autenticada e autorizada pelo serviço de malha. Um token de fora da malha pode ser de 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 os invasores não podem usar um token roubado na malha para acessar 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 sua 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 de uso, pode ser necessário criar exceções para permitir que determinados tráfego interno ou externo a ser excluído da segurança do Cloud Service Mesh e políticas de segurança, o que cria problemas 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. Você pode adicionar annotations, como excludeInboundPorts, excludeOutboundPorts e excludeOutboundIPRanges aos pods para impedir que o tráfego seja processado pelo Arquivo secundário do Envoy. Além das anotações para excluir o tráfego, é possível ignorar a malha implantando um aplicativo com injeção de arquivo secundário desativada: por exemplo, adicionando um rótulo sidecar.istio.io/inject="false" ao ao pod do aplicativo.

Ignorar as políticas de segurança do Cloud Service Mesh tem um impacto negativo na a 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 rede mesh em cenários em que é possível:

  • Verifique se o tráfego que ignora os arquivos secundários é criptografado nativamente e autenticado para evitar ataques MitM.
  • Aplicar políticas de rede do Kubernetes para limitar a conectividade de portas com exceções de políticas, como limitar uma porta com exceções de políticas para permitir apenas no mesmo namespace ou permitir apenas a passagem de tráfego as 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. É possível usar o Config Sync para evitar desvios de configuração.

aplicar os 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 fornece 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 e 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 de CNI do Istio (em inglês) para configurar o redirecionamento de tráfego para arquivos secundários.

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.
  • Processamento de vulnerabilidades e exposições comuns (CVE, na sigla em inglês). Após uma vulnerabilidade for descoberto em uma imagem de contêiner, os administradores da malha poderão 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 um chave da conta de serviço em um secret do Kubernetes e usando a chave da conta de serviço para acessar serviços não são tão seguros devido aos riscos vazamento de credenciais, escalonamento de privilégios, divulgação de informações do 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. Use o painel de segurança do GKE Enterprise e telemetria para exibir 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 credenciais ou dados confidenciais do usuário no serviço armazenamento, como secrets do Kubernetes ou diretamente nos pods, podem ficar vulneráveis a ataques oriundos de pods ou operações maliciosas. Os dados também ficarão vulneráveis a ataques de rede se forem transferidos a 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.
  • Aplicar a troca de token evitar a exfiltração de tokens de longa duração e altamente privilegiados.