В этой статье разберёмся, как зашифровать базу данных PostgreSQL в состоянии покоя (at rest) на Ubuntu. Почему это важно? Потому что даже если ваш сервер защищён, а доступ к базе ограничен, физический доступ к диску или его образу — это всегда риск. Шифрование данных на диске — последний бастион, который не даст злоумышленнику прочитать ваши данные, даже если он украдёт жёсткий диск или получит root-доступ к выключенному серверу. В статье — практические советы, схемы, команды и реальные кейсы. Всё, чтобы быстро поднять защищённый PostgreSQL на Ubuntu и не наступить на грабли.

Как это работает: шифрование базы данных в состоянии покоя

Когда говорят о шифровании PostgreSQL “at rest”, имеют в виду, что данные, которые лежат на диске (таблицы, индексы, WAL-логи, бэкапы), хранятся в зашифрованном виде. Это не то же самое, что шифрование соединения (SSL/TLS) или шифрование отдельных столбцов (column-level encryption). Здесь речь про шифрование всего, что PostgreSQL пишет на диск.

• Transparent Data Encryption (TDE) — встроенного TDE в PostgreSQL пока нет (ожидается в будущих релизах), но есть сторонние патчи и форки.
• Filesystem-level encryption — шифруем весь раздел или папку, где лежит база, средствами ОС (например, LUKS/dm-crypt, eCryptfs, fscrypt).
• Application-level encryption — шифруем данные на уровне приложения, но это отдельная тема.

В этой статье — про второй способ: шифруем диск или раздел, где живёт база, средствами Ubuntu. Это просто, надёжно и не требует пересобирать PostgreSQL или менять код приложения.

Как быстро и просто всё настроить: пошаговая инструкция

Покажу на примере LUKS/dm-crypt — это стандарт для Linux, поддерживается из коробки, надёжен и не требует экзотики. Подходит для VPS, выделенных серверов, домашних машин и даже Raspberry Pi.

1. Подготовка: резервное копирование
   • Перед началом — обязательно сделайте бэкап базы и важных данных.
2. Установка необходимых пакетов
   • На Ubuntu всё нужное уже есть, но на всякий случай:

   
sudo apt update
sudo apt install cryptsetup


3. Остановка PostgreSQL
   • Остановите сервис, чтобы не потерять данные:

   
sudo systemctl stop postgresql


4. Создание нового зашифрованного раздела
   • Лучше всего — выделить отдельный диск или раздел под базу. Если нет — можно использовать файл-контейнер (виртуальный диск).

   
# Пример для отдельного диска /dev/sdb
sudo cryptsetup luksFormat /dev/sdb
sudo cryptsetup luksOpen /dev/sdb pgdata_crypt
sudo mkfs.ext4 /dev/mapper/pgdata_crypt
sudo mkdir /mnt/pgdata
sudo mount /dev/mapper/pgdata_crypt /mnt/pgdata


   • Если хотите использовать файл-контейнер:

   
dd if=/dev/zero of=/root/pgdata.img bs=1M count=10240 # 10 ГБ
sudo cryptsetup luksFormat /root/pgdata.img
sudo cryptsetup luksOpen /root/pgdata.img pgdata_crypt
sudo mkfs.ext4 /dev/mapper/pgdata_crypt
sudo mkdir /mnt/pgdata
sudo mount /dev/mapper/pgdata_crypt /mnt/pgdata


5. Перенос базы данных
   • Копируем данные PostgreSQL на новый раздел:

   
sudo rsync -av /var/lib/postgresql/12/main/ /mnt/pgdata/


6. Меняем права и владельца:


sudo chown -R postgres:postgres /mnt/pgdata


7. Настройка PostgreSQL на новый путь
   • Редактируем /etc/postgresql/12/main/postgresql.conf:

   
data_directory = '/mnt/pgdata'


8. Автоматическое монтирование при загрузке
   • Добавьте запись в /etc/crypttab и /etc/fstab для автоматического открытия и монтирования.

   
# /etc/crypttab
pgdata_crypt /dev/sdb none luks

   # /etc/fstab
/dev/mapper/pgdata_crypt /mnt/pgdata ext4 defaults 0 2


9. Запуск PostgreSQL
   • Запускаем сервис:

   
sudo systemctl start postgresql


Всё! Теперь ваша база лежит на зашифрованном разделе. Без пароля (или ключа) никто не сможет прочитать данные с диска.

Примеры, схемы, практические советы

