Configure um perímetro dos VPC Service Controls para uma rede da nuvem privada virtual

Saiba como configurar um perímetro de serviço com os VPC Service Controls. Este tutorial usa definições de rede, como firewalls, o Private Service Connect e configurações de DNS, que são necessárias para usar um perímetro do VPC Service Controls de forma eficaz. Este tutorial demonstra como os serviços são permitidos ou recusados e como criar exceções detalhadas para uma lista de autorizações de serviços específicos.

Objetivos

  • Configure um perímetro dos VPC Service Controls com controlos de rede adicionais para mitigar caminhos de exfiltração.
  • Permitir ou recusar o acesso a serviços dentro do perímetro a partir de pedidos que tenham origem dentro do perímetro ou fora do perímetro.
  • Permitir ou negar o acesso a serviços fora do perímetro a partir de pedidos que têm origem dentro do perímetro.
  • Use a política da organização Restrict Resource Service Usage e os VPC Service Controls em conjunto.

Custos

Este tutorial usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Quando terminar este tutorial, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

  1. Este tutorial requer um projeto na sua organização. Se ainda não tiver uma organização, consulte o artigo Criar e gerir uma organização. Google Cloud

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  5. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  6. Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator

    Check for the roles

    1. In the Google Cloud console, go to the IAM page.

      Go to IAM
    2. Select the organization.

    3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

    4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

    Grant the roles

    1. In the Google Cloud console, go to the IAM page.

      Aceder ao IAM

    2. Selecione a organização.
    3. Clique em Conceder acesso.

    4. No campo Novos responsáveis, introduza o identificador do utilizador. Normalmente, este é o endereço de email de uma Conta Google.

    5. Na lista Selecionar uma função, selecione uma função.
    6. Para conceder funções adicionais, clique em Adicionar outra função e adicione cada função adicional.
    7. Clique em Guardar.

    8. Make sure that you have the following role or roles on the project: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor

      Check for the roles

      1. In the Google Cloud console, go to the IAM page.

        Go to IAM
      2. Select the project.

      3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

      4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

      Grant the roles

      1. In the Google Cloud console, go to the IAM page.

        Aceder ao IAM

      2. Selecione o projeto.
      3. Clique em Conceder acesso.

      4. No campo Novos responsáveis, introduza o identificador do utilizador. Normalmente, este é o endereço de email de uma Conta Google.

      5. Na lista Selecionar uma função, selecione uma função.
      6. Para conceder funções adicionais, clique em Adicionar outra função e adicione cada função adicional.
      7. Clique em Guardar.

        8. Configure o perímetro do VPC Service Controls

        Para implementar um perímetro do VPC Service Controls para uma rede VPC, tem de implementar controlos de rede que neguem o tráfego para serviços externos. As secções seguintes detalham as configurações de rede que tem de implementar nas redes VPC dentro do seu perímetro e um exemplo de configuração do perímetro.

        Prepare a sua rede de VPC

        Nesta secção, configura a conetividade privada às APIs e aos serviços Google para a sua rede VPC mitigar uma série de caminhos de saída de 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 o seguinte:

          • PROJECT_ID: o ID do projeto onde vai criar recursos
          • REGION: uma região próxima da sua localização, 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 à 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 ponto final 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 do Cloud DNS para redirecionar as consultas para as APIs Google Cloud para o seu ponto final 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 uma 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 uma prioridade mais elevada para permitir que o tráfego alcance o endereço IP usado pelo seu ponto final 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

          Estas regras de firewall negam a saída de forma geral, antes de permitir seletivamente a saída para o ponto final do Private Service Connect. Esta configuração nega o tráfego de saída para os domínios predefinidos que normalmente são acessíveis por predefinição com o acesso privado à Google e as regras de firewall implícitas.

        Crie um perímetro dos VPC Service Controls

        Nesta secção, cria um perímetro dos VPC Service Controls.

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

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

          O resultado é semelhante ao seguinte:

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

          Só pode existir um contentor de políticas de acesso no nó da organização. Se já tiver sido criada uma política na sua organização, o resultado é semelhante ao seguinte:

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

          Se vir esta mensagem, avance para o passo seguinte.

        2. Crie um perímetro dos VPC Service Controls que restrinja os serviços do Cloud Storage e 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"

        Valide os serviços permitidos a partir de tráfego fora do seu perímetro

        As secções seguintes demonstram como o perímetro do VPC Service Controls permite ou nega o acesso a pedidos feitos a partir do exterior do perímetro e como pode permitir seletivamente a entrada nos serviços configurando níveis de acesso e políticas de entrada.

        Para simular tráfego de fora do seu perímetro, pode executar comandos no Cloud Shell. O Cloud Shell é um recurso fora do seu próprio projeto e perímetro. O perímetro permite ou recusa pedidos, mesmo que os pedidos tenham privilégios de gestão de identidade e de acesso suficientes para serem bem-sucedidos.

        Este tutorial usa 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.

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

        Nesta secção, verifica se o perímetro nega o tráfego externo a serviços restritos.

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

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

        Nos passos seguintes, vai validar este conceito através do Cloud Shell para tentar criar uma VM na sua rede VPC, o que falha devido à configuração do perímetro dos VPC Service Controls.

        1. No Cloud Shell, execute o seguinte comando para criar uma VM na sua 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 é semelhante ao seguinte:

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

          O pedido falha porque o Cloud Shell está fora do seu perímetro e o Compute Engine está configurado com a flag --restricted-services.

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

          gcloud projects describe PROJECT_ID

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

          Demonstrou que o perímetro nega o tráfego externo aos serviços configurados em --restricted-services e permite o tráfego externo aos serviços não configurados explicitamente em --restricted-services.

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

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

        Nesta secção, verifica se um nível de acesso permite uma exceção ao perímetro. Um nível de acesso é útil quando quer criar uma exceção para o tráfego externo aceder a todos os serviços restritos no interior do perímetro e não precisa de exceções detalhadas para cada serviço ou outros atributos.

        Diagrama de arquitetura que ilustra como um nível de acesso concede uma exceção a todos os serviços no interior do perímetro do VPC Service Controls

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

        Nos passos seguintes, vai validar este conceito criando um nível de acesso e, em seguida, fazendo um pedido bem-sucedido ao serviço Compute Engine. Este pedido é permitido mesmo que tenha configurado o Compute Engine como restrito.

        1. No Cloud Shell, crie um ficheiro YAML que descreva a configuração de um nível de acesso e aplique-o ao seu perímetro. Este exemplo cria um nível de acesso para a identidade do utilizador que está a usar atualmente 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 novamente o seguinte comando 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, o pedido funciona. O seu perímetro impede que o tráfego externo use os serviços restritos, mas o nível de acesso que configurou permite uma exceção.

        Verifique se uma política de entrada permite uma exceção detalhada ao perímetro

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

        Diagrama arquitetónico que ilustra como uma política de entrada permite que uma exceção detalhada alcance serviços especificados dentro do perímetro

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

        Nos passos seguintes, vai validar este conceito substituindo o nível de acesso por uma política de entrada que permite a um cliente autorizado aceder apenas ao serviço Compute Engine, mas não permite o acesso a outros serviços restritos.

        1. No separador 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. No separador do Cloud Shell, crie uma política de entrada que permita que a identidade do utilizador entre no serviço Compute Engine apenas e aplique a política ao seu 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. No separador Cloud Shell, execute o seguinte comando para criar um contentor do Cloud Storage dentro do perímetro.

          gcloud storage buckets create gs://PROJECT_ID-01

          O resultado é semelhante ao seguinte:

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

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

        4. No separador do Cloud Shell, execute o seguinte comando para fazer um pedido ao serviço Compute Engine dentro do perímetro.

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

          Uma resposta bem-sucedida devolve os detalhes de demo-vm. Esta resposta demonstra que o seu perímetro permite tráfego externo que cumpre as condições da sua política de entrada no serviço Compute Engine.

        Valide os serviços permitidos a partir do tráfego dentro do seu perímetro

        As secções seguintes demonstram como o perímetro do VPC Service Controls permite ou nega pedidos a serviços a partir do interior do perímetro e como pode permitir seletivamente a saída para serviços externos através de políticas de saída.

        Para demonstrar a diferença entre o tráfego dentro e fora do perímetro, as secções seguintes usam o Cloud Shell fora do perímetro e uma instância do Compute Engine que cria dentro do perímetro. Os comandos que executa a partir da 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 a partir do Cloud Shell fora do perímetro usam a sua própria identidade. Quando segue a configuração recomendada para o tutorial, o perímetro permite ou nega pedidos, mesmo que os pedidos tenham privilégios de IAM suficientes para ser bem-sucedidos.

        Este tutorial usa 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.

        Verifique se o perímetro permite tráfego interno para serviços restritos no interior do perímetro

        Nesta secção, verifica se o perímetro permite o tráfego de pontos finais de rede no interior do perímetro se o serviço também estiver configurado nos serviços acessíveis da VPC.

        Diagrama arquitetónico que ilustra como a configuração de vpc-accessible-services permite que os serviços sejam alcançados a partir dos pontos finais da sua rede interna

        O diagrama anterior ilustra como um perímetro permite que o tráfego de pontos finais de rede dentro do perímetro alcance serviços restritos que também configurou como serviços acessíveis através da VPC. Não é possível aceder aos serviços que não configurou como serviços acessíveis por VPC a partir de pontos finais de rede dentro do perímetro.

        Nos passos seguintes, vai validar este conceito estabelecendo uma ligação SSH à instância do Compute Engine dentro do perímetro e, em seguida, fazendo pedidos aos serviços.

        1. No Cloud Shell, crie uma regra de firewall que permita o tráfego SSH para a sua rede VPC, permitindo a entrada do intervalo de endereços IP 35.235.240.0/20 usado pelo serviço IAP para encaminhamento 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 para esta instância:

          gcloud compute ssh demo-vm --zone=ZONE

          Verifique se estabeleceu ligação com êxito à instância demo-vm confirmando que o comando de linha de comandos foi alterado para mostrar o nome do anfitrião da sua instância:

          username@demo-vm:~$

          Se o comando anterior falhar, pode ver uma mensagem de erro semelhante à seguinte:

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

          Neste caso, a instância do Compute Engine pode não ter concluído o arranque. Aguarde um minuto e, em seguida, tente novamente.

        3. A partir da sessão SSH no seu perímetro, valide os serviços que o perímetro permite internamente através de um Google Cloud serviço que está configurado na lista de autorizações de serviços acessíveis da VPC. Por exemplo, experimente qualquer comando com o serviço Compute Engine.

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

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

        4. A partir da sessão SSH no interior do seu perímetro, verifique se os serviços não incluídos na lista de autorização de serviços acessíveis da VPC não são permitidos a partir da sua VM. Por exemplo, o seguinte comando 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 é semelhante ao seguinte:

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

          A sua instância do Compute Engine e outros pontos finais de rede só podem pedir serviços que estejam configurados na lista de autorizações de serviços acessíveis da VPC. No entanto, os recursos sem servidor ou o tráfego de serviços proveniente de fora do seu perímetro podem pedir esse serviço. Se quiser impedir a utilização de um serviço no seu projeto, consulte a Política de Utilização de Recursos de Serviços Restritos.

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

        Nesta secção, verifica se o perímetro bloqueia a comunicação dos serviços no interior do perímetro para os serviços no exterior do perímetro. Google Cloud

        Diagrama arquitetónico que ilustra como um perímetro do VPC Service Controls nega o acesso do tráfego no interior do perímetro a serviços restritos no exterior do perímetro

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

        Nos passos seguintes, vai validar este conceito tentando enviar tráfego interno para um serviço restrito dentro do perímetro e para um serviço restrito fora do perímetro.

        1. A partir da sessão SSH no interior do seu perímetro, execute o seguinte comando para criar um contentor de armazenamento no interior do seu perímetro. Este comando funciona porque o serviço Cloud Storage está configurado em restricted-services e accessible-services.

          gcloud storage buckets create gs://PROJECT_ID-02

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

        2. A partir da sessão SSH no interior do seu perímetro, execute o seguinte comando para ler a partir de um contentor que está fora do seu perímetro. Este contentor público permite autorização de leitura apenas a allUsers, mas o perímetro nega o tráfego do interior do seu perímetro para um serviço restrito fora do perímetro.

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

          O resultado é semelhante ao seguinte:

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

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

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

        Nesta secção, verifica se uma política de saída permite uma exceção ao perímetro.

        Diagrama arquitetónico 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 comunicar com um recurso externo específico quando concede uma exceção restrita com a política de saída.

        Nos passos seguintes, vai validar este conceito criando uma política de saída e, em seguida, acedendo a um contentor do Cloud Storage público fora do perímetro permitido pela política de saída.

        1. Abra uma nova sessão do Cloud Shell clicando em abrir um novo separador no Cloud Shell. Nos passos seguintes, alterna entre o primeiro separador com a sessão SSH dentro do seu perímetro e o segundo separador no Cloud Shell fora do seu perímetro, onde o comando começa com username@cloudshell.

        2. No separador 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 através do método google.storage.objects.get para um contentor público num 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. Regresse ao separador com a sessão SSH para a VM dentro do seu perímetro, onde o comando de linha começa com username@demo-vm.

        4. A partir da sessão SSH no interior do seu perímetro, faça outro pedido ao contentor do Cloud Storage e verifique se funciona.

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

          O resultado é semelhante ao seguinte:

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

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

        5. A partir da sessão SSH no interior do seu perímetro, também pode testar outros métodos que não foram explicitamente permitidos pela exceção da política de saída. Por exemplo, o seguinte comando requer a autorização google.storage.buckets.list, que é recusada pelo seu perímetro.

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

          O resultado é semelhante ao seguinte:

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

          Esta resposta demonstra que o seu perímetro nega o tráfego interno de objetos de listagem no contentor externo, o que indica que a política de saída permite estritamente métodos especificados explicitamente.

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

        (Opcional) Configure a política de utilização de recursos de serviços restritos

        Também pode ter requisitos internos ou de conformidade para permitir a utilização apenas de APIs aprovadas individualmente no seu ambiente. Neste caso, também pode configurar o Restricted Service Resource Usage Organization Policy Service. Ao aplicar a política de organização num projeto, restringe os serviços que podem ser criados nesse projeto. No entanto, a política de organização não impede que os serviços neste projeto comuniquem com serviços noutros projetos. Em comparação, o VPC Service Controls permite-lhe definir um perímetro para impedir a comunicação com serviços fora do perímetro.

        Por exemplo, se definir uma política de organização para permitir o Compute Engine e negar o Cloud Storage no seu projeto, uma VM neste projeto não pode criar um contentor do Cloud Storage no seu projeto. No entanto, a VM pode fazer pedidos a um contentor do Cloud Storage noutro projeto, pelo que a exfiltração com o serviço Cloud Storage continua a ser possível. Os passos seguintes mostram como implementar e testar este cenário:

        1. Mude para o separador Cloud Shell, onde o pedido de linha de comandos começa com username@cloudshell.

        2. No separador do Cloud Shell, crie um ficheiro YAML que descreva o serviço de políticas de organização que só permite a utilização do serviço Compute Engine e nega todos os outros serviços. Em seguida, aplique-o ao seu 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. Regresse ao separador com a sessão SSH para a VM dentro do seu perímetro, onde o comando de linha começa com username@demo-vm.

        4. A partir da sessão SSH no interior do seu perímetro, execute o seguinte comando para ver o mesmo contentor de armazenamento que criou anteriormente neste projeto.

          gcloud storage buckets describe gs://PROJECT_ID

          O resultado é semelhante ao seguinte:

          "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 Cloud Storage no seu projeto, independentemente da configuração do seu perímetro.

        5. A partir da sessão SSH dentro do seu perímetro, execute o seguinte comando para ver um contentor de armazenamento fora do perímetro que é permitido pela sua política de saída.

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

          O resultado é semelhante ao seguinte:

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

          Uma resposta bem-sucedida devolve o conteúdo de helloworld.txt no contentor de armazenamento externo. Esta resposta demonstra que a sua política de perímetro e de saída permite que o tráfego interno alcance um contentor de armazenamento externo em determinadas condições limitadas, mas o serviço de política da organização nega o serviço do Cloud Storage no seu projeto, independentemente da configuração do seu perímetro. Os serviços fora do seu projeto podem continuar a ser usados para exfiltração se forem permitidos pelo seu perímetro, independentemente do serviço de política de organização de utilização de recursos de serviços restritos.

          Para negar a comunicação com o Cloud Storage ou outros serviços Google fora do perímetro, a política da organização de utilização de recursos de serviços restritos não é suficiente. Tem de configurar um perímetro do VPC Service Controls. O VPC Service Controls mitiga os caminhos de exfiltração de dados e a utilização de recursos de serviços restritos é um controlo de conformidade para impedir a criação de serviços não aprovados no seu ambiente. Use estes controlos em conjunto para bloquear uma série de caminhos de exfiltração e permitir seletivamente serviços aprovados para utilização interna no seu ambiente.

        Limpar

      8. In the Google Cloud console, go to the Manage resources page.

        Go to Manage resources

      9. In the project list, select the project that you want to delete, and then click Delete.
      10. In the dialog, type the project ID, and then click Shut down to delete the project.

        11. Embora o perímetro dos VPC Service Controls não gere custos adicionais, deve ser limpo para evitar a acumulação de recursos não usados na sua organização.

        1. No seletor de projetos na parte superior da Google Cloud consola, selecione a organização que usou durante este tutorial.

        2. Na Google Cloud consola, aceda à página VPC Service Controls.

          Aceda aos VPC Service Controls

        3. Na lista de perímetros, selecione o perímetro que quer eliminar e clique em Eliminar.

        4. Na caixa de diálogo, clique novamente em Eliminar para confirmar a eliminação.

        O que se segue?