Este artigo descreve casos de uso comuns de acesso baseado no contexto e inclui exemplos das configurações desenvolvidas no Modo básico.
Para ver exemplos dos níveis de acesso desenvolvidos no Modo avançado (usando o editor de CEL), acesse Exemplos de acesso baseado no contexto no Modo avançado.
Permitir o acesso dos prestadores de serviços apenas na rede corporativa
Muitas empresas restringem o acesso dos prestadores de serviços aos recursos corporativos. Por exemplo, empresas que usam contratados para atender ligações de suporte geral ou trabalhar em centrais de ajuda e call centers. Assim como os funcionários em tempo integral, os prestadores de serviços precisam ter uma licença compatível para serem cobertos pelas políticas de Acesso baseado no contexto.
Neste exemplo, os prestadores de serviços só têm acesso aos recursos corporativos de um intervalo de endereços IP corporativos específico.
| Nome do nível de acesso | contractor_access |
| Um prestador de serviços terá acesso se | tiver os atributos |
| Atributo da condição 1 | Sub-rede IP (pública) 74.125.192.0/18 |
| Atribuição de nível de acesso | Unidades organizacionais para prestadores de serviços Todos os apps que os prestadores de serviços usam |
Bloquear o acesso de endereços IP de invasores conhecidos
Para proteger os recursos da empresa contra comprometimento, muitas empresas bloqueiam o acesso a fontes conhecidas de alto risco.
Neste exemplo, o endereço IP 74.125.195.105 está bloqueado. Os usuários têm acesso aos recursos corporativos se as sessões forem originadas de qualquer outro endereço IP. É possível especificar vários endereços IP e intervalos.
| Nome do nível de acesso | block_highrisk |
| Um usuário vai ter acesso se: | não cumprirem os atributos |
| Atributo da condição 1 | Sub-rede IP (pública) 74.125.195.105 |
| Atribuição de nível de acesso | Unidade organizacional de nível superior Todos os apps |
Permitir o acesso de uma rede particular específica no Google Cloud
Muitas empresas encaminham o tráfego de usuários para o Google por uma nuvem privada virtual (VPC). Uma VPC é uma rede segura e isolada no ambiente do Google Cloud.
O tráfego roteado pela VPC pode usar endereços IP particulares. Isso pode causar problemas com políticas de IP público ou de região.
Neste exemplo, é possível permitir o tráfego dessas VPCs específicas.
| Nome do nível de acesso | vpc_access |
| Um usuário terá acesso se | tiver os atributos |
| Atributos de condição 1 |
Sub-rede IP (particular) Sub-rede IP particular: //compute.googleapis.com/projects/project- name-test/global/networks/network-name Sub-rede VPC: 74.125.192.0/18 |
| Atribuição de nível de acesso |
Unidades organizacionais para todos os usuários Todos os apps que os prestadores de serviços usam |
Lembretes importantes:
- Somente tráfego direto: esse nível de acesso funciona apenas para tráfego que chega diretamente aos servidores do Google pela VPC na lista de permissões. Se o tráfego passar por outra rede ou túnel primeiro, o acesso não será concedido. O Google só reconhece a última VPC que envia o tráfego para os servidores dele.
- Permissões de administrador: para ver as VPCs e configurar esse nível de acesso, os administradores precisam ter o papel apropriado do Identity and Access Management (IAM) (por exemplo, compute.networks.list, compute.subnetworks.list, e assim por diante).
- VPCs externas: a VPC que você coloca na lista de permissões pode ser de fora do seu domínio atual do Google Cloud. Um administrador precisa ter permissão de visualização para adicionar a VPC externa.
Permitir ou proibir o acesso de locais específicos
Se você tiver funcionários que viajam regularmente para escritórios corporativos ou de parceiros remotos, especifique os locais geográficos em que eles podem acessar os recursos corporativos.
Por exemplo, se um grupo de vendedores visita regularmente clientes na Austrália e na Índia, você pode limitar o acesso do grupo ao escritório em casa e à Austrália e à Índia. Se os funcionários da equipe viajarem para outros países de férias como parte de uma viagem de negócios, eles não poderão acessar recursos corporativos nesses países.
Neste exemplo, o grupo de vendas só pode acessar os recursos corporativos dos EUA (home office), da Austrália e da Índia.
| Nome do nível de acesso | sales_access |
| A equipe de vendas terá acesso se | tiver os atributos |
| Atributo da condição 1 | Origem geográfica Austrália, EUA, Índia |
| Atribuição de nível de acesso | Grupo de vendedores Todos os apps que os vendedores usam |
Você também pode criar uma política para negar o acesso de países específicos especificando que os usuários terão acesso se não atenderem às condições. Você listaria os países de que quer bloquear o acesso.
Usar níveis de acesso aninhados em vez de selecionar vários níveis de acesso durante a atribuição
Em alguns casos, ao tentar atribuir níveis de acesso a uma determinada unidade organizacional ou grupo e a um aplicativo (ou um conjunto de aplicativos), você pode receber uma mensagem de erro pedindo para reduzir o número de aplicativos ou níveis de acesso.
Para evitar esse erro, reduza o número de níveis de acesso usados durante a atribuição aninhando-os em um único nível de acesso. O nível de acesso aninhado combina várias condições com uma operação OR, e cada condição contém um nível de acesso individual.
Neste exemplo, "Oeste dos EUA", "Leste dos EUA" e "Centro dos EUA" estão em três níveis de acesso separados. Digamos que você queira que os usuários possam acessar aplicativos se atenderem a qualquer um dos níveis de acesso USWest, USEast ou USCentral.É possível criar um único nível de acesso aninhado (chamado USRegions) usando o operador OR. Ao atribuir os níveis de acesso, atribua o nível USRegions ao aplicativo para a unidade organizacional ou o grupo.
|
Nome do nível de acesso |
Regiões dos EUA |
|
Um usuário terá acesso se: |
tiver os atributos |
|
Atributo da condição 1 (apenas um nível de acesso por condição) |
Nível de acesso USWest |
|
Unir a condição 1 e a condição 2 com |
OU |
|
Um usuário terá acesso se: |
tiver os atributos |
|
Atributo da condição 2 |
Nível de acesso USEast |
|
Combine a condição 2 e a condição 3 com |
OU |
|
Um usuário terá acesso se: |
tiver os atributos |
|
Atributo da condição 3 |
Nível de acesso USCentral |
Exigir computadores da empresa, mas não dispositivos móveis
Uma empresa pode exigir computadores que pertençam a ela, mas não um dispositivo móvel corporativo.
Primeiro, crie um nível de acesso para os computadores:
|
Nome do nível de acesso |
aldesktop_access |
|
Os usuários terão acesse se |
tiver os atributos |
|
Atributo da condição 1 |
Política do dispositivo
Criptografia do dispositivo = não compatível Sistema operacional do dispositivo macOS = 0.0.0 Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
Em seguida, crie um nível de acesso para os dispositivos móveis:
|
Nome do nível de acesso |
almobile_access |
|
Os usuários terão acesse se |
tiver os atributos |
|
Atributo da condição 1 |
Sistema operacional do dispositivo iOS = 0.0.0 Android = 0.0.0 |
Exigir segurança básica do dispositivo
A maioria das empresas agora exige que os funcionários acessem recursos corporativos em dispositivos criptografados e que atendam às versões mínimas do sistema operacional. Algumas também exigem o uso de dispositivos da empresa.
Você pode configurar essas políticas para todas as suas unidades organizacionais ou apenas para aquelas que acessam dados sensíveis, como executivos, departamento financeiro ou recursos humanos.
Há várias maneiras de configurar uma política que inclua criptografia de dispositivo, versão mínima do sistema operacional e dispositivos da empresa. Cada uma delas tem vantagens e desvantagens.
Um nível de acesso que contém todos os requisitos de segurança
Neste exemplo, os atributos "Criptografia do dispositivo", "Versão mínima do sistema operacional" e "Dispositivo da empresa" estão incluídos em um nível de acesso. Os usuários precisam atender a todas as condições para ter acesso.
Por exemplo, se um dispositivo criptografado e de propriedade da empresa não executar uma versão compatível do sistema operacional, o acesso será negado.
Vantagem: fácil de configurar. Quando você atribui esse nível de acesso a um app, o usuário precisa atender a todos os requisitos.
Desvantagem: para atribuir separadamente os requisitos de segurança a diferentes unidades organizacionais, é necessário criar um nível de acesso separado para cada requisito.
| Nome do nível de acesso | device_security |
| Um usuário terá acesso se: | tiver os atributos |
| Atributo da condição 1 (Você pode adicionar todos os atributos a uma condição ou criar três condições e uni-las com E.) |
Política de dispositivo Sistema operacional do dispositivo |
Três níveis de acesso separados
Neste exemplo, os atributos "Criptografia do dispositivo", "Versão mínima do sistema operacional" e "Dispositivo da empresa" estão em três níveis de acesso separados. Os usuários precisam atender às condições em apenas um nível para ter acesso. É um operador lógico "OR" de níveis de acesso.
Por exemplo, um usuário que tem um dispositivo criptografado e executa uma versão mais antiga do sistema operacional em um dispositivo pessoal recebe acesso.
Vantagem: uma maneira granular de definir níveis de acesso. Você pode atribuir níveis de acesso separadamente a unidades organizacionais diferentes.
Desvantagem: os usuários precisam atender às condições em apenas um nível de acesso.
| Nome do nível de acesso | device_encryption |
| Um usuário terá acesso se: | tiver os atributos |
| Atributo da condição 1 |
Política de dispositivo |
| Nome do nível de acesso | corp_device |
| Um usuário terá acesso se: | tiver os atributos |
| Atributo da condição 1 |
Política de dispositivo |
| Nome do nível de acesso | min_os |
| Um usuário terá acesso se: | tiver os atributos |
| Atributo da condição 1 |
Política de dispositivo |
Um nível de acesso com níveis de acesso aninhados
Neste exemplo, os requisitos de segurança "Criptografia do dispositivo", "Versão mínima do sistema operacional" e "Dispositivo da empresa" estão em três níveis de acesso separados. Esses três níveis de acesso estão aninhados em um quarto nível de acesso.
Quando você atribui o quarto nível de acesso aos apps, os usuários precisam atender às condições em cada um dos três níveis de acesso aninhados para ter acesso. É um operador lógico "AND" de níveis de acesso.
Por exemplo, um usuário que tem um dispositivo criptografado e executa uma versão mais antiga do sistema operacional em um dispositivo pessoal tem o acesso negado.
Vantagem: você mantém a flexibilidade de separar os requisitos de segurança nos níveis de acesso 1, 2 e 3. Usando o nível de acesso 4, você também pode aplicar uma política com todos os requisitos de segurança.
Desvantagem: o registro de auditoria captura apenas o acesso negado ao nível 4 (não aos níveis 1, 2 e 3), porque os níveis 1, 2 e 3 não são atribuídos diretamente aos apps.
Crie três níveis de acesso conforme descrito em "Três níveis de acesso separados" acima: "device_encryption", "corp_device" e "min_os". Em seguida, crie um quarto nível de acesso chamado "device_security" com três condições. Cada condição tem um nível de acesso como atributo. É possível adicionar apenas um atributo de nível de acesso por condição.
| Nome do nível de acesso | device_security |
| Um usuário terá acesso se: | tiver os atributos |
| Atributo da condição 1 (apenas um nível de acesso por condição) |
Nível de acesso device_encryption |
| Unir a condição 1 e a condição 2 com | AND |
| Um usuário terá acesso se: | tiver os atributos |
| Atributo da condição 1 | Nível de acesso corp_device |
| Combine a condição 2 e a condição 3 com | E |
| Um usuário terá acesso se: | tiver os atributos |
| Atributo da condição 1 | Nível de acesso min_os |
Informações relacionadas
- Visão geral do Acesso baseado no contexto
- Configurar softwares e criar níveis de acesso baseado no contexto
- Atribuir níveis de acesso baseado no contexto a apps
- Personalizar o acesso baseado no contexto com grupos
- Exemplos de acesso baseado no contexto no Modo avançado
- Registro de auditoria do Acesso baseado no contexto