Шифрование при хранении и при передаче: оба важны

Шифрование при передаче защищает данные в движении — например, между вашим браузером и сервером — с помощью TLS 1.3 с AES-256-GCM или ChaCha20-Poly1305. Шифрование при хранении защищает данные на диске: обычно AES-256-XTS для полнодискового шифрования или AES-256-GCM для отдельных файлов. Ни один из этих видов не достаточен сам по себе. TLS защищает от перехвата в сети, но расшифровывается на сервере; шифрование при хранении защищает данные на диске, но бесполезно, если ключи лежат рядом с шифротекстом. Настоящая защита приходит при использовании обоих видов вместе — в идеале с клиентским (сквозным) шифрованием, чтобы сервер вообще никогда не видел открытый текст.

Две угрозы, два разных контроля

Угрозы выглядят по-разному в зависимости от того, где находятся ваши данные:

При передаче (сетевой путь): злоумышленник в кофейне с анализатором трафика, скомпрометированный маршрутизатор провайдера, перехват на подводных кабелях государственными структурами. Документы Сноудена 2013 года раскрыли программу АНБ MUSCULAR, прослушивающую внутренние оптоволоконные каналы Google. Защита: TLS 1.3, предпочтительно с привязкой сертификата для приложений.

При хранении (диск): украденный ноутбук, утечка резервной ленты, неправильно настроенный S3-бакет, недобросовестный сотрудник дата-центра с доступом к дискам. Взлом Equifax в 2017 году раскрыл 147 миллионов записей частично потому, что данные хранились незашифрованными. Защита: LUKS, BitLocker, FileVault для дисков; AES-256-GCM или AES-256-XTS для файлов или блоков.

Ошибка — считать один вид шифрования заменой другому. TLS не защищает дамп базы данных. Шифрование диска не останавливает атаку «человек посередине».

Как TLS 1.3 защищает данные при передаче

TLS 1.3, стандартизированный в RFC 8446 (2018), — это современный стандарт по умолчанию. Он использует:

Прямую секретность по умолчанию через эфемерный обмен ключами ECDHE. Даже при утечке долгосрочного ключа сервера прошлые сессии остаются защищёнными.
Только AEAD-шифры — AES-128-GCM, AES-256-GCM или ChaCha20-Poly1305. Старые режимы CBC и RC4 исключены.
Рукопожатие за один обмен (1-RTT) или ноль обменов (0-RTT) при возобновлении.
Зашифрованное рукопожатие, чтобы пассивные наблюдатели не видели цепочку сертификатов.

Каждый достоверный сервис передачи файлов — WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer — работает с TLS 1.3 и заголовками HSTS, обязывающими HTTPS минимум на 12 месяцев. Проверить это можно инструментом SSL Labs' testssl; оценка ниже A- означает проблемы с конфигурацией.

Как шифрование при хранении работает на сервере

После того как файлы поступают и TLS завершается, вступает шифрование при хранении. Оно работает на нескольких уровнях:

На уровне блоков (полнодисковое): AES-256-XTS в LUKS (Linux), BitLocker (Windows), FileVault (macOS) или облачные эквиваленты вроде шифрования AWS EBS. Защищает от кражи дисков.
На уровне файловой системы: eCryptfs, Fscrypt на ext4/F2FS. Файлы каждого пользователя шифруются отдельными ключами.
На уровне объектного хранилища: AWS S3 SSE-KMS, Azure Blob с Storage Service Encryption, Google Cloud Storage с ключами под управлением клиента. Каждый объект шифруется AES-256-GCM.
На уровне приложения: сервис шифрует каждый файл в собственном коде перед записью в хранилище, ключи хранятся в KMS или HSM.

Шифрование на уровне приложения — самое надёжное, потому что происходит до того, как какая-либо система хранения видит данные. AWS KMS стоит $1 в месяц за ключ плюс $0,03 за 10 000 запросов — дёшево настолько, что серьёзные сервисы применяют его на каждый файл.

Ловушка «ключей рядом с шифротекстом»

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

