Neste tutorial, mostramos como proteger o Compute Engine usando um perímetro de serviço e como resolver um problema de violação de entrada para permitir o acesso autorizado ao Compute Engine.
Com o VPC Service Controls, é possível definir um perímetro de serviço em torno dos recursos dos serviços gerenciados pelo Google para controlar a comunicação entre eles. É possível estabelecer um perímetro de zero trust em torno dos seus recursos sensíveis, restringindo o acesso a endereços IP, usuários e dispositivos autorizados. Isso permite definir políticas de segurança que impedem o acesso a serviços gerenciados pelo Google fora de um perímetro confiável, bloquear o acesso a dados em locais não confiáveis e reduzir os riscos de exfiltração de dados.
Este tutorial é destinado a administradores do Google Cloud da organização que querem aprender os conceitos básicos do VPC Service Controls.
Criar um perímetro de serviço
Crie um perímetro de serviço que proteja a API Compute Engine no projeto My-Project-2
:
No console do Google Cloud , acesse a página VPC Service Controls.
Verifique se você está no escopo da organização.
Clique em Gerenciar políticas.
Crie uma nova política de acesso para a pasta
Exercise
.Crie um novo perímetro com os seguintes detalhes:
Título:
MyFirstPerimeter
Tipo de perímetro: Regular
Modo de aplicação: Restrito
Recursos a serem protegidos: projeto
My-Project-2
Serviços restritos: API Compute Engine
Verificar o perímetro
Nesta seção, você pode fazer solicitações de acesso aos recursos nos projetos para confirmar se o perímetro protege os recursos pretendidos.
Abra o projeto
My-Project-1
e verifique se você pode acessar o Compute Engine na página Instâncias de VM.Você vai conseguir acessar, porque
My-Project-1
não está protegido pelo perímetro criado anteriormente.Abra o projeto
My-Project-2
e verifique se você pode acessar o Compute Engine na página Instâncias de VM.O VPC Service Controls vai negar sua solicitação de acesso ao Compute Engine porque o perímetro
MyFirstPerimeter
protegeMy-Project-2
e a API Compute Engine.
Resolver um problema de violação
Os registros de auditoria do VPC Service Controls incluem detalhes sobre solicitações de recursos protegidos e o motivo pelo qual o VPC Service Controls negou a solicitação. Você precisa dessas informações para identificar e resolver o problema da violação no projeto My-Project-2
.
Acessar registros de auditoria
Encontre o ID exclusivo da violação do VPC Service Controls nos registros de auditoria do projeto
My-Project-2
:-
No console do Google Cloud , acesse a página Análise de registros:
Acessar a Análise de registros
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.
Selecione o projeto
My-Project-2
.Para mostrar todos os registros de auditoria, insira a seguinte consulta no campo do editor de consultas:
resource.type="audited_resource" protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
Clique em Executar consulta.
Essa consulta mostra todos os registros de auditoria do VPC Service Controls. Para encontrar os detalhes da violação ao acessar a API Compute Engine no projeto
My-Project-2
, confira o último registro de erros.Para mais informações, consulte Visualizar registros.
-
No painel Resultados da consulta, clique em VPC Service Controls ao lado da negação que você quer resolver e clique em Resolver problemas de negação.
A página do analisador de violações do VPC Service Controls é aberta. Essa página mostra o motivo da violação e outras informações, como se ela é de entrada ou saída.
Neste tutorial, procure as seguintes informações:
"principalEmail": "USER@DOMAIN" "callerIp": "PUBLIC_IP_ADDRESS" "serviceName": "compute.googleapis.com" "servicePerimeterName": "accessPolicies/POLICY_NUMBER/servicePerimeters/MyFirstPerimeter "ingressViolations": [ { "targetResource": "projects/PROJECT_NUMBER", "servicePerimeter": "accessPolicies/POLICY_NUMBER/servicePerimeters/MyFirstPerimeter" } ], "violationReason": "NO_MATCHING_ACCESS_LEVEL", "resourceNames": "PROJECT_ID"
O motivo da violação é
"NO_MATCHING_ACCESS_LEVEL"
. A violação de"NO_MATCHING_ACCESS_LEVEL"
ocorre quando o endereço IP, o tipo de dispositivo ou a identidade do usuário não corresponde a nenhuma regra de entrada ou nível de acesso associado ao perímetro. Se o endereço IP do autor da chamada estiver ausente ou aparecer como um endereço IP interno no registro, essa violação pode ser causada por um serviço do Google Cloud que não é compatível com o VPC Service Controls.
Para corrigir essa rejeição no projeto My-Project-2
, você tem duas opções:
Crie um nível de acesso que permita acessar o endereço IP do sistema para o projeto dentro do perímetro.
Crie uma regra de entrada que permita o acesso a um cliente de API de fora do perímetro a recursos dentro dele.
A seção a seguir mostra como resolver essa negação criando um nível de acesso.
Criar um nível de acesso
No console do Google Cloud , acesse a página Access Context Manager no escopo da pasta
Exercise
.Crie um nível de acesso com os seguintes detalhes:
Ao lado de Criar condições em, selecione Modo avançado.
Em Se a condição for atendida, retorne, selecione True.
Selecione o atributo Sub-redes de IP e informe o endereço IP público do seu sistema.
Selecione o atributo Localizações geográficas e especifique sua localização geográfica.
Esse nível de acesso só permite o acesso quando o endereço IP e a localização geográfica correspondem.
Acesse a página VPC Service Controls no escopo da organização.
Selecione a política de acesso que você criou anteriormente neste tutorial.
Adicione o nível de acesso que você criou no escopo da pasta
Exercise
ao perímetroMyFirstPerimeter
.
Testar o acesso
Depois de adicionar o nível de acesso, verifique se o Compute Engine está disponível no projeto My-Project-2
e é possível criar uma instância de VM.
No console do Google Cloud , acesse a página Instâncias de VM.
Após cerca de um minuto, o Compute Engine cria uma instância de VM. Essa ação verifica se você tem acesso total ao Compute Engine protegido dentro do perímetro.