Notas detalladas de la sesión ABM - Madurez de la gestión de identidades
Contexto y objetivos del servicio
Objetivo principal de la sesión: entrevista con el equipo de procesos ABM para evaluar el nivel de madurez de gestión de identidades en Compartamos.
Propósito del servicio de la unidad de NTT Data: ayudar a Compartamos a realizar una evaluación de madurez, identificar brechas, generar oportunidades de mejora y desarrollar un rol para evolucionar las capacidades de gestión de identidades.
Equipo de NTT Data (presentadores):
Mijaí Muñoz, especialista de gestión de identidades.
Hans Vigil, mánager de gestión de identidades.
Alicia Lara, líder de proyecto.
Richard Vargas, responsable de información y recopilación de información.
Equipo de Compartamos (participantes):
Víctor Yuya, arquitecto de seguridad TI.
Omar García, gestor del proyecto.
Contexto del programa IA (inteligencia artificial) y marco de gobernanza de identidades:
Enfoque en un framework de gobernanza de identidades (IAM) que abarca:
Autenticación: single sign-on (SSO); autenticación multifactor (MFA).
Identidades: gestión humana, provisión y desprovición de usuarios y cuentas.
Accesos privilegiados: cuentas nominales, genéricas y de servicio.
Directorios y federación de accesos; autorizaciones y gestión de roles; perfiles; segregación de funciones.
Auditoría y cumplimiento (repostería en términos de cumplimiento); controles y monitoreo.
Áreas de cumplimiento y riesgo: SBS, normas PSI, ciberfraude, suplantación de identidad; auditoría interna y externa para alinear procesos, políticas y lineamientos.
Experiencia del colaborador: satisfacción de accesos, cumplimiento de SLA, entrega de accesos en tiempo y forma.
Data analytics y métricas: detección de cuentas huérfanas, revisión de cuentas privilegiadas y calidad de otorgamientos.
Consideraciones de ciberseguridad y marcos de referencia utilizados (p. ej., NIS).
Equipos de interacción y gobernanza: interacción entre arquitectura TI, cumplimiento/regulatorio, auditoría, y áreas de negocio para la alineación de procesos.
Observación sobre la necesidad de efficacia de la gestión de accesos y controles para las unidades de negocio y áreas críticas.
Descripción de la arquitectura de la interacción ABM (ABB) y roles de los involucrados
Arquitectura de la solución a alto nivel: TI (Infraestructura), cumplimiento regulatorio, auditoría, y áreas de negocio involucradas para la implementación de ABM.
Enfoque de cumplimiento y auditoría: SBS, PSI, ciberfraude, suplantación de identidad; revisión de procesos y políticas para asegurar alineación.
Interacciones de seguridad y TI: apoyo mutuo entre seguridad de la información y TI para revisiones de perfiles, roles y permisos.
Proceso ABM: flujo general y responsabilidades (visión de José, Infraestructura)
Alcance de Infraestructura: manejo de Active Directory (AD) como base para integración de usuarios en aplicaciones.
Proceso de altas (nuevos ingresos):
Inicio por el equipo de Personas (RRHH) reportando nuevos ingresos.
Revisión por el equipo de Infraestructura.
Uso de plantillas para definir grupos, cargos y perfiles alineados a las funciones.
Aplicación también para plataformas que no se integran con AD directamente.
En el caso de IVMI (usuarios de base de datos), manejo específico de cuentas.
Proceso de bajas:
Reportes de RRHH generan la solicitud.
Proceso parcialmente automatizado para comparar con la lista de IDs de usuarios que deben deshabilitarse.
Mecanismo automatizado descrito: una ruta/servicio ejecuta a una hora determinada la deshabilitación en AD, quitar grupos y mover a una lista de deshabilitados.
Proceso de modificaciones (cambios):
Cambios en perfil, grupo o permisos deben ir de la mano con el visto de Seguridad de la Información (VSO).
Cambios como movimientos entre puestos en agencias implican actualizar grupos y permisos.
En ciertos casos, los cambios se originan por la mesa de ayuda y se definen periodos de vigencia.
Flujo de aprobación para privilegios altos:
Solicitante (usuario final) realiza la solicitud, obtiene visto bueno y se genera un ticket para ejecución.
En casos de privilegios altos, la aprobación inicial puede provenir de Seguridad, a través de correo, salvo que el proceso ya se canalice por un ticket formal.
Seguridad emite aprobación o denegación y devuelve el ticket al equipo solicitante, quien luego coordina con Infra para la ejecución.
En la práctica, el ticket suele contener los vistos buenos y la coordinación para ejecutar la alta de privilegio.
Alcance de alto privilegio y escalamiento:
Flujo cubre tanto cuentas de dominio como cuentas de servicios, incluidas cuentas genéricas.
Para satélites o aplicaciones que no están integradas al AD, Infraestructura puede gestionar la habilitación del usuario en la AD y la aplicación/componente correspondiente.
El equipo de operaciones puede asignar permisos en la aplicación satélite tras habilitar la cuenta en AD.
Proceso de alta para cuentas de servicio o genéricas:
Solicitud inicia por el usuario o por el equipo del proyecto; seguridad revisa datos requeridos y aprueba/deniega; Infra ejecuta.
Las políticas de contraseñas y la vigencia se aplican de forma homogénea; en cuentas de servicio puede haber reglas de no expiración o vigencia ligada a contrato para externos.
Roles y revisión de perfiles en Azure vs on-prem:
MFA y contraseñas: configuración de MFA está en Azure; MFA on-prem no está habilitado.
Azure AD y Office 365 exigen MFA para acceso a aplicaciones de Office y apps configuradas en el portal de Azure.
Aplicaciones empresariales administradas desde Azure: se comparte la lista de aplicaciones y permisos con operaciones para mayor detalle.
Políticas de contraseñas y MFA (alcance y valores técnicos)
Políticas de contraseñas en AD:
Longitud de la contraseña: caracteres.
Vigencia de la contraseña: días.
Historial de contraseñas: últimas contraseñas no pueden repetirse.
Bloqueo por intentos fallidos: intentos fallidos.
Duración del bloqueo: minutos.
MFA y AD:
MFA no está habilitado en el entorno on-premise.
MFA configurado y utilizado en Azure AD para aplicaciones en la nube (Office 365 y apps conectadas en Azure).
Para aplicaciones satélite sin MFA on-prem, MFA puede requerirse a nivel de Azure/Office 365 si aplican.
Autenticación y aplicaciones:
Lista de aplicaciones empresariales y su configuración en Azure: se proporcionará la lista a solicitud; el detalle de permisos requiere involucrar al equipo de operaciones.
Cuentas de dominio, privilegios y políticas asociadas
Cuentas de dominio y privilegios altos:
Las altas de privilegios siguen el flujo descrito (solicitud -> Seguridad -> ticket -> Infra).
Las cuentas tipo genéricas o de servicio siguen el mismo marco, con consideraciones de vigencia y contratos para externos.
Seguridad se involucra para definir el perfil y confirmar si existe un rol definido; si no, se asigna un rol base y se actualiza posteriormente.
Integración con CyberArk / CyberWatch y otros sistemas:
En el caso de servidores, hay interacción con CyberWatch para registrar nuevos equipos; para usuarios no se utiliza CyberArk de forma directa según lo discutido.
CyberArk es relevante principalmente para la gestión de accesos a servidores; para usuarios, la gestión se realiza principalmente a través de AD y Azure AD.
Integraciones y alcance de los sistemas críticos:
Algunos sistemas satélites requieren que la cuenta esté habilitada en AD y luego completan permisos dentro de la aplicación correspondiente (no todo pasa por AD).
Seguridad de TI valida los perfiles de roles y permisos para cada plataforma; el equipo de Infra lo implementa cuando corresponde.
Auditoría, controles y trazabilidad
Logging y auditoría:
Existe una herramienta de auditoría de AD (ad audit) que registra creación, modificación y eliminación de cuentas.
Debate sobre centralización: posibilidad de centralizar en una plataforma común (p. ej., AD Audit vs. otra solución) para trazabilidad; se mantiene actualmente doble fuente (AD Audit y otra herramienta de auditoría interna).
Recertificación y revisiones periódicas:
Seguridad de la Información y Seguridad TI manejan recertificación de usuarios y revisiones de accesos.
Las revisiones de cuentas huérfanas se realizan periódicamente; se verifica el uso y propiedad de cada cuenta con el dueño correspondiente.
En general, Seguridad envía reportes y se mantiene trazabilidad mediante tickets para evidenciar acciones de retirada o actualización de accesos.
Cuentas huérfanas y deshabilitación:
Proceso de cuentas huérfanas: se reporta a BD y se valida con el uso; si procede, se deshabilita o se retiran privilegios.
Métricas y reportes:
Reportes periódicos o por necesidad de seguridad (observaciones de baja de inactividad, cuentas desactivadas, revisiones de privilegios).
Generación de reportes de accesos y privilegios a partir de correos/alertas que disparan acciones.
Automatización, herramientas y entorno tecnológico
Arquitectura y herramientas actuales:
Active Directory como base para gestión de usuarios; scripts y plantillas para carga de altas y perfiles.
Azure AD para MFA y gestión de identidades en la nube; administración de portal de Azure para aplicaciones empresariales.
Adicional: ad audit para auditoría; posibilidad de centralización hacia una herramienta única (pendiente evaluación).
Interacciones operativas y escalamiento:
Comunicación para solicitudes de alta de privilegios (correo y ticketing); Security revisa y aprueba/deniega; Infra ejecuta.
Gobierno de cambios y plantillas: se emplean plantillas para la asignación de grupos y perfiles por cargo; cuando no existe un rol definido, Security revisa y define el perfil base.
Seguridad y operaciones:
Seguridad de la Información y Seguridad TI participan en la definición de roles, permisos y su correspondencia con las plataformas.
Equipo de Infraestructura (6 integrantes aproximadamente: 1 jefe, 2 consultores C3 con especialidad Power y 4 consultores C2; la estructura exacta puede variar) y el equipo de operaciones para habilitación en satélites y aplicaciones.
Comunicación y gobernanza entre equipos:
Interacciones con el equipo de CyberWatch para la gestión de servidores; para usuarios, CyberWatch no participa directamente.
Los cambios críticos pueden ser escalados por seguridad o por la gerencia para priorización.
Puestas en práctica: ejemplos y escenarios discutidos
Escenario de alta de privilegios en AD:
El solicitante envía la solicitud; Seguridad valida y aprueba; se genera un ticket; Infra ejecuta la activación de privilegios y actualiza grupos/permisos.
Escenario de alta para satélites/no integradas a AD:
Infra gestiona alta en AD; operaciones asigna permisos en la aplicación satélite correspondiente; la gestión de permisos en la aplicación la realiza la mesa de operaciones.
Escenario de baja: automatizado con fuente de RRHH y herramientas de base de datos para deshabilitar cuentas y eliminar accesos en AD.
Manejo de cuentas de servicio y cuentas genéricas:
Revisión por Seguridad, con requisitos de datos, aprobación y ejecución similar al proceso de cuentas de usuario; vigencia depende de contrato para externos.
Proceso de cierre y próximos pasos
Se acordó compartir listado de aplicaciones con accesos y permisos (a través de Omar) para complementar los puntos discutidos.
Se enviará una minuta de la sesión y una PPT con los puntos discutidos y las conclusiones.
Contactos/fuentes de información para follow-up: Omar, Víctor y Marcelo; se clarificarán detalles mediante su apoyo.
Observaciones finales: medir la madurez de ABM requiere consolidar herramientas de auditoría, centralizar la gobernanza y formalizar procesos de alta/baja/modificación con trazabilidad clara y ejecución automatizada cuando sea posible.
Notas técnicas y referencias numéricas (resumen rápido)
Contraseña: longitud , vigencia días, historial de contraseñas , bloqueo tras intentos, bloqueo por minutos.
Integración MFA: presente en Azure AD para aplicaciones en la nube; no habilitado on-premise.
Estructura de equipo Infra: jefe, consultores C3, consultores C2 (aproximado; la conversación indicó 6-7 personas según momento).
Flujo de alta de privilegios: solicitud -> Seguridad -> ticket -> Infra; adjuntos de aprobación via correo cuando corresponde.
Cuenta de servicio externa: vigencia ligada a contrato; algunas cuentas de servicio pueden no expirar (según política de seguridad y contrato).
Cuentas huérfanas y auditoría: revisión periódica; uso y propiedad verificados; deshabilitación/retirada de accesos mediante procesos automatizados y/o tickets.
Conclusión
El modelo actual de ABM en Compartamos con NTT Data combina AD en on-premise, Azure AD en la nube y controles de seguridad para gestionar altas/bajas/modificaciones de usuarios y privilegios.
Existe una base sólida de gobernanza, con roles y aprobaciones claras, aunque hay oportunidades de consolidar herramientas de auditoría y estandarizar procesos para acelerar respuestas ante incidentes o cambios de negocio.
Se requieren acciones de seguimiento para obtener la lista de aplicaciones y permisos detallados, y para formalizar los plazos y responsabilidades de revisiones periódicas.