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

Безопасная передача проектных файлов означает, что файлы нечитаемы для всех, кроме отправителя и получателя, — включая сам сервис передачи. Это обеспечивается сквозным шифрованием 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 ГБ.