Что провайдер облака, клиент синхронизации и хеш файла всё ещё могут увидеть после загрузки незашифрованного файла

Перетащить файл в облако — не «положить в сейф», а отдать открытый текст следующей системе

Потребительское облако легко принять за домашний сейф: файл «всё ещё мой», значит чужой его не откроет. После перетаскивания эти байты уже покинули папку на этом диске. Они становятся объектом, который сервис хранит, синхронизирует, дедуплицирует и — часто — индексирует для превью. Декларации, сканы паспорта, закрытые ключи SSH, дампы базы и таблицы клиентов без маскирования не должны попадать в чужое хранилище и поисковый индекс в открытом виде.

HTTPS закрывает только подслушивание на пути. Он не решает, в каком виде система сохранит файл, у кого ключи, что клиент синхронизации кэширует на этом компьютере и что откроет ссылка для доступа: шифротекст или восстановленный исходник. В предыдущей заметке тот же класс передачи: ключ, вставленный в сессию модели, попадает в историю и сроки хранения. Незашифрованный файл в облаке — та же передача. Получатель уже не вендор модели, а хранилище плюс его каналы синхронизации, превью и дедупликации. Вопрос перед загрузкой не «умное ли это облако». Вопрос: «есть ли в этой копии то, что не должно покинуть устройство в открытом виде».

Дальше опираемся на AWS S3, Google Drive / Google Cloud и iCloud: слои там написаны так, что их можно сверить. Потребительский диск редко формулирует «у кого ключи» таким же предложением, но инженерная модель обычно та же: TLS на проводе, шифрование при хранении ключами сервиса, сверху миниатюры, полнотекстовый поиск или мгновенная загрузка. Яндекс Диск в справке о безопасности говорит другое: данные идут только по зашифрованному соединению, а файлы до 1 ГБ автоматически проверяются антивирусом. Проверка антивирусом предполагает, что содержимое доступно сканеру сервиса. Это не «Яндекс не может расшифровать», и не стоит переносить на Диск формулировки SSE-S3 или «стандартной защиты данных». Сменив продукт, снова откройте страницу безопасности именно этого вендора.

HTTPS, шифрование при хранении и нулевое знание — это три разных замка

Вопрос «облако зашифровано или нет» как да/нет отбрасывает как минимум три слоя. Первый — шифрование при передаче. Браузер или клиент синхронизации отправляет байты по TLS. Путь посередине открытый текст не видит. Этот слой почти везде включён, и именно его обещает замочек в адресной строке.

Второй — шифрование при хранении, то есть серверное. Определение серверного шифрования S3 у AWS прямое: данные шифрует принимающий сервис в месте назначения; S3 шифрует при записи на диски в ЦОД AWS и расшифровывает, когда вы обращаетесь к объекту. С 5 января 2023 года каждая новая загрузка по умолчанию идёт через SSE-S3 (ключи Amazon S3). Алгоритм — AES-256, у каждого объекта свой ключ, корневой ключ AWS ротирует. Пока запрос аутентифицирован и авторизован, «нет разницы, как вы обращаетесь к зашифрованным и незашифрованным объектам». Presigned URL работает одинаково для обоих. Список объектов тоже не отличает зашифрованные от незашифрованных. Иначе говоря, слой защищает украденный диск. Он не значит «AWS не откроет ваш файл».

Публичная формулировка Google для Drive похожа: файлы, которые вы загружаете или создаёте в Docs, Sheets и Slides, «шифруются при передаче и при хранении алгоритмом AES-256». Дополнительная конфиденциальность требует клиентского шифрования Workspace, и этот путь доступен только рабочему или учебному аккаунту, где администратор включил функцию. Только после этого переключателя Google пишет «Google не может расшифровать ваши файлы». У слоя по умолчанию этой фразы нет. Шифрование Google Cloud при хранении по умолчанию ещё прямее: «Мы владеем ключами шифрования по умолчанию и управляем ими». Если вы остаётесь на шифровании по умолчанию, этих ключей у вас нет и ротацию вы не контролируете.

Apple разделяет значение по умолчанию и опцию. В обзоре безопасности данных iCloud стандартная защита данных — настройка аккаунта по умолчанию: данные шифруются, ключи лежат в ЦОД Apple, чтобы Apple могла помочь восстановить доступ. Сквозное шифрование по умолчанию покрывает только часть категорий. На той же странице счёт конкретный: 15 категорий всегда защищены сквозным шифрованием, включая «Здоровье» и связку ключей iCloud. Необязательная расширенная защита данных поднимает число до 25 и добавляет резервные копии iCloud, Фото, Заметки и iCloud Drive. Если расширенную защиту выключить, устройство «безопасно загружает нужные ключи шифрования на серверы Apple». Значение по умолчанию — не «Apple тоже не откроет файлы в iCloud Drive».

