Como proteger recursos com o VPC Service Controls

É possível proteger ainda mais os recursos do Compute Engine usando o VPC Service Controls.

O VPC Service Controls permite a definição de um perímetro de segurança para os recursos do Compute Engine. O perímetro de serviço limita a exportação e a importação de recursos e dados associados a eles dentro do perímetro definido.

Ao criar um perímetro de serviço, basta selecionar um ou mais projetos que serão protegidos pelo perímetro. As solicitações entre projetos dentro do mesmo perímetro não são afetadas. Todas as APIs existentes continuarão funcionando, desde que os recursos envolvidos estejam no mesmo perímetro de serviço. Observe que as políticas e os papéis do IAM ainda se aplicam em um perímetro de serviço.

Quando um serviço é protegido por um perímetro, as solicitações não podem ser feitas por dentro do perímetro a qualquer recurso fora dele. Isso inclui a exportação de recursos de dentro para fora do perímetro. É possível fazer solicitações de recursos protegidos fora de um perímetro se elas atenderem a certos critérios. Para mais informações, consulte Visão geral na documentação do VPC Service Controls.

Quando uma solicitação que viola o perímetro de serviço é feita, ela falha com o seguinte erro:

"code": 403, "message": "Request is prohibited by organization's policy."

Benefícios de segurança

O VPC Service Controls oferece os seguintes benefícios de segurança:

  • O acesso a operações confidenciais da API Compute Engine, como a alteração de regras de firewall, pode ser restrito ao acesso privado de redes autorizadas ou para permitir endereços IP listados.
  • Imagens personalizadas e snapshots do disco permanente do Compute Engine podem ser restritos a um perímetro.
  • Os metadados da instância do Compute Engine funcionam como um sistema de armazenamento limitado. O acesso a metadados da instância por meio da API Compute Engine é limitado pela política de perímetro de serviço, reduzindo os riscos de exfiltração usando este canal.

Além disso, a API do Compute Engine agora pode ser acessada no IP virtual restrito (VIP, na sigla em inglês). Isso simplifica a configuração do Cloud DNS e de roteamento para clientes dentro do perímetro que precisam acessar essa API.

Limitações

  • Firewalls hierárquicos não são afetados por perímetros de serviço.
  • As operações de peering de VPC não impõem restrições de perímetro de serviço à VPC.
  • O método da API projects.ListXpnHosts para a VPC compartilhada não impõe restrições de perímetro de serviço aos projetos retornados.

Permissões

Verifique se você tem os papéis adequados para administrar as configurações do perímetro do VPC Service Controls em sua organização.

Configurar um perímetro de serviço

Siga as instruções em Como criar um perímetro de serviço na documentação do VPC Service Controls para configurar um perímetro de serviço.

Se estiver configurando um perímetro de serviço usando a Google Cloud CLI, especifique compute.googleapis.com com a sinalização --restricted-services para restringir a API Compute Engine.

Como adicionar o Compute Engine como um serviço restrito a um perímetro atual

Se você tiver um perímetro de serviço existente e quiser adicionar o Compute Engine a ele, siga as instruções em Como atualizar um perímetro de serviço na documentação do VPC Service Controls.

Como criar uma VM com VPC Service Controls

Depois de configurar um perímetro de serviço, não é necessário alterar as chamadas ou ferramentas de API atuais, desde que os recursos afetados nas solicitações sejam incluídos no mesmo perímetro de serviço. Por exemplo, o comando a seguir cria uma instância de VM com uma imagem de exemplo. Nesse caso, o comando falhará se o IMAGE_PROJECT estiver fora do perímetro de serviço (e não houver ponte do perímetro de serviço entre os projetos).

gcloud compute instances create new-instance \
    --image-family IMAGE_FAMILY --image-project IMAGE_PROJECT \
    --zone us-central1-a --machine-type n1-standard-72

