Configurar um perímetro do VPC Service Controls para uma rede de nuvem privada virtual

Saiba como configurar um perímetro de serviço usando o VPC Service Controls. Neste tutorial, usamos configurações de rede, como firewalls, Private Service Connect e configurações de DNS, que são necessárias para usar um perímetro do VPC Service Controls de maneira eficaz. Em seguida, você verá como os serviços são permitidos ou negados e como criar exceções granulares para uma lista de permissões de serviços específicos.

Objetivos

  • Configurar um perímetro do VPC Service Controls com outros controles de rede para reduzir os caminhos de exfiltração.
  • Permita ou negue o acesso a serviços dentro do perímetro a partir de solicitações originadas de dentro ou fora do perímetro.
  • Permita ou negue o acesso a serviços fora do perímetro a partir de solicitações originadas no perímetro.
  • Use a política da organização Restrict Resource Service Usage e o VPC Service Controls juntos.

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Saiba mais em Limpeza.

Antes de começar

  1. Este tutorial requer um projeto na sua organização. Se você ainda não tem uma organização do Google Cloud, consulte Como criar e gerenciar uma organização.

  2. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  3. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  4. Ative as APIs Compute Engine, Access Context Manager e Cloud DNS .

    Ative as APIs

  5. No Console do Google Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

  6. Verifique se você tem os seguintes papéis na organização: Access Context Manager Admin, Organization Policy Administrator

    Verificar os papéis

    1. No console do Google Cloud, abra a página IAM.

      Acessar IAM
    2. Selecionar uma organização.

    3. Na coluna Principal, encontre a linha que contém seu endereço de e-mail.

      Caso seu endereço de e-mail não esteja nessa coluna, isso significa que você não tem papéis.

    4. Na coluna Papel da linha com seu endereço de e-mail, verifique se a lista de papéis inclui os papéis necessários.

    Conceder os papéis

    1. No console do Google Cloud, abra a página IAM.

      Acesse o IAM
    2. Selecionar uma organização.
    3. Clique em CONCEDER ACESSO.
    4. No campo Novos participantes, digite seu endereço de e-mail.
    5. Na lista Selecionar um papel, escolha um.
    6. Para conceder outros papéis, clique em Adicionar outro papel e adicione cada papel adicional.
    7. Clique em Save.

  7. Verifique se você tem os seguintes papéis no projeto: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor

    Verificar os papéis

    1. No console do Google Cloud, abra a página IAM.

      Acessar IAM
    2. Selecionar um projeto.

    3. Na coluna Principal, encontre a linha que contém seu endereço de e-mail.

      Caso seu endereço de e-mail não esteja nessa coluna, isso significa que você não tem papéis.

    4. Na coluna Papel da linha com seu endereço de e-mail, verifique se a lista de papéis inclui os papéis necessários.

    Conceder os papéis

    1. No console do Google Cloud, abra a página IAM.

      Acesse o IAM
    2. Selecionar um projeto.
    3. Clique em CONCEDER ACESSO.
    4. No campo Novos participantes, digite seu endereço de e-mail.
    5. Na lista Selecionar um papel, escolha um.
    6. Para conceder outros papéis, clique em Adicionar outro papel e adicione cada papel adicional.
    7. Clique em Save.

Configurar o perímetro do VPC Service Controls

Para implementar um perímetro do VPC Service Controls em uma rede VPC, você precisa implementar controles de rede que negam o tráfego para serviços externos. As seções a seguir detalham as configurações de rede que você precisa implementar em redes VPC dentro do perímetro e um exemplo de configuração de perímetro.

Prepare sua rede VPC

Nesta seção, você vai configurar a conectividade particular com as APIs e os serviços do Google para sua rede VPC para reduzir um intervalo de caminhos de saída da rede para a Internet.

  1. No Cloud Shell, defina as variáveis:

    gcloud config set project PROJECT_ID
