Esta página es una traducción facilitada por comodidad. La versión en inglés es la que prevalece. Leer en inglés

Información regulatoria

Seguridad e integridad

Seguridad e integridad de nuestras operaciones financieras

Entidades como la nuestra emplean infraestructuras de servidores especializadas para gestionar ámbitos operativos diferenciados. En función de los requisitos de arquitectura y de la normativa financiera, los principales tipos de servidores son los siguientes:

1. Servidores bancarios centrales

Estos servidores constituyen la columna vertebral operativa central y gestionan las cuentas de los clientes, las transacciones y el cumplimiento normativo:

  • Servidores de procesamiento de transacciones: ejecutan en tiempo real la autorización de pagos, los controles antifraude y las liquidaciones (p. ej., SWIFT, SEPA).
  • Servidores de gestión de cuentas: gestionan los eventos del ciclo de vida de las cuentas (apertura y cierre), el cálculo de intereses y el seguimiento de la liquidez.
  • Servidores de cumplimiento normativo: automatizan los controles AML (prevención del blanqueo de capitales), las pistas de auditoría y la elaboración de informes (por ejemplo, IFRS, GDPR).

2. Servidores de registro

Responsable de mantener registros financieros inmutables:

  • Servidores de libro mayor: registran la contabilidad por partida doble en todas las cuentas, garantizando el cumplimiento de normas contables como las NIIF.
  • Servidores de tecnología de registro distribuido (DLT): sistemas basados en blockchain para pagos transfronterizos, verificación KYC y registros de operaciones a prueba de manipulaciones.

3. Servidores de comunicación externa
Permiten interacciones seguras con entidades externas:

  • Servidores EBICS: gestionan el estándar Electronic Banking Internet Communication Standard para pagos SEPA, ampliamente utilizado en Alemania, Francia y Suiza.
  • Servidores Host-to-Host (H2H): conexiones directas SFTP/FTPS para operaciones corporativas de gran volumen (por ejemplo, procesamiento masivo de nóminas).
  • Servidores de pasarela de API: proporcionan interfaces RESTful para la iniciación de pagos y la agregación de cuentas en tiempo real (protegidas mediante OAuth2/mTLS).
  • Servidores de interfaz Swift: conectan al banco con la red Swift para la mensajería interbancaria (SCORE es el grupo cerrado de usuarios de Swift para el acceso corporativo, no un tipo de servidor).

4. Servidores de bases de datos
Repositorios centrales de datos financieros estructurados:

  • Servidores de datos de clientes: almacenan documentos KYC, historiales de transacciones y análisis de comportamiento.
  • Servidores de catálogo de productos: gestionan ofertas como préstamos, hipotecas y tipos de interés de depósitos.

5. Servidores de seguridad e infraestructura
Garantizan la integridad del sistema y el cumplimiento normativo:

  • Servidores con módulo de seguridad de hardware (HSM): protegen las claves criptográficas utilizadas para firmas digitales y el cifrado SSL/TLS.
  • Servidores de cortafuegos/VPN: aplican la segmentación de la red y el acceso remoto seguro para los empleados.
  • Servidores de recuperación ante desastres: alojan sistemas de respaldo para garantizar la continuidad de la actividad durante las interrupciones.

Los bancos modernos suelen implantar arquitecturas híbridas que combinan servidores centrales locales con nodos DLT basados en la nube para lograr escalabilidad. Por ejemplo, un banco puede utilizar los servidores bancarios centrales locales de IBM junto con servidores de libro mayor alojados en AWS para la conciliación en tiempo real. Este enfoque modular equilibra el cumplimiento normativo, el rendimiento y la innovación.

Los bancos deben equilibrar la consolidación de servidores por razones de eficiencia con el mantenimiento del aislamiento por motivos de seguridad y cumplimiento normativo. A continuación se detallan los servidores que pueden combinarse y los que no, según las limitaciones técnicas y las prácticas del sector:
Servidores que pueden combinarse
1. Servidores web y de aplicaciones

  • Método combinado: virtualización (VMware, KVM) o contenedorización (Docker/Kubernetes)
  • Ejemplo: Alojamiento de varios portales bancarios (banca minorista, de empresas y móvil) en un clúster de hipervisores con balanceo de carga.

