Visão geral da segurança do Cloud Service Mesh

O Cloud Service Mesh com a segurança de APIs do Istio ajuda você a reduzir as ameaças de pessoas com informações privilegiadas e reduzir o risco de violação de dados, garantindo que todas as comunicações entre cargas de trabalho são criptografados, mutuamente autenticados e autorizados.

Tradicionalmente, a microssegmentação que usa regras baseadas em IP tem sido usada para reduzir riscos de pessoas com informações privilegiadas. No entanto, a adoção de contêineres, serviços compartilhados e ambientes de produção distribuídos por várias nuvens torna essa abordagem mais difícil de configurar e ainda mais difícil de manter.

Com o Cloud Service Mesh, é possível configurar uma camada de serviços baseada no contexto e solicita segurança de rede independente da segurança da rede. Por isso, O Cloud Service Mesh permite que você adote uma postura de defesa em profundidade consistentes com os princípios de segurança Confiança Zero. Ele permite que você faça isso usando políticas declarativas e sem modificar o código do aplicativo.

TLS mútuo

O Cloud Service Mesh usa TLS mútuo (mTLS) para autenticação de peering. Autenticação se refere à identidade: quem é o serviço? quem é esse usuário final? e posso ter certeza de que eles são quem dizem ser?

O mTLS possibilita que as cargas de trabalho verifiquem as identidades umas das outras e e façam autenticações umas das outras. Talvez você esteja familiarizado com o TLS simples pelo seu uso em HTTPS para permitir que os navegadores confiem em servidores da Web e criptografem os dados que são trocados. Quando o TLS simples é usado, o cliente estabelece que o servidor é confiável ao validar o certificado. O mTLS é uma implementação de TLS em que o cliente e o servidor apresentam certificados um para o outro e verificam as identidades umas das outras.

Com o mTLS, o Cloud Service Mesh implementa autenticação e criptografia entre serviços.

No Cloud Service Mesh, o mTLS automático é ativado por padrão. Com o mTLS automático, uma O proxy sidecar do cliente detecta automaticamente se o servidor tem um sidecar. O o arquivo secundário do cliente envia mTLS para cargas de trabalho com arquivos secundários e envia texto simples para cargas de trabalho sem sidecars. No entanto, os serviços aceitam o tráfego de texto simples e mTLS. Para proteger sua malha de serviço, recomendamos que você migre seus serviços para aceitar apenas o tráfego mTLS.

Para mais informações sobre como aplicar apenas mTLS, consulte Cloud Service Mesh, por exemplo: mTLS

Benefícios de segurança

O Cloud Service Mesh oferece os seguintes benefícios de segurança:

  • Reduz os riscos de ataques de reprodução ou de falsificação de identidade que usam credenciais roubadas. O Cloud Service Mesh depende de certificados mTLS para autenticam pares, em vez de tokens do portador, como JSON Web Tokens (JWT). Como os certificados mTLS estão vinculados ao canal TLS, não é possível uma entidade em seu ambiente de produção para se passar por outra Repetir o token de autenticação sem acesso às chaves privadas.

  • Garante a criptografia em trânsito. O uso do mTLS para autenticação também garante que todas as comunicações TCP sejam criptografadas em trânsito.

  • Garante que apenas clientes autorizados possam acessar um serviço com dados confidenciais. Apenas os clientes autorizados podem acessar um serviço com dados confidenciais, independentemente do local da rede do cliente e das credenciais no nível do aplicativo. É possível especificar que apenas os clientes com identidades de serviço autorizadas ou nos namespaces autorizados do Kubernetes podem acessar um serviço. Você também podem usar políticas de acesso baseadas em IP para conceder acesso aos clientes fora dos clientes fora da malha.

  • Reduz o risco de violação de dados do usuário na rede de produção. É possível garantir que as pessoas com acesso só possam acessar dados confidenciais por meio de clientes autorizados. Além disso, é possível garantir que determinados clientes só tenham acesso aos dados do usuário se o cliente puder apresentar um token de usuário válido e de curta duração. Isso reduz o risco de que o comprometimento de uma única credencial do cliente concede a um invasor acesso a todos os dados do usuário.

  • Identifica quais clientes acessaram um serviço com dados confidenciais. A geração de registros de acesso do Cloud Service Mesh captura a identidade mTLS da além do endereço IP. Assim, é possível entender em qual carga de trabalho acessado um serviço, mesmo que a carga de trabalho seja efêmera e dinâmica implantados e em outro cluster ou rede de nuvem privada virtual (VPC).

Recursos

Nesta seção, descrevemos os recursos que o Cloud Service Mesh oferece para e perceber os benefícios de segurança.

Certificado automático e rotação de chaves

O uso do mTLS com base nas identidades de serviço permite criptografar todas as comunicações TCP e fornece uma credencial não reproduzível mais segura para controle de acesso. Um dos principais desafios do uso do mTLS em escala é o gerenciamento das chaves e dos certificados de todas as cargas de trabalho de destino. O Cloud Service Mesh cuida da rotação de chaves e certificados mTLS para cargas de trabalho da malha sem interrupções comunicações. Para reduzir os riscos, é possível definir intervalos menores de atualização de certificado.

