Envelope encryption con clave por usuario, qué se cifra y qué no, cómo lo puso a prueba una auditoría externa, y el incidente de rendimiento que provocó nuestro propio hardening de seguridad.
Montaste tu app con IA rápido: le pides unos datos al usuario, llamas al modelo, guardas el resultado en la base de datos y a producción.
Cómodo, sin complicaciones.
Hasta que un día miras bien qué estás guardando.
En Cuentopia generamos cuentos personalizados para niños.
Para personalizar, un padre nos cuenta cómo es su peque: su carácter, qué le da miedo, qué está pasando en casa.
El modelo no improvisa sobre la marcha: se apoya en un marco de criterios clínicos y pedagógicos para decidir cómo abordar cada situación, y luego lo reescribe todo en prosa.
Visto de golpe, lo que teníamos en la base de datos era el diario emocional de un montón de menores.
El RGPD lo trata como categoría especialmente protegida.
El sentido común, también. ¿Y si se filtra la base de datos? ¿Y un backup mal guardado? ¿Y un acceso indebido con privilegios de admin?
Relájate —bueno, primero asústate un poco; luego relájate—.
Te voy a contar cómo pensamos el cifrado en reposo en serio: una arquitectura de tipo envelope encryption, con una clave maestra que no sale nunca de Cloud KMS (Google Cloud) y una clave por usuario que cifra los campos sensibles antes de que toquen la base de datos.
Un aviso antes de seguir: te cuento el criterio y las decisiones, no el plano.
No vas a encontrar aquí nombres de recursos, rutas de repositorio, ni el detalle exacto que le serviría de receta a alguien con ganas de probar suerte con nuestros datos.
Y porque la seguridad honesta se cuenta entera, también te cuento dónde decidimos no llegar y por qué. ✨ Promesa: al terminar vas a entender, con criterio real de producto, cómo una familia sin ser expertos en cripto se planteó cifrar datos de menores — y por qué ciertas decisiones muy concretas no se hacen públicas nunca, ni en el artículo más honesto.
El mapa Lo construimos de dentro hacia fuera: primero el núcleo del cifrado, después una auditoría adversarial que nos bajó los humos y forzó varios cambios de endurecimiento, y por último —porque toda decisión de seguridad tiene una factura escondida— un incidente de rendimiento que nos costó un buen susto.
Esta es esa historia, contada en fases, no en versiones ni en commits.
Fase En qué consistió Diseño y cifrado base Arquitectura envelope, clave por usuario, primeros campos cifrados Auditoría y hardening Pentest adversarial, cierre de hallazgos, borrado con crypto-shredding Ajuste de rendimiento Un cambio de seguridad correcto que rompió la experiencia, y su arreglo Una aclaración antes de seguir, porque importa: hicimos todo este proceso —diseño, auditoría, endurecimiento— con Cuentopia en beta muy temprana, con mi propia cuenta como único usuario real en la base de datos.
Ningún dato de ninguna familia estuvo nunca ahí sin este cifrado; lo construimos antes de abrir la puerta a nadie más, precisamente porque hacerlo después —con usuarios reales y datos ya en producción— habría sido mucho más caro y mucho más arriesgado.
Si quieres ver cómo se lo contamos a las familias, sin la jerga de este artículo, ahí está la versión pensada para ellas: cuentopia.es/tu-confianza.
Y ya que estamos, crédito donde toca: todo esto corre sobre Firebase —Firestore para los datos, Cloud Functions para la lógica de servidor— y Google Cloud KMS para la clave maestra.
No reinventamos gestión de claves: nos apoyamos en servicios gestionados que ya audita gente con más recursos que nosotros.
TL;DR Cuentopia genera cuentos personalizados con IA a partir de datos sensibles de menores.
La solución: cifrado de campos en reposo con envelope encryption.
Una clave maestra vive en Cloud KMS, de Google Cloud, y nunca sale de ahí; cada usuario tiene su propia clave de datos, que la maestra envuelve y que se guarda cifrada junto a sus datos en Firestore.
El cliente pide su clave una vez por sesión, la usa en memori