Categories
Database Backup

** Learn how to protect enterprise database archives from ransomware using immutable storage. Discover technical implementation steps for AWS S3 Object Lock, ZFS, PostgreSQL, and SQL Server.

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

Для администраторов баз данных (DBA) и DevOps-инженеров традиционной стратегии резервного копирования 3-2-1 уже недостаточно. Чтобы гарантировать сохранность данных, инфраструктурные команды должны принять правило 3-2-1-1, где последняя «1» означает неизменяемое хранилище (immutable storage).

Эта статья представляет собой всесторонний технический обзор проектирования, внедрения и управления неизменяемым хранилищем для архивов баз данных, чтобы обеспечить абсолютную устойчивость к программам-вымогателям.

Механика неизменяемого хранилища

Неизменяемое хранилище основано на архитектуре WORM (Write-Once-Read-Many — «запись один раз, чтение многократно»). Как только данные записаны в неизменяемый целевой объект, они не могут быть изменены, зашифрованы или удалены ни одним пользователем — включая администраторов с правами root или скомпрометированные сервисные учетные записи — до истечения математически установленной временной блокировки.

Режим соответствия (Compliance Mode) против режима управления (Governance Mode)

При внедрении неизменяемости, особенно в облачных объектных хранилищах, таких как AWS S3, Azure Blob или S3-совместимых локальных SAN, необходимо понимать разницу между режимами хранения:

  • Режим управления (Governance Mode): Предотвращает удаление или изменение объектов обычными пользователями. Однако пользователи с определенными правами IAM (например, s3:BypassGovernanceRetention) могут обойти блокировку. Это полезно для тестирования, но недостаточно для защиты от программ-вымогателей, так как злоумышленники часто повышают привилегии до администратора домена или root.
  • Режим соответствия (Compliance Mode): Золотой стандарт защиты от программ-вымогателей. Как только объект заблокирован в режиме соответствия, срок его хранения нельзя сократить, а сам объект не может быть удален кем-либо, включая root-аккаунт AWS. Блокировка принудительно осуществляется на уровне кластера хранения.

Проектирование конвейера неизменяемого резервного копирования

Надежная архитектура архивирования баз данных отделяет активные операции с базой данных от уровня неизменяемого архива. Вы не можете применить неизменяемость к активным файлам баз данных (таким как .mdf/.ldf в SQL Server или каталог pg_data в PostgreSQL), поскольку базам данных требуется постоянный доступ на чтение/запись.

Вместо этого неизменяемость применяется к:
1. Файлам полных и дифференциальных резервных копий: Базовым снимкам базы данных.
2. Журналам транзакций / WAL-файлам: Непрерывному потоку изменений базы данных, необходимых для восстановления на момент времени (Point-in-Time Recovery, PITR).

Целевые хранилища для неизменяемости

Вы можете внедрить неизменяемое хранилище на разных уровнях инфраструктуры:
* Облачное объектное хранилище: AWS S3 Object Lock, Azure Blob Immutable Storage, политики хранения Google Cloud Storage.
* Локальное объектное хранилище: MinIO, Cloudian или Pure Storage FlashBlade с поддержкой API S3 Object Lock.
* Блочное/файловое хранилище: ZFS со снимками «только для чтения» и делегированным администрированием или атрибутами файлов Linux.

Внедрение неизменяемого хранилища: технические руководства

1. Облачное объектное хранилище: AWS S3 Object Lock

Чтобы защитить дампы баз данных и журналы транзакций в AWS, необходимо включить Object Lock при создании бакета.

Сначала создайте бакет с включенным Object Lock:

aws s3api create-bucket 
    --bucket prod-db-archive-immutable 
    --region us-east-1 
    --object-lock-enabled-for-bucket

Затем настройте политику хранения по умолчанию. Для архивов баз данных 30-дневная блокировка соответствия является стандартной базовой линией, гарантирующей наличие месячного запаса неизменяемых резервных копий.

aws s3api put-object-lock-configuration 
    --bucket prod-db-archive-immutable 
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }'

Когда ваш скрипт или агент резервного копирования базы данных отправляет файл в этот бакет, S3 автоматически рассчитывает дату Retain Until Date на основе метки времени создания объекта плюс 30 дней.

2. Локальная неизменяемость: ZFS и атрибуты Linux

Если вы архивируете базы данных на локальный Linux-сервер резервного копирования, вы можете добиться псевдонеизменяемости с помощью команды chattr или истинной неизменяемости с помощью снимков ZFS.

Использование Linux chattr:
Флаг +i (immutable) предотвращает изменение, удаление или переименование файла.

# Создание дампа базы данных
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Сделать резервную копию неизменяемой
sudo chattr +i /backups/mydb_$(date +%F).dump

# Проверка атрибута
lsattr /backups/mydb_$(date +%F).dump
# Вывод: ----i---------e------- /backups/mydb_2023-10-27.dump

Примечание: Хотя chattr останавливает базовые скрипты вымогателей, опытный злоумышленник с root-доступом может просто выполнить chattr -i. Поэтому это должно сочетаться со строгим RBAC и изолированными сетями резервного копирования.

Использование снимков ZFS:
ZFS обеспечивает гораздо более сильную защиту. Создавая снимок и устанавливая на него «удержание» (hold), вы предотвращаете его удаление.

# Создание снимка набора данных резервных копий
zfs snapshot tank/db_backups@archive_$(date +%F)

# Установка удержания на снимок для предотвращения удаления
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Даже root не может удалить этот снимок, не сняв удержание
zfs destroy tank/db_backups@archive_$(date +%F)
# Вывод: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Стратегии архивирования для конкретных баз данных

Для достижения восстановления на момент времени (PITR) необходимо постоянно архивировать журналы транзакций в ваше неизменяемое хранилище.

