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 prestadores de serviço para atender a chamadas gerais para o suporte ou trabalhar em Centrais de Ajuda e centrais de atendimento. Assim como os funcionários que trabalham 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, eles só têm acesso aos recursos corporativos em um intervalo de endereços IP corporativo 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 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 impedir que recursos sejam comprometidos, muitas empresas bloqueiam o acesso a fontes conhecidas por serem de alto risco.
Neste exemplo, o endereço IP 74.125.195.105 está bloqueado. Os usuários terão acesso a recursos corporativos se as sessões forem originadas de qualquer outro endereço IP. Você pode 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 74.125.195.105 |
| Atribuição de nível de acesso | Unidade organizacional de nível superior Todos os apps |
Permitir ou proibir o acesso de locais específicos
Se seus funcionários viajam regularmente para escritórios remotos corporativos ou de parceiros, especifique os locais geográficos onde eles podem acessar os recursos corporativos.
Por exemplo, se a equipe de vendas costuma visitar clientes na Austrália e na Índia, você pode permitir o acesso apenas na sede da empresa, na Austrália e na Í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, a equipe de vendas acessa recursos corporativos apenas nos Estados Unidos, na Austrália e na Í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 EUA, Austrália, Índia |
| Atribuição de nível de acesso | Grupo de vendedores Todos os apps usados pelos funcionários da equipe de vendas |
Também é possível criar uma política para negar o acesso em determinados países especificando que os usuários terão acesso se não atenderem às condições. Você precisa listar os países onde 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, quando você tenta atribuir níveis de acesso a uma unidade organizacional ou um grupo e a um app (ou um conjunto de apps), pode aparecer uma mensagem de erro solicitando a redução do número de apps ou níveis de acesso.
Para evitar esse erro, você pode reduzir 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 une várias condições com uma operação OR, e cada condição inclui um nível de acesso.
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 acessem apps se atenderem aos níveis de acesso "Oeste dos EUA" OU "Leste dos EUA" OU "Centro dos EUA". Você pode criar um único nível de acesso aninhado (chamado "Regiões dos EUA") com o operador OR. Em seguida, você pode atribuir o nível de acesso "Regiões dos EUA" ao app à unidade organizacional ou ao 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 Oeste dos EUA |
|
Unir a condição 1 e a condição 2 com |
OR |
|
Um usuário terá acesso se: |
tiver os atributos |
|
Atributo da condição 2 |
Nível de acesso Leste dos EUA |
|
Unir a condição 2 e a condição 3 com |
OR |
|
Um usuário terá acesso se: |
tiver os atributos |
|
Atributo da condição 3 |
Nível de acesso Centro dos EUA |
Exigir computadores da empresa, mas não dispositivos móveis
Uma empresa pode exigir computadores que pertençam á empresa, 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 |
tiverem 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 |
tiverem 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
Agora a maioria das empresas exige que os funcionários acessem recursos corporativos em dispositivos criptografados e com 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 confidenciais, como executivos, departamento financeiro ou recursos humanos.
Há várias maneiras de configurar uma política que inclui criptografia de dispositivo, versão mínima do sistema operacional e dispositivos da empresa. Cada uma tem vantagens e desvantagens.
Um nível de acesso que inclui todos os requisitos de segurança
Por exemplo, se um dispositivo de usuário estiver criptografado e pertencer à empresa, mas não utilizar 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: se você quiser atribuir os requisitos de segurança a diferentes unidades organizacionais separadamente, precisará criar um nível de acesso para cada requisito de segurança.
| 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 o parâmetro "AND". |
Política de dispositivo Sistema operacional do dispositivo |
Três níveis de acesso separados
Por exemplo, um usuário que tem um dispositivo criptografado e utiliza uma versão mais antiga do sistema operacional em um dispositivo pessoal recebe acesso.
Vantagem: uma maneira granular de definir os 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
Quando você atribui o quarto nível de acesso a apps, os usuários precisam atender às condições em cada um dos três níveis de acesso aninhados. A lógica dos níveis de acesso é "AND".
Por exemplo, um usuário que tem um dispositivo criptografado e utiliza uma versão mais antiga do sistema operacional em um dispositivo pessoal não tem acesso.
Vantagem: você mantém a flexibilidade de separar os requisitos de segurança entre os 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 no nível de acesso 4, porque os níveis de acesso 1, 2 e 3 não estão atribuídos diretamente a apps.
Conforme descrito em “Três níveis de acesso separados” acima, crie três níveis de acesso: “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 |
| Unir a condição 2 e a condição 3 com | AND |
| 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