Artículo · 2 min
Privacidad por diseño, no por retrofit
En una plataforma de salud no añadimos la seguridad al final. Moldeó la arquitectura desde el día uno — y ese orden de operaciones es todo el punto.
Hay un momento en muchos proyectos donde alguien dice “probablemente deberíamos cifrar eso”, y normalmente ya es demasiado tarde para que la respuesta sea buena. Trabajé en una plataforma de salud segura donde esa conversación ocurrió antes de la primera línea de código de backend — y la diferencia que eso hizo cambió por completo cómo pienso la seguridad.
El cifrado de base de datos es donde empieza el análisis, no donde termina
La postura por defecto — cifrar la base de datos y dar por terminado — protege los datos en reposo. Pero deja el texto plano expuesto a cualquier cosa que pueda llegar a la base de datos: bugs de aplicación, consultas demasiado amplias, herramientas internas. Para una plataforma que maneja información de salud altamente sensible, esa exposición residual era inaceptable.
Así que el diseño fue más lejos: múltiples categorías de datos personales se cifraron en la capa de aplicación, antes de llegar siquiera a la base de datos. Defensa en profundidad, más allá del límite de la base de datos. Incluso algo con acceso directo a la base de datos ve solo texto cifrado.
La decisión tiene un precio, y lo pagas en todas partes
El cifrado a nivel de aplicación no es una mejora gratuita. Dominaron dos costos.
Primero, la gestión de llaves se vuelve seria. Usamos envelope encryption para separar los datos cifrados de las llaves de cifrado — los datos viven en un lugar, las llaves que los abren en otro. Más piezas móviles, pero exactamente la separación datos/llaves que quieres cuando los datos son así de sensibles.
Segundo — y esto es lo que sorprende a la gente — pierdes la capacidad de consultar lo que cifraste. No puedes hacer WHERE email = ? sobre una columna cifrada. La respuesta fue el hashing determinístico: aplicar hash al valor sensible al entrar, y como entradas iguales producen el mismo hash, puedes hacer búsquedas seguras por igualdad sin exponer nunca el texto plano. El trade-off honesto: el hashing determinístico filtra igualdad — valores idénticos producen hashes idénticos. Lo aceptamos donde las búsquedas eran genuinamente necesarias, con la exposición entendida.
La seguridad deja de ser un módulo
Una vez que te comprometes con esto, los requisitos de seguridad se propagan hacia lugares que no parecen “trabajo de seguridad”: contratos de API, el modelo de datos, los flujos de validación, las reglas de logging (nada de datos sensibles en los logs — nunca), acceso de mínimo privilegio en todas partes. La seguridad se convirtió en un motor de diseño de todo el backend, no en una checklist al final.
Participé en implementar y mantener estos mecanismos como parte del esfuerzo de ingeniería backend y full-stack, y el cambio duradero para mí es simple: la seguridad es un requisito arquitectónico, decidido desde el inicio — no una funcionalidad añadida al final. Retroadaptar privacidad en un sistema maduro es una crisis. Diseñarla desde el día uno es manejable.
También redefinió “terminado” para mí. En trabajo con datos sensibles, una funcionalidad no está terminada cuando funciona. Está terminada cuando funciona y los datos que toca están protegidos por defecto.