Пока ключи у сервиса, что он всё ещё может сделать — и кому это видно

То, что сервис умеет расшифровать, — не пугалка. Это предпосылка функций по умолчанию. Онлайн-превью PDF, миниатюры фото, OCR, полнотекстовый поиск и сортировка «по типу» требуют, чтобы какой-то сервер увидел содержимое или хотя бы открытый индекс, выведенный из него. Google пишет цену клиентского шифрования на той же странице справки: зашифрованные Docs, Sheets и Slides нельзя править в мобильных приложениях, нельзя комментировать в Drive, нет голосового ввода и части дополнений; зашифрованные файлы редактора — не больше 100 МБ; история версий хранит не больше 100 версий. Эти ограничения появляются по конкретной причине: сервер больше не держит ключ, который открывает исходный текст.

AWS так же ясно описывает другую сторону. Когда вы делитесь объектом через presigned URL, доступ получателя выглядит так же, как к незашифрованному объекту. SSE-S3 не превращает «человек открыл ссылку» в «только шифротекст». Оно останавливает «кто унёс диск». Украденный аккаунт, утёкшая ссылка, выгрузка корпоративным администратором и законный запрос идут по пути «авторизованный доступ». Шифрование при хранении по умолчанию этот путь пропускает.

У потребительского диска есть ещё слой: клиент синхронизации. Файл сначала появляется в локальной папке синхронизации, потом уходит на сервер. Даже если облако потом запишет шифрование при хранении, этот компьютер, другой вход на домашнем ПК и офлайн-кэш на телефоне могут каждый оставить открытую копию. Закрыть вкладку браузера недостаточно: файл, который уже лёг в папку синхронизации, от этого не исчезает.

Яндекс в той же справке добавляет бытовую деталь: чужие фото могут оказаться на вашем Диске, если вы вошли в аккаунт на чужом телефоне и включена автозагрузка. Это не про ключи в ЦОД. Это про то, что клиент уже считает устройство доверенным и копирует содержимое как есть. Открытый файл в папке синхронизации живёт по тем же правилам, что и любой другой локальный файл: его видит программа Диска, антивирус на компьютере и любой, кто сел за уже разблокированный сеанс.

Кэш синхронизации, превью, хеш содержимого и ссылка для доступа — это отдельные копии

Слышать «загрузка завершена» как «в облаке одна копия» — значит пропустить копии с обеих сторон. Первая — рабочая копия клиента синхронизации: очередь на отправку, кэш повторных попыток, хвосты после конфликта версий. Вторая — производный файл, который сервер собирает для превью: миниатюра, перекодированное видео, текст OCR. Они часто лежат отдельно от оригинала. Удаление исходника не всегда сразу забирает производный файл.

Третья — хеш содержимого. Многие облака считают хеш всего файла или блоков и используют его для мгновенной загрузки и дедупликации: клиент сначала отправляет хеш; если сервер его уже знает, байты второй раз не едут. Для незашифрованного файла это удобно. Это же признание: «один и тот же открытый текст в системе хранится один раз». Загрузите незашифрованный установщик или публичный PDF — сервер по хешу подтвердит, что файл у вас есть. Загрузите один и тот же внутренний договор с нескольких столов — после дедупликации это всё равно один открытый объект. Зашифруйте на этом устройстве: каждый прогон берёт новый salt и IV, хеш шифротекста другой, мгновенная загрузка не срабатывает. Это не сбой. Это прямое следствие фразы «сервис не видит содержимое».

Apple публикует версию этого даже при включённой расширенной защите данных. В том же обзоре iCloud часть метаданных остаётся под стандартной защитой: контрольные суммы данных файлов и фотографий помогают Apple дедуплицировать и оптимизировать хранилище iCloud и устройств. Для iCloud Drive в список входят «сырые байтовые контрольные суммы содержимого файла и имя файла». Сквозное шифрование тела файла — не то же самое, что «Apple никогда не видит отпечаток байтов». Любую подсказку вендора «уже есть в облаке» или «мгновенная загрузка» читайте так же: совпадение хеша — утверждение о содержимом, не только об аккаунте.

Четвёртая копия — ссылка для доступа или командное пространство. Как только ссылка ушла, обычная модель — «у кого ссылка, тот забирает файл». Вместе с предыдущим разделом: шифрование при хранении по умолчанию не переписывает скачивание в «только шифротекст». В чужом браузере открывается восстановленный исходник. «Ссылка на Диск» в чате и вложение самого файла — разные поверхности. Ушёл ли открытый текст из вашего аккаунта, часто один и тот же ответ.

Почему ZIP с паролем часто не является клиентским шифрованием

