Roles en un programa de IGA: quién hace qué

Otro sentido de “rol”

Los cuatro artículos anteriores usaron “rol” en un solo sentido: un paquete de entitlements asignado a una población, como lo definió el artículo del catálogo de entitlements. Este artículo usa la palabra como la usa todo el mundo fuera de IAM: el puesto de una persona. Cierra el primer módulo nombrando a quienes hacen de verdad el trabajo que describieron los artículos anteriores, porque nada de eso funciona solo. Cada vez que esos artículos dijeron “el gobierno decide”, había una persona concreta detrás de la decisión, y de quién es esa persona trata este artículo.

El artículo del catálogo sostuvo que cada entitlement necesita un owner con nombre y que un entitlement sin owner se acumula como una cuenta huérfana. El artículo de JML mostró un conflicto en un traslado sobre el que alguien tuvo que decidir, y revisiones que necesitan a alguien con contexto de negocio para significar algo. Los dos lo describieron como requisitos estructurales sin responder una pregunta más simple: ¿de quién es este trabajo, en el organigrama de una organización real? Una política que dice que los entitlements necesitan owners no crea owners. Un programa necesita personas, con cargos y con tiempo asignado, haciendo el trabajo. Este artículo es el elenco, y los ejemplos usan los mismos casos de los artículos anteriores para que se vea quién estuvo detrás de cada uno.

El elenco

La dirección del programa

Quien dirige el programa es responsable del plan, del calendario y de la coordinación entre equipos. No del diseño técnico, y de ninguna decisión de negocio sobre el acceso. Su trabajo es conseguir que la arquitectura, la ingeniería, el análisis y los owners de aplicación hablen de verdad entre sí con un ritmo regular, que cada hito (una fase de descubrimiento, un piloto, una primera campaña de revisión completa) tenga responsable y fecha, y que cuando dos grupos no estén de acuerdo, por ejemplo ingeniería quiere ir más rápido de lo que le parece prudente a un owner de aplicación, haya un foro para resolverlo en lugar de un bloqueo.

Una disciplina útil para quien dirige el programa es distinguir un problema de calendario de un problema de decisión. Un plazo que se corre tiene arreglos de calendario: reordenar el trabajo, sumar gente, recortar alcance. Una decisión atascada porque un owner no respondió es otra cosa, y hay que escalarla a la jefatura de ese owner, no rodearla pasándole la decisión a quien esté disponible. Una dirección de programa que empieza a tomar decisiones sobre entitlements para no retrasar el calendario está deshaciendo en silencio el gobierno que el programa vino a construir.

La arquitectura de IAM

La arquitecta diseña el estado objetivo. Eso incluye el modelo de datos de identidad del artículo 2: qué sistemas son autoritativos para qué, cómo funciona el emparejamiento, cada cuánto corre la reconciliación. Incluye la convención de nombres y el esquema de niveles de riesgo del artículo del catálogo, y los patrones para conectar los sistemas destino con la plataforma. Responde de que el diseño aguante los casos reales: dos David en Finanzas, un contratista cuyo contrato vence sin ningún registro de baja, un sistema heredado sin un conector limpio. Un diseño que luce elegante en una pizarra y se desarma con la primera aplicación desordenada no estaba diseñado, solo esbozado.

La arquitecta es la autora natural de la convención de nombres y de los niveles de riesgo, no porque deba decidir qué significa cada entitlement, sino porque alguien tiene que ser dueño de la estructura común que permite que cientos de entitlements, definidos por decenas de owners a lo largo de meses, sigan leyéndose como un solo catálogo y no como decenas de esquemas locales incompatibles.

La ingeniería de IAM

El ingeniero construye y opera lo que diseñó la arquitecta: conectores, flujos de aprovisionamiento, el enrutamiento de aprobaciones y los escalamientos, los procesos de reconciliación y la configuración de la plataforma que hay debajo. En un programa chico, ingeniería y arquitectura suelen ser la misma persona, que cambia de sombrero a lo largo de la semana. En uno más grande, la arquitecta diseña, el ingeniero construye y la arquitecta sigue respondiendo de que lo que corre coincida con el diseño cuando se encuentra con sistemas reales.

El análisis de negocio

El analista conecta al equipo técnico con las partes del negocio que toca el programa. Recoge los requisitos reales del paquete estándar de un puesto, entrevista a los owners de aplicación sobre lo que hace de verdad un conjunto de permisos y traduce los procesos de negocio a algo contra lo que la arquitectura pueda diseñar. El ejemplo de curaduría de siniestros del artículo del catálogo, 340 grupos reducidos a cinco distinciones reales, dependió por completo de que alguien hiciera entrevistas estructuradas con la owner de operaciones de siniestros en lugar de adivinar por los nombres de los grupos. Ese trabajo de entrevista es el aporte central del analista, y es fácil subestimar cuánto de la calidad de un catálogo sale de ahí.

Un programa sin analista no se ahorra ese trabajo. Solo cae, de forma desigual, en la arquitecta o el ingeniero que tenga tiempo, y así terminan los catálogos curados por personas con mucho conocimiento técnico y poco contexto de negocio.

El owner de aplicación

El owner de aplicación es donde aterriza la mayor parte de la responsabilidad de este módulo. Es el owner que figura junto a cada entitlement de su sistema en el catálogo, quien aprueba las solicitudes de acceso a él y la persona a la que una revisión le pide confirmar que las asignaciones siguen siendo correctas. También es la persona a la que llega, al final, un conflicto de separación de funciones que involucra su sistema: ¿puede el negocio tolerar esta combinación concreta de accesos para esta persona concreta? Nadie más del elenco tiene el contexto de negocio para responder eso con credibilidad, y por eso la responsabilidad tiene que estar en el owner y no derivar hacia ingeniería de IAM solo porque ingeniería ya está en la sala.

Cumplimiento y riesgo

Cumplimiento y riesgo son dueños del marco regulatorio y de control al que este dominio vuelve una y otra vez: los controles de gestión de cuentas de NIST SP 800-53, las cláusulas de acceso de ISO/IEC 27001 y el marco del sector que corresponda. Su trabajo no es correr revisiones ni definir entitlements. Es traducir lo que de verdad va a pedir un auditor de SOX o de HIPAA en requisitos contra los que la arquitectura pueda diseñar, y comprobar, antes de que lo haga un auditor, si la evidencia del programa aguantaría. Esa comprobación vale más cuando es rutinaria. Una persona de cumplimiento que revisa una muestra de campañas de revisión y de reportes de reconciliación cada trimestre encuentra los huecos cuando todavía hay tiempo de arreglarlos, en lugar de encontrarlos con la presión de una auditoría que ya empezó.

Seguridad

El papel de seguridad es más acotado pero filoso. Revisa las excepciones de separación de funciones que conllevan riesgo real, participa en las bajas urgentes en las que la salida misma es un problema de seguridad, como un despido, y aporta la mirada de un atacante a la clasificación por riesgo. Esto último merece un ejemplo. El acceso de lectura a una base de datos de clientes puede parecer un entitlement “estándar” desde la mirada de operaciones. Para un atacante que comprometió una cuenta de pocos privilegios, es exactamente lo primero que querría, para reconocer el terreno antes de intentar ir más lejos. Un owner de aplicación concentrado en la operación diaria no siempre pondera eso, y por eso seguridad debería revisar los propios criterios de clasificación, no solo las excepciones sueltas.

El patrocinio ejecutivo

Por encima del elenco de trabajo suele haber una persona más, y los programas que no la tienen tienden a estancarse en su segundo año. El patrocinador ejecutivo, a menudo el CISO, el CIO o la dirección de riesgo, es dueño del caso de negocio y del presupuesto, y es quien puede decirle a una unidad de negocio reticente que sus owners de aplicación van a dedicar tiempo a las revisiones este trimestre. No asiste a cada reunión del foro ni aprueba decisiones sueltas. Su trabajo es mantener el programa financiado cuando pasa la presión de la primera auditoría, resolver disputas entre áreas que el foro no puede resolver y dejar claro que ser owner de una aplicación es parte del trabajo de una jefatura y no un favor a TI.

Un patrocinador que solo aparece en el arranque es casi tan malo como no tener ninguno. Una revisión trimestral breve con el patrocinador, construida sobre las métricas del foro, lo mantiene lo bastante cerca del programa como para defenderlo cuando se aprietan los presupuestos.

Quienes están fuera del equipo de IAM y también cuentan

Hay un puñado de grupos que nunca aparecen en el organigrama de IGA y que aun así deciden buena parte de lo que puede hacer el programa.

