Se ha hablado mucho sobre identidad federada y servicios de inicio de sesión único (SSO) a lo largo de aproximadamente de una decada, pero la necesidad fundamental de estas características solo se ha manifestado completamente en los últimos años. Originalmente, las empresas querían integrar aplicaciones y servicios internos con sistemas centrales de gestión de identidad para reducir el esfuerzo de gestión, pero esos desafíos de antaño,  ahora se han convertido en triviales. Nos aburre ya , hablar de la computación cloud y los dispositivos móviles como innovaciones disruptivas, pero estos avances han obligado a repensar por completo cómo crear una exitosa Gestión de Identidad y Acceso (IAM). Administrar usuarios en cloud y recursos móviles fuera de nuestra red corporativa y en sistemas de terceros fuera de nuestro control, no es sólo un simple cambio en los modelos de Gestión de Identidad.

Se nos presentan nuevos riesgos, derivados tanto del cambio en la forma en que se ofrecen los servicios, como de la forma en que los usuarios desean acceder a los mismos. "La Cloud" fuerza un cambio fundamental en la forma en que manejamos la autenticación, la autorización y la auditoria (AAA) . Las empresas desean extender las capacidades a sus usuarios a través de proveedores de servicios cloud, al tiempo que se mantiene la seguridad, la gestión de políticas y el cumplimiento. Pero no podemos simplemente usar la misma herramienta legacy con el fin de implementar un modelo de seguridad el cloud. El objetivo es utilizar los servicios cloud como si fueran nuestros propios sistemas internos, pero ampliando las capacidades de gestión de identidad y acceso que requieren estos nuevos modelos cloud , con el fin de tener una transiciones exitosa.

Si deseamos comprender las arquitecturas emergentes de Gestión de Accesos e Identidad (IAM), es mejor comenzar olvidando lo que sabemos ( En mi caso lo tengo fácil 😜 ). Los servicios de directorio que usamos hoy (normalmente LDAP y Active Directory) fueron diseñados en la era del cliente-servidor, y sus implementaciones generalmente presuponen un sistema cerrado. Los servicios en Cloud y, en menor medida, la informática móvil, han forzado un nuevo enfoque que abarca la descentralización. Comparamos el cambio del servicio de directorio interno a Cloud IAM como el de pasar de una vista centrada en la Tierra del universo a una vista centrada en el Sol: Es un cambio completo de perspectiva. Estamos hablando de la fusión de múltiples capacidades de administración de identidad y acceso, posiblemente a través de múltiples servicios Cloud, para computadoras y dispositivos que no están completamente bajo nuestro control.

Nuestro fin en la Gestión de Identidad y Accesos Cloud debería ser la capacidad de autorizar a los usuarios a través de múltiples servicios sin distribuir las credenciales a todos y cada uno de los proveedores.

Soluciones espaciales

El Cloud Computing es excelente para proporcionar a las empresas aplicaciones y datos bajo demanda, independientemente de la ubicación del usuario y las capacidades del lado del cliente. Los empleados pueden acceder a datos y aplicaciones corporativas sin usar servidores corporativos o a través de una conexión VPN. Pero, ¿cómo podemos gestionar la información de identidad con los proveedores externos cuando eliminamos aplicaciones del control de los sistemas de gestión de identidad en nuestras instalaciones? El negocio está tratando de descubrir cómo mantener el control de la gestión de identidades mientras aprovechamos la cloud.

El objetivo es unificar la gestión de identidad para usuarios internos y externos, tanto en nuestra TI tradicional como en servicios de nube de terceros.

Es posible administrar el acceso de los usuarios a los recursos Cloud Computing internamente, pero la arquitectura debe tener en cuenta la complejidad de la integración y los costos de administración. En muchas organizaciones, se encuentran con que estos inconvenientes superan los beneficios. Por una variedad de razones comunes (incluido el servicio bajo demanda, la elasticidad, el amplio acceso a la red, la reducción de los gastos de capital, la implementación rápida y el costo total), las empresas adoptan servicios Cloud Computing para reemplazar los servicios internos y aprovechar los servicios en Cloud de terceros para administrar identidad y acceso.

La gestión de la identidad era mucho más simple bajo el modelo antiguo de cliente-servidor, cuando los usuarios se limitaban principalmente a disponer de un único PC de escritorio con quizás otro conjunto de credenciales para acceder a un puñado de servidores. Se configuraban las Listas de Control de Acceso (ACL), se daban algunos roles y ¡ Listo ! . Pero a medida que los servidores y aplicaciones se multiplicaron, el 'End Point' pasó de los escritorios fijos a los dispositivos remotos y los servidores se integraron en otros dominios de servidor ( Ya no importan las ACLs y los roles, si no más bien ¿ En qué ámbito estamos ? ). Utilizamos los servicios de directorio como un único repositorio de gestión de identidad que propagamos a toda la empresa.

Ahora tenemos una explosión de proveedores de servicios externos: Aplicaciones financieras, almacenamiento Cloud, redes sociales, flujo de trabajo, CRM, correo electrónico, colaboración .... por nombrar solo algunos. Estos servicios "Outsides" son críticos para el negocio, pero ninguno se vinculan directamente con los servicios de directorio tradicionales.

Este diagrama nos ayuda a entender e ilustra el cambio en la arquitectura y la implementación de la identidad, y nos ayuda a crear una imagen de la Identidad como Servicio ( IDaaS )  que extiende las capacidades internas a la cloud:
El cambio viene en cuatro partes principalmente:

