Seguridad en la nube y on-premise: los nuevos desafíos

Durante años, la seguridad en banca se pensó como un castillo: un perímetro fuerte, un centro de datos propio y la confianza puesta en todo lo que estaba "adentro". Ese modelo ya no describe la realidad. Hoy un mismo banco opera con sistemas on-premise, servicios en la nube, APIs abiertas a terceros, colaboradores remotos y, cada vez más, agentes de IA que consumen y producen información.

El resultado es que el perímetro ya no es una línea, es una red de identidades, permisos y conexiones. Y cada entorno trae sus propios desafíos.

On-premise: el riesgo de lo que "siempre funcionó"

Tener la infraestructura en casa da control, pero también genera una falsa sensación de seguridad.

• Deuda de parches. Sistemas críticos que no se actualizan porque "no se pueden detener" acumulan vulnerabilidades conocidas.
• Confianza implícita en la red interna. Si un atacante entra, puede moverse lateralmente con poca resistencia.
• Visibilidad limitada. Muchos entornos on-premise tienen registros dispersos y poca correlación entre eventos.
• Dependencia de personas clave. Las configuraciones viven en la memoria de quien las hizo, no en código versionado.

On-premise no es sinónimo de inseguro, pero exige la misma disciplina que se le pide a la nube: inventario, configuración como código, monitoreo y segmentación.

Nube: el modelo de responsabilidad compartida

La nube no es más segura ni menos segura por sí misma. Es distinta. El proveedor protege la infraestructura; el banco sigue siendo responsable de cómo la configura y la usa.

Los incidentes más comunes en la nube no vienen de ataques sofisticados, sino de errores de configuración:

• almacenamiento expuesto públicamente por accidente,
• identidades con permisos excesivos,
• claves y secretos guardados en el código,
• servicios creados fuera de los controles del área de seguridad.

La velocidad que da la nube es también su riesgo: un error se despliega tan rápido como un acierto.

Híbrido: donde se juntan los dos mundos

La mayoría de bancos vivirá años en un modelo híbrido. Ahí aparecen desafíos propios:

• Identidad unificada. Usuarios y servicios deben autenticarse de forma coherente en ambos entornos, sin cuentas duplicadas ni excepciones permanentes.
• Conectividad segura. Los enlaces entre la nube y el centro de datos se convierten en rutas privilegiadas que hay que proteger y monitorear.
• Políticas consistentes. Una regla de seguridad que existe on-premise pero no en la nube (o al revés) es una puerta abierta.
• Soberanía y residencia de datos. Saber dónde está cada dato y bajo qué jurisdicción es un requisito regulatorio, no un detalle técnico.

Los nuevos desafíos

1. La identidad es el nuevo perímetro

En un entorno distribuido, lo que se protege es quién o qué accede, a qué y con qué permisos. El enfoque de confianza cero (zero trust) parte de no confiar en nada por estar "adentro": cada acceso se verifica, se limita al mínimo necesario y se registra.

Esto incluye identidades no humanas: servicios, procesos automáticos, integraciones y ahora agentes de IA. En muchos bancos ya hay más identidades de máquinas que de personas, y suelen ser las peor gobernadas.

2. APIs: la superficie de ataque que más crece

La banca abierta y la integración con terceros multiplican las APIs expuestas. Cada una es una puerta. Una capa media gobernada (con API Manager, autenticación fuerte, límites de uso, validación de contratos y monitoreo) es la diferencia entre exponer servicios y exponer el banco.

3. Gestión de secretos

Claves, tokens y certificados dispersos en archivos de configuración, scripts o repositorios siguen siendo una de las causas más frecuentes de incidentes. Un gestor de secretos centralizado, con rotación y auditoría, ya no es un lujo: es higiene básica.

4. IA como nuevo vector

La IA generativa trae riesgos que los marcos tradicionales todavía están absorbiendo:

• fuga de datos al enviar información sensible a modelos externos,
• inyección de instrucciones (prompt injection) que manipula a un asistente o agente para que haga algo no previsto,
• agentes con permisos excesivos que pueden ejecutar acciones reales,
• dependencia de modelos cuyo comportamiento cambia sin aviso.

La respuesta no es prohibir la IA, sino tratarla como cualquier otro componente: con identidad propia, permisos mínimos, registro de acciones y revisión humana en lo crítico.

5. La cadena de suministro de software

Librerías abiertas, imágenes de contenedores, herramientas de construcción: cada dependencia es código de terceros corriendo en el banco. Saber qué componentes se usan, en qué versión y con qué vulnerabilidades es parte de la seguridad, no un tema exclusivo de desarrollo.

Seguridad desde el diseño

La lección que más repito en arquitectura es que la seguridad cuesta menos cuando se diseña que cuando se agrega. En la práctica significa:

1. Modelar amenazas al diseñar cada solución, no al final del proyecto.
2. Definir patrones seguros por defecto: cómo se autentica un servicio, cómo se guardan secretos, cómo se registra un evento.
3. Infraestructura como código revisada y versionada, igual que el software.
4. Controles automáticos en el ciclo de desarrollo: análisis de dependencias, de configuración y de código antes de cada despliegue.
5. Observabilidad unificada entre nube y on-premise para detectar y responder rápido.
6. Ejercicios de respuesta a incidentes: el plan que no se practica no funciona el día que se necesita.

Gobierno: que la seguridad rinda cuentas

Un marco de gobierno como COBIT ayuda a que la seguridad deje de ser un conjunto de herramientas y pase a ser un proceso con responsables, métricas y mejora continua. Las preguntas que el directorio debería poder responder con datos son:

• ¿Qué activos críticos tenemos y dónde están?
• ¿Quién tiene acceso a ellos y por qué?
• ¿Cuánto tardamos en detectar y contener un incidente?
• ¿Qué riesgos aceptamos conscientemente y cuáles no?

Cierre

Nube, on-premise o híbrido: el entorno cambia, pero el principio no. La seguridad efectiva es la que se diseña, se automatiza y se gobierna. Los nuevos desafíos (identidades de máquina, APIs, IA, cadena de suministro) no requieren inventar una disciplina nueva, sino aplicar con más rigor la que ya conocemos, en más lugares y a mayor velocidad.

La tecnología debe ser confiable antes que ingeniosa. En seguridad, esa frase no es un lema: es el criterio de diseño.