Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Descripción general de Access Context Manager

En este documento, se proporciona una descripción general del servicio de Access Context Manager y sus funciones.Los administradores de la organización de Google Cloud pueden usar Access Context Manager para definir un control de acceso detallado y basado en atributos para proyectos y recursos en Google Cloud. Como administrador, primero debes definir una política de acceso, que es un contenedor para toda la organización que incluye niveles de acceso y perímetros de servicio.

Los niveles de acceso describen los requisitos necesarios para poder recibir los privilegios. Algunos ejemplos son los siguientes:

Tipo de dispositivo y sistema operativo
Dirección IP
Identidad de usuario

Los perímetros de servicio definen entornos de pruebas de recursos. Los recursos dentro del perímetro pueden intercambiar datos libremente, pero no pueden exportarlos fuera del perímetro. Access Context Manager no es responsable de que la política se aplique. En cambio, Access Context Manager está diseñado para definir reglas o contextos específicos. La política se configura y aplica en varios puntos, como los Controles del servicio de VPC. Puedes obtener más información sobre estos servicios en sus respectivas guías del usuario.

Puedes configurar y aplicar políticas de Access Context Manager en los siguientes componentes de la solución de Chrome Enterprise Premium:

Acceso adaptado al contexto para Google Workspace

Condiciones de Identity and Access Management (IAM)

Beneficios

Muchas empresas confían en un modelo de seguridad perimetral, como un firewall, para proteger los recursos internos. Un modelo de seguridad perimetral está muy protegido con un único punto de entrada y salida. Todo lo que se encuentre fuera del perímetro se considera peligroso. Todo lo que esté dentro es confiable.

Los firewalls y el modelo de seguridad perimetral funcionan bien si hay un límite bien definido alrededor de usuarios y servicios específicos. Sin embargo, si un personal es móvil, la variedad de dispositivos aumentará a medida que los usuarios lleven sus propios dispositivos (BYOD) y usen servicios basados en la nube. Esta situación genera vectores de ataque adicionales que el modelo perimetral no considera. Por lo tanto, el perímetro ya no es solo la ubicación física de la empresa, y no se puede suponer que lo que está dentro es seguro.

Puedes usar Access Context Manager para reducir el tamaño de la red privilegiada y pasar a un modelo en el que los extremos no tengan autoridad ambiental basada en la red. En su lugar, puedes otorgar acceso según el contexto de la solicitud, como el tipo de dispositivo, la identidad del usuario y mucho más, mientras verificas el acceso a la red corporativa cuando sea necesario.

Access Context Manager es una parte integral del esfuerzo de BeyondCorp en Google. Para obtener más información, consulta BeyondCorp.

Políticas de acceso

Una política de acceso es un contenedor para todos tus recursos de Access Context Manager, como los niveles de acceso y los perímetros de servicio.

Puedes crear una política de acceso en el contexto de una organización y usarla en cualquier lugar de tu organización. Para delegar la administración de una política de acceso, puedes crear una política de acceso con alcance y establecer el alcance de la política a nivel de la carpeta o del proyecto. El administrador delegado al que se le asigna la política con alcance solo puede administrar la política de acceso con alcance y no la política de acceso a nivel de la organización.

Una política de acceso tiene un control de versiones mediante un etag. Puedes usar etag para orientar los cambios a tu política de acceso, como modificaciones en los niveles de acceso o en una versión específica de la política. Si varias fuentes cambian tu política de acceso, usar el campo etag para la herramienta de línea de comandos de gcloud y las llamadas a la API ayuda a evitar reemplazos y conflictos no deseados.

Para obtener información sobre cómo crear políticas de acceso, consulta Crea una política de acceso.

Niveles de acceso

Los niveles de acceso se usan para permitir el acceso a los recursos según la información contextual de la solicitud. Mediante los niveles de acceso, puedes comenzar a organizar niveles de confianza. Por ejemplo, puedes crear un nivel de acceso llamado High_Level que permita solicitudes de un grupo pequeño de personas con muchos privilegios. También puedes identificar un grupo más general para confiar, como un rango de IP desde el que deseas permitir solicitudes. En ese caso, puedes crear un nivel de acceso llamado Medium_Level para permitir esas solicitudes.

Después de definir los niveles de acceso, los servicios de aplicación de políticas pueden usarlos para determinar si se debe aceptar una solicitud. Por ejemplo, puedes especificar que, si bien muchos recursos están disponibles para Medium_Trust, ciertos recursos más sensibles requieren el nivel High_Trust. Estas verificaciones se aplican además de la política de IAM estándar.

Los niveles de acceso se pueden personalizar. Los niveles de acceso High_Trust y Medium_Trust son ejemplos. Puedes especificar varios niveles de acceso como parte de una política de acceso.

Access Context Manager proporciona dos formas de definir los niveles de acceso:

Un nivel de acceso básico consiste en una colección de condiciones que se usan para probar las solicitudes. Las condiciones se pueden definir como un grupo de atributos que deseas probar, como el tipo de dispositivo, la dirección IP o la identidad del usuario. Los atributos se combinan como una operación AND (todos deben ser verdaderos) o una operación NOR (ninguno debe ser verdadero) para determinar si se cumple la condición.
Los niveles de acceso personalizados se crean con un subconjunto de Common Expression Language. Además del contexto de solicitud usado para los niveles de acceso básicos, también puedes usar niveles de acceso personalizados a fin de permitir solicitudes basadas en datos de servicios de terceros. Para obtener más información, consulta Niveles de acceso personalizados.