Se você estiver criando uma VM a partir de um modelo de instância, todos os recursos referenciados no modelo precisam pertencer ao mesmo perímetro de serviço em que você está executando o comando ou estar conectados por uma ponte do perímetro de serviço. A solicitação falhará se o modelo de instância se referir a um recurso fora do perímetro de serviço, mesmo que o próprio modelo esteja dentro dele.

Para ver um cenário de exemplo de um cliente do Compute Engine fora do perímetro, criando um disco do Compute Engine fora do perímetro usando uma chave do Cloud KMS dentro do perímetro, consulte Exemplos de solicitações de API permitidas pela combinação de regras de entrada e saída.

Projetos de imagens públicas

O Google fornece e mantém um conjunto de imagens públicas para suas instâncias. Esses projetos são implicitamente incluídos em todos os perímetros de segurança. Nenhuma outra ação é necessária para o uso destas imagens.

Veja a seguir uma lista de projetos que são incluídos automaticamente em todos os perímetros de segurança:

  • centos-cloud
  • cos-cloud
  • debian-cloud
  • fedora-cloud
  • fedora-coreos-cloud
  • rhel-cloud
  • rhel-sap-cloud
  • rocky-linux-cloud
  • opensuse-cloud
  • suse-cloud
  • suse-byos-cloud
  • suse-sap-cloud
  • ubuntu-os-cloud
  • ubuntu-os-pro-cloud
  • windows-cloud
  • windows-sql-cloud

Se você estiver usando um projeto de imagem que não está na lista e escolher não incluir o projeto diretamente no perímetro de segurança, recomendamos fazer uma cópia de todas as imagens que serão usadas em um projeto separado e depois incluí-lo no perímetro de segurança.

Como copiar imagens com o VPC Service Controls

É possível copiar imagens de um projeto para outro se os dois pertencerem ao mesmo perímetro de serviço. Neste exemplo, DST_PROJECT e SRC_PROJECT devem pertencer ao mesmo perímetro de serviço para que a solicitação funcione.

gcloud compute images create --project DST_PROJECT IMAGE_NAME \
   --source-image SOURCE_IMAGE --source-image-project SRC_PROJECT \
    --family IMAGE_FAMILY --storage-location LOCATION

Se você decidir não incluir o projeto de imagem diretamente no perímetro de segurança, recomendamos que primeiro faça uma cópia de todas as imagens que serão usadas em um projeto separado e depois inclua esse projeto no perímetro de segurança.

VPC compartilhada com VPC Service Controls

Ao usar a VPC compartilhada, as restrições do perímetro de serviço se aplicam a todos os projetos envolvidos em uma determinada operação. Ou seja, é necessário garantir que o projeto host e os projetos de serviço estejam dentro do mesmo perímetro de serviço quando uma operação envolver recursos distribuídos entre os projetos host e os de serviço.

Peering de rede VPC

O peering de rede VPC permite que este processo seja feito entre duas organizações independentes. Como um perímetro de serviço é limitado a projetos dentro de uma organização, eles não afetam o peering de redes VPC.

Firewalls hierárquicos

Firewalls hierárquicos são firewalls configurados fora de um projeto, seja na pasta ou no nível da organização. As restrições do perímetro de serviço se aplicam a um conjunto de projetos dentro de um perímetro. Portanto, não se aplica a firewalls hierárquicos.

Grupos de instâncias gerenciadas

Os grupos de instâncias gerenciadas ajudam no gerenciamento de um grupo de instâncias de VM como uma única entidade. Os grupos de instâncias gerenciadas (MIGs, na sigla em inglês) usam modelos de instância para criar VMs, e todas as restrições relacionadas a imagens ou redes e sub-redes de projetos se aplicam. Ou seja, ao usar imagens de outros projetos, verifique se eles pertencem ao mesmo perímetro ou copie as imagens necessárias para outro projeto e inclua esse projeto no perímetro de serviço. Os projetos de imagens públicas mantidos pelo Google são incluídos automaticamente em todos os perímetros de serviço.

Se você quiser usar grupos de instâncias com VPC compartilhada, verifique se seus projetos estão no mesmo perímetro de segurança.

A seguir