Безопасная передача файлов проекта: шифрованный обмен

Безопасная передача проектных файлов означает, что файлы нечитаемы для всех, кроме отправителя и получателя, — включая сам сервис передачи. Это обеспечивается сквозным шифрованием AES-256-GCM с ключом, который обе стороны согласовывают отдельно от ссылки. При загрузке шифрование происходит в браузере; при скачивании — расшифровка в браузере. Сервер хранит только зашифрованный текст. Slack, email-вложения и обычное облачное хранилище этой планки не достигают. Для проектных файлов, содержащих спецификации продуктов, неопубликованный код или клиентские данные, защищённые NDA, ссылка с нулевым знанием — минимально приемлемый канал.

Что делает передачу «безопасной» конкретно

«Безопасно» — слово, которым злоупотребляют. Вот чек-лист с конкретикой:

Шифрование при передаче: TLS 1.3 (RFC 8446) с современными наборами шифров (TLS_AES_256_GCM_SHA384). Стандарт во всех основных браузерах и серверах с 2018 года.
Шифрование при хранении: AES-256 на уровне хранилища с ротацией ключей. Это делают все серьёзные провайдеры.
Сквозное шифрование (E2EE): ключ в открытом виде никогда не существует на сервере. Это самое сложное — большинство «безопасных» сервисов этого не делают.
Аутентифицированное шифрование: AES-256-GCM (NIST SP 800-38D) выдаёт зашифрованный текст и 128-битный тег. Любое вмешательство обнаруживается при расшифровке.
Надёжная деривация ключа: PBKDF2-HMAC-SHA256 с 600 000+ итераций (руководство OWASP 2023) или Argon2id.
Без утечек метаданных: имена файлов и размеры не раскрываются серверу сверх необходимого.
Срок действия и отзыв: ссылки удаляются автоматически; отправитель может отозвать ссылку до истечения срока.

Большинство корпоративных инструментов выполняют первые два пункта. Очень немногие — все семь.

Почему Slack, email и OneDrive недостаточны

Бесплатный тариф Slack сжимает вложения, на платных тарифах — лимит 1 ГБ на файл; всё хранится на AWS, ключи расшифровки у Slack. Администратор Slack — или любой, у кого есть доступ к экспорту пространства — может прочитать любой загруженный файл. Для публичного маркетингового документа это нормально; для данных по слиянию и поглощению — нет.

Email (SMTP + TLS) шифруется поэтапно: каждый почтовый сервер по маршруту расшифровывает и перешифровывает. S/MIME и PGP сквозные, но требуют управления сертификатами/ключами, которого 99% команд никогда не настраивают.

OneDrive, Google Drive и Dropbox шифруют при хранении — но ключами владеет провайдер. Законное требование суда, недобросовестный администратор или взломанная система управления ключами могут раскрыть любой файл.

Сквозное шифрование шаг за шагом

Вот что происходит при загрузке архива проекта в правильно построенный E2EE-сервис передачи:

Вы вводите пароль в браузере. Сервис получает 256-битный ключ через PBKDF2-HMAC-SHA256: случайная 128-битная соль, 600 000 итераций. Пароль никогда не покидает браузер.
Файл разбивается на чанки по 5 МБ. Каждый получает уникальный 96-битный IV (nonce).
Каждый чанк шифруется AES-256-GCM. Результат: зашифрованный текст + 128-битный тег аутентификации на чанк.
Зашифрованные чанки загружаются на сервер по TLS 1.3. Сервер видит зашифрованные байты, IV и тег — но не ключ, не пароль.
Сервис возвращает URL. Ссылку вы отправляете одним каналом (email, Slack), пароль — другим (SMS, звонок, общий сейф в менеджере паролей).
Получатель открывает URL, вводит пароль, браузер повторно вычисляет тот же ключ (соль передаётся вместе с зашифрованным текстом), расшифровывает каждый чанк и собирает файл.

Если сервер будет взломан завтра, злоумышленник получит зашифрованный текст и соли — без пароля это бесполезно. Нулевое знание по конструкции.

