Exploración de las funciones avanzadas de las soluciones IGA

Hoy les voy a ofrecer una visión general de las principales funciones de las soluciones de gestión y administración de identidades (Identity Governance and Administration, IGA).

Llevo cuatro años trabajando como consultora en ciberseguridad: trabajé dos años en el ámbito de la integración de soluciones de IGA (en concreto, la solución IdentityIQ, de SailPoint) y llevo dos años trabajando en el desarrollo de una solución de informes y paneles de control para herramientas de IAM.

Resumen de las funciones de las soluciones de IGA

La aplicaciónautoritaria

Paraello,unaaplicaciónautoritariasese define.

Se dice que una aplicación es autoritaria si permite la creación de identidades. Cada cuenta leída en esta aplicación esunaidentidaddelSI.Laprimeralecturadeestaaplicacióncrealasidentidadesdelsistema.Mediantelasiguiente,siaparece nueva cuenta aparece durante la lectura, se activará la creación de una nueva identidad.

La aplicación autoritaria suele ser la de recursos humanos (RR. HH.). Puede haber varias aplicaciones autoritarias: por ejemplo, si existe una aplicación de RR. HH. para los externos y otra para los .

La solución de IGA puede definirse como la fuente autorizada. Esto equivale a inicializar la solución creando las identidades mediante otra aplicación que se define como autorizada únicamente durante la inicialización. Posteriormente, se convierte la solución en la fuente autorizada, permitiendo la creación de nuevas identidades únicamente a través de la propia solución (en mediantedeformulariosengeneral).

Elcuboidentidad

La aplicación autoritaria permite crear identidades. Cada identidad está representada por su propio cubo. En el cubo se encuentra toda la información conocida sobre esa identidad. Por lo tanto, la información inicial es la presentesenla aplicaciónautoritaria.

Porejemplo:seallísea menudoelnombre,elnombre,elcorreo electrónico,elprofesión, la unidad organizativa, datos personales como el teléfono de la oficina y el despacho, etc.

A esto hay que añadir toda la información leída en otras aplicaciones, así como las cuentas, las autorizaciones y los roles que se poseen. Cierta información no se lee, sino que se calcula a partir de la información leída.

Por ejemplo: el responsable se puedecalculara partirde la unidad organizativa;el estado activo/inactivoenla empresa se puedecalcularapartirdelas fechas de inicio y fin del contrato de la identidad.

Cierta información puede configurarse para que sea modificable en la interfaz de la solución. Esto permite corregir o añadir información. Estas acciones pueden configurarse para solicitar una aprobación aprobaciónylasoluciónpuedemantenermantenerunahuella.

Una vez completado el cubo de identidad, esta información puede escribirse en las aplicaciones no autoritarias. Esto permite una sincronización automática de la información relativa a la identidad entre la solución IGA y las del sistema de información.

Un cubo de identidad de la herramienta IdentityIQ de SailPoint es un buen ejemplo: en él se recoge la información de identidad (poco numerosa en este caso) y se puede ver que hay pestañas disponibles para visualizar los derechos (Entitlements), las cuentas de aplicación (Application Accounts), los eventos del ciclo de vida de esta identidad (Events), etc.

UncuboidentidadenIdentityIQprocedentedehttps://allidm.com/sailpoint-identityiq-create-identity/

La gestión del ciclo de vida de la identidad

La identidad de un sistema de información pasa por numerosas etapas a lo largo de su vida útil. Estas etapas son importantes y su seguimiento permite limitar anomalías como, por ejemplo, autorizaciones que no se ajustan a la situación dela identidadodeinformaciónerróneas.

La implantación de procesos asociados a cada etapa permite una gestión automática y fluida del ciclo de vida de la identidad.

Loseventosdesencadenantes

Ejemplo del ciclo de vida de una identidad

Los eventos del ciclo de vida de la identidad son numerosos. Cada uno de estos eventos requiere la gestión de la información y las autorizaciones de la identidad. Los eventos del ciclo de vida de la identidad son específicos a cada sistema de información, cada entorno y cada cliente.