1. El departamento de TI ya no posee los servidores y las aplicaciones de los que depende la organización, o al menos parte de ellos.
2. Las capacidades del proveedor Cloud no son totalmente compatibles con los sistemas internos existentes.
3. El modelo de seguridad centrado en la red, con conceptos claramente definidos de "interno" y "externo", desaparece.
4. Las formas en que los usuarios consumen servicios Cloud son radicalmente diferentes cuando se consideran dispositivos móviles y aplicaciones móviles. Un empleado puede consumir servicios corporativos en cloud sin tocar nunca los sistemas informáticos internos y combinar servicios personales y profesionales.

Casi todas las empresas aprovechan uno o más proveedores de software como servicio (SaaS), y muchos están dando sus primeros pasos con la plataforma y la infraestructura como servicio (PaaS e IaaS, respectivamente)  con sus propios enfoques de identidad y acceso. Extender los servicios tradicionales de Gestión de  Identidad corporativa fuera del entorno corporativo no es trivial ( Además de que genera mucho miedo ) : Ya que requiere la integración de los sistemas IAM existentes con los proveedores Cloud. El tiempo, el esfuerzo y el coste de desarrollar y mantener vínculos con cada proveedor de servicios pueden ser abrumadores.

Soluciones de Gestión de Identidad Cloud

Idealmente, nos gustaría extender las capacidades de gestión de identidad internas existentes a sistemas de terceros, minimizando el trabajo en la gestión de TI mientras brindamos servicios a los usuarios finales con una interrupción mínima o si es posible, inexistente.

Queremos mantener el control sobre los acceso de los usuarios:

• Agregar y eliminar usuarios según sea necesario y propagar nuevas políticas de autorización sin una latencia significativa.
• También queremos recopilar información sobre el acceso y el estado de la política para ayudar a cumplir con los requisitos de seguridad y cumplimiento.
• Y en lugar de construir un puente personalizado para todos y cada uno de los servicios de terceros, queremos una interfaz de administración única y simple que extienda nuestros controles y políticas a varios servicios de terceros.

Las características y beneficios comunes a la mayoría de los sistemas de gestión de acceso e identidad en Cloud incluyen:

• Single Sign-On (SSO): este servicio central consiste en :

1. Autenticación de credenciales de usuario
2. Provisión de acceso de usuario a múltiples servicios internos y externos sin proporcionar credenciales adicionales a cada servicio.

Por supuesto, ofrecer SSO a los usuarios, posiblemente sea la única vez en la que alguien se ponga feliz al ver aparecer al equipo de seguridad, ¡ Así que aprovecha al máximo!

• Federación de identidad : La identidad federada recopila configuraciones de identidad y autorización de múltiples sistemas de administración de identidad/repositorios, permitiendo que diferentes sistemas definan las capacidades y el acceso del usuario. La identidad y la autorización son una responsabilidad compartida entre múltiples fuentes autorizadas. La identidad federada es un superconjunto de autenticación e inicio de sesión único. La federación se ha vuelto mucho más relevante como motor de transmisión para SSO y servicios web. Su aceptación en Cloud ha sido sustancial porque su arquitectura central ayuda a las empresas a navegar uno de los problemas más espinosos de la nube: Retener el control interno de las cuentas de los usuarios y aprovechar las aplicaciones y los datos Cloud.
• Controles de autorización granulares: el acceso no suele ser una propuesta de "todo o nada": a cada usuario, se le permite acceder a un subconjunto de funciones y datos almacenados en Cloud. Los mapas de autorización indican a las aplicaciones qué recursos proporcionar a cada usuario. La cantidad de control que tiene sobre el acceso de cada usuario depende de las capacidades tanto del proveedor de servicios Cloud como del propio sistema IAM. La industria de la autorización y la cloud están evolucionando para centrarse en un control de acceso más detallado, eliminando la política de acceso del código tanto como sea posible. En pocas palabras, los roles son necesarios pero no suficientes para la autorización,  también necesitamos atributos. Tampoco deseamos detallar millones de líneas de código para definirlas, revisarlas, modificar o auditarlas, por lo que las reglas deben ser configurables y basadas en datos ( Cuantas menos reglas mejor ). Los estándares de autorización están disponibles, pero la madurez y la adopción de los mismos, son incipientes.
• Administración: Los administradores generalmente prefieren un panel de administración único para administrar usuarios y administrar la identidad en múltiples servicios. El objetivo de la mayoría de los sistemas de IAM en Cloud es hacer exactamente eso, pero necesitan ofrecer ajustes granulares a la autorización en diferentes aplicaciones mientras extraen datos de diferentes fuentes autoritativas de identidad. Esto requiere que la administración central se vincule con diferentes fuentes autoritativas de identidad, así como con los servicios que consumen información de identidad.
• Integración con servicios de directorio interno: Los sistemas Cloud IAM dependen de la integración con LDAP internos, Active Directory, sistemas de recursos humanos y otros servicios para replicar identidades, roles y grupos de empleados existentes en los servicios Cloud. Por norma general se están  aprovechando las fuentes internas que reducen la cantidad de trabajo para habilitar los servicios Cloud, y proporcionando un punto de partida confiable para Cloud IAM. Los servicios IAM internos siguen siendo la autoridad central para la identidad interna, pero delegan la responsabilidad de la administración del acceso al servicio IAM Cloud.
• Integración con servicios externos: Uno de los principales beneficios de los proveedores de IAM en Cloud es que ofrecen conectores a servicios comunes, por lo que no necesitamos escribir nuestro propio código de integración. La interfaz para comunicarse con Salesforce es diferente a las interfaces de Box, Evernote, Dropbox, Amazon Web Services y Rackspace. Ni siquiera las compañías más grandes quieren escribir código de interfaz personalizado para cada servicio externo en Cloud que usan. Aprovechar el "pegamento" de terceros para conectarse a proveedores de SaaS, PaaS e IaaS comunes hace que la integración sea más fácil y rápida.

