Para proteger ainda mais os recursos do Compute Engine, você pode protegê-los usando o VPC Service Controls .
O VPC Service Controls permite definir um perímetro de segurança para os recursos do Compute Engine. O perímetro de serviço limita a exportação e importação de recursos e seus dados associados dentro do perímetro definido.
Ao criar um perímetro de serviço, você seleciona um ou mais projetos a serem protegidos pelo perímetro. As solicitações entre projetos dentro do mesmo perímetro permanecem inalteradas. Todas as APIs existentes continuam a funcionar enquanto os recursos envolvidos estiverem dentro do mesmo perímetro de serviço. Observe que as funções e políticas do IAM ainda se aplicam dentro de um perímetro de serviço.
Quando um serviço é protegido por um perímetro, as solicitações não podem ser feitas pelo serviço dentro do perímetro para nenhum recurso fora do perímetro. Isto inclui exportar recursos de dentro para fora do perímetro. Solicitações de recursos protegidos de fora de um perímetro são possíveis se atenderem a determinados critérios. Para obter mais informações, consulte Visão geral na documentação do VPC Service Controls .
Quando é feita uma solicitação que viola o perímetro de serviço, a solicitação 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 alteração de regras de firewall, pode ser restrito ao acesso privado de redes autorizadas ou a endereços IP permitidos.
- Os snapshots de disco permanente e as imagens personalizadas do Compute Engine podem ser restritos a um perímetro.
- Os metadados da instância do Compute Engine atuam como um sistema de armazenamento limitado. O acesso aos metadados da instância por meio da API Compute Engine é limitado pela política de perímetro de serviço, mitigando os riscos de exfiltração usando esse canal.
Além disso, a API Compute Engine agora está acessível no IP virtual restrito (VIP) . Isso simplifica o Cloud DNS e a configuração de roteamento 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 impõem restrições de perímetro de serviço de VPC.
- O método de API
projects.ListXpnHosts
para VPC compartilhada não impõe restrições de perímetro de serviço em projetos retornados.
Permissões
Certifique-se de ter as funções adequadas para administrar as configurações do perímetro do VPC Service Controls para sua organização.
Configurar um perímetro de serviço
Siga as instruções em Criando 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 CLI do Google Cloud, especifique compute.googleapis.com
com a sinalização --restricted-services
para restringir a API Compute Engine.
Adicionar o Compute Engine como um serviço restrito a um perímetro existente
Se você 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.
Criando uma VM com VPC Service Controls
Depois de configurar um perímetro de serviço, não será necessário fazer alterações nas chamadas de API ou nas ferramentas existentes, desde que os recursos afetados nas suas solicitações estejam 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 IMAGE_PROJECT
estiver fora do perímetro de serviço (e não houver ponte de 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 de instância deverão pertencer ao mesmo perímetro de serviço onde você está executando o comando ou estar conectados usando uma ponte de 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 de instância esteja dentro do perímetro.
Para ver um exemplo de cenário 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 imagem pública
O Google fornece e mantém um conjunto de imagens públicas para suas instâncias. Estes projetos estão implicitamente incluídos em todos os perímetros de segurança. Nenhuma ação adicional é necessária para usar essas imagens.
A seguir está 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á nesta lista e optar por não incluir o projeto de imagem diretamente em seu perímetro de segurança, recomendamos que você faça primeiro uma cópia de todas as imagens a serem usadas em um projeto separado e, em seguida, inclua o projeto separado em seu perímetro de segurança.
Copiar imagens com VPC Service Controls
Você poderá 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
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ê optar por não incluir o projeto de imagem diretamente em seu perímetro de segurança, recomendamos que você faça primeiro uma cópia de todas as imagens a serem usadas em um projeto separado e, em seguida, inclua o projeto separado em seu perímetro de segurança.
VPC compartilhada com VPC Service Controls
Ao usar a VPC compartilhada, as restrições de perímetro de serviço serão aplicadas a todos os projetos envolvidos em uma determinada operação. Em outras palavras, recomendamos que você certifique-se de 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 de serviço.
Peering de rede VPC
O peering de rede VPC permite peering de redes VPC entre duas organizações separadas. Como um perímetro de serviço é limitado a projetos dentro de uma organização, os perímetros de serviço não afetam redes VPC de peering.
Firewalls hierárquicos
Firewalls hierárquicos são firewalls configurados fora de um projeto (na pasta ou no nível da organização). As restrições de perímetro de serviço aplicam-se a um conjunto de projetos dentro de um perímetro, portanto não se aplicam a firewalls hierárquicos.
Grupos de instâncias gerenciadas
Os grupos de instâncias gerenciadas ajudam você a gerenciar um grupo de instâncias de VM como uma entidade única. Os grupos de instâncias gerenciadas (MIGs) usam modelos de instância para criar VMs, e todas as restrições relacionadas a imagens ou redes e sub-redes entre projetos se aplicam. Ou seja, ao utilizar imagens de outros projetos, certifique-se de que os projetos 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 imagem pública 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, certifique-se de que seus projetos estejam no mesmo perímetro de segurança.
O que vem a seguir
- Saiba mais sobre o VPC Service Controls .
- Saiba mais sobre os serviços suportados por IPs virtuais restritos .
- Leia mais sobre as etapas de configuração do perímetro de serviço . ,
Para proteger ainda mais os recursos do Compute Engine, você pode protegê-los usando o VPC Service Controls .
O VPC Service Controls permite definir um perímetro de segurança para os recursos do Compute Engine. O perímetro de serviço limita a exportação e importação de recursos e seus dados associados dentro do perímetro definido.
Ao criar um perímetro de serviço, você seleciona um ou mais projetos a serem protegidos pelo perímetro. As solicitações entre projetos dentro do mesmo perímetro permanecem inalteradas. Todas as APIs existentes continuam a funcionar enquanto os recursos envolvidos estiverem dentro do mesmo perímetro de serviço. Observe que as funções e políticas do IAM ainda se aplicam dentro de um perímetro de serviço.
Quando um serviço é protegido por um perímetro, as solicitações não podem ser feitas pelo serviço dentro do perímetro para nenhum recurso fora do perímetro. Isto inclui exportar recursos de dentro para fora do perímetro. Solicitações de recursos protegidos de fora de um perímetro são possíveis se atenderem a determinados critérios. Para obter mais informações, consulte Visão geral na documentação do VPC Service Controls .
Quando é feita uma solicitação que viola o perímetro de serviço, a solicitação 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 alteração de regras de firewall, pode ser restrito ao acesso privado de redes autorizadas ou a endereços IP permitidos.
- Os snapshots de disco permanente e as imagens personalizadas do Compute Engine podem ser restritos a um perímetro.
- Os metadados da instância do Compute Engine atuam como um sistema de armazenamento limitado. O acesso aos metadados da instância por meio da API Compute Engine é limitado pela política de perímetro de serviço, mitigando os riscos de exfiltração usando esse canal.
Além disso, a API Compute Engine agora está acessível no IP virtual restrito (VIP) . Isso simplifica o Cloud DNS e a configuração de roteamento 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 impõem restrições de perímetro de serviço de VPC.
- O método de API
projects.ListXpnHosts
para VPC compartilhada não impõe restrições de perímetro de serviço em projetos retornados.
Permissões
Certifique-se de ter as funções adequadas para administrar as configurações do perímetro do VPC Service Controls para sua organização.
Configurar um perímetro de serviço
Siga as instruções em Criando 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 CLI do Google Cloud, especifique
compute.googleapis.com
com a sinalização--restricted-services
para restringir a API Compute Engine.Adicionar o Compute Engine como um serviço restrito a um perímetro existente
Se você 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.
Criando uma VM com VPC Service Controls
Depois de configurar um perímetro de serviço, não será necessário fazer alterações nas chamadas de API ou nas ferramentas existentes, desde que os recursos afetados nas suas solicitações estejam 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
IMAGE_PROJECT
estiver fora do perímetro de serviço (e não houver ponte de 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 de instância deverão pertencer ao mesmo perímetro de serviço onde você está executando o comando ou estar conectados usando uma ponte de 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 de instância esteja dentro do perímetro.
Para ver um exemplo de cenário 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 imagem pública
O Google fornece e mantém um conjunto de imagens públicas para suas instâncias. Estes projetos estão implicitamente incluídos em todos os perímetros de segurança. Nenhuma ação adicional é necessária para usar essas imagens.
A seguir está 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á nesta lista e optar por não incluir o projeto de imagem diretamente em seu perímetro de segurança, recomendamos que você faça primeiro uma cópia de todas as imagens a serem usadas em um projeto separado e, em seguida, inclua o projeto separado em seu perímetro de segurança.
Copiar imagens com VPC Service Controls
Você poderá copiar imagens de um projeto para outro se ambos os projetos pertencerem ao mesmo perímetro de serviço. Neste exemplo,
DST_PROJECT
eSRC_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ê optar por não incluir o projeto de imagem diretamente em seu perímetro de segurança, recomendamos que você faça primeiro uma cópia de todas as imagens a serem usadas em um projeto separado e, em seguida, inclua o projeto separado em seu perímetro de segurança.
VPC compartilhada com VPC Service Controls
Ao usar a VPC compartilhada, as restrições de perímetro de serviço serão aplicadas a todos os projetos envolvidos em uma determinada operação. Em outras palavras, recomendamos que você certifique-se de 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 de serviço.
Peering de rede VPC
O peering de rede VPC permite peering de redes VPC entre duas organizações separadas. Como um perímetro de serviço é limitado a projetos dentro de uma organização, os perímetros de serviço não afetam redes VPC de peering.
Firewalls hierárquicos
Firewalls hierárquicos são firewalls configurados fora de um projeto (na pasta ou no nível da organização). As restrições de perímetro de serviço aplicam-se a um conjunto de projetos dentro de um perímetro, portanto não se aplicam a firewalls hierárquicos.
Grupos de instâncias gerenciadas
Os grupos de instâncias gerenciadas ajudam você a gerenciar um grupo de instâncias de VM como uma entidade única. Os grupos de instâncias gerenciadas (MIGs) usam modelos de instância para criar VMs, e todas as restrições relacionadas a imagens ou redes e sub-redes entre projetos se aplicam. Ou seja, ao utilizar imagens de outros projetos, certifique-se de que os projetos 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 imagem pública 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, certifique-se de que seus projetos estejam no mesmo perímetro de segurança.
O que vem a seguir
- Saiba mais sobre o VPC Service Controls .
- Saiba mais sobre os serviços suportados por IPs virtuais restritos .
- Leia mais sobre as etapas de configuração do perímetro de serviço .