1. Introdução
O VPC Service Controls (VPC-SC) é um controle de segurança no nível da organização no Google Cloud que permite que clientes corporativos reduzam os riscos de exfiltração de dados. O VPC Service Controls oferece acesso estilo confiança zero a serviços multilocatários, permitindo que os clientes restrinjam o acesso a IPs autorizados, contexto do cliente e parâmetros de dispositivo enquanto se conectam a serviços multilocatários da Internet e de outros serviços para reduzir perdas intencionais e não intencionais. Como vimos no Tutorial básico I do VPC Service Controls, é possível usar o VPC Service Controls para criar perímetros que protegem os recursos e os dados dos serviços especificados explicitamente.
Estes são os objetivos deste tutorial:
- Entender os conceitos básicos do VPC Service Controls
- Atualizar um perímetro de serviço e testar usando o modo de teste
- Proteja dois serviços com o VPC Service Controls
- Resolver uma violação de saída do VPC Service Controls ao listar um objeto do Cloud Storage
2. Configuração e requisitos
Para este tutorial, precisamos dos seguintes pré-requisitos:
- Organização do GCP.
- Uma pasta em Organização.
- Dois projetos do GCP na mesma organização colocados na pasta.
- As permissões necessárias no nível da organização.
- conta de faturamento para os dois projetos.
- Tutorial básico do VPC Service Controls I Configuração do VPC Service Controls e do Access Context Manager
Recursos de configuração
- Configure os recursos conforme descrito em "Configuração de recursos" do Tutorial básico I do VPC Service Controls
- Verifique se você tem as permissões necessárias para administrar o Cloud Storage.
- Para este tutorial, vamos começar a usar a CLI em vez do console do Cloud. Em um dos ambientes de desenvolvimento, configure a CLI gcloud:
- Cloud Shell: para usar um terminal on-line com a CLI gcloud já configurada, ative o Cloud Shell.
Ative o Cloud Shell clicando no ícone no canto superior direito do console do Cloud. A inicialização da sessão pode levar alguns segundos. Consulte o guia do Cloud Shell para mais detalhes.
- Shell local: para usar um ambiente de desenvolvimento local, instale e inicialize a gcloud CLI.
Custo
É necessário ativar o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de teste sem custo financeiro de US $300.
Os únicos recursos que geram custos são a instância de VM e o objeto do Cloud Storage. Para ver uma estimativa do custo da instância de VM, use a calculadora de preços. Consulte o custo estimado do Cloud Storage nesta lista de preços.
3. Crie um bucket e um objeto do Storage
Como mencionado antes, vamos reutilizar os recursos criados no tutorial anterior. Vamos prosseguir com a criação do bucket do Cloud Storage. Para este tutorial, vamos começar a usar a CLI gcloud em vez do console.
- No console do Google, selecione ProjectX. Neste projeto, vamos criar o bucket do Storage e o objeto.
- Execute o comando a seguir para configurar o Cloud Shell para usar o ProjectX:
gcloud config set project PROJECT_ID
- No seu ambiente de desenvolvimento, execute este comando:
gcloud storage buckets create gs://BUCKET_NAME --location=us-central1
- Crie um objeto de armazenamento para que possamos lê-lo na instância de VM localizada no ProjectZ. Criaremos um arquivo .txt.
nano hello.txt
Adicione o que você quiser no arquivo de texto.
- Faça upload do objeto no bucket.
gcloud storage cp /home/${USER}/hello.txt gs://BUCKET_NAME
- Para verificar se foi feito o upload do objeto no bucket, liste-o.
gcloud storage ls gs://BUCKET_NAME
Você precisa ver o arquivo hello.txt listado no console.
4. API Protect Cloud Storage
No codelab anterior, criamos um perímetro e protegemos a API Compute Engine. Neste codelab, vamos editar o perímetro do modo de simulação e adicionar o Cloud Storage. Isso nos ajudará a determinar o impacto da proteção do perímetro mostrando as violações do VPC Service Controls nos registros de auditoria. No entanto, os recursos vão continuar acessíveis até a aplicação do perímetro.
- No Console do Google, selecione sua organização. Acessar o VPC Service Controls. Verifique se você está no escopo da organização.
- Abrir o Cloud Shell e atualizar o perímetro de simulação "SuperProtection" criado no laboratório anterior:
gcloud access-context-manager perimeters dry-run update SuperProtection --policy=POLICY --add-restricted-services=storage.googleapis.com
- Verifique se a API Cloud Storage foi atualizada descrevendo o perímetro.
gcloud access-context-manager perimeters dry-run describe SuperProtection --policy=POLICY
Na saída, você vai notar que a API Cloud Storage está listada abaixo dos serviços restritos
junto com a API Compute Engine, mas com um rótulo "-vpcAccessibleServices: {}"
:
5. Verificar se a API Cloud Storage foi protegida
No modo de teste, verifique se a opção "SuperProtection" do perímetro mostra a negação listando o objeto da instância de VM criada no ProjectZ para o ProjectX que está hospedando o bucket de armazenamento
- No console do Cloud, acesse o seletor de projetos, selecione "ProjectZ" e navegue até Compute Engine > Instâncias de VM.
- Clique no botão "SSH" para se conectar à instância de VM e acessar a linha de comando.
- Liste o arquivo hello.txt que enviamos anteriormente.
gcloud storage ls gs://BUCKET_NAME
Como a API Cloud Storage é protegida no modo de teste, é possível listar os recursos, mas é necessário exibir uma mensagem de erro nos registros de auditoria do ProjectZ.
- Acesse a API Logs Explorer no ProjectZ e procure a última mensagem de erro do VPC Service Controls. Use esse filtro para encontrar o registro que estamos procurando:
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS" "(Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:UNIQUE_ID"
Este filtro vai nos mostrar a última violação no modo de teste que pertence ao Cloud Storage. Confira um exemplo de registro. Podemos validar se a violação é uma violação de saída ao tentar listar o conteúdo no bucket localizado no ProjectX.
egressViolations: [ 0: { servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection" source: "projects/PROJECTX_ID" sourceType: "Network" targetResource: "projects/PROJECTZ_ID" } ] resourceNames: [ 0: "projects//buckets/BUCKET_NAME" ] securityPolicyInfo: { organizationId: "ORGANIZATION_ID" servicePerimeterName: "accessPolicies/POLICY/servicePerimeters/SuperProtection" } violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER" vpcServiceControlsUniqueId: "UNIQUE_ID" } methodName: "google.storage.objects.list"
- Como validamos que a chamada de API ao Cloud Storage gera uma violação do VPC Service Controls, vamos aplicar o perímetro com a nova configuração. Abra o Cloud Shell e aplique o perímetro de simulação:
gcloud access-context-manager perimeters dry-run enforce SuperProtection --policy=POLICY --async
- Conecte-se à instância de VM usando SSH e liste o bucket de armazenamento novamente para verificar se o perímetro de simulação foi aplicado corretamente.
gcloud storage ls gs://BUCKET_NAME
Vamos receber uma violação do VPC Service Controls na CLI da VM em vez de uma lista dos objetos do Storage:
ERROR: (gcloud.storage.ls) User [PROJECT_NUMBER-compute@developer.gserviceaccount.com] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:"UNIQUE_ID"
Conseguimos impedir a exfiltração de dados usando o VPC Service Controls para impedir a leitura ou cópia de dados em um recurso fora do perímetro.
6. Solução de problemas de negação de lista.
Vamos solucionar problemas de negação que recebemos da CLI da instância de VM. Verifique os registros de auditoria e procure o ID exclusivo do VPC Service Controls.
- Acesse o seletor de projetos e selecione ProjectZ.
- Encontre o ID exclusivo do VPC Service Controls nos registros de auditoria usando a seguinte consulta na Análise de registros:
resource.type="audited_resource" protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
Isso vai mostrar todos os registros de auditoria do VPC Service Controls. Vamos procurar o último registro de erros. Como a chamada de API foi feita da instância de VM, o principal precisa ser a conta de serviço do Compute Engine "PROJECT_NUMBER-compute@developer.gserviceaccount.com"
Como já temos o ID exclusivo do VPC Service Controls, podemos usá-lo para acessar o registro desejado diretamente com este filtro:
protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_ID"
- Clique no cabeçalho VPC Service Controls e selecione "Resolver problemas de negação". que vai abrir o solucionador de problemas do VPC Service Controls.
Essa API vai mostrar o motivo da violação em uma interface fácil de usar e se foi uma violação de entrada ou saída, entre outras coisas úteis.
Neste exercício, vamos procurar o seguinte:
authenticationInfo: { principalEmail: "PROJECT_ID-compute@developer.gserviceaccount.com" egressViolations: [ 0: { servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection" source: "projects/PROJECTZ_ID" sourceType: "Network" targetResource: "projects/PROJECTX_ID" } violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
Essas informações são suficientes para sabermos que precisamos criar uma regra de saída para permitir que a conta de serviço do Compute Engine acesse o bucket de armazenamento do ProjectZ para o ProjectX. Além disso, como a rede não está no mesmo perímetro, precisamos permitir a comunicação da VPC com os serviços e compartilhar dados entre eles.
- Ative o Cloud Shell e crie um arquivo .yaml com a regra de saída usando um editor de texto.
nano egresstorage.yaml
- egressTo: operations: - serviceName: storage.googleapis.com methodSelectors: - method: \"*\" resources: - projects/PROJECTX_ID egressFrom: identities: - serviceAccount:PROJECT_ID-compute@developer.gserviceaccount.com
- Atualize a política de entrada que protege o ProjectZ.
gcloud access-context-manager perimeters update SuperProtection --set-egress-policies=egresstorage.yaml --policy=POLICY
Agora podemos tentar acessar o bucket novamente pela instância da VM.
- No console do Cloud, acesse o seletor de projetos, selecione "ProjectZ" e navegue até Compute Engine > Instâncias de VM.
- Clique no botão "SSH" para se conectar à instância de VM e acessar a linha de comando.
- Na CLI da VM, tente listar os objetos no bucket de armazenamento.
gcloud storage ls gs://BUCKET_NAME/
Você vai receber a seguinte mensagem de erro:
ERROR: (gcloud.storage.ls) User [PROJECT_ID-compute@developer.gserviceaccount.com] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): PROJECT_ID-compute@developer.gserviceaccount.com does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist).
- Precisamos conceder uma permissão de leitor de objetos para a conta de serviço do Compute Engine poder listar os objetos no bucket do Storage.
gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=serviceAccount:PROJECT_ID-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer
- Mais uma vez, vamos tentar listar o arquivo hello.txt da CLI da instância de VM .
gcloud storage ls gs://BUCKET_NAME/ . . gs://BUCKET_NAME/hello.txt
Agora podemos listar o objeto sem uma violação de permissão do VPC Service Controls. Mas e quanto ao download do arquivo? Vamos tentar.
gcloud storage cp gs://BUCKET_NAME/hello.txt /home/${USER}
Teremos a seguinte saída
Copying gs://BUCKET_NAME/hello.txt to file:///home/${USER} Completed files 1/1 | 54.0B/54.0B
7. Limpeza
Não há cobrança separada pelo uso do VPC Service Controls quando o serviço não está em uso, mas a prática recomendada é limpar o ambiente usado no laboratório. Também é possível excluir sua instância de VM e/ou projetos do Cloud para evitar cobranças. A exclusão do projeto do Cloud interrompe o faturamento de todos os recursos usados nele.
- Para excluir sua instância de VM, marque a caixa de seleção à esquerda do nome da instância de VM e clique em Excluir.
- Para excluir o perímetro, siga estas etapas:
- No console do Google Cloud, clique em Segurança e depois em VPC Service Controls no escopo da organização.
- Na página do VPC Service Controls, na linha da tabela correspondente ao perímetro que você quer excluir, clique em "Excluir ícone".
- Para excluir o nível de acesso, siga estas etapas:
- No console do Google Cloud, abra a página Access Context Manager no escopo da pasta.
- Na grade, na linha do nível de acesso que você quer excluir, clique em "Excluir ícone" e em Excluir.
- Para excluir o objeto do Storage e o bucket, conclua as etapas a seguir:
- No console do Google Cloud, abra a página de buckets do Cloud Storage .
- Marque a caixa de seleção ao lado do bucket criado.
- Clique em Excluir.
- Na janela que é aberta, confirme que você quer excluir o bucket.
- Clique em Excluir.
- Para encerrar o projeto, siga estas etapas:
- No console do Google Cloud, acesse a página IAM e Configurações de administrador do projeto que você quer excluir.
- Na página "IAM e Configurações de administrador, clique em Encerrar.
- Digite o ID do projeto e clique em Encerrar mesmo assim.
8. Parabéns!
Neste codelab, você atualizou, aplicou e resolveu problemas de um perímetro de simulação do VPC Service Controls.
Saiba mais
- Consulte a documentação do VPC Service Controls.
- Consulte a documentação do Access Context Manager.
- Consulte a documentação do solucionador de problemas de VPC-SC.
- Consulte a documentação Regras de entrada e saída.
- Consulte a documentação de simulação.
- Consulte a documentação do Cloud Storage.
Licença
Este conteúdo está sob a licença Atribuição 2.0 Genérica da Creative Commons.