Правильные архитектуры разделяют ответственность:

Шифротекст — в S3 или аналогичном объектном хранилище.
Ключи шифрования — в AWS KMS, Google Cloud KMS, Azure Key Vault или выделенном HSM.
Доступ к ключам — через краткосрочные IAM-учётные данные с журналами аудита.

Ещё лучшие архитектуры идут дальше: ключи вообще не существуют на сервере. Клиентское шифрование (E2EE) означает, что браузер пользователя генерирует ключ, шифрует файл и сохраняет ключ у себя. Сервер хранит шифротекст и не имеет что утечь.

Где возникают пробелы в шифровании

Даже при наличии обоих видов шифрования данные кратковременно существуют в открытом виде в нескольких местах:

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

Именно поэтому важно клиентское (нулевого знания) шифрование. Когда файлы шифруются в браузере до загрузки, серверные пробелы становятся несущественными — сервер видит только шифротекст.

Что реально делают крупные сервисы

Примерная классификация на основе публичной документации:

Google Drive, Dropbox, OneDrive: TLS 1.3 при передаче, AES-256 при хранении с ключами на стороне провайдера. Не нулевое знание — провайдер может читать ваши файлы.
WeTransfer (бесплатный уровень): TLS 1.3, AES-256 при хранении на AWS S3. Ключи у провайдера.
Box Enterprise: TLS 1.3, AES-256-GCM при хранении, опциональные ключи под управлением клиента (Box KeySafe).
Tresorit, Proton Drive, SwissTransfer E2EE-уровень, HexaTransfer: TLS 1.3 при передаче, AES-256-GCM при хранении, но ключи для каждого файла генерируются клиентом и никогда не достигают сервера. Фактически нулевое знание.

Для чувствительных данных только последняя категория обеспечивает значимую защиту от внутренних угроз и законных требований о раскрытии.

Соответствие требованиям и принцип «глубокой обороны»

Регуляторы явно требуют оба вида шифрования:

GDPR, статья 32 обязывает к «псевдонимизации и шифрованию персональных данных» без ограничения состояния данных.
HIPAA Security Rule 45 CFR § 164.312(a)(2)(iv) и (e)(2)(ii) требует шифрования ePHI как при передаче, так и при хранении.
PCI DSS 4.0, требования 3 и 4 разделяет «защиту хранимых данных держателя карты» (при хранении) и «защиту данных держателя карты надёжной криптографией при передаче» (при передаче).
FIPS 140-3 распространяется на криптографические модули, применяемые в обоих контекстах.

Обеспечить только один вид — значит провалить требования соответствия ещё до провала безопасности.

Как проверить, что оба вида активны

Пять быстрых проверок для любого сервиса передачи файлов:

Запустите testssl.sh https://provider.com, чтобы убедиться в TLS 1.3 только с надёжными шифрами.
Проверьте заголовки HSTS с max-age не менее 31 536 000 (один год).
Прочитайте документ по безопасности: должно быть явное упоминание AES-256-GCM или AES-256-XTS при хранении.
Убедитесь, что ключи хранятся в KMS или HSM, а не в базе данных приложения.
Проверьте наличие сертификации SOC 2 Type II или ISO 27001 — обе требуют задокументированных мер при хранении и при передаче.

Бонус: проверьте, есть ли опция клиентского шифрования. Если есть — включите её для всего чувствительного.

Как правильно сочетать оба вида

Схема, которая действительно работает:

Браузер шифрует файл случайным ключом AES-256-GCM (клиентская сторона).
Шифротекст передаётся по TLS 1.3 на сервер (при передаче).
Сервер хранит шифротекст в зашифрованном хранилище AES-256 (при хранении).
Ключ расшифровки существует только во фрагменте URL, никогда не отправляясь на сервер.

Три независимых уровня. Взломайте один — остальные держатся. Именно эту архитектуру использует HexaTransfer, вместе с Tresorit Send, ссылками Proton Drive и режимом E2EE SwissTransfer.

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