Para cada evento, se define una lista de factores que permiten determinar que una identidad está experimentando el eventoencuestión.

Ejemplo:unaidentidadpuedevivirsullegadaenelSIcuandoellasese creaenlasolución:o biena través delalectura de la aplicación autoritaria, o bien mediante una creación en la solución. Pero en otro sistema de información, una identidad puede «vivir» su llegada cuando llega la fecha de inicio de su contrato: por lo tanto, puede crearse en la solución antes de su llegada efectiva.

Losfactores queenumerar puedensercambios en la informaciónofechas.

Ejemplo: elcambia el gerente,la cambia, entonces se detecta una mutación; la fecha de finalización del contrato desencadena la salida de la identidad; la fecha de finalización de un proyecto desencadena la retirada de los derechos y roles asociados. Puede haber varios factores para un mismo evento.

La definición precisa de los eventos y sus desencadenantes es un paso importante que requiere por partepor parte de la empresa cliente un profundo conocimiento de los procesos ya existentes y una profunda reflexión: las consecuencias de una definición incorrecta pueden ser importantes.

Los procesosrelacionadosa los eventos

La detección de un evento activa un proceso asociado. Los procesos son secuencias de pasos que permiten ajustar la identidad a las políticas del sistema de información relativas al evento en cuestión.

Ladefiniciónde estos procesos se realizaenfunción delaspolíticasdelSI yde losprocesosya implantados en la empresa. Es un ámbito en el que puede ser necesario gestionar el cambio si los procesos ya existentes no son satisfactorios en términos de seguridad o eficacia,o si no existen.También es un ámbito en el queel asesoramiento y la aportación de buenas prácticas son cruciales: la creación o la modificación de los procesos puede suponer un reto para el cliente.

Lospasos generalesde estosprocesos sonla modificacióny elcálculo de información,la eliminacióny la adiciónde derechosde accesoydefunciones,el envíodenotificaciones,lageneracióndeinformesetc.

Ej.:en el caso de un traslado provocado por el cambio de unidad organizativa (UO) de una identidad, los pasos pueden ser el cálculo del nuevo responsable en función de la nueva UO, la retirada de los roles y derechos asociados a la antigua UO, la adición de los roles y derechos asociados a la nueva UO, la notificación a los responsables y a la identidad en cuestión, y la generación de un informe que contenga las identidades trasladadas ese día.

Los procesos son un paso importante para definir las políticas vigentes y poner en marcha unamejorseguridaddedatos.

La escritura o aprovisionamiento

Tras el inicio de un proceso a raíz de la detección de un evento del ciclo de vida de la identidad, llega el momento de actualizar las aplicaciones del sistema de información con la nueva información y las autorizaciones de la identidad.

Estaetapapasaporlafuncionalidadde escrituratambiéndenominadaaprovisionamiento.

La nueva información de identidad se registra en sus cuentas de aplicación. Las nuevas autorizaciones de la identidad se actualizan en las aplicaciones: algunas se añaden y otras se eliminan de las cuentas de aplicación correspondientes.

Por último,la identidadeshoydía,lasaplicacionesdelSItambiényel eventohasese ha

He aquí un ejemplo de vista funcional de la gestión de la creación de una identidad: en ella se aprecia claramente el desencadenante del proceso mediante el reconocimiento del evento «Creación de una identidad»y, a continuación, los pasos necesarios para tratar el evento en cuestión.

Unprocesodecreaciónde identidadque surgede: https  ://documentation.sailpoint.com/saas/help/workflows/workflow-basics.html

La gestión de autorizaciones

La IGAincluye la gestión de las autorizaciones (o derechos de acceso) de las identidades dentro del SI.

La gestión de autorizaciones pasa por la creación de un catálogo completo de aplicaciones, la gestión de las solicitudesde acceso, la definición de un modelo de roles y la creación de una política precisa en materia de derechos de acceso.

