Tabla de contenidos
- Qué significa realmente «almacenamiento cloud cifrado»
- Conocimiento cero vs servidor: quién posee las claves
- Los modelos de amenaza que defiende cada diseño
- Jurisdicción y metadatos: la parte que el marketing omite
- Los compromisos reales del conocimiento cero
- El lugar de los proveedores E2E: Internxt y Proton Drive
- Un marco de decisión para desarrolladores
Qué significa realmente «almacenamiento cloud cifrado»
«Cifrado» es una de las palabras más sobrecargadas del mercado del almacenamiento. Casi todos los proveedores pueden afirmar con honestidad que su servicio está cifrado, porque alguna capa lo está — y la capa que importa rara vez es la de la página de marketing.
Todo producto de almacenamiento cloud tiene tres capas de cifrado distintas, que protegen contra cosas completamente diferentes:
- Cifrado en tránsito — TLS protege los bytes que viajan entre tu dispositivo y el servidor. Esto detiene a un fisgón de red. Todo proveedor serio lo hace; es un requisito mínimo, no una característica.
- Cifrado en reposo — los datos en los discos del proveedor están cifrados, normalmente con AES-256. Esto protege contra el robo físico de un disco del centro de datos. Pero el proveedor posee la clave, así que no hace nada contra el proveedor, un requerimiento judicial o una intrusión que alcance el almacén de claves.
- Cifrado de extremo a extremo / conocimiento cero — los datos se cifran en tu dispositivo con una clave que solo tú controlas, antes de llegar al servidor. El proveedor almacena texto cifrado que no puede leer.
Cuando un desarrollador preocupado por su privacidad pide «almacenamiento cloud cifrado», casi siempre piensa en la tercera capa. Cuando un proveedor masivo anuncia «tus datos están cifrados», casi siempre se refiere a las dos primeras. Esa brecha es todo el tema de este artículo.
Conocimiento cero vs servidor: quién posee las claves
La única pregunta que separa los dos mundos es: ¿quién puede descifrar tus archivos sin tu cooperación?
Cifrado en el servidor (convencional). El proveedor genera y almacena las claves de cifrado. Tus archivos están cifrados en reposo, pero el mismo sistema que almacena el texto cifrado almacena también el medio para descifrarlo. Es el modelo detrás de la experiencia por defecto de Dropbox, Google Drive, OneDrive y la mayoría del almacenamiento cloud de consumo. La ventaja es la comodidad: el servidor puede indexar tus archivos para la búsqueda, mostrar vistas previas, ejecutar análisis antivirus, alimentar la edición colaborativa y restablecer tu contraseña sin pérdida de datos. El coste es que el proveedor — y cualquiera que pueda alcanzar legal o ilegalmente su almacén de claves — puede leerlo todo.
Cifrado de conocimiento cero (extremo a extremo). La clave se deriva de tu contraseña en tu dispositivo mediante una función de derivación de claves como Argon2 o PBKDF2. El texto en claro se cifra en local; solo se sube texto cifrado. El proveedor almacena una copia cifrada de tu material de claves, envuelta por una clave que a su vez procede de tu contraseña, así que el conjunto almacenado es inútil sin ti. Por tanto, el proveedor no puede leer tus archivos, no puede producir texto en claro ante un requerimiento, y no puede restablecer tu contraseña sin que pierdas el acceso. El término «conocimiento cero» describe exactamente esto: el servicio tiene cero conocimiento de tu texto en claro.
La criptografía aquí no es exótica — es el mismo patrón de cifrado por sobre usado dentro de los gestores de contraseñas como los tratados en nuestra guía de gestores de contraseñas en CLI para desarrolladores. Lo que difiere entre proveedores es la disciplina de implementación: qué KDF, qué cifrado, si los nombres de archivos y la estructura de carpetas también se cifran, y si el cliente es de código abierto para que la promesa sea verificable en lugar de creída.
Los modelos de amenaza que defiende cada diseño
Elegir un modelo de cifrado es en realidad elegir un modelo de amenaza. Haz corresponder a tu adversario con el diseño, no al revés.
| Amenaza | En reposo (servidor) | Conocimiento cero (E2E) |
|---|---|---|
| Fisgón de red | Defendido (TLS) | Defendido (TLS) |
| Disco robado del centro de datos | Defendido | Defendido |
| El proveedor lee tus archivos | No defendido | Defendido |
| Empleado malicioso | No defendido | Defendido |
| Requerimiento judicial del contenido | No defendido | Defendido (sin texto en claro que dar) |
| Intrusión que alcanza el almacén de claves | No defendido | Defendido (claves nunca utilizables en el servidor) |
| Olvidas tu contraseña | El proveedor puede recuperar | Irrecuperable por diseño |
| Malware en tu propio dispositivo | No defendido | No defendido (el texto en claro existe en local) |
Dos filas merecen énfasis. El conocimiento cero no te protege del malware en tu propia máquina — una vez que descifras en local, el texto en claro está en tus manos y en tu RAM, así que la higiene del endpoint sigue importando. Y el conocimiento cero traslada el riesgo de recuperación de contraseña hacia ti: la incapacidad del proveedor para leer tus datos es la misma propiedad que hace irrecuperable una contraseña olvidada. Es una característica, pero una característica con filo.
Jurisdicción y metadatos: la parte que el marketing omite
El cifrado protege el contenido. No protege por sí solo los metadatos — y los metadatos a menudo bastan.
Incluso un servicio de conocimiento cero perfectamente implementado tiene que funcionar. Conoce el correo de tu cuenta (te registraste con él), tus direcciones IP al iniciar sesión, tu volumen de almacenamiento, los tamaños de archivos, las marcas de tiempo de subida y — según la implementación — los nombres de archivos y carpetas. Algunos diseños E2E cifran también los nombres de archivos; muchos no. Los metadatos generalmente no están cubiertos por la garantía de conocimiento cero, y son precisamente lo que se requiere primero.
Aquí vuelve a entrar la jurisdicción. El régimen legal de un proveedor determina qué metadatos pueden exigirse y bajo qué proceso. La CLOUD Act estadounidense (2018) permite a las autoridades de EE. UU. obligar a las empresas estadounidenses a producir datos guardados en cualquier parte del mundo. El RGPD de la UE y la Ley Federal de Protección de Datos revisada de Suiza (LPD, en vigor desde septiembre de 2023) imponen condiciones más estrictas a la divulgación. Es la misma lógica jurisdiccional que tratamos para el correo en email auto-alojado vs ProtonMail vs Fastmail y más ampliamente en soberanía de datos: dónde está constituido un servicio es una variable técnica primaria, no una nota al pie.
La conclusión práctica: combina un cifrado de contenido sólido con un proveedor en una jurisdicción respetuosa de la privacidad, y asume que tus metadatos son visibles para un proceso judicial suficientemente motivado pase lo que pase.
Los compromisos reales del conocimiento cero
El almacenamiento de conocimiento cero no está libre de fricción. Ser honesto sobre los costes es la única forma de elegir bien.
La búsqueda y las vistas previas se degradan. Como el servidor solo almacena texto cifrado, no puede construir un índice de texto completo de tus documentos ni mostrar vistas previas y miniaturas en el servidor como hace Google Drive. Los proveedores E2E buscan en el cliente (tras descifrar un índice en tu dispositivo) o limitan la búsqueda a los nombres de archivos. Para una carpeta de miles de documentos, la diferencia es notable.
La colaboración es más difícil. La edición colaborativa en tiempo real, la que hizo ubicuo a Google Docs, necesita fundamentalmente un servidor capaz de leer y fusionar el estado del documento. Los diseños de conocimiento cero pueden colaborar, pero de forma más limitada y con implementaciones más jóvenes.
Compartir con quienes no son usuarios exige intercambio de claves. Enviar un archivo cifrado a alguien fuera del servicio implica transmitir una clave de descifrado por un canal separado, o usar una función del proveedor que genere un enlace protegido con contraseña. Funciona, pero es un paso que los servicios convencionales ocultan.
La recuperación de contraseña corre de tu cuenta. Conviene repetirlo porque es la forma más común de perder datos en estos servicios. Guarda la clave de recuperación que el proveedor te da al registrarte, almacénala en un lugar duradero y sin conexión, y usa una contraseña fuerte y única. Todo el modelo de seguridad descansa en esa contraseña.
Ninguno de estos puntos es una razón para evitar el almacenamiento de conocimiento cero — son razones para usarlo deliberadamente, para los datos que lo justifican, en lugar de como sustituto universal de todos los flujos de trabajo.
El lugar de los proveedores E2E: Internxt y Proton Drive
Dos proveedores aparecen una y otra vez en las comparativas centradas en la privacidad porque entregan clientes de código abierto y cifrado de extremo a extremo por defecto, y no como complemento de pago o modo solo para empresas.
Internxt es un proveedor basado en la UE (España) que ofrece almacenamiento cloud de conocimiento cero, cifrado de extremo a extremo, con clientes de código abierto y un plan gratuito. Su posicionamiento es una suite completa de privacidad (drive, más herramientas de privacidad adyacentes), y su base europea lo sitúa bajo el RGPD. Como el cliente es de código abierto, la promesa de conocimiento cero es verificable en lugar de afirmada.
Proton Drive es el componente de almacenamiento del ecosistema Proton — basado en Suiza, cifrado de extremo a extremo, de código abierto, con un plan gratuito. Si ya usas Proton Mail o Proton VPN, Drive encaja en la misma cuenta y la misma jurisdicción suiza, lo que lo convierte en una forma natural de mantener archivos cifrados junto a un correo cifrado. El mismo modelo de acceso cero que protege una bandeja Proton protege los archivos de Drive.
Ninguno es una respuesta universal. Son la herramienta adecuada cuando necesitas concretamente que el proveedor sea incapaz de leer tus datos, y aceptas los compromisos de búsqueda/colaboración a cambio.
Un marco de decisión para desarrolladores
Deja de preguntar «cuál es el almacenamiento cloud más seguro» y empieza a preguntar «qué son estos datos, y quién no debe leerlos».
Usa almacenamiento convencional (Drive/Dropbox/OneDrive) cuando: necesitas búsqueda de texto completo rápida en documentos, colaboración en tiempo real, vistas previas ricas, y los datos no son lo bastante sensibles para justificar la fricción. La comodidad es un requisito legítimo.
Usa almacenamiento de conocimiento cero (Internxt, Proton Drive) cuando: el contenido debe permanecer ilegible para el proveedor — documentos personales, archivos de credenciales, datos de clientes bajo NDA, copias de seguridad de proyectos sensibles, cualquier cosa que no quisieras que se produjera bajo requerimiento. Acepta que la búsqueda es local y que compartir necesita una clave.
Para el código fuente: sigue usando Git en una forja por el flujo de trabajo; usa el almacenamiento cifrado para copias de seguridad de repositorios, archivos binarios grandes y artefactos de compilación que no quieras que indexe un tercero. No pongas secretos activos en archivos en bruto en ningún almacenamiento — usa un gestor de secretos dedicado o una bóveda cifrada.
Elijas lo que elijas, verifica la promesa. Prefiere clientes de código abierto para que el cifrado sea auditable, prefiere una jurisdicción respetuosa de la privacidad para que los metadatos sean más difíciles de exigir, y guarda tu clave de recuperación en cuanto te registres en un servicio de conocimiento cero. La mejor criptografía del mundo se deshace con una contraseña olvidada sin vía de recuperación.
Para el contexto más amplio de mantener tus datos fuera de los servicios bajo jurisdicción estadounidense, consulta nuestro pilar sobre soberanía de datos y la guía práctica de migración en alternativas a Google.
