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

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 instalar Malha de serviço do Cloud 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 usuários 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 e os 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 fornece controle declarativo sobre o comportamento de 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 no sistema de gerenciamento Malha de serviço do Istio, que permite configurações e topologias sofisticadas. Dependendo da estrutura da sua organização, uma ou mais equipes ou papéis 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. No entanto, em alguns casos, configurações personalizadas ou para conceder exceções excluindo determinados aplicativos, portas ou endereços IP de uma malha. Ter controles para controlar as configurações de malha e as exceções de segurança é importante.

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. Exemplos de tipos de ataque à segurança que podem ameaçar aplicativos em uma malha de serviço incluem:

  • 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 à 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 a seção Gerenciar exceções às políticas com segurança.
  • 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/operações de malha anormal não são atraídos 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 malha de serviço pela integração de vários mecanismos de segurança em diferentes que agregam a segurança geral do sistema sob o modelo modelo de segurança. O diagrama a seguir mostra a proposta do Cloud Service Mesh de segurança da nuvem.

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 o tráfego externo e protege o acesso externo às APIs expostas pelo e 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.
    • Autenticação de usuário do Cloud Service Mesh integra-se à infraestrutura do Google para autenticar chamadas externas desde navegadores da Web até 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.
    • O Cloud Armor pode se proteger contra ataques de negação de serviço (DDoS) distribuídos e ataques de camada 7 externos. Ele serve como um firewall de aplicativos da Web (WAF) para proteger a malha de ataques de rede. Por exemplo, ataques de injeção e de execução de código remoto.
    • 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 AC gerenciada, como a autoridade de certificação do Cloud Service Mesh e o serviço de autoridade de certificação, 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 à malha com base nas identidades e outros atributos deles.
    • 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.
    • A Política de rede do Kubernetes aplica o controle de acesso do pod com base em endereços IP, rótulos de pod, namespaces e muito mais.
    • A segurança do plano de controle protege contra ataques. Essa proteção impede que invasores modifiquem, explorem ou vazem dados de configuração e malha de serviço.
  • 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.
    • 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 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 Google Cloud auditam operações da malha.

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

fluxo de tráfego do diagrama de segurança

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 configurar a versão mínima de TLS para que as conexões TLS entre as cargas de trabalho atendam aos requisitos de e os requisitos de conformidade.

Para mais informações, consulte Cloud Service Mesh por exemplo: mTLS | Como aplicar mTLS em toda a malha.

Ativar controles de acesso

As políticas de segurança do Cloud Service Mesh (como políticas de autenticação e autorização) precisam ser 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 IP. Por exemplo, para estabelecer conexões nativas com serviços não gerenciados pelo Cloud Service Mesh. Para proteger o Cloud Service Mesh nesses 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 eles. 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 proveniente 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. As autenticações baseadas em mTLS ou JSON Web Token (JWT) precisam ser usadas juntas como parte das políticas de autorização do Cloud Service Mesh.

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

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). Autenticação JWT podem ser aplicadas a gateways de entrada para tráfego externo ou a serviços internos para o tráfego em malha. A autenticação JWT pode ser combinada com a autenticação mTLS quando um JWT é usado como credencial para representar o autor da chamada final e a solicitação serviço requer prova de que 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ário 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.

As políticas de autorização do Cloud Service Mesh precisam ser 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, o acesso a um serviço é negado, a menos que uma política de autorização seja explicitamente definida para permitir 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 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 somente um serviço A possa acessar o caminho /admin de um 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 Camada 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, um token em uma solicitação de fora da malha precisa ser trocado por um token interno de malha 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 da malha. Um token de fora da malha pode ter longa duração. Para se proteger contra ataques de repetição de token, um token de fora da malha precisa ser trocado por um token interno da malha 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.

A seguir