Es fácil ver por qué las empresas están gravitando hacia un modelo híbrido de gestión de identidades que promete lo mejor de ambos mundos: un poco en la nube y un poco en las instalaciones. En un entorno centrado en Active Directory, aprovechar la nube significa integrarse con Azure Active Directory.
Azure Active Directory (AAD), después de todo, está diseñado con la vista puesta en las aplicaciones SaaS, proporcionando un inicio de sesión único y control de acceso. A medida que aumenta la adopción de la nube, la capacidad de gestionar tanto el acceso local como el acceso a la nube se está convirtiendo en una necesidad empresarial. necesidad empresarial. La integración de AAD con Active Directory (AD) ayuda a hacer realidad la gestión de identidades híbridas.
Sin embargo, como ocurre con todo lo relacionado con las TI, sigue siendo válido el adagio de "mirar antes de saltar".
Lecturas relacionadas
Monumental cambio con el paso a la nube
Trasladar cualquier parte de una operación de TI a la nube requiere un ajuste. La autenticación de usuarios no es diferente. Desde un punto de vista conceptual, las organizaciones deben tener en cuenta tres cuestiones fundamentales.
1. Un nuevo modelo de autenticación
Después de 20 años gestionando la identidad de una sola manera, añadir la AAD a la mezcla será un ajuste crítico. Pasar de utilizar únicamente AD local a ampliar la autenticación a la nube requiere una mentalidad y un enfoque diferentes. En AAD, no hay unidades organizativas ni bosques, ni objetos de políticas de grupo. Los conceptos (y las cicatrices de batalla) sobre cómo proteger las identidades en AD ya no se aplican en AAD.
Muchos administradores empiezan creyendo que asegurar AAD es similar a asegurar AD, lo cual no es el caso. An usted puede que ya esté utilizando AAD sin pensar mucho en ello. Si su organización está utilizando cualquier ccomo Office 365, entonces AAD ya se está utilizando en segundo plano. AAD también se utiliza mucho para conectarse a otras aplicaciones SaaS que no son de Microsoft, como Salesforce. Todos estos factores introducen nuevas consideraciones y opciones. Por ejemplo, ¿debe mantener AD y AAD separados o fusionarlos mediante Azure AD Connect? Es necesario comprender muchos conceptos nuevos para poder tomar estas decisiones manteniendo la seguridad de los sistemas de información.
2. La extensión del perímetro
Una vez que una organización adopta la nube, la noción de perímetro de red tradicional deja de existir. Para los administradores de TI que han pasado las dos últimas décadas ejecutando AD en las instalaciones, esta noción supone un tremendo ajuste. En un entorno de identidad híbrida, las organizaciones ahora deben estar preparadas para protegerse de un sinfín de posibles puntos de entrada.
3. Cambios radicales en el modelo de permisos
El paso a AAD también cambia drásticamente el modelo de permisos que las organizaciones necesitan asegurar. En las instalaciones, es bastante fácil controlar quién tiene acceso físico a los controladores de dominio, y los puntos de entrada de gestión general están bien definidos y documentados. En un entorno AD híbrido, las identidades también se almacenan ahora en la nube, vulnerables a la explotación por cualquiera que tenga acceso a Internet. De repente, los administradores se enfrentan a un modelo inherentemente abierto para las conexiones de acceso iniciales, que-cuando se une al mayor número de servicios, funciones y permisos necesarios-tiene un impacto significativo en el riesgo.
Microsoft ha tratado activamente de proporcionar materiales educativos para preparar a las empresas para los cambios provocados por la adopción de AAD. Sin embargo, muchas organizaciones de TI siguen sin apreciar plenamente las implicaciones de la gestión de identidades híbridas. A medida que más empresas adoptan un enfoque híbrido, los atacantes han ampliado su modus operandi en consecuencia.
En septiembre 2020los investigadores de Mandiant (FireEye) señalaron que habían observado un aumento de incidentes relacionados con Microsoft 365 y Azure Active Directory, en su mayoría vinculados a correos electrónicos de phishing que intentaban atraer a las víctimas para que introdujeran sus credenciales de Office 365 en un sitio de phishing. Los investigadores de Mandiant también observaron que los atacantes utilizaban un módulo de PowerShell llamado AADInternalsque permite a los atacantes pasar del entorno local a AAD, crear puertas traseras, robar contraseñas y realizar otras acciones maliciosas. Estas amenazas seguirán aumentando con el crecimiento exponencial del interés por Azure y Office 365.
Permisos, permisos, permisos
Con diferencia, de los tres temas mencionados anteriormente, el mayor riesgo para la seguridad lo provocan los cambios en el modelo de permisos. Hay un gran número de servicios que están disponibles cuando las organizaciones pasan a un entorno de identidad híbrida. En lugar de un conjunto bien definido de grupos administrativos en Active Directory, ahora tienes roles en Azure AD, que te resultarán desconocidos. Puede ver esta lista de roles aquí. Cada rol tiene una larga lista de permisos asignados. Es difícil entender los permisos asignados a cada rol sólo por la descripción, pero muchos tienen un alto nivel de acceso que no es evidente.
Además, la vinculación de cualquier servicio SaaS a AAD, que es probablemente la razón por la que ha añadido AAD a la mezcla, añade modelos de permisos que necesitan ser gestionados. Microsoft Teams, por ejemplo, utiliza la integración de SharePoint en el back de SharePoint. Con las configuraciones incorrectas, añadir un invitado a Teams muede crear una situación en la que este nuevo usuario tenga acceso a los archivos almacenados en SharePoint para Teams.. Folks pueden no ser conscientes que estos archivos son ahora disponibles para los usuarios invitados que se añadieron a su canal sólo para una charla rápida. Además, la posibilidad de añadir Apps en Teams amplía efectivamente el modelo de permisos a estas herramientas de terceros. Este es sólo un ejemplo de la matriz de cuestiones complejas para cada servicio gestionado a través de AAD.
De hecho, realizar un seguimiento de los permisos de las aplicaciones de terceros es fundamental y es un área que no se gestiona adecuadamente en la mayoría de las implementaciones de AAD. Estas solicitudes de permisos activarán una ventana emergente única que enumera los permisos que necesita la aplicación. Estas listas pueden ser largas y deberían revisarse cuidadosamente antes de aceptarlas, pero rara vez se hace.
Las organizaciones también mueden enfrentarse a estos dos nuevos escenarios relacionados con los permisos que deben entenderse en un contexto de seguridad:
- Herramientas de terceros que extraen datos de Azure AD y los almacenan en su propia base de datos. Por ejemplo, una aplicación registrada en Azure AD que permite a un sistema CRM leer perfiles de usuario o tiene otros permisos de lectura efectivamente tiene la capacidad de recuperar y almacenar datos para sí misma. Una vez que los datos se extraen de Azure AD, se almacenan en una base de datos externa, dejando que la organización dependa del marco de seguridad de la herramienta de terceros.
- Herramientas de terceros con acceso de escritura que pueden realizar cambios dentro de su herramienta. En este caso, la autenticación necesaria para realizar cambios en el inquilino se traslada de Azure AD a los controles que tenga la herramienta de terceros. Un usuario muede ser capaz de iniciar sesión en la herramienta sin autenticación multifactor porque no admite el inicio de sesión único (SSO), operando en su lugar con la aplicación actuando como proxy de permisos que realiza la acción en su nombre sin algunas de las comprobaciones que normalmente se requerirían.
Las organizaciones de TI deberían considerar seriamente restringir quién puede aprobar aplicaciones o, como mínimo, tenere una orientación clara sobre qué permisos deben considerarse apropiados. Adoptar un enfoque de identidad híbrida requiere tratar con un modelo de permisos mucho más amplio. Para hacerlo de forma eficaz, las organizaciones deben establecer una sólida gobernanza sobre qué aplicaciones se van a activar y qué derechos de acceso van a obtener.
Comprender el riesgo de la gestión de identidades híbridas
Independientemente de que la autenticación se gestione en la nube, en las instalaciones o en ambos entornos, la seguridad siempre es lo primero. Aunque gestionar la identidad en un entorno híbrido puede parecer tan sencillo como unir un dispositivo Windows a AAD, no tener en cuenta los cambios en el panorama de riesgos abre la puerta a problemas que pueden causar dolores de cabeza en el futuro. cambios en el panorama de riesgos abre la puerta a problemas que pueden causar dolores de cabeza en el futuro. El conocimiento es siempre su primera línea de defensa, pero la cantidad de documentación necesaria para comprender plenamente la seguridad en AAD es desalentadora. Las herramientas nativas o de terceros que automatizan esa comprensión y reducen la complejidad de la seguridad ayudarán a reducir el riesgo de seguridad durante y después del despliegue de su entorno híbrido.
