Шифрование данных в базе: подходы и управление ключами

Если вы зашифруете диск с PostgreSQL, база всё равно будет отдавать приложению открытые данные, а доступ к отдельным полям может стать сложнее после шифрования на стороне приложения. На примере PostgreSQL 16 сравним три уровня защиты и разберём, где хранить ключи, чтобы утечка дампа или диска не превратилась в утечку данных.

Сначала определите, от кого защищаете данные

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

Для примера ниже — PostgreSQL 16. В его стандартной поставке нет встроенного прозрачного шифрования всего содержимого файлов базы данных. Шифрование дисков и файловых систем настраивают отдельно; для работы с отдельными данными можно использовать, в частности, расширение pgcrypto или шифровать значения до отправки в базу.

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

Термин. Шифрование envelope — схема, в которой данные шифрует отдельный ключ данных, а сам этот ключ хранится в зашифрованном виде с помощью ключа управления. Так проще менять доступ и организовать ротацию, не перешифровывая сразу весь массив.

Три подхода и цена каждого

Транспорт — отдельный слой. TLS защищает соединение между приложением и базой от перехвата в сети, но не шифрует данные, уже лежащие в таблице. Если у вас есть требование защищать и сеть, и хранение, настройте оба слоя.

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

Где держать ключи

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

Для приложения типовая схема выглядит так: приложение шифрует чувствительное значение ключом данных, а сервис управления ключами или отдельное защищённое хранилище хранит ключ управления. Ключ данных сохраняют рядом с шифротекстом только в зашифрованном виде. Доступ приложения к ключам задают отдельно от доступа к PostgreSQL, а операции расшифрования попадают в мониторинг.

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

Когда выбирать каждый вариант

Уровень защиты определяется не модой на «шифрование end-to-end», а моделью угроз и тем, какие операции должна выполнять база.

• Диск или файловая система — разумная базовая мера для защиты потерянного носителя. Убедитесь, что бэкапы, снимки дисков и экспортированные дампы защищены отдельно.
• pgcrypto — подходит, если удобно шифровать и расшифровывать значения в запросах PostgreSQL, а администрация сервера входит в доверенную зону. Учитывайте, что функции расширения выполняются внутри сервера базы.
• Шифрование в приложении — выбирайте, если дамп или доступ к таблицам не должен раскрыть содержимое без ключа, которым база не располагает. Это потребует спроектировать поиск, индексацию и ротацию ключей заранее.

Шифрование детерминированным способом может позволить сравнивать одинаковые шифротексты, но выдаёт совпадения значений. Случайное шифрование лучше скрывает повторяемость, зато обычный поиск по равенству не работает. Не выбирайте режим шифрования только ради удобного SQL-запроса: сначала оцените, какую информацию утечёт структура совпадений.

Что ломается после включения шифрования

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

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

Ротация тоже требует плана: старые записи зашифрованы прежним ключом, новые — уже новым. Храните для каждого зашифрованного значения идентификатор версии ключа, чтобы приложение понимало, чем его расшифровывать. Миграцию можно выполнять постепенно, но до начала нужно проверить, что приложение читает обе версии, а повторное шифрование не повреждает данные.

Что делать дальше

1. Составьте список чувствительных полей и мест, где появляются их копии: дампы, реплики, логи, аналитические выгрузки.
2. Запишите модель угроз: достаточно ли защитить выключенный диск или нужно исключить чтение данных через базу и её администраторов.
3. Проверьте запросы к выбранным полям: поиск, сортировку, уникальность, отчёты. Отдельно отметьте те, которые перестанут работать после шифрования в приложении.
4. Спроектируйте хранение ключей, ротацию и восстановление до переноса боевых данных. Проведите тест на копии базы и измерьте задержку операций, которые шифруют или расшифровывают значения.

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