gcloud config set compute/region REGION
gcloud config set compute/zone ZONE

    Substitua:

    • PROJECT_ID: o ID do projeto em que você criará recursos.
    • REGION: uma região próxima ao seu local, por exemplo, us-central1.
    • ZONE: uma zona próxima da sua localização. Por exemplo, us-central1-a.

  2. Crie uma rede VPC e uma sub-rede com o Acesso privado do Google ativado:

    gcloud compute networks create restricted-vpc --subnet-mode=custom
gcloud compute networks subnets create restricted-subnet \
--range=10.0.0.0/24 \
--network=restricted-vpc \
--enable-private-ip-google-access

  3. Crie um endpoint do Private Service Connect e uma regra de encaminhamento configurada para usar o pacote vpc-sc:

    gcloud compute addresses create restricted-psc-endpoint \
--global \
--purpose=PRIVATE_SERVICE_CONNECT \
--addresses=10.0.1.1 \
--network=restricted-vpc

gcloud compute forwarding-rules create restrictedpsc \
--global \
--network=restricted-vpc \
--address=restricted-psc-endpoint \
--target-google-apis-bundle=vpc-sc

  4. Configure a política do servidor Cloud DNS para redirecionar consultas das APIs do Google Cloud para o endpoint do Private Service Connect:

    gcloud dns managed-zones create restricted-dns-zone \
  --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \
  --dns-name="googleapis.com." \
  --networks=restricted-vpc \
  --visibility=private

gcloud dns record-sets create googleapis.com  \
--rrdatas=10.0.1.1 \
--type=A \
--ttl=300 \
--zone=restricted-dns-zone

gcloud dns record-sets create *.googleapis.com  \
--rrdatas="googleapis.com." \
--type=CNAME \
--ttl=300 \
--zone=restricted-dns-zone

  5. Configure uma regra de firewall com prioridade baixa para negar todo o tráfego de saída:

    gcloud compute firewall-rules create deny-all-egress \
--priority=65534 \
--direction=egress \
--network=restricted-vpc \
--action=DENY \
--rules=all \
--destination-ranges=0.0.0.0/0

  6. Configure uma regra de firewall com prioridade mais alta para permitir que o tráfego alcance o endereço IP usado pelo endpoint do Private Service Connect:

    gcloud compute firewall-rules create allow-psc-for-google-apis \
--priority=1000 \
--direction=egress \
--network=restricted-vpc \
--action=ALLOW \
--rules=tcp:443 \
--destination-ranges=10.0.1.1

    Essas regras de firewall negam a saída de modo abrangente antes de permitir seletivamente a saída para o endpoint do Private Service Connect. Essa configuração nega o tráfego de saída para domínios padrão que normalmente podem ser acessados por padrão com o Acesso privado do Google e a regras de firewall implícitas (em inglês).

Criar um perímetro do VPC Service Controls

Nesta seção, você cria um perímetro do VPC Service Controls.

  1. No Cloud Shell, crie uma política de acesso como um pré-requisito para gerar um perímetro do VPC Service Controls:

    gcloud access-context-manager policies create \
--organization=ORGANIZATION_ID --title "Access policy at organization node"

    O resultado será assim:

    "Create request issued
Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."

    Só pode haver um contêiner de política de acesso no nó da organização. Se uma política já tiver sido criada na sua organização, a saída será semelhante a esta:

    "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"

    Se essa mensagem aparecer, continue para a próxima etapa.

  2. Criar um perímetro do VPC Service Controls que restrinja os serviços do Cloud Storage e do Compute Engine.

    export POLICY_ID=$(gcloud access-context-manager policies list \
--organization=ORGANIZATION_ID \
--format="value(name)")

gcloud access-context-manager perimeters create demo_perimeter \
--title="demo_perimeter" \
--resources=projects/$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") \
--restricted-services="storage.googleapis.com,compute.googleapis.com" \
--enable-vpc-accessible-services \
--policy=$POLICY_ID \
--vpc-allowed-services="RESTRICTED-SERVICES"

