Файловый обмен с нулевым доверием: не доверяй никому, шифруй всё

Файловый обмен с нулевым доверием (zero-trust) исходит из того, что сеть враждебна, сервер скомпрометирован, а устройство получателя может быть заражено — и шифрует данные соответственно. Файлы шифруются в браузере отправителя с помощью AES-256-GCM ещё до того, как хоть один байт покидает устройство; ключи выводятся из пароля плюс соли, хранящейся во фрагменте URL, а сервер работает только с непрозрачным шифротекстом. Это операционная модель, закреплённая в NIST SP 800-207 применительно к передаче файлов: верифицировать явно, предоставлять минимальные привилегии, считать систему взломанной на каждом уровне.

Три допущения, определяющие архитектуру

Zero trust опирается на три предпосылки. Первая: транспорт скомпрометирован — корпоративные прокси выполняют TLS-инспекцию, Wi-Fi в кафе подвержен ARP-спуфингу, а перехват магистральных каналов на уровне государств задокументирован (Сноуден в 2013 году, Bloomberg подтверждает в 2024-м). Вторая: сервер скомпрометирован — облачные провайдеры взламывают (AWS в 2019-м, Microsoft в 2023-м), администраторы становятся злоумышленниками, а повестки приходят тихо. Третья: устройство получателя может быть заражено — на ноутбуке сотрудника устаревший Chrome, вредоносное ПО собирает расшифрованные файлы. Каждое проектное решение вытекает из этих трёх допущений.

Шифрование на стороне клиента как первый принцип

Если сервер может видеть открытый текст — это не zero trust. Всё начинается с браузера отправителя, запускающего Web Crypto API: сгенерировать 256-битный ключ, вывести его из пароля пользователя с помощью PBKDF2 при 600 000 итерациях, зашифровать файл с помощью AES-256-GCM и лишь затем передавать шифротекст на сервер. Firefox Send доказал, что это работает в потребительском масштабе, прежде чем Mozilla закрыла его в 2020 году. Современные преемники — HexaTransfer, Wormhole, Skiff — используют ту же схему. Сервер хранит байты, которые не может прочитать.

Ключевой материал никогда не покидает конечные точки

Ключ расшифровки должен достигать получателя, не затрагивая сервер. Работают два механизма. Первый — трюк с фрагментом URL: ключ находится после # в ссылке для скачивания, и браузеры никогда не включают его в HTTP-запросы. Второй — ключи, выведенные из пароля: отправитель сообщает получателю пароль через отдельный канал (Signal, телефонный звонок, 1Password Psst!), и браузер получателя заново выводит ключ. Оба подхода исключают попадание ключевого материала в серверные логи, кеши CDN и резервные копии баз данных — что имеет значение при неизбежном нарушении.

Проверка кода, выполняемого в браузере

Zero trust на стороне клиента сложнее реализовать, чем на стороне сервера, поскольку сервер поставляет JavaScript, выполняющий шифрование. Вредоносный сервер мог бы подсунуть backdoor-бандл конкретному целевому пользователю. Меры противодействия: публиковать SHA-384 хеши каждого релиза, подписывать их через Sigstore или корпоративный PGP-ключ, рекомендовать опытным пользователям проверять через расширения браузера, например Code Verify (Meta поставляет его для WhatsApp Web). Заголовки CSP с script-src 'self' и Subresource Integrity блокируют внедрение со скомпрометированных CDN. Ни одно из этих решений не идеально, но они сужают поверхность атаки.

Аутентификация без хранимых общих секретов

Пароли, отправляемые по email и хранящиеся в серверных базах данных, — прямая противоположность zero trust. Замените их на WebAuthn passkey, привязанные к устройству получателя: закрытый ключ никогда не покидает Secure Enclave, а сервер хранит только открытый. Для разовых передач используйте OPAQUE (RFC 9380) для аутентификации по паролю, которая не передаёт и не хранит пароль на стороне сервера. Magic-ссылки, отправляемые на предварительно верифицированный email, предлагают промежуточный вариант: энтропия токена (128 бит) устраняет необходимость в хранимом секрете.

Сегментирование передач по степени конфиденциальности

Не каждый файл заслуживает одинаковых мер контроля. Сервис файлового обмена в духе zero trust должен позволять отправителям классифицировать загрузки: публичные (без пароля, срок 7 дней), внутренние (пароль, срок 48 часов), конфиденциальные (пароль + 2FA, срок 4 часа, одно скачивание), ограниченные (passkey + привязка к IP + срок 15 минут). По возможности автоматизируйте классификацию по типу файла: налоговые декларации PDF → конфиденциальные; контракты DOCX → внутренние; маркетинговые макеты PSD → публичные. NIST SP 800-171 называет это обработкой контролируемой несекретной информации — она точно ложится на рабочие процессы передачи файлов.

Устройство получателя как ненадёжная среда

После того как получатель расшифровал юридическое резюме на 5 МБ, файл лежит в папке «Загрузки». Если ноутбук скомпрометирован — файл утечёт. Логика zero trust распространяется и сюда: рекомендуйте получателям расшифровывать в эфемерное хранилище (Tails OS, гостевая сессия Chrome OS), избегать расшифровки на общих машинах, агрессивно удалять файлы после использования. Для ставок высокой важности используйте защищённые программы просмотра, расшифровывающие в изолированную вкладку браузера и предотвращающие скачивание — получатель видит PDF, но не получает байты на диск. Очевидно, это ухудшает UX; оставьте такой подход для высшего уровня.

Логирование без превращения в систему слежки

Журнал аудита zero trust фиксирует лишь то, что необходимо для реагирования на инциденты и соответствия требованиям. Хешируйте IP-адреса ежедневно, храните только семейства User-Agent (не полные строки), никогда не логируйте пароли или ключи, соблюдайте минимальные сроки хранения по каждому регулятору — 90 дней для целей GDPR статья 30, 6 лет для HIPAA 164.316. Сам лог размещается в append-only хранилище (S3 Object Lock, режим Compliance), чтобы скомпрометированный администратор не мог замести следы. Ежедневная публикация корней Merkle на публичной доске объявлений обеспечивает внешнюю верификацию.

Там, где zero trust встречает правовую реальность

Zero trust не освобождает вас от запросов правоохранительных органов. Он меняет то, что вы можете предоставить: шифротекст, который невозможно расшифровать, IP-хеши, которые нельзя обратить, логи о том, кто обращался к какому slug. Этого, как правило, достаточно для удовлетворения законного ордера при сохранении конфиденциальности данных пользователей от массовой слежки. Публикуйте отчёты о прозрачности по образцу Twitter — объём запросов и частоту ответов. Задокументируйте минимизацию данных в политике конфиденциальности, чтобы пользователи понимали компромиссы: вы можете подтвердить факт передачи файла, но не можете его прочитать или однозначно идентифицировать получателя.

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