RR. HH. es dueño de los datos sobre los que corre casi todo el programa. Lo rápido que registra altas, traslados y bajas fija el piso de lo rápido que puede cambiar el acceso en esos eventos, y el artículo del modelo de datos explicó por qué una conversación con RR. HH. sobre qué campos mueven el acceso vale más que cualquier conector. Compras o la gestión de proveedores cumple el mismo papel para los contratistas, sobre todo con las fechas de fin.

La mesa de servicio suele ser donde IGA se encuentra con la gente por primera vez: responde “¿dónde está mi acceso?”, ejecuta a mano el aprovisionamiento en los sistemas sin conector y suele ser la primera en notar cuando una regla o un flujo se porta mal. Sumarla pronto al programa, y darle una forma de reportar patrones, detecta los problemas antes que cualquier tablero.

Legal y privacidad, incluida una persona delegada de protección de datos donde exista, tienen algo que decir sobre qué datos de identidad puede guardar el programa y durante cuánto tiempo. La auditoría interna, por último, prueba los mismos controles que los auditores externos, normalmente antes en el año, y es una de las aliadas más útiles que tiene un programa.

Quién está en la sala cuando Sara cambia de puesto

El artículo de JML siguió el ascenso de Sara López de analista de operaciones con clientes a líder del equipo de revisión de fraude, y la verificación de conflictos que debería evaluar su acceso viejo y el nuevo juntos antes de otorgar el nuevo. Aquel artículo describió el mecanismo. Aquí está quién participa cuando ocurre.

El evento de traslado llega desde RR. HH., y el flujo que construyó el ingeniero de IAM lo contrasta con la política de separación de funciones. Esa política la diseñó la arquitecta, y el analista de negocio la llenó con reglas de negocio reales recogidas meses antes en entrevistas con los owners de operaciones con clientes y de revisión de fraude. La verificación encuentra el conflicto: durante un tiempo, Sara podría marcar una transacción sospechosa y también despejar una alerta como falso positivo. El sistema envía la decisión a la owner de la aplicación de revisión de fraude, el lado de mayor riesgo.

La owner no decide a ciegas. Gracias al trabajo de nombres del catálogo, ve exactamente qué otorga cada lado: no dos nombres de grupo crípticos, sino “Marcar transacción sospechosa” y “Anular alerta como falso positivo”. Elige el camino más seguro. Primero se quita el acceso de Sara para anular alertas, la reconciliación confirma que ya no está y solo entonces se activa el acceso de revisión de fraude, un día más tarde de lo que habría tardado un otorgamiento sin condiciones y sin ningún momento en que el conflicto existiera.

Cumplimiento revisa el resultado después, no porque tuviera que aprobarlo en tiempo real, sino porque un conflicto documentado, una persona con nombre que decidió, una resolución concreta y una marca de tiempo que muestra que se cerró en días es exactamente lo que un auditor pedirá ver tarde o temprano. La dirección del programa nunca toca la decisión. Su única participación es notar, por los retrasos registrados en el flujo, que este tipo de conflicto entre estos dos equipos aparece tan seguido que vale la pena llevarlo al siguiente foro de gobierno como candidato a una política permanente en lugar de una decisión puntual cada vez.

Un evento, cinco de los roles de este artículo, cada uno haciendo una parte distinta, y solo uno, la owner de aplicación, tomando la decisión de fondo. Así se ven la mayoría de los eventos reales de gobierno en un programa de IGA cuando los roles tienen nombre.

flowchart LR
  accTitle: Una decisión de acceso pasa por los roles del programa y la toma el owner de aplicación
  accDescr: Un disparador, como un evento de traslado, un hallazgo de revisión o la propuesta de un entitlement nuevo, lo presenta la arquitectura o la ingeniería de IAM, con contexto de negocio del análisis. Llega al owner de aplicación, que toma la decisión. Cumplimiento y riesgo revisan las decisiones de alto riesgo y la dirección del programa sigue el resultado hasta cerrarlo, pero el juicio en sí corresponde al owner de aplicación.
  TRIG([Disparador: traslado, hallazgo<br/>de revisión o entitlement nuevo]) --> ARCH[Arquitectura o ingeniería<br/>lo presenta y aporta contexto]
  BA[Análisis de negocio<br/>contexto del proceso] --> OWNER
  ARCH --> OWNER{El owner de aplicación<br/>decide}
  OWNER -->|Alto riesgo| RISK[Cumplimiento y riesgo<br/>revisan]
  OWNER -->|Estándar| CLOSE
  RISK --> CLOSE([La dirección del programa<br/>lo sigue hasta cerrarlo])