Защита канала передачи пароля

Самое надёжное шифрование бесполезно, если пароль идёт в том же письме, что и ссылка. Раздельные каналы:

Ссылка по email, пароль по SMS
Ссылка в Slack DM, пароль через Signal
Ссылка в системе управления проектами, пароль в 1Password Shared Vault
Для критических случаев: ссылка онлайн, пароль по телефону

Для команд используйте менеджер паролей (1Password, Bitwarden, Keeper) с общими хранилищами, привязанными к проекту. Пароль хранится там; участники видят его, присоединившись к хранилищу — никто не вставляет его в email.

Типы проектных файлов и их содержимое

| Файл | Типичное содержимое | Почему важно шифрование | | --- | --- | --- | | .fig резервная копия Figma | Неопубликованный UI, торговые марки | Риск конкурентной утечки | | .rvt модель Revit | Планы здания, адрес клиента | Последствия для физической безопасности | | .psd мастер Photoshop | Кампания до запуска | Репутационный риск бренда | | .docx черновик договора | Цены, условия, стороны | Ответственность за нарушение NDA | | .zip исходный код | Проприетарные алгоритмы | Кража интеллектуальной собственности | | .dicom медицинские снимки | Данные о здоровье пациента | Нарушение HIPAA / GDPR | | .csv экспорт клиентской базы | Персональные данные | Применение GDPR ст. 32 |

Сервис передачи, способный прочитать файл, становится участником риска. E2EE исключает сервис из модели угроз.

Хранение и жизненный цикл проекта

Согласуйте срок действия ссылки с этапами проекта. Для двухнедельного спринта — 14 дней: файл исчезает, когда заканчивается спринт. Для ежеквартального клиентского отчёта — 30 дней. Для долгосрочного проекта по слиянию и поглощению используйте специализированный VDR (Virtual Data Room) — Intralinks или Firmex, а не универсальную ссылку для передачи.

После истечения срока проверьте, не повторялась ли отправка одного и того же файла через пять разных ссылок. Если да — лучше перенести его в общее зашифрованное рабочее пространство (Tresorit, Proton Drive или self-hosted Nextcloud с шифрованием на сервере).

Журналы аудита для регулируемых команд

Командам, работающим по ISO 27001, SOC 2 Type II или GDPR, необходимо фиксировать, кто, что и когда отправил и скачал. Хороший сервис передачи предоставляет:

Идентификатор отправителя (или временну́ю метку + IP, если анонимно)
Временну́ю метку скачивания получателем
Временну́ю метку истечения срока и удаления
Webhook при скачивании — по email или в Slack

HexaTransfer записывает эти события, не сохраняя содержимое файла в открытом виде. Журнал аудита подтверждает доставку без нарушения принципа нулевого знания.

Сравнение сервисов для командной передачи

| Сервис | Сквозное шифрование | Пароль на ссылку | Срок действия | Webhook при скачивании | Макс. размер (бесплатно) | | --- | --- | --- | --- | --- | --- | | Загрузка файла в Slack | Нет | Нет | Хранение в пространстве | Нет | 1 ГБ | | Ссылка Google Drive | Нет | Опционально | Вручную | Нет | Квота 15 ГБ | | Tresorit Send | Да (на стороне сервера) | Да | До 7 дней | Да | 5 ГБ бесплатно | | WeTransfer Pro | Нет | Да | До 365 дней | Да | 20 ГБ | | HexaTransfer | Да (AES-256-GCM в браузере) | Да | Настраиваемый | Да | 10 ГБ |

Напоследок: не шифруйте дважды то, что уже зашифровано

Если исходный файл — это GPG-зашифрованный .asc или .7z с встроенным AES-256, добавление шифрования на уровне браузера избыточно и не повышает безопасность. Выберите один слой, реализуйте его правильно, передайте ключ вне основного канала — и двигайтесь дальше.

Безопасная передача — это про модель угроз, а не про маркетинговый текст. E2EE передаёт контроль туда, где ему место: к двум людям, которым нужно читать файл.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.