Controles para restringir o acesso a APIs aprovadas individualmente

Last reviewed 2024-02-06 UTC

Muitas organizações têm uma exigência de conformidade para restringir o acesso de rede a uma lista explicitamente aprovada de APIs, com base nos requisitos internos ou como parte da adoção de Cargas de trabalho garantidas. No local, esse requisito geralmente é tratado com controles de proxy, mas na sua nuvem privada virtual (VPC) do Google é possível lidar com o recurso Restringir o uso do serviço de recursos Política da organização. Essa política permite que um administrador defina quais recursos do Google Cloud podem ser criados na hierarquia de recursos. No entanto, para usar essa política da organização com eficiência, é necessário alinhar vários controles de rede no ambiente.

Este documento descreve como restringir o acesso a APIs do Google aprovadas individualmente usando o serviço de política da organização e outros controles de rede, bem como os desafios de aplicar a abordagem baseada em proxy local aos serviços do Google Cloud. Este documento é destinado a administradores de rede ou equipes de segurança que querem restringir quais APIs do Google Cloud podem ser alcançadas pelos endpoints da rede VPC.

Desafios com proxies para controle de acesso a APIs do Google

Em uma rede local, sua empresa pode ter um requisito de conformidade para permitir o tráfego de saída apenas para serviços e domínios aprovados. Esse requisito pode ser aplicado filtrando o tráfego de saída por meio de um proxy da Web ou de um gateway de acesso seguro. Esse proxy intercepta todo o tráfego de saída e permite a saída apenas para APIs explicitamente aprovadas.

Em algumas empresas, pode haver um requisito de conformidade para restringir o acesso da rede VPC a APIs aprovadas do Google Cloud. Esse controle de conformidade costuma ser visto nos seguintes cenários:

  • Uma empresa está adotando o Assured Workloads para cargas de trabalho confidenciais e controles de conformidade.
  • Uma empresa tem requisitos de conformidade internos de que os endpoints de rede no Google Cloud só podem acessar as APIs do Google Cloud aprovadas por um processo interno.
  • Uma empresa quer migrar cargas de trabalho de infraestrutura como serviço (IaaS, na sigla em inglês) para o Google Cloud com refatoração mínima.
  • Uma empresa ainda não desenvolveu controles para nuvem e prefere estender os controles atuais do ambiente local.

Sua empresa pode usar um proxy da Web para controlar a saída da rede local para serviços da Web, mas não recomendamos essa abordagem para controlar o acesso da rede VPC às APIs do Google Cloud. O uso dessa abordagem de proxy cria preocupações de escalonabilidade, cria um ponto único de falha e não resolve riscos de exfiltração de dados usando APIs do Google Cloud.

Recomendamos o uso da política da organização Restrict Resource Service Usage em vez de proxies para permitir o acesso seletivo a APIs individuais do Google Cloud. Os desafios relacionados à criação e manutenção de um proxy da Web para controle de acesso a APIs individuais do Google são discutidos nas seções a seguir.

Intervalos de endereços IP compartilhados usados por várias APIs do Google

Não é possível controlar o acesso a uma API individual do Google por uma regra de proxy ou firewall que filtre um único endereço IP. O Google usa um intervalo dinâmico de endereços IP para domínios padrão. Nesses endereços IP, não há uma relação um para um entre um endereço IP dedicado e uma API específica.

Domínios compartilhados usados pelas APIs do Google

Em algumas APIs do Google, não é possível controlar o acesso à rede filtrando o tráfego em domínios. A maioria das APIs do Google pode ser acessada em endpoints que diferenciam APIs específicas por caminho e começam com um URI que começa com www.googleapis.com. Algumas APIs do Google também usam um endpoint com um subdomínio dedicado. Por exemplo, a referência da API Cloud Storage documenta os URIs em relação ao endpoint storage.googleapis.com/storage/v1, mas também é possível usar um URI que começa com www.googleapis.com/storage/v1 para chamar os mesmos métodos de API.

Quando você usa várias APIs que têm apenas endpoints no domínio www.googleapis.com, o proxy de saída não pode distinguir entre as APIs baseadas exclusivamente no domínio. Por exemplo, algumas APIs do Google Cloud, como Deployment Manager, e outras APIs do Google, como Tag Manager ou Google Play Games, só podem ser acessadas no domínio www.googleapis.com. Além disso, todas as APIs do Google Cloud usam a criptografia TLS por padrão. Se você quiser permitir uma dessas APIs, mas bloquear as outras, seu proxy precisará descriptografar a solicitação para filtrar com base no caminho do URI, aumentando a complexidade.

Gargalos causados por proxies

Se todo o tráfego da sua rede VPC para as APIs do Google precisar passar por um proxy de saída, o proxy poderá se tornar um gargalo. Se você usa um proxy de saída para o tráfego da sua rede VPC para as APIs do Google, recomendamos que crie um proxy de alta disponibilidade para evitar interrupção do serviço. Manter e escalonar o proxy podem se tornar ações complexas porque, à medida que sua organização cresce, o proxy pode introduzir um ponto único de falha, latência e capacidade de processamento reduzida. Pode haver um impacto específico nas operações que transferem grandes volumes de dados.