2. Servidores de bases de datos

  • Método combinado: bases de datos en la nube multiinquilino (AWS RDS, Azure SQL)
  • Las bases de datos bancarias centrales en Oracle/MS SQL pueden coexistir con sistemas analíticos en PostgreSQL/MongoDB en configuraciones de nube híbrida.

3. Pasarelas de comunicación externa

  • Método de combinación: pasarelas API unificadas (Apigee, MuleSoft)
  • Los servicios EBICS, SWIFT y SFTP pueden operar sobre una infraestructura compartida con microservicios específicos para cada protocolo.

4. Servidores de recuperación ante desastres

  • Método de combinación: georredundancia activo-activo
  • Las réplicas del sistema bancario central y los servidores de libro mayor de respaldo pueden compartir clústeres de recuperación ante desastres.

5. Servidores de middleware

  • Método de combinación: bus de servicios empresariales (ESB)
  • Servicios de enrutamiento de pagos, controles de cumplimiento normativo y conversión de divisas consolidados en IBM Integration Bus/SAP PI.

Servidores que deben permanecer aislados
1. Servidores centrales de procesamiento de transacciones

  • Motivo: La separación (física o mediante una segmentación estricta) reduce el alcance de los controles de PCI DSS y SOC 2
  • Ejemplo: los monitores de transacciones CICS que se ejecutan en IBM zSystems no pueden compartir el hardware con otras cargas de trabajo.

2. Servidores con módulo de seguridad de hardware (HSM)

  • Motivo: FIPS 140-2/140-3 Nivel 3 exige hardware dedicado a prueba de manipulación
  • Implementación: HSM de Thales/Gemalto para la gestión de firmas digitales y claves de cifrado.

3. Sistemas de libro mayor en tiempo real

  • Motivo: la contabilidad por partida doble exige atomicidad
  • Ejemplo: servidores de contabilidad de Oracle Financial Services con almacenamiento NVMe de conexión directa.

4. Servidores de comunicación de información regulatoria

  • Motivo: los registros de auditoría deben protegerse frente a su alteración y conservarse durante los plazos que exigen el RGPD y la normativa contra el blanqueo de capitales; la separación facilita acreditarlo.
  • Configuración: Instancias aisladas de SQL Server para los informes de MiFID II/FATCA.

5. Sistemas de autorización de cajeros automáticos y TPV

  • Motivo: acuerdo de nivel de servicio con disponibilidad del 99,999 % y requisitos de segmentación de red
  • Arquitectura: IBM Power Systems con redes SAN Fibre Channel redundantes.

Limitaciones técnicas:

  • Los sistemas bancarios centrales de alto volumen requieren conexiones de red dedicadas y de gran ancho de banda
  • PCI DSS exige que los números de tarjeta almacenados (PAN) se hagan ilegibles y que el entorno de datos de titulares de tarjetas esté segmentado
  • El Swift Customer Security Programme (CSP) exige que la infraestructura Swift se ubique en una zona segura protegida

Hemos consolidado con éxito el 80 % de los servidores no críticos (web/aplicaciones/middleware), manteniendo totalmente aislados los sistemas centrales, HSM y de libro mayor.

La protección de los servidores de libro mayor en la nube exige medidas de seguridad en múltiples capas, adaptadas a la sensibilidad de los datos financieros. Sobre la base de las mejores prácticas de seguridad de AWS y de implementaciones específicas del sector bancario, se presenta a continuación un enfoque estructurado:

1. Tecnología de libro mayor inmutable
Utilice bases de datos de libro mayor diseñadas específicamente, con verificación criptográfica de cada transacción:

  • Encadenamiento criptográfico: cada transacción se procesa mediante una función hash y se vincula a la entrada anterior, creando una pista de auditoría inmutable.
  • Controles de integridad integrados: la base de datos verifica automáticamente su propio historial, lo que impide cualquier manipulación.
  • Consultas de tipo SQL: mantiene la compatibilidad con los sistemas financieros existentes y añade una seguridad propia de la cadena de bloques.

2. Aislamiento de red

  • Arquitectura VPC: despliegue los servidores del libro mayor en subredes privadas sin acceso público a internet.
  • Grupos de seguridad: restrinja el tráfico entrante a puertos específicos (por ejemplo, PostgreSQL/Aurora) desde rangos de direcciones IP previamente aprobados.
  • Puntos de conexión VPC: utilice AWS PrivateLink para la comunicación segura entre los servidores del libro mayor y servicios como S3/KMS sin exponer los datos a la web pública.

