En este documento se describen las prácticas recomendadas para usar el acceso contextual y proteger tus Google Cloud recursos de forma eficaz. El acceso contextual es un enfoque de seguridad que te permite controlar el acceso de los usuarios en función de la solidez de su autenticación, la postura del dispositivo, la ubicación de la red, la ubicación geográfica u otros atributos. Este enfoque va más allá del uso de identidades de usuario básicas para el acceso de seguridad y puede ayudarte a implementar un modelo de seguridad de confianza cero para mejorar tu postura de seguridad general. Para obtener información sobre cómo implementar el acceso contextual en diferentes tipos de aplicaciones y recursos, consulta el artículo Proteger aplicaciones y recursos mediante el acceso contextual.
Para proteger tus aplicaciones y recursos de Google Cloud , puedes definir un control de acceso granular basado en una variedad y combinación de factores contextuales. Puedes usar el Administrador de contextos de acceso para definir políticas de acceso, que contienen niveles de acceso y parámetros de servicio.
Este documento está dirigido a cualquier profesional de la seguridad responsable de la gestión de identidades y accesos (IAM) y de la seguridad de los recursos y las aplicaciones de Google Cloud . En este documento se da por hecho que ya conoces el Administrador de contextos de acceso,Google Cloudy la gestión de IAM.
Métodos de acceso contextual
Cuando configures el acceso contextual en tu organización, debes decidir si quieres aplicar controles de acceso contextual a las aplicaciones, los recursos o ambos. Para tomar esa decisión, es útil distinguir entre los siguientes tipos de aplicaciones y servicios:
- Aplicaciones administrativas: estas aplicaciones permiten a los usuarios gestionar o interactuar conGoogle Cloud recursos, como instancias de VM, conjuntos de datos de BigQuery o segmentos de Cloud Storage. Algunos ejemplos de aplicaciones administrativas son la consola, la CLI de Google Cloud, Terraform y IAP Desktop. Google Cloud
- Aplicaciones de línea de negocio: estas aplicaciones incluyen aplicaciones web que se ejecutan enGoogle Cloud y usan SAML o Identity-Aware Proxy (IAP) para la autenticación y la autorización. Estas aplicaciones se denominan aplicaciones internas. Entre las aplicaciones de línea de negocio se incluyen los sistemas de gestión de relaciones con clientes (CRM), los paneles de control y otras aplicaciones personalizadas.
- Google Workspace y otros servicios de Google: estos servicios los proporciona Google, pero no están relacionados con Google Cloud.
Puedes distinguir aún más las aplicaciones de línea de negocio en función de cómo gestionen la autenticación y la autorización:
- SAML aplicaciones que usan SAML de Google Workspace para la autenticación. Las aplicaciones SaaS suelen pertenecer a esta categoría.
- IAP: aplicaciones web personalizadas que has implementado detrás de IAP.
- OAuth aplicaciones web o de escritorio personalizadas que usan OAuth 2.0 y uno o varios Google Cloud permisos de OAuth.
En el siguiente diagrama de flujo se muestra el enfoque de acceso adaptado al contexto más adecuado para cada tipo de aplicación:
En el diagrama se muestran los siguientes tipos de aplicaciones:
Aplicaciones administrativas: por lo general, es más importante proteger los recursos a los que facilita el acceso la aplicación administrativa que la propia aplicación.Google Cloud Veamos los siguientes casos:
- Un usuario no puede acceder a ninguno de los recursos. En este caso, es probable que el usuario no valore tanto el acceso a una aplicación administrativa.
- Un usuario tiene acceso a un recurso, pero no puede acceder a una aplicación administrativa. En este caso, es posible que pueda encontrar otra aplicación administrativa que no esté bloqueada y que le permita acceder al recurso.
Por lo tanto, en el caso de las aplicaciones administrativas, adopta un enfoque centrado en los recursos. Para aplicar los controles de acceso contextuales adecuados a los recursos de la forma más eficaz, utiliza perímetros de servicio de nube privada virtual (VPC) con las reglas de entrada apropiadas. Puedes complementar los perímetros de servicio de VPC con vinculaciones de acceso.
Aplicaciones de línea de negocio que usan OAuth: en estas aplicaciones, es importante proteger el acceso a las aplicaciones en sí, así como a los recursos que puedan usar. Para proteger las aplicaciones mediante el acceso contextual, usa enlaces de acceso.
Aplicaciones de línea de negocio que usan IAP: aunque IAP usa OAuth, no puedes usar enlaces de acceso para proteger aplicaciones que usen IAP para autenticar usuarios. En su lugar, protege estas aplicaciones mediante condiciones de gestión de identidades y accesos.
Aplicaciones de línea de negocio que usan SAML: al igual que las aplicaciones de línea de negocio que usan OAuth, es importante proteger el acceso a las aplicaciones en sí, así como a los recursos que puedan usar. Para proteger estas aplicaciones, usa el acceso contextual de Google Workspace.
Google Workspace y otros servicios de Google: en estas aplicaciones, es importante proteger el acceso a las aplicaciones en sí, así como a los recursos que puedan usar. Para proteger estas aplicaciones, usa el acceso contextual de Google Workspace.
Gestión del nivel de acceso
En las siguientes secciones se describen las prácticas recomendadas que debes seguir al gestionar los niveles de acceso.
Crear niveles de acceso reutilizables
Los niveles de acceso son un recurso global y están pensados para usarse en todos los recursos de tu organización Google Cloud . Por lo tanto, es mejor limitar el número total de niveles de acceso y hacer que sean significativos y aplicables en varios recursos. Ten en cuenta lo siguiente:
- No incluyas los nombres de recursos o aplicaciones específicos en el nombre de un nivel de acceso.
- No codifiques ningún requisito específico de recursos o aplicaciones en un nivel de acceso.
- Usa nombres que afirmen una postura determinada del usuario o del dispositivo, como
Fully Trusted Device.
Usar niveles de acceso compuestos
Para reducir la sobrecarga de mantenimiento y garantizar la coherencia cuando cambien las subredes o las regiones, no repitas los mismos requisitos en varios niveles de acceso. En su lugar, haz que los niveles de acceso dependan entre sí.
Por ejemplo, no incluyas las mismas regiones o subredes IP de confianza en varios niveles de acceso, sino que crea un nivel de acceso adicional llamado Trusted location. Este nivel Trusted location puede servir
como dependencia de los demás niveles de acceso.
Eximir a los usuarios con acceso de emergencia en los niveles de acceso
Para evitar que se produzca un bloqueo accidental, es recomendable excluir al menos a un usuario de acceso de emergencia de todos los niveles de acceso. Para asegurarte de que la exención se aplique a todas las aplicaciones y recursos a los que apliques el nivel de acceso, configura la exención en el propio nivel de acceso:
- Añade una condición que defina tus requisitos habituales.
- Añade otra condición con un
membersrequisito que incluya a uno o varios de tus usuarios con acceso de emergencia. - Define la función de combinación como una
ORcondición para que los usuarios solo tengan que cumplir una de las dos condiciones.
Por ejemplo, el siguiente nivel de acceso restringe el acceso a tres regiones, pero el usuario emergencyaccess@example.net no tiene que cumplir este requisito:
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
Configurar un mensaje de solución
Es posible que los usuarios de tu organización no sepan que su ubicación, su dispositivo y otros factores pueden influir en si tienen permiso para acceder a determinadas aplicaciones. Para mantener a los usuarios informados y reducir las solicitudes de asistencia, configura un mensaje de solución personalizado que les indique los pasos que deben seguir para recuperar el acceso.
Gestión de vinculaciones de acceso
Los enlaces de acceso te permiten configurar el acceso contextual para las aplicaciones OAuth que usan uno o varios permisos. Google Cloud Los enlaces de acceso también son una forma eficaz de aplicar el acceso contextual a las aplicaciones de línea de negocio.
En las siguientes secciones se describen las prácticas recomendadas que debes seguir al usar enlaces de acceso.
Usar un solo enlace de acceso con ajustes acotados
Cuando uses enlaces de acceso, debes tener en cuenta las siguientes restricciones:
- Cada grupo de Cloud Identity puede tener un máximo de un enlace de acceso.
- Si se aplica más de un enlace de acceso a un usuario, tiene prioridad el enlace de acceso menos restrictivo.
Para cumplir estas dos restricciones, usa un solo enlace de acceso que se aplique a todos tus usuarios:
- Crea un grupo que contenga automáticamente a todos los usuarios de tu cuenta de Cloud Identity o Google Workspace.
- Crea o usa una vinculación de acceso que asocie un nivel de acceso predeterminado al grupo. El nivel de acceso predeterminado debería ser adecuado para la mayoría de los usuarios, dispositivos y aplicaciones.
- Si es necesario, usa los ajustes de acceso limitado (
scopedAccessSettings) para asignar niveles de acceso más débiles a las aplicaciones seleccionadas.
Usar un nivel de acceso predeterminado estricto
Si un enlace de acceso especifica tanto un ajuste de acceso con ámbito como un nivel de acceso predeterminado, los dos niveles de acceso se combinan mediante la semántica OR.
Este comportamiento tiene las siguientes implicaciones:
- Para acceder a la aplicación OAuth, los usuarios solo tienen que cumplir uno de los niveles de acceso.
- Cuando añades un ajuste de acceso limitado a una aplicación OAuth, puedes reducir los requisitos de acceso efectivos.
- Un ajuste de acceso limitado no tiene ningún efecto si usa un nivel de acceso más estricto que el nivel de acceso predeterminado del enlace de acceso.
Cuando selecciones un nivel de acceso predeterminado para un enlace de acceso, te recomendamos que hagas lo siguiente:
- Usar un nivel de acceso estricto como nivel de acceso predeterminado.
- Aplica niveles de acceso inferiores a aplicaciones OAuth concretas mediante ajustes de acceso con ámbito.
Puedes añadir algunas o todas las siguientes restricciones al nivel de acceso predeterminado:
- Restricciones de navegador y dispositivo: exige que tus usuarios accedan a las aplicaciones mediante un navegador Chrome gestionado y un dispositivo aprobado por el administrador.
- Restricciones geográficas: si tu organización opera exclusivamente en determinadas regiones, usa restricciones de región para incluir solo esas regiones en la lista de permitidas. De lo contrario, puedes usar las restricciones por región para restringir el acceso a las zonas geográficas que tengan sanciones o que no sean relevantes por otros motivos.
- Restricciones de red IP: si los usuarios de tu organización acceden a Google Cloud exclusivamente desde determinadas redes o si tu organización usa un proxy de salida común, puedes incluir restricciones de red IP.
No uses niveles de acceso que requieran autenticación basada en certificados como nivel de acceso predeterminado. La autenticación basada en certificados es la más adecuada para las reglas de acceso de los perímetros de servicio de VPC.
Gestionar excepciones por aplicación
Para gestionar las excepciones al nivel de acceso predeterminado, añade excepciones para aplicaciones concretas en lugar de para usuarios o grupos.
Un nivel de acceso predeterminado estricto puede ser adecuado para la mayoría de las aplicaciones, pero no para todas:
- Puede que algunas aplicaciones sean menos sensibles y que necesites que los usuarios que no cumplan el nivel de acceso predeterminado puedan acceder a ellas. Por ejemplo, aplicaciones a las que deben acceder partners, invitados o antiguos alumnos.
- Es posible que algunas aplicaciones sean técnicamente incompatibles con una de las restricciones que se aplican en el nivel de acceso predeterminado.
Para excluir aplicaciones concretas del nivel de acceso predeterminado, usa la configuración de acceso limitado. En cada aplicación afectada, añade un ajuste con ámbito y asigna un nivel de acceso más adecuado para la aplicación en cuestión.
No cree enlaces de acceso adicionales para gestionar excepciones por usuario o grupo. Las vinculaciones de acceso adicionales pueden provocar los siguientes problemas:
- Es posible que crees enlaces de acceso superpuestos sin darte cuenta.
- Puede que sea difícil determinar qué requisitos de acceso contextual se están aplicando de forma eficaz en aplicaciones concretas.
Evitar las vinculaciones de acceso superpuestas
Las vinculaciones de acceso están asociadas a grupos. Si un usuario es miembro de varios grupos, se le pueden aplicar varios enlaces de acceso. En este caso, los requisitos de acceso en función del contexto de estas vinculaciones de acceso se combinan mediante la semántica OR.
Este comportamiento puede provocar efectos no deseados. Por ejemplo, si se permite que los usuarios se unan a más grupos, se puede poner en peligro la protección de determinadas aplicaciones.
Para evitar este tipo de situaciones, te recomendamos que no superpongas enlaces de acceso:
- Minimiza el número de enlaces de acceso, idealmente a uno.
- Si necesitas varios enlaces de acceso, asígnalos a grupos que sean mutuamente excluyentes.
Proteger los grupos frente a modificaciones no autorizadas
De forma predeterminada, Cloud Identity permite que los miembros de un grupo lo abandonen. Este comportamiento es adecuado para los grupos de acceso, pero supone un problema para los grupos con enlaces de acceso asociados. Si un usuario abandona un grupo que tiene una vinculación de acceso asociada, dejará de estar sujeto a los requisitos de acceso contextual que imponen las vinculaciones de acceso. Por lo tanto, los usuarios pueden eludir los requisitos de acceso contextual saliendo de un grupo.
Utiliza siempre grupos de aplicación y no permitas que los usuarios abandonen un grupo de aplicación cuando configures enlaces de acceso. También puedes crear un grupo que incluya automáticamente a todos los usuarios de tu cuenta de Cloud Identity o Google Workspace.
No permitir el acceso de usuarios externos cuando se usan enlaces de acceso
Los enlaces de acceso solo afectan a los usuarios de la cuenta de Cloud Identity o de Google Workspace a la que pertenece tu Google Cloud organización. Estos usuarios siguen estando sujetos a las vinculaciones de acceso de tu Google Cloud organización si intentan acceder a recursos de otras Google Cloud organizaciones. Esta aplicación de enlaces de acceso en usuarios es diferente del comportamiento en otros contextos con Cloud Identity.
Si permites que los usuarios de cuentas externas de Cloud Identity o Google Workspace accedan a los recursos de tus organizaciones, tus enlaces de acceso no tendrán ningún efecto en esos usuarios. Google Cloud
Para asegurarte de que tus enlaces de acceso sean efectivos, no concedas acceso a usuarios externos a ninguna aplicación ni recurso de tu organización de Google Cloud . Además, no añadas usuarios externos a grupos de tu cuenta de Cloud Identity o Google Workspace.
Usar enlaces de acceso independientes para controlar la duración de las sesiones
Además del control de acceso contextual, también puedes usar enlaces de acceso para gestionar la duración de las sesiones del navegador y los tokens de OAuth.
Cuando usas enlaces de acceso para controlar el acceso contextual, lo mejor es evitar que se solapen.
Cuando uses enlaces de acceso para controlar la duración de la sesión, no crees enlaces de acceso superpuestos. Si se aplica más de un enlace de acceso de este tipo a un usuario, solo se tendrá en cuenta el último enlace de acceso actualizado, lo que puede dar lugar a resultados no deseados.
Para evitar estos resultados no deseados, usa un enlace de acceso independiente para controlar la duración de la sesión.
No permitir que los usuarios actúen como cuentas de servicio
Los enlaces de acceso se aplican a los usuarios de Cloud Identity y Google Workspace, pero no afectan a las cuentas de servicio. Si permites que los usuarios se autentiquen y actúen como una cuenta de servicio, podrían eludir tus controles de acceso contextuales.
Existen otros riesgos cuando los usuarios pueden actuar como cuentas de servicio. Si quieres permitir que los usuarios aumenten sus privilegios temporalmente, te recomendamos que uses Gestor de acceso privilegiado. No uses la suplantación de identidad de cuentas de servicio, excepto para fines de desarrollo.
Para obtener más información sobre cómo proteger las cuentas de servicio y sus claves, consulta las prácticas recomendadas para usar cuentas de servicio y las prácticas recomendadas para gestionar claves de cuentas de servicio.
Reglas de entrada para perímetros de servicio de VPC
Las reglas de entrada te permiten conceder acceso contextual desde fuera del perímetro de servicio a los recursos que se encuentran dentro del perímetro. Los perímetros de servicio de VPC y las reglas de entrada protegen los Google Cloud recursos, no las aplicaciones individuales. Por lo tanto, un perímetro de servicio con reglas de entrada es ideal para aplicar el acceso contextual a herramientas administrativas como la consola y la CLI de gcloud. Google Cloud
Para obtener más información y consultar las prácticas recomendadas sobre los perímetros de servicio de VPC, consulta el artículo Prácticas recomendadas para habilitar Controles de Servicio de VPC.
En las siguientes secciones se describen las prácticas recomendadas para usar reglas de entrada con el fin de aplicar el acceso contextual.
Incluir el reenvío de TCP de IAP como servicio restringido
Permitir que los usuarios se conecten a instancias de VM de tu perímetro de servicio mediante SSH o RDP puede ser arriesgado por los siguientes motivos:
- Tus reglas de entrada no se aplican a las conexiones porque el uso de SSH y RDP no implica el acceso a ninguna API de Google.
- Una vez que los usuarios establecen una sesión SSH o RDP, se considera que cualquier acceso a la API que se inicie desde dentro de esa sesión se ha originado desde dentro del perímetro de servicio. Por lo tanto, tus reglas de entrada no se aplican a ningún acceso a la API iniciado desde esa sesión.
Para mitigar estos riesgos, permite el acceso SSH y RDP a las VMs solo a través del reenvío de TCP de IAP:
- Incluye el servicio
iaptunnel.googleapis.comcomo servicio restringido. - Configura reglas de cortafuegos que restrinjan el acceso a los puertos SSH y RDP mediante el reenvío de TCP de IAP.
Usa el reenvío de TCP de IAP para asegurarte de que la configuración de las reglas de entrada del perímetro de servicio de tu VPC se aplique a todos los intentos de acceso por SSH y RDP.
Usar el acceso basado en certificados para perímetros de servicio sensibles
De forma predeterminada, los tokens de acceso y de actualización de Google no están vinculados a un dispositivo y pueden ser vulnerables a robos o ataques de repetición. Para mitigar estos riesgos, puedes usar el acceso basado en certificados (CBA), que restringe el acceso a los dispositivos que tienen un certificado X.509 de confianza.
La autenticación basada en certificados te ayuda a reforzar la seguridad, pero este enfoque también añade requisitos de infraestructura adicionales:
- El dispositivo de un usuario debe tener un certificado X.509 emitido por una autoridad de certificación interna.
- La clave asociada al certificado debe almacenarse de forma que se impida la exportación no autorizada.
- Las aplicaciones cliente deben usar la autenticación TLS mutua (mTLS) para conectarse a las APIsGoogle Cloud .
Usa la autenticación basada en certificados para proteger el acceso a tus perímetros de servicio de VPC más sensibles. Este enfoque te permite equilibrar la solidez de la seguridad con los requisitos mínimos de infraestructura y el impacto general.
Colaboradores
Autor: Johannes Passing | Arquitecto de soluciones en la nube
Otro colaborador: Ido Flatow | Arquitecto de soluciones en la nube