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.

Во современиот пејзаж на закани, рансомот (ransomware) еволуираше од опортунистичко шифрирање во високо насочени кампањи со повеќекратна изнуда. Напредните постојани закани (APT) и синдикатите за рансом сега активно ги бараат инфраструктурите за резервни копии и архивите на базите на податоци за време на нивниот престој во системот. Ако напаѓач ја компромитира вашата примарна база на податоци и истовремено ги избрише или шифрира вашите складишта за резервни копии, вашата организација се соочува со катастрофално губење на податоци.

За администраторите на бази на податоци (DBA) и DevOps инженерите, традиционалната стратегија за резервни копии 3-2-1 веќе не е доволна. За да се гарантира преживувањето на податоците, инфраструктурните тимови мора да го усвојат правилото 3-2-1-1, каде што последната „1“ претставува непроменливо складирање (immutable storage).

Оваа статија обезбедува сеопфатна, техничка анализа за архитектирање, имплементирање и управување со непроменливо складирање за архиви на бази на податоци за да се обезбеди апсолутна отпорност на рансом.

Механиката на непроменливото складирање

Непроменливото складирање се потпира на архитектурата „пиши еднаш, читај многупати“ (WORM). Откако податоците ќе се запишат на непроменлива цел, тие не можат да бидат изменети, шифрирани или избришани од ниту еден корисник — вклучително и администратори со root привилегии или компромитирани сервисни сметки — сè додека не истече математички спроведената временска блокада.

Режим на усогласеност наспроти режим на управување

При имплементирање на непроменливост, особено во облак објектно складирање како AWS S3, Azure Blob или S3-компатибилни локални SAN системи, мора да ја разберете разликата помеѓу режимите на задржување:

  • Режим на управување (Governance Mode): Ги спречува стандардните корисници да бришат или менуваат објекти. Сепак, корисниците со специфични IAM дозволи (на пр., s3:BypassGovernanceRetention) можат да ја заобиколат блокадата. Ова е корисно за тестирање, но недоволно за заштита од рансом, бидејќи напаѓачите често ги ескалираат привилегиите до домен администратор или root.
  • Режим на усогласеност (Compliance Mode): Златниот стандард за одбрана од рансом. Откако објектот ќе се заклучи во режимот на усогласеност, неговиот период на задржување не може да се скрати, а објектот не може да биде избришан од никого, вклучително и од AWS root сметката. Блокадата се спроведува на ниво на кластер за складирање.

Архитектирање на цевковод за непроменливи резервни копии

Робустната архитектура за архивирање на бази на податоци ги одвојува активните операции на базата на податоци од непроменливото ниво на архива. Не можете да примените непроменливост на активни датотеки на базата на податоци (како .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

За да ги заштитите исписите (dumps) на базата на податоци и трансакциските дневници во AWS, мора да овозможите Object Lock во моментот на креирање на bucket-от.

Прво, креирајте го 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
            }
        }
    }'

Кога вашата скрипта или агент за резервна копија на базата на податоци ќе испрати датотека во овој bucket, 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 bucket.

Во вашиот 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 bucket спроведува 30-дневна блокада за усогласеност, но pgBackRest се обидува да ги истече и избрише WAL датотеките по 14 дена врз основа на repo1-retention-archive, повиците за бришење API ќе бидат неуспешни. Мора да се осигурате дека политиката за задржување на вашиот софтвер за резервни копии е поголема или еднаква на непроменливата блокада на ниво на складирање.

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

SQL Server поддржува изворни резервни копии директно до S3-компатибилно објектно складирање. Можете да конфигурирате SQL Server Agent задача за запишување на .bak и .trn датотеки директно во непроменлив bucket.

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 или pg_start_backup() API за PostgreSQL.
2. Ги стримува дедуплицираните, шифрирани податоци од резервната копија директно до целта за складирање.
3. CloudSave динамично ги применува WORM API повиците (на пр., PutObjectRetention) на основа на секој објект, совршено усогласувајќи го времетраењето на блокадата на складирањето со распоредот за задржување дефиниран со политиката.
4. Ако напаѓач ја компромитира конзолата за управување со CloudSave, тие сепак не можат да ги избришат резервните копии, бидејќи блокадата за усогласеност се спроведува од основната инфраструктура за складирање, а не од софтверот за резервни копии.

Најдобри практики за непроменливи архиви на бази на податоци

За да се осигурате дека вашата непроменлива архитектура е навистина отпорна, придржувајте се до следните најдобри практики за системско инженерство:

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

Непроменливите блокади се математички поврзани со временски печати. Ако NTP (Network Time Protocol) услугата на вашата низа за складирање или сервер за резервни копии е компромитирана или отстапува, тоа може да предизвика блокадите да истечат предвреме или никогаш да не истечат. Осигурете се дека вашата инфраструктура за складирање користи автентицирани, редундантни NTP извори.

2. Изолирајте ги IAM улогите и акредитивите

Акредитивите што се користат за пишување во непроменливиот bucket мора да имаат само 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 складирање повеќе не е опционално — тоа е задолжителен столб на модерната администрација на бази на податоци и обновување од катастрофи.

Категории