5  Unidad: Servidores y Aplicaciones Críticas

5.1 Introducción de la Unidad

Los servidores son el corazón de la infraestructura tecnológica financiera: alojan los sistemas de core bancario, las bases de datos de clientes, los ERP y CRM, las aplicaciones de banca en línea, así como los servidores de respaldo, DNS, DHCP y directorios como Active Directory. Una vulnerabilidad o mala práctica en esta capa puede exponer datos financieros, permitir fraudes, comprometer transacciones o dejar inoperativos servicios críticos como cajeros automáticos y banca móvil.

Normativas internacionales como ISO/IEC 27001 (Anexo A.8 y A.13), PCI DSS v4.0 (Requisitos 2, 6 y 10), NIST SP 800-123 (Hardening de Servidores), y CIS Benchmarks establecen que los servidores deben configurarse bajo políticas estrictas de seguridad, con acceso limitado, segmentación, horarios de administración definidos y registros auditables. La LOPDP (Ecuador, 2021) añade obligaciones de protección de datos sensibles y trazabilidad de accesos.

En el sector financiero, los riesgos más frecuentes son:

  • Puertos y protocolos inseguros habilitados en servidores expuestos.

  • Servidores sin parches o con sistemas operativos obsoletos.

  • Cuentas administrativas sin control de horarios ni MFA, utilizadas para accesos indebidos.

  • Bases de datos expuestas directamente a la red interna, en lugar de restringirse a consultas vía API.

  • Servidores de respaldo accesibles desde la red de usuarios, utilizados por atacantes para borrar copias.

5.2 Riesgos Globales Asociados a una mala administración de servidores y aplicaciones críticas.

  • Exposición del core bancario y sistemas críticos por servidores mal segmentados o con puertos inseguros, lo que puede derivar en fraudes, manipulación de transacciones y pérdida de confianza en la institución.

  • Compromiso de bases de datos financieras y personales, lo que facilita exfiltración de información sensible (nombres, cuentas, tarjetas, historiales crediticios). Este tipo de fuga activa directamente sanciones bajo la Ley Orgánica de Protección de Datos Personales (LOPDP, Ecuador) y normativas internacionales como PCI DSS.

  • Ataques de ransomware a servidores internos y de respaldo, provocando interrupciones prolongadas de banca en línea, cajeros automáticos y pagos electrónicos. Esto impacta la continuidad del negocio, genera pérdidas económicas directas y puede forzar la suspensión temporal de servicios financieros.

  • Accesos indebidos fuera de horario laboral, que permanecen indetectados si no existen políticas claras y monitoreo centralizado. Esto habilita a atacantes internos o externos a mantener persistencia en los sistemas.

  • Mala gestión de servidores de seguridad (IDS/IPS, IA, microservicios) que deberían proteger la red, pero si están mal configurados se convierten en vectores de ataque adicionales.

  • Incumplimiento legal y sanciones regulatorias:

    • Bajo la LOPDP, las instituciones financieras pueden enfrentar sanciones administrativas, multas económicas proporcionales al daño causado, e incluso la inhabilitación para procesar datos personales.

    • Los clientes afectados pueden iniciar demandas civiles por daños y perjuicios ocasionados por la pérdida de su información personal o financiera.

    • Una filtración de datos de tarjetas sin cumplimiento de PCI DSS puede llevar a la revocación de licencias para procesar pagos electrónicos, perdiendo negocios con emisores y adquirentes internacionales.

  • Daño reputacional y pérdida de confianza, que en el sector financiero puede ser devastador: un solo incidente de fuga de datos o caída de servicios puede causar la migración masiva de clientes hacia la competencia, además de perder contratos con aliados estratégicos.

5.3 Inventario y Clasificación de Servidores

