Proteger recursos com os VPC Service Controls

Para proteger ainda mais os seus recursos do Compute Engine, pode protegê-los com os VPC Service Controls.

Os VPC Service Controls permitem-lhe definir um perímetro de serviço para os seus recursos do Compute Engine. O perímetro de serviço limita a exportação e a importação de recursos e os respetivos dados associados ao perímetro definido.

Quando cria um perímetro de serviço, seleciona um ou mais projetos a serem protegidos pelo perímetro. Os pedidos entre projetos dentro do mesmo perímetro permanecem inalterados. Todas as APIs existentes continuam a funcionar desde que os recursos envolvidos estejam dentro do mesmo perímetro de serviço. Tenha em atenção que as políticas e as funções do IAM continuam a aplicar-se num perímetro de serviço.

Quando um serviço está protegido por um perímetro, os pedidos não podem ser feitos pelo serviço no interior do perímetro a nenhum recurso no exterior do perímetro. Isto inclui a exportação de recursos de dentro para fora do perímetro. Os pedidos de recursos protegidos fora de um perímetro são possíveis se cumprirem determinados critérios. Para mais informações, consulte a vista geral na documentação dos VPC Service Controls.

Quando é feito um pedido que viola o perímetro de serviço, o pedido falha com o seguinte erro:

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

Vantagens de segurança

Os VPC Service Controls oferecem as seguintes vantagens de segurança:

  • O acesso a operações da API Compute Engine confidenciais, como a alteração de regras de firewall, pode ser restrito ao acesso privado a partir de redes autorizadas ou a endereços IP que fazem parte de uma lista de autorizações.
  • Os instantâneos de discos persistentes e as imagens personalizadas do Compute Engine podem ser restringidos a um perímetro.
  • Os metadados de instâncias do Compute Engine atuam como um sistema de armazenamento limitado. O acesso aos metadados da instância através da API Compute Engine está limitado pela política de perímetro de serviço, o que mitiga os riscos de exfiltração através deste canal.

Além disso, a API Compute Engine já está acessível no IP virtual (VIP) restrito. Isto simplifica a configuração do DNS e do encaminhamento na nuvem para clientes dentro do perímetro que precisam de acesso a esta API.

Limitações

  • Os firewalls hierárquicos não são afetados pelos perímetros de serviço.
  • As operações de peering de VPC não aplicam restrições de perímetro de serviço de VPC.
  • O método da API projects.ListXpnHosts para a VPC partilhada não aplica restrições de perímetro de serviço aos projetos devolvidos.

Autorizações

Certifique-se de que tem as funções adequadas para administrar as configurações do perímetro do VPC Service Controls para a sua organização.

Configure um perímetro de serviço

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

Se configurar um perímetro de serviço através da CLI do Google Cloud, especifique compute.googleapis.com com a flag --restricted-services para restringir a API Compute Engine.

Adicionar o Compute Engine como um serviço restrito a um perímetro existente

Se tiver um perímetro de serviço existente e quiser adicionar o Compute Engine ao perímetro de serviço, siga as instruções em Atualizar um perímetro de serviço na documentação do VPC Service Controls.

Criar uma VM com os VPC Service Controls

Depois de configurar um perímetro de serviço, não tem de fazer alterações às chamadas de API nem às ferramentas existentes, desde que os recursos afetados nos seus pedidos estejam incluídos no mesmo perímetro de serviço. Por exemplo, o comando seguinte cria uma instância de VM com uma imagem de exemplo. Neste caso, o comando falha se o IMAGE_PROJECT estiver fora do perímetro de serviço (e não existir uma 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 estiver a criar uma VM a partir de um modelo de instância, todos os recursos referenciados no modelo de instância têm de pertencer ao mesmo perímetro de serviço onde está a executar o comando ou estar ligados através de uma ponte de perímetro de serviço. O pedido falha se o modelo de instância fizer referência a um recurso fora do perímetro do serviço, mesmo que o próprio modelo de instância esteja dentro do perímetro.

Para ver um cenário de exemplo de um cliente do Compute Engine fora do perímetro a criar um disco do Compute Engine fora do perímetro com uma chave do Cloud KMS dentro do perímetro, consulte os Exemplos de pedidos de API permitidos pela combinação de regras de entrada e saída.

Projetos de imagens públicas

Todos os projetos de imagens apresentados na página Detalhes do SO são incluídos automaticamente em todos os perímetros de serviço. Além disso, as imagens projetadas para o Fedora Cloud, openSUSE e HPC OS também são incluídas automaticamente.

Se estiver a usar projetos de imagens que não estão incluídos no seu perímetro de serviço e não quiser adicioná-los diretamente, recomendamos que copie estes projetos de imagens para um projeto separado. Em seguida, pode adicionar esse projeto ao seu perímetro de serviço.

Copiar imagens com os VPC Service Controls

Pode copiar imagens de um projeto para outro se ambos os projetos pertencerem ao mesmo perímetro de serviço. Neste exemplo, DST_PROJECT e SRC_PROJECT têm de pertencer ao mesmo perímetro de serviço para que o pedido 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 optar por não incluir o projeto de imagens diretamente no seu perímetro de segurança, recomendamos que faça primeiro uma cópia de todas as imagens a usar num projeto separado e, em seguida, inclua o projeto separado no seu perímetro de segurança.

VPC partilhada com VPC Service Controls

Quando usa a VPC partilhada, as restrições do perímetro de serviço aplicam-se a todos os projetos envolvidos numa determinada operação. Por outras palavras, recomendamos que se certifique de que o projeto anfitrião e os projetos de serviço estão dentro do mesmo perímetro de serviço quando uma operação envolve recursos distribuídos entre o projeto anfitrião e os projetos de serviço.

Intercâmbio de redes da VPC

O intercâmbio da rede da VPC permite o intercâmbio de redes da VPC entre duas organizações separadas. Uma vez que um perímetro de serviço está limitado a projetos numa organização, os perímetros de serviço não afetam as redes VPC com intercâmbio.

Firewalls hierárquicas

As firewalls hierárquicas são firewalls configuradas fora de um projeto (ao nível da pasta ou da organização). As restrições do perímetro de serviço não se aplicam a firewalls hierárquicos.

Grupos de instâncias geridas

Os grupos de instâncias geridas ajudam a gerir um grupo de instâncias de VM como uma única entidade. Os grupos de instâncias geridos (MIGs) usam modelos de instâncias para criar VMs, e aplicam-se todas as restrições relativas a imagens ou redes e sub-redes entre projetos. Ou seja, quando usar imagens de outros projetos, certifique-se de que os projetos pertencem ao mesmo perímetro ou copie as imagens de que precisa para outro projeto e inclua esse projeto no perímetro de serviço. Os projetos de imagens públicas mantidos pela Google são incluídos automaticamente em todos os perímetros de serviço.

Se quiser usar grupos de instâncias com a VPC partilhada, certifique-se de que os seus projetos estão no mesmo perímetro de serviço.

O que se segue?