Nueve programas dirigidos en entidades bancarias
Casos
Una selección de nueve programas dirigidos en entidades bancarias — hay más, pero estos resumen bien el tipo de trabajo. Los cuento con la misma estructura —el reto, el enfoque y el resultado— porque es la forma más honesta de enseñar cómo trabajo: lo interesante casi nunca es la tecnología elegida, sino cómo se llega a producción sin romper nada.
Todos arrancaron con un análisis por servicio aprobado por las partes antes de mover nada. Los clientes van sin nombre por confidencialidad. Todos son entidades financieras españolas y en todos dirigí el programa o el proyecto de principio a fin.
300 servidores críticos migrados sin parar el negocio
En un sector regulado, un proyecto no se juzga por la tecnología que emplea sino por lo que pasa cuando algo sale mal. Este resume bien cómo trabajo.
01 · El reto
Una plataforma bancaria sobre soporte que se acababa
Una entidad financiera española operaba su plataforma sobre Windows Server 2008. El soporte extendido tenía fecha de caducidad y, con él, la posibilidad de defender la infraestructura ante una auditoría: un sistema que deja de recibir parches no es un riesgo teórico, es un hallazgo. Había más de 300 activos, cada uno con sus aplicaciones, sus dependencias y su propietario dentro del negocio. Y varios servicios críticos sin alta disponibilidad: un solo servidor entre el servicio y la caída.
02 · El enfoque
Inventario, ventanas negociadas y vuelta atrás probada
Dirigí el programa completo durante dos años. Primero, clasificar los 300 activos por criticidad y dependencias, porque el orden de migración es la mitad del proyecto. Después, coordinar tres frentes a la vez: los equipos técnicos, los usuarios propietarios de cada aplicación y, cuando el software no soportaba la versión nueva, el propio fabricante. Cada ventana de migración se negoció con negocio y ninguna tocó producción sin un plan de vuelta atrás probado. Y cada migración se aprovechó para dotar de alta disponibilidad a los servicios que carecían de ella: si hay que mover un servidor, se mueve una vez y se mueve bien.
03 · El resultado
Cero incidencias graves y en plazo
Más de 300 activos migrados a Windows Server 2016 y 2019 dentro de los dos años comprometidos. Cero incidencias graves y sin pérdida de servicio para el negocio. La entidad salió del soporte extendido antes de la fecha límite, que era el objetivo regulatorio de fondo. Y los servicios que entraron al proyecto como punto único de fallo salieron de él en alta disponibilidad.
Una plataforma de contenedores desde la idea hasta producción
Un proyecto de signo contrario al anterior: no había nada que migrar, había que crear algo que la organización no tenía.
01 · El reto
Contenedores en un banco, partiendo de cero
La organización no tenía plataforma de contenedores ni nadie con experiencia en ella. No había que migrar nada: había que justificar la inversión, elegir la tecnología, comprarla, formar al equipo, montarla con la redundancia que exige un entorno bancario y ponerla en producción. Y hacerlo sin que el gobierno IT ni seguridad tuvieran que aceptar nada que no supieran auditar.
02 · El enfoque
Plan a cuatro años, formación certificada y dos CPD
Dirigí el proyecto desde la idea. Empecé por el plan de costes: una hoja de ruta a cuatro años que cubría implantación y crecimiento, para que la plataforma se aprobara como inversión y no como experimento. Elegimos Red Hat OpenShift y compramos el hardware para alojarla en varios centros de proceso de datos, con redundancia entre ellos. Antes de desplegar nada, formación reglada y certificación oficial de Red Hat para todos los recursos del equipo: una plataforma que solo entiende quien la instaló es una plataforma con un punto único de fallo humano. Coordiné a todos los implicados, del fabricante a los equipos internos de sistemas y de seguridad.
03 · El resultado
Servicio en marcha y la primera aplicación dentro
La plataforma quedó en marcha, redundada entre centros y con el equipo certificado para operarla. Se contenerizó y migró la primera aplicación, que era el objetivo de la fase inicial: demostrar el camino con un caso real antes de abrirlo al resto de la organización. La inversión quedó planificada y aprobada para los cuatro años siguientes.
Gobierno de identidades en una entidad bancaria
Misma metodología, otro banco y otra materia: quién puede acceder a qué, y quién responde de haberlo autorizado.
01 · El reto
Implantar gestión de identidades donde no la había
Implantación de una plataforma de gestión y gobierno de identidades (SailPoint IdM) en una entidad bancaria. El control de accesos es de los puntos que más pesan en una auditoría: hay que poder demostrar quién tiene cada permiso, quién lo aprobó y cuándo se revisó.
02 · El enfoque
La misma receta que ya había funcionado
Apliqué la metodología de los proyectos anteriores: plan de costes y horizonte plurianual antes de comprar nada, formación y certificación del equipo antes de desplegar, y coordinación de los tres frentes —fabricante, sistemas y seguridad— desde el primer día. La diferencia con un proyecto de infraestructura es que aquí el interlocutor principal no es técnico: los propietarios de los permisos están en negocio.
03 · El resultado
Accesos gobernados y auditables
La plataforma quedó implantada y operada por un equipo formado, con los procesos de alta, revisión y baja de accesos documentados y defendibles ante auditoría.
Cuentas privilegiadas fuera de obsolescencia
Las cuentas privilegiadas son las llaves maestras de una organización. Cuando la plataforma que las custodia queda obsoleta, el problema no es la versión: es que la única defensa frente a un acceso indebido depende de software sin soporte.
01 · El reto
Una bóveda de credenciales sin soporte y sin redundancia
Migración completa de la plataforma de identidades privilegiadas (CyberArk) por obsolescencia. Además de quedarse sin soporte, el servicio carecía de alta disponibilidad: si caía, se caía con él el acceso administrado a los sistemas críticos.
02 · El enfoque
Migrar y redundar en el mismo movimiento
Mismo método: inventario y dependencias primero, ventanas negociadas con los propietarios de cada sistema y vuelta atrás probada. Y, como en la migración de servidores, aprovechar la parada para arreglar lo que ya estaba mal: la plataforma no se movió tal cual, se rediseñó con alta disponibilidad.
03 · El resultado
Plataforma soportada y sin punto único de fallo
La plataforma quedó en versión soportada y en alta disponibilidad, y las cuentas privilegiadas volvieron a estar bajo una custodia que se puede defender en una auditoría.
La plataforma de prevención de fuga de datos
Migración de la plataforma de prevención de fuga de datos (DLP) y de todos sus componentes, en otra entidad bancaria.
01 · El reto
Un control que no se puede apagar
El DLP no es una aplicación aislada: son consolas, servidores, agentes en los puestos y reglas de negocio acumuladas durante años. Y es un control de cumplimiento: mientras dura la migración, la entidad no puede quedarse sin vigilancia sobre la información que sale.
02 · El enfoque
Convivencia de las dos plataformas
Mismo método de siempre: inventario de componentes y dependencias, ventanas negociadas y vuelta atrás probada. La diferencia aquí es que las dos plataformas tuvieron que convivir durante la transición, para que ninguna política de protección dejara de aplicarse ni un solo día.
03 · El resultado
Migración completa sin hueco de cobertura
Todos los componentes migrados y las políticas trasladadas y verificadas, sin periodo en el que la información quedara fuera de control.
Migración y despliegue del SIEM
El SIEM es el sistema que recoge y correlaciona los eventos de seguridad de toda la organización. Es, literalmente, con lo que se ve.
01 · El reto
Migrar los ojos sin quedarse a ciegas
Migrar y desplegar el SIEM significa mover las fuentes de eventos, las reglas de correlación y los cuadros de mando de todo el perímetro. Y hacerlo sin que el equipo de seguridad pierda visibilidad durante la transición, porque un hueco en la recolección es un hueco en la capacidad de detectar.
02 · El enfoque
Fuente a fuente, con la anterior aún encendida
Inventario de fuentes y reglas, migración por fases con las dos plataformas recogiendo en paralelo, y validación de que cada regla seguía disparando en la nueva antes de apagar la anterior. Coordinación con los equipos propietarios de cada sistema que emite eventos.
03 · El resultado
Plataforma desplegada y visibilidad continua
SIEM migrado y desplegado, con las fuentes y las reglas trasladadas y verificadas, sin periodo de pérdida de visibilidad.
Despliegue y puesta en marcha de Microsoft Purview
Antes de proteger la información hay que saber qué información se tiene, dónde está y cuánto importa. De eso va este proyecto.
01 · El reto
Poner nombre y etiqueta a la información
Despliegue y puesta en marcha de Microsoft Purview: descubrir, clasificar y etiquetar la información de la organización y aplicar sobre ella las políticas de protección y retención. Un proyecto que se sostiene o se cae en la parte que no es técnica, porque la clasificación la tiene que validar quien es dueño del dato.
02 · El enfoque
Clasificar primero con negocio, automatizar después
Definición del esquema de clasificación y de etiquetas con los propietarios de la información antes de tocar la herramienta. Despliegue por fases, empezando por los ámbitos de mayor sensibilidad, y coordinación con seguridad y con los equipos de puesto de trabajo. Las políticas se activaron primero en modo de observación y solo después en modo de bloqueo, para no romper el trabajo de nadie por una regla mal calibrada.
03 · El resultado
Plataforma operativa y políticas aplicándose
Purview desplegado y en marcha, con el esquema de etiquetas acordado con negocio y las políticas de protección y retención aplicándose sobre la información clasificada.
Migración de cortafuegos locales y perimetrales
Tres fabricantes distintos —Check Point, Palo Alto y Fortinet— y el perímetro de la organización de por medio. Aquí no hay ventana de mantenimiento cómoda: si se corta, se corta todo.
01 · El reto
Reglas acumuladas durante años, en tres tecnologías
Migración de los cortafuegos locales y perimetrales sobre plataformas de Check Point, Palo Alto y Fortinet. Un cortafuegos veterano acumula cientos de reglas cuyo motivo original ya nadie recuerda, y ninguna se puede quitar a ciegas: cualquiera puede ser la que sostiene un servicio que solo se usa una vez al trimestre.
02 · El enfoque
Traducir reglas, no copiarlas
Inventario de reglas y de sus dependencias reales antes de traducir nada, porque entre fabricantes no hay equivalencia automática: lo que en uno es una regla, en otro son tres o ninguna. Migración por fases con validación de tráfico en cada corte y vuelta atrás preparada. Coordinación con los equipos de red, de seguridad y con los propietarios de las aplicaciones afectadas.
03 · El resultado
Perímetro migrado y reglas depuradas
Cortafuegos migrados en las tres tecnologías, con el conjunto de reglas revisado y depurado por el camino: la migración sirvió también para retirar lo que ya no protegía nada.
Implantación de XDR en el puesto y el servidor
Detectar ya no es mirar un solo sitio. Un XDR correlaciona lo que pasa en el puesto, en el servidor y en la red, y responde sin esperar a que alguien lo mire.
01 · El reto
Un agente nuevo en cada máquina de la organización
Implantación de Cortex XDR de Palo Alto. La dificultad de un proyecto así no está en la consola: está en desplegar un agente en miles de equipos y servidores sin degradar el rendimiento ni bloquear aplicaciones legítimas, y sin que el usuario note que le han cambiado la máquina debajo.
02 · El enfoque
Piloto, ajuste de falsos positivos y despliegue por oleadas
Piloto en un grupo controlado para medir impacto y depurar falsos positivos antes de tocar producción. Despliegue por oleadas, empezando por perfiles de menor riesgo, con las políticas primero en modo de detección y solo después en modo de prevención. Coordinación con seguridad, con sistemas y con los responsables del puesto de trabajo.
03 · El resultado
Cobertura completa y respuesta automatizada
Plataforma implantada con el parque cubierto, las políticas de prevención activas y el equipo de seguridad operando la respuesta desde una sola consola.
Lo que tienen en común
Ninguno empezó por la ejecución. En todos hubo antes un análisis servicio a servicio —alcance, dependencias, riesgos, impacto en negocio, requisitos de disponibilidad y plan de vuelta atrás—, y ese análisis se aprobó con todas las partes interesadas e involucradas en cada servicio antes de tocar nada. Es el trabajo que no se ve, y es el que decide si el proyecto sale o se convierte en una sucesión de sorpresas.
Aprobado eso, lo demás siempre es igual: inventario y dependencias antes de mover nada. Formación del equipo antes de desplegar. Ventanas negociadas con quien es dueño del servicio, no impuestas. Vuelta atrás probada antes de tocar producción. Y aprovechar cada parada para arreglar lo que ya estaba mal, porque la siguiente oportunidad tarda años en llegar.
Si tienes por delante un proyecto de este tipo —o uno de IA o cumplimiento en un entorno regulado—, escríbeme y lo hablamos. También puedes ver mi trayectoria completa.
