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 malha de serviços do Google Cloud e utilizadores que executam serviços numa malha de serviços do Google Cloud. 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 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 pressupõe que as ameaças de segurança têm origem dentro e fora 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 processar estes casos de forma segura, consulte a secção Processe exceções às políticas de forma segura.
  • 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 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 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) da 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 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 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 Cloud Key Management Service (Cloud KMS) protege dados ou credenciais confidenciais através de Hardware Security Modules (HSM). Por exemplo, os fluxos de trabalho podem usar o Cloud KMS para armazenar credenciais ou outros dados confidenciais. O serviço de AC, usado para emitir certificados para cargas de trabalho de malha, suporta chaves de assinatura por cliente e baseadas em HSM geridas pelo Cloud KMS.
    • 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. 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.

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 malha de serviços na nuvem nestes exemplos de utilização, consulte o artigo Como processar exceções de políticas da malha de serviços na nuvem de forma segura.

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 no símbolo da Web JSON (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 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 aos 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 agrupamentos para excluir o processamento do tráfego pelo Envoy sidecar. Além das anotações para excluir tráfego, pode ignorar a malha por completo implementando uma aplicação com a injeção de sidecar desativada. Por exemplo, adicionando uma etiqueta sidecar.istio.io/inject="false" ao pod de aplicação.

A ignorância das políticas de segurança da 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 para uma porta de rede através de anotações, não haverá 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, a ignorar as políticas da Cloud Service Mesh também afeta as políticas de não 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 IP (intencionalmente ou não), devem existir outras medidas de segurança em vigor para proteger a malha e monitorizar exceções de segurança, potenciais lacunas de segurança e o estado geral da aplicação da segurança. Para proteger a sua 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, limitar 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 com a política de segurança do Cloud Service Mesh aplicada.
  • Aplique o Policy Controller do GKE Enterprise para validar automaticamente as políticas da Cloud Service Mesh. Por exemplo, aplique que os sidecars da malha de serviços na nuvem são sempre injetados em cargas de trabalho.

Aplique políticas de rede do Kubernetes

O Cloud Service Mesh baseia-se na plataforma subjacente (por exemplo, o Kubernetes). Assim, a segurança do Cloud Service Mesh depende da segurança da plataforma subjacente. Por exemplo, sem controlo sobre quem pode atualizar os recursos do Kubernetes, um utilizador pode alterar a implementação do Kubernetes de um serviço para ignorar o sidecar do serviço.

Para formar uma postura de segurança forte para uma malha de serviços, os mecanismos de segurança da plataforma subjacente devem ser aplicados para funcionar em conjunto com as políticas de segurança da malha de serviços na nuvem.

As políticas de rede do Kubernetes funcionam na camada de rede (L3 e L4) para endereços IP e portas em namespaces e pods do Kubernetes. As políticas de rede do Kubernetes podem ser aplicadas em conjunto com as políticas do Cloud Service Mesh para melhorar a segurança da malha.

Por exemplo, o administrador da malha pode configurar políticas de rede do Kubernetes para permitir apenas que o tráfego use portas com a política de segurança da Cloud Service Mesh aplicada. Se todo o tráfego tiver de ser aplicado com o mTLS da Cloud Service Mesh, o administrador pode configurar uma política de rede do Kubernetes para permitir apenas tráfego em portas configuradas com a política mTLS da Cloud Service Mesh. O administrador da malha também pode configurar políticas de rede do Kubernetes para limitar a conetividade de portas com exceções de políticas. Por exemplo, limite a conetividade de tais portas para que fiquem dentro de um espaço de nomes.

Acesso seguro ao plano de controlo

O plano de controlo da Cloud Service Mesh autentica todos os clientes que se ligam. Assim, apenas os autores da chamada com credenciais válidas (JWT do Kubernetes ou certificados X.509 emitidos por ACs permitidas) podem aceder ao plano de controlo da Cloud Service Mesh. O TLS encripta as ligações entre as cargas de trabalho e o plano de controlo da malha de serviços na nuvem.

Além do mecanismo de autenticação, para a malha de serviços na nuvem no cluster, é possível implementar políticas de rede do Kubernetes para isolar o espaço de nomes do sistema da malha de serviços na nuvem (por predefinição, istio-system) de espaços de nomes não geridos e clientes fora da malha, ao mesmo tempo que permite que os planos de dados acedam ao plano de controlo. As regras de firewall da VPC podem impedir que o tráfego fora de um cluster alcance o Istiod. Com estas medidas de isolamento de rede, um atacante fora da malha não consegue aceder ao plano de controlo, mesmo que tenha uma credencial válida. Para os planos de controlo geridos, a Google processa a segurança dos planos de controlo e não são necessárias essas políticas de isolamento de rede para os planos de controlo.

Aplique limites de espaço de nomes

Para impedir que um utilizador de um espaço de nomes aceda/atualize recursos num espaço de nomes não autorizado:

  • Aplique controlos de acesso.
  • Aplique políticas de rede do Kubernetes. Se os serviços num espaço de nomes não tiverem tráfego fora do espaço de nomes, o administrador da malha deve implementar uma política de rede do Kubernetes que permita apenas tráfego dentro do espaço de nomes: sem entrada nem saída do espaço de nomes.
  • Aplique políticas de CABF do Kubernetes.
    • As funções dos administradores de aplicações devem estar associadas a um espaço de nomes.
    • Permitir que apenas os administradores da malha tenham ClusterRole.

Aplique políticas de RBAC do Kubernetes

Os administradores da malha devem aplicar as políticas de CABF do Kubernetes para controlar quem tem autorização para aceder e atualizar os recursos do Kubernetes. O controlo de acesso do Kubernetes pode mitigar os riscos de segurança na malha. Por exemplo, não deve ser permitido que utilizadores não autorizados alterem as implementações do Kubernetes e contornem as aplicações de políticas da Cloud Service Mesh. As funções de um utilizador devem estar associadas a um espaço de nomes para que o utilizador não tenha permissão para aceder a mais espaços de nomes do que aqueles a que precisa de aceder. Para ver guias detalhados e exemplos de configuração do CABF, consulte o artigo Configure o controlo de acesso baseado em funções. Depois de ativar a federação de identidades da carga de trabalho para o GKE, também pode permitir que uma conta de serviço do Kubernetes atue como uma conta de serviço do IAM.

Segurança de Edge da malha

Uma vez que a maioria dos ataques também pode ter origem fora de um cluster, é fundamental garantir a segurança no limite da malha.

Controlo de acesso de entrada do cluster

O Cloud Service Mesh recebe tráfego externo de entrada através do gateway de entrada. Os serviços expostos pela gateway de entrada podem ser alvo de ataques de origens externas. Os administradores de segurança devem garantir sempre que os serviços expostos ao tráfego externo através de gateways de entrada são suficientemente seguros para se defenderem contra ataques.

O Ingress deve aplicar a autenticação e a autorização para serviços expostos a autores de chamadas externos.

  • Aplique políticas de segurança de entrada do cluster. Quando o cluster precisa de receber tráfego externo, o administrador da malha deve aplicar políticas de segurança de entrada, incluindo o TLS de gateway do Cloud Service Mesh, políticas de autenticação e autorização, para autenticar pedidos externos e verificar se os pedidos externos estão autorizados a aceder a serviços expostos pelo gateway de entrada. A aplicação de políticas de segurança de entrada defende contra ataques externos à malha que tentam aceder a um serviço sem credenciais ou autorizações válidas.
  • Use o Cloud Armor como uma firewall de aplicação Web (WAF) para se defender contra ataques baseados na Web (por exemplo, ataques de injeção e ataques de execução remota). Para mais informações, consulte o artigo Do limite à malha: exponha aplicações de malha de serviços através do GKE Ingress.

Regule o tráfego de saída do cluster

A segurança de saída do cluster é fundamental para a segurança da malha, porque as políticas de segurança de saída podem defender-se contra ataques de exfiltração de dados, aplicar a filtragem do tráfego de saída e aplicar a origem do TLS para o tráfego de saída. Os administradores de segurança devem regular e auditar o tráfego de saída do cluster.

Além de usar firewalls da VPC para restringir o tráfego de saída, os administradores da malha também devem aplicar políticas de segurança de saída para o cluster e configurar o respetivo tráfego de saída para passar por gateways de saída.

As políticas de saída podem mitigar os seguintes ataques:

  • Ataques de exfiltração de dados.
  • Os Service Pods podem ser explorados por atacantes se as respetivas CVEs não forem corrigidas. Os pods comprometidos podem tornar-se uma botnet controlada por atacantes para enviar spam ou iniciar ataques DoS.

As políticas de autorização aplicadas a gateways de saída podem garantir que apenas os serviços autorizados podem enviar tráfego para anfitriões específicos fora da malha. Entretanto, para o tráfego que sai da malha, em vez de processar a origem do TLS em sidecars individuais, o TLS pode ter origem em gateways de saída. Isto oferece uma forma uniforme e mais segura de originar tráfego TLS, porque os certificados de cliente para mTLS podem ser isolados dos espaços de nomes onde as aplicações são executadas.

Use um cluster privado ou o VPC Service Controls para bloquear acessos externos

Além de aplicar políticas de segurança de entrada e saída, bloqueie o acesso externo através de um cluster privado ou dos VPC Service Controls sempre que possível. Embora as políticas de segurança sejam controladas pelos administradores de segurança da malha, a configuração do cluster privado ou os VPC Service Controls podem ser aplicados pelos administradores de segurança da organização.

Os VPC Service Controls podem ser aplicados para definir um perímetro de segurança para os serviços, de modo a:

  • Restrinja o acesso dos serviços a recursos externos.
  • Restringir o acesso de pessoas externas aos serviços num perímetro de segurança.

Os VPC Service Controls ajudam a defender-se contra ataques de exfiltração de dados e impedem que atacantes externos acedam a serviços dentro de uma malha.

Defenda-se contra ataques DDoS externos

Os ataques DDoS externos podem sobrecarregar os gateways de entrada e os serviços de back-end, impedindo o processamento de pedidos legítimos. O Cloud Armor pode ser usado para se defender contra ataques DDoS. O Cloud Armor defende contra ataques DDoS não só ao nível da rede (L3 e L4), mas também ao nível da aplicação (L7).

Segurança para a administração e a automatização da rede de malha

É importante considerar a segurança para as operações administrativas e qualquer automatização que criar em torno da sua malha, por exemplo, CI/CD. As seguintes práticas destinam-se a garantir que a malha pode ser operada em segurança sem o risco de expor os serviços a ataques adicionais.

Segmente as funções usadas para operações de malha

Seguindo o mesmo princípio do controlo de acesso baseado em funções, os utilizadores de uma rede de malha devem ser classificados de acordo com as respetivas funções. Cada função deve receber apenas o conjunto mínimo de privilégios necessários para a função.

Por exemplo, o conjunto de utilizadores que fazem implementações de serviços não deve ter privilégios para atualizar as políticas de autenticação e autorização.

Existem diferentes categorias de operadores. Por exemplo, operadores de clusters e operadores de espaços de nomes. É importante impedir a escalada de privilégios por parte de um operador, o que pode resultar no acesso ilícito a recursos não autorizados.

As políticas RBAC do Kubernetes permitem que os administradores da malha limitem o acesso aos recursos apenas a utilizadores autorizados.

Valide automaticamente as configurações de políticas

Os operadores podem configurar incorretamente as políticas da Cloud Service Mesh por engano, o que pode resultar em incidentes de segurança graves. Para evitar a configuração incorreta e validar automaticamente as políticas da Cloud Service Mesh, os administradores da malha podem usar o Policy Controller para aplicar restrições às configurações de políticas.

Para evitar depositar demasiada confiança em indivíduos com autorizações para atualizar as políticas de segurança do Cloud Service Mesh e para automatizar a validação das políticas do Cloud Service Mesh, os administradores da malha devem implementar restrições nas políticas do Cloud Service Mesh através do Policy Controller.

O Policy Controller baseia-se no projeto de código aberto Gatekeeper e pode ser executado como um controlador de admissão do Kubernetes para recusar a aplicação de recursos inválidos ou no modo de auditoria para que os administradores possam ser alertados para violações. O Policy Controller pode validar automaticamente a implementação de recursos na malha, como validar se as anotações numa implementação não ignoram as políticas do Cloud Service Mesh, validar se as políticas do Cloud Service Mesh estão conforme esperado e validar se uma implementação não inclui capacidades de raiz (como NET_ADMIN e NET_RAW).

O Policy Controller também pode auditar recursos existentes da Cloud Service Mesh em relação a restrições para detetar configurações incorretas de políticas.

Seguem-se alguns exemplos do Policy Controller do GKE Enterprise a aplicar políticas de segurança:

A biblioteca de modelos de restrições fornecida com o Policy Controller contém um conjunto de modelos de restrições que podem ser usados com o pacote de restrições de segurança do Cloud Service Mesh para aplicar práticas recomendadas de segurança específicas do Cloud Service Mesh, por exemplo, políticas de autenticação, autorização e tráfego. Seguem-se alguns exemplos de restrições incluídas no pacote:

  • Aplique o nível da malha mTLS rigoroso PeerAuthentication.
  • A aplicação de todas as PeerAuthentications não pode substituir o mTLS rigoroso.
  • Aplique a AuthorizationPolicy de recusa predefinida ao nível da malha.
  • Aplique os padrões seguros da AuthorizationPolicy.
  • Aplique que os sidecars da malha de serviços na nuvem sejam sempre injetados nas cargas de trabalho.

Para processar exceções e situações de emergência, o administrador da malha pode:

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. O Config Sync pode ser usado para impedir a deriva da configuração.

Aplique a monitorização e o registo de auditoria

Os administradores da rede de malha devem monitorizar o seguinte:

Estes recursos de observabilidade podem ser usados para verificar se a configuração de segurança está a funcionar conforme esperado e monitorizar eventuais 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 a utilização da observabilidade do Google Cloud (anteriormente Stackdriver). A solução de observabilidade incorporada para o Google Cloud oferece registo, recolha de métricas, monitorização e alertas, que são totalmente geridos e fáceis de usar.

Proteja a autoridade de certificação para certificados no cluster

Por predefinição, o Cloud Service Mesh usa uma autoridade de certificação (AC) gerida pela Google denominada autoridade de certificação do Cloud Service Mesh.

Se estiver a usar a autoridade de certificação (AC) do Istio não gerida, que está alojada como parte do Istiod, a chave de assinatura da AC é armazenada num segredo do Kubernetes e é acessível aos operadores que têm acesso ao recurso secreto no espaço de nomes istio-system. Isto representa um risco, uma vez que um operador pode usar a chave da AC independentemente da AC do Istiod e, potencialmente, assinar certificados de carga de trabalho de forma independente. Também existe o risco de uma chave de assinatura da AC autogerida poder ser divulgada acidentalmente devido a um erro operacional.

Para proteger a chave de assinatura da AC, o administrador da malha pode atualizar a malha para usar a autoridade de certificação do Cloud Service Mesh ou o serviço de autoridade de certificação (serviço de AC), que são protegidos e geridos pela Google. Em comparação com a autoridade de certificação do Cloud Service Mesh, o serviço de CA suporta chaves de assinatura por cliente através do Cloud KMS com o apoio do Cloud HSM. O serviço de AC também suporta cargas de trabalho regulamentadas, ao passo que a autoridade de certificação da malha de serviços na nuvem não o faz.

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.
  • Os pods do Kubernetes executados no modo privilegiado podem manipular as pilhas de rede e outras capacidades do kernel no anfitrião. O Policy Controller do GKE Enterprise pode ser usado para impedir que os pods executem contentores privilegiados.
  • É possível configurar o 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 que faz implementações de cargas de trabalho tenha 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

  • Análise de contentor. A análise de contentores pode analisar e apresentar vulnerabilidades em cargas de trabalho do GKE.
  • Processamento de CVEs (vulnerabilidades e exposições comuns). Depois de ser descoberta uma vulnerabilidade numa imagem de contentor, os administradores da malha devem corrigir a vulnerabilidade o mais rapidamente possível. Para a malha de serviços na nuvem gerida com o plano de dados gerido, a Google processa automaticamente a aplicação de patches a CVEs que afetam as imagens da 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. O painel de controlo de segurança do GKE Enterprise e a telemetria podem ser usados 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 analisa e visualiza 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

Os dados ou as credenciais de utilizadores confidenciais podem ser vulneráveis a ataques originados de pods ou operações maliciosas se forem armazenados no armazenamento persistente do cluster, como a utilização de segredos do Kubernetes ou diretamente em pods. Também são vulneráveis a ataques de rede se forem transferidas 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.

O que se segue?