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.

V moderním prostředí hrozeb se ransomware vyvinul z oportunistického šifrování na vysoce cílené kampaně s vícenásobným vydíráním. Pokročilé trvalé hrozby (APT) a syndikáty ransomwaru nyní během doby svého působení v síti aktivně vyhledávají zálohovací infrastrukturu a databázové archivy. Pokud útočník kompromituje vaši primární databázi a zároveň smaže nebo zašifruje vaše zálohovací úložiště, čelí vaše organizace katastrofální ztrátě dat.

Pro databázové administrátory (DBA) a DevOps inženýry již tradiční strategie zálohování 3-2-1 nestačí. Aby byla zaručena přežitelnost dat, musí týmy infrastruktury přijmout pravidlo 3-2-1-1, kde poslední „1“ představuje neměnné (imutable) úložiště.

Tento článek poskytuje komplexní technický vhled do návrhu, implementace a správy neměnného úložiště pro databázové archivy, aby byla zajištěna absolutní odolnost vůči ransomwaru.

Mechanismus neměnného úložiště

Neměnné úložiště spoléhá na architekturu WORM (Write-Once-Read-Many – jednou zapiš, mnohokrát čti). Jakmile jsou data zapsána do neměnného cíle, nemohou být upravena, zašifrována ani smazána žádným uživatelem – včetně administrátorů s právy root nebo kompromitovaných servisních účtů – dokud nevyprší matematicky vynucený časový zámek.

Režim shody (Compliance Mode) vs. Režim správy (Governance Mode)

Při implementaci neměnnosti, zejména v cloudových objektových úložištích, jako jsou AWS S3, Azure Blob nebo S3 kompatibilní on-premises SAN, musíte rozumět rozdílu mezi režimy uchovávání:

  • Režim správy (Governance Mode): Zabraňuje běžným uživatelům mazat nebo měnit objekty. Uživatelé se specifickými oprávněními IAM (např. s3:BypassGovernanceRetention) však mohou zámek obejít. To je užitečné pro testování, ale nedostatečné pro ochranu před ransomwarem, protože útočníci často eskalují svá oprávnění na úroveň doménového administrátora nebo roota.
  • Režim shody (Compliance Mode): Zlatý standard pro obranu proti ransomwaru. Jakmile je objekt uzamčen v režimu shody, jeho retenční období nelze zkrátit a objekt nemůže smazat nikdo, včetně root účtu AWS. Zámek je vynucen na úrovni úložného clusteru.

Návrh neměnné zálohovací pipeline

Robustní architektura archivace databází odděluje aktivní databázové operace od neměnné archivační vrstvy. Neměnnost nelze aplikovat na aktivní databázové soubory (jako .mdf/.ldf v SQL Serveru nebo adresář pg_data v PostgreSQL), protože databáze vyžadují neustálý přístup pro čtení a zápis.

Místo toho se neměnnost aplikuje na:
1. Soubory úplných a rozdílových záloh: Základní snímky databáze.
2. Transakční logy / WAL soubory: Kontinuální proud databázových změn potřebný pro obnovu k určitému bodu v čase (Point-in-Time Recovery – PITR).

Cílová úložiště pro neměnnost

Neměnné úložiště můžete implementovat napříč různými vrstvami infrastruktury:
* Cloudové objektové úložiště: AWS S3 Object Lock, Azure Blob Immutable Storage, retenční politiky Google Cloud Storage.
* On-premises objektové úložiště: MinIO, Cloudian nebo Pure Storage FlashBlade s podporou S3 Object Lock API.
* Blokové/souborové úložiště: ZFS se snímky (snapshots) pouze pro čtení a delegovanou správou nebo atributy souborů v Linuxu.

Implementace neměnného úložiště: Technické návody

1. Cloudové objektové úložiště: AWS S3 Object Lock

Pro ochranu databázových dumpů a transakčních logů v AWS musíte povolit Object Lock již při vytváření bucketu.

Nejprve vytvořte bucket s povoleným Object Lockem:

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

Poté nakonfigurujte výchozí retenční politiku. Pro databázové archivy je 30denní zámek v režimu shody standardním základem, který zajišťuje, že máte měsíc neměnných záloh.

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

Když váš skript pro zálohování databáze nebo agent nahraje soubor do tohoto bucketu, S3 automaticky vypočítá Retain Until Date na základě časového razítka vytvoření objektu plus 30 dní.

2. On-premises neměnnost: ZFS a atributy Linuxu

Pokud archivujete databáze na on-premises linuxový zálohovací server, můžete dosáhnout pseudo-neměnnosti pomocí příkazu chattr nebo skutečné neměnnosti pomocí ZFS snapshotů.

Použití Linux chattr:
Příznak +i (immutable) zabraňuje úpravě, smazání nebo přejmenování souboru.

# Dump databáze
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Nastavení neměnnosti zálohy
sudo chattr +i /backups/mydb_$(date +%F).dump

# Ověření atributu
lsattr /backups/mydb_$(date +%F).dump
# Výstup: ----i---------e------- /backups/mydb_2023-10-27.dump

Poznámka: I když chattr zastaví základní skripty ransomwaru, sofistikovaný útočník s root přístupem může jednoduše spustit chattr -i. Proto musí být toto řešení kombinováno s přísným RBAC a izolovanými zálohovacími sítěmi.

Použití ZFS snapshotů:
ZFS poskytuje mnohem silnější obranu. Vytvořením snímku a nastavením „hold“ (podržení) zabráníte jeho smazání.

# Vytvoření snímku zálohovacího datasetu
zfs snapshot tank/db_backups@archive_$(date +%F)