El catálogo de aplicaciones

La gestión de las autorizaciones requiere conocer todas las autorizaciones del sistema de información y relacionarlas conidentidades correctas.

Esto implica conectar la solución de IGA a las aplicaciones, leer las cuentas de las aplicaciones y establecer la correlaciónentrelasidentidadesdelSIylascuentasde las aplicaciones.

Elcatálogode aplicacionesesformadolascuentas,gruposyautorizacionesleídasenlasaplicacionesdelSI.

Losconectores

La función del conector es servir de enlace entre las aplicaciones del sistema de información y la solución. Existen múltiples conectores, cuya principal diferencia radica en el tipo de aplicación a la que permiten conectarse. Por ejemplo: existen conectores de Active Directory, SAP, JDBC, CSV, XML... También es posible desarrollar conectores personalizados para conectarse a tipos de aplicaciones no cubiertos por los conectores predeterminados.

Cada conector incluye una configuración que le permite conectarse a la aplicación correspondiente. El conector permite leer y escribir los datos presentes en la aplicación. Se dice que algunas aplicaciones están conectadasodirectas:eselcasocuandoelconectorse leeyescribedirectamenteenla aplicación.

Elfuncióndelconector-Aplicaciónconectada

Las aplicaciones sin conexión o indirectas no permiten leer ni escribir desde la solución:sesuelepora travésarchivosarchivossin formato(CSVoXML).Seseelarchivoplanomedianteextraccióndedatos de la aplicación en cuestión. El conector permite leer el archivo y crear objetos en la solución. Cuando es necesario modificar los datos de esta aplicación, el conector modifica el archivo planoo crea uno nuevo. La aplicación se actualiza leyendo el archivo plano más reciente disponible.

Elfuncióndelconector-Aplicacióndesconectada

La lectura de las aplicaciones

Al leer las aplicaciones, la solución obtiene los objetos presentes en ellas. Los más comunes son las cuentas de aplicación, los grupos y las autorizaciones. La solución almacena todos los objetos necesarios: este es el catálogo de aplicaciones.

La correlación

Las reglas de correlación permiten asignar cada cuenta de aplicación a la identidad correspondiente. Para ello, se compara la información presente en la cuenta de aplicación con la misma información del cubo de identidad.

Siunaúnicainformaciónbastaparahacerlala correlación,sese tratadeel identificadordeidentidades:estodebeserun atributoúnicoypersonal,diferenteparacadaidentidad.Por ejemplo:elcorreo electrónico,el nombre de usuariodeoeltrigrama.

También se puede utilizar varios datos que, en conjunto, permiten asignar la cuenta de aplicación sin riesgode cometer errores.

Ejemplo:elnombre,elnombreyla UOpuedenbastaenalgunasempresas.

Correlaciónenla direcciónde correo electrónico

A menudo es necesario realizar un estudio de la calidad de los datos y de la singularidad de los factores de correlación para cer- quequelasreglasdecorrelaciónsonadecuadas.

Las cuentas que no se pueden vincular a identidades existentes y que proceden de aplicaciones autorizadas son la causa la creación de nuevas identidades. Por el contrario, las cuentas no correlacionables procedentes de otras aplicaciones quedan huérfanas.

Lassolicitudesde acceso

La lectura de las aplicaciones permite conocer el estado del sistema de información en todo momento. La gestión de autorizaciones se basa también por la gestión automática y fluida de las necesidades de los usuarios.

Las solicitudes de concesión o retirada de accesos pueden estar motivadas por eventos predefinidos. Un evento desencadena entonces un proceso que incluye la concesión y la retirada de autorizaciones. Ej : los eventos del ciclo devida de la identidad suelen requerir la concesión y la retirada de derechos de acceso. Al producirse un cambio de puesto de una identidad dentro de la empresa,losaccesoscorrespondientesasuantiguopuestosonretiradosyloscorrespondientesasunuevopuestosonasignadas.

