En este documento se ofrecen recomendaciones para ayudarte a mantener el acceso continuo a los recursos de Google Cloud . La continuidad del negocio tiene como objetivo asegurar que tu organización pueda mantener las operaciones esenciales, incluso durante interrupciones como cortes de suministro o desastres. Este objetivo incluye el acceso continuado de los empleados cuando los servicios y la infraestructura críticos no están disponibles.
Este documento está dirigido a profesionales de seguridad o fiabilidad que se encargan de la gestión de identidades y accesos (IAM) y del mantenimiento de un acceso seguro a Google Cloud. En este documento se presupone que ya conoces Cloud Identity, Google Workspace y la gestión de IAM.
Para ayudarte a prepararte ante posibles interrupciones y garantizar un acceso continuo, en este documento se describen los siguientes pasos recomendados que puedes implementar. Puedes seguir todos o algunos de estos pasos, pero te recomendamos que los implementes en el siguiente orden.
Configurar el acceso de emergencia: habilita el acceso de último recurso a los recursos deGoogle Cloud .
Te recomendamos que configures el acceso de emergencia en todas tus organizaciones, independientemente de los requisitos de continuidad de negocio que tengas.Google Cloud
Ofrece alternativas de autenticación a los usuarios críticos: si tu organización utiliza el inicio de sesión único (SSO), cualquier interrupción que afecte a tu proveedor de identidades (IdP) externo puede influir en la capacidad de los empleados para autenticarse y usarGoogle Cloud.
Para reducir el impacto general de una interrupción del IdP en tu organización, proporciona una alternativa de autenticación para que los usuarios críticos para la empresa puedan seguir accediendo a los recursos. Google Cloud
Usar un IdP de respaldo: para permitir que todos los usuarios accedan a los recursos de Google Cloud durante una interrupción del IdP, puedes mantener un IdP de respaldo.
Un IdP de respaldo puede ayudar a minimizar aún más el impacto de una interrupción, pero es posible que esta opción no sea rentable para todas las organizaciones.
En las siguientes secciones se describen estos pasos recomendados y prácticas recomendadas.
Configurar el acceso de emergencia
El objetivo del acceso de emergencia es permitir el acceso de último recurso a los recursos deGoogle Cloud y evitar situaciones en las que puedas perder el acceso por completo.
Los usuarios con acceso de emergencia se caracterizan por las siguientes propiedades:
- Son usuarios que creas en tu cuenta de Cloud Identity o Google Workspace.
- Tienen el privilegio de superadministrador, que proporciona a los usuarios acceso suficiente para resolver cualquier error de configuración que afecte a tus recursos de Cloud Identity, Google Workspace oGoogle Cloud .
- No están asociadas a un empleado concreto de la organización y están exentas del ciclo de vida Altas, traslados y bajas (ATB) de las cuentas de usuario normales.
- Están exentos del inicio de sesión único.
En las siguientes secciones se describen las prácticas recomendadas que debes seguir al gestionar y proteger a los usuarios con acceso de emergencia.
Crear usuarios con acceso de emergencia para cada entorno
En los Google Cloud entornos que alojan cargas de trabajo de producción, el acceso de emergencia es fundamental. En los entornos que se usan para pruebas o fases de desarrollo, la pérdida de acceso puede seguir siendo perjudicial. Google Cloud
Para asegurarte de que tienes acceso continuo a todos tus Google Cloud entornos, crea y mantén usuarios con acceso de emergencia en Cloud Identity o Google Workspace para cada entorno.
Asegurar la redundancia del acceso de emergencia
Un único usuario con acceso de emergencia es un punto único de fallo. En este caso, si una llave de seguridad no funciona, se pierde una contraseña o se suspende una cuenta, se puede interrumpir el acceso a la cuenta. Para reducir este riesgo, puedes crear más de un usuario de acceso de emergencia para cada cuenta de Cloud Identity o Google Workspace.
Los usuarios con acceso de emergencia tienen muchos privilegios, así que no crees demasiados. En la mayoría de las organizaciones, recomendamos que haya entre dos y cinco usuarios de acceso de emergencia por cada cuenta de Cloud Identity o Google Workspace.
Usar una unidad organizativa independiente para los usuarios con acceso de emergencia
Los usuarios con acceso de emergencia requieren una configuración especial y no están sujetos al ciclo de vida de JML que se sigue con otras cuentas de usuario.
Para mantener a los usuarios con acceso de emergencia separados de las cuentas de usuario normales, utiliza una unidad organizativa específica para ellos. Una unidad organizativa independiente te permite aplicar configuraciones personalizadas solo a los usuarios de emergencia.
Usar llaves de seguridad FIDO para la verificación en dos pasos
Usa llaves de seguridad Fast IDentity Online (FIDO) para la verificación en dos pasos.
Como los usuarios con acceso de emergencia tienen privilegios muy elevados en tu cuenta de Cloud Identity o Google Workspace, debes protegerlos mediante la verificación en dos pasos.
De los métodos de verificación en dos pasos que admiten Cloud Identity y Google Workspace, te recomendamos que uses llaves de seguridad FIDO. Este método ofrece protección contra el phishing y una seguridad sólida. Para asegurarte de que todos tus usuarios de acceso de emergencia usen llaves de seguridad FIDO para la verificación en dos pasos, haz lo siguiente:
- En la unidad organizativa que contiene a tus usuarios de acceso de emergencia, configura la verificación en dos pasos para que solo se puedan autenticar con llaves de seguridad.
- Habilita la verificación en dos pasos para todos los usuarios con acceso de emergencia.
- Registra dos o más llaves de seguridad FIDO para cada usuario de acceso de emergencia.
Si registras varias llaves para cada usuario, reduces el riesgo de que pierdan el acceso si se les rompe una llave de seguridad. También aumentas la probabilidad de que el usuario pueda acceder al menos a una de las llaves en caso de emergencia.
Puedes usar el mismo conjunto de llaves de seguridad para varios usuarios de acceso de emergencia. Sin embargo, es mejor usar llaves de seguridad diferentes para cada usuario de acceso de emergencia.
Usa controles de seguridad física para proteger las credenciales y las llaves de seguridad
Cuando almacenes las credenciales y las llaves de seguridad de los usuarios con acceso de emergencia, debes encontrar el equilibrio entre una protección sólida y la disponibilidad en caso de emergencia:
- Impedir que personal no autorizado pueda acceder a las credenciales de usuario de acceso de emergencia. Los usuarios con acceso de emergencia solo deben usar estas credenciales en caso de emergencia.
- Asegúrate de que el personal autorizado pueda acceder a las credenciales con el mínimo retraso posible en caso de emergencia.
Te recomendamos que no utilices un gestor de contraseñas basado en software. En su lugar, es mejor usar controles de seguridad físicos para proteger las credenciales y las llaves de seguridad de los usuarios con acceso de emergencia.
Cuando elijas los controles de seguridad física que vas a aplicar, ten en cuenta lo siguiente:
- Mejorar la disponibilidad:
- Guarda copias de las contraseñas en varias ubicaciones físicas, como en varias cajas fuertes en diferentes oficinas.
- Registra varias llaves de seguridad para cada usuario de acceso de emergencia y guarda una llave en cada oficina pertinente.
- Mejorar la seguridad: guarda la contraseña y las llaves de seguridad en ubicaciones diferentes.
Evitar la automatización de la rotación de contraseñas
Puede parecer beneficioso automatizar la rotación de contraseñas de los usuarios con acceso de emergencia. Sin embargo, esta automatización puede aumentar el riesgo de que se vea comprometida la seguridad. Los usuarios con acceso de emergencia tienen privilegios de superadministrador. Para cambiar la contraseña de un usuario superadministrador, las herramientas o las secuencias de comandos de automatización también deben tener privilegios de superadministrador. Este requisito puede hacer que las herramientas sean objetivos atractivos para los atacantes.
Para asegurarte de que no se debilite tu postura de seguridad general, no uses la automatización para cambiar las contraseñas.
Usar contraseñas seguras
Para proteger a los usuarios con acceso de emergencia, asegúrate de que utilicen una contraseña larga y segura. Para aplicar un nivel mínimo de complejidad de las contraseñas, utiliza una unidad organizativa específica, como se ha descrito anteriormente, e implementa los requisitos de las contraseñas.
A menos que cambies las contraseñas manualmente, inhabilita la caducidad de las contraseñas de todos los usuarios con acceso de emergencia.
Excluir a un usuario de acceso de emergencia de las políticas de acceso
Durante una emergencia, las políticas de acceso contextual pueden provocar que incluso un usuario con acceso de emergencia no pueda acceder a determinados recursos. Para reducir este riesgo, excluye al menos a un usuario de acceso de emergencia de todos los niveles de acceso de tus políticas de acceso.
Estas excepciones te ayudan a asegurarte de que al menos uno de tus usuarios de acceso de emergencia tenga acceso continuo a los recursos. En caso de emergencia o de que se haya configurado incorrectamente una política de acceso contextual, estos usuarios podrán mantener su acceso.
Configurar alertas para eventos de usuarios con acceso de emergencia
Cualquier actividad de un usuario con acceso de emergencia fuera de un evento de emergencia probablemente indique un comportamiento sospechoso. Para recibir notificaciones sobre los eventos relacionados con la actividad de los usuarios con acceso de emergencia, crea una regla de notificación en la consola de administración de Google. Cuando creas una regla de notificación, puedes definir condiciones como las siguientes:
- Fuente de datos: eventos de registro de usuarios.
Atributos de la pestaña Creador de condiciones: usa atributos y operadores para crear un filtro de la UO que contenga a los usuarios y los eventos con acceso de emergencia.
Por ejemplo, puede definir atributos y operadores para crear un filtro similar a las siguientes instrucciones condicionales:
Actor organizational unit Is /Privileged AND (Event Is Successful login OR Event Is Failed login OR Event Is Account password change)Umbral: cada hora cuando el recuento es > 0
Acción: enviar notificaciones por correo electrónico
Destinatarios de correo: selecciona un grupo que contenga a los miembros pertinentes de tu equipo de seguridad.
Ofrecer alternativas de autenticación a los usuarios críticos
Si tu organización usa el inicio de sesión único (SSO) para que los empleados se autentiquen en los servicios de Google, la disponibilidad de tu proveedor de identidades (IdP) externo se vuelve fundamental. Cualquier interrupción en tu IdP puede impedir que los empleados accedan a herramientas y recursos esenciales.
Aunque el acceso de emergencia te ayuda a garantizar el acceso administrativo continuo, no satisface las necesidades de los empleados durante una interrupción del IdP.
Para reducir el posible efecto de una interrupción del IdP, puedes configurar tu cuenta de Cloud Identity o Google Workspace para que use un método de autenticación alternativo para los usuarios críticos. Puedes usar el siguiente plan de respaldo:
- Durante el funcionamiento normal, permite que los usuarios se autentiquen mediante el SSO.
- Durante una interrupción del IdP, puedes inhabilitar de forma selectiva el SSO para estos usuarios críticos y permitir que se autentiquen con las credenciales de inicio de sesión de Google, que debes proporcionar con antelación.
En las siguientes secciones se describen las prácticas recomendadas cuando permites que los usuarios críticos se autentiquen durante las interrupciones de IdPs externos.
Centrarse en los usuarios con privilegios
Para que los usuarios críticos puedan autenticarse durante una interrupción del proveedor de identidades, deben tener credenciales de inicio de sesión de Google válidas, como las siguientes:
- Una contraseña con una llave de seguridad para la autenticación de dos factores.
- Una llave de acceso.
Si proporcionas credenciales de inicio de sesión con Google a los usuarios que normalmente usan el SSO, es posible que aumentes la carga operativa y las dificultades de los usuarios de las siguientes formas:
- Es posible que no puedas sincronizar las contraseñas de los usuarios automáticamente, en función de tu proveedor de identidades. Por lo tanto, es posible que tengas que pedir a los usuarios que configuren una contraseña manualmente.
- Es posible que tengas que pedir a los usuarios que registren una llave de acceso o que activen la verificación en dos pasos. Normalmente, este paso no es necesario para los usuarios de SSO.
Para equilibrar las ventajas de tener acceso ininterrumpido a los servicios de Google con la sobrecarga adicional, céntrate en los usuarios con privilegios y en los usuarios críticos para la empresa. Es más probable que estos usuarios se beneficien significativamente de un acceso ininterrumpido, y puede que solo representen una pequeña parte de tu base de usuarios.
Aprovecha la oportunidad para habilitar la verificación posterior al SSO
Si proporcionas una autenticación alternativa a los usuarios con privilegios, puede que se produzca un resultado no deseado: una sobrecarga adicional. Para compensar esta sobrecarga, también puedes habilitar la verificación posterior al SSO para estos usuarios.
De forma predeterminada, cuando configuras el SSO para tus usuarios, no es obligatorio que realicen la verificación en dos pasos. Aunque esta práctica es cómoda, si el IdP se ve comprometido, cualquier usuario que no tenga habilitada la verificación posterior al SSO puede convertirse en un objetivo de ataques de falsificación de credenciales.
La verificación posterior al SSO te ayuda a mitigar el posible efecto de una vulneración del proveedor de identidades, ya que los usuarios deben realizar la verificación en dos pasos después de cada intento de SSO. Si proporcionas credenciales de inicio de sesión de Google a usuarios con privilegios, la verificación posterior al SSO puede ayudarte a mejorar la seguridad de estas cuentas de usuario sin que suponga un esfuerzo adicional.
Usar una UO independiente para los usuarios con privilegios
Los usuarios con privilegios que pueden autenticarse durante las interrupciones del proveedor de identidades externo requieren una configuración especial. Esta configuración es diferente de la de los usuarios normales y de los usuarios con acceso de emergencia.
Para ayudarte a mantener a los usuarios con privilegios separados de estas otras cuentas de usuario, utiliza una unidad organizativa específica para los usuarios con privilegios. Esta unidad organizativa independiente te permite aplicar políticas personalizadas, como la verificación posterior al SSO, solo a estos usuarios con privilegios.
Una UO independiente también te ayuda a inhabilitar el SSO de forma selectiva para los usuarios con privilegios durante una interrupción del proveedor de identidades. Para inhabilitar el SSO en la unidad organizativa, puedes modificar las asignaciones de perfil de SSO.
Usar un IdP alternativo
Cuando proporcionas alternativas de autenticación a los usuarios críticos durante las interrupciones del proveedor de identidades, contribuyes a reducir el efecto de esa interrupción en tu organización. Sin embargo, es posible que esta estrategia de mitigación no sea suficiente para mantener la capacidad operativa completa. Es posible que muchos usuarios sigan sin poder acceder a aplicaciones y servicios esenciales.
Para reducir aún más el posible efecto de una interrupción del proveedor de identidades, puedes cambiar a un proveedor de identidades de respaldo. Puedes usar el siguiente plan de copia de seguridad:
- Durante el funcionamiento normal, permites que los usuarios se autentiquen mediante el inicio de sesión único y tu proveedor de identidades principal.
- Durante una interrupción del proveedor de identidades, cambia la configuración del SSO de tu cuenta de Cloud Identity o Google Workspace para cambiar al proveedor de identidades de reserva.
No es necesario que el IdP de backup sea del mismo proveedor. Cuando crees un IdP de reserva, usa una configuración que coincida con la de tu IdP principal. Para asegurarte de que el IdP de respaldo permite que todos tus usuarios se autentiquen y accedan a los servicios de Google, debe usar una copia actualizada de la base de usuarios del IdP principal.
Un IdP de respaldo puede ayudar a proporcionar un acceso de contingencia completo. Sin embargo, debes sopesar estas ventajas con los riesgos adicionales que podría suponer un IdP de respaldo. Estos son algunos de los posibles riesgos:
- Si el proveedor de identidades de reserva tiene una seguridad más débil que el proveedor de identidades principal, la postura de seguridad general de tu entorno Google Cloud también podría ser más débil durante una conmutación por error.
- Si el proveedor de identidades principal y el de respaldo difieren en cómo emiten aserciones SAML, el proveedor de identidades podría exponer a los usuarios a ataques de suplantación de identidad.
En las siguientes secciones se describen las prácticas recomendadas cuando se usa un IdP de respaldo para el acceso de contingencia.
Crear un perfil SAML independiente para el proveedor de identidades de respaldo
Cloud Identity y Google Workspace te permiten crear varios perfiles SAML. Cada perfil de SAML puede hacer referencia a un proveedor de identidades SAML diferente.
Para minimizar el trabajo necesario para cambiar al proveedor de identidades de respaldo, prepara un perfil SAML para el proveedor de identidades de respaldo con antelación:
- Crea perfiles SAML independientes para tu proveedor de identidades principal y para tu proveedor de identidades de respaldo.
- Configura las asignaciones de perfil de SSO para asignar solo el perfil de SAML del proveedor de identidades principal durante las operaciones normales.
- Modifica las asignaciones de perfiles de SSO para usar el perfil SAML del proveedor de identidades de respaldo durante una interrupción del proveedor de identidades. No cambies la configuración de los perfiles de SAML.
Usar un IdP local
No es necesario aprovisionar un IdP adicional para que actúe como copia de seguridad. En su lugar, comprueba si puedes usar un IdP local para este fin. Por ejemplo, tu organización puede usar Active Directory como fuente autorizada de identidades y también puede usar Servicios de federación de Active Directory (AD FS) para el SSO. En este caso, puede usar AD FS como proveedor de identidades de reserva.
Este enfoque de reutilización puede ayudarte a limitar los costes y la sobrecarga de mantenimiento.
Prepara el IdP de respaldo para que gestione la carga necesaria
Cuando cambies la autenticación al IdP de copia de seguridad, este deberá gestionar todas las solicitudes de autenticación que normalmente gestiona tu IdP principal.
Cuando implementes y dimensionas un IdP de respaldo, recuerda que el número de solicitudes previstas depende de los siguientes factores:
- El número de usuarios de tu cuenta de Cloud Identity o Google Workspace.
- La Google Cloud duración de la sesión configurada.
Por ejemplo, si la duración de la sesión es de entre 8 y 24 horas, las solicitudes de autenticación pueden aumentar durante las horas de la mañana, cuando los empleados empiezan su jornada laboral.
Prueba el procedimiento de conmutación por error periódicamente
Para asegurarte de que el proceso de conmutación por error del SSO funciona de forma fiable, debes verificarlo periódicamente. Cuando pruebes el procedimiento de conmutación por error, haz lo siguiente:
- Modifica manualmente la asignación de perfil de SSO de una o varias unidades organizativas o grupos para usar el proveedor de identidades de respaldo.
- Verifica que el SSO con el IdP de copia de seguridad funciona correctamente.
- Verifica que los certificados de firma estén actualizados.
Siguientes pasos
- Consulta las prácticas recomendadas de seguridad para proteger cuentas de administrador.
- Más información sobre las prácticas recomendadas para federar Google Cloud con un proveedor de identidades externo
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.
Colaboradores
Autor: Johannes Passing | Arquitecto de soluciones en la nube
Otro colaborador: Ido Flatow | Arquitecto de soluciones en la nube