# Nastavení hold na snímek pro zabránění smazání
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Ani root nemůže tento snímek smazat bez uvolnění hold
zfs destroy tank/db_backups@archive_$(date +%F)
# Výstup: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Strategie archivace specifické pro databáze

Pro dosažení obnovy k určitému bodu v čase (PITR) musíte kontinuálně archivovat transakční logy do svého neměnného úložiště.

Archivace PostgreSQL WAL pomocí pgBackRest

pgBackRest je vysoce spolehlivý nástroj pro zálohování PostgreSQL, který nativně podporuje S3 kompatibilní úložiště. Pro ochranu svých Write-Ahead Logs (WAL) nakonfigurujte pgBackRest tak, aby je odesílal přímo do vašeho neměnného S3 bucketu.

Ve vašem 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

# Zajistěte, aby retence odpovídala vaší konfiguraci S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2

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

Klíčové upozornění: Pokud váš S3 bucket vynucuje 30denní zámek v režimu shody, ale pgBackRest se pokusí vypršet platnost a smazat WAL soubory po 14 dnech na základě repo1-retention-archive, volání API pro smazání selžou. Musíte zajistit, aby retenční politika vašeho zálohovacího softwaru byla větší nebo rovna neměnnému zámku na úrovni úložiště.

Microsoft SQL Server: Zálohování na URL

SQL Server podporuje nativní zálohování přímo do S3 kompatibilního objektového úložiště. Můžete nakonfigurovat úlohu SQL Server Agenta tak, aby zapisovala soubory .bak a .trn přímo do neměnného bucketu.

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

Automatizace a orchestrace s CloudSave

Správa příznaků neměnné retence, rotace přístupových klíčů a zajištění synchronizace mezi retenčními politikami databáze a zámky úložiště pomocí vlastních skriptů je vysoce náchylná k chybám. Jediná chybná konfigurace v cron jobu nebo volání API může nechat vaše archivy nechráněné nebo vést k raketovému nárůstu nákladů na cloudové úložiště kvůli osiřelým, uzamčeným objektům.

Podnikové zálohovací platformy jako CloudSave tuto architekturu zjednodušují. CloudSave se nativně integruje s AWS S3 Object Lock, Azure Blob Immutable Storage a on-premises S3 kompatibilními API.

Při konfiguraci plánu zálohování databáze v CloudSave:
1. Platforma automaticky řeší quiescence VSS (Volume Shadow Copy Service) pro SQL Server nebo API pg_start_backup() pro PostgreSQL.
2. Streamuje deduplikovaná a zašifrovaná zálohovaná data přímo do cílového úložiště.
3. CloudSave dynamicky aplikuje WORM API volání (např. PutObjectRetention) na úrovni jednotlivých objektů, čímž dokonale sladí dobu trvání zámku úložiště s retenčním plánem definovaným politikou.
4. Pokud útočník kompromituje konzoli pro správu CloudSave, stále nemůže smazat zálohy, protože zámek shody je vynucen základní infrastrukturou úložiště, nikoliv zálohovacím softwarem.

Osvědčené postupy pro neměnné databázové archivy

Abyste zajistili, že vaše neměnná architektura je skutečně odolná, dodržujte následující osvědčené postupy systémového inženýrství:

1. Přísná synchronizace NTP

Neměnné zámky jsou matematicky vázány na časová razítka. Pokud je služba NTP (Network Time Protocol) na vašem úložném poli nebo zálohovacím serveru kompromitována nebo vykazuje odchylky, může to způsobit předčasné vypršení zámků nebo jejich nefunkčnost. Zajistěte, aby vaše úložná infrastruktura používala autentizované a redundantní zdroje NTP.

2. Izolace IAM rolí a přihlašovacích údajů

Přihlašovací údaje používané pro zápis do neměnného bucketu musí mít pouze oprávnění s3:PutObject a s3:PutObjectRetention. Nikdy by neměly mít oprávnění s3:DeleteObject nebo s3:PutBucketObjectLockConfiguration.

Příklad IAM politiky s nejnižšími privilegii pro agenta zálohování databáze:

{
    "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. Nastavení retenčního období

Nenastavujte zámky shody na příliš dlouhou dobu (např. 7 let pro shodu) na vaší primární vrstvě pro rychlou obnovu. Databáze generují obrovské množství WAL/transakčních logů. Uzamčení těchto dat na roky povede k exponenciálnímu růstu nákladů na úložiště.
Místo toho použijte vrstvený přístup:
* Vrstva operativní obnovy: 14 až 30 dní neměnné retence pro úplné zálohy a logy.
* Vrstva dlouhodobé archivace: Měsíční úplné zálohy přesunuté do Glacier/Deep Archive s Vault Lockem na 1–7 let.

4. Pravidelné testování obnovy v izolovaných VPC

Neměnnost zaručuje, že data nelze smazat, ale nezaručuje, že data neobsahují logické poškození. Musíte automatizovat obnovu svých neměnných databázových archivů do izolovaného, air-gapped VPC nebo VLAN. Spusťte DBCC CHECKDB (SQL Server) nebo pg_amcheck (PostgreSQL) na obnovených datech pro ověření strukturální integrity.

Závěr

Obrana proti ransomwaru je cvičením v předpokladu průniku. V době, kdy se ve vašem SIEM spustí výstraha, se útočníci pravděpodobně již pokusili kompromitovat vaši zálohovací infrastrukturu. Architektura vašich databázových archivů pomocí neměnného úložiště v režimu shody zbavuje útočníky jejich hlavní páky. Ať už využíváte nativní cloudová API, ZFS holdy nebo podnikovou orchestraci jako CloudSave, implementace WORM úložiště již není volitelná – je to povinný pilíř moderní správy databází a obnovy po havárii.

Rubriky