Risco de exfiltração entre serviços

Um proxy da Web pode controlar se uma API do Google é acessível pela sua rede VPC, mas não resolve outros caminhos de exfiltração que usam a API do Google. Por exemplo, um funcionário da sua empresa pode ter privilégios do IAM legítimos para ler buckets internos do Cloud Storage. Com esse privilégio, eles podem ler dados internos e depois copiá-los para um bucket público. O proxy de saída não pode limitar o tráfego entre APIs que não seja proveniente da sua VPC ou limitar como o tráfego da Internet alcança os endpoints públicos das APIs do Google Cloud.

Para dados sensíveis, um perímetro do VPC Service Controls ajuda a atenuar esse tipo de exfiltração. A aplicação de um perímetro do VPC Service Controls ajuda a proteger recursos dentro do perímetro contra políticas do IAM configuradas incorretamente, exfiltração e credenciais comprometidas.

Configurar controles de rede para restringir serviços não aprovados

Ao usar a política da organização de restrição de uso de serviços de recursos para restringir o acesso aos serviços de maneira eficaz, é preciso considerar como a rede VPC restringe o tráfego de saída e os caminhos de exfiltração. As seções a seguir descrevem as práticas recomendadas para que o design de rede use a política da organização de restrição de uso de serviços de recursos de maneira eficiente.

Configurar o VPC Service Controls

Ao usar a política da organização de restrição de uso de serviços de recursos, recomendamos que você também configure o VPC Service Controls. Ao aplicar a política da organização em um projeto, você restringe quais serviços podem ser usados nesse projeto, mas a política da organização não impede que os serviços neste projeto se comuniquem com serviços em outros projetos. Em comparação, o VPC Service Controls permite que você defina um perímetro para evitar a comunicação com serviços fora do perímetro.

Por exemplo, se você definir uma política da organização para permitir apenas o Compute Engine e bloquear o Cloud Storage no seu projeto, uma VM nesse projeto não poderá criar ou se comunicar com um bucket do Cloud Storage no projeto. No entanto, como a VM pode fazer solicitações a um bucket do Cloud Storage em outro projeto, a exfiltração do serviço do Cloud Storage ainda é possível. Para bloquear a comunicação com o Cloud Storage ou outros Serviços do Google fora do perímetro, é preciso configurar um perímetro do VPC Service Controls.

Use esses controles juntos para permitir seletivamente os serviços aprovados no seu ambiente e bloquear uma variedade de caminhos de exfiltração para serviços não aprovados.

Remover caminhos para a Internet

Se os recursos na sua rede VPC puderem se comunicar diretamente com a Internet, talvez haja um caminho alternativo para APIs não aprovadas do Google e outros serviços que você quer bloquear. Portanto, recomendamos que você use apenas endereços IP internos nas suas VMs e não permita rotas de saída por meio de uma solução NAT ou de proxy. A política da organização de restrição de uso de serviços de recursos não minimiza os caminhos de exfiltração para a Internet pública, portanto, os serviços não aprovados ainda podem ser acessados indiretamente em um servidor fora do ambiente.

Configurar um endpoint particular para acesso à API

Para controlar os endpoints da API na sua rede, recomendamos o acesso às APIs do Google usando o Private Service Connect. Quando você configura o Acesso privado do Google para permitir que VMs com apenas IP interno acessem as APIs do Google, isso inclui acesso a todas as APIs do Google, incluindo as não compatíveis com o VPC Service Controls ou a Política da organização de Restrição de Uso do Serviço de Recursos. É possível restringir o Acesso privado do Google apenas às APIs compatíveis, configurando também o Private Service Connect com o pacote vpc-sc.

Por exemplo, ativar o Acesso privado do Google permite um caminho de rede particular para todas as APIs do Google, como Google Drive ou Plataforma Google Maps. Um funcionário pode copiar dados para o Google Drive pessoal de uma instância do Compute Engine usando a API do Google Drive. Evite esse caminho de exfiltração configurando o Private Service Connect com o pacote vpc-sc para fornecer acesso ao mesmo conjunto de serviços compatíveis com o IP virtual restrito (VIP, na sigla em inglês) no endpoint restricted.googleapis.com. Em comparação, um conjunto mais amplo de APIs do Google pode ser alcançado usando o Acesso privado do Google quando você usa os domínios padrão do Google, um endpoint do Private Service Connect configurado com pacote all-apis ou o VIP particular (private.googleapis.com).

Como alternativa, é possível configurar rotas para restricted.googleapis.com. Você pode usar o VIP restrito se não quiser criar um endpoint do Private Service Connect para cada região e cada rede VPC no seu ambiente. No entanto, recomendamos a abordagem do Private Service Connect, porque é possível criar um endpoint interno para sua rede VPC em comparação com a abordagem VIP restrita, que exige uma rota para um endpoint anunciado publicamente.

A seguir