También es posible establecer una duración determinada para la concesión de autorizaciones.

Ej.: Al inicio de un proyecto, se asignan las autorizaciones necesarias y se indica la fecha de finalización del proyecto para que las autorizaciones se retiren automáticamente.

Por último, los usuarios del sistema de información pueden solicitar ellos mismos la concesión o la retirada de derechos de acceso. Los Los procesos automatizados cubren gran parte de las necesidades de los usuarios y su objetivo es minimizar las solicitudes adicionales. Los casos particulares se gestionan mediante solicitudes individuales realizadas por los usuariosen lasolución. Se ha definido unproceso específico para gestionar estas solicitudes. Por ejemplo: los usuarios tienen acceso a un formulario que les permite solicitar la concesión o la retirada de accesos. Cuando se realiza una solicitud, el proceso de concesión o retiradasuele incluiraprobacionespor partedel responsable ydel administrador de la aplicación en cuestión . Una vez completado el proceso con éxito, se pueden conceder las autorizaciones y se actualizan las aplicaciones.

La definición de los procesos y formularios relacionados con las solicitudes de acceso es muy personalizable y debe planificarse con detalle. Los usuarios pueden realizar estas solicitudes directamente desde la interfaz de la solución, tanto ellos mismos y para los colaboradores a su cargo. Las solicitudes de acceso pueden configurarse para que secamposcomocomentarios,fechadeinicioydefinde asignación,justificanteyotrosesténcumplimentadosporelde solicitante. Además, los formularios pueden configurarse para mostrar al solicitante la información importante sobre los accesos, como la descripción, los roles a los que pertenece, el riesgo asociado, etc.

Un buen ejemplo es el sencillo formulario de solicitud de acceso de la herramienta IdentityIQ de SailPoint: en él se observaelprimerapestañade unasolicitudde accesoparauno mismo.Élhayhayunapestañaparasolicitarunasolicitarde accesoyy otroparalosretiradasde acceso.Losaccesosala pantallasonautorizacionesautorizacionesyunfunción.Seseinformacionesinformaciónla relacionadas.La segundapestaña esuna pestañade revisiónde lasolicitud paracomprobar quees correctaantes deenviarla enviar.

Unformulariodesolicitudde accesoenIdentityIQ procedentedeIdentityIQAccessSolicitudesporSailPointTecnologíasenYouTube.

Elmodeloderoles

Los roles son conjuntos de características que agrupan identidades y otorgan derechos de acceso.La definición de roles permite simplificar la asignación de derechos de acceso y su posterior revisión.

La definición del modelo de funciones puede correr a cargo de los propios empleados: se pide a cada responsable que reúna las autorizaciones necesarias para trabajar en su equipo. De este modo se crea un modelo de funciones según las funciones y las unidades operativas.

Las soluciones de IGA suelen contar con una función de extracción de roles que permite definir los roles observables a partir del catálogo de aplicaciones vinculado al repositorio de identidades. La propia solución identifica los puntos en común entre las identidades que poseen un mismo conjunto de derechos de acceso.

El modelo de roles es una ventaja para una solución IGA eficaz y segura.

• Losusuariosvenvenasignanunjuegode accesocoherentesintenertenerhacerunasolicitarlo.
• La comprensión de los accesos se simplifica: el rol tiene un nombre y una descripción claros, a diferencia de los múltiples accesos técnicos que comprende.
• Las solicitudes de acceso son más fáciles de tramitar y aprobar: un rol claro en lugar de una lista de accesosindefinida.
• El se reduce el riesgo de solicitar y obtener derechos innecesarios .

Losdiferentestiposdefunciones

Unejemplodemodeloderolesparala UOFinanzas

Unamatrizdefuncionescompletatienevariosniveles.

• Losfuncionesde autorizaciones(ennaranja)asocianunderechode accesoasucargo
• Losfuncionestécnicas(enverde)asocianunconjuntodefuncionesde autorizacionesaunnecesidadtécnica
• Las funciones profesionales (en azul) asocian un conjunto de funciones técnicas a una profesión o a una tarea característicade una profesión
• Losfuncionesorganizacionales(envioleta)se asocianunconjuntodefuncionesprofesionalesaunaUO

