En este documento, se describen las prácticas recomendadas para usar el acceso adaptado al contexto y proteger tus Google Cloud recursos de manera eficaz. El acceso adaptado al contexto es un enfoque de seguridad en el que controlas el acceso de los usuarios en función de su nivel de autenticación, la postura del dispositivo, la ubicación de la red, la ubicación geográfica o cualquier otro atributo. Este enfoque va más allá de usar 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 detalles sobre cómo implementar el acceso adaptado al contexto para diferentes tipos de apps y recursos, consulta Protege apps y recursos con el acceso adaptado al contexto.
Para proteger tus apps y Google Cloud recursos, puedes definir un control de acceso detallado basado en una variedad y combinación de factores contextuales. Puedes usar Access Context Manager para definir políticas de acceso, que contienen niveles de acceso y parámetros de servicio.
Este documento está dirigido a cualquier profesional de seguridad responsable de Identity and Access Management (IAM) y de la seguridad de los Google Cloud recursos y las apps. En este documento, se supone que ya estás familiarizado con Access Context Manager, Google Cloud, y la administración de IAM.
Enfoques de acceso adaptado al contexto
Cuando configuras el acceso adaptado al contexto en tu organización, debes decidir si deseas aplicar controles de acceso adaptado al contexto a las apps, los recursos o ambos. Para tomar esa decisión, es útil distinguir entre los siguientes tipos diferentes de apps y servicios:
- Apps administrativas: Estas apps permiten que los usuarios administren recursos, como instancias de VM, conjuntos de datos de BigQuery o buckets de Cloud Storage, o interactúen con ellos. Google Cloud Algunos ejemplos de apps administrativas incluyen la Google Cloud consola, Google Cloud CLI, Terraform y IAP Desktop.
- Apps de línea de negocios: Estas apps incluyen apps web que se ejecutan en Google Cloud y usan SAML o Identity-Aware Proxy (IAP) para la autenticación y la autorización. A veces, estas apps se denominan apps internas. Algunos ejemplos de apps de línea de negocios incluyen sistemas CRM, paneles y otras apps personalizadas.
- Google Workspace y otros servicios de Google: Google proporciona estos servicios, pero no están relacionados con Google Cloud.
Puedes distinguir aún más las apps de línea de negocios según cómo manejan la autenticación y la autorización:
- SAML: Apps que usan SAML de Google Workspace para la autenticación. Las apps de SaaS suelen pertenecer a esta categoría.
- IAP: Apps web personalizadas que implementaste detrás de IAP.
- OAuth: Apps web o de escritorio personalizadas que usan OAuth 2.0 y uno o más 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 app:
En el diagrama, se muestran los siguientes tipos de apps:
Apps administrativas: Por lo general, es más importante proteger los Google Cloud recursos a los que la app administrativa facilita el acceso que la app en sí. Considere estas situaciones:
- Un usuario no puede acceder a ninguno de los recursos. En este caso, es probable que el acceso a una app administrativa no sea tan valioso para el usuario.
- Un usuario tiene acceso a un recurso, pero no puede acceder a una app administrativa. En este caso, es posible que pueda encontrar una app administrativa diferente que no esté bloqueada y que le permita acceder al recurso.
Por lo tanto, para las apps administrativas, adopta un enfoque centrado en los recursos. Para aplicar de la manera más eficaz los controles de acceso adaptado al contexto correctos a los recursos, usa perímetros de servicio de la nube privada virtual (VPC) con las reglas de entrada adecuadas. Puedes complementar los perímetros de servicio de VPC con vinculaciones de acceso.
Apps de línea de negocios que usan OAuth: Para estas apps, es importante proteger el acceso a las apps en sí, así como a los recursos que podrían usar las apps. Para proteger las apps con el acceso adaptado al contexto, usa vinculaciones de acceso.
Apps de línea de negocios que usan IAP: Aunque IAP usa OAuth, no puedes usar vinculaciones de acceso para proteger las apps que usan IAP para autenticar a los usuarios. En su lugar, protege estas apps con condiciones de IAM.
Apps de línea de negocios que usan SAML: Al igual que las apps de línea de negocios que usan OAuth, es importante proteger el acceso a las apps en sí, así como a los recursos que podrían usar las apps. Para proteger estas apps, usa el acceso adaptado al contexto de Google Workspace.
Google Workspace y otros servicios de Google: Para estas apps, es importante proteger el acceso a las apps en sí, así como a los recursos que podrían usar las apps. Para proteger estas apps, usa el acceso adaptado al contexto de Google Workspace.
Administración del nivel de acceso
En las siguientes secciones, se describen las prácticas recomendadas para usar cuando administras los niveles de acceso.
Crea niveles de acceso reutilizables
Los niveles de acceso son un recurso global y están diseñados para usarse en todos los recursos de tu Google Cloud organización. Por lo tanto, es mejor limitar la cantidad general de niveles de acceso y hacer que sean significativos y aplicables en varios recursos. Ten en cuenta lo siguiente:
- Evita incorporar los nombres de recursos o apps específicos en el nombre de un nivel de acceso.
- Evita codificar cualquier requisito específico de recursos o de apps en un nivel de acceso.
- Usa nombres que afirmen una determinada postura del usuario o del dispositivo, como
Fully Trusted Device.
Usa niveles de acceso compuestos
Para reducir la sobrecarga de mantenimiento y garantizar la coherencia cuando cambian las subredes o las regiones, no repitas los mismos requisitos en varios niveles de acceso. En su lugar, permite que los niveles de acceso dependan unos de otros.
Por ejemplo, no enumeres 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 para los otros niveles de acceso.
Exime a los usuarios de acceso de emergencia en los niveles de acceso
Para evitar un bloqueo accidental, es mejor 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 apps y los recursos a los que aplicas el nivel de acceso, configura la exención en el nivel de acceso en sí:
- Agrega una condición que defina tus requisitos habituales.
- Agrega otra condición con un
membersrequisito que enumere uno o más de tus usuarios de acceso de emergencia. - Configura la función de combinación en una condición
ORpara que los usuarios solo deban cumplir con una de las dos condiciones.
Por ejemplo, el siguiente nivel de acceso restringe el acceso a tres regiones, pero el usuario emergencyaccess@example.net está exento de este requisito:
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
Configura un mensaje de corrección
Es posible que los usuarios de tu organización no sepan que su ubicación, dispositivo y otros factores pueden afectar si se les permite acceder a ciertas apps o no. Para mantener informados a los usuarios y reducir las solicitudes de asistencia, configura un mensaje de corrección personalizado que les indique los pasos que deben seguir para recuperar el acceso.
Administración de vinculaciones de acceso
Las vinculaciones de acceso te permiten configurar el acceso adaptado al contexto para las apps de OAuth que usan uno o más Google Cloud permisos. Las vinculaciones de acceso también son una forma eficaz de aplicar el acceso adaptado al contexto para las apps de línea de negocios.
En las siguientes secciones, se describen las prácticas recomendadas para usar cuando usas vinculaciones de acceso.
Usa una sola vinculación de acceso con parámetros de configuración determinados
Cuando usas vinculaciones de acceso, debes tener en cuenta las siguientes restricciones:
- Cada grupo de Cloud Identity puede tener un máximo de una vinculación de acceso.
- Si se aplica más de una vinculación de acceso a un usuario, tiene prioridad la vinculación de acceso menos restrictiva.
Para adaptarse a estas dos restricciones, usa una sola vinculación 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 de Google Workspace.
- Crea o usa una vinculación de acceso que asocie un nivel de acceso predeterminado con el grupo. El nivel de acceso predeterminado debe ser adecuado para la mayoría de los usuarios, dispositivos y apps.
- Si es necesario, usa
la configuración de acceso determinado (
scopedAccessSettings) para asignar niveles de acceso más débiles a las apps seleccionadas.
Usa un nivel de acceso predeterminado estricto
Si una vinculación de acceso especifica una configuración de acceso determinado y un nivel de acceso predeterminado, los dos niveles de acceso se combinan con la semántica OR.
Este comportamiento tiene las siguientes implicaciones:
- Un usuario solo necesita cumplir con uno de los niveles de acceso para acceder a la app de OAuth.
- Cuando agregas una configuración de acceso determinado para una app de OAuth, puedes reducir los requisitos de acceso efectivos.
- Una configuración de acceso determinado no tiene efecto si usa un nivel de acceso más estricto que el nivel de acceso predeterminado de la vinculación de acceso.
Cuando seleccionas un nivel de acceso predeterminado para una vinculación de acceso, te recomendamos que hagas lo siguiente:
- Usa un nivel de acceso estricto como nivel de acceso predeterminado.
- Aplica niveles de acceso más bajos a las apps de OAuth individuales con la configuración de acceso determinado.
Considera agregar algunas o todas las siguientes restricciones al nivel de acceso predeterminado:
- Restricciones de navegador y dispositivo: Exige que los usuarios accedan a las apps con un navegador Chrome administrado y un dispositivo aprobado por el administrador.
- Restricciones geográficas: Si tu organización opera exclusivamente en ciertas regiones, usa restricciones de región para incluir solo esas regiones en la lista de entidades permitidas. De lo contrario, puedes usar restricciones de región para restringir el acceso a ubicaciones 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 Google Cloud exclusivamente desde ciertas 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 más adecuada para las reglas de entrada del perímetro de servicio de VPC.
Administra excepciones por app
Para administrar las excepciones al nivel de acceso predeterminado, agrega excepciones para apps individuales, en lugar de excepciones para usuarios o grupos.
Un nivel de acceso predeterminado estricto puede ser adecuado para la mayoría de las apps, pero no para todas:
- Es posible que algunas apps sean menos sensibles y debas hacerlas accesibles para los usuarios que no cumplen con el nivel de acceso predeterminado. Algunos ejemplos pueden incluir apps que deben ser accesibles para socios, invitados o exalumnos.
- Es posible que algunas apps sean técnicamente incompatibles con una de las restricciones que aplica el nivel de acceso predeterminado.
Para eximir apps individuales del nivel de acceso predeterminado, usa la configuración de acceso determinado. Para cada app afectada, agrega un parámetro de configuración determinado y asigna un nivel de acceso que sea más adecuado para la app individual.
No crees vinculaciones de acceso adicionales para administrar excepciones por usuario o grupo. Las vinculaciones de acceso adicionales pueden causar los siguientes problemas:
- Es posible que crees vinculaciones de acceso superpuestas sin darte cuenta.
- Puede ser difícil determinar qué requisitos de acceso adaptado al contexto se aplican de manera eficaz para las apps individuales.
Evita las vinculaciones de acceso superpuestas
Las vinculaciones de acceso están asociadas con grupos. Si un usuario es miembro de varios grupos, se le podrían aplicar varias vinculaciones de acceso. En este caso, los requisitos de acceso adaptado al contexto de estas vinculaciones de acceso se combinan con la semántica OR.
Este comportamiento puede causar efectos no deseados. Por ejemplo, cuando se permite que los usuarios se unan a grupos adicionales, se puede socavar la protección de ciertas apps.
Para evitar estas situaciones, te recomendamos que evites las vinculaciones de acceso superpuestas:
- Minimiza la cantidad de vinculaciones de acceso, idealmente a una.
- Si necesitas varias vinculaciones de acceso, asígnalas a grupos que sean mutuamente exclusivos.
Protege los grupos de modificaciones no autorizadas
De forma predeterminada, Cloud Identity permite que los miembros del grupo abandonen un grupo. Este comportamiento es adecuado para los grupos de acceso, pero es problemático para los grupos con vinculaciones de acceso asociadas. Si un usuario abandona un grupo que tiene una vinculación de acceso asociada, ya no está sujeto a los requisitos de acceso adaptado al contexto que imponen las vinculaciones de acceso. Por lo tanto, los usuarios pueden eludir los requisitos de acceso adaptado al contexto si abandonan un grupo.
Siempre usa grupos de aplicación y no permitas que los usuarios abandonen un grupo de aplicación cuando configures vinculaciones de acceso. Como alternativa, crea un grupo que contenga automáticamente a todos los usuarios de tu cuenta de Cloud Identity o de Google Workspace.
No permitas el acceso de usuarios externos cuando uses vinculaciones de acceso
Las vinculaciones 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 aún están sujetos a las vinculaciones de acceso en tu Google Cloud organización si intentan acceder a recursos en otras Google Cloud organizaciones. Esta aplicación de vinculaciones de acceso en los usuarios es diferente del comportamiento en otros contextos con Cloud Identity.
Si permites que los usuarios de cuentas externas de Cloud Identity o de Google Workspace accedan a los recursos de tus Google Cloud organizaciones, tus vinculaciones de acceso no tendrán ningún efecto en esos usuarios.
Para asegurarte de que tus vinculaciones de acceso sean eficaces, no otorgues acceso a usuarios externos a ninguna app o recurso de tu Google Cloud organización. Además, no agregues usuarios externos a grupos en tu cuenta de Cloud Identity o de Google Workspace.
Usa vinculaciones de acceso independientes para el control de la duración de la sesión
Además del control de acceso adaptado al contexto, también puedes usar vinculaciones de acceso para administrar la duración de las sesiones del navegador y los tokens de OAuth.
Cuando usas vinculaciones de acceso para controlar el acceso adaptado al contexto, es mejor evitar las vinculaciones de acceso superpuestas.
Cuando usas vinculaciones de acceso para controlar la duración de la sesión, no crees vinculaciones de acceso superpuestas. Si se aplica más de una vinculación de acceso de este tipo a un usuario, solo se aplica la vinculación de acceso actualizada más recientemente, lo que puede generar resultados no deseados.
Para evitar estos resultados no deseados, usa una vinculación de acceso independiente para controlar la duración de la sesión.
No permitas que los usuarios actúen como una cuenta de servicio
Las vinculaciones 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, es posible que puedan socavar tus controles de acceso adaptado al contexto.
Existen otros riesgos cuando los usuarios pueden actuar como una cuenta de servicio. Si deseas permitir que los usuarios eleven sus privilegios de forma temporal, te recomendamos que uses Privileged Access Manager. No uses la identidad temporal como cuenta de servicio, excepto para fines de desarrollo.
Para obtener más información sobre cómo proteger las cuentas de servicio y las claves de cuentas de servicio, consulta Prácticas recomendadas para usar cuentas de servicio y Prácticas recomendadas para administrar claves de cuentas de servicio.
Reglas de entrada para perímetros de servicio de VPC
Las reglas de entrada te permiten otorgar acceso adaptado al contexto desde fuera del perímetro de servicio a los recursos dentro del perímetro. Los perímetros de servicio de VPC y las reglas de entrada protegen Google Cloud los recursos, no las apps individuales. Por lo tanto, un perímetro de servicio con reglas de entrada es ideal para aplicar el acceso adaptado al contexto para herramientas administrativas, como la Google Cloud consola y la gcloud CLI.
Para obtener más información y conocer las prácticas recomendadas sobre los perímetros de servicio de VPC, consulta Prácticas recomendadas para habilitar los Controles del servicio de VPC.
En las siguientes secciones, se describen las prácticas recomendadas para cuando usas reglas de entrada para aplicar el acceso adaptado al contexto.
Incluye el reenvío de TCP de IAP como un servicio restringido
Puede ser riesgoso permitir que los usuarios se conecten a instancias de VM en tu perímetro de servicio con SSH o RDP por los siguientes motivos:
- Tus reglas de entrada no se aplican a las conexiones porque el uso de SSH y RDP no implica ningún acceso a la API de Google.
- Después de que los usuarios establecen una sesión de SSH o RDP, se considera que cualquier acceso a la API que se inicia desde esa sesión se originó dentro del perímetro de servicio. Por lo tanto, tus reglas de entrada no se aplican a ningún acceso a la API que se inicie 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
iaptunnel.googleapis.comservicio como un servicio restringido. - Configura reglas de firewall que restrinjan el acceso a los puertos SSH y RDP a través del 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 VPC se aplique a cada intento de acceso SSH y RDP.
Usa el acceso basado en certificados para perímetros de servicio sensibles
De forma predeterminada, los tokens de acceso y los tokens de actualización de Google no están vinculados a un dispositivo y pueden ser vulnerables al robo o a los ataques repetidos. Para mitigar estos riesgos, puedes usar el acceso basado en certificados (CBA), que restringe el acceso a los dispositivos que poseen un certificado X.509 de confianza.
El CBA te ayuda a fortalecer la seguridad, pero este enfoque también agrega requisitos de infraestructura adicionales:
- El dispositivo de un usuario debe tener un certificado X.509 emitido por una autoridad certificadora interna.
- La clave asociada con el certificado debe almacenarse de una manera que impida la exportación no autorizada.
- Las apps cliente deben usar la autenticación de TLS mutua (mTLS) para conectarse a Google Cloud las APIs.
Usa el CBA 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 requisitos de infraestructura mínimos y un impacto general.
Colaboradores
Autor: Johannes Passing | Arquitecto de Soluciones de Cloud
Otro colaborador: Ido Flatow | Arquitecto de Soluciones de Cloud