Problemas clave con los servicios de identidad

Entre las capacidades adicionales de los diversos servicios figuran la autenticación multifactorial, la integración de los usuarios móviles y el apoyo a las personas con múltiples usuarios. Estas características ayudan a vincular la gestión de identidad tradicional con los servicios en Cloud. Pero a medida que los proveedores intentan resolver estos problemas, la IAM en Cloud crea nuevos problemas que no reciben tanta atención.

• APIs: Aunque los proveedores de IAM ofrecen conectores a los servicios Cloud más comunes, es poco probable que proporcionen todos los conectores que se necesitan. Además, los proveedores Cloud cambian las APIs con regularidad, a veces rompiendo las aplicaciones de sus clientes. Es probable que tenga que proporcionar su propia integración, aprovechar las herramientas de los proveedores de servicios de IAM para crear conexiones personalizadas o contratar a un proveedor de IAM para que las cree por nosotros. Esto plantea el reto adicional de incorporar a los desarrolladores de terceros y darles los derechos de acceso adecuados.
• Mapeo de autorización: Existen muchas formas posibles de especificar las reglas de autorización, como por ejemplo por función o por atributo.
  Es probable que las reglas de acceso existentes necesiten ser reescritas por un proveedor de servicios Cloud, después de que todos los objetos ( tales como URL y datos ) a los que estamos concediendo acceso sean proporcionados por el proveedor Cloud.
• Auditoría: Los sistemas internos pueden vincularse con los sistemas de gestión de registros y SIEMs para producir informes de cumplimiento y proporcionar la vigilancia y la detección de eventos de seguridad. Los registros de auditoría de los proveedores de servicios Cloud siguen siendo problemáticos en el modelo "multi-tenant" impide que la mayoría de los proveedores proporcionen registros completos porque podrían revelar datos sobre otros clientes.
• Privacidad: Los usuarios, los atributos de los usuarios y otra información a menudo son empujados fuera de su red corporativa , en uno o más repositorio de datos en Cloud. Los controles de seguridad y privacidad de estos repositorios externos no están totalmente bajo su control, por lo que es necesario explorar qué datos copia nuestro proveedor, qué utilizan "in situ", y determinar los controles de seguridad tanto del proveedor de IAM como del proveedor de servicios Cloud en las copias que residen en la misma.
• Latencia: Propagar los cambios de reglas del IAM interno al IAM Cloud puede tomar algún tiempo. Por ejemplo, si se despide a un empleado o se reducen sus derechos de acceso, puede haber un desfase entre el cambio interno y el momento en que el servicio de la nube aplica el cambio. La latencia es un tema que debe discutirse tanto con su proveedor de IAM como con el proveedor de servicios Cloud.
• Gestión de usuarios privilegiados: Esto ha sido un problema durante mucho tiempo, y la nube añade una nueva "brecha". Históricamente los usuarios privilegiados eran todos los empleados, y si las cosas se ponían feas se podía manejar como un evento de RRHH. En Cloud esto no es posible.
• Identidad de la aplicación / App Identity: Una vez que el usuario ha iniciado sesión, puede que todavía tenga que verificar la aplicación que está utilizando o tal vez no haya ningún usuario, sólo middleware. ¿Pero de dónde vino la solicitud? La triste verdad es que mientras sepas cómo llamar al servicio, muchas aplicaciones hoy en día no verifican el cliente... Al igual que el punto anterior, este ha sido un problema de TI durante mucho tiempo.
• Móvil: Los equipos de seguridad aún están absorbiendo las implicaciones de Cloud, pero la tecnología no espera: Tenemos un paradigma completamente nuevo a desarrollar. La seguridad móvil es particularmente relevante no solo en Cloud. El móvil es parte de la Cloud, SaaS, IaaS y PaaS forman el lado del servicio del Cloud Computing, los dispositivos móviles forman el lado del consumidor. Como mencionamos al inicio, las conexiones móviles a los servicios Cloud ocurren fuera de los límites de las operaciones normales de TI. Esto significa, otro dominio más para administrar, uno que se acopla libremente desde el directorio interno y los sistemas de autorización. Si bien no podemos cubrir toda la IAM de la parte móvil en este post, hay varios
  tendencias que vale la pena mencionar: La primera es el concepto de autorización condicional. En esencia, esto significa que los derechos de los usuarios pueden verse limitados si están fuera de la red corporativa o si usan aplicaciones móviles. El contexto de lo que un usuario intenta hacer y bajo qué condiciones ( ubicación geográfica, tipo de dispositivo ... ) se tienen en cuenta en la autorización de la plataforma de la aplicación. La segunda tendencia es la necesidad de autenticación de dos factores ( 2FA ), y no solo confiar en el supuesto de que su usuario posee un dispositivo móvil. Requerir una verificación adicional de que un usuario es quien dice ser hace que sea más difícil para los atacantes simplemente robar dispositivos, o tokens de identidad, y actuar como usuario en docenas de diferentes servicios Cloud. Una vez que aprecias que un smartphone es esencialmente una tarjeta inteligente multiinquilino, puedes ver que la seguridad móvil es fundamentalmente un problema de identidad y por qué estas tendencias son los primeros indicadores de que el móvil se convierte en un punto de convergencia para la identidad y por ello, para la ciberseguridad.