Las normas y políticas

Unafuncionalidad de lassoluciones de IGAes laposibilidad dedefinirreglas y políticas para garantizar la seguridad del sistema de información.

Losmecanismoscomolaseparacióndetareas(SegregaciónofDu- ties - SoD) permiten verificar automáticamente la coherencia de los derechos y los accesos con las normas vigentes y de señalar las anomalías. La SoDse basa en asociaciones de derechos, accesosy cuentas que están prohibidas . La solución puede impedir que se produzcan estas asociaciones, denegando una solicitud de acceso si no es compatible con los accesos de los que yase dispone.

Detareasautomáticasparadetectarlasdedesusnormasse se establecen. Si se incumple una regla, se pueden enviar notificaciones,se activan auditoríasse activanpara mantenerun registrodel eventoy losprocesospuedeniniciarseiniciadosparacorregirla anomalía.

Lostiposdepolíticasderivadasdehttps://community.sailpoint.com/t5/IdentityIQ-Wiki/Separation-of-duties-SoD-best- practices-in-IdentityIQ/ta-p/178004#toc-hId–192551779

La inteligencia analítica

Laparteinteligenciadel análisisse basaenvariasnecesidades:

Lasnecesidadesde análisisenIGA

Dentro de una solución que centraliza todas las identidades y aplicaciones, funciones como las auditorías, los informes y las búsquedas permiten tener una visión clara del sistema de información y mantener un historial de acciones y del estado del sistema de información.

El cumplimiento de las políticas vigentes en el sistema de información se garantiza mediante funciones de detección y corrección de anomalías.

Losusuariostambiéntambiéndetectarycorregirdetectaranomalíasdurantelasrevisionesdeaccesos.

El análisisdedatos

Herramientas como la generación de informes, los paneles de control y los motores de búsqueda están disponibles en las soluciones de IGA para ayudar a los administradores de estas soluciones a gestionar el sistema de información de la mejor manera posible.

Informes e investigaciones

Los informes de auditoría son informes sencillos, informativos y concisos. Su elaboración se inicia a partir de una lista de accionespredefinidasqueelclientedeseatrazar.Por ejemplo:la accióndereiniciodelasoluciónpuedeiniciaruninforme de auditoría en el que se indicará la hora del reinicio y el tiempo necesario. También se pueden configurar informesde auditoríaparacadacreaciónde identidadconla hora,lafecha,losinformacióndela identidadencuestiónylafuente.

Los informes específicos son más detallados, completos y complejos. Se configuran para satisfacer las necesidades de información del cliente y para poder exportarlos. Se pueden crear según sea necesario o configurarse para que se se generenperiódicamente.Por ejemplo:lascuentasenunaaplicaciónencuyaslicenciassonde pagopuedenserobjetode un informe específico, en el que podrían aparecer columnas con datos como los nombres y apellidos de las identidades en cuestión, la fecha de creación y de último uso de cada cuenta, así como los derechos asociados.

Los informes ofrecen un sinfín de posibilidades, y los más pertinentes dependerán del contexto y de las necesidades del cliente.

Las búsquedas avanzadas y personalizadas permiten buscar objetos en la solución y ofrecen una grancantidad de información.Las búsquedasse configuranfácilmente desdela interfaz gráficapor el cliente y permiten obtener una visión general rápida de las identidades, los accesos y las autorizaciones presentes en la solución. Las búsquedas bien configuradas pueden dar lugar a la elaboración de un nuevo informe.

Lasfuncionesde análisisdedatos de las quetresimágenesprocedentesdeIdentityIQdeSailpoint

Detección y corrección de anomalías

En caso de que se detecte una discrepancia entre la teoría y la práctica, el sistema debe ser capaz de identificar las anomalías, activar una alerta y resolver el problema, o permitir que los usuarios lo resuelvan rápidamente.