Quién hace qué, evento por evento

La forma más clara de ver cómo interactúan los roles es contrastarlos con los eventos que describieron los artículos anteriores.

Lo importante está en las celdas en negrita. Es el owner de aplicación, no ingeniería de IAM ni la dirección del programa, quien toma las decisiones de fondo que este módulo viene describiendo desde el primer artículo. Los demás facilitan, construyen, documentan o revisan. La decisión de si un acceso concreto debe existir le corresponde a la persona con contexto de negocio, siempre.

Qué roles cubrir primero

Pocos programas pueden cubrir todos los roles el primer día, y la pregunta de quién va primero aparece en casi cualquier iniciativa de IGA nueva.

La arquitectura suele ir primero, porque casi todos los demás roles necesitan algo que ella produce: el análisis necesita un modelo de datos contra el que recoger requisitos, los owners necesitan una convención de nombres y de niveles antes de que ser owner signifique algo concreto, y la ingeniería necesita un diseño antes de tener algo que construir. Un programa que contrata capacidad de ingeniería antes que de arquitectura suele terminar con el tipo de construcción descoordinada que describió el ejemplo SaaS del artículo del catálogo: técnicamente funciona, estructuralmente no tiene coherencia.

El trabajo con los owners de aplicación tiene que empezar casi a la vez, incluso antes de que haya una plataforma que mostrarles. La parte más lenta de la mayoría de los programas es conseguir que los owners de negocio dediquen el tiempo que exigen la curaduría y las revisiones, y construir esa relación lleva meses, mucho más que cualquier componente técnico. Los programas que dejan a los owners para el final del despliegue descubren, justo cuando más los necesitan, que no están disponibles, no están convencidos o no entienden qué se les pide.

La dirección del programa y cumplimiento pueden sumarse un poco después sin frenar los primeros avances. La dirección del programa importa cuando hay suficiente coordinación entre equipos como para necesitar un calendario, y la participación más intensa de cumplimiento llega con el diseño de controles y la revisión de evidencia, que importan más cuando ya hay algo funcionando. El análisis y la ingeniería crecen con el trabajo de diseño de la arquitectura: útiles desde temprano, imprescindibles cuando hay un diseño contra el que recoger requisitos y que construir.

Cómo cambian los roles a medida que madura el programa

El equilibrio entre estos roles no es fijo. Se mueve a medida que el programa pasa de construir a operar.

El primer año el peso recae en la arquitectura y la ingeniería: el modelo de datos, los primeros conectores, el proceso de bajas, la primera revisión de un sistema crítico. Los owners de aplicación participan, pero sobre todo curando sus entitlements por primera vez, que es lo más exigente que se les va a pedir.

El segundo año el peso pasa a los owners y al análisis. Se suman más aplicaciones por oleadas, cada una con su curaduría y su owner al que hay que incorporar, y las campañas de revisión pasan de un sistema a muchos. Cumplimiento se vuelve más visible a medida que la evidencia que produce el programa empieza a usarse en auditorías reales.

Cuando el programa llega a un funcionamiento estable, buena parte del equipo de construcción se convierte en un equipo de operaciones que corre conectores, reconciliación y campañas, y el análisis se orienta a incorporar aplicaciones nuevas y mejorar los roles existentes. El foro pasa a ser el centro de gravedad. Los programas que mantienen un equipo grande de construcción mucho después de terminar de construir, o que disuelven el foro cuando la plataforma ya está en marcha, suelen perder la mitad de gobierno del ciclo sin darse cuenta. Una mirada anual a quién está haciendo qué trabajo, comparada con el elenco en el papel, es una forma barata de notar la deriva antes que una auditoría.

Cuando una persona lleva tres sombreros

Todo lo anterior describe un programa maduro con personas dedicadas a cada función. La mayoría de los programas reales, sobre todo en sus primeros dieciocho meses, no tienen eso, y fingir lo contrario produce una matriz de responsabilidades que parece rigurosa y no describe la semana real de nadie.

