Как шифровать резервные копии базы данных PostgreSQL

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

Зачем шифровать резервные копии PostgreSQL

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

Риски незашифрованных резервных копий

Подумайте, куда ваши резервные копии могут путешествовать:

Облачное хранилище: S3 buckets, Google Cloud Storage, Azure Blob - неправильно настроенные разрешения выявили бесчисленные базы данных
Трансферные сети: Резервные копии, перемещающиеся между серверами, могут быть перехвачены
Запасное хранилище: Физические средства могут быть потеряны, украдены или неправильно утилизированы
Доступ команды: Разработчики и подрядчики могут получить доступ к резервному хранению по законным причинам
Аудиторы соблюдения: Некоторые правила требуют доказательства того, что резервные данные защищены

Без шифрования, одна неправильная конфигурация или инсайдерская угроза подвергает все. С шифрованием скомпрометированные архивные файлы остаются защищенными.

Подходы шифрования для резервного копирования PostgreSQL

Существует несколько методов для шифрования резервных копий PostgreSQL. Каждый имеет компромисс между сложностью, безопасностью и возможностями автоматизации.

GPG шифрование

GNU Privacy Guard (GPG) - наиболее распространенный подход для шифрования резервных файлов. Он работает с любым резервным форматом — pg_dump SQL-файлы, свалки пользовательского формата и архивы tar.

Симметрическое шифрование использует одну фразу:

1
2
3
4
5
# Create encrypted backup
pg_dump -Fc mydb | gpg --symmetric --cipher-algo AES256 -o backup.dump.gpg

# Decrypt for restoration
gpg --decrypt backup.dump.gpg | pg_restore -d mydb

Асимметричное шифрование использует публичную/частную пару ключей:

1
2
3
4
5
6
7
8
# Generate key pair (one-time setup)
gpg --full-generate-key

# Encrypt with public key
pg_dump -Fc mydb | gpg --encrypt --recipient your@email.com -o backup.dump.gpg

# Decrypt with private key
gpg --decrypt backup.dump.gpg | pg_restore -d mydb

Асимметричное шифрование лучше для команд — резервная система нуждается только в публичном ключе, в то время как частный ключ остается защищенным отдельно.

OpenSSL шифрование

OpenSSL предоставляет еще один вариант для резервного шифрования, доступный на большинстве систем:

1
2
3
4
5
# Encrypt backup
pg_dump -Fc mydb | openssl enc -aes-256-cbc -salt -pbkdf2 -out backup.dump.enc

# Decrypt for restoration
openssl enc -d -aes-256-cbc -pbkdf2 -in backup.dump.enc | pg_restore -d mydb

OpenSSL задает пароль. Для автоматизации вы можете передавать его через переменную среды (менее безопасный) или файл:

1
2
# Using password file
pg_dump -Fc mydb | openssl enc -aes-256-cbc -salt -pbkdf2 -pass file:/secure/backup.key -out backup.dump.enc

Age шифрование

Age - современный инструмент шифрования, предназначенный для того, чтобы быть проще, чем GPG:

1
2
3
4
5
6
7
8
# Generate key pair
age-keygen -o key.txt

# Encrypt backup
pg_dump -Fc mydb | age -r age1publickey... -o backup.dump.age

# Decrypt for restoration
age --decrypt -i key.txt backup.dump.age | pg_restore -d mydb

Age имеет более чистый интерфейс и меньшую поверхность атаки, чем GPG. Стоит подумать о новых реализациях.

Шифрование резервных копий pg_dump

pg_dump - это стандартный инструмент резервного копирования PostgreSQL. Объединение его с шифрованием создает безопасные резервные файлы.

Автоматизированный зашифрованный сценарий резервного копирования

Вот полный сценарий для зашифрованных резервных копий:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#!/bin/bash
set -euo pipefail

# Configuration
DB_NAME="mydb"
BACKUP_DIR="/backup"
ENCRYPTION_KEY="/secure/backup.pub"  # GPG public key
RETENTION_DAYS=30