• Identity Strore: si las empresas están trasladando sus aplicaciones y datos a servicios Cloud, ¿también moverán las tiendas de identidad existentes? Algunas empresas ven esto como una evolución lógica, mientras que otras tienen requisitos de seguridad y gobierno que requieren que los datos de identidad y autorización se mantengan internamente. A medida que los conceptos de 'adentro' versus 'afuera' continúen erosionándose, y la diferenciación entre aplicaciones 'empresariales' y 'cloud' se desdibuje, tanto los riesgos como los beneficios de mover las tiendas de identidad estarán en el centro del debate en los próximos años.

CASOS DE USO

El cloud computing plantea diferentes desafíos y requiere repensar las implementaciones de IAM. Los siguientes casos de uso ilustran los principales motivadores mencionados por los negocios que mueven las aplicaciones existentes a la nube, tanto para implementaciones internas como externas, y cómo se integran con servicios en Cloud de terceros.

La arquitectura IAM a menudo se siente bastante abstracta: describir sus rasgos es un poco como postular si la luz se comporta más como una partícula o una onda. Y luego están los estándares, muchísimos estándares. Pero los casos de uso son concretos: muestran el catalizador, la actividad y el valor para la empresa y los usuarios. Comienza con casos de uso y luego busca tecnologías de identidad y estándares que se ajustan, al lugar del contrario.

Para ayudar a comprender por qué el cloud computing requiere que las compañías reconsideren su estrategia de gestión de identidad y acceso, intentaremos ver y comprender problemas comunes. Estos casos representan los controladores de la estructura de implementación de IAM y la necesidad de nuevos protocolos para propagar los privilegios de los usuarios y establecer la identidad en entornos distribuidos.

Conceptos clave de IAM

Antes de llegar a los casos de uso, debemos describir los tipos de actores en IAM. Puede haber numerosos roles diferentes en un sistema Cloud IAM, pero los siguientes se encuentran en la mayoría de las implementaciones:

• Identity Provider: Consultado en tiempo de ejecución, el IdP es una fuente autorizada de información sobre los usuarios. A menudo se trata de un servidor Active Directory o LDAP, que a su vez proporciona atributos que el IdP usa para acuñar tokens que representan las identidades de los usuarios. Las arquitecturas cloud compunting a menudo incluyen más de un IdP. El IdP generalmente se implementa "internamente" en el sistema empresarial.
• Relying Party: Un RP es una aplicación que se basa en la información de identidad afirmada por el Identity Provider para establecer la identidad. La parte que confía valida los tokens como genuinos y de un Identity Provider  autorizado, y luego los usa para afirmar la identidad del usuario. Los RP generalmente se implementan en el sistema del proveedor Cloud. En algunos casos, un RP busca aprovechar el "efecto de red" de múltiples servicios confiables para ayudar a validar que un usuario es quien dice ser.
• Attribute Provider: Un AP tiene acceso o almacena directamente los atributos específicos que definen las capacidades del usuario. El AP difiere de un IdP en que usa atributos asociados con un usuario en lugar de contraseñas. El AP usa cosas como número de teléfono, dirección, número de tarjeta de crédito como una forma orientada al consumidor de identificar a los usuarios. Los permisos pueden estar basados en roles, en atributos o en ambos. El valor está en habilitar el control de acceso dinámico basado en datos. Esta información es crítica: define el comportamiento de la aplicación y permite el acceso del usuario a funciones y datos. La forma en que proporciona información de atributos y se integra con la aplicación varía mucho.
• Fuente autoritativa/autorizada: Esta es la autoridad en configuración de identidad y aprovisionamiento. El AP es típicamente el sistema de recursos humanos que almacena registros de identidad maestros, utilizados como la fuente de la verdad para el estado de la cuenta. Este sistema tiene derechos para agregar, editar y deshabilitar cuentas de otros sistemas, generalmente a través de un sistema de aprovisionamiento. Para los requisitos legales y de cumplimiento, estos sistemas mantienen registros de transacciones detallados.
• Policy Decision Point: Un PDP maneja las decisiones de autorización asignando cada solicitud de acceso a una política. Esto puede realizarse en el código de la aplicación o dentro de una política configurada por separado.
  Puede haber otros roles de IAM en su implementación, pero este es el conjunto básico para IAM en la nube. La clave es que las funciones de gestión de identidad y acceso se dividen en funciones simples y cada una se distribuye en una o más plataformas internas o Cloud. La ubicación de cada servicio varía según el modelo de implementación seleccionada. Cada rol puede ser cumplido por el proveedor Cloud y/o empresa, pero estos roles distribuyen las responsabilidades fundamentales para los servicios de identidad en la nube.

CASO DE USO CLOUD

