Este documento descreve as práticas recomendadas para usar o acesso sensível ao contexto de modo a ajudar a proteger os seus Google Cloud recursos de forma eficaz. O acesso sensível ao contexto é uma abordagem de segurança em que controla o acesso dos utilizadores com base na respetiva força de autenticação, postura do dispositivo, localização de rede, localização geográfica ou outros atributos. Esta abordagem vai além da utilização de identidades de utilizadores básicas para acesso de segurança e pode ajudar a implementar um modelo de segurança de confiança zero para melhorar a sua postura de segurança geral. Para ver detalhes sobre como implementar o acesso sensível ao contexto para diferentes tipos de apps e recursos, consulte o artigo Proteja apps e recursos através do acesso sensível ao contexto.
Para ajudar a proteger as suas apps e Google Cloud recursos, pode definir um controlo de acesso detalhado com base numa variedade e combinação de fatores contextuais. Pode usar o Gestor de contexto de acesso para definir políticas de acesso, que contêm níveis de acesso e parâmetros de serviço.
Este documento destina-se a todos os profissionais de segurança responsáveis pela gestão de identidade e acesso (IAM) e pela segurança dos Google Cloud recursos e das apps. Este documento pressupõe que já conhece o Access Context Manager, Google Cloude a gestão do IAM.
Abordagens de acesso sensível ao contexto
Quando configura o acesso sensível ao contexto na sua organização, tem de decidir se quer aplicar controlos de acesso sensível ao contexto a apps, recursos ou ambos. Para tomar essa decisão, é útil distinguir entre os seguintes diferentes tipos de apps e serviços:
- Apps administrativas: estas apps permitem que os utilizadores façam a gestão ou interajam comGoogle Cloud recursos, como instâncias de VMs, conjuntos de dados do BigQuery ou contentores do Cloud Storage. Exemplos de apps administrativas: incluem a Google Cloud consola, a CLI Google Cloud, o Terraform e o IAP Desktop.
- Apps de linha de negócio: estas apps incluem apps Web que são executadas no Google Cloud e usam SAML ou Identity-Aware Proxy (IAP) para autenticação e autorização. Por vezes, estas apps são designadas apps internas. Exemplos de apps de linha de negócio incluem sistemas de CRM, painéis de controlo e outras apps personalizadas.
- Google Workspace e outros serviços Google: estes serviços são fornecidos pela Google, mas não estão relacionados com o Google Cloud.
Pode distinguir ainda mais as apps de linha de negócio com base na forma como processam a autenticação e a autorização:
- SAML: apps que usam o SAML do Google Workspace para autenticação. As apps de SaaS enquadram-se frequentemente nesta categoria.
- CNA: apps Web personalizadas que implementou atrás do CNA.
- OAuth: apps Web ou de computador personalizadas que usam o OAuth 2.0 e usam um ou mais Google Cloud âmbitos do OAuth.
O diagrama de fluxo seguinte mostra a abordagem de acesso com reconhecimento do contexto mais adequada para cada tipo de app:
O diagrama mostra os seguintes tipos de apps:
Apps administrativas: geralmente, é mais importante proteger os Google Cloud recursos aos quais a app administrativa facilita o acesso do que a própria app. Considere os seguintes cenários:
- Um utilizador não consegue aceder a nenhum dos recursos. Neste cenário, é provável que ter acesso a uma app administrativa não seja tão valioso para o utilizador.
- Um utilizador tem acesso a um recurso, mas não consegue aceder a uma app administrativa. Neste cenário, pode conseguir encontrar uma app administrativa diferente que não esteja bloqueada e que lhe permita aceder ao recurso.
Por conseguinte, para apps administrativas, adote uma abordagem centrada nos recursos. Para aplicar os controlos de acesso sensíveis ao contexto certos aos recursos da forma mais eficaz, use perímetros de serviço da nuvem virtual privada (VPC) com as regras de entrada adequadas. Pode complementar os perímetros de serviço da VPC com associações de acesso.
Apps empresariais que usam OAuth: para estas apps, é importante proteger o acesso às próprias apps, bem como aos recursos que as apps possam usar. Para proteger as apps através do acesso sensível ao contexto, use associações de acesso.
Apps de linha de negócio que usam a IAP: embora a IAP use o OAuth, não pode usar associações de acesso para proteger apps que usam a IAP para autenticar utilizadores. Em alternativa, proteja estas apps através de condições do IAM.
Apps de linha de negócio que usam SAML: semelhante às apps de linha de negócio que usam OAuth, é importante proteger o acesso às próprias apps, bem como aos recursos que as apps possam usar. Para proteger estas apps, use o acesso sensível ao contexto do Google Workspace.
Google Workspace e outros serviços Google: para estas apps, é importante proteger o acesso às próprias apps, bem como aos recursos que as apps possam usar. Para proteger estas apps, use o acesso sensível ao contexto do Google Workspace.
Gestão de níveis de acesso
As secções seguintes descrevem as práticas recomendadas a usar quando gerir os níveis de acesso.
Crie níveis de acesso reutilizáveis
Os níveis de acesso são um recurso global e destinam-se a ser usados em todos os recursos da sua Google Cloud organização. Por isso, é melhor limitar o número total 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 num nível de acesso.
- Use nomes que afirmem uma determinada postura do utilizador ou do dispositivo, como
Fully Trusted Device.
Use níveis de acesso compostos
Para ajudar a reduzir os custos gerais de manutenção e garantir a consistência quando as sub-redes ou as 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 fidedignas nem as sub-redes IP em vários níveis de acesso. Em alternativa, crie um nível de acesso adicional denominado Trusted location. Este nível Trusted location pode servir como dependência para os outros níveis de acesso.
Isente utilizadores de acesso de emergência nos níveis de acesso
Para evitar um bloqueio acidental, é melhor excluir, pelo menos, um utilizador de acesso de emergência de todos os níveis de acesso. Para garantir que a isenção se aplica a todas as apps e recursos aos quais aplica o nível de acesso, configure a isenção no próprio nível de acesso:
- Adicione uma condição que defina os seus requisitos normais.
- Adicione outra condição com um
membersrequisito que liste um ou mais dos seus utilizadores de acesso de emergência. - Defina a função de combinação para uma
ORcondição para que os utilizadores só tenham de cumprir uma das duas condições.
Por exemplo, o seguinte nível de acesso restringe o acesso a três regiões, mas o utilizador emergencyaccess@example.net está isento deste requisito:
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
Configure uma mensagem de remediação
Os utilizadores na sua organização podem não saber que a respetiva localização, dispositivo e outros fatores podem afetar a autorização de acesso a determinadas apps. Para manter os utilizadores informados e ajudar a reduzir os pedidos de apoio técnico, configure uma mensagem de correção personalizada que indique aos utilizadores os passos a seguir para recuperarem o acesso.
Gestão de associações de acesso
As associações de acesso permitem-lhe configurar o acesso sensível ao contexto para apps OAuth que usam um ou mais Google Cloud âmbitos. As associações de acesso também são uma forma eficaz de aplicar o acesso sensível ao contexto para apps de linha de negócio.
As secções seguintes descrevem as práticas recomendadas a usar quando usa associações de acesso.
Use uma única associação de acesso com definições no âmbito
Quando usa associações de acesso, tem de considerar as seguintes restrições:
- Cada grupo do Cloud Identity pode ter, no máximo, uma associação de acesso.
- Se mais do que uma associação de acesso se aplicar a um utilizador, a associação de acesso menos restritiva tem precedência.
Para ter em conta estas duas restrições, use uma única associação de acesso que se aplique a todos os seus utilizadores:
- Crie um grupo que contenha automaticamente todos os utilizadores da sua conta do Cloud ID ou Google Workspace.
- Crie ou use uma associação de acesso que associe um nível de acesso predefinido ao grupo. O nível de acesso predefinido deve ser adequado para a maioria dos utilizadores, dispositivos e apps.
- Se necessário, use as
definições de acesso com âmbito (
scopedAccessSettings) para atribuir níveis de acesso mais fracos a apps selecionadas.
Usar um nível de acesso predefinido rigoroso
Se uma associação de acesso especificar uma definição de acesso com âmbito e um nível de acesso predefinido, os dois níveis de acesso são combinados através da semântica OR.
Este comportamento tem as seguintes implicações:
- Um utilizador só tem de cumprir um dos níveis de acesso para aceder à app OAuth.
- Quando adiciona uma definição de acesso restrito para uma app OAuth, pode reduzir os requisitos de acesso efetivos.
- Uma definição de acesso com âmbito não tem efeito se usar um nível de acesso que seja mais restrito do que o nível de acesso predefinido da associação de acesso.
Quando seleciona um nível de acesso predefinido para uma associação de acesso, recomendamos que faça o seguinte:
- Usar um nível de acesso restrito como nível de acesso predefinido.
- Aplique níveis de acesso mais baixos a apps OAuth individuais através das definições de acesso com âmbito.
Pondere adicionar algumas ou todas as seguintes restrições ao nível de acesso predefinido:
- Restrições de navegador e dispositivo: exija que os seus utilizadores acedam às apps através de um navegador Chrome gerido e de um dispositivo aprovado pelo administrador.
- Restrições geográficas: se a sua organização operar exclusivamente em determinadas regiões, use restrições de regiões para incluir apenas essas regiões na lista de autorizações. Caso contrário, pode usar restrições de regiões para restringir o acesso a geografias que tenham sanções contra si ou que não sejam relevantes por outros motivos.
- Restrições de rede IP: se os utilizadores na sua organização acederem ao Google Cloud conteúdo exclusivamente a partir de determinadas redes ou se a sua organização usar um proxy de saída comum, pode incluir restrições de rede IP.
Não use níveis de acesso que exijam autenticação baseada em certificados como um nível de acesso predefinido. A autenticação baseada em certificados é mais adequada para regras de entrada do perímetro de serviço da VPC.
Faça a gestão de exceções por app
Para gerir exceções ao nível de acesso predefinido, adicione exceções para apps individuais, em vez de exceções para utilizadores ou grupos.
Um nível de acesso predefinido rigoroso pode ser adequado para a maioria das apps, mas não para todas as suas apps:
- Algumas apps podem ser menos sensíveis e tem de as tornar acessíveis a utilizadores que não cumprem o nível de acesso predefinido. Os exemplos podem incluir apps que têm de estar acessíveis a parceiros, convidados ou antigos alunos.
- Algumas apps podem ser tecnicamente incompatíveis com uma das restrições aplicadas pelo nível de acesso predefinido.
Para isentar apps individuais do nível de acesso predefinido, use definições de acesso com âmbito. Para cada app afetada, adicione uma definição com âmbito e atribua um nível de acesso mais adequado para a app individual.
Não crie associações de acesso adicionais para gerir exceções por utilizador ou grupo. As associações de acesso adicionais podem causar os seguintes problemas:
- Pode criar inadvertidamente associações de acesso sobrepostas.
- Pode tornar-se difícil determinar que requisitos de acesso sensível ao contexto estão a ser aplicados de forma eficaz a apps individuais.
Evite associações de acesso sobrepostas
As associações de acesso estão associadas a grupos. Se um utilizador for membro de vários grupos, podem aplicar-se-lhe várias associações de acesso. Neste caso, os requisitos de acesso sensíveis ao contexto destas associações de acesso são combinados através da semântica OR.
Este comportamento pode causar efeitos não intencionais. Por exemplo, quando os utilizadores têm autorização para aderir a grupos adicionais, a proteção de determinadas apps pode ser comprometida.
Para ajudar a evitar estas situações, recomendamos que evite associações de acesso sobrepostas:
- Minimize o número de associações de acesso, idealmente para uma.
- Se precisar de várias associações de acesso, atribua-as a grupos que sejam mutuamente exclusivos.
Proteja os grupos contra modificações não autorizadas
Por predefinição, o Cloud Identity permite que os membros de um grupo saiam do mesmo. Este comportamento é adequado para grupos de acesso, mas é problemático para grupos com associações de acesso associadas. Se um utilizador sair de um grupo que tenha uma associação de acesso associada, deixa de estar sujeito aos requisitos de acesso sensíveis ao contexto impostos pelas associações de acesso. Por conseguinte, os utilizadores podem contornar os requisitos de acesso sensível ao contexto ao sair de um grupo.
Use sempre grupos de aplicação e não permita que os utilizadores saiam de um grupo de aplicação quando configurar associações de acesso. Em alternativa, crie um grupo que contenha automaticamente todos os utilizadores da sua conta do Cloud ID ou Google Workspace.
Não permita o acesso de utilizadores externos quando usar associações de acesso
As associações de acesso só afetam os utilizadores da conta do Cloud ID ou do Google Workspace à qual a sua Google Cloud organização pertence. Estes utilizadores continuam sujeitos às associações de acesso na sua Google Cloud organização se tentarem aceder a recursos noutras organizações Google Cloud . Esta aplicação de associações de acesso aos utilizadores é diferente do comportamento noutros contextos com o Cloud ID.
Se permitir que utilizadores de contas externas do Cloud ID ou do Google Workspace acedam a recursos nas suas organizações, as associações de acesso não têm efeito nesses utilizadores. Google Cloud
Para ajudar a garantir que as associações de acesso são eficazes, não conceda acesso a utilizadores externos a apps nem recursos na sua organização. Google Cloud Além disso, não adicione utilizadores externos a grupos na sua conta do Cloud ID ou do Google Workspace.
Use associações de acesso separadas para o controlo da duração da sessão
Além do controlo de acesso sensível ao contexto, também pode usar associações de acesso para gerir a duração das sessões do navegador e dos tokens OAuth.
Quando usa associações de acesso para controlar o acesso sensível ao contexto, é melhor evitar associações de acesso sobrepostas.
Quando usar associações de acesso para controlar a duração da sessão, não crie associações de acesso sobrepostas. Se mais do que uma associação de acesso deste tipo se aplicar a um utilizador, apenas a associação de acesso atualizada mais recentemente entra em vigor, o que pode gerar resultados não intencionais.
Para ajudar a evitar estes resultados não intencionais, use uma associação de acesso separada para controlar a duração da sessão.
Não permitir que os utilizadores atuem como uma conta de serviço
As associações de acesso aplicam-se aos utilizadores do Cloud ID e do Google Workspace, mas não afetam as contas de serviço. Se permitir que os utilizadores se autentiquem e atuem como uma conta de serviço, podem conseguir comprometer os seus controlos de acesso sensíveis ao contexto.
Existem outros riscos envolvidos quando os utilizadores podem agir como uma conta de serviço. Se quiser permitir que os utilizadores elevem temporariamente os respetivos privilégios, recomendamos que use o Gestor de acesso privilegiado. Não use a simulação da conta de serviço, exceto para fins de desenvolvimento.
Para mais informações sobre como proteger as contas de serviço e as chaves das contas de serviço, consulte as práticas recomendadas para usar contas de serviço e as práticas recomendadas para gerir chaves de contas de serviço.
Regras de entrada para perímetros de serviço da VPC
As regras de entrada permitem-lhe conceder acesso sensível ao 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 os Google Cloud recursos, não as apps individuais. Por conseguinte, um perímetro de serviço com regras de entrada é ideal para aplicar o acesso sensível ao contexto a ferramentas administrativas, como a consola e a CLI gcloud. Google Cloud
Para mais informações e práticas recomendadas acerca dos perímetros de serviço da VPC, consulte o artigo Práticas recomendadas para ativar os VPC Service Controls.
As secções seguintes descrevem as práticas recomendadas para quando usa regras de entrada para aplicar o acesso sensível ao contexto.
Inclua o encaminhamento TCP da IAP como um serviço restrito
Pode ser arriscado permitir que os utilizadores estabeleçam ligação a instâncias de VM no seu perímetro de serviço através do SSH ou do RDP pelos seguintes motivos:
- As suas regras de entrada não se aplicam às ligações porque a utilização de SSH e RDP não envolve o acesso a nenhuma API Google.
- Depois de os utilizadores estabelecerem uma sessão SSH ou RDP, qualquer acesso à API iniciado a partir dessa sessão é considerado como tendo origem no perímetro do serviço. Por conseguinte, as suas regras de entrada não se aplicam a nenhum acesso à API iniciado a partir dessa sessão.
Para mitigar estes riscos, permita o acesso SSH e RDP às VMs apenas através do encaminhamento 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 através do encaminhamento TCP do IAP.
Use o encaminhamento TCP do IAP para ajudar a garantir que a configuração das regras de entrada do perímetro de serviço da VPC se aplica a todas as tentativas de acesso SSH e RDP.
Use o acesso baseado em certificados para perímetros de serviço sensíveis
Por predefinição, as chaves de acesso e as chaves de atualização da Google não estão associadas a um dispositivo e podem ser vulneráveis a roubo ou ataques de repetição. Para ajudar a mitigar estes riscos, pode usar o acesso baseado em certificados (CBA), que restringe o acesso a dispositivos que possuem um certificado X.509 fidedigno.
A CBA ajuda a reforçar a segurança, mas esta abordagem também adiciona requisitos de infraestrutura adicionais:
- O dispositivo de um utilizador tem de ter um certificado X.509 emitido por uma autoridade de certificação interna.
- A chave associada ao certificado tem de ser armazenada de forma a impedir a exportação não autorizada.
- As apps cliente têm de usar a autenticação TLS mútua (mTLS) para se ligarem às Google Cloud APIs.
Use a CBA para proteger o acesso aos seus perímetros de serviço da VPC mais sensíveis. Esta abordagem permite-lhe equilibrar a força da segurança com requisitos de infraestrutura mínimos e impacto geral.
Colaboradores
Autor: Johannes Passing | Arquiteto de soluções na nuvem
Outro colaborador: Ido Flatow | Arquiteto de soluções na nuvem