En este artículo se describen algunos casos prácticos habituales del acceso contextual y ejemplos de configuraciones desarrolladas en el modo básico.
Para ver ejemplos de niveles de acceso desarrollados en el modo Avanzado (con el editor CEL), consulta el artículo Ejemplos de acceso contextual del modo Avanzado.
Dar acceso a los contratistas solo a través de la red corporativa
Muchas empresas quieren restringir el acceso de los contratistas a los recursos corporativos. Por ejemplo, es el caso de las empresas que recurren a contratistas para atender llamadas de asistencia generales o que trabajan en centros de ayuda y centralitas. Al igual que ocurre con los empleados a tiempo completo, los contratistas deben tener licencias compatibles que admitan las políticas de acceso contextual.
En este ejemplo, los contratistas solo pueden acceder a los recursos corporativos desde un intervalo de direcciones IP corporativas específico.
| Nombre del nivel de acceso | contractor_access |
| Los contratistas pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 | Subred de IPs 74.125.192.0/18 |
| Asignación del nivel de acceso | Unidades organizativas para contratistas Todas las aplicaciones que utilizan los contratistas |
Bloquear el acceso desde direcciones IP conocidas de hackers
Para evitar que se vulneren sus recursos, muchas empresas bloquean el acceso a fuentes que se sabe que son de alto riesgo.
En este ejemplo, la dirección IP 74.125.195.105 está bloqueada. Los usuarios obtienen acceso a los recursos corporativos si sus sesiones se originan desde cualquier otra dirección IP. Se pueden especificar varios intervalos y direcciones IP.
| Nombre del nivel de acceso | block_highrisk |
| Los usuarios pueden acceder si: | No cumplen los atributos |
| Atributo de la condición 1 | Subred de IP 74.125.195.105 |
| Asignación del nivel de acceso | Unidad organizativa de nivel superior Todas las aplicaciones |
Permitir o bloquear el acceso desde ubicaciones concretas
Si tienes empleados que viajan con frecuencia a oficinas de la empresa o de colaboradores en otros países, puedes especificar las ubicaciones geográficas desde las que pueden acceder a los recursos corporativos.
Por ejemplo, si un grupo de ventas visita habitualmente a clientes de Australia y la India, puedes limitar los lugares desde los que pueden acceder a los recursos a la sede central, Australia y la India. En este caso, si durante un viaje de negocios van de vacaciones a otros países, no podrán acceder a los recursos corporativos desde esos países.
En este ejemplo, el grupo de ventas solo puede acceder a los recursos corporativos desde EE. UU. (sede central), Australia y la India.
| Nombre del nivel de acceso | sales_access |
| Los miembros del equipo de ventas pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 | Origen geográfico EE. UU., Australia y la India |
| Asignación del nivel de acceso | Grupo de ventas Todas las aplicaciones que utiliza el equipo de ventas |
También podrías crear una política que deniegue el acceso desde determinados países. En ese caso, tendrías que indicar que los usuarios solo tienen acceso si no cumplen las condiciones y enumerar los países en los que quieres bloquear el acceso.
Anidar niveles de acceso en lugar de seleccionar varios durante la asignación
En algunos casos, cuando intentas asignar niveles de acceso a una unidad organizativa o a un grupo concretos para acceder a una aplicación o a un conjunto de aplicaciones, es posible que aparezca un mensaje de error en el que se te pida que reduzcas el número de aplicaciones o niveles de acceso.
Para evitar este error, puedes anidar varios niveles de acceso en uno solo y así utilizar menos niveles en la asignación. Los niveles de acceso anidados permiten combinar mediante operadores OR varias condiciones, cada una de ellas con un nivel de acceso.
En el siguiente ejemplo, USWest, USEast y USCentral están en tres niveles de acceso independientes. Supongamos que quieres que los usuarios puedan acceder a aplicaciones si cumplen las condiciones de alguno de esos tres niveles de acceso. En este caso, puedes crear un único nivel de acceso anidado (denominado USRegions) combinando USWest, USEast y USCentral con el operador OR. Cuando tengas que asignar esos niveles de acceso, basta con que asignes el nivel de acceso USRegions a la unidad organizativa o grupo que te interese para esa aplicación.
|
Nombre del nivel de acceso |
USRegions |
|
Los usuarios pueden acceder si: |
Cumplen los atributos |
|
Atributo de la condición 1 (solo un nivel de acceso por condición) |
Nivel de acceso USWest |
|
Unir las condiciones 1 y 2 con |
OR |
|
Los usuarios pueden acceder si: |
Cumplen los atributos |
|
Atributo de la condición 2 |
Nivel de acceso USEast |
|
Unir las condiciones 2 y 3 con |
OR |
|
Los usuarios pueden acceder si: |
Cumplen los atributos |
|
Atributo de la condición 3 |
Nivel de acceso USCentral |
Requerir el uso de dispositivos de empresa en el caso de los ordenadores, pero no de los móviles
Una empresa puede requerir el uso de dispositivos propios en el caso de los ordenadores, pero permitir que se utilicen dispositivos móviles personales.
En primer lugar, crea un nivel de acceso para los ordenadores:
|
Nombre del nivel de acceso |
aldesktop_access |
|
Los usuarios pueden acceder si: |
Cumplen los atributos |
|
Atributo de la condición 1 |
Política de dispositivos
Cifrado del dispositivo = no disponible SO del dispositivo macOS = 0.0.0 Windows = 0.0.0 SO Linux = 0.0.0 Chrome OS = 0.0.0 |
A continuación, crea un nivel de acceso para los dispositivos móviles:
|
Nombre del nivel de acceso |
almobile_access |
|
Los usuarios pueden acceder si: |
Cumplen los atributos |
|
Atributo de la condición 1 |
SO del dispositivo iOS = 0.0.0 Android = 0.0.0 |
Requerir medidas de seguridad básicas en dispositivos
Hoy en día, la mayoría de las empresas exigen que los empleados accedan a los recursos de la empresa a través de dispositivos cifrados y con versiones del sistema operativo que cumplan unos requisitos mínimos. Algunas también obligan a los empleados a utilizar dispositivos propiedad de la empresa.
Puedes configurar estas políticas en todas tus unidades organizativas o solo en aquellas que trabajen con datos sensibles, como los ejecutivos de la empresa, el departamento de finanzas o el de recursos humanos.
Hay varias formas de configurar una política que incluya el cifrado de dispositivos, una versión mínima del sistema operativo y dispositivos propiedad de la empresa. Cada una tiene sus ventajas e inconvenientes.
Un nivel de acceso que contenga todos los requisitos de seguridad
Por ejemplo, si el dispositivo de un usuario está cifrado y pertenece a la empresa, pero la versión del sistema operativo que usa no está admitida, se le denegará el acceso.
Ventajas: este método es fácil de configurar. Al asignar este nivel de acceso a una aplicación, el usuario debe cumplir todos los requisitos.
Inconvenientes: para poder asignar los requisitos de seguridad a diferentes unidades organizativas por separado, debes crear un nivel de acceso independiente por cada requisito.
| Nombre del nivel de acceso | device_security |
| Los usuarios pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 -Puedes añadir todos los atributos a una condición o crear tres condiciones y unirlas con AND. |
Política de dispositivos SO del dispositivo |
Tres niveles de acceso independientes
Por ejemplo, tendrá acceso un usuario que tenga un dispositivo cifrado aunque utilice una versión anterior del sistema operativo en un dispositivo personal.
Ventajas: permite definir los niveles de acceso de forma detallada. Puedes asignar niveles de acceso por separado a diferentes unidades organizativas.
Inconvenientes: los usuarios solo deben cumplir las condiciones de un nivel de acceso.
| Nombre del nivel de acceso | device_encryption |
| Los usuarios pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 |
Política de dispositivos |
| Nombre del nivel de acceso | corp_device |
| Los usuarios pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 |
Política de dispositivos |
| Nombre del nivel de acceso | min_os |
| Los usuarios pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 |
Política de dispositivos |
Un nivel de acceso con niveles de acceso anidados
Al asignar el cuarto nivel de acceso a aplicaciones, los usuarios deben cumplir las condiciones de los tres niveles de acceso anidados. Es decir, funciona como un operador lógico AND de niveles de acceso.
Por ejemplo, se le denegará el acceso a un usuario que tenga un dispositivo cifrado y utilice una versión anterior del sistema operativo en un dispositivo personal.
Ventajas: sigue ofreciendo la flexibilidad de poder separar los requisitos de seguridad en los niveles de acceso 1, 2 y 3. Además, con el nivel de acceso 4 se puede aplicar una política obligatoria que incluya todos los requisitos de seguridad.
Inconvenientes: el registro de auditoría solo recoge los accesos denegados al nivel de acceso 4 y no a los niveles 1, 2 y 3, ya que estos no están asignados a las aplicaciones directamente.
Para aplicar este método, crea tres niveles de acceso como se describe en la sección anterior "Tres niveles de acceso independientes": "device_encryption", "corp_device" y "min_os". A continuación, crea un cuarto nivel de acceso denominado "device_security" que incluya tres condiciones. Cada condición incluye un nivel de acceso como atributo, ya que solo se puede añadir un atributo de nivel de acceso por condición.
| Nombre del nivel de acceso | device_security |
| Los usuarios pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 Solo hay un nivel de acceso por condición. |
Nivel de acceso device_encryption |
| Unir las condiciones 1 y 2 con | AND |
| Los usuarios pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 | Nivel de acceso corp_device |
| Unir las condiciones 2 y 3 con | AND |
| Los usuarios pueden acceder si: | Cumplen los atributos |
| Atributo de la condición 1 | Nivel de acceso min_os |
