En este artículo, se describen los casos de uso habituales del acceso adaptado al contexto y se incluyen ejemplos de configuraciones 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 desean restringir el acceso de los contratistas a los recursos corporativos. Por ejemplo, las empresas que utilizan contratistas para responder llamadas de asistencia generales 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 las siguientes condiciones: | Atributos de Meet |
| Atributo de 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 posibles vulneraciones, 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 cumple con las siguientes condiciones: | No cumplir con los atributos |
| Atributo de 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 aislada y segura 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 pública o 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 adecuado de Administración de identidades y accesos (IAM) (por ejemplo, compute.networks.list, compute.subnetworks.list, etcétera).
- VPCs externas: La VPC que agregues a la lista de entidades permitidas puede estar fuera de tu dominio actual de Google Cloud. Un administrador debe tener permiso de visualización para agregar la VPC externa.
Permite o rechaza 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 los clientes en Australia y la India, puedes limitar el acceso del grupo a su oficina central y a Australia y la India. Si viaja a otros países por vacaciones personales como parte de un viaje de negocios, no podrá acceder a los recursos corporativos desde esos otros países.
En este ejemplo, el grupo de ventas solo puede acceder a los recursos corporativos 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 las siguientes condiciones: | Atributos de Meet |
| Atributo de condición 1 | Origen geográfico EE.UU., Australia, India |
| Asignación de nivel de acceso | Grupo de vendedores Todos los vendedores de aplicaciones usan |
También puedes crear una política para denegar el acceso desde países específicos. Para ello, especifica que los usuarios obtienen acceso si no cumplen con las condiciones. En este caso, enumerarías 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 que te solicite reducir 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 cumple con las siguientes condiciones: |
Atributos de Meet |
|
Atributo de 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 las siguientes condiciones: |
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 cumple con las siguientes condiciones: |
Atributos de Meet |
|
Atributo de condición 3 |
Nivel de acceso USCentral |
Se requiere un dispositivo propiedad de la empresa en computadoras, pero no en dispositivos móviles
Una empresa podría requerir un dispositivo de escritorio propiedad de la empresa, pero no un dispositivo móvil propiedad 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 las siguientes condiciones: |
Atributos de Meet |
|
Atributo de 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 las siguientes condiciones: |
Atributos de Meet |
|
Atributo de 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 exigen que los empleados accedan a los recursos corporativos a través de dispositivos encriptados 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 propiedad de la empresa. Cada uno tiene sus ventajas y desventajas.
1 nivel de acceso que contiene todos los requisitos de seguridad
En este ejemplo, los atributos de encriptación del dispositivo, versión mínima del sistema operativo y dispositivo propiedad de la empresa se incluyen en un nivel de acceso. Los usuarios deben cumplir con todas las condiciones para obtener acceso.
Por ejemplo, si un dispositivo del 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, 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 cumple con las siguientes condiciones: | 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 AND) |
Política del dispositivo SO del dispositivo |
3 niveles de acceso independientes
En este ejemplo, los atributos de encriptación del dispositivo, versión mínima del sistema operativo y dispositivo propiedad 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 los 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 de solo un nivel de acceso.
| Nombre del nivel de acceso | device_encryption |
| Un usuario obtiene acceso si cumple con las siguientes condiciones: | Atributos de Meet |
| Atributo de condición 1 |
Política de dispositivo |
| Nombre del nivel de acceso | corp_device |
| Un usuario obtiene acceso si cumple con las siguientes condiciones: | Atributos de Meet |
| Atributo de condición 1 |
Política de dispositivo |
| Nombre del nivel de acceso | min_os |
| Un usuario obtiene acceso si cumple con las siguientes condiciones: | Atributos de Meet |
| Atributo de condición 1 |
Política del dispositivo |
1 nivel de acceso con niveles de acceso anidados
En este ejemplo, los requisitos de encriptación del dispositivo, la versión mínima del sistema operativo y la seguridad del dispositivo propiedad 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 los niveles de acceso.
Por ejemplo, se le niega 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), 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 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 las siguientes condiciones: | Atributos de Meet |
| 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 las siguientes condiciones: | Atributos de Meet |
| Atributo de 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 las siguientes condiciones: | Atributos de Meet |
| Atributo de 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
- Cómo personalizar 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