SINGLE SIGN-ON

Single Sign-On es la mayor motivación para que las empresas vean las nuevas tecnologías IAM para admitir el Cloud computing. Y por una buena razón: Durante nuestro recorrido en seguridad, he visto pocas ocasiones en que las personas se alegran de ver las características de seguridad introducidas por norma general. Sin embargo, el inicio de sesión único (SSO) es una feliz excepción a esta regla porque facilita la vida de todos los usuarios. Proporcionar  nuestra contraseña una vez, y automáticamente obtener acceso a todos los sitios que usemos durante el día... Agregar nuevas aplicaciones en Cloud (Salesforce, Amazon Web Services y Dropbox ... ) solo hace que el SSO sea más deseable. La mayoría de otras tecnologias de ciberseguridad no escala bien, pero SSO sí.
Detrás de los telones, SSO ofrece otras ventajas más sutiles para la ciberseguridad y las operaciones. En una implementación de SSO, el proveedor de identidad proporciona una ubicación central para las políticas y el control. El almacén de usuarios se comporta como la fuente autorizada de información de identidad, y al extender esta capacidad a Clouf, a través de API, tokens y servicios de terceros, el equipo de ciberseguridad puede evitar cierta preocupación por las discrepancias entre las cuentas internas y las cuentas Cloud. El proveedor de identidad actúa efectivamente como la fuente de la "verdad" para las aplicaciones Cloud. Debeis tener en cuenta que para este caso de uso nos centramos en SSO para servicios en la nube.  

Si hemos dominado esta capacidad con los servicios de TI internos tradicionales, extender SSO a la nube presenta nuevos desafíos. El SSO tiene muchos sabores/colores cloud, algunos basados ​​en estándares inmaduros y en evolución, otros patentados y específicos del proveedor. Peor aún, los mecanismos por los cuales la identidad se "consume" varían, con algunos servicios que "extraen" la identidad directamente de otros sistemas de TI, mientras que otros requieren que la información sea "enviada" a ellos. Finalmente, los protocolos utilizados para realizar estas tareas también varían: SAML, OAuthv2, API de proveedores, etc.

Afortunadamente, SAML, como el estándar acordado, es ofrecido por los principales proveedores de SaaS e IaaS, y se está volviendo cada vez más común con los proveedores de PaaS que anteriormente se enfocaban en las contraseñas proporcionadas a través de API web.

Otro desafío para el SSO Cloud es la ciberseguridad de los tokens de identidad. A medida que los tokens se convierten en algo más que simples cookies de sesión para aplicaciones web, e incorporan capacidades de usuario para potencialmente docenas de aplicaciones, se vuelven más atractivos como objetivos. Un atacante con un token SSO obtiene todos los derechos de usuario transmitidos por el token, lo que podría proporcionar acceso a docenas de aplicaciones en Cloud. Esto es un problema menor si todos los protocolos protegen adecuadamente los tokens comunicados a través de Internet, pero algunos no. Por lo tanto, los tokens SSO deben estar protegidos por TLS / SSL, con un régimen de protección para el acceso y almacenamiento de tokens por parte de las aplicaciones.

El SSO hace la vida más fácil para los usuarios y administradores, pero para los desarrolladores es solo una solución parcial. El proceso de inicio de sesión se simplifica, pero la granularidad de los atributos y los enganches en el código de autorización de Relying Party aún requieren un diseño y desarrollo cuidadosos.
Finalmente, tenemos el problema inverso de SSO: SLO (Single Logout).

"¿Qué hacemos cuando un usuario cierra sesión?" Si el usuario ha iniciado sesión en muchas aplicaciones, ¿finalizamos solo una sesión o todas? Incluso si desea que todas las sesiones se cierren, la mayoría de los sistemas SSO no pueden limpiar las sesiones en ejecución. Deberemos revisar la administración de la sesión y los tiempos de espera de la actividad junto con las capacidades del sistema SSO. Debe probarse para garantizar que las aplicaciones en sí mismas no mantengan las sesiones abiertas a pesar de la política. SLO se menciona casi universalmente en todas las RFI y RFP de las compañías, pero en la práctica rara vez se implementa. En cambio, las empresas confían en los tiempos de espera de sesión automáticos y otras técnicas para limpiar las sesiones SSO.

APROVISIONAMIENTO

A medida que agregamos nuevas aplicaciones y servicios en Cloud, nos surgen nuevas preguntas, ¿cómo podemos habilitar el acceso de los usuarios a ellos? Esto se denomina aprovisionamiento y es cómo proporcionamos información de la cuenta de usuario a las aplicaciones Cloud. Hay varias posibilidades, y los clientes pueden emplear uno o más, generalmente combinados en un proceso de aprovisionamiento:

1. Registro de la cuenta: Crea una nueva cuenta en el servicio Cloud, mediante el registro del usuario o posiblemente enviando información de una fuente autorizada como el Sistema de Recursos Humanos.
2. Propagación de cuenta: Sincroniza o replica cuentas al proveedor Cloud, generalmente desde servicios de directorio.
3. Administración de cuentas: Actualiza el estado de la cuenta, atributos, grupos, roles y otra información de la cuenta.
4. Deshabilitar cuenta: "Desaprovisionar" o deshabilitar el acceso a funciones o aplicaciones.
5. Auditoría: realiza un seguimiento de las actividades integrales de los usuarios y la gestión de los derechos de acceso. Esto incluye tanto la monitorización  contínua de la actividad como la revisión periódica de políticas para preocupaciones tales como la separación de funciones.

