Ir al contenido
HexaTransfer
Volver al blog
Transferencia de archivos

Transferir archivos de proyecto de forma segura: cifrado

Transfiere archivos de proyecto de forma segura a tu equipo. El cifrado de extremo a extremo mantiene los datos confidenciales en tránsito.

Transferir archivos de proyecto de forma segura significa que los archivos son ilegibles para cualquiera excepto el remitente y el destinatario —incluido el propio servicio de transferencia. El mecanismo que lo garantiza es el cifrado de extremo a extremo con AES-256-GCM, con clave derivada de una contraseña que ambas partes acuerdan por un canal separado al del enlace. La subida cifra en el navegador; la descarga descifra en el navegador. El servidor solo almacena texto cifrado. Slack, los adjuntos de email y el almacenamiento en la nube convencional no alcanzan ese nivel. Para archivos de proyecto que contienen especificaciones de producto, código no publicado o datos de clientes bajo NDA, un enlace de transferencia de conocimiento cero es el canal mínimo aceptable.

Qué hace que una transferencia sea "segura" en términos concretos

"Seguro" es una palabra que las empresas usan con demasiada libertad. Esta es la lista de verificación con especificaciones reales:

  • Cifrado en tránsito: TLS 1.3 (RFC 8446) con suites de cifrado modernas (TLS_AES_256_GCM_SHA384). Estándar en todos los navegadores y servidores importantes desde 2018.
  • Cifrado en reposo: AES-256 en la capa de almacenamiento, con rotación de claves. Cualquier proveedor serio lo ofrece.
  • Cifrado de extremo a extremo (E2EE): la clave de texto plano nunca existe en el servidor. Esta es la parte difícil —la mayoría de los servicios "seguros" la omiten.
  • Cifrado autenticado: AES-256-GCM (NIST SP 800-38D) produce un texto cifrado y una etiqueta de 128 bits. La manipulación es detectable al descifrar.
  • Derivación de clave robusta: PBKDF2-HMAC-SHA256 con 600.000+ iteraciones (guía OWASP 2023) o Argon2id.
  • Sin filtración de metadatos: los nombres de archivo y tamaños no se exponen al servidor más allá de lo necesario.
  • Caducidad y revocación: los enlaces se eliminan automáticamente; el remitente puede revocarlos antes de que expiren.

La mayoría de las herramientas empresariales marcan los dos primeros. Muy pocas marcan los siete.

Por qué Slack, el email y OneDrive no son suficientes

El plan gratuito de Slack comprime los adjuntos, limita a 1 GB por archivo en los planes de pago, y almacena todo en AWS con Slack como poseedor de las claves de descifrado. Un administrador de Slack —o cualquiera con acceso a la exportación del espacio de trabajo— puede leer cualquier archivo subido. Está bien para un documento público de marketing; no está bien para una sala de datos de fusiones y adquisiciones.

El correo electrónico (SMTP + TLS) está cifrado salto a salto, lo que significa que cada servidor de correo en la ruta descifra y vuelve a cifrar. S/MIME y PGP son de extremo a extremo, pero requieren una gestión de certificados y claves que el 99% de los equipos nunca configura.

OneDrive, Google Drive y Dropbox cifran en reposo. El proveedor guarda las claves. Una orden judicial válida, un administrador deshonesto o una brecha en el servicio de gestión de claves expone todos los archivos.

Cifrado de extremo a extremo, paso a paso

Esto es lo que ocurre cuando subes un archivo de proyecto a un servicio de transferencia E2EE correctamente implementado:

  1. Introduces una contraseña en el navegador. El servicio deriva una clave de 256 bits con PBKDF2-HMAC-SHA256, usando una sal aleatoria de 128 bits y 600.000 iteraciones. La contraseña nunca sale del navegador.
  2. El archivo se divide en fragmentos de 5 MB. Cada fragmento recibe un IV (nonce) de 96 bits nuevo.
  3. Cada fragmento se cifra con AES-256-GCM. Resultado: texto cifrado + etiqueta de autenticación de 128 bits por fragmento.
  4. Los fragmentos cifrados se suben al servidor mediante TLS 1.3. El servidor ve bytes cifrados, el IV y la etiqueta. Nunca la clave, nunca la contraseña.
  5. El servicio devuelve una URL. Compartes la URL por un canal (email, Slack) y la contraseña por otro (SMS, llamada, bóveda compartida en un gestor de contraseñas).
  6. El destinatario abre la URL, introduce la contraseña, el navegador deriva la misma clave (la sal se envía con el texto cifrado), descifra cada fragmento y reensambla el archivo.

