En este artículo, se describen casos de uso comunes del Acceso adaptado al contexto y se incluyen configuraciones de muestra desarrolladas en el modo básico.
Para ver ejemplos de niveles de acceso desarrollados en el modo avanzado (con el editor de CEL), consulta Ejemplos de Acceso adaptado al contexto para el modo avanzado.
Permite el 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, las empresas que usan contratistas para responder llamadas de asistencia general o trabajar en centros de ayuda y centros de llamadas. Al igual que los empleados de tiempo completo, los contratistas deben tener una licencia compatible para estar cubiertos por las políticas de Acceso adaptado al contexto.
En este ejemplo, los contratistas obtienen acceso a los recursos corporativos solo desde un rango de direcciones IP corporativas específico.
| Nombre del nivel de acceso | contractor_access |
| Un contratista obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 | Subred de IP (pública) 74.125.192.0/18 |
| Asignación de nivel de acceso | Unidades organizativas para contratistas Todas las apps que usan los contratistas |
Bloquea el acceso desde direcciones IP de secuestradores conocidas
Para proteger los recursos de la empresa de que se vean comprometidos, muchas empresas bloquean el acceso a fuentes conocidas de alto riesgo.
En este ejemplo, se bloquea la dirección IP 74.125.195.105. Los usuarios obtienen acceso a los recursos corporativos si sus sesiones se originan en cualquier otra dirección IP. Puedes especificar varias direcciones IP y rangos.
| Nombre del nivel de acceso | block_highrisk |
| Un usuario obtiene acceso si | No cumple con los atributos |
| Atributo de la condición 1 | Subred de IP (pública) 74.125.195.105 |
| Asignación de nivel de acceso | Unidad organizativa de nivel superior Todas las apps |
Permite el acceso desde una red privada específica en Google Cloud
Muchas empresas enrutan el tráfico de usuarios a Google a través de una nube privada virtual (VPC). Una VPC es una red segura y aislada dentro del entorno de Google Cloud.
Ten en cuenta que el tráfico que se enruta a través de tu VPC podría usar direcciones IP privadas. Esto puede causar problemas con las políticas de IP o región públicas.
En este ejemplo, puedes permitir el tráfico de estas VPC específicas.
| Nombre del nivel de acceso | vpc_access |
| Un usuario obtiene acceso si… | Cumple con los atributos |
| Atributos de la condición 1 |
Subred de IP (privada) Subred de IP privada: //compute.googleapis.com/projects/project- name-test/global/networks/network-name Subred de VPC: 74.125.192.0/18 |
| Asignación de nivel de acceso |
Unidades organizativas para todos los usuarios Todas las apps que usan los contratistas |
Aspectos importantes que debes recordar:
- Solo tráfico directo: Este nivel de acceso solo funciona para el tráfico que llega directamente a los servidores de Google desde la VPC incluida en la lista de entidades permitidas. Si el tráfico pasa primero por otra red o túnel, no se otorga el acceso. Google solo reconoce la última VPC que envía el tráfico a sus servidores.
- Permisos de administrador: Para ver las VPC y configurar este nivel de acceso, los administradores deben tener el rol adecuado de Identity and Access Management (IAM) (por ejemplo, compute.networks.list, compute.subnetworks.list, etcétera).
- VPC externas: La VPC que incluyes en la lista de entidades permitidas puede ser de fuera de tu dominio actual de Google Cloud. Un administrador debe tener permiso de visualización para agregar la VPC externa.
Permite o deniega el acceso desde ubicaciones específicas
Si tienes empleados que viajan con frecuencia a oficinas corporativas o de socios remotas, puedes especificar las ubicaciones geográficas desde las que pueden acceder a los recursos corporativos.
Por ejemplo, si un grupo de vendedores visita con frecuencia a clientes en Australia y la India, puedes limitar el acceso del grupo a su oficina central y a Australia y la India. Si viajan a otros países por vacaciones personales como parte de un viaje de negocios, no podrán acceder a los recursos corporativos desde esos otros países.
En este ejemplo, el grupo de ventas puede acceder a los recursos corporativos solo desde EE.UU. (oficina central), Australia y la India.
| Nombre del nivel de acceso | sales_access |
| El equipo de ventas obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 | Origen geográfico EE.UU., Australia, India |
| Asignación de nivel de acceso | Grupo de vendedores Todas las apps que usan los vendedores |
También puedes crear una política para denegar el acceso desde países específicos. Para ello, especifica que los usuarios obtengan acceso si no cumplen con las condiciones. Deberás enumerar los países desde los que quieres bloquear el acceso.
Usa niveles de acceso anidados en lugar de seleccionar varios niveles de acceso durante la asignación
En algunos casos, cuando intentas asignar niveles de acceso a una unidad organizativa o un grupo determinados y a una aplicación (o un conjunto de aplicaciones), es posible que veas un mensaje de error en el que se te pida que reduzcas la cantidad de aplicaciones o niveles de acceso.
Para evitar este error, puedes reducir la cantidad de niveles de acceso que se usan durante la asignación anidándolos en un solo nivel de acceso. El nivel de acceso anidado une varias condiciones con una operación OR, y cada condición contiene un nivel de acceso individual.
En este ejemplo, USWest, USEast y USCentral se encuentran en 3 niveles de acceso separados. Supongamos que quieres que los usuarios puedan acceder a las aplicaciones si cumplen con cualquiera de los niveles de acceso USWest, USEast o USCentral.Puedes crear un solo nivel de acceso anidado (llamado USRegions) con el operador OR. Cuando llegue el momento de asignar los niveles de acceso, asigna el nivel de acceso USRegions a la aplicación para la unidad organizativa o el grupo.
|
Nombre del nivel de acceso |
USRegions |
|
Un usuario obtiene acceso si |
Cumple con los atributos |
|
Atributo de la condición 1 (solo 1 nivel de acceso por condición) |
Nivel de acceso USWest |
|
Une la condición 1 y la condición 2 con |
O |
|
Un usuario obtiene acceso si |
Cumple con los atributos |
|
Atributo de la condición 2 |
Nivel de acceso USEast |
|
Une la condición 2 y la condición 3 con |
O |
|
Un usuario obtiene acceso si |
Cumple con los atributos |
|
Atributo de la condición 3 |
Nivel de acceso USCentral |
Exige que el dispositivo sea propiedad de la empresa en computadoras, pero no en dispositivos móviles
Una empresa podría exigir un dispositivo de escritorio de la empresa, pero no un dispositivo móvil de la empresa.
Primero, crea un nivel de acceso para dispositivos de escritorio:
|
Nombre del nivel de acceso |
aldesktop_access |
|
Los usuarios obtienen acceso si |
Cumplen con los atributos |
|
Atributo de la condición 1 |
Política de dispositivo
Encriptación del dispositivo = No compatible SO del dispositivo macOS = 0.0.0 Windows =0.0.0 SO Linux = 0.0.0 Chrome OS = 0.0.0 |
Luego, crea un nivel de acceso para dispositivos móviles:
|
Nombre del nivel de acceso |
almobile_access |
|
Los usuarios obtienen acceso si |
Cumplen con los atributos |
|
Atributo de la condición 1 |
SO del dispositivo iOS = 0.0.0 Android = 0.0.0 |
Exige seguridad básica del dispositivo
La mayoría de las empresas ahora exigen que los empleados accedan a los recursos corporativos a través de dispositivos encriptados y que cumplan con las versiones mínimas del sistema operativo. Algunas también exigen que los empleados usen dispositivos de la empresa.
Puedes configurar estas políticas para todas tus unidades organizativas o solo para aquellas que trabajan con datos sensibles, como ejecutivos de la empresa, finanzas o recursos humanos.
Existen varias formas de configurar una política que incluya la encriptación del dispositivo, la versión mínima del sistema operativo y los dispositivos de la empresa. Cada una tiene ventajas y desventajas.
1 nivel de acceso que contiene todos los requisitos de seguridad
En este ejemplo, la encriptación del dispositivo, la versión mínima del sistema operativo y los atributos del dispositivo de la empresa se incluyen en un nivel de acceso. Los usuarios deben cumplir con todas las condiciones para obtener acceso.
Por ejemplo, si el dispositivo de un usuario está encriptado y es propiedad de la empresa, pero no ejecuta una versión compatible del sistema operativo, se le deniega el acceso.
Ventaja: Es fácil de configurar. Cuando asignas este nivel de acceso a una app, un usuario debe cumplir con todos los requisitos.
Desventaja: Para asignar por separado los requisitos de seguridad a diferentes unidades organizativas, debes crear un nivel de acceso independiente para cada requisito de seguridad.
| Nombre del nivel de acceso | device_security |
| Un usuario obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 (Puedes agregar todos los atributos a una condición o crear 3 condiciones y unirlas con Y). |
Política de dispositivo SO del dispositivo |
3 niveles de acceso separados
En este ejemplo, la encriptación del dispositivo, la versión mínima del sistema operativo y los atributos del dispositivo de la empresa se encuentran en 3 niveles de acceso separados. Los usuarios deben cumplir con las condiciones de solo un nivel de acceso para obtener acceso. Es un OR lógico de niveles de acceso.
Por ejemplo, un usuario que tiene un dispositivo encriptado y ejecuta una versión anterior del sistema operativo en un dispositivo personal obtiene acceso.
Ventaja: Es una forma detallada de definir los niveles de acceso. Puedes asignar niveles de acceso por separado a diferentes unidades organizativas.
Desventaja: Los usuarios deben cumplir con las condiciones de solo un nivel de acceso.
| Nombre del nivel de acceso | device_encryption |
| Un usuario obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 |
Política de dispositivo |
| Nombre del nivel de acceso | corp_device |
| Un usuario obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 |
Política de dispositivo |
| Nombre del nivel de acceso | min_os |
| Un usuario obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 |
Política de dispositivo |
1 nivel de acceso con niveles de acceso anidados
En este ejemplo, la encriptación del dispositivo, la versión mínima del sistema operativo y los requisitos de seguridad del dispositivo de la empresa se encuentran en 3 niveles de acceso separados. Estos 3 niveles de acceso están anidados dentro de un cuarto nivel de acceso.
Cuando asignas el cuarto nivel de acceso a las apps, los usuarios deben cumplir con las condiciones de cada uno de los 3 niveles de acceso anidados para obtener acceso. Es un AND lógico de niveles de acceso.
Por ejemplo, a un usuario que tiene un dispositivo encriptado y ejecuta una versión anterior del sistema operativo en un dispositivo personal se le deniega el acceso.
Ventaja: Conservas la flexibilidad de separar los requisitos de seguridad en los niveles de acceso 1, 2 y 3. Con el nivel de acceso 4, también puedes aplicar una política con todos los requisitos de seguridad.
Desventaja: El registro de auditoría solo captura el acceso denegado al nivel de acceso 4 (no a los niveles de acceso 1, 2 y 3), ya que los niveles de acceso 1, 2 y 3 no se asignan directamente a las apps.
Crea 3 niveles de acceso como se describe en "3 niveles de acceso separados" más arriba: "device_encryption", "corp_device" y "min_os". Luego, crea un cuarto nivel de acceso llamado "device_security" que tenga 3 condiciones. Cada condición tiene un nivel de acceso como su atributo. (Solo puedes agregar 1 atributo de nivel de acceso por condición).
| Nombre del nivel de acceso | device_security |
| Un usuario obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 (solo 1 nivel de acceso por condición) |
Nivel de acceso device_encryption |
| Une la condición 1 y la condición 2 con | Y |
| Un usuario obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 | Nivel de acceso corp_device |
| Une la condición 2 y la condición 3 con | Y |
| Un usuario obtiene acceso si | Cumple con los atributos |
| Atributo de la condición 1 | Nivel de acceso min_os |
Información relacionada
- Descripción general del Acceso adaptado al contexto
- Configura el software y crea niveles de acceso adaptado al contexto
- Asigna niveles de acceso adaptado al contexto a las apps
- Personaliza el acceso adaptado al contexto con grupos
- Ejemplos de Acceso adaptado al contexto para el modo avanzado
- Registro de auditoría del Acceso adaptado al contexto