Ediciones compatibles con esta función: Frontline Standard y Frontline Plus; Enterprise Standard y Enterprise Plus; Education Standard y Education Plus; Enterprise Essentials Plus; Cloud Identity Premium. Comparar tu edición
En este artículo, se describen casos de uso comunes para el Acceso adaptado al contexto y se incluyen parámetros de configuración de ejemplo desarrollados 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.
Permitir 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 atención telefónica. Al igual que los empleados de tiempo completo, los contratistas deben tener una licencia compatible para que se les apliquen 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 | Atributos de Meet |
| 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 usurpadores conocidos
Para proteger los recursos de la empresa de cualquier vulneración, 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 desde 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 cumplir 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 los 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 puede usar direcciones IP privadas. Esto puede causar problemas con las políticas de IP pública o de región.
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 las siguientes condiciones: | Atributos de Meet |
| 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 |
No olvides lo siguiente:
- 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 de Identity and Access Management (IAM) adecuado (por ejemplo, compute.networks.list, compute.subnetworks.list, etcétera).
- VPC externas: La VPC que agregues a la lista de entidades permitidas puede ser externa a tu dominio actual de Google Cloud. Un administrador debe tener permiso de visualización para agregar la VPC externa.
Permitir o denegar 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 en 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, Australia y la India. Si viajan a otros países para pasar unas vacaciones personales como parte de un viaje de negocios, no pueden 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 | Atributos de Meet |
| 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 indicando que los usuarios obtienen acceso si no cumplen con las condiciones. Debes 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 solicite 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 independientes. 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 |
Atributos de Meet |
|
Atributo de la condición 1 (solo 1 nivel de acceso por condición) |
Nivel de acceso USWest |
|
Unir la condición 1 y la condición 2 con |
O |
|
Un usuario obtiene acceso si |
Atributos de Meet |
|
Atributo de condición 2 |
Nivel de acceso USEast |
|
Une la condición 2 y la condición 3 con |
O |
|
Un usuario obtiene acceso si |
Atributos de Meet |
|
Atributo de condición 3 |
Nivel de acceso USCentral |
Exigir que el dispositivo sea propiedad de la empresa en computadoras de escritorio, pero no en dispositivos móviles
Una empresa puede requerir un dispositivo de escritorio de su propiedad, pero no un dispositivo móvil de su propiedad.
Primero, crea un nivel de acceso para dispositivos de escritorio:
|
Nombre del nivel de acceso |
aldesktop_access |
|
Los usuarios obtienen acceso si |
Atributos de Meet |
|
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 |
Atributos de Meet |
|
Atributo de la condición 1 |
SO del dispositivo iOS = 0.0.0 Android = 0.0.0 |
Requerir seguridad básica del dispositivo
La mayoría de las empresas ahora requieren 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 de dispositivos, la versión mínima del sistema operativo y los dispositivos de la empresa. Cada uno tiene ventajas y desventajas.
1 nivel de acceso que contenga todos los requisitos de seguridad
En este ejemplo, la encriptación del dispositivo, la versión mínima del sistema operativo y los atributos de 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 denegará el acceso.
Ventaja: Es fácil de configurar. Cuando asignas este nivel de acceso a una app, el 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 | Atributos de Meet |
| 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 independientes
En este ejemplo, la encriptación del dispositivo, la versión mínima del sistema operativo y los atributos del dispositivo de propiedad de la empresa se encuentran en 3 niveles de acceso independientes. Los usuarios deben cumplir con las condiciones de un solo nivel de acceso para obtenerlo. Es un operador 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 a diferentes unidades organizativas por separado.
Desventaja: Los usuarios deben cumplir con las condiciones en un solo nivel de acceso.
| Nombre del nivel de acceso | device_encryption |
| Un usuario obtiene acceso si | Atributos de Meet |
| Atributo de la condición 1 |
Política de dispositivo |
| Nombre del nivel de acceso | corp_device |
| Un usuario obtiene acceso si | Atributos de Meet |
| Atributo de la condición 1 |
Política de dispositivo |
| Nombre del nivel de acceso | min_os |
| Un usuario obtiene acceso si | Atributos de Meet |
| 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 de los dispositivos de la empresa se encuentran en 3 niveles de acceso independientes. 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 los niveles de acceso.
Por ejemplo, se le deniega el acceso a un usuario que tiene un dispositivo encriptado y ejecuta una versión anterior del sistema operativo en un dispositivo personal.
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), porque 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 independientes" 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 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 | Atributos de Meet |
| Atributo de condición 1 (solo 1 nivel de acceso por condición) |
Nivel de acceso device_encryption |
| Unir la condición 1 y la condición 2 con | Y |
| Un usuario obtiene acceso si | Atributos de Meet |
| 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 | Atributos de Meet |
| 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