El futuro de los servicios de directorio es sin dominio

Los enfoques fundamentales de la seguridad, la gestión de dispositivos y el control de acceso están cambiando.

Durante la mayor parte de los 30 años, estas prioridades centrales de TI han sido inseparables de Active Directory y OpenLDAP, que fueron soluciones excelentes en la era del dominio local. Pero el cambio reciente al trabajo remoto deja en claro que la seguridad perimetral tradicional y la infraestructura local ya no son suficientes para proteger las identidades de los usuarios y los datos confidenciales de una organización en la nube.

Para administrar mejor los entornos de trabajo modernos, necesitamos volver a imaginar las funciones individuales de un servicio de directorio y separar esas funciones del concepto anticuado del dominio cableado, de castillo y foso. Lo que más importa hoy en día es proteger al usuario y al dispositivo sin importar en qué parte del mundo se encuentren.

El futuro de los servicios de directorio, entonces, es sin dominio. Aquí hay una mirada más detallada de cómo llegamos aquí, cómo se ve la empresa sin dominio en la práctica y los pasos que las organizaciones pueden tomar para modernizar su infraestructura de IAM.

Reimaginar los servicios de directorio y el concepto de dominio

El concepto de dominio, tal como lo conocemos, se diseñó esencialmente en la década de 1990 y era una solución excelente para el gobierno seguro de usuarios y computadoras en los entornos de oficina cableados de la época. Si bien la mayoría de las otras áreas de TI se han transformado por completo desde entonces, este modelo aún sustenta los enfoques de la mayoría de las organizaciones para la administración de identidades y accesos en la actualidad.

Muchos profesionales de TI dan por sentado el dominio y han asumido que el siguiente paso lógico es adaptarlo y ampliarlo para la era de la nube agregando proveedores de inicio de sesión único (SSO) de aplicaciones web y otros puentes de identidad. Pero un enfoque más práctico podría ser mirar hacia atrás a los problemas centrales que el dominio fue diseñado inicialmente para resolver, decidir cuáles de esos problemas siguen siendo relevantes hoy en día y explorar nuevas formas de resolverlos utilizando innovaciones modernas.

Desde mediados de la década de 1990 hasta mediados de la década de 2000, los entornos de oficina eran muy diferentes. Los trabajadores ingresaron a los establecimientos físicos utilizando tarjetas de acceso o llaves reales. Caminaron hacia sus escritorios y se sentaron frente a computadoras estacionarias. Esas computadoras estaban conectadas a través de un cable de ethernet a algún centro de datos interno o armario de servidores dentro de la oficina física. Desde dentro de esa ubicación central, el controlador de dominio otorgó acceso a los recursos de TI dentro de la red local. Esa red física, a su vez, estaba protegida de ataques externos por un firewall y por el propio edificio para el acceso físico.

En ese momento, esta configuración era esencialmente segura y sencilla de administrar, y ofrecía una experiencia de usuario tan fluida que los usuarios no tenían que administrar varias contraseñas ni pensar en los procesos de autorización y autenticación que se realizaban tras bambalinas. Los entornos eran homogéneos, con una torre de escritorio que ejecutaba programas de Windows y Microsoft en cada estación de trabajo. Active Directory (AD) se adaptaba tan bien a este tipo de entorno que pudo brindarles a los usuarios lo que quizás fue la primera experiencia de inicio de sesión único (SSO): un conjunto único de credenciales para acceder a sus recursos de TI basados ​​en Windows a través de un único inicio de sesión del sistema.

Ahora, avance rápidamente al presente y derribe todas las paredes de ese edificio. TI tendía hacia la flexibilidad fuera de la oficina habilitada por la tecnología en la nube y el Internet inalámbrico de alta velocidad ampliamente disponible. En lugar de computadoras fijas con torres y monitores de tubo, los empleados ahora tienen computadoras portátiles y otros dispositivos que pueden llevar consigo casi a cualquier lugar, conectarse a Internet y comenzar a trabajar. Esa es la empresa sin dominio en pocas palabras, y esa es nuestra realidad actual.

Pero en un mundo donde tanto trabajo ocurre fuera del dominio, los departamentos de TI se ven obligados a reevaluar los desafíos que Active Directory manejó una vez por sí solo.

Deficiencias modernas del modelo de dominio

Active Directory ha tenido problemas para adaptarse e integrarse con los recursos de la nube modernos y los sistemas operativos que no son de Windows, y el modelo de seguridad perimetral para el que fue diseñado no es suficiente para proteger a los trabajadores remotos.