Verificar os serviços permitidos do tráfego fora do perímetro

As seções a seguir demonstram como o perímetro do VPC Service Controls permite ou nega acesso a solicitações feitas fora dele. Além disso, mostra como permitir seletivamente a entrada para serviços configurando níveis de acesso e políticas de entrada.

Para simular o tráfego de fora do perímetro, é possível executar comandos no Cloud Shell. O Cloud Shell é um recurso fora do seu projeto e perímetro. O perímetro permite ou nega solicitações, mesmo que elas tenham privilégios suficientes do Identity and Access Management.

Neste tutorial, usamos a API Compute Engine, a API Cloud Storage e a API Cloud Resource Manager, mas os mesmos conceitos também se aplicam a outros serviços.

Verificar se o perímetro nega tráfego externo a serviços restritos

Nesta seção, você verifica se o perímetro nega tráfego externo para serviços restritos.

Diagrama arquitetônico que ilustra como um perímetro do VPC Service Controls nega acesso a serviços restritos

O diagrama anterior ilustra como um cliente autorizado tem acesso negado aos serviços dentro do perímetro configurado como restrito, mas o cliente tem acesso permitido aos serviços que você não configurou como restrito.

Nas etapas a seguir, verifique esse conceito usando o Cloud Shell para tentar criar uma VM na sua rede VPC, que falha devido à configuração do perímetro do VPC Service Controls.

  1. No Cloud Shell, execute o seguinte comando para criar uma VM dentro da rede VPC.

    gcloud compute instances create demo-vm \
    --machine-type=e2-micro \
    --subnet=restricted-subnet \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --no-address

    O resultado será assim:

    "ERROR: (gcloud.compute.instances.create) Could not fetch resource:
- Request is prohibited by organization's policy."

    A solicitação falha porque o Cloud Shell está fora do perímetro e o Compute Engine está configurado com a sinalização --restricted-services.

  2. No Cloud Shell, execute o seguinte comando para acessar o serviço do Resource Manager, que não está configurado na sinalização --restricted-services.

    gcloud projects describe PROJECT_ID

    Uma resposta bem-sucedida retorna os detalhes do projeto. Essa resposta demonstra que o perímetro permite tráfego externo para a API Cloud Resource Manager.

    Você demonstrou que o perímetro nega tráfego externo a serviços configurados no --restricted-services e permite o tráfego externo para serviços não configurados explicitamente em --restricted-services.

As seções a seguir apresentam padrões de exceção para alcançar serviços restritos dentro do perímetro.

Verificar se um nível de acesso permite uma exceção ao perímetro

Nesta seção, você verifica se um nível de acesso permite uma exceção ao perímetro. Um nível de acesso é útil quando você quer criar uma exceção para que o tráfego externo acesse todos os serviços restritos dentro do perímetro e não precise de exceções granulares para cada serviço ou outros atributos.

Diagrama arquitetônico que ilustra como um nível de acesso concede uma exceção a todos os serviços dentro do perímetro do VPC Service Controls

O diagrama anterior ilustra como um nível de acesso permite que um cliente autorizado acesse todos os serviços restritos dentro do perímetro.

Nas etapas a seguir, verifique esse conceito criando um nível de acesso e, em seguida, fazendo uma solicitação bem-sucedida para o serviço do Compute Engine. Essa solicitação é permitida mesmo que você tenha configurado o Compute Engine como restrito.

  1. No Cloud Shell, crie um arquivo YAML que descreva a configuração de um nível de acesso e aplique-o ao perímetro. Esta amostra cria um nível de acesso para a identidade do usuário que você está usando no momento para executar o tutorial.

    export USERNAME=$(gcloud config list account --format "value(core.account)")

cat <<EOF > user_spec.yaml
- members:
  - user:$USERNAME
EOF

    gcloud access-context-manager levels create single_user_level \