La detección

Lasalertas puedenestablecerseconfigurarcuando se detectense detectanse hayan detectadopor lasolución de IGA. Si estas alertas están dirigidas a los usuarios, se muestran notificaciones o se envían correos electrónicos. Si está previsto que la solución gestione estas anomalías, estas alertas activarán los procesos correspondientes.

Ambas soluciones pueden utilizarse conjuntamente: notificación a los usuarios y activación de un pro-proceso específico.

Deinformesde auditoríapuedengenerarsegeneradosporestasalertasparamantenerunpistadelel evento.

La corrección mediante la solución

Si las anomalías detectadas son previsibles, se definen procesos para subsanarlas de forma automática, rápida y sin intervención de los usuarios del sistema de información. El cliente debe definir los pasos clave para resolver cada alerta. Esto permite que la solución gestione por sí misma su cumplimiento de las normas vigentes. Además, las anomalías que puedan suponer fallos de seguridad para el sistema de información se subsanan de inmediato y se preserva la seguridad del sistema.

Ej.:Imaginemos un sistema de información en el que se ha establecido que las contraseñas deben cambiarse cada tres meses. La solución de IGAlanza una alertasi la contraseña de un usuario tiene más de tres meses de antigüedad.El proceso puede consistir en solicitar sistemáticamente otro factor de autenticación(respuesta a una pregunta,código enviado por correo electrónico...)al usuario cuando intente iniciar sesión y, a continuación, hacer obligatorio el cambio de contraseña tan pronto como se haya autenticado en la solución.De este modo,serespeta lapolíticadecontraseñas de la soluciónyla alerta «Contraseñademasiado antigua»es gestionada directamente por la propia solución.

Corrección por parte de los usuarios

Los usuarios de la solución también pueden resolver ciertas anomalías del sistema de información. Si se requiere una intervención humana para gestionar una alerta, se pueden mostrar formularios a los usuarios responsables para obtener las instrucciones o la información necesaria.

Cuando la anomalía sea un caso particular sin precedentes o no exista ningún proceso que pueda aplicarse de forma generalizada para resolver este problema, se notificará a los usuarios responsables y estos corregirán la anomalía manualmente.

Por ejemplo:LascuentasdeaplicacionesnoautoritariasquenosonnocorrelacionablesconidentidadesdelSIsesehuérfanas. Losusuariosresponsablesdeaplicacionesen cuestiónpuedenentoncesconciliarestascuentasconlasidentidadesquelas poseen.

Si el caso concreto puesto de manifiesto por la anomalía puede volver a producirse, se definirá una nueva regla. Si error humano es la causa de ese caso concreto, se resolverá la anomalía y, a continuación, se archivará la alerta.

Lasrecertificaciones

Una recertificación permite a las personas competentes verificar que los accesos, cuentas o roles concedidos loscorrectosyderevocarlosnoadecuados.

El marco

Unacampañaderecertificaciónsedefineporsumarco:¿quéessese revisa ?

Es posible revisar las cuentas, las autorizaciones y/o los roles de las identidades. Una recertificación puede abarcar una o varias aplicaciones del SI. Las identidades incluidas en la recertificación pueden identificarse mediante unacaracterísticacomún.Lasposibilidadessoninfinitas.

Ej.:Se llevará a cabo una recertificación de los accesos clasificados como sensibles en todas las identidades que posean al menos un acceso sensible. Esto afectará a todas las aplicaciones que ofrezcan accesos denominados sensibles.

Losaprobadores

Unarecertificaciónsedefinetambiénporsusaprobadores:¿quién¿Quién lo revisa ?

Las opciones más habituales son los gestores de identidades y/o los responsables de las aplicaciones en cuestión. Eses posible configurar que la recertificación requiera varias aprobaciones.