Архивирование WAL в PostgreSQL с помощью pgBackRest

pgBackRest — это высоконадежный инструмент резервного копирования для PostgreSQL, который нативно поддерживает S3-совместимые хранилища. Чтобы защитить ваши журналы предзаписи (WAL), настройте pgBackRest на отправку данных напрямую в ваш неизменяемый S3-бакет.

В вашем pgbackrest.conf:

[global]
repo1-type=s3
repo1-s3-bucket=prod-db-archive-immutable
repo1-s3-region=us-east-1
repo1-s3-endpoint=s3.amazonaws.com
repo1-s3-key=AKIAIOSFODNN7EXAMPLE
repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Убедитесь, что срок хранения соответствует вашей конфигурации S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2

[prod_cluster]
pg1-path=/var/lib/postgresql/14/main

Важное замечание: Если ваш S3-бакет принудительно применяет 30-дневную блокировку соответствия, а pgBackRest пытается удалить WAL-файлы через 14 дней на основе repo1-retention-archive, вызовы API удаления завершатся ошибкой. Вы должны убедиться, что политика хранения вашего ПО для резервного копирования больше или равна сроку неизменяемой блокировки на уровне хранилища.

Microsoft SQL Server: Резервное копирование по URL

SQL Server поддерживает нативное резервное копирование напрямую в S3-совместимое объектное хранилище. Вы можете настроить задание агента SQL Server для записи файлов .bak и .trn непосредственно в неизменяемый бакет.

CREATE CREDENTIAL [s3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com]
WITH IDENTITY = 'S3 Access Key',
SECRET = 'AccessKeyID:SecretAccessKey';
GO

BACKUP DATABASE [ProductionDB]
TO URL = 's3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com/ProductionDB_Full.bak'
WITH FORMAT, COMPRESSION, STATS = 10;
GO

Автоматизация и оркестрация с помощью CloudSave

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

Корпоративные платформы резервного копирования, такие как CloudSave, упрощают эту архитектуру. CloudSave нативно интегрируется с AWS S3 Object Lock, Azure Blob Immutable Storage и локальными S3-совместимыми API.

При настройке плана резервного копирования базы данных в CloudSave:
1. Платформа автоматически обрабатывает квиесценцию VSS (Volume Shadow Copy Service) для SQL Server или API pg_start_backup() для PostgreSQL.
2. Она передает дедуплицированные, зашифрованные данные резервной копии напрямую в целевое хранилище.
3. CloudSave динамически применяет вызовы WORM API (например, PutObjectRetention) для каждого объекта, идеально согласовывая длительность блокировки хранилища с графиком хранения, определенным политикой.
4. Если злоумышленник скомпрометирует консоль управления CloudSave, он все равно не сможет удалить резервные копии, так как блокировка соответствия обеспечивается базовой инфраструктурой хранения, а не программным обеспечением для резервного копирования.

Лучшие практики для неизменяемых архивов баз данных

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

1. Строгая синхронизация NTP

Неизменяемые блокировки математически привязаны к меткам времени. Если служба NTP (Network Time Protocol) на вашем массиве хранения или сервере резервного копирования скомпрометирована или дает сбой, это может привести к преждевременному истечению срока блокировки или к тому, что она никогда не истечет. Убедитесь, что ваша инфраструктура хранения использует аутентифицированные, избыточные источники NTP.

2. Изоляция ролей и учетных данных IAM

Учетные данные, используемые для записи в неизменяемый бакет, должны иметь только права s3:PutObject и s3:PutObjectRetention. Они никогда не должны иметь прав s3:DeleteObject или s3:PutBucketObjectLockConfiguration.

Пример политики IAM с минимальными привилегиями для агента резервного копирования базы данных:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetBucketObjectLockConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::prod-db-archive-immutable",
                "arn:aws:s3:::prod-db-archive-immutable/*"
            ]
        }
    ]
}

3. Определение срока хранения

Не устанавливайте блокировки соответствия на чрезмерно длительные периоды (например, 7 лет для соответствия требованиям) на вашем основном уровне быстрого восстановления. Базы данных генерируют огромные объемы данных WAL/журналов транзакций. Блокировка этих данных на годы приведет к экспоненциальному росту затрат на хранение.
Вместо этого используйте многоуровневый подход:
* Уровень оперативного восстановления: от 14 до 30 дней неизменяемого хранения для полных копий и журналов.
* Уровень долгосрочного архивирования: ежемесячные полные резервные копии, перемещенные в Glacier/Deep Archive с Vault Lock на 1-7 лет.

4. Регулярное тестирование восстановления в изолированных VPC

Неизменяемость гарантирует, что данные не могут быть удалены, но не гарантирует, что данные свободны от логических повреждений. Вы должны автоматизировать восстановление ваших неизменяемых архивов баз данных в изолированную, «воздушную» (air-gapped) VPC или VLAN. Запускайте DBCC CHECKDB (SQL Server) или pg_amcheck (PostgreSQL) на восстановленных данных, чтобы проверить структурную целостность.

Заключение

Защита от программ-вымогателей — это упражнение в предположении о взломе. К тому времени, когда в вашем SIEM сработает оповещение, злоумышленники, скорее всего, уже попытались скомпрометировать вашу инфраструктуру резервного копирования. Архитектурно выстроив архивы баз данных с использованием неизменяемого хранилища в режиме соответствия, вы лишаете злоумышленников их главного рычага давления. Независимо от того, используете ли вы нативные облачные API, удержания ZFS или корпоративную платформу оркестрации, такую как CloudSave, внедрение WORM-хранилища больше не является опцией — это обязательный столп современного администрирования баз данных и аварийного восстановления.

Рубрики