# Generate filename with timestamp
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_${TIMESTAMP}.dump.gpg"
CHECKSUM_FILE="${BACKUP_FILE}.sha256"

# Create encrypted backup
pg_dump -Fc "$DB_NAME" | gpg --encrypt --recipient-file "$ENCRYPTION_KEY" > "$BACKUP_FILE"

# Calculate checksum of encrypted file
sha256sum "$BACKUP_FILE" > "$CHECKSUM_FILE"

# Verify backup can be read (structure only, doesn't need private key)
gpg --list-packets "$BACKUP_FILE" > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "ERROR: Encrypted backup verification failed"
    exit 1
fi

# Clean old backups
find "$BACKUP_DIR" -name "*.dump.gpg" -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -name "*.sha256" -mtime +$RETENTION_DAYS -delete

echo "Backup completed: $BACKUP_FILE"

Этот сценарий создает зашифрованные резервные копии, вычисляет контрольные суммы и управляет удержанием автоматически.

Сжатия и шифрования

При объединении сжатия и шифрования, порядок имеет значение:

Затем зашифровать (рекомендуется):

1
pg_dump mydb | gzip | gpg --encrypt -r backup@example.com > backup.sql.gz.gpg

Сжатие перед шифрованием создает меньшие файлы. Зашифрованные данные не сжимаются хорошо, потому что они кажутся случайными.

Пользовательский формат уже сжаты:

Пользовательский формат pg_dump (-Fc) включает в себя сжатие по умолчанию. Добавление внешнего сжатия не дает преимуществ:

1
2
3
4
5
# This is redundant - custom format is already compressed
pg_dump -Fc mydb | gzip | gpg --encrypt -r backup@example.com > backup.dump.gz.gpg

# Better approach for custom format
pg_dump -Fc mydb | gpg --encrypt -r backup@example.com > backup.dump.gpg

Поток зашифрованных резервных копий в облачное хранилище

Зашифровать резервные копии во время загрузки, чтобы избежать записи незашифрованных данных на диск:

1
2
3
4
5
# Stream encrypted backup directly to S3
pg_dump -Fc mydb | gpg --encrypt -r backup@example.com | aws s3 cp - s3://bucket/backup.dump.gpg

# Stream from S3 and decrypt for restoration
aws s3 cp s3://bucket/backup.dump.gpg - | gpg --decrypt | pg_restore -d mydb

Этот подход сохраняет незашифрованные резервные данные полностью в памяти.

Управление ключами для резервного шифрования

Шифрование так же безопасно, как и управление ключами. Потерянные ключи означают невосстановимые резервные копии. Компромиссные ключи означают скомпрометированные резервные копии.

Основные методы хранения

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

Хранить ключи в специальном секретном менеджере (OpenBao - форк Vault с открытой лицензией.)
Используйте модули безопасности оборудования (HSM) для самых высоких требований безопасности
Сохранить офлайн копии ключей в защищенных физических местах
Применение ключевых процедур ротации

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

Стратегия ротации

Ротирование ключей шифрования ограничивает влияние ключевого компромисса:

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

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

1
BACKUP_FILE="${DB_NAME}_${TIMESTAMP}_keyv2.dump.gpg"

Процедуры доступа

Что происходит, когда человек с ключевым доступом недоступен? План:

Несколько человек с ключевым доступом
Documented procedures for emergency key rerieval
Регулярное тестирование ключевого доступа различных членов команды
Обеспечение непрерывности деятельности

Проверка зашифрованных резервных копий

Зашифрованные резервные копии нуждаются в проверке, как и любые другие резервные копии. Вы не можете видеть содержимое без расшифровки, поэтому проверка требует больше шагов.

Проверка расшифровки

Регулярно проверять резервные копии можно расшифровать:

1
2
3
# Verify GPG can decrypt (outputs to /dev/null, doesn't restore)
gpg --decrypt backup.dump.gpg > /dev/null 2>&1
echo "Decryption test exit code: $?"