«Сжать в ZIP с паролем и загрузить» звучит как клиентское шифрование. Сначала спросите, какой именно шифр ZIP вы использовали. Классическое шифрование PKWARE (ZipCrypto) — потоковый шифр. В 1994 году Эли Бихам и Пол Кохер в работе A Known Plaintext Attack on the PKZIP Stream Cipher написали: шифр слабый и не должен защищать ценные данные; примерно 13–40 байт сжатого известного открытого текста или около 30–200 байт в начале несжатого файла восстанавливали внутреннее представление ключа на тогдашнем персональном компьютере за часы. Современный код опускает планку ниже. bkcrack описывает восстановление минимум по 12 байтам известного открытого текста (из них не меньше 8 подряд): внутреннее состояние возвращается, затем открывается весь архив и другие записи с тем же паролем. Длина пароля в этой атаке не помогает. Цель — состояние потока ключа, а не перебор вашей фразы.

Даже если архиватор перешёл на AES, ZIP всё ещё может оставить в заголовке имена файлов, структуру каталогов и незашифрованные комментарии записей. Список файлов в облаке, поиск и фильтр «по типу» читают именно эти метаданные. Считать «у архива есть пароль» за «облако видит только шум» — пропустить и заголовок, и слабый алгоритм.

Более частая операционная ошибка: зашифрованный архив и readme.txt с паролем оказываются в одной папке и уезжают в синхронизацию вместе. Замок и ключ попадают к одному хранителю. Ни шифрование при хранении, ни пароль ZIP в этом случае не спасают.

Что меняется, если сначала зашифровать на устройстве

У клиентского шифрования узкий критерий: открытый текст становится шифротекстом до того, как покинет устройство; пароль, из которого выводится ключ, не уходит провайдеру хранилища; в обычной работе сервис файл не откроет. Google описывает клиентское шифрование Workspace как «сквозное и между клиентами» и прямо пишет «Google не может расшифровать ваши файлы». Это дополнительный слой, который включает администратор. Это не значение по умолчанию для личного бесплатного Drive. Если вы шифруете сами и потом загружаете, граница та же. Ключи остаются в вашем пароле и на вашем устройстве. Вам неважно, есть ли у конкретного диска переключатель клиентского шифрования.

Проверяемый путь в браузере — AES-GCM через Web Crypto, а не самодельный XOR. Пояснения MDN к AesGcmParams совпадают с NIST SP 800-38D: при одном ключе IV каждый раз должен быть уникальным; спецификация рекомендует IV в 96 бит (12 байт); IV не обязан быть секретом и может лежать открыто рядом с шифротекстом. NIST ставит уникальность жёстко: повтор IV при том же ключе открывает подделку, и это требование почти столь же важно, как секретность ключа. Тег подлинности по умолчанию — 128 бит (16 байт). Неверный пароль или подделанный шифротекст должны завершиться отказом, а не выдать обломанный открытый текст.

Шифрование файлов MakePwd держит эту границу: потоковый AES-256-GCM в текущей вкладке, пароль растягивается PBKDF2-HMAC-SHA256 на 100 000 итераций, у каждого файла свой salt на 16 байт, у каждого блока свой IV на 12 байт, на выходе IV + шифротекст + тег 16 байт. Один файл — до 5 ГБ. Блок по умолчанию — 1 МБ, чтобы не читать весь файл в память сразу. Результат — .lock или .enc, двоичный формат один. Файл и пароль не уходят на сервер. Всеми инструментами можно пользоваться без аккаунта; хранилища паролей, которое берегло бы фразу за вас, нет. Страница отвечает на вопрос «успеет ли это стать шифротекстом, пока не покинуло браузер». Она не загружает файл в чужое облако за вас.

Проверка на месте: канарейка не попадает в очередь загрузки, в Network только шифротекст

Слоган «ничего не загружается» сам себя не доказывает. Разбейте проверку на две части. Сначала убедитесь, что шаг шифрования не отправил открытый текст как рабочие данные. Затем убедитесь, что в облако вы отдаёте шифротекст.

1. Создайте текстовый файл с одним предложением, которого не бывает в настоящей работе, например canary-cloud-20260902-only-once. Имя файла тоже может нести канарейку. Пароль — одноразовая длинная фраза, не тот, которым вы пользуетесь каждый день.
2. Откройте в браузере страницу шифрования файлов. Откройте DevTools, перейдите в Network, включите Preserve log. Выберите файл, введите пароль, скачайте .lock. Вставьте канарейку в фильтр: её не должно быть в строке запроса, в теле и в аналитике. Пароля тоже не должно быть.
3. Откройте скачанный .lock в шестнадцатеричном просмотрщике или редакторе. В заголовке должна быть фиксированная сигнатура, а не только что написанная фраза. Неверный пароль должен завершиться отказом и не создать обломанный открытый файл.
4. Если копия в своём облаке всё же нужна, загружайте .lock, не исходник. После загрузки поищите превью в диске: читаемого текста быть не должно. Пароль в ту же папку синхронизации не кладите.

