Resumen

Access Context Manager permite a los administradores de organizaciones de Google Cloud definir un control de acceso detallado basado en atributos para proyectos y recursos en Google Cloud.

Los administradores primero definen una política de acceso, que es un contenedor en toda la organización para los niveles de acceso y los perímetros de servicio.

Los niveles de acceso describen los requisitos necesarios que se deben respetar para las solicitudes. Los ejemplos incluyen:

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

Los perímetros de servicio definen zonas de pruebas de recursos que pueden intercambiar datos libremente dentro del perímetro, pero no se les permiten exportar datos fuera de él. Access Context Manager no es responsable de la aplicación de las políticas. Su propósito es describir las reglas deseadas. La política se configura y aplica de manera forzosa en varios puntos, como los Controles del servicio de VPC. Puedes leer más acerca de estos servicios en sus respectivas guías del usuario.

Por qué Access Context Manager

Muchas empresas dependen de un modelo de seguridad perimetral, por ejemplo, firewalls, para proteger recursos internos. Este modelo es similar a un castillo medieval: un fuerte con paredes gruesas, rodeado de un foso, con un punto único de entrada y salida muy protegido. Todo lo que se encuentre fuera de la pared se considera peligroso. Todo lo de adentro es de confianza.

Los firewalls y el modelo de seguridad perimetral funcionan bien si hay un límite preciso para usuarios y servicios específicos. Sin embargo, si una fuerza de trabajo es móvil, la variedad de dispositivos aumenta a medida que los usuarios traen sus propios dispositivos (BYOD) y usan servicios basados en la nube. Esto da como resultado vectores de ataque adicionales que el modelo de perímetro no considera. El perímetro ya no es solo la ubicación física de la empresa y lo que contiene dentro no se puede suponer que es seguro.

Access Context Manager te permite reducir el tamaño de la red privilegiada y pasar a un modelo en el que los extremos no lleven una autoridad ambiental según la red. En su lugar, puedes otorgar acceso en función del contexto de la solicitud, como el tipo de dispositivo, la identidad de usuario y más, sin dejar de verificar el acceso a la red corporativa si es 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 niveles de acceso y perímetros de servicio.

Access Context Manager es una función de toda la organización. Puedes crear una política de acceso en el contexto de un proyecto con fines de cuota, pero puedes usar la política en cualquier lugar de tu organización, no solo en ese proyecto.

Se creó una versión de una política de acceso con una etag. Esto te permite orientar cambios a tu política de acceso, como modificaciones a niveles de acceso, a una versión específica de la política. Si varias fuentes modifican la política de acceso, usar el campo etag para los comandos gcloud de Access Context Manager y las llamadas a la API puede garantizar que no se reemplacen cambios de forma inesperada y que no se ingresan conflictos indeseados.

Consulte la guía de inicio rápido para obtener información sobre cómo crear una política de acceso.

Niveles de acceso

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

Una vez que hayas definido los niveles de acceso, los servicios de aplicación pueden usarlos para determinar si cumplen con una solicitud. Por ejemplo, puedes especificar que, si bien muchos recursos están disponibles para “Medium_Trust”, algunos recursos más sensibles requieren el nivel “High_Trust”. Estas comprobaciones se aplican junto con la política estándar de administración de identidades y accesos.

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 ofrece dos formas de definir niveles de acceso: básico y personalizado.

Un nivel de acceso básico es una colección de condiciones que se usan para probar solicitudes. Las condiciones son un grupo de atributos que quieres probar, como el tipo de dispositivo, la dirección IP o la identidad de usuario. Los atributos de nivel de acceso representan información contextual sobre una solicitud.

Los niveles de acceso personalizados se crean con un subconjunto de Common Expression Language. Además del contexto de solicitud que se usa para los niveles de acceso básicos, también puedes usar niveles de acceso personalizados con el fin de permitir solicitudes basadas en datos de servicios de terceros. Para obtener más información, consulta Niveles de acceso personalizados.

Dirección IP

Puedes otorgar un nivel de acceso en función de la dirección IP de la solicitud original. El rango de IP que se permitirán se especifica en forma de un bloque Enrutamiento entre dominios sin clases (CIDR), que permite un control simple, pero detallado sobre las IP permitidas.

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

Consulta Crea un nivel de acceso para el acceso de red corporativo a fin de obtener información sobre cómo crear un nivel de acceso que solo permita el acceso a un rango de direcciones IP específico (por ejemplo, los que están dentro de una red corporativa).

Tipo de dispositivo

Access Context Manager usa la verificación de extremos para recopilar información relacionada con los dispositivos de los usuarios, incluida la versión y el sistema operativo. Puedes otorgar un nivel de acceso según estos datos. Por ejemplo, puedes optar por otorgar un nivel de acceso más permisivo a los dispositivos que ejecutan la última versión del sistema operativo principal implementado en tu empresa.

Lee Crea un nivel de acceso para dispositivos de usuarios a fin de obtener más información sobre cómo otorgar un nivel de acceso a determinados dispositivos.

Identidad de usuario

En algunos casos, es posible que desees otorgar un nivel de acceso a entidades específicas. En este caso, la identidad del emisor determina si se cumple la condición.

Este escenario a menudo se usa junto con Cuentas de servicio y Controles del servicio de VPC; por ejemplo, para habilitar una función de Cloud Functions para acceder a datos protegidos por los controles del servicio de VPC.

Los niveles de acceso solo con identidad solo se pueden crear y administrar con la herramienta de línea de gcloud, no con Google Cloud Console.

Aprenda a trabajar con identidades y niveles de acceso en Incluya identidades en niveles de acceso con redes.

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). Solo otorga el nivel de acceso si se cumplen todas las condiciones. Por ejemplo, es posible que necesites que una solicitud provenga de la red corporativa y de un dispositivo que ejecute el sistema operativo más reciente.

OR es una opción menos restrictiva. Solo se requiere una de las muchas condiciones. Esto a veces es valioso cuando se trata de identidades de usuarios. 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 modo que una condición dependa de otra condición. Por ejemplo, si tienes dos niveles de acceso, confianza “media” y “alta”, puedes establecer los requisitos para “Alta” y exigir “Media”, además de otras condiciones.

Las condiciones de anidación pueden hacer que la administración de niveles de acceso sea más conveniente. Por ejemplo, imagina el nivel de acceso más permisivo que contiene una versión mínima del sistema operativo y estableces los niveles más restrictivos para que dependan de este. Ahora, si actualizas la versión mínima en el futuro, solo tienes que actualizar una condición única, en lugar de cada nivel de acceso en la política.

Más información