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). След като данните бъдат записани в неизменима цел, те не могат да бъдат модифицирани, криптирани или изтрити от никой потребител – включително администратори с 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. Пълни и диференциални файлове с резервни копия: Базовите снимки (snapshots) на базата данни.
2. Транзакционни логове / WAL файлове: Непрекъснатият поток от промени в базата данни, необходим за възстановяване към определен момент във времето (PITR).

Цели за съхранение за неизменимост

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

Внедряване на неизменимо съхранение: Технически ръководства

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

За да защитите дъмп файловете на базата данни и транзакционните логове в AWS, трябва да активирате Object Lock по време на създаването на кофата (bucket).

Първо, създайте кофата с активиран 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), трябва непрекъснато да архивирате транзакционните логове към вашето неизменимо съхранение.

PostgreSQL WAL архивиране с 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 Agent да записва .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. Редовно тестване на възстановяването в изолирани (air-gapped) VPC

Неизменимостта гарантира, че данните не могат да бъдат изтрити, но не гарантира, че данните са без логическа корупция. Трябва да автоматизирате възстановяването на вашите неизменими архиви на бази данни в изолиран, air-gapped VPC или VLAN. Изпълнете DBCC CHECKDB (SQL Server) или pg_amcheck (PostgreSQL) върху възстановените данни, за да проверите структурната цялост.

Заключение

Защитата срещу рансъмуер е упражнение по приемане на пробив. До момента, в който се задейства сигнал във вашия SIEM, нападателите вероятно вече са се опитали да компрометират вашата инфраструктура за архивиране. Чрез проектиране на вашите архиви на бази данни с помощта на неизменимо съхранение в режим на съответствие, вие лишавате нападателите от основния им лост за влияние. Независимо дали използвате облачни API, ZFS задържания или корпоративна платформа за оркестрация като CloudSave, внедряването на WORM съхранение вече не е опция – то е задължителен стълб на съвременното администриране на бази данни и възстановяване след бедствия.

Категории