Esta página foi traduzida pela API Cloud Translation.

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

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.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.
Enable the APIs
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
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 colunn 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.
  Acessar o IAM
2. Selecionar uma organização.
3. Clique em CONCEDER ACESSO.
4. No campo Novos principais, insira seu identificador de usuário. Normalmente, é o endereço de e-mail de uma Conta do Google.
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 Salvar.
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 colunn 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.
    Acessar o IAM
  2. Selecionar um projeto.
  3. Clique em CONCEDER ACESSO.
  4. No campo Novos principais, insira seu identificador de usuário. Normalmente, é o endereço de e-mail de uma Conta do Google.
  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 Salvar.
  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 as 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.
  
  Observação: este tutorial implementa um perímetro aplicado porque não há recursos de produção dentro do perímetro. Se você estiver adicionando um perímetro a projetos de produção existentes, recomendamos testar com o modo de simulação antes de aplicar.
  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"
    
    Atenção: neste tutorial, você vai restringir apenas os serviços do Compute Engine e do Cloud Storage. Em um perímetro de produção, recomendamos restringir todos os serviços com suporte para reduzir uma variedade de caminhos de exfiltração.
    O perímetro de exemplo configura a flag --vpc-allowed-services com o valor de alias RESTRICTED-SERVICES para permitir o tráfego dessa VPC para o mesmo conjunto de serviços definido pela flag --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.
  
  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.
  
  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.
    
    Observação: depois que você atualizar um perímetro de serviço, pode levar algum tempo para que as alterações sejam propagadas e entrem em vigor. Se você receber um resultado inesperado, aguarde um minuto e tente novamente depois que o perímetro for totalmente atualizado.
  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.
  
  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 permite que um cliente autorizado acesse apenas o serviço do Compute Engine, mas não permite 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 pela VPC.
  
  O diagrama anterior ilustra como um perímetro permite que o tráfego de endpoints de rede dentro do perímetro acesse 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 pela VPC não podem ser acessados de endpoints de rede dentro do perímetro.
  
  Nas etapas a seguir, você vai verificar esse conceito estabelecendo uma conexão SSH com a instância do Compute Engine dentro do perímetro e, em seguida, fazendo solicitações para os 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 para os serviços do Google Cloud fora do perímetro.
  
  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ê vai verificar esse 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. 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ê verifica se uma política de saída permite uma exceção ao 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.
    
    Observação: depois que você atualizar um perímetro de serviço, pode levar algum tempo para que as alterações sejam propagadas e entrem em vigor. Se você receber um resultado inesperado, aguarde um minuto e tente novamente depois que o perímetro for totalmente atualizado.
  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.
    
    Observação: depois de atualizar o serviço de políticas da organização, pode levar algum tempo para que as alterações sejam propagadas e entrem em vigor. Se você receber um resultado inesperado, aguarde um minuto e tente novamente depois que o perímetro for totalmente atualizado.
  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 compliance 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
  Cuidado: excluir um projeto tem os seguintes efeitos:
  
  Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
  
  Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
  
  Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.
  Delete a Google Cloud project:
  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
  - Saiba mais sobre as práticas recomendadas para ativar o VPC Service Controls.
  - Saiba mais sobre os serviços compatíveis com o VPC Service Controls.
  - Saiba como ativar os serviços acessíveis por VPC.
  - Leia sobre a configuração do Private Service Connect para acessar as APIs do Google.
  - Para mais arquiteturas de referência, diagramas, tutoriais e práticas recomendadas, explore o Centro de arquitetura do Cloud.

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

Objetivos

Custos

Antes de começar

Check for the roles

Grant the roles

Check for the roles

Grant the roles

Configurar o perímetro do VPC Service Controls

Prepare sua rede VPC

Criar um perímetro do VPC Service Controls

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

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

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

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

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

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

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

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

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

Limpar

A seguir