Este ciclo de vida se puede administrar dentro de la empresa, con sincronización con el proveedor Cloud. O se puede realizar completamente en la nube si el riesgo adicional de tener un conjunto completo de credenciales de usuario dentro del entorno del proveedor (probablemente multi-tenant). Manejar todo el aprovisionamiento de forma remota en Cloud generalmente requiere un mayor esfuerzo.

La tercera opción es la Gestión de identidades externalizada como servicio: servicios en Cloud para IAM. Un puñado de proveedores puede conectar sistemas internos con proveedores externos en Cloud, cuidando la sincronización e integración de los servicios. Los proveedores ahora ofrecen el ciclo de vida IDM a través de nubes IDM dedicadas con la interfaz de administración asociada del usuario.

Intercambio de atributos

Los sistemas tradicionales de TI de las empresas y de proveedores Cloud, necesitan una gestión coordinada de datos. La información puede ser retenida por una o más partes, por lo que la sincronización es clave. El intercambio de datos se produce a través de puertas de enlace, portales de servicios web, Enterprise Service Buses (ESB) o identidad de aplicaciones, sistemas que toman decisiones basadas en la identidad de la aplicación en lugar de la identidad del usuario. Podemos  pensar en esto como una forma de aprovisionamiento, pero la forma en que se proporcionan los datos y cómo la utiliza la aplicación es fundamentalmente diferente.

La identidad de la aplicación es un área en la que los proveedores de la nube a menudo están por delante de la práctica estándar en TI, porque a cada host generalmente se le asigna su propia cuenta en lugar de ser administrado mediante un proceso ad hoc. Estas identidades, ya sea ESB, puerta de enlace, servidor de aplicaciones u otras, tienden a ser más duraderas, por lo que pueden estar en juego diferentes protocolos. La identidad de la aplicación se puede administrar con los certificados x.509 de la "vieja escuela", como con AWS de Amazon, pero estos intercambios de atributos se prestan a protocolos diseñados para manejar tales problemas, como SCIM para aprovisionamiento y SAML para SSO. Para operaciones más precisas o datos "más frescos", x.509 a menudo no es lo suficientemente bueno.

El servicio de token de seguridad (STS) se puede utilizar para intercambiar interacciones de identidad. Un factor a tener en cuenta en este caso de uso es el papel del cliente. En algunos patrones, como la seguridad API, WS-Trust y OAuth, el cliente es responsable de realizar el trabajo de empujar y tirar para configurar las cookies y los datos de la sesión y navegar "el baile" de protocolo entre el cliente y el servidor. En patrones como SAML y seguridad basada en navegador, el cliente puede ser pasivo, con el servidor iniciando operaciones y el cliente recibiendo y respondiendo mensajes.

Ya sea en la vieja escuela o en Cloud, los casos de uso de Attribute Exchange son la cinta aislante de la identidad: cubren una amplia variedad de escenarios de integración, desde compartir identidad en los últimos smartphones hasta sistemas de mensajería legacy. La identidad es la gestión de compartir, y el intercambio de atributos ayuda a abarcar las interacciones. Ningún producto o protocolo único puede lograr una cobertura total de extremo a extremo, pero es esencial que el arquitecto tenga en cuenta la cadena completa de responsabilidades para mantener la calidad e integridad de los datos de identidad.

Modelos de implementación de identidad en Cloud

Las implementaciones de IAM para la nube generalmente usan alguna combinación de los siguientes enfoques:

• Almacenar cuentas en Cloud: Esto es exactamente lo que parece: replicar o sincronizar cuentas en el entorno de la nube. Esto es conceptualmente simple, y la mayoría de los departamentos de TI ya están familiarizados con la replicación de directorios, por lo que es la forma más fácil de comenzar. También es un modelo que crea problemas de seguridad cuando replica, y potencialmente expone, información confidencial, incluidas claves, contraseñas y otros datos de control de acceso.
  Recuerde, "Cloud" es, naturalmente, un entorno de múltiples inquilinos, compartido por otros clientes y administradores. Los cambios de roles, así como la eliminación o desactivación de cuentas, pueden retrasarse de manera inaceptable antes de que el cambio interno sea efectivo en el proveedor Cloud.

• Federación de identidad: En esta opción, las identidades de los usuarios se administran localmente, pero las afirmaciones de identidad se pueden validar a través de tokens presentados en la interfaz del servicio Cloud. La empresa conserva el control y la gestión local, generalmente a través de Active Directory, y las solicitudes se realizan de forma dinámica. Esto evita almacenar datos secretos como contraseñas en la nube. La federación nos permite aprovechar los procesos IDM existentes, posiblemente en múltiples sistemas, lo que simplifica la administración y el aprovisionamiento.

• IDMaaS: Identity Management as a Service es una arquitectura emergente que debemos tener muy presente. Esto es efectivamente un híbrido de los dos primeros enfoques. Una nube separada gestiona la identidad, generalmente administrada por un proveedor de servicios Cloud diferente, que se vincula directamente a los sistemas internos locales para el soporte de la decisión de políticas. Una de las principales ventajas de este enfoque es que el proveedor IDMaaS lo vincula a varios servicios en la nube, manejando todas sus idiosincrasias técnicas detrás de escena. El proveedor IDMaaS efectivamente pega todo junto, proporcionando federación de identidad y soporte de autorización. Sin embargo, debemos tener cuidado de que nuestro proveedor realmente ofrezca IDMaaS y no simplemente copie todos nuestros datos en su entorno Cloud, en esencia se convierta en un centro de datos tercerizado.