--title="single-user access level" \
--basic-level-spec=user_spec.yaml \
--policy=$POLICY_ID

gcloud access-context-manager perimeters update demo_perimeter \
--add-access-levels=single_user_level \
--policy=$POLICY_ID

  2. No Cloud Shell, execute o seguinte comando novamente para tentar criar uma VM:

    gcloud compute instances create demo-vm \
--machine-type=e2-micro \
--subnet=restricted-subnet \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--no-address

    Desta vez, a solicitação funciona. O perímetro impede que o tráfego externo use os serviços restritos, mas o nível de acesso configurado permite uma exceção.

Verificar se uma política de entrada permite uma exceção granular para o perímetro

Nesta seção, você verifica se uma política de entrada permite uma exceção granular ao perímetro Em comparação com o nível de acesso de alta granularidade, uma política de entrada mais refinada pode configurar atributos adicionais sobre a origem do tráfego e permitir o acesso a serviços ou métodos individuais

Diagrama de arquitetura que ilustra como uma política de entrada permite que uma exceção granular alcance serviços especificados dentro do perímetro

O diagrama anterior ilustra como uma política de entrada permite que um cliente autorizado acesse apenas um serviço especificado dentro do perímetro, sem permitir acesso a outros serviços restritos.

Nas etapas a seguir, verifique esse conceito substituindo o nível de acesso por uma política de entrada que permita que um cliente autorizado acesse apenas o serviço do Compute Engine, mas não permita o acesso a outros serviços restritos.

  1. Na guia do Cloud Shell, execute o seguinte comando para remover o nível de acesso.

    gcloud access-context-manager perimeters update demo_perimeter \
--policy=$POLICY_ID \
--clear-access-levels

  2. Na guia do Cloud Shell, crie uma política de entrada que permita que a identidade do usuário entre apenas no serviço do Compute Engine e aplique a política ao perímetro.

    cat <<EOF > ingress_spec.yaml
- ingressFrom:
    identities:
    - user:$USERNAME
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - methodSelectors:
      - method: '*'
      serviceName: compute.googleapis.com
    resources:
    - '*'
EOF

    gcloud access-context-manager perimeters update demo_perimeter \
--set-ingress-policies=ingress_spec.yaml \
--policy=$POLICY_ID

  3. Na guia do Cloud Shell, execute o comando a seguir para criar um bucket do Cloud Storage dentro do perímetro.

    gcloud storage buckets create gs://PROJECT_ID-01

    O resultado será assim:

    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."

    O Cloud Shell é um cliente fora do perímetro. Por isso, o perímetro do VPC Service Controls impede que o Cloud Shell se comunique com serviços restritos dentro do perímetro.

  4. Na guia do Cloud Shell, execute o comando a seguir para fazer uma solicitação ao serviço do Compute Engine dentro do perímetro.

    gcloud compute instances describe demo-vm --zone=ZONE

    Uma resposta bem-sucedida retorna os detalhes de demo-vm. Essa resposta demonstra que o perímetro permite o tráfego externo que atende às condições da política de entrada para o serviço do Compute Engine.

Verificar os serviços permitidos do tráfego dentro do perímetro

Nas seções a seguir, demonstramos como o perímetro do VPC Service Controls permite ou nega solicitações para serviços de dentro do perímetro. Além disso, mostramos como é possível selecionar seletivamente a saída para serviços externos por políticas de saída.

Para demonstrar a diferença entre o tráfego dentro e fora do perímetro, as seções a seguir usam o Cloud Shell fora do perímetro e uma instância do Compute Engine criada dentro dele. Os comandos executados na sessão SSH na instância do Compute Engine dentro do perímetro usam a identidade da conta de serviço anexada, enquanto os comandos executados no Cloud Shell fora do perímetro usam sua própria identidade. Ao seguir a configuração recomendada para o tutorial, o perímetro permite ou nega solicitações, mesmo que elas tenham privilégios do IAM suficientes para sucesso.