Способ	Плюсы	Минусы	Когда использовать
LUKS/dm-crypt (раздел)	Просто, надёжно, поддерживается ядром, не требует изменений в PostgreSQL	Требует перезапуска при смене ключа, нужен root для управления	Серверы, VPS, выделенные машины
eCryptfs (каталог)	Можно шифровать отдельные папки, не требует отдельного раздела	Медленнее, не так надёжно, проект устарел	Локальные тестовые стенды, домашние проекты
fscrypt (ext4, f2fs)	Современный, встроен в ядро, шифрует каталоги	Требует ext4/f2fs, не работает на старых системах	Новые проекты, где важна гибкость
Patched PostgreSQL (TDE)	Гранулярное шифрование, можно менять ключи без остановки	Нужно собирать свой билд, неофициально	Финтех, банки, параноидальные проекты

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

Отрицательный кейс: На другом проекте забыли добавить автоматическое открытие раздела в /etc/crypttab. После перезагрузки сервер не поднял базу, пришлось ехать в дата-центр с флешкой и паролем. Вывод: автоматизируйте всё, но не забывайте про безопасность ключей!

Команды и скрипты для автоматизации


# Скрипт для автоматического открытия и монтирования раздела (пример)
#!/bin/bash
cryptsetup luksOpen /dev/sdb pgdata_crypt --key-file /root/pgdata.key
mount /dev/mapper/pgdata_crypt /mnt/pgdata
systemctl start postgresql


Можно интегрировать в systemd-юнит или использовать Ansible для автоматизации развёртывания (см. Ansible crypttab module).

Похожие решения, программы и утилиты

• PostgreSQL TDE патч — экспериментальный, не для продакшена.
• dm-crypt/LUKS — стандарт для Linux.
• eCryptfs — для шифрования папок, но проект устарел.
• fscrypt — современное шифрование каталогов.
• HashiCorp Vault — для хранения ключей и секретов.

Статистика, сравнение с другими решениями

• Скорость работы LUKS/dm-crypt на современных CPU с AES-NI практически не отличается от незашифрованного раздела (разница 2-5%).
• eCryptfs медленнее на 10-20%, особенно на мелких файлах.
• fscrypt — почти не уступает LUKS, но требует ext4/f2fs и свежего ядра.
• Встроенного TDE в PostgreSQL пока нет, но в Oracle и MS SQL — есть (и это одна из причин, почему их любят в enterprise).

Интересные факты и нестандартные способы использования

• Можно хранить ключи для LUKS на USB-брелоке или в TPM-модуле, чтобы автоматизировать запуск без ввода пароля вручную.
• Для особо параноидальных — используйте два ключа: один для автоматизации, второй для аварийного доступа.
• Можно шифровать только WAL-логи или только бэкапы, если основной массив данных не критичен.
• Виртуальные контейнеры (файлы-образы) удобно переносить между серверами — просто копируете файл и открываете на новом сервере.

Новые возможности: автоматизация и скрипты

• Интеграция с systemd — можно сделать сервис, который открывает раздел и стартует PostgreSQL автоматически.
• Использование Ansible/Puppet/Chef для массового развёртывания зашифрованных баз на кластере.
• Скрипты для ротации ключей — можно менять ключи без пересоздания раздела (добавлять/удалять ключи в LUKS).
• Мониторинг состояния шифрования — скрипты для проверки, что база действительно лежит на зашифрованном разделе.

Выводы и рекомендации

Шифрование базы данных PostgreSQL в состоянии покоя на Ubuntu — это не только про безопасность, но и про соответствие требованиям регуляторов, аудиторов и здравого смысла. LUKS/dm-crypt — надёжное, простое и проверенное решение, которое можно внедрить за пару часов. Не забывайте про бэкапы, автоматизацию и хранение ключей — это критично для отказоустойчивости.

Используйте шифрование на всех серверах, где есть хоть какие-то персональные или чувствительные данные. Для продакшена — только dm-crypt/LUKS или fscrypt. Для тестов и домашних проектов — можно поиграться с eCryptfs или контейнерами.

Если нужен VPS для экспериментов — заказать VPS. Для серьёзных задач — выделенный сервер. Не забывайте: безопасность — это не опция, а must-have.

Официальные ресурсы для изучения:

• Документация PostgreSQL
• Debian/Ubuntu cryptsetup wiki
• ArchWiki: PostgreSQL

Вопросы, фидбек и ваши кейсы — приветствуются в комментариях. Шифруйте базы, не доверяйте железу и не забывайте про бэкапы!

---

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

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