Standards

Los estándares de identidad son los componentes básicos de la identidad en Cloud y ayudan a conectar todas las partes. Pero hay muchas partes móviles diferentes, cada una con un trabajo diferente, por lo que hay muchos estándares diferentes. La buena noticia es que cada estándar sobresale en un aspecto en la propagación de identidad. La mala noticia es que hay muchos estándares de identidad para elegir, por lo que es difícil saber qué estándar hace qué o cuál es el adecuado para nosotros.

Si estamos creando nuestra propia solución, debemos elegir con cuidado: la arquitectura IAM en Cloud debe estar basada en estándares, pero los estándares no deben impulsar la arquitectura IAM en la nube. Una de las ventajas de trabajar con proveedores externos de IdaaS es que ya lo tienen en funcionamiento, lo que ahorra tiempo y esfuerzo. Nos integramos con el proveedor de IdaaS, que proporciona "pegamento"  a otros servicios en la nube en nuestro nombre.
Al pensar en los desafíos de identidad, es útil separar la tarea a realizar del estándar IAM que hace el trabajo. Como ejemplo, el siguiente es un posible conjunto de estándares para lograr un complemento completo de las tareas de IAM.

No todos los estándares disfrutan de una amplia adopción. De hecho, muchos estándares están en su "infancia", con una adopción limitada incluso entre los proveedores de servicios de identidad Cloud. Además, se requiere que ambas partes, en una relación federada apoyen el mismo enfoque para SSO / Federación para que funcione.

En este cuadro podemos ver la madurez relativa a las normas comunes:

Roadmap de Implementación IAM Cloud

Los proyectos de IAM son complejos, abarcan la mayor parte de la infraestructura de TI y pueden llevar años implementar y desplegar por completo ( Pongo esto en negrita, ya que hay quien piensa que puede llegar a solventarse con un simple proyecto ). Intentar hacer todo a la vez es , y será , morir en el intento, por debemos disponer de una hoja de ruta de implementación para ayudarnos a alcanzar nuestros objetivos, intentando sufrir lo menos posible.

Debemos centrarnos en cómo construir un esquema "arquitectónico" para nuestra organización en particular, basado en el servicio Cloud y en los modelos de implementación que seleccionamos. Luego, crearemos diferentes hojas de ruta de implementación, dependiendo de los objetivos de nuestro proyecto y marcaremos los requisitos comerciales más críticos.

Anteriormente describimos tres casos de uso comunes para Cloud IAM: SSO, aprovisionamiento e intercambio de atributos. La buena noticia es que el proceso de creación de una hoja de ruta de implementación es prácticamente lo mismo, independientemente del caso de uso que elijamos. Lo único cambiante, es el entorno y las prioridades de cada cliente, cada negocio, por lo que cumplir con estos casos de uso requiere una implementación y un plan ligeramente diferentes para cada uno.

Strategy First

Haciendo un pequeño guiño a Trump. Las hoja de ruta de la implementación comienzan con un diseño del sistema, en el que luego se describen una serie de pasos necesarios para implementar la solución en diferentes fases.

La hoja de ruta debe comenzar con el supuesto de que habrá muchas dificultades ( Que las habrá seguro )  porque pocas organizaciones tienen estrategias de identidad coherentes. Desafortunadamente, los equipos de identidad dedicados son raros, y suele carecer del poder que se le debe otorgar. Este trabajo se deja en gran parte a las almas desafortunadas que zigzaguearon y que como recompensa obtuvieron el título de "Arquitecto IAM" incluido en una lista existente de responsabilidades. Estas personas, abrumadas por la complejidad, tienden a despejar y externalizar el problema a los consultores. El resultado predecible es un mosaico de soluciones tácticas parcialmente implementadas.

Con estas consideraciones en mente, podemos decidir de manera realista qué problemas abordar primero, teniendo en cuenta el soporte organizativo, de procesos y tecnológico disponibles. Debemos intente no pensar en IAM Cloud como otro punto de solución IAM. El replanteamiento total de IAM impulsado por el cloud computing ofrece soluciones más flexibles y efectivas que las disponibles antes. Por lo tanto, debemos ajustar nuestro pensamiento, considerar dónde serán útiles las soluciones de identidad y descubrir cómo una de las arquitecturas en Cloud  descritas, puede ampliar nuestras capacidades.

Según nuestra arquitectura, seleccionar y establecer una lista de prioridades y luego enumerar qué capacidades están presentes dentro de su infraestructura existente actual.

Roles como guía de proceso

Debemos analizar nuestros casos de uso y centrarnos específicamente en los roles de los "actores", mapeando cómo interactúan entre sí. Tocamos varios roles comunes:

• Identity Provider
• Relying Party
• Proveedor de atributos
• Fuente autoritativa
• Punto de decisión de políticas.

