Federación, sincronización y cuentas de invitado
Muchas empresas han implementado servicios de directorio locales como Active Directory dentro de su organización para almacenar información relacionada con los usuarios y otras entidades. En algunos casos, estos servicios han existido durante décadas y la información almacenada en ellos es voluminosa y fundamental para el funcionamiento de la organización.
Cuando organizaciones como estas migran a la nube, uno de los desafíos a los que se enfrentan es cómo controlar el acceso a los recursos de nube con las mismas identidades de usuario, grupo y aplicación que usan para controlar el acceso a los recursos locales. Podrían usar identidades independientes (y credenciales independientes) para los recursos locales y los recursos de nube, pero esto no es lo ideal. Si un usuario deja la organización, debe quitarse del directorio de nube y del directorio local. Además, exige que los usuarios se las apañen con varias cuentas, lo que es un inconveniente y una amenaza para la seguridad.
Existen tecnologías para extender los servicios de directorio locales a la nube, lo que simplifica la administración de los recursos de nube y evita que los usuarios tengan que iniciar sesión con un conjunto de credenciales para acceder a un recurso local y otro conjunto de credenciales para acceder a un recurso de nube. Una de estas técnicas es la federación; otra es la sincronización. Un desafío independiente aunque relacionado es cómo permitir a los usuarios externos (por ejemplo, contratistas que no forman parte de la organización pero que trabajan en su nombre) acceder a los recursos de nube de la organización sin emitirles credenciales para su sistema. Una solución elegante y que se usa con frecuencia son las cuentas de invitado. Vamos a analizar la federación, la sincronización y las cuentas de invitado y a comprender lo que son y el papel que desempeñan en la administración de la nube.
Federación
La federación es anterior a la nube. Su finalidad es crear una relación de confianza entre las organizaciones, de modo que la organización A pueda acceder a los recursos de red de la organización B sin necesidad de que la organización B emita credenciales a los miembros de la organización A. La federación se basa en estándares como WS-Fed, que definen los protocolos que se usan para negociar la información de identidad entre sistemas. Servicios de federación como los Servicios de federación de Active Directory (ADFS) de Microsoft implementan protocolos de WS-Fed y unen sistemas de identidad de modo que las identidades de la organización A puedan usarse como identidades federadas en la organización B. Otra manera de pensar en la federación es que permite a los usuarios externos acceder a recursos internos. Es decir, extiende las identidades de una organización más allá de los límites de esta.
Imagine que dos empresas denominadas Contoso y Fabrikam establecen una alianza comercial. Contoso quiere que los empleados de Fabrikam tengan acceso a determinados recursos compartidos de archivos de la red de Contoso y viceversa. Las dos empresas federan sus sistemas de identidad, lo que permite a los empleados de Fabrikam acceder a los recursos de Contoso con las mismas credenciales que usan para acceder a los recursos de Fabrikam. Cuando los administradores de TI que trabajan para Contoso agregan usuarios a la lista de usuarios que pueden acceder a los recursos compartidos de archivos, ven a los empleados de Contoso y a los empleados de Fabrikam, aunque Contoso nunca haya creado cuentas para los empleados de Fabrikam. Eso es la federación en pocas palabras.
La federación no se limita a conectar las redes locales de diferentes organizaciones; también se puede usar para extender las identidades locales a la nube. Azure, AWS y GCP ofrecen soluciones de administración de identidades que permiten a servicios de directorio locales como Active Directory proporcionar también información de identidad a los servicios en la nube. Si un usuario intenta acceder a un recurso de red protegido, la solicitud se redirige a la solución de directorio local, que autentica al usuario como si estuviera accediendo a un recurso local (figura 3.4). Esto proporciona administración centralizada de usuarios, credenciales y permisos. También evita que los usuarios tengan que usar una cuenta independiente para acceder a los recursos de nube de su organización.
Figura 3.4: Flujo de identidad federada.
Las organizaciones usan mucho la federación para proteger el acceso a los recursos de nube con la misma información de identidad que protege el acceso a los recursos locales. Pero esto no es perfecto. Requiere una conexión confiable entre el servicio de directorio local y la nube para que se pueda consultar al directorio local cada vez que un usuario accede a un recurso de nube que exige autenticación. Una solución para eso (otro medio para compartir credenciales entre directorios locales y la nube) es la sincronización.
Sincronización
La sincronización es una alternativa a la federación. Con la sincronización, la información del directorio local se sincroniza periódicamente con un directorio en la nube. La diferencia principal entre la federación y la sincronización es que, con la primera, la autenticación se produce en local, mientras que con la sincronización, la autenticación se produce en la nube.
La sincronización se implementa mediante la instalación de un servicio de sincronización en los sistemas locales de la organización (figura 3.5). El servicio sincroniza periódicamente la información de usuario entre el directorio local y el directorio en la nube. Toda la autenticación se realiza en el directorio en la nube, que contiene la misma información que el directorio local.
Figura 3.5: Flujo de identidad sincronizada.
Una diferencia operativa fundamental entre la federación y la sincronización es que la última es más resistente a las interrupciones de conectividad. La sincronización no requiere acceso al directorio local cada vez que un usuario accede a un recurso de nube. Solo requiere acceso cuando se produce la sincronización. La principal desventaja de la sincronización es que los cambios realizados en el directorio local tardan tiempo en propagarse a la nube. Si un administrador agrega a Alice al directorio local, pero la sincronización se produce solo una vez a la hora, Alice no puede acceder a los recursos de nube protegidos hasta una hora después de la realización del cambio.
Hay herramientas como Microsoft Entra Connect disponibles para sincronizar directorios. AADC sincroniza la información almacenada de forma local en Active Directory con la información almacenada en la nube en Microsoft Entra ID. Amazon proporciona una oferta similar con AD Connector, como hace Google con Google Cloud Directory Sync (GCDS).
Las soluciones de sincronización se suelen preferir sobre los enfoques basados en la federación. Normalmente, incurren en menos sobrecarga de administración y no requieren una conexión siempre disponible entre servicios de directorio. El Centro Nacional de Ciberseguridad del Reino Unido se hace eco de esta recomendación1.
Cuentas de invitado
Otro desafío para TI es cómo controlar a los usuarios externos de la organización. Estos usuarios suelen incluir contratistas, consultores y becarios, usuarios que no son parte formal de la organización pero que necesitan acceso a los recursos internos como si lo fueran.
Una solución consiste en crear cuentas internas para los usuarios externos. Estas cuentas suelen usar un prefijo o sufijo en los nombres de cuenta para indicar su naturaleza externa. En Microsoft, por ejemplo, la mayoría de las cuentas externas tienen nombres como v-jeffpro, donde "v" quiere decir "vendor" (proveedor). Pero este enfoque está lejos de ser perfecto. ya que agrava la proliferación de cuentas. ("Aquí hay otro nombre de usuario que seguir y otra contraseña que debe cambiarse cada 60 días y ajustarse a una directiva exclusiva de esta organización"). También aumenta la carga de trabajo de los administradores al aumentar el número de cuentas de las que son responsables y al obligarles a establecer un mecanismo o proceso para propagar los cambios en el estado de los usuarios externos dentro de sus propias organizaciones a sistemas internos de administración de identidades. Por ejemplo, si un consultor con credenciales "externas" se retira o acepta un trabajo en otro lugar, es necesario revocar sus credenciales para que ya no se puedan usar para acceder a los sistemas.
Una solución mejor es usar cuentas de invitado. Las cuentas de invitado son un caso especial de cuentas federadas. Los usuarios externos son "invitados" a unirse al sistema de administración de identidades de una organización mediante las credenciales de su propia organización. Se crea un nuevo registro de usuario, pero cuando el usuario invitado se autentica, lo hace en su organización de origen. Esto elimina la necesidad de que el usuario administre otro conjunto de credenciales. También elimina la necesidad de que TI sea consciente del cambio de estado del usuario en su organización de origen. Una vez que el personal de TI de origen lo quita del sistema, ya no puede autenticarse en ninguno de los sistemas.
Referencias
- National Cyber Security Centre (2019). Securing Office 365 with better configuration (Protección de Office 365 con una mejor configuración). https://www.ncsc.gov.uk/blog-post/securing-office-365-with-better-configuration