Este documento descreve as práticas recomendadas para usar o acesso sensível ao contexto e proteger seus recursos Google Cloud de maneira eficaz. O acesso baseado no contexto é uma abordagem de segurança em que você controla o acesso dos usuários com base na força da autenticação, na postura do dispositivo, na localização da rede e geográfica ou em outros atributos. Essa abordagem vai além do uso de identidades básicas de usuário para acesso de segurança e pode ajudar você a implementar um modelo de segurança de confiança zero para melhorar sua postura geral de segurança. Para detalhes sobre como implementar o acesso baseado no contexto para diferentes tipos de apps e recursos, consulte Proteger apps e recursos usando o acesso baseado no contexto.
Para ajudar a proteger seus apps e recursos do Google Cloud , você pode definir um controle de acesso granular com base em vários fatores contextuais e combinações deles. Use o Access Context Manager para definir políticas de acesso, que contêm níveis de acesso e parâmetros de serviço.
Este documento é destinado a qualquer profissional de segurança responsável pelo Identity and Access Management (IAM) e pela segurança dos recursos e apps do Google Cloud . Este documento pressupõe que você já conheça o Access Context Manager, Google Cloude o gerenciamento do IAM.
Abordagens de acesso baseado no contexto
Ao configurar o acesso baseado no contexto na sua organização, você precisa decidir se quer aplicar controles de acesso baseado no contexto a apps, recursos ou ambos. Para tomar essa decisão, é útil distinguir entre os seguintes tipos diferentes de apps e serviços:
- Apps administrativos: permitem que os usuários gerenciem ou interajam com recursos do Google Cloud , como instâncias de VM, conjuntos de dados do BigQuery ou buckets do Cloud Storage. Exemplos de apps administrativos incluem o console Google Cloud , a Google Cloud CLI, o Terraform e o IAP Desktop.
- Apps de linha de negócios: incluem apps da Web que são executados no Google Cloud e usam SAML ou Identity-Aware Proxy (IAP) para autenticação e autorização. Às vezes, esses apps são chamados de apps internos. Exemplos de apps de linha de negócios incluem sistemas de CRM, painéis e outros apps personalizados.
- Google Workspace e outros Serviços do Google: esses serviços são fornecidos pelo Google, mas não estão relacionados ao Google Cloud.
Você pode distinguir ainda mais os apps de linha de negócios com base em como eles lidam com autenticação e autorização:
- SAML: apps que usam o SAML do Google Workspace para autenticação. Os apps SaaS geralmente se enquadram nessa categoria.
- IAP: apps da Web personalizados implantados por trás do IAP.
- OAuth: apps da Web ou de computador personalizados que usam o OAuth 2.0 e um ou mais escopos do OAuthGoogle Cloud .
O diagrama de fluxo a seguir mostra a abordagem de acesso sensível ao contexto mais adequada para cada tipo de app:
O diagrama mostra os seguintes tipos de apps:
Apps administrativos: geralmente, é mais importante proteger os recursos do Google Cloud que o app administrativo facilita o acesso do que o próprio app. Considere os cenários a seguir:
- Um usuário não pode acessar nenhum dos recursos. Nesse cenário, é provável que o acesso a um app administrativo não seja tão valioso para o usuário.
- Um usuário tem acesso a um recurso, mas não a um app administrativo. Nesse cenário, talvez ele consiga encontrar um app administrativo diferente que não esteja bloqueado e permita o acesso ao recurso.
Portanto, para apps administrativos, adote uma abordagem centrada em recursos. Para aplicar da maneira mais eficaz os controles de acesso sensíveis ao contexto aos recursos, use perímetros de serviço da nuvem privada virtual (VPC) com as regras de entrada adequadas. É possível complementar os perímetros de serviço da VPC com vinculações de acesso.
Apps de linha de negócios que usam o OAuth: para esses apps, é importante proteger o acesso aos apps e aos recursos que eles podem usar. Para proteger os apps usando o acesso baseado no contexto, use vinculações de acesso.
Apps de linha de negócios que usam o IAP: embora o IAP use o OAuth, não é possível usar vinculações de acesso para proteger apps que usam o IAP para autenticar usuários. Em vez disso, proteja esses apps usando condições do IAM.
Apps de linha de negócios que usam SAML: assim como os apps de linha de negócios que usam OAuth, é importante proteger o acesso aos apps e aos recursos que eles podem usar. Para proteger esses apps, use o acesso baseado no contexto do Google Workspace.
Google Workspace e outros Serviços do Google: para esses apps, é importante proteger o acesso aos apps e aos recursos que eles podem usar. Para proteger esses apps, use o acesso baseado no contexto do Google Workspace.
Gerenciamento de nível de acesso
As seções a seguir descrevem as práticas recomendadas para usar ao gerenciar níveis de acesso.
Criar níveis de acesso reutilizáveis
Os níveis de acesso são um recurso global e devem ser usados em todos os recursos da sua Google Cloud organização. Portanto, é melhor limitar o número geral de níveis de acesso e torná-los significativos e aplicáveis em vários recursos. Considere o seguinte:
- Evite incorporar os nomes de recursos ou apps específicos no nome de um nível de acesso.
- Evite codificar requisitos específicos de recursos ou de apps em um nível de acesso.
- Use nomes que afirmem uma determinada postura do usuário ou do dispositivo, como
Fully Trusted Device.
Usar níveis de acesso compostos
Para reduzir a sobrecarga de manutenção e garantir a consistência quando as sub-redes ou regiões mudam, não repita os mesmos requisitos em vários níveis de acesso. Em vez disso, deixe os níveis de acesso dependerem uns dos outros.
Por exemplo, não liste as mesmas regiões ou sub-redes IP confiáveis em vários níveis de acesso. Em vez disso, crie um nível de acesso adicional chamado Trusted location. Esse nível Trusted location pode servir
como uma dependência para os outros níveis de acesso.
Isentar usuários de acesso de emergência em níveis de acesso
Para evitar um bloqueio acidental, é melhor excluir pelo menos um usuário de acesso de emergência de todos os níveis de acesso. Para garantir que a isenção se aplique a todos os apps e recursos em que você aplica o nível de acesso, configure a isenção no próprio nível de acesso:
- Adicione uma condição que defina seus requisitos regulares.
- Adicione outra condição com um requisito de
membersque liste um ou mais usuários de acesso de emergência. - Defina a função de combinação como uma condição
ORpara que os usuários só precisem atender a uma das duas condições.
Por exemplo, o nível de acesso a seguir restringe o acesso a três regiões, mas
o usuário emergencyaccess@example.net está isento desse requisito:
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
Configurar uma mensagem de correção
Os usuários da sua organização talvez não saibam que a localização, o dispositivo e outros fatores podem afetar o acesso a determinados apps. Para manter os usuários informados e ajudar a reduzir as solicitações de suporte, configure uma mensagem de correção personalizada que mostre as etapas para recuperar o acesso.
Gerenciamento de vinculações de acesso
Com as vinculações de acesso, é possível configurar o acesso baseado no contexto para apps OAuth que usam um ou mais escopos Google Cloud . As vinculações de acesso também são uma maneira eficaz de aplicar o acesso baseado no contexto a apps de linha de negócios.
As seções a seguir descrevem as práticas recomendadas para usar vinculações de acesso.
Usar uma única vinculação de acesso com configurações de escopo
Ao usar vinculações de acesso, considere as seguintes restrições:
- Cada grupo do Cloud Identity pode ter no máximo uma vinculação de acesso.
- Se mais de uma vinculação de acesso se aplicar a um usuário, a menos restritiva terá precedência.
Para acomodar essas duas restrições, use uma única vinculação de acesso que se aplique a todos os seus usuários:
- Crie um grupo que contenha automaticamente todos os usuários da sua conta do Cloud Identity ou do Google Workspace.
- Crie ou use uma vinculação de acesso que associe um nível de acesso padrão ao grupo. O nível de acesso padrão é adequado para a maioria dos usuários, dispositivos e apps.
- Se necessário, use as configurações de acesso limitado (
scopedAccessSettings) para atribuir níveis de acesso mais fracos a apps selecionados.
Usar um nível de acesso padrão estrito
Se uma vinculação de acesso especificar uma configuração de acesso limitado e um nível de acesso padrão, os dois níveis serão combinados usando a semântica OR.
Esse comportamento tem as seguintes implicações:
- Um usuário só precisa atender a um dos níveis de acesso para acessar o app OAuth.
- Ao adicionar uma configuração de acesso limitado para um app OAuth, você pode reduzir os requisitos de acesso efetivos.
- Uma configuração de acesso limitado não tem efeito se usar um nível de acesso mais restrito do que o nível de acesso padrão da vinculação de acesso.
Ao selecionar um nível de acesso padrão para uma vinculação de acesso, recomendamos que você faça o seguinte:
- Use um nível de acesso restrito como padrão.
- Aplique níveis de acesso mais baixos a apps OAuth individuais usando configurações de acesso limitado.
Considere adicionar algumas ou todas as restrições a seguir ao nível de acesso padrão:
- Restrições de navegador e dispositivo: exija que os usuários acessem apps usando um navegador Chrome gerenciado e um dispositivo aprovado pelo administrador.
- Restrições geográficas: se a organização operar exclusivamente em determinadas regiões, use restrições de região para incluir apenas essas regiões na lista de permissões. Caso contrário, use restrições de região para limitar o acesso a regiões geográficas que estão sujeitas a sanções ou que não são relevantes por outros motivos.
- Restrições de rede IP: se os usuários da sua organização acessarem Google Cloud exclusivamente de determinadas redes ou se a organização usar um proxy de saída comum, inclua restrições de rede IP.
Não use níveis de acesso que exigem autenticação baseada em certificado como um nível de acesso padrão. A autenticação com base em certificados é mais adequada para regras de entrada de perímetro de serviço da VPC.
Gerenciar exceções por app
Para gerenciar exceções ao nível de acesso padrão, adicione exceções para apps individuais, em vez de usuários ou grupos.
Um nível de acesso padrão estrito pode ser adequado para a maioria dos apps, mas não para todos eles:
- Alguns apps podem ser menos sensíveis, e você precisa torná-los acessíveis para usuários que não atendem ao nível de acesso padrão. Por exemplo, apps que precisam estar acessíveis a parceiros, convidados ou ex-alunos.
- Alguns apps podem ser tecnicamente incompatíveis com uma das restrições impostas pelo nível de acesso padrão.
Para isentar apps individuais do nível de acesso padrão, use as configurações de acesso no escopo. Para cada app afetado, adicione uma configuração com escopo e atribua um nível de acesso mais adequado para o app individual.
Não crie outras vinculações de acesso para gerenciar exceções por usuário ou grupo. Outras vinculações de acesso podem causar os seguintes problemas:
- Você pode criar inadvertidamente vinculações de acesso sobrepostas.
- Pode ser difícil determinar quais requisitos de acesso baseado no contexto estão sendo aplicados de maneira eficaz para apps individuais.
Evitar vinculações de acesso sobrepostas
As vinculações de acesso são associadas a grupos. Se um usuário for membro de vários grupos, várias vinculações de acesso poderão ser aplicadas a ele. Nesse caso, os requisitos de acesso sensíveis ao contexto dessas vinculações de acesso são combinados usando a semântica OR.
Esse comportamento pode causar efeitos indesejados. Por exemplo, quando os usuários podem participar de outros grupos, a proteção de determinados apps pode ser prejudicada.
Para evitar essas situações, recomendamos que você não tenha vinculações de acesso sobrepostas:
- Minimize o número de vinculações de acesso, idealmente para uma.
- Se você precisar de várias vinculações de acesso, atribua-as a grupos que sejam mutuamente exclusivos.
Proteger grupos contra modificações não autorizadas
Por padrão, o Cloud Identity permite que os participantes saiam de um grupo. Esse comportamento é adequado para grupos de acesso, mas é problemático para grupos com vinculações de acesso associadas. Se um usuário sair de um grupo que tem uma vinculação de acesso associada, ele não estará mais sujeito aos requisitos de acesso baseados no contexto impostos pelas vinculações de acesso. Portanto, os usuários podem burlar os requisitos de acesso baseado no contexto ao sair de um grupo.
Sempre use grupos de imposição e não permita que os usuários saiam de um grupo de imposição ao configurar vinculações de acesso. Ou crie um grupo que contenha automaticamente todos os usuários da sua conta do Cloud Identity ou do Google Workspace.
Não permitir o acesso de usuários externos ao usar vinculações de acesso
As vinculações de acesso afetam apenas os usuários da conta do Cloud Identity ou do Google Workspace a que sua organização Google Cloud pertence. Esses usuários ainda estão sujeitos às vinculações de acesso na sua Google Cloud organização se tentarem acessar recursos em outras Google Cloud organizações. Essa aplicação de vinculações de acesso em usuários é diferente do comportamento em outros contextos com o Cloud Identity.
Se você permitir que usuários de contas externas do Cloud Identity ou do Google Workspace acessem recursos nas suas organizações do Google Cloud, as vinculações de acesso não terão efeito sobre esses usuários.
Para garantir que as vinculações de acesso sejam eficazes, não conceda a usuários externos acesso a apps ou recursos na sua organização do Google Cloud . Além disso, não adicione usuários externos a grupos na sua conta do Cloud Identity ou do Google Workspace.
Usar vinculações de acesso separadas para controle da duração da sessão
Além do controle de acesso baseado no contexto, também é possível usar vinculações de acesso para gerenciar a duração das sessões do navegador e dos tokens OAuth.
Ao usar vinculações de acesso para controlar o acesso baseado no contexto, é melhor evitar vinculações de acesso sobrepostas.
Ao usar vinculações de acesso para controlar a duração da sessão, não crie vinculações de acesso sobrepostas. Se mais de uma vinculação de acesso desse tipo se aplicar a um usuário, apenas a última vinculação atualizada vai entrar em vigor, o que pode levar a resultados indesejados.
Para evitar esses resultados indesejados, use uma vinculação de acesso separada para controlar a duração da sessão.
Não permitir que os usuários atuem como uma conta de serviço
As vinculações de acesso se aplicam aos usuários do Cloud Identity e do Google Workspace, mas não afetam as contas de serviço. Se você permitir que os usuários se autentiquem e atuem como uma conta de serviço, eles poderão prejudicar seus controles de acesso sensíveis ao contexto.
Outros riscos estão envolvidos quando os usuários podem agir como uma conta de serviço. Se você quiser permitir que os usuários elevem temporariamente os privilégios, recomendamos usar o Privileged Access Manager. Não use a representação de conta de serviço, exceto para fins de desenvolvimento.
Para mais informações sobre como proteger contas de serviço e chaves de conta de serviço, consulte Práticas recomendadas para usar contas de serviço e Práticas recomendadas para gerenciar chaves de conta de serviço.
Regras de entrada para perímetros de serviço da VPC
Com as regras de entrada, é possível conceder acesso baseado no contexto de fora do perímetro de serviço a recursos dentro dele. Os perímetros de serviço da VPC e as regras de entrada protegem os recursos do Google Cloud , não os apps individuais. Portanto, um perímetro de serviço com regras de entrada é ideal para aplicar o acesso sensível ao contexto a ferramentas administrativas, como o console Google Cloud e a CLI gcloud.
Para mais informações e práticas recomendadas sobre perímetros de serviço da VPC, consulte Práticas recomendadas para ativar o VPC Service Controls.
As seções a seguir descrevem as práticas recomendadas para usar regras de entrada para aplicar o acesso sensível ao contexto.
Incluir o encaminhamento de TCP do IAP como um serviço restrito
Pode ser arriscado permitir que os usuários se conectem a instâncias de VM no perímetro de serviço usando SSH ou RDP pelos seguintes motivos:
- Suas regras de entrada não se aplicam às conexões porque o uso de SSH e RDP não envolve acesso a nenhuma API do Google.
- Depois que os usuários estabelecem uma sessão SSH ou RDP, qualquer acesso à API iniciado de dentro dessa sessão é considerado originado de dentro do perímetro de serviço. Portanto, as regras de entrada não se aplicam a nenhum acesso à API iniciado nessa sessão.
Para reduzir esses riscos, permita o acesso SSH e RDP às VMs apenas pelo encaminhamento de TCP do IAP:
- Inclua o
serviço
iaptunnel.googleapis.comcomo um serviço restrito. - Configure regras de firewall que restringem o acesso às portas SSH e RDP pelo encaminhamento TCP da IAP.
Use o encaminhamento TCP do IAP para garantir que a configuração das regras de entrada do perímetro de serviço da VPC se aplique a todas as tentativas de acesso SSH e RDP.
Usar o acesso baseado em certificado para perímetros de serviço sensíveis
Por padrão, os tokens de acesso e de atualização do Google não estão vinculados a um dispositivo e podem ficar vulneráveis a roubo ou ataques de repetição. Para ajudar a reduzir esses riscos, use o acesso com base em certificado (CBA), que restringe o acesso a dispositivos com um certificado X.509 confiável.
A CBA ajuda a reforçar a segurança, mas essa abordagem também adiciona outros requisitos de infraestrutura:
- O dispositivo de um usuário precisa ter um certificado X.509 emitido por uma autoridade de certificação interna.
- A chave associada ao certificado precisa ser armazenada de forma a evitar a exportação não autorizada.
- Os apps clientes precisam usar a autenticação TLS mútua (mTLS) para se conectar às APIsGoogle Cloud .
Use a CBA para proteger o acesso aos perímetros de serviço da VPC mais sensíveis. Essa abordagem permite equilibrar a força da segurança com requisitos mínimos de infraestrutura e impacto geral.
Colaboradores
Autor: Johannes Passing | Arquiteto de soluções na nuvem
Outro colaborador: Ido Flatow | Arquiteto de soluções do Cloud