Entonces, la pregunta es cómo traducir el flujo de trabajo administrativo centralizado y la experiencia de usuario simple y segura que alguna vez brindó AD a un entorno moderno que incluye sistemas Mac y Linux, aplicaciones web, servidores en la nube y redes remotas, y que puede tener o no todavía. -infraestructura prem también. Los usuarios deben conectarse a sus recursos de TI con una fricción mínima, independientemente de dónde estén trabajando, y los administradores de TI deben estar seguros de que las identidades de los usuarios y los datos de propiedad están protegidos contra ataques.

El problema es que TI no tiene casi el nivel de control sobre las identidades de los usuarios modernos que habría tenido en un entorno de dominio de AD convencional. Las aplicaciones han migrado de una arquitectura heredada de compra única e instalación local a un modelo de suscripción basado en la nube. Algunas aplicaciones todavía se instalan localmente, con identidades y configuraciones manejadas en la nube a través de un navegador web.

Al tener que administrar sus propias identidades, los usuarios terminan con decenas, si no cientos, de contraseñas y enfrentan la tentación de ignorar las pautas de seguridad y compartir o reutilizar contraseñas débiles.

Los usuarios también pueden tener la tentación de crear sus propias cuentas para nuevas aplicaciones según lo crean conveniente, sin la aprobación o regulación de TI. Esta TI en la sombra plantea un riesgo de seguridad innecesario para la organización. E incluso las identidades que son administradas por TI pueden existir en sus propios silos, con cada identidad separada que requiere su propio proceso manual de aprovisionamiento y desaprovisionamiento.

No existe una identidad única y central análoga a la identidad AD de antaño. Los administradores necesitan una nueva forma de asegurar las conexiones, mantener todo seguro bajo el control de TI, cumplir con las líneas de base de seguridad y cumplimiento y preparar los dispositivos para el trabajo remoto.

Cuando se trata de sistemas, los sistemas MacBook y Linux ahora son comunes. Donde los administradores experimentados de Microsoft alguna vez se resistieron a la introducción de los sistemas Mac en el lugar de trabajo, ahora es una práctica estándar adaptar esos sistemas. En un dominio tradicional de Active Directory, la administración del sistema Mac y Linux no sería tan fluida ni segura sin la adición de otras soluciones puntuales más allá de AD, como una herramienta de administración del sistema o incluso un MDM.

Los entornos de dominio creados en torno a OpenLDAP no funcionan mucho mejor: los dominios y servidores LDAP administran principalmente identidades, contraseñas, grupos y unidades organizativas, pero a menudo carecen de administración de sistemas, aplicación de políticas de seguridad y capacidades de integración de aplicaciones en la nube. Los recursos de TI han pasado de usar LDAP como el protocolo de autenticación elegido a aprovechar estándares modernos como SAML, SCIM, OAuth, OIDC y más. Los entornos LDAP heredados también requieren un alto grado de experiencia para configurarlos y mantenerlos.

La forma lógica de llenar los vacíos anteriores en la supervisión de TI es implementar una arquitectura moderna sin dominio.

¿Qué significa realmente sin dominio en la práctica?

La perspectiva de quedarse sin dominio puede sonar un poco aterradora para los administradores experimentados, pero un entorno sin dominio correctamente configurado puede ser considerablemente más seguro que una configuración de dominio tradicional en el panorama de TI actual. En un entorno sin dominio, la postura de seguridad de la organización envuelve a cada usuario individual, su sistema Mac, Windows o Linux y los recursos a los que necesitan acceder, donde sea que se encuentre cada uno de esos componentes.

Cada recurso de TI ahora tiene su propio perímetro ajustado. Esto significa que, en lugar de funcionar esencialmente sin seguridad dentro de los límites de un perímetro más grande reforzado después de autenticarse una vez, las identidades y los derechos de acceso se verifican y verifican constantemente. Los usuarios acceden a sus recursos directamente a través de una conexión a Internet estándar, en lugar de enrutar a través de un dominio para la autenticación. Y en lugar de un controlador de dominio, un servicio de directorio en la nube maneja la administración de acceso, la autenticación de usuarios y la aplicación de la seguridad.

Es este concepto de un servicio de directorio en la nube lo que hace que la empresa sin dominio sea factible en la práctica. Pero incluso cuando tantos otros aspectos de TI han migrado efectivamente a la nube, muchos administradores tienen reservas sobre la implementación de un espectro completo de servicios de directorio en la nube.

En su mayor parte, eso se debe a que la idea de un servicio de directorio en sí está tan indisolublemente ligada a Active Directory: la herramienta existente representa los problemas individuales que alguna vez resolvió. Y el aspecto de seguridad del dominio es más intuitivo: los cortafuegos y las cerraduras de las puertas son familiares y nos dan una sensación de control. Parece lógico que renunciar al dominio signifique una mayor exposición a los ataques y una disminución del control sobre la seguridad.