3. Cifrado

  • En reposo: las claves gestionadas por AWS KMS cifran los datos del libro mayor en Amazon Aurora, con rotación automática de claves.
  • En tránsito: aplicar TLS 1.3 en todas las comunicaciones entre cliente y servidor y entre servicios.
  • Cifrado del lado del cliente: cifre previamente los campos sensibles (por ejemplo, saldos de cuentas) antes de su almacenamiento mediante el AWS Encryption SDK.

4. Control de acceso

  • Roles de IAM: asigne permisos granulares (por ejemplo, roles de solo inserción) para evitar la eliminación accidental o malintencionada de datos.
  • Credenciales temporales: utilice AWS STS para un acceso limitado en el tiempo durante las tareas de mantenimiento.
  • Aplicación de MFA: exija tokens de hardware (YubiKey) para las cuentas de root/administrador.

5. Seguimiento y auditoría

  • Alertas en tiempo real: configure AWS CloudWatch para activar alertas ante patrones de transacciones inusuales (p. ej., transferencias superiores a 1 M EUR).
  • Registros de actividad: seguimiento de todas las modificaciones del libro mayor mediante AWS CloudTrail integrado con herramientas SIEM.
  • Auditorías automatizadas: ejecución semanal de reglas de AWS Config para verificar el estado del cifrado y las políticas de red.

6. Cumplimiento normativo y gobernanza

  • Segmentación por zonas: entornos de libro mayor DEV/TEST/PROD separados mediante AWS Organizations.
  • Informes automatizados: genere informes de cumplimiento de PCI DSS y del RGPD mediante AWS Audit Manager.
  • Auditorías de terceros: programe anualmente pruebas de penetración con socios homologados por AWS.

7. Recuperación ante desastres

  • Replicación entre regiones: mantener réplicas cifradas del libro mayor en las regiones de AWS de Fráncfort y Estocolmo.
  • Recuperación a un momento determinado: active copias de seguridad continuas para restaurar los datos a cualquier segundo dentro del período de conservación (hasta 35 días).
  • Copias de seguridad aisladas de la red (air-gapped): almacenamiento de instantáneas trimestrales del libro mayor en AWS Backup Vault con un plazo de conservación de 7 años.
Seguridad e integridad: protección por capas de los datos financieros

Para evitar que las entradas maliciosas se propaguen a los servidores de recuperación ante desastres (DR), los bancos aplican estrategias de seguridad por capas que aíslan las copias de seguridad, imponen controles de acceso estrictos y validan la integridad de los datos. A continuación se presenta un desglose técnico de las medidas principales:
1. Copias de seguridad inmutables con configuraciones de escritura única y lectura múltiple (WORM)

  • Finalidad: impedir que el ransomware altere o cifre los datos de copia de seguridad.

Implementación: Utilice AWS S3 Object Lock o Azure Blob Immutable Storage para impedir la eliminación o modificación durante un período de conservación definido. Aplique un algoritmo de hash criptográfico (SHA-256) a los archivos de respaldo; cualquier manipulación invalida el hash y activa las alertas.
2. Replicación aislada de la red y sin conexión

  • Aislamiento de red: Almacene los servidores de recuperación ante desastres en una VPC/VLAN independiente, sin acceso entrante desde internet. Utilice replicación unidireccional (primario → recuperación ante desastres) mediante herramientas como AWS Storage Gateway o Azure Site Recovery, bloqueando la sincronización inversa.
  • Aislamiento físico (air-gapping): para los sistemas críticos, mantener copias de seguridad en cinta o almacenamiento sin conexión que solo se conecten durante las ventanas de replicación programadas.

3. Controles de acceso de confianza cero

  • Autenticación: Exigir MFA en todas las interfaces de gestión de recuperación ante desastres (p. ej., AWS SSO, Azure AD Conditional Access). Asignar roles IAM con permisos de mínimo privilegio (p. ej., `s3:GetObject` únicamente).
  • Seguridad de red: restrinja el tráfico de replicación a túneles VPN IPsec o a AWS Direct Connect/Azure ExpressRoute. Implemente sistemas de detección de intrusiones (IDS) como Snort o Suricata para supervisar los canales de replicación.

