Avanzando hacia la gestión de identidades
Un acceso más cómodo y sencillo a los recursos TI, el aprovisionamiento automatizado de contraseñas y un mayor nivel de seguridad y productividad son tan sólo algunas de las ventajas que están animando a muchas empresas a plantearse el despliegue de infraestructuras de gestión de identidades. Sin embargo, estos proyectos suelen resultar mucho más complejos de lo previsto y algunos de sus objetivos iniciales pueden quedar frustrados.
A medida que la industria de seguridad se ha ido consolidando, muchas de las herramientas de gestión de identidades, en un pasado autónomas, han ido siendo absorbidas por suites que integran aprovisionamiento de usuario, gestión de acceso Web, firma única (SSO) y otras funcionalidades en un mismo entorno. Pero centralizar la gestión de información sobre identidades sigue siendo un reto costoso y complejo que implica la integración de diversos repositorios basados en directorio y específicos de aplicación. Además, paradójicamente, en aquellas organizaciones a las que más ventajas aportarían estas posibilidades (grandes empresas donde la gestión manual de cuentas se hace más difícil dado el elevado número de usuarios, la alta frecuencia de los cambios y la gran cantidad de aplicaciones corporativas) es precisamente donde más difícil resulta el despliegue de infraestructuras de gestión de identidades centralizadas y globales.
Según Gartner, la integración de algunas aplicaciones en una solución centralizada y las cuestiones relacionadas con la gestión basada en roles constituyen objetivos que deben estar soportados por arquitecturas que muchas organizaciones encuentran muy complejas de planificar y desplegar. Y no es de extrañar, teniendo en cuenta que las soluciones para identificar y gestionar roles de usuario constituyen hoy un mercado todavía muy incipiente. Como resultado, casi siempre, lo que a menudo se plantea como un proyecto global y centralizado termina reduciéndose a la implementación de una solución para sólo determinadas aplicaciones y grupos de usuarios. No todas las aplicaciones corporativas estarán preparadas para integrarse en las nuevas plataformas, ni todos los roles serán estandarizables. Por tanto, muchas veces algunas tareas, como, por ejemplo, el aprovisionamiento de derechos de acceso, deberán seguir haciéndose de forma manual.
Alcance limitado
Uno de los principales problemas en este tipo de proyectos está relacionado directamente con la heterogeneidad de las infraestructuras ya existentes en las empresas, en las que abundan los sistemas heredados. En un caso documentado por IDG, una gran compañía petrolera planificó un ambicioso proyecto que perseguía la creación de una infraestructura de gestión de identidades gestionada de forma centralizada. Uno de los objetivos era que el nuevo sistema permitiera automatizar el proceso de distribución de nuevas cuentas de usuario para acceder al elevado número de aplicaciones corporativas. El plan incluía la gestión del ciclo de vida de todas las identidades de usuario y privilegios de acceso. Desafortunadamente, hubo que paralizar esos planes el año pasado, tras comprobar que la tecnología disponible no podía satisfacer sus requerimientos.
El problema era conseguir tales objetivos a gran escala. Para lograrlo, la petrolera necesitaba gestionar identidades y proporcionar acceso en función de cada rol de usuario y de cada tipo de acceso requerido para realizar mejor sus tareas; algo bastante complejo en una organización con 84.000 empleados repartidos por 200 países. Los productos disponibles podían manejar un pequeño número de roles estáticos, pero no estaban bien preparados para gestionar roles dinámicos basados en atributos. Además, en el análisis previo de la infraestructura para conocer los cambios que el nuevo sistema exigiría, la compañía descubrió que muchas de sus aplicaciones no soportaban acceso basado en roles. Y añadir tal capacidad a cada aplicación hubiera resultado demasiado complejo y costoso. Resultado: el proyecto quedó congelado a la espera de un mejor momento para su despliegue.
Ciertamente, los productos han mejorado desde que la compañía del caso citado se planteó por primera vez el proyecto, pero, aún así, el acceso basado en roles todavía no está lo suficientemente maduro. Las nuevas aplicaciones con soporte de un sistema de directorio común, como Active Directory, simplifican bastante la gestión basada en roles, pero incluso entonces seguirán existiendo grandes dificultades. Aunque Active Directory permite seguir la trayectoria de los roles, sigue siendo necesario trabajar directamente en cada aplicación para hacer el mantenimiento de determinadas tareas, como, por ejemplo, asignar, cambiar y eliminar las acciones a las que están autorizados esos roles en esa aplicación.
Por otra parte, muchos despliegues de gestión de identidades también carecen de la suficiente granularidad, pues sólo soportan un acceso tipo “todo o nada” a las aplicaciones. La implementación de controles de acceso más precisos, donde los usuarios dispongan de distintas clases de acceso según sus roles, es todavía algo limitado a muy pocas organizaciones. Y esto significa que, en la mayoría de los casos, los administradores, si desean un acceso granular, siguen viéndose obligados a gestionarlo dentro de todas y cada una de las aplicaciones.
Definición de roles
La limpieza y el mapeado de los datos es otro de los grandes retos de cualquier proceso de despliegue de infraestructuras de gestión de identidades. De hecho, las empresas no siempre tienen sus datos en un formato que permita reunirlos e integrarlos en un repositorio común de identidades. A veces, también ocurre que los propios responsables de los proyectos no entienden los procesos de negocio lo suficientemente bien como para desplegar sistemas basados en roles de forma adecuada. Los despliegues, además, pueden resultar muy costosos, y, como ya se ha visto, la complejidad aumenta con el tamaño de la organización. Los ejecutivos TI deben asumir que habrán de pagar entre 20 y 30 dólares por usuario en concepto de software, y entre dos y seis veces esa cantidad por la integración, según datos de Microsoft.
Por otra parte, la definición de roles es, de por sí, una tarea tremendamente compleja. A menudo, no existe una manera estandarizada de hacerlo desde una perspectiva de proceso de negocio. Durante la definición surgen muchas incertidumbres que nada tienen que ver con las capacidades de la tecnología, sino con decisiones de gestión de más alto nivel que a veces pueden entrar en conflicto por motivos de disparidad de criterios. Así, por ejemplo, el jefe de un área en un hospital puede considerar que, además de los enfermeros, el director de enfermería debe disfrutar también de acceso a los registros médicos porque alguna de sus competencias así lo exija. Sin embargo, el de otra área puede determinar que tal acceso no está justificado. Incluso es posible que esa disparidad de opiniones esté justificada por el hecho mismo de que las tareas de uno y otro director de enfermería pueden ser diferentes debido a la distinta organización del trabajo dentro de cada unidad. Estandarizar completamente sobre esta base será más que complicado.
Inevitablemente, la creación y el modelado de roles es generalmente un proceso largo que exige gran dedicaci&#
A medida que la industria de seguridad se ha ido consolidando, muchas de las herramientas de gestión de identidades, en un pasado autónomas, han ido siendo absorbidas por suites que integran aprovisionamiento de usuario, gestión de acceso Web, firma única (SSO) y otras funcionalidades en un mismo entorno. Pero centralizar la gestión de información sobre identidades sigue siendo un reto costoso y complejo que implica la integración de diversos repositorios basados en directorio y específicos de aplicación. Además, paradójicamente, en aquellas organizaciones a las que más ventajas aportarían estas posibilidades (grandes empresas donde la gestión manual de cuentas se hace más difícil dado el elevado número de usuarios, la alta frecuencia de los cambios y la gran cantidad de aplicaciones corporativas) es precisamente donde más difícil resulta el despliegue de infraestructuras de gestión de identidades centralizadas y globales.
Según Gartner, la integración de algunas aplicaciones en una solución centralizada y las cuestiones relacionadas con la gestión basada en roles constituyen objetivos que deben estar soportados por arquitecturas que muchas organizaciones encuentran muy complejas de planificar y desplegar. Y no es de extrañar, teniendo en cuenta que las soluciones para identificar y gestionar roles de usuario constituyen hoy un mercado todavía muy incipiente. Como resultado, casi siempre, lo que a menudo se plantea como un proyecto global y centralizado termina reduciéndose a la implementación de una solución para sólo determinadas aplicaciones y grupos de usuarios. No todas las aplicaciones corporativas estarán preparadas para integrarse en las nuevas plataformas, ni todos los roles serán estandarizables. Por tanto, muchas veces algunas tareas, como, por ejemplo, el aprovisionamiento de derechos de acceso, deberán seguir haciéndose de forma manual.
Alcance limitado
Uno de los principales problemas en este tipo de proyectos está relacionado directamente con la heterogeneidad de las infraestructuras ya existentes en las empresas, en las que abundan los sistemas heredados. En un caso documentado por IDG, una gran compañía petrolera planificó un ambicioso proyecto que perseguía la creación de una infraestructura de gestión de identidades gestionada de forma centralizada. Uno de los objetivos era que el nuevo sistema permitiera automatizar el proceso de distribución de nuevas cuentas de usuario para acceder al elevado número de aplicaciones corporativas. El plan incluía la gestión del ciclo de vida de todas las identidades de usuario y privilegios de acceso. Desafortunadamente, hubo que paralizar esos planes el año pasado, tras comprobar que la tecnología disponible no podía satisfacer sus requerimientos.
El problema era conseguir tales objetivos a gran escala. Para lograrlo, la petrolera necesitaba gestionar identidades y proporcionar acceso en función de cada rol de usuario y de cada tipo de acceso requerido para realizar mejor sus tareas; algo bastante complejo en una organización con 84.000 empleados repartidos por 200 países. Los productos disponibles podían manejar un pequeño número de roles estáticos, pero no estaban bien preparados para gestionar roles dinámicos basados en atributos. Además, en el análisis previo de la infraestructura para conocer los cambios que el nuevo sistema exigiría, la compañía descubrió que muchas de sus aplicaciones no soportaban acceso basado en roles. Y añadir tal capacidad a cada aplicación hubiera resultado demasiado complejo y costoso. Resultado: el proyecto quedó congelado a la espera de un mejor momento para su despliegue.
Ciertamente, los productos han mejorado desde que la compañía del caso citado se planteó por primera vez el proyecto, pero, aún así, el acceso basado en roles todavía no está lo suficientemente maduro. Las nuevas aplicaciones con soporte de un sistema de directorio común, como Active Directory, simplifican bastante la gestión basada en roles, pero incluso entonces seguirán existiendo grandes dificultades. Aunque Active Directory permite seguir la trayectoria de los roles, sigue siendo necesario trabajar directamente en cada aplicación para hacer el mantenimiento de determinadas tareas, como, por ejemplo, asignar, cambiar y eliminar las acciones a las que están autorizados esos roles en esa aplicación.
Por otra parte, muchos despliegues de gestión de identidades también carecen de la suficiente granularidad, pues sólo soportan un acceso tipo “todo o nada” a las aplicaciones. La implementación de controles de acceso más precisos, donde los usuarios dispongan de distintas clases de acceso según sus roles, es todavía algo limitado a muy pocas organizaciones. Y esto significa que, en la mayoría de los casos, los administradores, si desean un acceso granular, siguen viéndose obligados a gestionarlo dentro de todas y cada una de las aplicaciones.
Definición de roles
La limpieza y el mapeado de los datos es otro de los grandes retos de cualquier proceso de despliegue de infraestructuras de gestión de identidades. De hecho, las empresas no siempre tienen sus datos en un formato que permita reunirlos e integrarlos en un repositorio común de identidades. A veces, también ocurre que los propios responsables de los proyectos no entienden los procesos de negocio lo suficientemente bien como para desplegar sistemas basados en roles de forma adecuada. Los despliegues, además, pueden resultar muy costosos, y, como ya se ha visto, la complejidad aumenta con el tamaño de la organización. Los ejecutivos TI deben asumir que habrán de pagar entre 20 y 30 dólares por usuario en concepto de software, y entre dos y seis veces esa cantidad por la integración, según datos de Microsoft.
Por otra parte, la definición de roles es, de por sí, una tarea tremendamente compleja. A menudo, no existe una manera estandarizada de hacerlo desde una perspectiva de proceso de negocio. Durante la definición surgen muchas incertidumbres que nada tienen que ver con las capacidades de la tecnología, sino con decisiones de gestión de más alto nivel que a veces pueden entrar en conflicto por motivos de disparidad de criterios. Así, por ejemplo, el jefe de un área en un hospital puede considerar que, además de los enfermeros, el director de enfermería debe disfrutar también de acceso a los registros médicos porque alguna de sus competencias así lo exija. Sin embargo, el de otra área puede determinar que tal acceso no está justificado. Incluso es posible que esa disparidad de opiniones esté justificada por el hecho mismo de que las tareas de uno y otro director de enfermería pueden ser diferentes debido a la distinta organización del trabajo dentro de cada unidad. Estandarizar completamente sobre esta base será más que complicado.
Inevitablemente, la creación y el modelado de roles es generalmente un proceso largo que exige gran dedicaci&#