Neste tutorial, usamos a API Compute Engine, a API Cloud Storage e a API Cloud Resource Manager, mas os mesmos conceitos também se aplicam a outros serviços.

Verificar se o perímetro permite o tráfego interno para serviços restritos dentro do perímetro

Nesta seção, você verifica se o perímetro permite o tráfego de endpoints de rede dentro do perímetro se o serviço também estiver configurado em serviços acessíveis por VPC.

Diagrama de arquitetura que ilustra como a configuração de vpc-Accessibility-services permite que os serviços sejam acessados de endpoints de rede internos

O diagrama anterior ilustra como um perímetro permite que o tráfego de endpoints de rede dentro do perímetro alcance serviços restritos que você também configurou como serviços acessíveis por VPC. Os serviços que você não configurou como acessíveis por VPC não podem ser acessados de endpoints de rede dentro do perímetro.

Nas etapas a seguir, você verifica esse conceito estabelecendo uma conexão SSH com a instância do Compute Engine dentro do perímetro e fazendo solicitações a serviços.

  1. No Cloud Shell, crie uma regra de firewall que permita o tráfego SSH para sua rede VPC, permitindo a entrada do intervalo de endereços IP 35.235.240.0/20 que é usado pelo serviço IAP para encaminhamento de TCP:

    gcloud compute firewall-rules create demo-allow-ssh \
--direction=INGRESS \
--priority=1000 \
--network=restricted-vpc \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20

  2. Inicie uma sessão SSH com esta instância:

    gcloud compute ssh demo-vm --zone=ZONE

    Verifique se você se conectou à instância demo-vm confirmando que o prompt da linha de comando foi alterado para mostrar o nome do host da sua instância:

    username@demo-vm:~$

    Se o comando anterior falhar, talvez você veja uma mensagem de erro semelhante a esta:

    "[/usr/bin/ssh] exited with return code [255]"

    Nesse caso, a inicialização da instância do Compute Engine pode não ter sido concluída. Aguarde um minuto e tente novamente.

  3. Na sessão SSH dentro do perímetro, verifique os serviços permitidos internamente usando um serviço do Google Cloud configurado na lista de permissões de serviços acessíveis pela VPC. Por exemplo, tente qualquer comando usando o serviço do Compute Engine.

    gcloud compute instances describe demo-vm --zone=ZONE

    Uma resposta bem-sucedida retorna os detalhes de demo-vm. Essa resposta demonstra que o perímetro permite o tráfego interno para a API Compute Engine.

  4. Na sessão SSH dentro do perímetro, verifique se os serviços não incluídos na lista de permissões dos serviços acessíveis por VPC não são permitidos na VM. Por exemplo, o comando a seguir usa o serviço Resource Manager, que não está configurado na lista de permissões de serviços acessíveis da VPC.

    gcloud projects describe PROJECT_ID

    O resultado será assim:

    "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."

    Sua instância do Compute Engine e outros endpoints de rede só podem solicitar serviços configurados na lista de permissões de serviços acessíveis pela VPC. No entanto, o tráfego de recursos ou serviços sem servidor originado de fora do perímetro poderá solicitar esse serviço. Se você quiser impedir que um serviço seja usado no projeto, consulte a Política de uso de recursos do serviço restrito.

Verificar se o perímetro nega tráfego interno a serviços restritos fora do perímetro

Nesta seção, você verifica se o perímetro bloqueia a comunicação de serviços dentro do perímetro com serviços do Google Cloud fora dele.

Diagrama de arquitetura que ilustra como um perímetro do VPC Service Controls nega acesso do tráfego dentro do perímetro a serviços restritos fora dele

O diagrama anterior ilustra como o tráfego interno não pode se comunicar com serviços restritos fora do perímetro.