Pero la verdad es que incluso con medidas como firewalls, detección de red y detección y respuesta de punto final, las organizaciones aún sufren violaciones. Después de que cada nuevo ataque exitoso llegue al ciclo de noticias, la comunidad de TI se vuelve a enfocar en cómo aplicar una versión mejor y más fuerte del mismo enfoque de seguridad. Claramente, la vieja forma de hacer las cosas no está funcionando. Ha llegado el momento de un enfoque fundamentalmente nuevo centrado en la nube.

Funciones principales de un servicio de directorio en la nube

La frase servicio de directorio en la nube se usa para describir una variedad de soluciones que encajan libremente en la categoría de IAM, pero es difícil precisar qué significa realmente esta frase de un proveedor a otro.

Las diferentes soluciones de directorio en la nube rara vez ofrecen una funcionalidad comparable, y casi ninguna de ellas replica la gama completa de capacidades de control de acceso, autenticación y gobernanza del sistema original de AD como proveedor de identidad central de una organización. Pero eso es exactamente lo que debe hacer un servicio de directorio en la nube para admitir y proteger una arquitectura moderna sin dominio.

De hecho, un servicio de directorio en la nube que valga la pena debería ir más allá del alcance original de AD al administrar el acceso a aplicaciones de terceros y sistemas operativos distintos de Windows, todo desde una plataforma.

Esta distinción es importante al comparar un verdadero servicio de directorio en la nube con una plataforma SSO de aplicación web, que brinda a los usuarios una identidad para acceder a sus aplicaciones SaaS, pero es posible que no pueda administrar el acceso al dispositivo, las líneas de base de seguridad o autenticar a los usuarios en sistemas heredados o locales. recursos utilizando sus protocolos de autenticación preferidos. En este sentido, el SSO basado en SAML es solo un componente de un servicio de directorio en la nube; los términos no son intercambiables.

En lugar de crear una traducción uno a uno del modelo de dominio de AD establecido en la nube, un servicio de directorio en la nube adecuado divide las funciones de AD en sus componentes y vuelve a imaginar cada una de esas partes. Si podemos separar los problemas individuales de la solución que damos por sentado, podemos llegar a nuevas formas de resolverlos.

Las siguientes funciones principales son esenciales para un servicio de directorio en la nube creado para la empresa sin dominio:

• Una identidad de usuario única y segura para acceder a dispositivos, aplicaciones, Wi-Fi/VPN, servidores e infraestructura de desarrollo, tanto en las instalaciones como en la nube, independientemente del proveedor.
• Capacidad para integrar y consolidar las identidades de los usuarios de otros servicios, incluidos G Suite, Office 365, AWS, AD/Azure y HR/sistemas de nómina
• Capacidad automatizada de aprovisionamiento y desaprovisionamiento de usuarios
• Administración remota del sistema con control de políticas similar a GPO sobre sistemas Mac, Windows y Linux e informes detallados sobre el estado y los atributos del sistema
• Autenticación multifactor (MFA) en el inicio de sesión del sistema Mac, Windows y Linux y para acceder a prácticamente todos los demás recursos de TI, además de la capacidad de administración de claves SSH
• Administración flexible y automatizada a través de secuencias de comandos, API o PowerShell
• Registro detallado de datos y eventos para respaldar las necesidades de auditoría y cumplimiento

Muchas fallas de seguridad se remontan no a la ausencia total de cualquiera de los componentes anteriores, sino a la incapacidad de aplicarlos, hacerlos cumplir y actualizarlos de manera uniforme en toda la organización. Con eso en mente, el valor de un servicio de directorio en la nube centralizado queda claro.

Las claves para quedarse sin dominio: confianza en el dispositivo y MFA

Aunque muchas soluciones de IAM en la nube se basan completamente en el navegador, les falta la clave de la seguridad moderna sin dominio: el dispositivo. Los usuarios aún necesitan una puerta de enlace física para su trabajo, ya sea una computadora portátil, una tableta o un teléfono inteligente. Una gran parte de la verificación constante requerida para proteger un entorno sin dominio debe ser manejada por el dispositivo, utilizando un marco que podemos considerar como confianza en el dispositivo .

La idea es que el usuario inicie sesión en el dispositivo una vez, usando una combinación de contraseña o credenciales sin contraseña más MFA, y luego obtenga acceso seguro a todos sus recursos de TI. Cada transacción está protegida y cifrada a nivel atómico, por lo que el trabajo se puede realizar de forma segura a través de una conexión a Internet estándar.

La experiencia del usuario es similar a la experiencia SSO de iniciar sesión en una máquina de escritorio en el dominio AD de finales de la década de 1990 y principios de la década de 2000, pero lo que sucede detrás de escena es mucho más complejo y la amplitud de los recursos de TI disponibles para acceder es mucho mayor.