Это подтверждает, что правильный ключ расшифровывает резервную копию, не выполняя полного восстановления.

Полное восстановление

Периодически выполнить полное восстановление зашифрованных резервных копий:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
#!/bin/bash
TEST_DB="restore_test_$(date +%s)"

# Decrypt and restore
gpg --decrypt backup.dump.gpg | pg_restore -d "$TEST_DB"

# Run validation queries
psql -c "SELECT count(*) FROM important_table" "$TEST_DB"

# Cleanup
dropdb "$TEST_DB"

Запланируйте эти тесты минимум на месяц. Ежеквартально приемлем для менее критических систем.

Шифрование резервных переводов

Данные уязвимы во время передачи. Зашифруйте резервные копии в пути, даже если они будут зашифрованы в состоянии покоя.

Безопасная копия с SCP/SFTP

SCP и SFTP используют шифрование SSH для передачи:

1
2
3
4
5
# Transfer backup over encrypted SSH connection
scp backup.dump.gpg user@backup-server:/backups/

# Using rsync over SSH
rsync -avz -e ssh backup.dump.gpg user@backup-server:/backups/

Резервный файл уже зашифрован, и SSH добавляет второй слой шифрования во время передачи.

Выбор алгоритма шифрования

Не все шифрование равно. Выбор алгоритма влияет на безопасность и производительность.

Избегайте более старых алгоритмов, таких как DES, 3DES и RC4. Они имеют известные слабости или недостаточную длину ключа.

Соображения

Современные процессоры включают аппаратное ускорение AES (AES-NI). При поддержке оборудования шифрование AES добавляет минимальный накладный — обычно менее 5% к времени резервного копирования.

Проверьте, поддерживает ли ваша система AES-NI:

1
2
3
4
5
# Linux
grep -o aes /proc/cpuinfo | head -1

# macOS
sysctl -a | grep machdep.cpu.features | grep -i aes

Без аппаратного ускорения ChaCha20-Poly1305 может быть быстрее. Но большинство серверов, построенных за последнее десятилетие, имеют AES-NI.

Ошибки шифрования

Несколько распространенных ошибок подрывают безопасность резервного шифрования.

Хранение ключей с резервными копиями

Самая распространенная ошибка. Если ключи и резервные копии вместе, шифрование не обеспечивает защиты от компромисса с хранилищем:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Wrong - key in same directory as backups
/backups/
  backup.dump.gpg
  encryption.key  # Attacker gets both

# Right - keys stored separately
/backups/
  backup.dump.gpg

/secure/keys/  # Different storage, different access controls
  encryption.key

Слабые пассфразы

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

1
2
3
4
5
# Generate random key file
openssl rand -base64 32 > /secure/backup.key

# Use key file for encryption
pg_dump -Fc mydb | gpg --symmetric --passphrase-file /secure/backup.key --batch -o backup.dump.gpg

Шифрование для «внутренних» резервных копий

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

Завершение

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

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

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

Вы можете поделиться статьей со своими друзьями в социальных сетях, которым может быть интересна эта статья или просто оставить комментарий ниже. Спасибо.

Зачем шифровать резервные копии PostgreSQL#

Риски незашифрованных резервных копий#

Подходы шифрования для резервного копирования PostgreSQL#

GPG шифрование#

OpenSSL шифрование#

Age шифрование#

Шифрование резервных копий pg_dump#

Автоматизированный зашифрованный сценарий резервного копирования#

Сжатия и шифрования#

Поток зашифрованных резервных копий в облачное хранилище#

Управление ключами для резервного шифрования#

Основные методы хранения#

Стратегия ротации#

Процедуры доступа#

Проверка зашифрованных резервных копий#

Проверка расшифровки#

Полное восстановление#

Шифрование резервных переводов#

Безопасная копия с SCP/SFTP#

Выбор алгоритма шифрования#

Соображения#

Ошибки шифрования#

Хранение ключей с резервными копиями#

Слабые пассфразы#

Шифрование для «внутренних» резервных копий#

Завершение#