Ej.:una recertificación puede requerir primero la aprobación del responsable y, a continuación, la del responsable de la aplicación. Las aprobaciones también pueden delegarse, es decir, el aprobador designado puede optar por pedir a otra persona que apruebe el acceso en cuestión. Esto resulta útil en el caso de los responsables que no conocenun ámbitoen particulary prefierenpedirle alresponsable delproyecto que apruebeel acceso.

Lasconsecuencias

Por último,unacampañasedefineporsusconsecuencias:que¿qué¿qué pasa ? Elaccesos norevisados despuésla fechade finalizaciónde larecertificación puedenser retirados,calificados comono aprobados o marcados como no revisados. Los accesos desaprobados pueden eliminarse tan pronto como se revise el acceso o al final de la recertificación. Pueden marcarsecomo no aprobadospero dejarseen las identidadesmientrasa que un responsablelas retireél mismo.

Lacriticidadde losobjetosrevisadosdurantedelarecertificaciónpermitirádefinirdefinirlasmedidasqueponerenponer

Laspersonalizaciones

Por lo general, se envían notificaciones por correo electrónico durante los procesos de recertificación. Se avisa a los responsables de la aprobación del inicio de la campaña y se les notifica periódicamente que aún les quedan elementos por revisar mientras no hayan terminado.

Opciones avanzadas como los comentarios, las fechas de revocación, las aprobaciones por lotes, etc., permiten definir campañas de recertificación que se ajusten al máximo a las necesidades del cliente. Laspolíticaspuedenseenenaplicarenderecertificaciones.

El principio del privilegio mínimo puede ponerse de relieve durante la recertificación indicando claramente qué autorizaciones de las que se dispone no parecen indispensables para la identidad, en función de su puesto, su unidad operativa y sus proyectos en curso. A continuación, los responsables de la aprobación decidirán si mantienen esas autorizaciones si son necesarias o si las revocan. El principio de la necesidad de conocer también puede ponerse de relieve recordando a los responsables de la aprobación que solo deben conservarse las autorizaciones que sean realmente útiles para el usuario. El hecho de poder tener una autorización por su puesto, su unidad organizativa o sus proyectos en cursono es motivo suficiente para conceder una autorización. Las reuniones informativas y los correos electrónicos de notificación pueden servir para recordar a los responsables de la autorización estas buenas prácticas cruciales.

Ejemploderevistade acceso resultadodeIdentityIQdeSailpoint

Las herramientas disponibles

Hay disponibles algunas funciones muy útiles que permiten que las soluciones de IGA se adapten a necesidadesdeclientesydeintegrarseenlavidadela empresa.

La interfaz gráfica

La interfaz gráfica de las soluciones de IGA se puede personalizar para adaptarse a la imagen de marca del cliente: los colores, los logotipos y las fuentes se definen junto con el cliente para ajustarse al máximo a su manual de identidad corporativa y para que la herramienta se integre perfectamente en el entorno del cliente.

La interfaz gráfica también se puede personalizar en cuanto a la visualización, los atajos y las funcionalidades. Los menús desplegables, los atajos y la información que aparece en la página de inicio deben definirse junto con el cliente. La página de inicio debe ser intuitiva, fácil de usar y de entender para que la solución funcione bien en la empresa. Las funcionalidades y la información más importantes deben estar en primer plano y ser de rápido acceso. Junto con el cliente, observando las herramientas que ya se utilizan, se define la mejor interfaz gráfica para el proyecto.

Por último, la interfazgráfica que se ofrece al usuariose puede personalizaren función de supuesto, su UOodesupuestojerárquicoenla empresa.

Ej.:los empleados dispondrán de una interfaz personalizada que les permitirá gestionar fácilmente su propia identidad,sus cuentas y sus autorizaciones.Losresponsablescontarán con una interfaz diferente paragestionartanto lo que les concierne a ellos como loqueconcierne alos empleados a su cargo.Por último,los responsables de lasunidades operativas dispondrán de una interfaz que les permitirá visualizar más fácilmente las diferentes identidades que gestionan, las tareas pendientes (certificaciones, aprobaciones en espera, etc.) y las funcionalidades que más utilizan.

