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-файлів: Безперервного потоку змін бази даних, необхідних для відновлення на певний момент часу (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-сумісні сховища. Щоб захистити ваші журнали Write-Ahead Logs (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 більше не є опцією — це обов’язковий стовп сучасного адміністрування баз даних та відновлення після катастроф.

Категорії