Un patrón habitual y viable para un equipo chico se ve así. Una persona es arquitecta e ingeniera a la vez, repartiendo el tiempo entre diseñar y construir. La dirección del programa es una tarea a tiempo parcial que se suma al trabajo de alguien, muchas veces otra vez de la arquitecta, o de un responsable de entregas prestado de otra parte de TI. El análisis se reparte entre los owners de aplicación que tengan tiempo y ganas de involucrarse a fondo, y la arquitecta cubre el hueco de los que no. Cumplimiento participa con un ritmo más liviano, una revisión mensual en lugar de una participación continua, porque un equipo de cumplimiento chico cubre a toda la organización.

Incorporar a un owner de aplicación nuevo

La mayoría de los owners de aplicación nunca pidieron serlo. Dirigen una función de negocio y un día alguien les dice que ahora son owners de cuarenta entitlements del sistema de finanzas. Cómo sale esa conversación decide si se convierten en owners comprometidos o en nombres en una hoja de cálculo.

Una incorporación corta y concreta ayuda más que un documento de política. Explícales en una página qué significa ser owner en la práctica: aprobar las solicitudes de su sistema, una campaña de revisión una o dos veces al año, decidir sobre algún conflicto de vez en cuando y una mirada anual a si sus entitlements siguen teniendo sentido. Dales una estimación del tiempo que lleva, normalmente unas pocas horas por trimestre cuando el catálogo ya está en forma, y más durante la primera curaduría. Recorre con ellos una solicitud real y un elemento de revisión real, con los entitlements de su propio sistema. Y elige con ellos un suplente el primer día, para que la titularidad sobreviva a sus vacaciones y, algún día, a su salida.

Los primeros meses son los que más importan. Un owner cuya primera revisión es una lista de 900 entradas ilegibles concluirá que ser owner es una pérdida de tiempo y actuará en consecuencia. Un owner cuya primera revisión son treinta entitlements legibles, ordenados por riesgo y con su fecha de último uso, suele salir convencido de que valió la pena.

El foro de gobierno

Los roles con responsabilidades individuales siguen necesitando un lugar donde tomar juntos las decisiones que los cruzan, en lugar de que cada owner decida por su cuenta y nadie compare notas. Un foro de gobierno, una reunión periódica, normalmente mensual, con la arquitectura, cumplimiento y riesgo, un grupo rotativo de owners de aplicación y la dirección del programa, es donde eso pasa.

Su agenda tiende a asentarse en unos pocos puntos fijos: la salud del catálogo de entitlements (titularidad, revisiones atrasadas, entitlements obsoletos que siguen asignados), las excepciones de separación de funciones abiertas y sus controles compensatorios, los huecos que encontró la reconciliación desde la reunión anterior, la tendencia de la calidad de los datos de identidad (tasas de coincidencia, huérfanas y duplicados) y cualquier aplicación cuyo owner falte o no responda. Además, aprueba cambios en los paquetes birthright, decide si una regla de conflicto propuesta es demasiado estricta o demasiado floja según cuántas excepciones genera y resuelve los desacuerdos que los owners no pueden resolver solos, como dos owners que creen que un entitlement en disputa le corresponde al sistema del otro.

Es también donde las medidas construidas a lo largo de este módulo las miran personas con autoridad para actuar sobre ellas. Un tablero que nadie revisa en una sala con poder de decisión es solo un número que nadie lee; el foro es lo que convierte la medición en gobierno.

El foro necesita derechos de decisión explícitos, o deriva en una reunión de estado en la que se comparte información y no se decide nada. Un patrón que funciona es que el foro pueda aprobar por mayoría los cambios de catálogo y de política que afectan a una sola aplicación, siempre que su owner esté de acuerdo, mientras que los cambios en la política de separación de funciones de varias aplicaciones, o en los propios criterios de clasificación por riesgo, necesitan la aprobación de cumplimiento antes de entrar en vigor. Son justo los cambios por los que preguntará un auditor más adelante, y “lo discutimos en el foro” es una respuesta más débil que “cumplimiento lo revisó y lo aprobó”.

Cómo falla el elenco

Algunos patrones se repiten, y cada uno es una forma en que el elenco se degrada en la práctica aunque todas las casillas del organigrama estén cubiertas.