Un inventario completo es la base de la seguridad en servidores. Debe incluir:

  • Nombre y función (Core Bancario, ERP, BD Clientes, Web Banca, DNS, DHCP, Directorio AD, Microservicios, Servidores de IA, IDS/IPS – ej. Snort/Suricata).

  • Sistema Operativo (Windows Server, Linux, Unix, etc.) y versión exacta.

  • Fecha de último parche aplicado y frecuencia de actualización.

  • Políticas de contraseñas robustas.

  • Zona de ubicación: DMZ externa (públicos), DMZ interna (core bancario, bases de datos), DMZ de integración (APIs, middleware), Red de respaldo.

  • Protocolos y puertos habilitados, con justificación de uso.

  • IPs permitidas y denegadas, tanto internas como externas.

  • Política de firewall aplicada (# de referencia) para trazabilidad.

  • Si el servidor consume recursos externos vía VPN, especificar: a qué institución, bajo qué reglas, con qué cifrado y trazabilidad.

  • Responsable administrativo y de seguridad asignado.

Un inventario actualizado asegura control y permite detectar servidores no autorizados o configuraciones obsoletas.

5.3.1 Hardening de Servidores

El hardening asegura que cada servidor tenga la menor superficie de ataque posible:

  • Deshabilitar protocolos inseguros: Telnet, FTP, ICMP generalizado, SNMPv1/v2.

  • Solo habilitar puertos mínimos requeridos por la aplicación.

  • Uso de cifrado TLS 1.3/IPsec en todas las comunicaciones.

  • Logs locales y de aplicación enviados en tiempo real a un SIEM central.

  • Instalación de agentes de seguridad (antivirus, EDR/XDR, HIDS).

  • Verificación periódica de integridad con hashes y control de cambios.

5.3.2 Accesos y Gestión de Credenciales

  • Administración remota únicamente por SSH (con claves o tokens) o RDP con MFA, desde redes de TI autorizadas.

  • Prohibida la autenticación por usuario/contraseña simple.

  • Uso de cuentas estándar con escalamiento controlado de privilegios (sudo, Just-in-Time Access).

  • Eliminación periódica de cuentas huérfanas.

  • Administración documentada y limitada a horarios laborales; accesos fuera de horario solo con autorización especial y registro en SIEM.

5.3.3 Segmentación de Servidores en Zonas de Seguridad

Para mantener coherencia en la arquitectura, los servidores deben dividirse en zonas:

  • DMZ externa: servidores públicos como web de banca, correo corporativo, aplicativos móviles.

  • DMZ interna: sistemas críticos (Core Bancario, ERP, bases de datos, servidores de seguridad como IDS/IPS, IA analítica).

  • DMZ de integración: APIs, middleware y microservicios para consulta segura.

  • Red de respaldo: exclusiva para servidores de backup, inaccesible desde usuarios finales.

5.3.4 Políticas de Horarios y Administración

  • Administración solo en ventanas de mantenimiento definidas.

  • En emergencias fuera de horario, se habilitan políticas temporales con autorización de seguridad.

  • Servicios internos y respaldos también deben ejecutarse en horarios específicos, evitando uso indebido nocturno.

  • Accesos administrativos desde fuera de la institución solo vía VPN cifrada + MFA, registrada en SIEM.

5.4 Checklist de Servidores y Aplicaciones Críticas

Control / Medida Responsable Qué revisar / Evidencia Riesgo si no se cumple
Inventario actualizado (función, SO, versión, parches, zona, política de firewall, VPN asociada) TI / Seguridad Registro central de inventario, documentación de roles de servidor, bitácora de actualizaciones Servidores no inventariados → activos invisibles con vulnerabilidades sin control
Estado del Sistema Operativo TI Confirmar versión soportada por fabricante (Windows Server, Linux, Unix), verificar fin de soporte SO obsoleto → falta de parches de seguridad y vectores de ataque conocidos
Parches aplicados y última fecha TI Logs de actualizaciones, reportes WSUS/Intune/Kaseya Parches pendientes → explotación de vulnerabilidades críticas (ej. CVE en bases de datos o RDP)
Puertos y protocolos mínimos habilitados según función TI / Seguridad Escaneo con Nmap, revisión de configuración de firewall interno Puertos innecesarios → pivoting lateral, fuga de datos, ataques de fuerza bruta
Hardening aplicado (Telnet/FTP/ICMP general deshabilitado, SNMPv3 activo, TLS 1.3/IPsec habilitado) TI Scripts de validación, CIS Benchmark aplicado Protocolos inseguros → sniffing, manipulación de tráfico, robo de credenciales
Administración por SSH/RDP solo con tokens/MFA TI / Seguridad Configuración de acceso remoto, logs de autenticación, revisión de políticas GPO Credenciales robadas → acceso directo a servidores críticos
Escalamiento controlado de privilegios (ej. sudo) TI Configuración en AD, políticas de Just-in-Time Access Administradores con acceso permanente → abuso interno, falta de trazabilidad
Segmentación en DMZs (externa, interna, integración, respaldo) Infraestructura Diagramas de red, configuración de VLANs, reglas de firewall entre zonas Falla de segmentación → ataque a web compromete core bancario o BD
Políticas de firewall aplicadas (# de política por servidor) Seguridad Revisión de reglas en firewall, referencia de política aplicada Sin control → reglas inconsistentes permiten accesos indebidos
Accesos por VPN documentados (externos y hacia bancos centrales) TI / Cumplimiento Listado de túneles VPN activos, alcance, logs de tráfico VPN sin regulación → fuga de datos, intrusión por terceros
Administración limitada a horarios definidos TI / Seguridad Políticas en SIEM, revisión de logs fuera de horario Accesos nocturnos → persistencia de atacantes sin detección
Respaldos segmentados e inaccesibles desde usuarios TI Revisión de topología de red de backups, pruebas de restauración Ransomware borra respaldos si están en la misma red que producción
Logs enviados a SIEM centralizado (aplicación, sistema, seguridad) Seguridad / SOC Validar envío en tiempo real, correlación en SIEM (Wazuh, Splunk) Incidentes sin trazabilidad ni detección temprana
Servidores de seguridad (IDS/IPS, Snort, Suricata, IA) incluidos en inventario y actualizados Seguridad / SOC Reporte de actualización de firmas/reglas, pruebas de funcionamiento IDS/IPS sin actualización → ataques avanzados sin detección
Servidores de IA y microservicios monitorizados DevOps / Seguridad Auditoría de APIs, revisión de logs de anomalías Microservicios sin control → puerta de entrada a sistemas internos