Прямой ответ
Шифрование в покое защищает данные, когда они не используются: на дисках, в файлах БД, в резервных копиях. Его главная практическая ценность — ограничение ущерба при потере носителя, краже оборудования, утилизации дисков или компрометации облачного хранилища.
Важно понимать границу: шифрование в покое не защищает от атакующего, который получил доступ к работающей системе. В этот момент данные расшифрованы и доступны. Поэтому оно дополняет, а не заменяет контроль доступа, журналирование и защиту периметра — см. безопасность баз данных.
Уровни реализации:
- Полное шифрование диска (LUKS, dm-crypt, BitLocker). Прозрачно для приложений, защищает при физической потере носителя. Слабое место — ключ в памяти работающей машины.
- Шифрование файловой системы или каталога (fscrypt). Позволяет шифровать отдельные каталоги с разными ключами.
- Шифрование на уровне БД. Табличные пространства или отдельные поля. Полевое шифрование защищает даже при компрометации учётной записи приложения.
- Шифрование резервных копий. Отдельный обязательный уровень: копии часто лежат в менее защищённом месте и хранятся дольше оригиналов.
- Облачное шифрование с клиентским ключом (envelope encryption). Данные шифруются ключом данных, а ключ данных — главным ключом в KMS.
# LUKS2 на отдельном разделе под данные PostgreSQL
cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 /dev/nvme0n1p2
cryptsetup open /dev/nvme0n1p2 pgdata
mkfs.xfs /dev/mapper/pgdata
-- полевое шифрование через pgcrypto
INSERT INTO customers (id, ssn_enc)
VALUES (42, pgp_sym_encrypt('123-45-6789', current_setting('app.field_key')));
SELECT pgp_sym_decrypt(ssn_enc, current_setting('app.field_key'))
FROM customers WHERE id = 42;
Принципы управления ключами:
- Ключ не хранится рядом с данными. Ключ на том же диске, что и зашифрованные данные, обнуляет смысл шифрования.
- Разделение ролей. Тот, кто имеет доступ к данным, не должен иметь неограниченный доступ к ключам.
- Резервная копия ключа обязательна. Потеря ключа — безвозвратная потеря данных; это более частый инцидент, чем успешная атака.
- Ротация запланирована. Ротация главного ключа должна быть возможной без перешифрования всех данных — это даёт envelope encryption.
Практика: что выбрать и как эксплуатировать
Выбор уровня под угрозу.
| Угроза | Достаточный уровень |
|---|---|
| Потеря или кража диска, утилизация | Полное шифрование диска |
| Доступ к файлам БД без учётных данных | Шифрование каталога или табличных пространств |
| Компрометация учётной записи приложения | Полевое шифрование чувствительных столбцов |
| Утечка из объектного хранилища резервных копий | Шифрование копий ключом, не хранящимся в том же хранилище |
Управление ключами. Для большинства команд рабочая схема — специализированное хранилище секретов с аудитом доступа и версионированием; детали — в статье про Vault и SOPS.
Ротация. Практический подход: главный ключ ротируется по расписанию, ключи данных — при каждом использовании или по сроку. Ротация без возможности расшифровать старые данные — это инцидент, поэтому старые версии ключей сохраняются до полного перешифрования.
Проверка восстановления. Шифрованные резервные копии обязаны регулярно восстанавливаться в тестовом окружении: проверяется и целостность, и доступность ключа.
Рекомендации:
- Не шифруйте «всё подряд» без цели. Шифрование добавляет операции и точки отказа. Определяйте, от какой угрозы защищает каждый уровень.
- Следите за производительностью. Аппаратное ускорение AES (AES-NI) делает шифрование диска почти незаметным, но полевое шифрование на больших объёмах влияет на запросы.
- Ключи в памяти — ограниченная зона. Для полевого шифрования передавайте ключ приложению, а не храните его в конфигурации БД; очищайте настройки сессии после использования.
- Журналируйте доступ к ключам. Обращение к ключу — событие безопасности; необычная активность часто заметнее, чем сама утечка данных.
- Свяжите шифрование с классификацией данных. Разные категории данных требуют разного уровня защиты; классификация — в статье про маскирование PII.
Практический сценарий: утилизация дисков и обнаружение незашифрованных данных
Контекст: сервер выводился из эксплуатации; проверка показала, что часть дисков не была зашифрована, а на одном хранились резервные копии с персональными данными.
- Диагностика. Инвентаризация выявила: том с данными PostgreSQL зашифрован LUKS, а каталог с резервными копиями и дампами — нет. Копии создавались скриптом, который писал в отдельный каталог вне зашифрованного тома.
- Дополнительно. Ключ LUKS хранился в файле на том же сервере, поэтому защита сводилась к защите файловой системы.
- Действия. (а) Диски перед утилизацией уничтожены физически, а не просто отформатированы; (б) каталог резервных копий перенесён на зашифрованный том, дополнительно включено шифрование самих дампов; (в) ключ вынесен во внешнее хранилище с аудитом доступа; (г) скрипт копий исправлен и покрыт тестом, проверяющим путь и факт шифрования результата.
- Проверка. Выполнено тестовое восстановление из зашифрованной копии; время восстановления уложилось в целевое.
- Профилактика. Введена периодическая проверка: автоматическая задача сверяет, что все каталоги с данными и копиями находятся на зашифрованных томах, а отклонение поднимает алерт.
Вывод: шифрование, настроенное «для основной базы», почти всегда оставляет незакрытыми вспомогательные каталоги — копии, дампы, экспорты. Инвентаризация мест хранения важнее выбора алгоритма.
FAQ
Достаточно ли шифрования облачного провайдера по умолчанию? Оно защищает от физической потери носителя в дата-центре, но не от компрометации вашей учётной записи или ошибок в правах доступа. Для чувствительных данных нужен собственный ключ (customer-managed key) или клиентское шифрование.
Что хуже: потерять ключ или быть взломанным? Потеря ключа происходит чаще и приводит к гарантированной безвозвратной потере данных. Поэтому резервная копия ключа с раздельным хранением и проверкой восстановления — обязательная часть схемы.
Нужно ли шифровать данные в оперативной памяти? Обычно нет: это требует специализированных механизмов и даёт ограниченную защиту. Практичнее сокращать время жизни чувствительных данных в памяти и ограничивать доступ к процессу.
Как шифрование связано с правом на удаление? Криптографическое удаление (crypto-erasure) — уничтожение ключа, после которого данные становятся нечитаемыми. Это рабочий приём для архивов и копий, но он не заменяет удаление данных из активных систем, где ключ продолжает использоваться.
Источники: PostgreSQL docs (encryption options), cryptsetup, OWASP Key Management Cheat Sheet — ссылки в шапке.