Un buen primer paso para delinear nuestra estrategia, es descubrir qué servidores cumplirán estos roles. Segundo, determinar cómo se comunicarán las partes y qué información necesitan intercambiar. Este roadmap del proceso debe proporcionar una buena comprensión de cómo funcionan todas las piezas juntas, qué característica será importante y qué datos deben estar disponibles. Nuestro rodmap debe incluir las restricciones impuestas por estos actores del sistema, por ejemplo, la aplicación en Cloud del Relying Party probablemente acepta un conjunto limitado de tokens de identidad. La comprensión temprana de las limitaciones es tan importante como conocer los requisitos de las funciones.

Cada rol necesita comunicarse con otros roles. Las comunicaciones a menudo se dan por sentadas, si pensamos en "Internet" debería ser HTTP/s, sobre todo, pero no siempre. La comunicación podría ser a través de llamadas API, o las comunicaciones HTTP podrían depender de SSL / TLS suplementario por seguridad. Cada parte necesita establecer una confianza mutua para evitar ser engañados por otros actores maliciosos. Para evitar sorpresas y simulacros de incendio de última hora sobre cambios en las reglas del firewall, rastrea las comunicaciones y los protocolos necesarios de extremo a extremo. Los problemas de seguridad surgen debido a fugas de información, seguridad de las sesiones, suplantación de identidad y otras preocupaciones, por lo que vale la pena examinar el diálogo entre las partes y especificar la seguridad de las comunicaciones durante la fase de diseño.

Busca los gaps

El estado de IAM es con frecuencia una mezcolanza de cosas, con varios componentes atornillados a problemas específicos que surgieron con el tiempo. Esto obliga a muchos proyectos de IAM a quemar mucho en tiempo o un tiempo  considerable en la limpieza y transformación de datos. El punto de partida es un esquema para la identidad y las cuentas utilizadas para las decisiones de acceso a Cloud. Es fundamental comprender qué trabajo debe realizarse e identificar las integraciones más difíciles.

A partir de ahí, el orden de implementación está muy influenciado por la cantidad de desorden que necesitemos limpiar. Lo simple es lo mejor: no intentes construir un esquema de superidentidad para todos. Incluso cuando la definición del esquema es sencilla, nuestra aplicación en múltiples backends rara vez lo es. Es importante revisar las fuentes de datos, asegurarnos de que funcionan con el esquema de identidad y establecer un proceso para limpiar y manejar los conflictos.

Las expectativas realistas son esenciales: sé conservador sobre lo que se puede lograr y no seas demasiado agresivo desde el principio. No copies tu lista de funciones del documento de capacidades de un proveedor y asume que todo "simplemente funcionará".

Sé conservador: menos es más.

Una última palabra sobre cómo construir nuestro esquema: debemos comprender no sólo cómo funcionan las cosas, sino también qué sucede cuando no funcionan. La identidad y el acceso tienen puntos de fallo, muy feos, que cuando se rompen la gente se da cuenta muy rápido y tú tienes la culpa.

Planifica las fallas en cada nodo dentro de nuestro esquema y comprende los efectos secundarios cuando cada servicio deja de funcionar. ¿Hay complicaciones interesantes si dos o más se caen al mismo tiempo, o en la peor secuencia posible? ¿Puede nuestro sistema soportar breves interrupciones periódicas? Necesitamos pruebas suficientes para descubrir problemas graves antes de la implementación en producción. Pero la mayoría de las herramientas de seguridad y control de calidad no son adecuadas para probar IAM. Por ello, para cada caso de uso que desemos implementar, debemos crear un conjunto de casos de prueba ( positivos: esto debería funcionar; y negativos: esto debería fallar ) para asegurarnos de que lo que estamos "promocionando" funciona de principio a fin. Estas pruebas pueden influir en la línea de tiempo de la implementación a medida que se descubren los problemas: es mejor encontrarlos y solucionarlos ahora que durante o después de mover el sistema a producción. La mayoría de los usuarios no se preocupan por tus problemas técnicos, "solo" necesitan que todo funcione siempre.

La planificación operativa también debe incluir la construcción de un runbook: documentación de la instalación, configuración, registro y tareas administrativas necesarias para mantener el sistema IAM en funcionamiento. Para las aplicaciones Cloud, esto requiere una planificación y coordinación cuidadosa, porque algunos roles y responsabilidades son nuevos, y los roles se comparten entre los proveedores Cloud y la empresa. Debemos comprender qué roles administramos y cuáles son manejados por nuestro proveedor de servicios Cloud. Para algunas implementaciones en la nube (IaaS, Cloud privada y algunas PaaS), podemos configurar la infraestructura para garantizar que el registro, la configuración del sistema y los roles de administrador estan completamente definidos antes de iniciar cualquier instancia.

Conclusión

Identity and Access Management es un tema tremendamente complejo, y acabamos de rascar la superficie para darle una visión general de las tendencias y soluciones actuales. Podríamos pasar toda la carrera estudiando los matices de cómo todas estas piezas funcionan de forma junta.

Es probable que IAM sea solo una parte de nuestro trabajo, por lo que es normal no dominar todo lo que hemos hablado. En mi opinión , es una de las áreas más difíciles y a la cual menos interés se presta, y que a la vez, es de extrema importancia y necesidad.

En mi caso, fue la primera área que toque en este sector de la ciberseguridad, durante un corto periodo de tiempo, y a la que tengo cierto "cariño" , llegando a comprender la importancia que debe dársela , y la criticidad y complejidad que tiene.

El IAM es en mi opinión , el principal pilar de la ciberseguridad