Autoridade de certificação do Cloud Service Mesh

O Cloud Service Mesh inclui uma rede privada multirregional autoridade certificadora, autoridade de certificação do Cloud Service Mesh, para emitir certificados para mTLS. A autoridade certificadora do Cloud Service Mesh é um serviço altamente confiável e escalonável que é otimizado para cargas de trabalho escalonadas dinamicamente em uma plataforma de nuvem. Com Autoridade certificadora do Cloud Service Mesh, o Google gerencia a segurança e a disponibilidade dos back-end da AC. A autoridade de certificação do Cloud Service Mesh permite que você use uma única raiz de confiança entre clusters. Ao usar a autoridade certificadora do Cloud Service Mesh, você pode confiar na carga de trabalho pools de identidade para fornecer isolamento de alta granularidade. Por padrão, a autenticação falhará se o cliente e o servidor não estiverem no mesmo pool de identidades da carga de trabalho.

Os certificados da autoridade de certificação do Cloud Service Mesh incluem os seguintes dados sobre serviços do seu aplicativo:

  • O ID do projeto do Google Cloud
  • O namespace do GKE
  • O nome da conta de serviço do GKE
.

Certificate Authority Service

Como alternativa à autoridade certificadora do Cloud Service Mesh, é possível configurar Cloud Service Mesh para usar o Certificate Authority Service, que é adequado para os seguintes casos de uso:

  • Se você precisar de autoridades certificadoras diferentes para assinar certificados de carga de trabalho em clusters diversos.
  • Se você precisar fazer backup das chaves de assinatura em um HSM gerenciado.
  • sua empresa é altamente regulada e está sujeita a conformidade.
  • Se você quiser encadear sua CA do Cloud Service Mesh a uma certificado raiz empresarial para assinar certificados de carga de trabalho.

O custo da autoridade certificadora do Cloud Service Mesh está incluído no Preços do Cloud Service Mesh. O custo do CA Service não é incluído no preço base do Cloud Service Mesh e cobrado separadamente. Além disso, o CA Service vem com um SLA explícito, mas a autoridade certificadora do Cloud Service Mesh não.

Para essa integração, todas as cargas de trabalho no Cloud Service Mesh recebem dois Papéis do IAM:

Políticas de controle de acesso baseadas na identidade (firewall)

Com o Cloud Service Mesh, você pode configurar políticas de segurança de rede baseados na identidade mTLS em comparação com o endereço IP do terminal. Isso permite crie políticas independentes do local da rede da carga de trabalho. Só há suporte para comunicações entre clusters no mesmo projeto do Google Cloud.

Solicitar políticas de controle de acesso com base em declarações (firewall)

Além da identidade mTLS, é possível conceder acesso com base nas declarações de solicitação no cabeçalho do JWT de solicitações HTTP ou gRPC. O Cloud Service Mesh permite declarar que um JWT é assinado por uma entidade confiável. Isso significa que é possível configurar políticas que permitam o acesso de determinados clientes apenas se uma solicitação declaração existe ou corresponde a um valor especificado.

Autenticação de usuário com o Identity-Aware Proxy

Você autentica os usuários que acessam qualquer serviço exposto em um o gateway de entrada do Cloud Service Mesh usando Identity-Aware Proxy (IAP): O IAP pode autenticar usuários que fazem login em um navegador, fazer a integração com provedores de identidade personalizados e emitir um token JWT de curta duração ou um RCToken que poderá ser usado para conceder acesso no gateway de entrada ou em um serviço downstream (com um arquivo secundário). Para mais informações, consulte Como integrar o IAP com o Cloud Service Mesh

Autenticação de usuários com o Identity Provider atual

É possível integrar seu provedor de identidade atual ao Cloud Service Mesh para autenticação de usuário final baseada em navegador e controle de acesso para seus cargas de trabalho implantadas. Para mais informações, consulte Como configurar a autenticação de usuário do Cloud Service Mesh.

Geração de registros e monitoramento de acesso

O Cloud Service Mesh garante que as métricas e os registros de acesso estejam disponíveis Google Cloud Observability e fornece um painel integrado para entender os padrões de acesso de um serviço ou carga de trabalho com base nesses dados.

Em conformidade com o FIPS

O componente do plano de dados usa Criptografia validada pelo FIPS 140-2 módulos.

Limitações

A segurança do Cloud Service Mesh tem as seguintes limitações:

  • A autenticação do usuário que usa o IAP exige que um serviço seja publicado na Internet. IAP e Cloud Service Mesh permitem configurar políticas que restringem o acesso a usuários autorizados e clientes em um intervalo de IP permitido. Se você optar por expor o serviço apenas a na mesma rede, é preciso configurar um mecanismo de política para autenticação de usuário e emissão de token.

A seguir