Nas etapas a seguir, você verifica esse conceito tentando enviar o tráfego interno para um serviço restrito dentro do perímetro e para um serviço restrito fora dele.

  1. Na sessão SSH dentro do perímetro, execute o comando a seguir para criar um bucket de armazenamento dentro do perímetro. Esse comando funciona porque o serviço do Cloud Storage está configurado em restricted-services e accessible-services.

    gcloud storage buckets create gs://PROJECT_ID-02

    Uma resposta bem-sucedida cria o bucket de armazenamento. Essa resposta demonstra que o perímetro permite o tráfego interno para o serviço do Cloud Storage.

  2. Na sessão SSH dentro do perímetro, execute o comando a seguir para ler um bucket que está fora do perímetro. Esse bucket público permite permissão somente leitura para allUsers, mas o perímetro nega o tráfego de dentro do perímetro para um serviço restrito fora dele.

    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

    O resultado será assim:

    "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited
by organization's policy."

    Essa resposta demonstra que é possível usar serviços restritos dentro do perímetro, mas um recurso dentro do perímetro não pode se comunicar com serviços restritos fora do perímetro.

Verificar se uma política de saída permite uma exceção ao perímetro

Nesta seção, você vai verificar se uma política de saída permite uma exceção no perímetro.

Diagrama de arquitetura que ilustra como uma política de saída permite que exceções específicas alcancem um serviço restrito fora do perímetro

O diagrama anterior ilustra como o tráfego interno pode se comunicar com um recurso externo específico quando você concede uma exceção restrita com a política de saída.

Nas etapas a seguir, verifique esse conceito criando uma política de saída e acessando um bucket público do Cloud Storage fora do perímetro permitido pela política de saída.

  1. Para abrir uma nova sessão do Cloud Shell, clique em abrir uma nova guia no Cloud Shell. Nas etapas subsequentes, você alterna entre a primeira guia com a sessão SSH dentro do perímetro e a segunda guia no Cloud Shell fora do perímetro em que o prompt de linha de comando começa com username@cloudshell.

  2. Na guia do Cloud Shell, crie uma política de saída que permita a saída da identidade da conta de serviço anexada de demo-vm usando o método google.storage.objects.get para um bucket público em um projeto externo. Atualize o perímetro com a política de saída.

    export POLICY_ID=$(gcloud access-context-manager policies list \
--organization=ORGANIZATION_ID \
--format="value(name)")

export SERVICE_ACCOUNT_EMAIL=$(gcloud compute instances describe demo-vm \
--zone=ZONE) \
--format="value(serviceAccounts.email)"

    cat <<EOF > egress_spec.yaml
- egressFrom:
    identities:
      - serviceAccount:$SERVICE_ACCOUNT_EMAIL
  egressTo:
    operations:
    - methodSelectors:
      - method: 'google.storage.objects.get'
      serviceName: storage.googleapis.com
    resources:
    - projects/950403849117
EOF

    gcloud access-context-manager perimeters update demo_perimeter \
--set-egress-policies=egress_spec.yaml \
--policy=$POLICY_ID

  3. Volte para a guia com a sessão SSH para a VM no perímetro, em que o prompt de linha de comando começa com username@demo-vm.

  4. Na sessão SSH dentro do perímetro, faça outra solicitação para o bucket do Cloud Storage e verifique se ele funciona.

    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

    O resultado será assim:

    "Hello world!
This is a sample file in Cloud Storage that is viewable to allUsers."

    Essa resposta demonstra que o perímetro e a política de saída permitem o tráfego interno de uma identidade específica para um bucket específico do Cloud Storage.

  5. Na sessão SSH no perímetro, também é possível testar outros métodos que não eram explicitamente permitidos pela exceção da política de saída. Por exemplo, o comando a seguir requer a permissão google.storage.buckets.list, que é negada pelo perímetro.

    gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*

    O resultado será assim:

    "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."

    Essa resposta demonstra que seu perímetro nega tráfego interno da listagem de objetos no bucket externo, indicando que a política de saída permite métodos explicitamente especificados.

