En este documento, se describen las prácticas recomendadas para usar el acceso según el contexto y proteger tus recursos de Google Cloud 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 la solidez de su autenticación, la posición del dispositivo, la ubicación de la red, la ubicación geográfica o cualquier otro atributo. Este enfoque va más allá del uso de identidades básicas de usuario para el acceso de seguridad y puede ayudarte a implementar un modelo de seguridad de confianza cero para mejorar tu posición 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 recursos de Google Cloud , 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 la seguridad de los recursos y las apps de Google Cloud . En este documento, se supone que ya conoces Access Context Manager,Google Cloudy la administración de IAM.
Enfoques de acceso adaptado al contexto
Cuando configures 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 a los usuarios administrar o interactuar con recursos deGoogle Cloud , como instancias de VM, conjuntos de datos de BigQuery o buckets de Cloud Storage. Entre los ejemplos de apps administrativas, se incluyen la consola de Google Cloud , Google Cloud CLI, Terraform y IAP Desktop.
- Apps de línea de negocio: Estas apps incluyen apps web que se ejecutan enGoogle 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. Entre los ejemplos de apps de línea de negocio, se incluyen los sistemas de CRM, los paneles y otras apps 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 apps de línea de negocio según cómo manejan la autenticación y la autorización:
- SAML: Son las apps que usan SAML de Google Workspace para la autenticación. Las apps de SaaS suelen entrar en esta categoría.
- IAP: Apps web personalizadas que implementaste detrás de IAP.
- OAuth: Apps personalizadas para la Web o computadoras 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 según el contexto más adecuado para cada tipo de app:
En el diagrama, se muestran los siguientes tipos de apps:
Apps administrativas: En general, es más importante proteger los recursosGoogle Cloud 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 tener 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 otra app administrativa 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 los controles de acceso basados en el contexto adecuados a los recursos de la manera más eficaz, usa perímetros de servicio de la nube privada virtual (VPC) con las reglas de entrada apropiadas. Puedes complementar los perímetros de servicio de VPC con vinculaciones de acceso.
Apps de línea de negocios que usan OAuth: En el caso de estas apps, es importante proteger el acceso a las apps en sí, así como a los recursos que podrían usar. Para proteger las apps con el acceso adaptado al contexto, usa vinculaciones de acceso.
Apps de línea de negocio que usan IAP: Si bien IAP usa OAuth, no puedes usar vinculaciones de acceso para proteger las apps que usan IAP para autenticar usuarios. En su lugar, protege estas apps con condiciones de IAM.
Apps de línea de negocios que usan SAML: Al igual que con 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 estas puedan usar. Para protegerlas, usa el acceso adaptado al contexto de Google Workspace.
Google Workspace y otros servicios de Google: En el caso de estas apps, es importante proteger el acceso a las apps en sí, así como a los recursos que podrían usar. Para proteger estas apps, usa el acceso adaptado al contexto de Google Workspace.
Administración de niveles de acceso
En las siguientes secciones, se describen las prácticas recomendadas que debes 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 organización Google Cloud . Por lo tanto, lo mejor es limitar la cantidad total 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 requisitos específicos de recursos o de la app 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 ayudar a 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 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 de Trusted location puede servir como dependencia para los demás niveles de acceso.
Exime a los usuarios con 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 apliques el nivel de acceso, configura la exención en el nivel de acceso:
- Agrega una condición que defina tus requisitos habituales.
- Agrega otra condición con un requisito de
membersque incluya uno o más de tus usuarios de acceso de emergencia. - Establece la función de combinación en una condición
ORpara que los usuarios solo deban 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 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, su dispositivo y otros factores pueden influir en si se les permite acceder a ciertas apps. Para mantener a los usuarios informados y ayudar a 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 permisos de Google Cloud alcance. Las vinculaciones de acceso también son una forma eficaz de aplicar el acceso adaptado al contexto para las apps de línea de negocio.
En las siguientes secciones, se describen las prácticas recomendadas que debes usar cuando trabajes con vinculaciones de acceso.
Usa una sola vinculación de acceso con configuración de alcance
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 satisfacer 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 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 con alcance (
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 tanto un parámetro de configuración de acceso con alcance como un nivel de acceso predeterminado, los dos niveles de acceso se combinan con la semántica de 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 un parámetro de configuración de acceso con alcance para una app de OAuth, puedes reducir los requisitos de acceso efectivos.
- Un parámetro de configuración de acceso con alcance 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 selecciones 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 apps de OAuth individuales con la configuración de acceso con alcance.
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 regionales para incluir solo esas regiones en la lista de entidades permitidas. De lo contrario, puedes usar restricciones regionales para limitar el acceso a las ubicaciones geográficas que tienen sanciones o que no son relevantes por otros motivos.
- Restricciones de red de IP: Si los usuarios de tu organización acceden aGoogle Cloud exclusivamente desde ciertas redes o si tu organización usa un proxy de salida común, puedes incluir restricciones de red de 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 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 podría 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 a las que deben acceder socios, invitados o exalumnos.
- Es posible que algunas apps sean técnicamente incompatibles con una de las restricciones que se aplican en el nivel de acceso predeterminado.
Para eximir apps individuales del nivel de acceso predeterminado, usa la configuración de acceso con alcance. Para cada app afectada, agrega un parámetro de configuración con alcance y asigna un nivel de acceso 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, sin querer, crees vinculaciones de acceso superpuestas.
- Puede resultar 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 se asocian 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 sensible al contexto de estas vinculaciones de acceso se combinan con la semántica de 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 no superpongas las vinculaciones de acceso:
- 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 de un grupo lo abandonen. 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 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 adaptado al contexto si abandonan un grupo.
Siempre usa grupos de aplicación de políticas y no permitas que los usuarios salgan de un grupo de aplicación de políticas 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 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 Google Workspace a la que pertenece tu organización de Google Cloud . Estos usuarios aún están sujetos a las vinculaciones de acceso en tu organizaciónGoogle Cloud si intentan acceder a recursos en otras organizacionesGoogle Cloud . 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 Google Workspace accedan a los recursos de tus organizaciones de Google Cloud, tus vinculaciones de acceso no tendrán efecto en esos usuarios.
Para asegurarte de que tus vinculaciones de acceso sean efectivas, no otorgues acceso a usuarios externos a ninguna app o recurso de tu organización de Google Cloud . Además, no agregues usuarios externos a los grupos de tu cuenta de Cloud Identity o Google Workspace.
Usa vinculaciones de acceso independientes para controlar 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, lo mejor es evitar las vinculaciones de acceso superpuestas.
Cuando uses 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 surtirá efecto 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 basados en el contexto.
Existen otros riesgos cuando los usuarios pueden actuar como una cuenta de servicio. Si quieres 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.
Si deseas obtener más información para 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 los 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 los recursos de Google Cloud , no las apps individuales. Por lo tanto, un perímetro de servicio con reglas de entrada es ideal para aplicar el acceso según el contexto para herramientas administrativas, como la Google Cloud consola y 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 según el contexto.
Incluye el redireccionamiento 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 inicie 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 servicio de
iaptunnel.googleapis.comcomo 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 por SSH y RDP.
Usa el acceso basado en certificados para los 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 a robos o ataques de reproducción. 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.
La 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 al certificado debe almacenarse de manera que se impida la exportación no autorizada.
- Las apps cliente deben usar la autenticación de TLS mutua (mTLS) para conectarse a las APIs deGoogle Cloud .
Usa la 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 los requisitos mínimos de infraestructura y el impacto general.
Colaboradores
Autor: Johannes Passing | Arquitecto de soluciones de Cloud
Otro colaborador: Ido Flatow | Arquitecto de Soluciones de Cloud