Este documento descreve implementações no nível de acesso e fornece recomendações para iniciar a aplicação do perímetro de serviço com base em listas de permissões.
Ao concluir uma execução de simulação de cargas de trabalho, você identifica uma lista de endereços IP e identidades que precisa adicionar a uma lista de permissões. Talvez você também descubra que algumas cargas de trabalho precisam de uma lista de permissões baseada em dispositivo. Para conceder acesso controlado a recursos protegidos do Google Cloud, use os níveis de acesso do VPC Service Controls. Algumas maneiras práticas de implementar os níveis de acesso são baseadas em endereço IP, identidade ou dispositivo.
Para mais informações, consulte Acesso baseado no contexto com regras de entrada.
Como conceder acesso com base no IP de origem
Você só pode usar intervalos CIDR de IP público nos níveis de acesso das listas de permissões baseadas em IP. Como esse método concede permissão a todas as APIs protegidas desse intervalo de IP, o ambiente por trás desses IPs precisa ser confiável e controlado. Um cenário de uso típico desta lista de permissões é permitir o acesso de perímetro a partir de redes locais. O diagrama a seguir mostra como uma lista de permissões baseada em IP bloqueia e permite o acesso do perímetro:
No diagrama anterior, uma identidade válida tenta acessar o perímetro. As tentativas de acesso são rejeitadas quando se originam de qualquer endereço IP da Internet. No entanto, o acesso é permitido quando é proveniente dos endereços IP públicos corporativos.
Uma variação desse cenário é quando você permite o acesso ao perímetro de
recursos privados implantados em um projeto ou organização diferente. Neste uso
Nesse caso, é necessário um gateway do Cloud NAT no projeto de origem.
Cloud NAT
tem integração com o Acesso privado do Google
que ativa automaticamente o Acesso privado do Google na sub-rede do recurso,
e mantém o tráfego para as APIs e serviços do Google interno, em vez de roteá-lo
para a Internet usando o endereço IP externo do gateway do Cloud NAT.
Como o tráfego é roteado dentro da rede interna do Google, o campo RequestMetadata.caller_ip do objeto AuditLog é substituído por gce-internal-ip. Para permitir o acesso ao perímetro nesse caso, você precisa:
configurar uma regra de entrada para permitir o acesso com base em outros atributos, como
projeto ou conta de serviço, em vez de configurar um nível de acesso com base
no endereço IP de origem externa.
Como conceder acesso com base na identidade do autor da chamada
Para implementar uma lista de permissões baseada em identidade, adicione contas de serviço e superadministradores da organização a uma lista de permissões. O perímetro é aberto para essas identidades de qualquer endereço IP. Portanto, você precisa garantir que elas sejam bem protegidas. Também é preciso evitar a redução de chaves nas contas de serviço adicionadas a uma lista de permissões. Não é uma prática comum adicionar identidades de usuários a uma lista de permissões (não é possível adicionar grupos a uma lista de permissões) em um perímetro.
Os recursos dentro do perímetro podem ser acessados por VMs dentro dele, por redes locais confiáveis ou por dispositivos de confiança. Recomendamos o uso do Cloud Workstations para acessar recursos dentro de perímetros porque o VPC Service Controls não é compatível com o Cloud Shell.
Como qualificar o acesso com base nos atributos do dispositivo do autor da chamada
A confiança do dispositivo, também chamada de endpoint confiável, exige que um usuário da organização válido faça login em um navegador Chrome ou em um Chromebook. A confiança se aplica à sessão de login do SO. Por exemplo, um usuário do Windows que esteja conectado e executando uma sessão do Chrome (o navegador não precisa estar aberto) pode chamar comandos da CLI gcloud em APIs de perímetro protegido. No entanto, uma sessão diferente do usuário do Windows na mesma máquina não pode chamar comandos nas APIs do perímetro protegidas.
Estas são as condições do dispositivo úteis para estabelecer a confiança dele:
O Chrome OS verificado é uma condição altamente segura e verificada por criptografia que indica que um usuário válido da organização está conectado a um Chromebook com inicialização segura. Essa é uma condição de confiança de nível 1 recomendada.
Exigir a aprovação do administrador para acesso ao dispositivo permite que os administradores do Cloud Identity aprovem cada dispositivo antes que qualquer acesso seja concedido. Por padrão, os dispositivos são aprovados automaticamente se tiverem um usuário da organização válido conectado. No entanto, recomendamos desativar a opção de aprovação automática.
Exigir dispositivo corporativo próprio exige que o agente do Chrome recupere o número de série do SO, que geralmente vem do BIOS. Esse número precisa corresponder aos números de série existentes que você inseriu no Cloud Identity.
Como o número de série não é autoritativo em dispositivos que não sejam o Chrome OS, um usuário com privilégios de administrador elevados pode ser capaz de falsificar o número de série. Portanto, recomendamos o uso dessa condição apenas como uma verificação de nível 2.
Para um rastreador de amostra que concede acesso controlado com base nas condições discutidas na lista anterior, consulte Modelo de integração do VPC Service Controls: lista de permissões (PDF).
Iniciar aplicação de restrições
Depois de projetar a lista de permissões e atualizar os níveis de acesso, recomendamos que você execute as cargas de trabalho novamente para confirmar se não há violações. Se as cargas de trabalho forem executadas sem violações, é possível iniciar a aplicação de restrições do VPC Service Controls sem afetar os aplicativos.
Ao planejar a aplicação das restrições, inclua o seguinte:
- Escolha uma data de aplicação de restrições e comunique essa data a todas as equipes relacionadas.
- Garanta que as equipes de operações de segurança e resposta a incidentes estejam cientes da implantação. Além disso, garanta que os indivíduos com as permissões apropriadas inspecionem os registros e aprovem outras listas de permissões, se necessário.
- Garanta que a equipe de resposta à situação possa abrir um caso de suporte do Google Cloud para dúvidas ou problemas que possam surgir.
- Crie ou modifique o perímetro e níveis de acesso usando ferramentas de automação como o Terraform. Não é recomendável executar essas tarefas manualmente.
Ao iniciar a aplicação de restrições, comece movendo os projetos associados a uma única carga de trabalho do perímetro do modo de teste para o perímetro ativo. Aguarde o aplicativo ser executado por um tempo enquanto você observa os registros de violação. Repita o processo para as cargas de trabalho restantes uma de cada vez.
Para detectar violações bloqueadas, configure um coletor de geração de registros agregado que envia os registros de auditoria de todos os projetos do perímetro para o BigQuery. Em seguida, execute a seguinte consulta:
SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter
A seguir
- Saiba como permitir o acesso a recursos protegidos fora do perímetro.
- Saiba como listar, atualizar e excluir perímetros de serviço.