La interfaz también se puede personalizar en función de las opciones disponibles para cada colaborador en la solución.

Ej.:todosloscolaboradorestienenaccesoalasfuncionesrelacionadasen relación concomolasolicitudde autorizaciónylavisibilidaddeinformaciónrelacionadaasuidentidad.Máslosprivilegiosenla empresasonimportantes,máslasfuncionalidades delasoluciónestándisponibles:sese piensaen particularenla inteligenciade análisisque permiteobtenerinformesinformesyde cuadros de mando sobre las identidades y las aplicaciones del sistema de información, que solo está disponible para determinados empleados.

La precisión en la personalización de la interfaz gráfica y de la página de inicio exige tener en cuenta la estructura organizativa de la empresa y las necesidades de cada empleado. Cuanto más accesible sea la interfaz, más soluciónse integraráenlavidadela empresayseráunaserá una ventaja.

Algunosejemplosdepáginasde iniciodesoluciónde IGA

Losformularios

Las soluciones de IGA cuentan con formularios para solicitar a los usuarios cierta información necesaria necesariaparafuncionamientodelasolución.

Los formularios pueden servir de soporte para funciones como las solicitudes de acceso, la creación de identidades o la modificación de los datos de una identidad (cambio de domicilio, traslado, etc.). En este caso, rellenar el formulario es el primer paso del proceso y el formulario está disponible de forma permanente para los usuarios.

Los formularios también pueden ser pasos de los procesos. En ese caso, el formulario solo aparece cuando la información sea necesaria para el proceso, en forma de ventana emergente, y dejará de estar disponible una vez validada.

Los campos de un formulario se pueden personalizar: listas en las que se puede hacer clic, campos con formato (Apellidos, Nombre), fechas,camposcalculados yno modificables(responsable calculadoen funciónde la UOelegida), de losvalores porpredeterminados modificables, etc.

Lavalidaciónde unformularioiniciaunprocesoadecuadoyqueenenlasinformaciónintroducida.

Uno de los retos es hacer que sean muy fáciles de usar, adaptándose al público objetivo. Las pruebas de los formularios en fase de desarrollo pueden realizarse con un grupo de futuros usuarios para tener en cuenta desdeel diseñolas posibles observaciones de losdepartamentos. Adaptarselo másposible a losformularios ylos procesos ya existentespermiteentoncesdelimitarlaconduccióndelcambio.

La automatizaciónde las tareas

Las tareas permiten automatizar la actualización de la solución. Se pueden iniciar manualmente cuando sea necesario, programar para que se ejecuten periódicamente o programar para que se ejecuten en momentos clave (una tareasequeconunresultadoprecisoendispararunaotraporejemplo).

Ejemplodetareas tareas

Se pueden programar secuencias de tareas para la actualización de la solución u otras necesidades periódicas ydemasiadoimportantesparasergestionarseporunsimpleproceso.

Ej.:La actualización de la solución puede requerir :

• Leerlosdatosdela aplicación autoritaria
• Actualizar los cubos de identidad
• Activarselosprocesosdecreaciónde identidadsidecuentascuentashan aparecidoenla aplicaciónautoritaria
• Eliminarlasidentidadesquenoyayacuentasenla aplicaciónautoritaria,
• Leerlosdatosdeotrasaplicaciones
• Iniciarlosprocesosrelacionadosapolíticasparaverificarlaelconformidaddeautorizacionesylascuentasexistentes
• Poneralactualizarlassolicitudesde acceso(cerrarlasparalaslaslecturashandemostradoquelasaccesosestáncorrectamente asignados)

Las tareas disponibles y el historial de sus resultados permiten un mantenimiento de la solución sin intervención humana y una importante trazabilidad de la información: gracias al historial, sabemos cuándo informaciónseobtenidaylosprocesossese activan.

Mariann FAURE

Consultora de ciberseguridad