Notas de Gestión de Autorizaciones y Accesos en Sistemas Empresariales

Autorización y Acceso

• Autorización: Define los permisos de una persona mediante un rol o perfil una vez ha sido validada. Esto asegura el acceso correcto a los sistemas.

• Equipos que interactúan: Incluyen soluciones estándar, cumplimiento de regulaciones (ej. SBS), prevención de suplantación de programadores, análisis de datos, métricas y gestión de cuentas privilegiadas no identificadas.

• Gestión de Acceso con Active Directory (AD):

  • El acceso se sincroniza con el AD. Los permisos en AD otorgan acceso a sistemas integrados.

  • Ejemplo: Si un usuario es "líder" en AD, tendrá el mismo permiso en sistemas como Bantota, Calpa (un sistema de negocios) y Sefis.

  • Sistemas de sincronización automática: Bantota, Sefis y Calpa se sincronizan automáticamente con AD. Una promoción de puesto se reflejará automáticamente en estos tres sistemas.

  • Sistemas con ajustes manuales: Para otros sistemas (ej. Extranet o herramientas no sincronizadas), los accesos deben gestionarse manualmente. Un usuario debe generar un ticket para solicitar el permiso si no se actualiza automáticamente.

Matriz de Roles de Acceso

• Existe una "matriz de roles de acceso" publicada. Es gestionada por el área de Seguridad de la Información, quienes la crearon y se encargan de su actualización.

• Los accesos se otorgan basándose en esta matriz. Las solicitudes se realizan a través de un ticket generado en una herramienta específica.

• Si una solicitud de acceso se encuentra en la matriz, se considera autorizada por Seguridad de la Información.

• Si una solicitud de acceso no está en la matriz, se requiere validación y autorización de Seguridad de la Información para otorgar el permiso (sea temporal, permanente o por licenciamiento).

Soporte y Gestión de Tickets

• Todas las peticiones o incidencias deben registrarse a través del sistema de tickets.

• Este sistema centraliza el soporte de "primer nivel" ($helpdesk$), pero la persona que atiende las solicitudes puede variar.

• Alcance de aplicaciones soportadas:

  • Las que generan más tickets son: Bantota, Sefis, Calpa (plataforma de cobranzas), Oracle (para viáticos y transmisiones), Extranet y plataformas SBS.

  • Otras herramientas menos recurrentes se gestionan por otras vías si no están en el alcance principal del equipo.

• Excepciones y Escalados de Seguridad:

  • Si un acceso no está en la matriz o requiere una "zona caliente", siempre se debe consultar a Seguridad de la Información.

  • Si el usuario no lo sabe, el equipo de soporte le indicará que contacte a Seguridad.

Desbloqueo de Cuentas (Autoservicio)

• Existe un servicio de autoservicio para el desbloqueo de cuentas accesible a través de una web, la laptop o una aplicación móvil.

• Según la gerencia, esta herramienta será reemplazada por una nueva para mejorar la autogestión de usuarios.

• El objetivo es promover el uso de estas herramientas para reducir la carga de trabajo del soporte.

• Un área externa ('Atento') proporciona soporte de "nivel 0" para usuarios que no pueden autogestionarse.

Retrasos en las Actualizaciones de Perfiles (Power BI)

• Problema: Los reportes de Power BI no se actualizan en tiempo real.

• Causa: Se alimentan de una base de datos espejo del área de datos, la cual está actualizada a "$D-1$" (el día anterior).

• Implicación: Si un usuario cambia de perfil hoy, su acceso a los reportes de Power BI no será inmediato, sino que se actualizará al día siguiente después de que la base de datos espejo refleje el nuevo perfil.

Procedimientos e Instructivos

• Existen instructivos compartidos con el equipo de 'Atento'.

• Se dispone de bases de conocimiento para la autogestión de los usuarios.

• Se reconoce que puede haber una falta de procedimientos formales "paso a paso" para todas las tareas.

Capacitaciones y Monitoreo de Seguridad

• Capacitaciones: Se imparten cursos periódicos de seguridad (ej. a través de Udemy) para todos los empleados.

• Monitoreo: El área de Seguridad de la Información realiza sus propios controles y cuenta con una extensa lista de ellos.

• Reportes de Contraseñas Débiles:

  • Seguridad emite reportes (aparentemente mensuales) sobre contraseñas débiles.

  • Cuando se detecta una contraseña débil, el equipo de soporte la cambia, forzando al usuario a establecer una nueva contraseña en su próxima sesión. Esta es la principal notificación de seguridad que reciben.

Acuerdos de Nivel de Servicio (SLAs)

• Solicitudes: Existen SLAs específicos para cada categoría de solicitud, con tiempos de atención que varían (ej. $1$ o $2$ horas).

• Incidentes: Los SLAs se basan en el impacto y la urgencia, con tiempos de resolución que pueden ir desde $2$ horas hasta $8$ días.

• Encuestas de Satisfacción (NPS):

  • El NPS se mide principalmente para la atención de incidentes, aunque también se registran solicitudes para la medición.

  • Mecanismo: Al día siguiente del cierre de tickets resueltos, una herramienta de operaciones envía encuestas vía WhatsApp a los usuarios.

  • Un reporte de Power BI actualiza estas encuestas al mediodía.

Manejo de Solicitudes de Accesos Temporales