Si el servidor se ve comprometido mañana, el atacante obtiene texto cifrado y sales —inútiles sin la contraseña. Eso es conocimiento cero por construcción.

Proteger el canal de la contraseña

El cifrado más sólido falla si la contraseña viaja en el mismo email que el enlace. Canales separados:

  • Enlace por email, contraseña por SMS
  • Enlace por Slack DM, contraseña por Signal
  • Enlace en la herramienta de gestión de proyectos, contraseña en una bóveda compartida de 1Password
  • Para situaciones de alto riesgo: enlace en línea, contraseña por llamada telefónica

Para equipos, usa un gestor de contraseñas (1Password, Bitwarden, Keeper) con bóvedas compartidas delimitadas al proyecto. La contraseña vive ahí; las personas la ven al unirse a la bóveda; nadie la pega en un email.

Tipos de archivos de proyecto y qué contienen

| Archivo | Contenido típico | Por qué importa el cifrado | | --- | --- | --- | | .fig backup Figma | UI no publicada, marcas comerciales | Riesgo de filtración competitiva | | .rvt modelo Revit | Planos de edificio, dirección del cliente | Implicaciones de seguridad física | | .psd master Photoshop | Creatividad de campaña pre-lanzamiento | Riesgo para la reputación de marca | | .docx borrador de contrato | Precios, condiciones, partes | Responsabilidad por incumplimiento de NDA | | .zip código fuente | Algoritmos propietarios | Robo de propiedad intelectual | | .dicom imagen médica | Información sanitaria del paciente | Infracción HIPAA / RGPD | | .csv exportación de clientes | Datos personales | RGPD Art. 32 activado |

Un servicio de transferencia que puede leer el archivo es parte del riesgo. El E2EE elimina el servicio del modelo de amenaza.

Retención y ciclo de vida del proyecto

Alinea la caducidad de la transferencia con los hitos del proyecto. Para un entregable de un sprint de dos semanas, una caducidad de 14 días es perfecta —el archivo desaparece cuando termina el sprint. Para un informe trimestral de cliente, 30 días. Para una sala de datos de fusiones y adquisiciones a largo plazo, usa un VDR (Virtual Data Room) dedicado como Intralinks o Firmex, no un enlace de transferencia de propósito general.

Tras la caducidad, verifica si algo fue reenviado. Si el mismo archivo de proyecto circula por cinco transferencias separadas, es mejor ubicarlo en un espacio de trabajo cifrado compartido (Tresorit, Proton Drive, o un Nextcloud autohospedado con cifrado del lado del servidor).

Registros de auditoría para equipos regulados

Los equipos bajo ISO 27001, SOC 2 Type II o RGPD necesitan registrar quién envió qué, cuándo y cuándo se descargó. Un buen servicio de transferencia expone:

  • Identidad del remitente (o marca de tiempo de subida + IP si es anónimo)
  • Marca(s) de tiempo de descarga del destinatario
  • Marca de tiempo de caducidad y eliminación
  • Webhook en la descarga, por email o publicado en Slack

HexaTransfer registra estos eventos sin almacenar el contenido del archivo en texto plano. El registro de auditoría confirma la entrega sin romper la propiedad de conocimiento cero.

Comparativa de transferencia segura para equipos

| Servicio | Cifrado E2E | Contraseña en enlace | Caducidad | Webhook descarga | Tamaño máx. (gratuito) | | --- | --- | --- | --- | --- | --- | | Subida a Slack | No | No | Retención del espacio de trabajo | No | 1 GB | | Enlace Google Drive | No | Opcional | Manual | No | Cuota 15 GB | | Tresorit Send | Sí (asistido servidor) | Sí | Hasta 7 días | Sí | 5 GB gratuito | | WeTransfer Pro | No | Sí | Hasta 365 días | Sí | 20 GB | | HexaTransfer | Sí (AES-256-GCM en navegador) | Sí | Configurable | Sí | 10 GB |

Un último apunte: no cifres lo que ya está cifrado

Si el archivo fuente es un .asc cifrado con GPG o un .7z con AES-256 ya incorporado, añadir cifrado en la capa del navegador es redundante y no aporta seguridad adicional. Elige una capa, hazla bien, comunica la clave fuera de banda y sigue adelante.

La transferencia segura trata del modelo de amenaza, no del texto de marketing. El E2EE coloca el control donde debe estar: en las dos personas que deberían poder leer el archivo.

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