Gestión de identidades IAM

Implementación de la gestión de identidad

Administrar la identificación y autenticación de personas, dispositivos y servicios

La actividad central dentro de la administración de identidades y accesos (IAM) es la administración de identidades, incluidas las personas, los dispositivos y los servicios. En laboratorio, describimos los procesos y las tecnologías que se utilizan en la actualidad.

Implementación de gestión de identidad

La implementación de la gestión de identidades comienza con un plan. Un sistema de administración de identidad y acceso (IAM) en una organización es un sistema complejo y distribuido que toca sistemas, redes y aplicaciones, y también controla el acceso a los activos. Un sistema IAM también incluye los procesos comerciales que funcionan junto con las tecnologías y el personal de IAM para realizar el trabajo.

Un sistema IAM es probablemente la función más importante que implementará una organización. Después de la propia red, el sistema IAM suele ser el más crítico en un entorno, porque el sistema IAM controla el acceso a todos los sistemas y aplicaciones.

Inicio de sesión único (SSO)

El concepto de inicio de sesión único (SSO) aborda un problema común tanto para los usuarios como para los administradores de seguridad. Cada cuenta que existe en un sistema, red o aplicación es un punto potencial de acceso no autorizado. Varias cuentas que pertenecen a un solo usuario representan un riesgo aún mayor:

• Los usuarios que necesitan acceso a múltiples sistemas o aplicaciones a menudo deben mantener numerosas credenciales. Inevitablemente, esto conduce a atajos en la creación y recuperación de contraseñas. Abandonados a sus propios dispositivos, los usuarios crean contraseñas débiles que solo tienen ligeras variaciones o, peor aún, usarán las mismas contraseñas en todos los lugares que puedan. Cuando tienen múltiples conjuntos de credenciales para administrar, es más probable que los usuarios las anoten. No se detiene en los límites de la organización: los usuarios a menudo usan las mismas contraseñas en el trabajo que usan para sus cuentas personales.
• Varias cuentas también afectan la productividad del usuario porque el usuario debe detenerse para iniciar sesión en diferentes sistemas. Alguien también debe crear y mantener cuentas, lo que implica desbloquear cuentas y brindar soporte, eliminar, restablecer y deshabilitar múltiples conjuntos de ID de usuario y contraseñas.

A primera vista (por desgracia), SSO parece la solución “perfecta” que buscan los usuarios y los administradores de seguridad. SSO permite que un usuario presente un conjunto único de credenciales de inicio de sesión, generalmente a un servidor de autenticación, que luego registra al usuario de manera transparente en todos los demás sistemas y aplicaciones empresariales para los que ese usuario está autorizado. Por supuesto, SSO tiene algunas desventajas, que incluyen:

¡Guau!: Después de autenticarte, tienes las llaves del reino.

Lo puedes entender como que ya tienes acceso a todos los recursos autorizados Es la pesadilla del profesional de la seguridad. Si las credenciales de inicio de sesión de las cuentas de un usuario se ven comprometidas, un intruso puede acceder a todo lo que el usuario final estaba autorizado a acceder. Piensa lo que podría pasar en un Ayuntamiento.

Complejidad

Implementar SSO puede ser difícil y llevar mucho tiempo. Debe abordar los problemas de interoperabilidad entre diferentes sistemas y aplicaciones. 

Lenguaje de marcado de aserción de seguridad (SAML)

El protocolo de facto para la autenticación, SAML, se utiliza para facilitar la autenticación de usuarios entre sistemas y entre organizaciones, a través del intercambio de información de autenticación y autorización entre organizaciones. SAML es el pegamento que se utiliza para hacer funcionar la mayoría de los sistemas de inicio de sesión único (SSO).

Como sugiere su nombre completo, SAML es un lenguaje de marcado XML. XML se está convirtiendo en un método estándar para intercambiar información entre sistemas diferentes.

Kerberos 

Kerberos, comúnmente utilizado en Sun Network File System (NFS) y Microsoft Windows, es quizás el protocolo de autenticación de claves simétricas basado en tickets más popular que se usa en la actualidad.

Kerberos lleva el nombre del feroz perro de tres cabezas que guarda las puertas del Hades en la mitología griega. Investigadores del Instituto Tecnológico de Massachusetts (MIT, también conocido como Millionaires in Training) desarrollaron este protocolo de sistemas abiertos a mediados de la década de 1980.

Kerberos es un protocolo complejo que tiene muchas implementaciones diferentes y no tiene una explicación simple. La siguiente discusión paso a paso es una descripción básica del funcionamiento de Kerberos:

1)El cliente solicita al sujeto (como un usuario) un identificador y una credencial (por ejemplo, nombre de usuario y contraseña). Con la información de autenticación (contraseña), el cliente genera y almacena temporalmente una clave secreta para el sujeto mediante una función hash unidireccional y luego envía solo la identificación del sujeto (nombre de usuario) al servidor de autenticación (AS) del Centro de distribución de claves (KDC). La contraseña/clave secreta no se envía al KDC:

2) El AS en el KDC verifica que el sujeto (conocido como principal) existe en la base de datos del KDC. El Servicio de concesión de tickets (TGS) del KDC genera una clave de sesión de cliente/TGS cifrada con la clave secreta del sujeto, que solo conocen el TGS y el cliente. El TGS también genera un Ticket de concesión de tickets (TGT), que consta de la identificación del sujeto, la dirección de red del cliente, el período de validez del ticket y la clave de sesión del cliente/TGS. El TGS encripta el TGT utilizando su clave secreta, que solo el TGS conoce, luego envía la clave de sesión del cliente/ TGS y el TGT al cliente.

3) El cliente descifra la clave de sesión del cliente/TGS (usando la clave secreta almacenada que generó usando la contraseña del sujeto), autentica al sujeto (usuario) y luego borra la clave secreta almacenada para evitar un posible compromiso. El cliente no puede descifrar el TGT, que el TGS cifró mediante la clave secreta de TGS.

4) Cuando el sujeto solicita acceso a un objeto específico (como un servidor, también conocido como principal), envía el TGT, el identificador del objeto (como un nombre de servidor) y un autenticador al TGS en el KDC. (El autenticador es un mensaje separado que contiene la identificación del cliente y una marca de tiempo, y usa la clave de sesión del cliente/TGS para encriptarse).

5) El TGS en el KDC genera una clave de sesión de cliente/servidor (que cifra mediante el uso de la Clave de Sesión Cliente/TGS) y un Ticket de Servicio (que consta de la identificación del sujeto, la dirección de red del cliente, el período de validez del ticket y la Clave de Sesión Cliente/Servidor). El TGS encripta el Ticket de Servicio utilizando la clave secreta del objeto solicitado (servidor), que solo conocen el TGS y el objeto. Luego, el TGS envía la clave de sesión del cliente/servidor y el vale de servicio al cliente.

6) El cliente descifra la clave de sesión de cliente/servidor mediante la clave de sesión de cliente/TGS. El cliente no puede descifrar el Ticket de Servicio, que el TGS cifró utilizando la clave secreta del objeto solicitado.

7) El cliente puede entonces comunicarse directamente con el objeto solicitado (servidor).

El cliente envía el Ticket de Servicio y un autenticador al objeto solicitado (servidor). El cliente cifra el autenticador (que comprende la identificación del sujeto y una marca de tiempo) utilizando la clave de sesión de cliente/servidor que generó el TGS. El objeto (servidor) descifra el ticket de servicio utilizando su clave secreta.

El ticket de servicio contiene la clave de sesión del cliente/servidor, que permite que el objeto (servidor) descifre el autenticador. Si la identificación del sujeto y la marca de tiempo son válidas (de acuerdo con la identificación del sujeto, la dirección de red del cliente y el período de validez especificado en el ticket de servicio), se establece la comunicación entre el cliente y el servidor. La clave de sesión de cliente/

servidor se usa luego para comunicaciones seguras entre el sujeto y el objeto.

---

LDAP

El protocolo ligero de acceso a directorios (LDAP) es tanto un protocolo IP como un modelo de datos.

LDAP (pronunciado EL-dap) se utiliza para admitir funciones de directorio y autenticación para personas y recursos. Varios proveedores han implementado LDAP, incluidos:

• Servidor de Directorio Apache
• Directorio eTrust de CA
• IBM SecureWay y Tivoli Directory Server
• Directorio Activo de Microsoft
• Servidor de directorio Sun

Radius

El protocolo RADIUS (Remote Authentication Dial-In User Service ) es un protocolo de red cliente- servidor de código abierto, definido en más de 25 RFC del IETF  actual, que proporciona autenticación, autorización y responsabilidad (AAA). RADIUS es un protocolo de capa de aplicación que utiliza paquetes de protocolo de datagramas de usuario (UDP) para el transporte. UDP es un protocolo sin verificación de conexión, lo que significa que es rápido, pero no tan confiable como otros protocolos de transporte.

RADIUS se implementa comúnmente en redes de proveedores de servicios de red (NSP), así como en servicios corporativos de acceso remoto (RAS) y redes privadas virtuales (VPN). RADIUS también se está volviendo cada vez más popular en las redes inalámbricas corporativas. Un usuario proporciona información de nombre de usuario/contraseña a un cliente RADIUS mediante PAP o CHAP. El cliente RADIUS cifra la contraseña y envía el nombre de usuario y la contraseña cifrada al servidor RADIUS para la autenticación.

Nota: Las contraseñas intercambiadas entre el cliente RADIUS y el servidor RADIUS están encriptadas, pero las contraseñas intercambiadas entre el cliente de la estación de trabajo y el cliente RADIUS no están necesariamente encriptadas, por ejemplo, si se utiliza la autenticación PAP. Si el cliente de la estación de trabajo también es un cliente RADIUS, todos los intercambios de contraseñas se cifran, independientemente del protocolo de autenticación utilizado.