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 de cliente e parâmetros de dispositivos enquanto se conectam a serviços multilocatários na Internet e em 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 protejam os recursos e os dados de serviços especificados explicitamente.
As metas deste tutorial são:
- Entender os princípios básicos do VPC Service Controls
- Atualizar e testar um perímetro de serviço usando o modo de teste
- Proteger dois serviços com o VPC Service Controls
- Resolver um problema de 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 na 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.
Resources-setup
- Configure os recursos conforme descrito na seção "Resources-setup" do Tutorial básico I do VPC Service Controls.
- Verifique se você tem as permissões necessárias para administrar o Cloud Storage.
- Neste 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 CLI gcloud.
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 podem aproveitar o programa de avaliação sem custos de US $300.
Os únicos recursos que vão gerar um custo são a instância de VM e o objeto do Cloud Storage. Um custo estimado da instância de VM pode ser encontrado na calculadora de preços. O custo estimado do Cloud Storage pode ser encontrado nesta lista de preços.
3. Criar um bucket e um objeto do Cloud Storage
Como mencionado anteriormente, vamos reutilizar os recursos criados no tutorial anterior. Então, vamos continuar com a criação do bucket do Cloud Storage. Neste 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.
- Verifique se você definiu o Cloud Shell para usar o ProjectX executando o seguinte comando:
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 em ProjectZ. Vamos criar um arquivo .txt.
nano hello.txt
Adicione o que quiser ao arquivo de texto.
- Faça upload do objeto para o bucket.
gcloud storage cp /home/${USER}/hello.txt gs://BUCKET_NAME
- Verifique se o objeto foi enviado para o bucket listando.
gcloud storage ls gs://BUCKET_NAME
O arquivo hello.txt vai aparecer no console.
4. Proteger a API Storage do Cloud
No codelab anterior, criamos um perímetro e protegemos a API Compute Engine. Neste codelab, vamos editar o perímetro do modo de teste a seco e adicionar o Cloud Storage. Isso vai ajudar a determinar o impacto da proteção de perímetro, mostrando as violações do VPC Service Controls nos registros de auditoria. No entanto, os recursos vão permanecer acessíveis até que o perímetro seja aplicado.
- No console do Google, selecione sua organização e acesse o VPC Service Controls. Verifique se você está no escopo da organização.
- Abra o Cloud Shell e atualize o perímetro do modo de teste "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 Storage do Cloud Storage foi atualizada descrevendo o perímetro
gcloud access-context-manager perimeters dry-run describe SuperProtection --policy=POLICY
Na saída, você vai ver que a API Storage está listada abaixo dos serviços restritos.
junto com a API Compute Engine, mas com um rótulo "-vpcAccessibleServices: {}"":
5. Verifique se a API Storage do Cloud foi protegida
No modo de teste, verifique se o perímetro "SuperProtection" está mostrando 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 e selecione ProjectZ. Em seguida, 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 dela.
- Liste o arquivo hello.txt que enviamos por upload anteriormente.
gcloud storage ls gs://BUCKET_NAME
Como a API Cloud Storage está protegida no modo de simulação, é possível listar os recursos, mas você precisa ter uma mensagem de erro nos registros de auditoria do ProjectZ.
- Acesse a API Análise de registros no ProjectZ e procure a última mensagem de erro do VPC Service Controls. Use este 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"
Esse filtro vai mostrar a última violação no modo de simulação que pertence ao Cloud Storage. Confira um exemplo de como o registro aparece. Podemos validar que a violação é de saída ao tentar listar o conteúdo no bucket localizado em 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 para o 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"
Evitamos a exfiltração de dados usando o VPC Service Controls para impedir a leitura ou cópia de dados para um recurso fora do perímetro.
6. Resolver problemas de negação da lista.
Vamos resolver o problema da negação que recebemos da CLI da instância de VM. Vamos verificar os registros de auditoria e procurar o ID exclusivo do VPC Service Controls.
- Acesse o seletor de projetos e escolha "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 usando 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 em uma interface amigável o motivo da violação e se ela foi 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, a rede não está no mesmo perímetro. Portanto, precisamos permitir a comunicação da VPC com os serviços e compartilhar dados entre os perímetros de serviço.
- 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 na instância de VM novamente.
- No console do Cloud, acesse o seletor de projetos e selecione ProjectZ. Em seguida, 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 dela.
- Depois de acessar a 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 leitura de objetos à conta de serviço do Compute Engine para listar os objetos no bucket de armazenamento.
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 na 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 o download do arquivo? Vamos tentar.
gcloud storage cp gs://BUCKET_NAME/hello.txt /home/${USER}
e vamos receber 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 extra pelo uso do VPC Service Controls quando o serviço não está em uso, mas é recomendável limpar a configuração usada neste laboratório. Você também pode excluir sua instância de VM e/ou projetos do Cloud para evitar cobranças. A exclusão do projeto na nuvem interrompe o faturamento de todos os recursos usados nele.
- Para excluir a instância de VM, marque a caixa de seleção à esquerda do nome dela e clique em Excluir.
- Para excluir o perímetro, siga estas etapas:
- No console do Google Cloud, clique em Segurança e em VPC Service Controls no escopo da organização.
- Na página "VPC Service Controls", na linha da tabela correspondente ao perímetro que você quer excluir, clique no ícone "Excluir".
- 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 "Ícone de exclusão" e em Excluir.
- Para excluir o objeto e o bucket do Storage, siga estas etapas:
- 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 seu projeto, siga estas etapas:
- No console do Google Cloud, acesse a página Configurações do IAM e do administrador do projeto que você quer excluir.
- Na página "Configurações do IAM e administrador", clique em Desativar.
- Digite o ID do projeto e clique em Encerrar mesmo assim.
8. Parabéns!
Neste codelab, você atualizou, aplicou e solucionou 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 do VPC-SC.
- Consulte a documentação sobre 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.