!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED  // levels.regions_check

inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED  // levels.ip_check

!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED

levels.regions_check || levels.ip_check -> GRANTED

Dirección IP

Puedes otorgar un nivel de acceso basado en la dirección IP de la solicitud de origen. El rango de direcciones IP que se permite se especifica como un bloque de enrutamiento entre dominios sin clases (CIDR), lo que otorga un control detallado sobre las direcciones IP permitidas.

Un solo nivel de acceso puede contener varios rangos de IP.

Para aprender a crear un nivel de acceso que solo permita el acceso a un rango específico de direcciones IP, como las que se encuentran dentro de una sola red corporativa, consulta Crea un nivel de acceso para el acceso a la red corporativa.

Access Context Manager trata los siguientes rangos de IP como rangos privados:

10.0.0.0/8 (RFC 1918)
172.16.0.0/12 (RFC 1918)
192.168.0.0/16 (RFC 1918)
100.64.0.0/10 (espacio de direcciones compartidas de RFC 6598)
fc00::/7 (direcciones locales únicas IPv6 RFC 4193)

Tipo de dispositivo

Access Context Manager usa la Verificación de extremos para recopilar información sobre los dispositivos del usuario, como el sistema operativo, el tipo de dispositivo o la versión. Puedes otorgar un nivel de acceso según estos datos. Por ejemplo, puedes otorgar un nivel de acceso más permisivo a los dispositivos que ejecutan la última versión del sistema operativo principal que implementa tu empresa.

Para obtener información sobre cómo otorgar un nivel de acceso basado en esos atributos del dispositivo, consulta Limita el acceso por tipo de dispositivo.

Identidad de usuario

En algunas situaciones, es posible que quieras otorgar un nivel de acceso a entidades específicas. En estas situaciones, la identidad del emisor determina si se cumple la condición. Esta situación suele usarse junto con cuentas de servicio y Controles del servicio de VPC. Por ejemplo, puedes usar esta situación para habilitar una Cloud Function y así acceder a datos protegidos por los Controles del servicio de VPC.

Puedes crear y administrar niveles de acceso solo por identidad con la herramienta de línea de comandos de gcloud, pero no con la consola de Google Cloud .

Para comenzar a crear un nivel de acceso básico, consulta Crea un nivel de acceso para Access Context Manager.

Para obtener información sobre cómo crear un nivel de acceso que permita el acceso según el contexto de una solicitud, consulta Crea un nivel de acceso personalizado.

Combina condiciones

Un solo nivel de acceso puede contener varias condiciones. Las condiciones se pueden evaluar mediante el operador AND o OR. Puedes especificar el modo cuando creas o actualizas un nivel de acceso.

El caso AND es la opción más estricta y predeterminada. Esta opción solo otorga el nivel de acceso si se cumplen todas las condiciones. Por ejemplo, puedes solicitar que una solicitud provenga de la red corporativa y de un dispositivo que ejecute la versión más reciente de un sistema operativo.

OR es una opción menos restrictiva. Esta opción solo requiere que una de muchas condiciones sea verdadera. Esto a veces es valioso cuando se trabaja con identidades de usuario, por ejemplo, para excluir entidades específicas (como cuentas de servicio) de los requisitos normales.

Condiciones de anidación

Las condiciones se pueden anidar de tal manera que una condición depende de otra condición. Por ejemplo, si tienes los dos niveles de acceso de confianza "Media" y "Alta", puedes establecer los requisitos para que "Alta" requiera "Media", además de otras condiciones.

Las condiciones de anidación pueden hacer que administrar los niveles de acceso sea más conveniente. Por ejemplo, imagina que tu nivel de acceso más permisivo contiene una versión mínima del sistema operativo y configuras tus niveles más restringidos para depender de él. Si actualizas la versión mínima en el futuro, solo tendrás que actualizar una sola condición, en lugar de cada nivel de acceso de la política.

Cuando anides niveles de acceso, ten en cuenta los siguientes límites y restricciones:

No hay dependencias circulares: No se permiten las dependencias circulares. Los niveles de acceso no pueden hacerse referencia entre sí en un bucle, ya sea de forma directa (por ejemplo, Level_A requiere Level_B y Level_B requiere Level_A, o un nivel de acceso se hace referencia a sí mismo) o de forma transitiva (por ejemplo, Level_A requiere Level_B, Level_B requiere Level_C y Level_C requiere Level_A). Si intentas crear o actualizar un nivel de acceso que introduce una dependencia circular, la llamada falla con un error INVALID_ARGUMENT.
Dependencias máximas por condición: En un nivel de acceso básico, la lista requiredAccessLevels de una sola condición puede hacer referencia a un máximo de 15 niveles de acceso más.
Profundidad de anidamiento: Debido a que Access Context Manager evalúa los niveles de acceso anidados en orden de dependencia en lugar de expandirlos de forma recurrente, no hay un límite de profundidad máximo independiente en una cadena de niveles de acceso anidados más allá del límite general de niveles de acceso por política de acceso. Todos los niveles de acceso a los que se hace referencia deben pertenecer a la misma política de acceso.