Шифрование при хранении и при передаче: от чего защищает каждое
Основы3 минРедакция Innovialabs
Коротко
Шифрование при передаче (TLS) защищает данные, пока они идут по сети, а шифрование при хранении — когда они лежат на диске, в базе или бэкапе. Нужны оба, но ни одно не спасает от взлома самого приложения.
Коротко: в чём разница
Данные бывают в трёх состояниях: передаются по сети, хранятся на диске и обрабатываются в памяти. Шифрование закрывает первые два, и это разные задачи.
- Шифрование при передаче (in transit) защищает от того, кто подслушивает или подменяет трафик: публичный Wi-Fi, провайдер, скомпрометированный маршрутизатор.
- Шифрование при хранении (at rest) защищает от того, кто получил физический носитель или файл: украденный ноутбук, списанный диск, утёкший бэкап, доступ к хранилищу в облаке.
Одно не заменяет другое. HTTPS не поможет, если бэкап базы лежит открытым в хранилище, а зашифрованный диск — если пароли идут по сети открытым текстом.
Где применяется каждое
| Слой | Тип | Пример |
|---|---|---|
| Браузер — сервер | В передаче | HTTPS (TLS) на сайте и API |
| Сервер — база данных | В передаче | TLS-подключение к PostgreSQL, MySQL, Redis |
| Между сервисами | В передаче | TLS или mTLS внутри кластера, VPN между площадками |
| Диск сервера, ноутбука | При хранении | Шифрование тома: LUKS, BitLocker, FileVault, шифрование дисков у облачного провайдера |
| База данных | При хранении | Шифрование файлов базы (TDE) или зашифрованный том |
| Бэкапы | При хранении | Шифрование архивов до отправки в хранилище |
| Отдельные поля | При хранении | Field-level encryption для паспортных данных, токенов, медицинских сведений |
От чего это НЕ защищает
Это самый важный раздел. Шифрование — не волшебный щит.
- Взлом приложения. Если злоумышленник нашёл SQL-инъекцию или украл учётку администратора, приложение само расшифрует данные и отдаст их. Для работающей системы зашифрованный диск выглядит обычным.
- Утечка ключей. Если ключ шифрования лежит рядом с данными — в том же репозитории, на том же сервере в открытом файле — защита условная.
- Слабые пароли и XSS. Шифрование не мешает войти под чужим аккаунтом или выполнить скрипт в браузере пользователя.
- Данные в памяти. Во время обработки данные расшифрованы.
- Логи и временные файлы. Если персональные данные пишутся в логи открытым текстом, шифрование базы их не прикроет.
Поэтому шифрование — один слой обороны, наряду с контролем доступа, обновлениями и аудитом.
Минимальная схема для типичного веб-приложения
- HTTPS везде: сертификат на домен, редирект с HTTP, заголовок HSTS. Никаких смешанных страниц.
- TLS до базы данных и кэша, особенно если они на отдельных серверах или в управляемом облачном сервисе.
- Шифрование дисков серверов и рабочих ноутбуков команды. У облачных провайдеров его обычно можно включить для дисков и хранилищ.
- Зашифрованные бэкапы с ключом, который хранится отдельно от самих бэкапов.
- Пароли пользователей не шифруют, а хешируют медленным алгоритмом (bcrypt, scrypt, Argon2). Это не шифрование: обратно пароль получить нельзя, и так и должно быть.
- Field-level encryption для самых чувствительных полей — номеров документов, токенов доступа к сторонним сервисам.
- Секреты и ключи — в менеджере секретов или переменных окружения с ограниченным доступом, не в коде.
Пример проверки, что подключение к PostgreSQL требует TLS:
psql "host=db.example.com dbname=app user=app sslmode=verify-full sslrootcert=ca.pem"
Режим verify-full проверяет и шифрование, и подлинность сервера по сертификату.
Частые ошибки
- Считать, что «облако всё шифрует само», и не проверять бэкапы, экспорт и логи.
- Шифровать бэкапы, но хранить ключ в том же бакете.
- Включить HTTPS на сайте, но ходить в базу по открытой сети без TLS.
- Шифровать пароли обратимо вместо хеширования.
- Не продумать ротацию ключей и восстановление: потерянный ключ означает потерянные данные.