• Problemática: Existe una alta demanda de solicitudes de accesos temporales, especialmente por parte de las agencias.

• Sistema: Se utiliza un sistema corporativo ($GIRA$) con un formulario donde las agencias solicitan cambios de perfil temporales por un máximo de $30$ días.

• Motivos: Cobertura de encargaturas, vacaciones o adaptación a la demanda operativa de las agencias (ej., un empleado podría ser especialista de atención un día y cajero al siguiente).

• Proceso:

  1. La agencia ingresa la solicitud a través de Recursos Humanos.

  2. La solicitud llega a un programa que el equipo de soporte procesa.

  3. El equipo cambia el estado de "solicitado" a "atendido".

• Bloqueante Principal: La "caja de colaborador" (sesión de transacciones del usuario) debe estar cerrada para que el cambio de perfil se aplique. Si está activa, el sistema lo bloquea.

• Impacto: Este bloqueo impide que el cambio de perfil se complete al $100\%$, afectando la operación del usuario.

• Origen del problema: Este sistema existe desde, al menos, $2017$. A pesar de mejoras (ej., el límite de $30$ días en lugar de permanente), el bloqueo por caja abierta persiste.

• Esfuerzos de mejora: Se ha conversado con Operaciones y T&I para mejorar el proceso, ya que es manual, repetitivo y no agrega valor.

• Causa de la demora: El proceso no es automático; implica ingresar al programa, marcar como "atendido" y guardar. Durante este lapso, si la caja se abre de nuevo, el cambio no se aplica inmediatamente.

• Picos de demanda: A finales y principios de cada mes, debido a que los accesos temporales son por $30$ días y se gestionan con fecha de inicio "$00:00$" (medianoche).

• Solución temporal: Colaboración con Billy e Inés (operadores de cierre) para que atiendan las solicitudes a medianoche, cuando las cajas deberían estar cerradas, asegurando que los usuarios cuenten con los perfiles "listos" al día siguiente.

• Volumen: Se han registrado hasta $150$ solicitudes pendientes por día, afectando a más de $120$ agencias.

• Mensaje de error común: Si la caja está abierta, no se puede atender la solicitud. Este problema no está relacionado con la matriz de roles, sino con el estado operativo del usuario.

Sincronización Bantota - Seguridad - Matriz (Caso Específico)

• Problema: Un escenario específico surge si el perfil de un usuario no debería tener acceso a Bantota según Seguridad, incluso si la matriz general de roles lo permite.

• Detección: Tras una revisión de seguridad, se determinó que si un perfil no tiene acceso a Bantota, tampoco debe tener un usuario creado en Bantota, ya que esto podría considerarse una "puerta abierta" de acceso.

• Bloqueo: Dado que el sistema de acceso temporal está sincronizado con Bantota, si el puesto solicitado no figura en la matriz de roles y seguridad de Bantota, el sistema bloqueará la solicitud, incluso si la matriz de roles general lo permitiría para otros sistemas no integrados.

• Roles afectados: Esto afecta roles específicos como analistas de comunicaciones, marketing o producto, cuyos roles periféricos podrían no estar contemplados en la estricta matriz de Bantota. En las agencias, se espera que los roles sí estén incluidos.

Derivación de Tickets no Competencia del Área

• Problema: Anteriormente, el equipo recibía tickets que no eran de su competencia, lo que saturaba su bandeja de entrada.

• Ejemplo: Solicitudes de cambio de clave de AD. Existe un servicio de autoservicio (vía correo electrónico con un enlace) para esto, pero los usuarios a menudo no lo utilizan.

• Solución: Se ha derivado la atención de estos casos a un equipo de 'Atento' para que gestionen la mayoría, liberando al equipo principal.

Bajas y Modificaciones de Acceso

• Proceso: Cuando un usuario es dado de baja o su perfil se modifica, el equipo recibe un correo (ej. de RRHH) detallando al usuario y todas sus herramientas de acceso.

• Acción: El equipo de soporte accede manualmente a cada herramienta dentro de su alcance (ej. Bantota, Sefis) y desactiva al usuario. Este proceso es manual y específico para cada herramienta.

• Monitoreo/Revalidación:

  • No existe un monitoreo o revalidación periódica formal para asegurar que las bajas se hayan aplicado en todas las aplicaciones.

  • Incidente Pasado: Una incidencia detectada por "Ventanilla" (no por Seguridad directamente) reveló que usuarios tenían roles incorrectos en la plataforma SAC (cobranzas) en comparación con la matriz. Esto ocurrió por la falta de actualización manual de perfiles tras una promoción.

  • Conclusión: Se determinó que el equipo principal es responsable de autorizar y gestionar estos accesos.

• Acceso Principal: Si un usuario desea acceder a los sistemas principales sincronizados (Bantota, Sefis, Calpa), AD les otorga el "acceso principal". Para cualquier otro acceso, deben solicitarlo mediante un ticket. Es decir, los equipos, los jefes deben solicitar los accesos de las personas a su cargo.

• Dependencia: Calpa funciona como una "máscara" para la información de Bantota, lo que implica que deben estar sincronizados. El disparador para la aplicación de accesos parece ser CEPIS.

• Doble acción manual: Para accesos como los de Bantota y Calpa, es necesario realizar el ajuste manual en ambos sistemas. No existe un programa de acceso unificado que gestione ambos.