Первая половина — строка запроса, тело, аналитика — та же проверка, что в Шифрование в браузере: как убедиться, что исходный текст не покинул устройство. Здесь добавляется четвёртый шаг: объект покинул браузер, и слой сменился с «локальный Web Crypto» на «будет ли облако считать это открытым текстом». Канарейка должна жить только в исходнике, который вы оставили себе. Если она всплыла в превью диска или в подсказке мгновенной загрузки — вы всё ещё отправили незашифрованную копию.

Границу удобно отработать на шифровании файлов без аккаунта

Если нужно «сначала шифротекст, потом сами решите, куда его класть», регистрироваться не надо и файл MakePwd не отдаёте. Откройте шифрование файлов, возьмите маленький файл, который можно выбросить, зашифруйте длинным случайным паролем, скачайте .lock и поищите канарейку в Network, как выше. Если пароль должен запомнить человек или его нужно отдать коллеге, возьмите случайную строку 6–128 символов в генераторе паролей (по умолчанию 16; короче 8 сервис помечает как более слабую) и при необходимости отправьте её один раз одноразовой ссылкой, а не положите в ту же папку облака, что и шифротекст. Ключ одноразовой ссылки лежит во фрагменте URL #. Страница чтения открыта получателю.

Шифрование файлов не заменяет переключатель клиентского шифрования у облака и не обещает, как другой продукт будет сканировать шифротекст антивирусом или смотреть имена файлов. В заголовке .lock есть исходное имя, поэтому диск может его увидеть. Если само имя нельзя показывать, перед шифрованием переименуйте файл во что-то бессмысленное. Забытый пароль из шифротекста не восстановить. Держите его там, где контролируете вы.

Частые вопросы

Облако пишет «зашифровано». Может ли сервис всё равно открыть мои файлы?

При шифровании при хранении по умолчанию — обычно да. AWS прямо пишет: серверное шифрование шифрует при записи на диск и расшифровывает при доступе; авторизованный запрос к зашифрованному объекту неотличим от запроса к незашифрованному. Ключи Google для шифрования по умолчанию хранит сам Google. Стандартная защита данных Apple держит большинство ключей в своих ЦОД, чтобы помочь восстановить доступ. Это другой слой, чем «сервис не может расшифровать».

Достаточно ли перед загрузкой упаковать файлы в ZIP с паролем?

Классический ZipCrypto — нет. В 1994 году Бихам и Кохер показали: примерно десяток байт известного открытого текста восстанавливает внутреннее состояние ключа; длина пароля здесь не помогает. Даже архив с AES часто оставляет имена файлов и структуру каталогов в открытом виде. Чтобы облако видело только шифротекст, закончите аутентифицированное шифрование на этом устройстве.

Если сначала зашифровать, сработают ли мгновенная загрузка и превью?

Обычно нет — не по исходным байтам. Мгновенная загрузка сравнивает хеш содержимого; один и тот же открытый текст после нового salt и IV даёт другой хеш. Превью, миниатюры и OCR требуют исходный текст. Это ожидаемая плата: сервис не видит содержимое — и не может собрать превью за вас.

Можно ли держать пароль в той же папке облака, что и файл .lock?

Нет. Шифротекст и пароль в одном аккаунте и одной папке синхронизации — это замок и ключ у одного хранителя. Пароль положите в менеджер паролей или отправьте один раз одноразовой ссылкой. Забытый пароль из .lock не восстановить. Это граница резервной копии с нулевым знанием, а не дефект.

Три вещи, которые стоит помнить перед следующей загрузкой

Первое: замочек в адресной строке и надпись «зашифровано» закрывают путь и украденный диск. Они не закрывают провайдера, администратора и того, у кого ссылка. Второе: кэш синхронизации, производные превью, хеш содержимого и ссылка для доступа могут каждый оставить копию; загрузка без шифрования пускает открытый текст во все эти каналы. Третье: чтобы облако видело только непрозрачные байты, сначала зашифруйте на устройстве AES-256-GCM в .lock / .enc, пароль отправьте другим каналом, затем поищите канарейку в Network и в превью диска.

Если следующий вопрос — не ушёл ли открытый текст как рабочие данные на шаге шифрования, читайте Шифрование в браузере: как убедиться, что исходный текст не покинул устройство. Когда пароль, которым открывается шифротекст, нужно отдать человеку, читайте Почему ключ после решётки в URL удобно класть и когда эта защита ломается и Что остаётся на сервере, когда одноразовую ссылку прочитали один раз. Здесь только сведена в вывод граница: что ещё может остаться видимым после того, как незашифрованный файл попал в потребительское облако.