Compartir archivos zero-trust: no confíes en nadie, cifra todo
Aplica principios de seguridad zero-trust al compartir archivos. Por qué asumir que toda red es hostil lleva a mejor cifrado.
Compartir archivos con zero-trust asume que la red es hostil, el servidor está comprometido y el dispositivo del destinatario puede estar infectado — y cifra en consecuencia. Los archivos se cifran en el navegador del remitente con AES-256-GCM antes de que un solo byte viaje por la red; las claves se derivan de una contraseña más una sal almacenada en el fragmento de la URL, y el servidor maneja únicamente texto cifrado opaco. Este es el modelo operativo codificado en NIST SP 800-207 aplicado a la transferencia de archivos: verificar explícitamente, conceder el mínimo privilegio y asumir una brecha en cada capa.
Las tres premisas que guían el diseño
Zero-trust parte de tres supuestos. Primero, el transporte está comprometido — los proxies corporativos realizan inspección TLS, el Wi-Fi de una cafetería puede ejecutar ARP spoofing y existen escuchas en la troncal nacional (documentadas por Snowden en 2013, aún operativas según Bloomberg en 2024). Segundo, el servidor está comprometido — los proveedores cloud sufren brechas (AWS en 2019, Microsoft en 2023), los administradores se vuelven desleales y las órdenes judiciales llegan en silencio. Tercero, el dispositivo del destinatario puede estar infectado — el portátil de un empleado corre un Chrome desactualizado, el malware extrae archivos ya descifrados. Cada decisión de diseño fluye de estas tres premisas.
Cifrado en el cliente como primer principio
Si el servidor puede ver texto en claro, no es zero-trust. Todo comienza con el navegador del remitente ejecutando la Web Crypto API: generar una clave de 256 bits, derivarla de la contraseña del usuario con PBKDF2 a 600 000 iteraciones, cifrar el archivo con AES-256-GCM y solo entonces transmitir el texto cifrado al servidor. Firefox Send demostró que esto funcionaba a escala de consumidor antes de que Mozilla lo cerrara en 2020. Sus sucesores modernos — HexaTransfer, Wormhole, Skiff — retoman el patrón. El servidor retiene bytes que no puede leer.
El material de clave nunca abandona los extremos
La clave de descifrado debe llegar al destinatario sin pasar por el servidor. Dos mecanismos funcionan. Primero, el truco del fragmento de URL: la clave vive tras # en la URL de descarga, que los navegadores nunca envían en las peticiones HTTP. Segundo, claves derivadas de contraseña: el remitente comunica la contraseña al destinatario por un canal separado (Signal, llamada telefónica, 1Password Psst!), y el navegador del destinatario vuelve a derivar la clave. Ambos mantienen el material de clave fuera de los logs del servidor, las cachés de CDN y las copias de seguridad de la base de datos — algo que importa cuando se produce la inevitable brecha.
Verificar el código que se ejecuta en el navegador
Zero-trust en el cliente es más difícil que en el servidor porque el servidor envía el JavaScript que realiza el cifrado. Un servidor malicioso podría entregar un bundle con puerta trasera dirigido a un usuario concreto. Mitigaciones: publicar hashes SHA-384 de cada versión, firmarlos con Sigstore o una clave PGP corporativa, y animar a los usuarios avanzados a verificar con extensiones de navegador como Code Verify (Meta la distribuye para WhatsApp Web). Las cabeceras CSP con script-src 'self' y Subresource Integrity bloquean la inyección desde CDN comprometidas. Nada de esto es perfecto, pero reduce la superficie de ataque.
Autenticación sin secretos compartidos almacenados en reposo
Las contraseñas enviadas por correo y almacenadas en bases de datos del servidor son la antítesis de zero-trust. Sustitúyelas por passkeys WebAuthn vinculadas al dispositivo del destinatario — la clave privada nunca sale del Secure Enclave, y el servidor solo almacena la clave pública. Para transferencias puntuales, usa OPAQUE (RFC 9380) para autenticación con contraseña que nunca la transmite ni la almacena en el servidor. Los magic links enviados a correos verificados previamente ofrecen un camino intermedio: la entropía del token (128 bits) sustituye la necesidad de un secreto almacenado.
Segmentar transferencias por nivel de sensibilidad
No todos los archivos merecen los mismos controles. Un servicio de transferencia zero-trust debería permitir a los remitentes clasificar las subidas: público (sin contraseña, caducidad de 7 días), interno (contraseña, caducidad de 48 horas), confidencial (contraseña + 2FA, caducidad de 4 horas, descarga única), restringido (passkey + vinculación de IP + caducidad de 15 minutos). Automatiza la clasificación por tipo de archivo cuando sea posible: declaraciones de IRPF en .pdf → confidencial; contratos en .docx → interno; composiciones de marketing en .psd → público. NIST SP 800-171 llama a esto gestión de información no clasificada controlada, y encaja perfectamente en los flujos de trabajo de transferencia.
Tratar el dispositivo del destinatario como no confiable
Una vez que Bob descifra el informe legal de 5 MB de Alice, este queda en su carpeta de Descargas. Si su portátil está comprometido, el archivo se filtra. El pensamiento zero-trust se extiende aquí: anima a los destinatarios a descifrar en almacenamiento efímero (Tails OS, una sesión de invitado en Chrome OS), a evitar descifrar en máquinas compartidas y a borrar agresivamente tras el uso. Para transferencias de alto riesgo, utiliza visores protegidos que descifren en una pestaña del navegador con sandbox e impidan la descarga — el destinatario ve el .pdf pero nunca obtiene los bytes en disco. Obviamente esto implica un coste en experiencia de usuario; resérvalo para el nivel superior.
Registrar sin convertirse en un sistema de vigilancia
Un registro de auditoría zero-trust anota lo imprescindible para la respuesta a incidentes y el cumplimiento, nada más. Aplica hash a las IPs diariamente, almacena solo familias de User-Agent (no cadenas completas), nunca registres contraseñas ni claves, y retén durante el período mínimo que exige cada normativa — 90 días para el artículo 30 del RGPD, 6 años para HIPAA 164.316. El propio log vive en almacenamiento de solo adición (S3 Object Lock, modo compliance) para que un administrador comprometido no pueda borrar sus huellas. Publicar raíces Merkle diariamente en un tablón de anuncios público añade verificación externa.
Donde zero-trust se encuentra con la realidad jurídica
Zero-trust no te exime de las solicitudes de las fuerzas del orden. Cambia lo que puedes entregar — texto cifrado que no puedes descifrar, hashes de IP que no puedes revertir, logs de quién accedió a qué slug. Eso suele ser suficiente para satisfacer una orden judicial válida mientras se mantiene la privacidad de los datos frente a la vigilancia masiva. Publica un informe de transparencia (el antiguo modelo de Twitter) que muestre volúmenes de solicitudes y tasas de respuesta. Documenta tu minimización de datos en la política de privacidad para que los usuarios entiendan las compensaciones: puedes verificar que un archivo se transfirió, pero no puedes leerlo ni identificar al destinatario con certeza.
Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo