Pocas ideas generan tanto consenso en tecnología y tan poca práctica como esta: la seguridad debería formar parte del diseño y no añadirse al final. Todo el mundo la comparte. Y, sin embargo, la seguridad sigue llegando casi siempre tarde, en forma de auditoría posterior al despliegue, de parche tras una vulnerabilidad o de control añadido porque alguien detectó un riesgo que debería haberse evitado antes.
Cada una de esas capas tiene sentido, pero todas parten de la misma premisa: el sistema ya existe y ahora hay que protegerlo.
¿Y si la mejor forma de proteger un sistema fuera diseñarlo para que determinados problemas no puedan ocurrir?
La mejor vulnerabilidad es la que no puede existir
Un servicio que no está expuesto a internet no puede atacarse desde internet. Una credencial que no existe no puede filtrarse. Un dato que nunca se recoge no puede acabar en una brecha. Un permiso que nunca se concedió no puede utilizarse de forma indebida.
Esa es, para mí, la diferencia entre añadir seguridad y diseñar con seguridad. En el primer caso reaccionamos a las amenazas. En el segundo reducimos las oportunidades de que aparezcan.
Diseñar así implica decisiones arquitectónicas distintas. Restringir el acceso por defecto en lugar de abrirlo y cerrarlo después. Usar identidades temporales en lugar de claves que viven indefinidamente. Cifrar porque es lo normal y no lo excepcional. Asumir que algún componente fallará, para que ese fallo no se convierta en un incidente.
Cambiar de CPD no es cambiar de modelo
Un ejemplo claro es el de las migraciones a la nube.
Migrar a AWS con un lift & shift, es decir, trasladar los servidores tal cual a máquinas virtuales en la nube, es prácticamente no hacer nada. Se cambia el CPD, pero todo lo demás viaja con la carga: los mismos sistemas operativos que hay que parchear, las mismas copias de seguridad que hay que vigilar, las mismas credenciales de larga duración, la misma red pensada para un perímetro que ya no existe.
El resultado es una infraestructura nueva con el modelo de seguridad de hace una década. Y con una dificultad añadida: la nube tiene su propio modelo de responsabilidad compartida y sus propias formas de equivocarse. Un grupo de seguridad mal configurado o un permiso demasiado amplio son errores que antes no existían con esa forma.
Migrar de esta manera no reduce la deuda operativa de la que hablaba en el artículo anterior. La traslada. Se paga más por lo mismo y la seguridad sigue dependiendo de que alguien recuerde hacer cada tarea.
Diseñar con seguridad en la nube significa aprovechar lo que esa plataforma permite hacer de otra manera. Servicios gestionados que eliminan la responsabilidad sobre capas enteras. Roles temporales en lugar de claves estáticas. Redes privadas por defecto. Entornos definidos como código, que se crean siempre con la misma configuración y se revisan como se revisa cualquier otro cambio. La migración deja de ser un traslado y pasa a ser una oportunidad de rediseño.
La seguridad manual también es deuda operativa
Revisar permisos a mano, rotar credenciales según un calendario, comprobar configuraciones una por una o preparar evidencias para cada auditoría son tareas necesarias. Pero cuando dependen de personas, funcionan solo mientras alguien se acuerda de hacerlas.
Un control que depende de la memoria o de la disciplina de alguien no es un control robusto. Es un riesgo aplazado.
Por eso las organizaciones que mejor gestionan la seguridad suelen ser también las que más han automatizado. Cuando las políticas se definen como código, se aplican siempre igual. Cuando el cumplimiento se verifica de forma continua, la auditoría deja de ser un acontecimiento y pasa a ser una consecuencia. Cuando la privacidad se contempla desde el inicio, la normativa no obliga a rediseñar lo ya construido.
Un buen diseño de hoy puede ser una vulnerabilidad mañana
Hay algo que se dice menos y que me parece igual de importante: diseñar con seguridad no es una decisión que se toma una vez.
El lift & shift es, en el fondo, un problema de evolución. Replica en infraestructura moderna un diseño que pertenece a otra época. Lo que hace diez años era una arquitectura razonable, con un perímetro bien definido y confianza implícita dentro de la red corporativa, hoy resulta insuficiente. Por eso modelos como Zero Trust, que formaliza referencias como el NIST SP 800-207, parten de una premisa distinta: no confiar por defecto en nada, ni siquiera dentro de la red. Lo mismo ha pasado con la identidad. Las contraseñas robustas dieron paso al doble factor, y este empieza a ceder terreno frente a la autenticación sin contraseña.
Y no es exclusivo de la seguridad. Ocurre en cualquier disciplina técnica:
- Un equipo de desarrollo que no ha revisado sus prácticas en cinco años probablemente siga desplegando manualmente lo que hoy debería ser un proceso automatizado y verificable.
- Una infraestructura que no ha evolucionado sigue administrándose servidor a servidor, cuando el sector ya piensa en entornos definidos como código.
- Un equipo de datos que no actualiza su forma de trabajar acaba protegiendo arquitecturas que otros ya han dejado atrás.
El problema rara vez es no saberlo todo al principio. Es dejar de mirar hacia dónde se mueve la disciplina. Un sistema diseñado con seguridad en 2020 y que nadie ha vuelto a cuestionar no es un sistema seguro. Es un sistema que fue seguro.
Evolucionar es parte del diseño
Esto cambia lo que deberíamos pedir a un equipo técnico. No basta con que conozca bien la tecnología que utiliza hoy. Importa que tenga el hábito, y el tiempo asignado, para revisar si esa tecnología sigue siendo la adecuada.
Un equipo que deja de evolucionar no falla de golpe. Se queda atrás poco a poco, sin que nadie lo note, hasta que un incidente revela cuánto tiempo llevaba desactualizado el criterio con el que se diseñaba.
Por eso, cuando observo una arquitectura, no me pregunto solo si es segura hoy.
¿Seguirá siéndolo dentro de cinco años, o solo lo es mientras todo lo que la rodea permanezca igual?