4. Validación de la integridad de los datos

  • Comprobaciones previas a la replicación: analizar los datos de origen en busca de software malicioso con herramientas como ClamAV o CrowdStrike Falcon antes de la replicación. Comparar las sumas de verificación antes y después de la transferencia para detectar alteraciones.
  • Auditorías posteriores a la replicación: Utilice AWS Config o Azure Policy para aplicar políticas de cifrado y de acceso en los servidores de recuperación ante desastres. Programe comprobaciones de integridad diarias mediante scripts (por ejemplo, la validación con `sha256sum`).

5. Entornos lógicamente segmentados

6. Pruebas automatizadas de conmutación por error

  • Ataques simulados: utilice herramientas como Chaos Monkey para simular infecciones de ransomware y validar la resiliencia de los servidores de recuperación ante desastres (DR). Mida los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) durante los simulacros.
  • Análisis forense: conserve durante 90 días los VPC Flow Logs y los eventos de CloudTrail para rastrear anomalías de replicación.

La implantación de copias de seguridad inmutables es fundamental para proteger los datos frente al ransomware, las eliminaciones accidentales y los incumplimientos normativos. Conforme a las normas del sector y a herramientas como AWS, Veeam y Azure, estas son las mejores prácticas:
1. Aplicar la inmutabilidad en la capa de almacenamiento

  • Utilice configuraciones WORM (Write-Once-Read-Many) mediante almacenamiento de objetos con S3 Object Lock (AWS), Azure Immutable Blob Storage o Veeam Hardened Repositories.
  • Active bloqueos de retención para impedir la eliminación o modificación prematuras, incluso por parte de los administradores.

2. Adopte una estrategia de copias de seguridad 3-2-1-1

  • 3 copias de los datos (principal y dos copias de seguridad)
  • 2 tipos de soportes de almacenamiento (por ejemplo, disco y nube)
  • 1 copia externa (geográficamente aislada)
  • 1 copia inmutable (aislada de la red o con tecnología WORM).

3. Implantar controles de acceso estrictos

  • Acceso basado en roles (RBAC): restrinja los permisos mediante roles de IAM (por ejemplo, las políticas de acceso a las bóvedas de AWS Backup).
  • Autenticación multifactor (MFA): aplíquese de forma obligatoria en las interfaces de gestión de copias de seguridad (por ejemplo, el acceso condicional de Azure AD).
  • Aislamiento de red: almacenar las copias de seguridad en subredes o VPC privadas sin acceso público a internet.

4. Cifre los datos de extremo a extremo

  • En reposo: utilice AES-256 o claves gestionadas mediante KMS (AWS, Azure).
  • En tránsito: TLS 1.3 para los canales de replicación.
  • Cifrado en el lado del cliente: cifrar previamente los campos sensibles antes de la copia de seguridad (por ejemplo, el AES-256 de Veeam con claves gestionadas por el usuario).

5. Automatizar la conservación y la validación

  • Políticas de conservación: defina el RPO y el RTO y automatice las reglas del ciclo de vida (por ejemplo, la conservación durante 7 años de AWS Backup Vault).
  • Validación de sumas de verificación: verificación de la integridad previa y posterior a la replicación (p. ej., mediante hash SHA-256).
  • Auditorías periódicas: utilice herramientas como AWS Config o Veeam SureBackup para comprobar las restauraciones.

6. Seguridad por capas para entornos híbridos

7. Garantizar el cumplimiento normativo y la irreversibilidad

  • Bloquear los ajustes de inmutabilidad tras las pruebas (por ejemplo, el estado «Enabled and locked» de Azure).
  • Cumpla la normativa: adáptese al RGPD, HIPAA o SOX mediante herramientas como AWS Audit Manager.
  • Auditorías de terceros: programe pruebas de penetración anuales (por ejemplo, con socios homologados por AWS).

Ejemplo de flujo de trabajo con AWS y Veeam
1. Copia de seguridad primaria: Veeam Backup & Replication hacia un bucket de S3 con Object Lock.
2. Replicación: AWS DataSync hacia una región secundaria (Fráncfort → Estocolmo).
3. Validación: registros diarios de CloudTrail + simulacros trimestrales de restauración.
4. Retención: periodo inmutable de 90 días con cifrado KMS.

Mediante la combinación de funciones de inmutabilidad, controles de acceso y redundancia híbrida, las organizaciones pueden lograr copias de seguridad resistentes al ransomware y, al mismo tiempo, satisfacer las exigencias de cumplimiento normativo.