Este documento descreve as implementações ao nível do acesso e fornece recomendações para iniciar a aplicação do perímetro de serviço com base em listas de autorizações.
Quando conclui uma execução de teste de cargas de trabalho, identifica uma lista de endereços IP e identidades que tem de adicionar a uma lista de autorizações. Também pode constatar que algumas cargas de trabalho precisam de uma lista de autorizações baseada no dispositivo. Para conceder acesso controlado a recursos Trusted Cloud protegidos, pode usar níveis de acesso dos VPC Service Controls. Algumas formas práticas de implementar níveis de acesso baseiam-se no endereço IP, na identidade ou no dispositivo.
Para mais informações, consulte o artigo Acesso sensível ao contexto com regras de entrada.
Conceder acesso com base no IP de origem
Só pode usar intervalos CIDR de IP público nos níveis de acesso para listas de autorizações baseadas em IP. Uma vez que este método permite todas as APIs protegidas deste intervalo de IPs, o ambiente por detrás destes IPs tem de ser fidedigno e controlado. Um cenário de utilização típico desta lista de autorizações é permitir o acesso ao perímetro a partir de redes no local. O diagrama seguinte mostra como uma lista de autorizações baseada em IP bloqueia e permite o acesso ao perímetro:
No diagrama anterior, uma identidade válida tenta aceder ao perímetro. As tentativas de acesso são rejeitadas quando têm origem em endereços IP da Internet. No entanto, o acesso é permitido quando é proveniente dos endereços IP públicos da empresa.
Uma variação deste cenário ocorre quando permite o acesso ao perímetro a partir de recursos privados implementados num projeto ou numa organização diferente. Neste exemplo de utilização, é necessária uma gateway do Cloud NAT no projeto de origem.
O Cloud NAT tem uma integração com o acesso privado à Google que ativa automaticamente o acesso privado à Google na sub-rede do recurso e mantém o tráfego para as APIs e os serviços Google internos, em vez de o encaminhar para a Internet através do endereço IP externo do gateway do Cloud NAT.
Uma vez que o tráfego é encaminhado na rede interna da Google, o campo
RequestMetadata.caller_ip do objeto AuditLog é ocultado para
gce-internal-ip. Para permitir o acesso ao perímetro neste caso, tem de
configurar uma regra de entrada para permitir o acesso com base noutros atributos, como
o projeto ou a conta de serviço, em vez de configurar um nível de acesso com base
no endereço IP de origem externo.
Conceder acesso com base na identidade do autor da chamada
Para implementar uma lista de autorizações baseada na identidade, adicione contas de serviço e superadministradores da organização a uma lista de autorizações. O perímetro está aberto para estas identidades a partir de qualquer endereço IP, pelo que tem de se certificar de que as identidades estão bem protegidas. Também tem de se certificar de que evita gerar chaves para contas de serviço que adicionou a uma lista de autorizações. Não é comum adicionar identidades de utilizadores a uma lista de autorizações (não é possível adicionar grupos a uma lista de autorizações) num perímetro.
Os recursos dentro do perímetro podem ser acedidos através de VMs dentro do perímetro, a partir de redes no local fidedignas ou a partir de dispositivos fidedignos. Recomendamos que use o Cloud Workstations para aceder aos recursos dentro dos perímetros, uma vez que os VPC Service Controls não suportam o Cloud Shell.
Acesso de qualificação com base nos atributos do dispositivo do autor da chamada
A confiança no dispositivo, também denominada ponto final fidedigno, baseia-se na existência de um utilizador da organização válido com sessão iniciada num navegador Chrome ou num Chromebook. A confiança aplica-se à sessão iniciada do SO. Por exemplo, um utilizador do Windows com sessão iniciada e a executar uma sessão do Chrome (o navegador não tem de estar aberto) pode chamar com êxito comandos da CLI gcloud em APIs de perímetro protegidas. No entanto, uma sessão de utilizador do Windows diferente na mesma máquina não pode chamar comandos nas APIs de perímetro protegido.
As seguintes condições do dispositivo são úteis para estabelecer a confiança no dispositivo:
Chrome OS validado é uma condição altamente segura e validada criptograficamente que indica que um utilizador da organização válido tem sessão iniciada num Chromebook iniciado de forma segura. Esta é uma condição de confiança de nível 1 recomendada.
Exigir aprovação do administrador para acesso ao dispositivo permite que os administradores do Cloud Identity aprovem cada dispositivo antes de ser concedido qualquer acesso. Por predefinição, os dispositivos são aprovados automaticamente se tiverem um utilizador da organização válido com sessão iniciada. No entanto, recomendamos que desative a opção de aprovação automática.
A opção Exigir dispositivo pertencente à empresa baseia-se no agente do Chrome que obtém o número de série do SO, que normalmente é proveniente do BIOS. Este número tem de corresponder aos números de série existentes que introduziu no Cloud Identity.
Uma vez que o número de série não é autoritário em dispositivos que não executam o ChromeOS, um utilizador com privilégios de administrador elevados pode conseguir falsificar o número de série. Recomendamos que use esta condição apenas como uma verificação de nível 2.
Para ver um exemplo de rastreador para conceder acesso controlado com base nas condições abordadas na lista anterior, consulte o modelo de integração do VPC Service Controls – lista de autorizações (PDF).
Inicie a aplicação
Depois de criar a lista de autorizações e atualizar os níveis de acesso, recomendamos que execute novamente as cargas de trabalho para confirmar que não existem violações. Se as cargas de trabalho forem executadas sem violações, pode iniciar a aplicação do VPC Service Controls sem afetar as aplicações.
Quando planear a aplicação, inclua o seguinte:
- Escolha uma data de aplicação e comunique-a a todas as equipas relacionadas.
- Certifique-se de que as equipas de operações de segurança e de resposta a incidentes estão cientes da implementação. Além disso, certifique-se de que os indivíduos com as autorizações adequadas inspecionam os registos e aprovam listas de autorizações adicionais, se necessário.
- Certifique-se de que a equipa de resposta a situações pode abrir um Trusted Cloud registo de apoio técnico, se surgirem dúvidas ou problemas.
- Crie ou modifique o perímetro e os níveis de acesso através de ferramentas de automatização como o Terraform. Recomendamos que não execute estas tarefas manualmente.
Quando iniciar a aplicação, comece por mover os projetos associados a uma única carga de trabalho do perímetro de teste para o perímetro ativo. Certifique-se de que dá tempo para a aplicação ser executada corretamente enquanto observa os registos de violações. Repita o processo para as cargas de trabalho restantes uma de cada vez.
Para apresentar violações bloqueadas, configure um sink de registo agregado que envie registos de auditoria de todos os projetos no 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
O que se segue?
- Saiba como permitir o acesso a recursos protegidos a partir do exterior do perímetro.
- Saiba como listar, atualizar e eliminar perímetros de serviço.