RGPD y credenciales: qué exige realmente el cifrado de accesos

El RGPD no es un estándar técnico. No dice "usa AES-256" ni "cifra con X25519". Pero sí dice, con bastante claridad, que el cifrado es una de las medidas de seguridad que se esperan de cualquier organización que trate datos personales — y eso incluye, indirectamente, cómo proteges las credenciales que dan acceso a esos datos.

Este artículo repasa qué exige el RGPD en materia de cifrado, por qué las API keys y tokens importan aunque no sean "datos personales" en sí mismos, y qué puede y qué no puede resolver una herramienta de gestión de secretos.

Qué dice el RGPD sobre el cifrado (y qué no dice)

Artículo 32: medidas técnicas y organizativas

El Artículo 32 del RGPD obliga a implementar "medidas técnicas y organizativas apropiadas" para garantizar un nivel de seguridad adecuado al riesgo. Cita explícitamente la pseudonimización y el cifrado de datos personales como ejemplo de esas medidas — pero como ejemplo, no como requisito único ni obligatorio en todos los casos.

Esto significa dos cosas en la práctica:

No hay una lista cerrada de algoritmos aprobados por el RGPD.
Lo que sí se exige es que la medida sea proporcional al riesgo: cuanto más sensibles los datos y mayor el impacto de una brecha, más difícil es justificar no cifrar.

Para credenciales de infraestructura — claves de API, tokens de bases de datos, secretos de terceros — el razonamiento es directo: si esas credenciales dan acceso a datos personales, protegerlas es parte de proteger esos datos. Una fuga de una DATABASE_URL en un repositorio público no es un incidente "solo técnico": es una vía de acceso no autorizado a datos personales, y cae de lleno bajo el Artículo 32.

Artículo 34: la exención de notificación de brechas

Aquí es donde el cifrado deja de ser "recomendable" y pasa a tener consecuencias legales concretas. El Artículo 34 exige notificar a los afectados cuando una brecha suponga un alto riesgo para sus derechos — salvo que los datos estuvieran cifrados con medidas que los hagan ininteligibles para quien accediera a ellos sin autorización.

En otras palabras: si tus secretos están cifrados de forma que un atacante que roba la base de datos no puede leerlos, puedes estar exento de una notificación pública que dañaría la confianza de tus usuarios y tu reputación. Si están en texto plano en un .env filtrado o en un bucket mal configurado, no hay exención posible.

Por qué las API keys y tokens entran en esta conversación

El RGPD regula "datos personales", y una API key no es un nombre, un email o un IBAN. Pero en la práctica, la inmensa mayoría de las credenciales que gestionan los equipos de desarrollo son la puerta de entrada a sistemas que sí contienen datos personales: bases de datos de usuarios, proveedores de email transaccional, pasarelas de pago, servicios de analítica.

Miles de secretos se filtran cada día en repositorios públicos, logs, capturas de pantalla y builds de CI mal configurados — no es una hipótesis, es el patrón más repetido en los informes de incidentes del sector. Con el código generado por IA esto se ha acelerado: un asistente que autocompleta un .env de ejemplo con una clave real, o que copia una credencial de un proyecto a otro, es hoy una de las vías de fuga más comunes. Hablamos de esto con más detalle en /ai-security.

Cifrado en tránsito, en reposo y de extremo a extremo

No todo "cifrado" es igual a efectos de cumplimiento:

Cifrado en tránsito (TLS): protege el secreto mientras viaja por la red. Es mínimo indispensable, no un diferenciador.
Cifrado en reposo: protege el secreto en la base de datos del proveedor. Reduce el riesgo, pero si el proveedor tiene la clave de descifrado, sigue pudiendo leer tus secretos — y un atacante que comprometa su infraestructura, también.
Cifrado de extremo a extremo (zero-knowledge): el proveedor almacena únicamente texto cifrado y nunca tiene acceso a las claves de descifrado. Es el nivel que mejor sostiene la exención del Artículo 34, porque incluso si el proveedor sufre una brecha, los datos siguen siendo ininteligibles.

Koove trabaja en este último nivel: cifrado de extremo a extremo con X25519 y AES-256-GCM (envelope encryption), sobre primitivas criptográficas open-source (paquete @koove/crypto). El servidor almacena solo ciphertext; los secretos se descifran únicamente en consumidores verificados mediante atestación móvil (Apple App Attest / Google Play Integrity) y biometría, o en backends autorizados.

Cómo se ve esto en la práctica

# Guardar un secreto sin que pase nunca por un .env en texto plano
koove set STRIPE_SECRET_KEY sk_live_xxx --env prod

# Ver qué hay guardado (metadatos, no el valor en claro)
koove list --env prod

# Aprobar el dispositivo de un nuevo desarrollador antes de que pueda descifrar nada
koove device-approve --device-id <id>

# Rotar el cifrado cuando alguien deja el equipo
koove rewrap --env prod

El código de la aplicación solo referencia STRIPE_SECRET_KEY por nombre; el valor real nunca se escribe en un archivo ni llega a un asistente de IA que autocompleta el repositorio. Los detalles técnicos completos están en /docs/sdk y la arquitectura en /security.

Lo que el cifrado no resuelve por sí solo

Es importante ser honestos sobre los límites, porque el RGPD no se cumple solo con una herramienta:

El cifrado no sustituye una base legal de tratamiento, un registro de actividades o un análisis de riesgos. Es una medida técnica dentro de un marco más amplio.
Revocar el acceso de un dispositivo o rotar un secreto no deshace el acceso ya concedido. Si un desarrollador ya descifró y copió una credencial antes de que se le revocara el acceso, esa copia sigue existiendo. koove device-revoke y koove rewrap protegen el acceso futuro, no borran lo ya expuesto.
Koove no sustituye una auditoría de cumplimiento. No ofrecemos certificaciones SOC 2 o ISO — si tu organización las necesita para un cliente o auditor, tendrás que evaluarlo como parte de tu propia due diligence, no asumir que una herramienta de cifrado las otorga automáticamente.

Checklist práctico

Inventaría qué credenciales dan acceso a datos personales, no solo cuáles "parecen sensibles".
Verifica si tus secretos viajan en texto plano en algún punto: CI/CD, logs, .env versionados.
Prioriza cifrado de extremo a extremo para credenciales de alto impacto (bases de datos de producción, proveedores de pago).
Documenta el proceso de rotación y revocación de accesos — el RGPD valora que existan procedimientos, no solo tecnología.
Revisa los precios y el modelo de acceso en /plans antes de decidir qué nivel de protección necesitas para cada entorno.

Si tienes dudas concretas sobre atestación, dispositivos o recuperación de acceso, la /faq cubre los casos más habituales.

Empieza por lo que sí puedes controlar

El RGPD no te va a decir qué algoritmo usar, pero sí te exige poder demostrar que las credenciales que protegen datos personales no quedan expuestas en texto plano. Es una de las pocas áreas donde una decisión técnica concreta — cifrar de extremo a extremo en lugar de confiar en variables de entorno sueltas — tiene un efecto legal directo.

Si quieres dejar de gestionar secretos a mano y empezar a cifrarlos de extremo a extremo desde el primer koove set, puedes registrarte aquí.