Contexto
Trabajé en una plataforma de salud segura que manejaba datos personales altamente sensibles bajo estrictos requisitos de privacidad y cumplimiento. En un producto así, la protección de datos no puede ser algo que se añade al final — tiene que moldear la arquitectura desde la primera decisión.
Desafío
El cifrado a nivel de base de datos, por sí solo, no es suficiente. Protege los datos en reposo, pero deja el texto plano expuesto a cualquier cosa con acceso a la base de datos — bugs de aplicación, consultas demasiado amplias, herramientas internas. Para una plataforma con información de salud sensible, esa exposición residual era inaceptable. Necesitábamos proteger múltiples categorías de datos personales en una capa por encima de la base de datos, sin perder la capacidad de usar realmente los datos.
Restricciones
Un contexto de salud regulado fijó el listón: estrictos requisitos de privacidad y cumplimiento aplicaban a cada categoría de datos personales que la plataforma tocaba, y el acceso a los datos debía seguir el principio de mínimo privilegio en todo momento. Ganara lo que ganara el diseño en protección, el producto seguía necesitando poder buscar registros.
Arquitectura
La decisión central fue cifrar los datos sensibles en la capa de aplicación en lugar de depender solo de la base de datos — defensa en profundidad más allá del límite de la base de datos. El envelope encryption separó los datos cifrados de las llaves de cifrado: más piezas móviles de gestión de llaves, pero una separación datos/llaves que vale la pena por la postura de seguridad.
La seguridad se propagó luego hacia afuera. Dejó de ser un módulo y se convirtió en un motor de diseño en todo el backend: los contratos de API, el modelo de datos, los flujos de validación y el logging (sin datos sensibles en los logs) fueron moldeados por ella.
Trade-offs
Cifrado de PII a nivel de aplicación en lugar de cifrado solo en base de datos
Una plataforma de salud segura manejaba datos personales altamente sensibles bajo estrictos requisitos de privacidad y cumplimiento. El cifrado a nivel de base de datos, por sí solo, deja el texto plano expuesto a cualquier cosa con acceso a la base de datos.
Cifrar múltiples categorías de PII en la capa de aplicación, y usar cifrado de sobre (envelope encryption) para separar los datos cifrados de las llaves de cifrado. El acceso a los datos siguió el principio de mínimo privilegio.
- Defensa en profundidad más allá del límite de la base de datos
- Separación llaves/datos y una mejor postura de gestión de llaves vía envelope encryption
- Postura de cumplimiento y auditabilidad apropiada para PII de salud
- Mayor complejidad de implementación
- Los campos cifrados no pueden consultarse por igualdad normal — se necesitó hashing determinístico para búsquedas seguras
- Los requisitos de seguridad se propagaron al diseño de API, modelado de datos, validación y logging
La seguridad debe ser parte de la arquitectura desde el inicio — no puede añadirse al final.
La consecuencia dura de cifrar en la capa de aplicación es que consultar campos cifrados deja de ser gratis — ya no puedes buscar registros por valor. Usamos hashing determinístico: aplicar hash al valor sensible de modo que entradas iguales produzcan el mismo hash, lo que permite búsquedas seguras por igualdad sin descifrar ni exponer nunca el texto plano. El costo honesto es que el hashing determinístico filtra igualdad — valores idénticos producen hashes idénticos — algo que aceptamos donde las búsquedas eran necesarias.
Implementación
Participé en la implementación y el mantenimiento de estos mecanismos de seguridad como parte del esfuerzo de ingeniería backend y full-stack. En la práctica eso significó trabajar dentro de los patrones que la arquitectura exigía: decisiones de cifrado a nivel de campo, rutas de búsqueda basadas en hash que se mantienen indexables, flujos de validación que respetan el límite cifrado, y logging que nunca toca el texto plano.
Lecciones
El cambio duradero para mí fue tratar la seguridad como 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”: una funcionalidad no está terminada cuando funciona — está terminada cuando funciona y los datos que toca están protegidos por defecto.
Qué mejoraría
Profundizaría en el trade-off entre cifrado determinístico y aleatorizado para campos consultables — el hashing determinístico habilita búsquedas por igualdad pero filtra igualdad — y en patrones más sólidos para consultar datos cifrados sin esa filtración.