La arquitecta se convierte en silencio en owner de aplicación. Con la presión de una fecha, el silencio de un owner que no responde lo llena quien ya está en la sala con acceso al sistema, normalmente la arquitecta o el ingeniero, que empieza a decidir sobre la elegibilidad para no retrasar una migración. Es peligroso justamente porque en el momento no parece un fallo. La migración termina a tiempo, y el hueco aparece meses después cuando una revisión encuentra accesos que nadie con contexto de negocio aprobó nunca.

La dirección del programa empieza a resolver disputas de política. Cuando dos owners no se ponen de acuerdo sobre a quién le corresponde un entitlement compartido o si una excepción es aceptable, quien dirige el programa, acostumbrado a resolver desacuerdos para que las cosas avancen, suele estar en la mejor posición para simplemente decidir. Es el instinto correcto para una cuestión de calendario y el equivocado para una de política. Una decisión de política tomada así no tiene revisión de cumplimiento ni otra justificación que “necesitábamos avanzar”, que es exactamente lo que preguntará un auditor.

Cumplimiento solo aparece cuando hay auditoría. Una persona de cumplimiento a la que solo se consulta cuando se acerca una auditoría termina revisando años de decisiones acumuladas de golpe y con presión, en lugar de detectar los huecos de control a medida que aparecen. Es el mismo fallo que reconciliar una vez al año, aplicado a la supervisión de cumplimiento.

Nadie es dueño del elenco mismo. Igual que un catálogo necesita a alguien que lo mantenga al día, la asignación de estos roles necesita mantenimiento: un owner de aplicación cambia de puesto, se va la arquitecta que diseñó el modelo de datos, llega una aplicación nueva sin que nadie sea nombrado su owner. Un programa que asignó los roles una vez en el arranque y no volvió a mirarlos termina con exactamente los huecos silenciosos que este artículo intenta evitar.

Qué pasa cuando un rol no tiene nombre

El fallo no es dramático. Es la misma deriva lenta que describieron los demás artículos de este módulo. Sin una arquitectura clara, el modelo de datos lo diseña por partes quien esté arreglando el conector más urgente esa semana, y las decisiones sobre las fuentes autoritativas nunca quedan escritas donde alguien nuevo pueda encontrarlas. Sin análisis, la curaduría la hacen ingenieros leyendo consolas de administración en lugar de hablar con quienes usan el acceso, y el resultado es un catálogo técnicamente exacto y en la práctica ilegible para los revisores. Sin owners comprometidos, las revisiones se convierten en el trámite de clics contra el que advirtieron los artículos del modelo de datos y del catálogo, no porque los revisores sean descuidados sino porque nunca se nombró a nadie con responsabilidad real para revisar. Y sin un foro de gobierno, cada medida que construyó este módulo se recoge con cuidado y no la lee nadie.

Medir si el elenco funciona

La señal de que estos roles funcionan no es un organigrama con todas las casillas llenas. Es si la responsabilidad que representan esas casillas se ejerce de verdad, y unas pocas medidas, revisadas en el foro, lo hacen visible.

La proporción de aplicaciones con un owner activamente involucrado muestra si ser owner es una función real o un nombre en una hoja de cálculo; si baja, normalmente significa que nadie sigue la rotación de owners para reemplazarlos. El tiempo medio que tardan los owners en resolver un hallazgo de revisión o una excepción de conflicto muestra si las decisiones llegan a tiempo; si sube, a menudo significa que los owners tienen poco tiempo o poco compromiso. La proporción de puntos del foro que terminan con una decisión registrada y un responsable con nombre muestra si el foro decide cosas o solo las conversa.

La medida más difícil de reunir es también la más útil: cuántas decisiones de acceso se toman fuera del elenco nombrado, de manera informal, por ingeniería o por la dirección del programa. Nadie registra “tomé una decisión que no me correspondía”. Hay que deducirlo, normalmente comparando quién ejecutó un cambio con quién dice la matriz de responsabilidades que debía decidirlo. Construir esa comparación, aunque sea aproximada, en lo que sea que registre los cambios de acceso es de lo más valioso que puede sumar un programa cuando estos roles ya tienen nombre, porque detecta los huecos de responsabilidad antes que una revisión o una auditoría.

Cómo se relaciona con estándares y marcos