Para mais referências sobre padrões comuns para compartilhar dados fora do perímetro de serviço, consulte Troca de dados segura com regras de entrada e saída.

(Opcional) Configurar a política de Uso de recursos de serviço restrito

Talvez você também tenha requisitos internos ou de compliance para permitir que apenas APIs aprovadas individualmente sejam usadas no seu ambiente. Nesse caso, também é possível configurar o serviço de política da organização Restricted Service Resource Usage. Ao aplicar a política da organização em um projeto, você restringe quais serviços podem ser criados nele. No entanto, 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. As etapas a seguir mostram como implementar e testar esse cenário:

  1. Alterne para a guia do Cloud Shell, em que o prompt de linha de comando começa com username@cloudshell.

  2. Na guia do Cloud Shell, crie um arquivo YAML descrevendo o serviço de políticas da organização que permitirá apenas o uso do serviço do Compute Engine. Ele também negará todos os outros serviços e, em seguida, o aplicará ao projeto.

    cat <<EOF > allowed_services_policy.yaml
constraint: constraints/gcp.restrictServiceUsage
listPolicy:
  allowedValues:
  - compute.googleapis.com
  inheritFromParent: true
EOF

    gcloud resource-manager org-policies set-policy allowed_services_policy.yaml \
--project=PROJECT_ID

  3. Volte para a guia com a sessão SSH para a VM no perímetro, em que o prompt de linha de comando começa com username@demo-vm.

  4. Na sessão SSH dentro do perímetro, execute o seguinte comando para ver o mesmo bucket de armazenamento que você criou no projeto.

    gcloud storage buckets describe gs://PROJECT_ID

    O resultado será assim:

    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."

    Esta resposta demonstra que o Serviço de políticas da organização nega o serviço do Cloud Storage no projeto, independentemente da configuração do perímetro.

  5. Na sessão SSH dentro do perímetro, execute o comando a seguir para ver um bucket de armazenamento fora do perímetro permitido pela política de saída.

    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

    O resultado será assim:

    "Hello world!
This is a sample file in Cloud Storage that is viewable to allUsers."

    Uma resposta bem-sucedida retorna o conteúdo de helloworld.txt no bucket de armazenamento externo. Essa resposta demonstra que sua política de perímetro e saída permite que o tráfego interno alcance um bucket de armazenamento externo sob determinadas condições limitadas, mas o serviço de política da organização nega o serviço do Cloud Storage no projeto, independentemente da configuração de seu perímetro. Serviços fora do projeto ainda podem ser usados para exfiltração se forem permitidos pelo perímetro, independentemente do Serviço de política da Organização do uso de recursos do Serviço restrito.

    Para negar a comunicação com o Cloud Storage ou outros serviços do Google fora do perímetro, o Serviço de política da organização de Uso de recursos restritos não é suficiente. É preciso configurar um Perímetro do VPC Service Controls. O VPC Service Controls reduz os caminhos de exfiltração de dados, e o Restricted Service Resource Usage é um controle de conformidade para evitar a criação de serviços não aprovados no ambiente. Use esses controles juntos para bloquear uma série de caminhos de exfiltração e permitir seletivamente serviços aprovados para uso interno no seu ambiente.

Limpar

Exclua um projeto do Google Cloud:

gcloud projects delete PROJECT_ID

O perímetro do VPC Service Controls não gere custos adicionais, mas ele precisa ser limpo para evitar acúmulo e recursos não utilizados na organização.

  1. No seletor de projetos na parte superior do console do Google Cloud, escolha a organização usada durante este tutorial.

  2. No console do Google Cloud, acesse a página VPC Service Controls.

    Acessar o VPC Service Controls

  3. Na lista de perímetros, selecione o perímetro que você quer excluir e clique em Excluir.

  4. Na caixa de diálogo, clique em Excluir novamente para confirmar a exclusão.

A seguir