2 Definición de Roles y Accesos
La gestión de usuarios y roles constituye la base de la seguridad en cualquier institución financiera. Definir quién accede, a qué recursos y bajo qué condiciones, determina en gran medida la capacidad de la organización para prevenir accesos indebidos, fraudes internos y ataques cibernéticos.En el sector financiero, la correcta administración de identidades y privilegios es un requisito regulatorio y de cumplimiento normativo, además de ser un pilar para la protección de datos sensibles y operaciones críticas.
Diversas normativas internacionales refuerzan esta necesidad, entre las cuales se destacan:
ISO/IEC 27001 (control de accesos).
ISO/IEC 27701 (privacidad y datos personales).
PCI DSS v4.0 (protección de datos de tarjetas).
marcos como NIST CSF y CIS Controls.
A nivel nacional
- la Ley Orgánica de Protección de Datos Personales (LOPDP) la cuál exige medidas proporcionales para garantizar que solo personal autorizado acceda a la información personal de clientes.
Esta unidad proporciona lineamientos detallados sobre cómo estructurar, gestionar y controlar los roles de usuario, desde el cajero bancario hasta el analista de seguridad en un SOC, incluyendo personal externo y proveedores
En el sector financiero, la correcta definición y gestión de roles y accesos es vital para proteger la información sensible de clientes, transacciones y operaciones internas.
El objetivo de esta unidad es establecer cómo se definen, asignan, revisan y revocan los accesos a sistemas y datos bajo los principios de Mínimo Privilegio y Confianza Cero (Zero Trust).
Nota:
- Mínimo privilegio: cada persona recibe solo lo necesario para cumplir su trabajo.
- Confianza Cero (Zero Trust): no se confía por defecto en ningún usuario, dispositivo o red, siempre se valida la identidad y el contexto.
Aplica a: usuarios internos, terceros, cuentas de servicio, sistemas críticos (core bancario, pagos, tesorería), infraestructura tecnológica (Active Directory, firewalls, switches), y herramientas de monitoreo (SIEM, EDR/XDR).
2.1 Principios a considerar para la creación de roles y accesos
- Mínimo privilegio: cada identidad recibe solo los permisos estrictamente necesarios para su función.
- Confianza cero: verificar de forma continua identidad, dispositivo y contexto antes de conceder acceso.
- Separación de funciones (SoD): ninguna persona controla extremo a extremo un proceso crítico (p.ej., creación y aprobación de pagos).
- Trazabilidad: toda acción relevante debe ser registrable y atribuible.
- Temporalidad: accesos privilegiados con caducidad y justificación.
- Automatización: preferencia por RBAC/grupos y flujos automáticos de alta/cambio/baja (JML).
2.1.1 Gobernanza y responsabilidades de los roles (RACI)
R: Responsable (ejecuta) · A: Aprobador final · C: Consultado · I: Informado.
| Actividad | Seguridad (CISO) | TI/IdP | Dueño de Activo | Talento Humano | Auditoría |
|---|---|---|---|---|---|
| Definir/actualizar roles | R | C | A | C | I |
| Aprobar acceso a sistemas críticos | C | C | A | I | I |
| Provisionar/desprovisionar (IdP/AD) | C | R | I | C | I |
| Recertificación de accesos | A | R | C | I | C |
| Gestión cuentas privilegiadas/PAM | A | R | I | I | C |
| Gestión de terceros | A | R | C | R | I |
Un IdP (Identity Provider, Proveedor de Identidad) es el sistema o servicio encargado de gestionar identidades digitales dentro de una organización.
Su función principal es autenticar a los usuarios (verificar que son quienes dicen ser) y emitir credenciales o tokens que les permiten acceder a aplicaciones, sistemas o datos.
Ejemplo explicativo - Definir/actualizar roles: el área de TI puede proponer un nuevo rol (ej. Analista de Fraudes), pero Talento Humano valida que el perfil existe en la organización y el Dueño del Activo aprueba qué accesos lleva.
- Provisionar/desprovisionar: si un empleado entra a la organización, Talento Humano notifica a TI, que crea el usuario en el IdP. Si ese empleado sale, TI deshabilita la cuenta en un plazo máximo de 1 hora.
- Gestión de terceros: si entra un proveedor, Seguridad aprueba el nivel de acceso, TI lo crea en el sistema, y Talento Humano confirma contrato y vigencia.
2.1.2 Modelo de roles (RBAC) y atributos (ABAC)
¿Qué es RBAC?
RBAC (Role-Based Access Control, Control de Acceso Basado en Roles) es un modelo donde los permisos no se asignan a cada usuario directamente, sino a roles predefinidos.
Luego, los usuarios reciben esos roles de acuerdo a su puesto o función.
Características:
Simplifica la administración de accesos.
Roles alineados con puestos de trabajo (ej. Cajero, Analista de Finanzas, Administrador de Infraestructura).
Evita la asignación individual de permisos.
Facilita auditorías: se revisan roles en lugar de miles de permisos individuales.
Ejemplo:
Un Analista de Finanzas tiene permisos para crear órdenes de pago en el ERP, pero no para aprobarlas. Si otro empleado entra al mismo puesto, se le asigna el rol y hereda los mismos accesos automáticamente.
¿Qué es ABAC?
ABAC (Attribute-Based Access Control, Control de Acceso Basado en Atributos) es un modelo más dinámico que usa atributos (del usuario, del recurso o del contexto) para decidir si se permite o no el acceso.
Características:
Usa reglas lógicas basadas en atributos.
Permite decisiones más granulares que RBAC
Se adapta a condiciones contextuales (hora, ubicación, nivel de riesgo del dispositivo)
Ejemplos:
Un empleado de Tesorería puede aprobar pagos solo en horario laboral (08h00–19h00) y desde la red corporativa
Si intenta aprobar un pago a las 23h00 desde su casa → el IdP aplica ABAC y bloquea el acceso o pide MFA adicional.
2.1.2.1 Catálogo de roles (ejemplo)
| Rol | Descripción | Grupo/IdP | Sistemas | Permisos clave |
|---|---|---|---|---|
| Empleado-Operativo | Operaciones diarias | grp_emp_oper | Core, CRM | Consulta/alta tickets, no borra |
| Analista-Finanzas | Contabilidad y tesorería | grp_fin_analyst | ERP, Pagos | Crea órdenes, no aprueba |
| Aprobador-Pagos | Nivel de aprobación | grp_pay_approver | Pagos | Aprueba hasta $10k |
| Admin-Infra | Infraestructura limitada | grp_admin_infra | AD, VMWare | Admin por segmento |
| Lector-Auditor | Solo lectura auditoría | grp_audit_read | SIEM, ERP | Exportar reportes |
Ejemplo narrativo
Un Analista-Finanzas puede crear órdenes de pago en el ERP, pero no aprobarlas. La aprobación corresponde a un Aprobador-Pagos. De esta forma, se cumple la separación de funciones (SoD): nadie controla el proceso completo de creación y aprobación.
Reglas ABAC (ejemplo)
- Atributos comunes:
departamento,ubicación,nivel_riesgo_dispositivo,horario_laboral. - Política: “Usuarios del departamento Pagos, conectados desde dispositivos corporativos seguros y en horario 08:00–19:00 (Ecuador), pueden aprobar hasta $10k. Fuera de ese horario se exige MFA reforzado y segunda aprobación.”
2.2 Separación de funciones (SoD)
La Separación de Funciones (SoD) es un principio de control interno que busca evitar que una sola persona tenga control completo sobre un proceso crítico.
Se aplica especialmente en el sector financiero, donde el riesgo de fraude interno o errores no detectados es alto.
Objetivo principal: reducir la probabilidad de fraudes, abusos de privilegios o errores al dividir las tareas críticas entre múltiples roles independientes.
Ejemplo:
Gestión de usuarios en Active Directory (IdP):
Talento Humano comunica el alta/baja de personal.
TI crea o elimina la cuenta.
Auditoría revisa periódicamente que los accesos sean correctos.
De este modo, TI no puede crear usuarios sin autorización y Auditoría detecta cuentas indebidas.
2.3 Proceso JML (Joiner–Mover–Leaver)
El proceso JML es un marco para gestionar de manera segura el ciclo de vida de las identidades dentro de una organización.
El nombre proviene de las siglas en inglés:
- Joiner (alta): cuando entra un nuevo empleado, Talento Humano activa el proceso → TI crea la cuenta en el IdP → Seguridad asigna el rol mínimo necesario.
- Mover (cambio de rol): si un Analista pasa a Jefe, se retiran los permisos de Analista y se asignan los nuevos; nunca deben coexistir.
- Leaver (baja): cuando un usuario sale de la organización o termina su contrato. Su cuenta debe ser deshabilitada de inmediato para evitar accesos indebidos.
2.4 Acceso a Recursos y Puertos
La correcta gestión de accesos a protocolos y servicios es un control esencial exigido en normativas como PCI DSS v4.0 (Req. 7 y 1.2.6), ISO/IEC 27001 (A.9.1.2), y buenas prácticas como CIS Control 6 y NIST CSF. La asignación de servicios debe basarse en el rol del usuario y en el principio de mínimo privilegio.
Esto asegura que cada rol tenga visibilidad únicamente de lo que necesita, evitando ataques de pivoting, fuga de información y accesos no autorizados.
A continuación, se presenta una tabla de referencia con protocolos y servicios más comunes, indicando cuándo deben estar permitidos, cuándo deben bloquearse y cuál es la justificación:
2.4.1 Tabla de Accesos Permitidos y Denegados
| Protocolo / Servicio | Acceso Permitido | Acceso Denegado | Justificación / Riesgo Asociado |
|---|---|---|---|
| HTTP (80) | Solo para redirección automática a HTTPS y en servidores públicos en DMZ | Denegado en endpoints internos | El tráfico en claro expone credenciales y datos sensibles a sniffing. |
| HTTPS (443) | Acceso a portales internos, core bancario y servicios autorizados | Denegado a sitios no relacionados con la operación (ej. redes sociales, streaming) | Cifrado robusto para transacciones; bloqueo reduce riesgos de fuga de información. |
| SMTP (25/587) | Solo servidores de correo autorizados en DMZ | Denegado en endpoints de usuarios finales | Evita que equipos comprometidos actúen como spammers o botnets. |
| IMAP/POP3 (143/110/993/995) | Solo clientes corporativos con TLS habilitado | Denegado en usuarios no autorizados | Acceso controlado a buzones institucionales; bloqueo evita filtración de correos. |
| DNS (53) | Permitido solo hacia servidores DNS corporativos | Denegado hacia DNS externos (Google, OpenDNS, etc.) | DNS Filtering protege contra spoofing y phishing. |
| RDP (3389) | Permitido únicamente a administradores desde redes de gestión seguras con MFA | Denegado en usuarios finales | RDP expuesto es vector común de ransomware y fuerza bruta. |
| SSH (22) | Permitido solo a administradores mediante llaves/certificados desde redes de TI | Denegado en usuarios comunes | Autenticación por password en SSH es altamente vulnerable. |
| FTP/SFTP (21/22) | Permitido únicamente en servidores de transferencia seguros, con logging | Denegado en endpoints de usuarios | FTP en claro es inseguro; incluso SFTP debe restringirse para evitar exfiltración. |
| Base de datos (1433 – SQL Server, 1521 – Oracle, 3306 – MySQL, etc.) | Solo conexiones entre aplicaciones autorizadas y BD en segmentos internos | Denegado en endpoints de usuarios y en redes abiertas | Usuarios no deben acceder directamente a bases de datos; toda consulta debe ir vía aplicaciones o APIs. |
| ICMP (Ping) | Permitido únicamente para monitoreo desde herramientas de red autorizadas | Denegado en usuarios finales | ICMP puede usarse para reconocimiento y túneles encubiertos. |
| Telnet (23) | No permitido en ningún caso | Totalmente bloqueado | Protocolo obsoleto, transmite credenciales en claro. |
| SNMP v1/v2 | No permitido, reemplazado por SNMPv3 con autenticación y cifrado | Totalmente bloqueado | Versión insegura, expone información sensible de red. |
| Servicios web/API | Acceso limitado por rol, autenticación fuerte (OAuth2, mTLS) | Bloqueo de accesos externos no autorizados | APIs son puntos críticos de integración; deben estar en DMZ y protegidas por WAF/API Gateway. |
| Acceso a dominios | Dominios institucionales, proveedores financieros, sitios de soporte autorizado | Redes sociales, pornografía, descargas P2P, streaming, sitios de juegos | Bloqueo evita pérdida de productividad, malware y fuga de datos. |
2.5 Aspectos Legales en la Gestión de Usuarios
En el sector financiero, la gestión de usuarios no es únicamente un asunto técnico: tiene un fuerte componente legal y contractual. Cada acceso asignado a un empleado, proveedor o externo implica una responsabilidad jurídica para la institución, ya que involucra el tratamiento de datos personales, financieros y transaccionales.
2.5.1 Fundamento Normativo
Ley Orgánica de Protección de Datos Personales (LOPDP – Ecuador, 2021): exige que todo tratamiento de datos tenga base legal, finalidad legítima, consentimiento informado y medidas de seguridad proporcionales.
ISO/IEC 27001 (A.9 – Control de Acceso): establece que los accesos deben ser autorizados formalmente, revisados periódicamente y retirados cuando ya no son necesarios.
PCI DSS v4.0 (Requisito 7): obliga a restringir el acceso a sistemas y datos de tarjetas únicamente a personas que lo requieran por funciones laborales.
NIST CSF – Protect (PR.AC): destaca la importancia de gestionar identidades y credenciales con trazabilidad.
2.5.2 Obligaciones para Usuarios Internos
Todo contrato laboral debe contener cláusulas de:
Confidencialidad, asegurando que el empleado no divulgará información sensible obtenida durante su labor.
Uso aceptable de recursos, especificando que los sistemas, correos y dispositivos corporativos pueden ser monitoreados y auditados.
Aceptación de pruebas de seguridad, indicando que las cuentas de usuario pueden ser incluidas en auditorías técnicas, pruebas de pentesting o ejercicios de red team, siempre bajo protocolos internos controlados.
Debe existir un registro documental de accesos asignados a cada usuario, con evidencia de su autorización.
El incumplimiento de las políticas de seguridad debe estar tipificado como falta disciplinaria, con sanciones claras.
2.5.3 Obligaciones para Proveedores y Externos
Los proveedores con acceso a sistemas financieros deben firmar:
Acuerdos de confidencialidad (NDA).
Contratos con cláusulas de seguridad, que definan alcance, duración y tipo de accesos autorizados.
Compromisos de auditoría y supervisión, permitiendo a la institución revisar logs y monitorear sus actividades.
Todo acceso de terceros debe ser temporal, controlado y registrado, evitando cuentas permanentes o genéricas.
2.5.4 Riesgos Legales sin Control
La falta de medidas legales y contractuales adecuadas puede derivar en:
Demandas de empleados si consideran que su privacidad fue vulnerada durante una prueba de seguridad.
Multas de la Autoridad de Protección de Datos si se evidencia tratamiento indebido de información personal.
Responsabilidad solidaria frente a clientes si un proveedor externo comete fraude utilizando credenciales autorizadas.
Pérdida de trazabilidad en caso de auditorías externas, dificultando demostrar cumplimiento regulatorio.
2.5.5 Tabla de Referencia – Aspectos Legales en la Gestión de Usuarios
| Situación | Medida Legal/Contractual | Normativa de Referencia | Riesgo si no se aplica |
|---|---|---|---|
| Empleados acceden a datos personales | Contrato con cláusula de confidencialidad y uso aceptable | LOPDP – Art. 9, ISO/IEC 27001 A.9 | Posible divulgación de información sensible; sanciones legales. |
| Inclusión de usuarios en pruebas de seguridad | Cláusula contractual de aceptación de auditorías y pentesting | LOPDP – Principio de consentimiento informado | Demandas por vulneración de derechos de privacidad. |
| Acceso de proveedores externos | NDA + contrato con cláusulas de seguridad, cuentas temporales | ISO/IEC 27036-3, PCI DSS Req. 12.8 | Riesgo de fraude o fuga de datos por terceros. |
| Cuentas inactivas o huérfanas | Procedimiento documentado de baja de accesos | ISO/IEC 27001 A.9.2.6 | Uso indebido de cuentas olvidadas para intrusión. |
| Auditoría de accesos | Registro formal de autorizaciones y revisiones periódicas | NIST CSF PR.AC, PCI DSS Req. 10 | Imposibilidad de demostrar cumplimiento en caso de incidente. |
2.6 Aspectos Legales en Pentesting y Auditorías de Seguridad
Las pruebas de seguridad son necesarias para validar la robustez de la infraestructura financiera frente a ataques reales, pero su ejecución sin un marco legal adecuado puede implicar responsabilidades para la institución. Por ello, deben regularse mediante documentación formal, aprobaciones internas y contratos específicos con los proveedores o equipos internos que las realicen.
Elementos clave a considerar:
Scope of Work (SOW):
- Documento que define claramente el alcance de la prueba, qué sistemas serán evaluados, qué técnicas están permitidas (ej. pruebas de fuerza bruta controlada, inyección SQL, explotación de vulnerabilidades), y qué entornos quedan fuera (ej. sistemas en producción que contengan datos sensibles si no hay autorización explícita).
- Debe estar firmado por la institución y por el proveedor o equipo interno de pentesting.
Limitaciones y exclusiones:
Se deben establecer límites técnicos claros para proteger los servicios críticos (ej. cajeros automáticos en producción, sistemas core bancarios).
En caso de necesitar pruebas sobre sistemas productivos, deben realizarse en ventanas controladas y con planes de contingencia.
Confidencialidad:
Todo hallazgo pertenece exclusivamente a la institución financiera.
El equipo de pentesting debe firmar un Acuerdo de Confidencialidad (NDA) que prohíba divulgar, usar o compartir la información detectada fuera del contrato.
Protección de usuarios y clientes:
Las pruebas no deben exponer datos personales reales de empleados o clientes sin consentimiento explícito, en cumplimiento de la LOPDP.
Si se utilizan cuentas de usuarios reales, estos deben ser informados previamente en la política contractual de la institución.
Responsabilidad y seguros:
El contrato debe especificar responsabilidades en caso de daño accidental a la infraestructura o interrupción del servicio.
Algunos proveedores deben contar con seguros de responsabilidad civil en ciberseguridad.
2.6.1 Tabla de Referencia – Aspectos Legales en Pentesting
| Elemento Legal | Descripción | Normativa de Referencia | Riesgo si no se aplica |
|---|---|---|---|
| Scope of Work (SOW) | Documento firmado con alcance, técnicas permitidas y exclusiones | ISO/IEC 27001 A.18.2.3, Buenas prácticas OWASP | Pruebas mal definidas que afecten sistemas críticos en producción |
| NDA firmado | Garantiza la confidencialidad de hallazgos y datos accedidos | LOPDP Ecuador, ISO/IEC 27701 | Filtración de vulnerabilidades o datos a terceros |
| Limitaciones técnicas | Definición de qué no se debe tocar (ej. core bancario en horario productivo) | NIST CSF PR.IP-12 | Interrupción de servicios críticos por pruebas invasivas |
| Protección de usuarios | Consentimiento contractual para incluir cuentas reales en pruebas | LOPDP – Principio de consentimiento informado | Demandas de empleados o clientes por vulneración de privacidad |
| Responsabilidad civil | Contrato establece responsabilidades y seguros de proveedor | Directrices Superintendencia de Bancos | Institución asume sola los daños ocasionados en pruebas |
2.7 Resumen
2.7.1 Checklist de Verificación y Riesgos Asociados
| Control a Verificar | Descripción / Evidencia Requerida | Responsable | Riesgo si no se cumple |
|---|---|---|---|
| Principio de mínimo privilegio aplicado | Cada rol tiene definidos únicamente los accesos indispensables. Matriz de accesos actualizada. | Seguridad / TI | Privilegios excesivos que permiten abuso interno o explotación de cuentas comprometidas. |
| Zero Trust implementado en accesos | Accesos validados siempre mediante MFA, segmentación y monitoreo. | Seguridad / TI | Un atacante con credenciales válidas accede libremente a múltiples sistemas. |
| Directorio centralizado (AD/LDAP) en uso | Usuarios gestionados en OU, con GPO aplicadas (cifrado de discos, bloqueo de pantallas, etc.). | TI | Cuentas locales no controladas, proliferación de accesos no trazables. |
| Revisión periódica de cuentas inactivas | Auditoría trimestral y eliminación de cuentas huérfanas o no utilizadas. | Seguridad / Cumplimiento | Uso indebido de cuentas olvidadas para intrusión. |
| Roles clasificados según área | Operativos, administrativos, TI, seguridad, directivos y externos documentados con accesos específicos. | Cumplimiento / RRHH | Confusión en permisos, exposición innecesaria de datos sensibles. |
| Protocolos inseguros bloqueados | Verificación de bloqueo de Telnet, FTP, SNMPv1, ICMP general en endpoints. | TI | Uso de protocolos inseguros para ataques de pivoting, sniffing o exfiltración de datos. |
| Restricción de servicios críticos | Bases de datos y aplicaciones accesibles solo vía aplicaciones o APIs, no directamente por usuarios. | TI / DBA | Consultas no autorizadas a datos financieros o personales, fuga de información. |
| Control de acceso a dominios | Acceso permitido solo a sitios institucionales y de negocio; bloqueo de redes sociales, streaming y pornografía. | Seguridad / TI | Riesgo de fuga de datos, pérdida de productividad y malware por navegación insegura. |
| Contratos laborales con cláusulas de seguridad | Documentación contractual con confidencialidad, uso aceptable y aceptación de pruebas de seguridad. | RRHH / Legal | Demandas de empleados por uso indebido de información o accesos no informados. |
| Acuerdos de confidencialidad (NDA) firmados | Proveedores externos y consultores con NDA vigente antes de recibir accesos. | Legal / Compras | Proveedor puede divulgar vulnerabilidades o datos sin responsabilidad legal. |
| Scope of Work (SOW) firmado en pruebas de seguridad | Documento formal con alcance, técnicas permitidas, exclusiones y responsabilidades. | Seguridad / Legal | Pentesting fuera de alcance que afecte sistemas críticos en producción. |
| Protección de usuarios en pruebas de seguridad | Consentimiento contractual para uso de cuentas reales en pentesting; anonimización de datos en pruebas. | Cumplimiento / Seguridad | Demandas de usuarios o clientes por vulneración de la privacidad durante auditorías. |
| Registro y trazabilidad de accesos | Logs de creación, modificación y eliminación de usuarios; evidencia de auditorías periódicas. | Seguridad / TI | Falta de trazabilidad ante incidentes o incumplimiento en auditorías regulatorias. |
2.7.2 Riesgos Globales Asociados a la Mala Gestión de Usuarios
Riesgo de abuso interno: empleados con privilegios innecesarios pueden manipular datos financieros o extraer información confidencial.
Intrusión externa facilitada: credenciales comprometidas permiten accesos amplios si no se aplica mínimo privilegio ni Zero Trust.
Incumplimiento normativo: la ausencia de controles documentados puede generar sanciones bajo la LOPDP y regulaciones de la Superintendencia de Bancos.
Demandas legales: usuarios internos o externos pueden demandar a la institución si se sienten vulnerados en su privacidad durante auditorías o pentesting.
Fuga de información crítica: accesos mal gestionados pueden derivar en robo de datos de clientes, afectando la confianza y reputación institucional.
Fraude financiero: cuentas huérfanas o accesos de proveedores no controlados pueden ser aprovechados para fraudes electrónicos.
Recomendaciones propias para definir un rol.
Los roles deben estar alineados a las funciones del negocio.
Se debe evitar roles “demasiado amplios” o “genéricos”.
Se debe garantizar la segregación de funciones (ejemplo: quien aprueba un pago no debe ser el mismo que lo ejecuta).
2.8 Política de Accesos por Rol
2.8.1 Roles Operativos (Front-Office y Atención al Cliente)
| Categoría | Rol | Puertos/Servicios Permitidos | Puertos/Servicios Denegados | Servicios Permitidos | Servicios Denegados | Dominios Permitidos | Dominios Denegados | Rango IP / VLAN | Descripción / Justificación |
|---|---|---|---|---|---|---|---|---|---|
| Roles Operativos | Cajero Bancario | 80, 443 (HTTP/HTTPS), 25/587 (SMTP) | 22 (SSH), 21 (FTP), 22 (SFTP), 1433/3306/1521 (DB), 445 (SMB) | Core Bancario, Correo | AD, SIEM, Carpetas compartidas | — | — | VLAN Cajeros | Solo usa Core vía web. SSH y DB bloqueados (consultas vía Core). FTP/SFTP bloqueados para evitar fuga. |
| Roles Operativos | Oficial de Servicio al Cliente | 80, 443, 25/587 | 22, 21, DB directos, 445 | CRM, Correo corporativo, Intranet | Core bancario, SIEM | — | — | VLAN Atención | Acceso a CRM e intranet. SSH/DB bloqueados (no administra servidores). |
| Roles Operativos | Ejecutivo de Negocios / Asesor Comercial | 80, 443, 25/587 | 22, 21, DB directos, 445 | ERP, CRM financiero | Core bancario, SIEM | — | — | VLAN Ejecutivos | Acceso a ERP; sin acceso a DB ni a infraestructura TI. |
| Roles Operativos | Personal de Call Center / Contact Center | 80, 443, 5060/5061 (VoIP) | 22, 21, DB directos, 445 | CRM, Telefonía IP | Core bancario, ERP | — | — | VLAN Call Center | Solo CRM y VoIP. DB bloqueadas para evitar exposición indebida. |
2.8.2 Roles Administrativos y de Apoyo (Middle-Office)
| Categoría | Rol | Puertos/Servicios Permitidos | Puertos/Servicios Denegados | Servicios Permitidos | Servicios Denegados | Dominios Permitidos | Dominios Denegados | Rango IP / VLAN | Descripción / Justificación |
|---|---|---|---|---|---|---|---|---|---|
| Middle-Office | Analista de Crédito / Riesgo Crediticio | 80, 443, 25/587 | 22, 21, DB directos | ERP financiero, scoring | Infra TI | — | — | VLAN Finanzas | Procesa créditos vía ERP. DB bloqueadas; consultas deben pasar por ERP. |
| Middle-Office | Contador / Finanzas | 80, 443, 25/587 | 22, 21, DB directos | ERP contable, Nómina | Core bancario | — | — | VLAN Finanzas | Accede a ERP contable. SSH/DB bloqueados por seguridad. |
| Middle-Office | Talento Humano (RRHH) | 80, 443, 25/587 | 22, 21, DB directos | HRM, Nómina | Core bancario | — | — | VLAN RRHH | Solo HRM. Maneja datos sensibles (LOPDP). |
| Middle-Office | Área de Cumplimiento / Legal | 80, 443 | 22, 21, DB directos | AML/PLD, Reportes regulatorios | Core bancario | — | — | VLAN Compliance | Acceso a sistemas regulatorios. DB bloqueadas. |
2.8.3 Roles Tecnológicos (TI e Infraestructura)
| Categoría | Rol | Puertos/Servicios Permitidos | Puertos/Servicios Denegados | Servicios Permitidos | Servicios Denegados | Dominios Permitidos | Dominios Denegados | Rango IP / VLAN | Descripción / Justificación |
|---|---|---|---|---|---|---|---|---|---|
| TI | Usuario Estándar de TI | 80, 443 | 22, 21, DB directos | Helpdesk, Ticketing | Producción TI | — | — | VLAN TI usuarios | Acceso básico a helpdesk. No administra infraestructura. |
| TI | Soporte Técnico / Mesa de Ayuda | 80, 443, 3389 (RDP), 22 (SSH limitado) | DB productivas | Soporte remoto, Escritorios | Core bancario, Producción crítica | — | — | VLAN Soporte | Escritorios vía Jump Server. DB bloqueadas. |
| TI | Administrador de Redes e Infraestructura | 22, 443, 161 (SNMP), VPN | DB apps | Switches, Routers, Firewalls | Core apps | — | — | VLAN Infraestructura, IP fija | Gestiona red y conectividad. SSH solo desde IP autorizada. |
| TI | Administrador de Servidores / Virtualización | 22, 3389, 443, 1521/1433 | Apps usuarios | Servidores, VM | Core apps | — | — | VLAN Admin | Administra servidores/VM. Producción bajo auditoría. |
| TI | Administrador de Aplicaciones (Core/ERP/CRM) | 80, 443, DB app | SSH | Core, ERP, CRM | Infra TI | — | — | VLAN Apps | Acceso a apps críticas. Sin acceso a infraestructura TI. |
| TI | Administrador de Base de Datos (DBA) | 1433, 1521, 3306, 443 | FTP, Telnet | Gestión de DB | Core apps directas | — | — | VLAN DB, IP fija | Acceso directo a DB (controlado y auditado). |
| TI | Arquitecto de TI | 80, 443, VPN | Producción | Documentación, Dev/Test | Core bancario | — | — | VLAN Lab | Diseña arquitectura y pruebas. Sin acceso a producción. |
2.8.4 Roles de Seguridad (Ciberseguridad y Cumplimiento)
| Categoría | Rol | Puertos/Servicios Permitidos | Puertos/Servicios Denegados | Servicios Permitidos | Servicios Denegados | Dominios Permitidos | Dominios Denegados | Rango IP / VLAN | Descripción / Justificación |
|---|---|---|---|---|---|---|---|---|---|
| Seguridad | Oficial de Seguridad de la Información (CISO/ISO) | 443 | 22, DB | Dashboards, Reportes de seguridad | Producción TI | — | — | VLAN CISO | Responsable de seguridad; no gestiona servidores. |
| Seguridad | Analista SOC Nivel 1 (Monitoreo) | 443, puertos SIEM | 22, DB | SIEM (Wazuh, Splunk) | Core bancario | — | — | VLAN SOC | Monitorea alertas. Solo lectura. |
| Seguridad | Analista SOC Nivel 2 (Investigación) | 443, SIEM, IDS | DB productivas | Correlación de eventos, IDS | Producción crítica | — | — | VLAN SOC | Investiga incidentes. Dev/Test; no producción. |
| Seguridad | Analista SOC Nivel 3 (Threat Hunting / DFIR) | 443, IDS/IPS, Threat Intel | DB directos | Threat hunting, DFIR | Producción | — | — | VLAN SOC avanzada | Producción solo bajo autorización. |
| Seguridad | Administrador de Seguridad (Red/Endpoint/SIEM) | 22, 443, puertos SIEM | DB productivas | IDS/IPS, EDR, Firewalls | Core apps | — | — | VLAN Seguridad | Gestiona infraestructura de seguridad. |
| Seguridad | Pentester / Red Team | 22, 80, 443 (solo lab) | Producción, Core | Laboratorio de pruebas | Producción | — | — | VLAN Pentest aislada | Solo entornos de prueba; nunca producción. |
| Seguridad | Blue Team / DFIR (Forensics & IR) | 443, SIEM, EDR | Producción directa | Análisis de logs, Forense | Core bancario | — | — | VLAN DFIR | Respuesta a incidentes. Producción bajo autorización. |
| Seguridad | Auditor Interno/Externo | 443, VPN controlado | SSH, DB | Dashboards de auditoría | Producción | — | — | VLAN Auditoría | Acceso temporal, supervisado. Solo lectura. |
2.8.5 Roles Directivos y Estratégicos
| Categoría | Rol | Puertos/Servicios Permitidos | Puertos/Servicios Denegados | Servicios Permitidos | Servicios Denegados | Dominios Permitidos | Dominios Denegados | Rango IP / VLAN | Descripción / Justificación |
|---|---|---|---|---|---|---|---|---|---|
| Directivos | Gerente de Sucursal | 443 | 22, DB | Reportes operativos | Producción TI | — | — | VLAN Gerencia | Acceso a reportes; no a sistemas TI. |
| Directivos | Gerente de Operaciones | 443 | 22, DB | Dashboards de operaciones | Infra TI | — | — | VLAN Operaciones | Supervisa conciliaciones y operaciones. |
| Directivos | Gerente Financiero (CFO) | 443 | 22, DB | ERP, dashboards financieros | Infra TI | — | — | VLAN CFO | Reportes financieros. Sin acceso a infra TI. |
| Directivos | Gerente de Riesgos | 443 | 22, DB | Dashboards de riesgos | Producción TI | — | — | VLAN Riesgos | Reportes de riesgos. Sin acceso a infra TI. |
| Directivos | Gerente de TI (CIO/CTO) | 443, VPN | DB directos | Reportes TI | Producción | — | — | VLAN Directivos | Supervisa TI. No opera sistemas. |
| Directivos | Gerente de Seguridad de la Información (CISO) | 443 | DB directos | Reportes de seguridad | Producción | — | — | VLAN Seguridad | Rol directivo; reportes estratégicos. |
| Directivos | Director General / Presidencia | 443 | Todo técnico | Dashboards ejecutivos | Infra TI | — | — | VLAN Presidencia | Reportes globales. Sin acceso técnico. |
2.8.6 Externos
| Categoría | Rol | Puertos/Servicios Permitidos | Puertos/Servicios Denegados | Servicios Permitidos | Servicios Denegados | Dominios Permitidos | Dominios Denegados | Rango IP / VLAN | Descripción / Justificación |
|---|---|---|---|---|---|---|---|---|---|
| Externos | Proveedores Externos (outsourcing, mantenimiento) | 443, VPN temporal | 22, DB | Acceso puntual contratado | Producción, Core | — | — | VLAN Proveedores | Acceso temporal. Cuentas desechables y monitoreadas. |
| Externos | Consultores TIC / Seguridad | 443, VPN, Jump Server | Producción real | Entornos Dev/Test | Core bancario | — | — | VLAN Consultoría | Solo Dev/Test. Nunca producción. |
| Externos | Auditores Externos (financieros o cumplimiento) | 443, VPN controlado | 22, DB | Dashboards de auditoría | Producción | — | — | VLAN Auditoría | Acceso temporal, controlado. Solo lectura. |
| Externos | Clientes Invitados (WiFi oficinas) | 80, 443 | Todo interno | Internet público | Intranet, Core | — | — | VLAN Invitados | Solo Internet. Aislado de red interna. |