• El IDPro Body of Knowledge trata los roles y responsabilidades de un programa de identidad como un tema propio, y describe casi el mismo elenco, arquitectura, ingeniería, titularidad de negocio y gobierno, con nombres parecidos.
• La guía de gobierno de ISACA, incluido el material alineado con COBIT, trata la asignación clara de responsabilidades, quién decide, a quién se consulta, a quién se informa, como un control básico por sí mismo, independiente de la tecnología, que es el argumento estructural de este artículo sobre la titularidad de las aplicaciones.
• NIST SP 800-53, control PS-2 (designación del riesgo de los puestos) y los controles de personal relacionados, exigen documentar las responsabilidades de los puestos que intervienen en decisiones de acceso: la versión de catálogo de controles de tener una persona con nombre y responsable detrás de cada decisión.

Cerrando este módulo

El primer artículo abrió este dominio con un ciclo: la administración ejecuta los cambios, el gobierno decide y verifica. Los artículos siguientes construyeron, pieza a pieza, lo que el gobierno necesita para hacerlo de verdad: un modelo de identidad confiable, un ciclo de vida gobernado y auditable y un catálogo curado de lo que se otorga realmente. Este artículo añade la última pieza, las personas que responden de cada mitad del ciclo. Un ciclo sin nadie asignado a la mitad de gobierno no es un ciclo. Es administración funcionando sin control al lado de un documento de política que nadie lee.

El próximo módulo pasa de esta base a los componentes core de IGA, la maquinaria para la que estos cinco artículos estaban preparando el terreno. Nada de eso funciona sin el modelo de datos, la disciplina del ciclo de vida, el catálogo o las personas que este módulo nombró. Una plataforma desplegada sobre un buen modelo de datos con un elenco débil o sin nombre produce el fallo al que este módulo volvió una y otra vez con distintos nombres: un proceso que parece completo en un tablero y no lo es, porque nadie con responsabilidad real respalda las decisiones que reporta.

Resumen

• Este artículo usa “rol” para referirse al puesto de una persona dentro del programa de IGA, distinto del sentido de paquete de entitlements que definió el artículo del catálogo. El artículo de ingeniería de roles, más adelante, junta los dos sentidos.
• La dirección del programa, la arquitectura, la ingeniería, el análisis de negocio, el owner de aplicación, cumplimiento y riesgo y seguridad tienen cada uno una responsabilidad distinta. En un programa chico varios son la misma persona, pero las responsabilidades no desaparecen.
• El owner de aplicación toma las decisiones de fondo: qué significan los entitlements, quién puede tenerlos, las excepciones de conflictos, las decisiones de revisión. Los demás facilitan, construyen o revisan alrededor.
• Ser owner de aplicación es la única responsabilidad que ingeniería no debería absorber, por chico que sea el programa.
• Cubre primero la arquitectura y empieza a trabajar con los owners casi a la vez. Un patrocinador ejecutivo mantiene el programa financiado, y RR. HH., compras, la mesa de servicio, legal y la auditoría interna lo moldean desde fuera.
• Incorpora a los owners de aplicación con una explicación concreta y acotada en tiempo y una primera revisión legible, y nombra un suplente el primer día.
• Un foro de gobierno con derechos de decisión explícitos es donde se actúa en conjunto sobre las medidas y las decisiones transversales de este módulo.

Tres preguntas para ponerte a prueba

1. Un programa chico tiene a una sola persona cubriendo la arquitectura y el análisis. ¿Qué riesgo concreto señala este artículo y cómo lo reducirías sin sumar gente?
2. Con la tabla de arriba, explica por qué es el owner de aplicación, y no el ingeniero que construyó el conector, quien decide si un conflicto en un traslado se acepta con un control compensatorio.
3. Un foro de gobierno lleva un año reuniéndose cada mes, pero los owners de aplicación casi dejaron de asistir. ¿Qué sugiere este artículo que está fallando y qué revisarías primero?

Ejercicio práctico

Piensa en una organización que conozcas y en una decisión relacionada con el acceso que haya ocurrido allí hace poco, o invéntala.

1. Nombra quién cumplió cada uno de los roles de este artículo en esa decisión, aunque una persona haya cubierto varios.
2. Identifica quién tomó realmente la decisión sobre si el acceso debía existir, y si coincide con quien debería haberla tomado.
3. Escribe la agenda del primer foro de gobierno de esa organización, con tres puntos fijos y los derechos de decisión de cada uno.
4. Anota los dos roles que cubrirías primero si empezaras mañana el programa allí, y por qué.