Para que un servicio de directorio en la nube establezca una relación de confianza con un dispositivo, se deben cumplir y reafirmar constantemente varios criterios. Esos criterios se simplifican a verificar que:

• El usuario correcto está accediendo al dispositivo y ese usuario es quien dice ser
• El dispositivo correcto está solicitando acceso
• Se solicita acceso desde la ubicación correcta
• Se aplican los permisos correctos para el usuario/dispositivo dentro de un recurso dado

Aquí es donde el concepto de MFA se expande más allá de las medidas orientadas al usuario, como los tokens TOTP y las claves de seguridad WebAuthn. Los requisitos anteriores se pueden confirmar entre el dispositivo y el servicio de directorio en la nube, estableciendo un tercer, cuarto, quinto y más factores de autenticación que serían prácticamente imposibles de replicar juntos para un atacante.

La idea de violar una red cambia radicalmente por esta autenticación multifactor repetida: ya no hay un área no segura para atravesar durante una sesión abierta después de una sola autenticación inicial. Esto se debe a que, en el modelo sin dominio, la seguridad y el control de acceso ocurren efectivamente en cada nivel en lugar de solo en el nivel de la red. Solo la persona adecuada, con la máquina adecuada, accediendo desde la ubicación correcta con los permisos adecuados puede acceder a los datos y las aplicaciones.

Un servicio de directorio en la nube establece la confianza del dispositivo a través de una combinación de gobierno del sistema similar a GPO, software creado según el principio de privilegio mínimo y cifrado de todos los datos en tránsito y en reposo. Otra forma de pensar en este enfoque es dentro del contexto de la seguridad de confianza cero .

Seguridad de confianza cero en la práctica

La seguridad de confianza cero significa que el servicio de directorio encargado de la autenticación nunca da por sentada la legitimidad de un usuario, dispositivo, aplicación u otro recurso de TI. Se logra asegurando las siguientes cuatro áreas: empleados, sistemas, aplicaciones y red.

Empleados

Existe un sistema para verificar que realmente son quienes dicen ser al confirmar su contraseña (algo que saben) y su token MFA (algo que tienen) contra la base de datos del directorio, que sirve como fuente autorizada de la verdad.

Sistemas

El sistema, probablemente una máquina emitida por la empresa, que una persona validada está utilizando para acceder a los recursos de TI debe estar limpio y la persona debe tener acceso legítimo a esa máquina. En la práctica, esto significa algún tipo de mecanismo para garantizar que la máquina sea conocida, las políticas y la configuración hagan cumplir los estándares de seguridad y un alto grado de certeza de que el usuario es quien dice ser. El software de seguridad está comprobado y actualizado. La telemetría del sistema ayuda a garantizar la visibilidad de que la máquina en sí no se ve comprometida.

Aplicaciones

Es fundamental que solo las personas adecuadas, en sistemas confiables, accedan a las aplicaciones. La extensión lógica de lo anterior, entonces, es verificar que el usuario y la máquina tengan derechos sobre la aplicación y la red en la que se encuentra la aplicación, y verificar la seguridad de esa red. Aquí es donde una VPN a veces aún puede desempeñar un papel crucial en la empresa sin dominio, como un túnel seguro a una aplicación o recurso.

La red

Independientemente de la red en la que se encuentre el usuario, debe ser lo más segura posible, pero incluso si no es completamente segura, el usuario puede crear un enclave seguro dentro de esa red mediante una VPN. Además, las redes se pueden proteger a través de medios adicionales como MFA e incluso segmentación de VLAN.

Primeros pasos hacia la implementación de una arquitectura sin dominio

Esta idea de una arquitectura sin dominio habilitada por un servicio de directorio en la nube y seguridad de confianza cero no es puramente filosófica o una aspiración lejana para el futuro: está aquí ahora y los equipos de TI pueden comenzar a implementarla de inmediato, ya sea por completo o en un enfoque escalonado gradual adecuado a su infraestructura existente.

Para las organizaciones que están muy comprometidas con un dominio de AD en funcionamiento, un servicio de directorio en la nube puede envolver la instancia de AD, brindando muchos de los beneficios del modelo sin dominio y sirviendo como un trampolín hacia el modelo de toda la nube.

Un servicio de directorio en la nube fuerte tendrá la capacidad de valerse por sí mismo como un proveedor de identidad central, por lo que incluso las organizaciones que no están listas para estar 100 % sin dominio ahora tienen la opción de salir sin problemas de AD cuando esa migración tenga sentido.

Si desea obtener más información, explore la información sobre los servicios de directorio en la nube en G2.