Este documento descreve as práticas recomendadas para usar o acesso baseado no contexto e proteger seus Google Cloud recursos 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, no local da rede, na localização 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 mais 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 Google Cloud recursos, você pode definir um controle de acesso granular com base em uma variedade e combinação de fatores contextuais. 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 de Google Cloud recursos e apps. Este documento pressupõe que você já esteja familiarizado com o Access Context Manager, Google Cloud, e 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: esses apps permitem que os usuários gerenciem ou interajam com Google Cloud recursos como instâncias de VM, conjuntos de dados do BigQuery ou buckets do Cloud Storage. Exemplos de apps administrativos incluem o Google Cloud console, a Google Cloud CLI, o Terraform e o IAP Desktop.
- Apps de linha de negócios: esses apps incluem apps da Web executados em 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 processam a autenticação e a 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 que você implantou por trás do IAP.
- OAuth: apps da Web ou de computador personalizados que usam o OAuth 2.0 e um ou mais Google Cloud escopos do OAuth.
O fluxograma a seguir mostra a abordagem de acesso baseado no contexto mais adequada para cada tipo de app:
O diagrama mostra os seguintes tipos de apps:
Apps administrativos: geralmente, é mais importante proteger os Google Cloud recursos que o app administrativo facilita o acesso a, em vez do próprio app. Considere os seguintes cenários:
- Um usuário não consegue acessar nenhum dos recursos. Nesse cenário, é provável que ter 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 consegue acessar um app administrativo. Nesse cenário, ele pode 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 os controles de acesso baseado no contexto aos recursos da maneira mais eficaz, use perímetros de serviço da nuvem privada virtual (VPC) com as regras de entrada adequadas. Você pode 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 próprios apps, bem como 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 o SAML: semelhante aos apps de linha de negócios que usam o OAuth, é importante proteger o acesso aos próprios apps, bem como 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 próprios apps, bem como aos recursos que eles podem usar. Para proteger esses apps, use o acesso baseado no contexto do Google Workspace.
Gerenciamento do 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 a 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 apps em um nível de acesso.
- Use nomes que afirmem uma determinada postura de usuário ou dispositivo, como
Fully Trusted Device.
Usar níveis de acesso compostos
Para ajudar a 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, permita que os níveis de acesso dependam uns dos outros.
Por exemplo, não liste as mesmas regiões confiáveis
ou sub-redes IP em vários níveis de acesso, mas 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 aos quais 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 normais.
- Adicione outra condição com um
membersrequisito que 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 podem não estar cientes de que a localização, o dispositivo e outros fatores podem afetar se eles têm permissão para acessar determinados apps ou não. Para manter os usuários informados e ajudar a reduzir as solicitações de suporte, configure uma mensagem de correção personalizada que forneça aos usuários as etapas necessárias para recuperar o acesso.
Gerenciamento de vinculações de acesso
As vinculações de acesso permitem configurar o acesso baseado no contexto para apps OAuth que usam um ou mais Google Cloud escopos. As vinculações de acesso também são uma maneira eficaz de aplicar o acesso baseado no contexto para apps de linha de negócios.
As seções a seguir descrevem as práticas recomendadas para usar ao usar vinculações de acesso.
Usar uma única vinculação de acesso com configurações no escopo
Ao usar vinculações de acesso, você precisa considerar 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 vinculação de acesso menos restritiva terá precedência.
Para acomodar essas duas restrições, use uma única vinculação de acesso que se aplique a todos os 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 precisa ser adequado para a maioria dos usuários, dispositivos e apps.
- Se necessário, use
configurações de acesso no escopo (
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 no escopo e um nível de acesso padrão, os dois níveis de acesso serão combinados usando a semântica OR.
Esse comportamento tem as seguintes implicações:
- Um usuário precisa atender apenas a um dos níveis de acesso para acessar o app OAuth.
- Ao adicionar uma configuração de acesso no escopo para um app OAuth, você pode reduzir os requisitos de acesso eficazes.
- Uma configuração de acesso no escopo não tem efeito se usar um nível de acesso mais estrito 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 estrito como o nível de acesso padrão.
- Aplique níveis de acesso mais baixos a apps OAuth individuais usando configurações de acesso no escopo.
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 sua organização opera 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, você pode usar restrições de região para restringir o acesso a regiões que têm 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, você poderá incluir 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 baseada em certificado é 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 exceções para 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 os seus apps:
- Alguns apps podem ser menos sensíveis, e você precisa torná-los acessíveis a usuários que não atendem ao nível de acesso padrão. Exemplos podem incluir apps que precisam estar acessíveis a parceiros, convidados ou ex-alunos.
- Alguns apps podem ser tecnicamente incompatíveis com uma das restrições aplicadas pelo nível de acesso padrão.
Para isentar apps individuais do nível de acesso padrão, use configurações de acesso no escopo. Para cada app afetado, adicione uma configuração no escopo e atribua um nível de acesso mais adequado ao app individual.
Não crie vinculações de acesso adicionais para gerenciar exceções por usuário ou grupo. Vinculações de acesso adicionais podem causar os seguintes problemas:
- Você pode criar vinculações de acesso sobrepostas inadvertidamente.
- 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 estã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 baseado no 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ê evite 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 mutuamente exclusivos.
Proteger grupos contra modificação não autorizada
Por padrão, o Cloud Identity permite que os membros do grupo 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 baseado no contexto impostos pelas vinculações de acesso. Portanto, os usuários podem contornar os requisitos de acesso baseado no contexto saindo de um grupo.
Sempre use grupos de aplicação e não permita que os usuários saiam de um grupo de aplicação ao configurar vinculações de acesso. Como alternativa, crie um grupo que contenha automaticamente todos os usuários da sua conta do Cloud Identity ou do Google Workspace.
Não permitir 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 Google Cloud organização 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 aos 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 Google Cloud organizações, as vinculações de acesso não terão efeito nesses usuários.
Para garantir que as vinculações de acesso sejam eficazes, não conceda acesso a usuários externos a nenhum app ou recurso na sua Google Cloud organização. 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 de duração da sessão
Além do controle de acesso baseado no contexto, você também pode 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 vinculação de acesso atualizada mais recentemente 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 a usuários do Cloud Identity e do Google Workspace, mas não afetam 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 baseado no contexto.
Outros riscos estão envolvidos quando os usuários podem atuar como uma conta de serviço. Se você quiser permitir que os usuários elevem temporariamente os privilégios, recomendamos que use o Privileged Access Manager. Não use a identidade temporária 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 conta de serviço serviço.
Regras de entrada para perímetros de serviço da VPC
As regras de entrada permitem conceder acesso baseado no contexto de fora do perímetro de serviço a recursos dentro do perímetro. Os perímetros de serviço da VPC e as regras de entrada protegem Google Cloud recursos, não apps individuais. Portanto, um perímetro de serviço com regras de entrada é ideal para aplicar o acesso baseado no contexto para ferramentas administrativas, como o Google Cloud console 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 quando você usa regras de entrada para aplicar o acesso baseado no 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:
- As regras de entrada não se aplicam às conexões porque o uso de SSH e RDP não envolve nenhum acesso à API do Google.
- Depois que os usuários estabelecem uma sessão SSH ou RDP, qualquer acesso à API iniciado nessa sessão é considerado originário 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 a VMs apenas pelo encaminhamento de TCP do IAP:
- Inclua o
iaptunnel.googleapis.comserviço como um serviço restrito. - Configure regras de firewall que restringem o acesso às portas SSH e RDP pelo encaminhamento de TCP do IAP.
Use o encaminhamento de 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 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 ser vulneráveis a roubo ou ataques de repetição. Para ajudar a reduzir esses riscos, você pode usar o acesso baseado em certificado (CBA, na sigla em inglês), que restringe o acesso a dispositivos que possuem um certificado X.509 confiável.
O CBA ajuda a fortalecer a segurança, mas essa abordagem também adiciona requisitos de infraestrutura adicionais:
- 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 uma maneira que impeça a exportação não autorizada.
- Os apps cliente precisam usar a autenticação TLS mútua (mTLS) para se conectar às Google Cloud APIs.
Use o 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 na nuvem