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.

A modern fenyegetési környezetben a zsarolóvírusok az opportunista titkosítástól a nagymértékben célzott, többszörös zsarolással járó kampányok felé fejlődtek. A fejlett, állandó fenyegetések (APT-k) és a zsarolóvírus-szindikátusok ma már aktívan vadásznak a biztonsági mentési infrastruktúrára és az adatbázis-archívumokra a rendszerben töltött idejük alatt. Ha egy támadó kompromittálja az elsődleges adatbázisát, és ezzel egyidejűleg törli vagy titkosítja a biztonsági mentési tárolóit, szervezete katasztrofális adatvesztéssel néz szembe.

Az adatbázis-adminisztrátorok (DBA-k) és a DevOps mérnökök számára a hagyományos 3-2-1 biztonsági mentési stratégia már nem elegendő. Az adatok túlélésének garantálása érdekében az infrastruktúra-csapatoknak el kell fogadniuk a 3-2-1-1 szabályt, ahol az utolsó „1” a változtathatatlan (immutable) tárolást jelöli.

Ez a cikk átfogó, technikai mélyelemzést nyújt az adatbázis-archívumokhoz tartozó, változtathatatlan tárolás tervezéséről, megvalósításáról és kezeléséről az abszolút zsarolóvírus-ellenállóság biztosítása érdekében.

A változtathatatlan tárolás mechanikája

A változtathatatlan tárolás a Write-Once-Read-Many (WORM – egyszer írható, sokszor olvasható) architektúrára épül. Miután az adatokat egy változtathatatlan célhelyre írták, azokat egyetlen felhasználó sem módosíthatja, titkosíthatja vagy törölheti – beleértve a root jogosultságokkal rendelkező rendszergazdákat vagy a kompromittált szolgáltatásfiókokat is –, amíg egy matematikailag érvényesített időzár le nem jár.

Megfelelőségi mód (Compliance Mode) vs. Irányítási mód (Governance Mode)

A változtathatatlanság megvalósításakor, különösen a felhőalapú objektumtárolókban, mint például az AWS S3, az Azure Blob vagy az S3-kompatibilis helyszíni SAN-ok esetében, meg kell értenie a megőrzési módok közötti különbséget:

  • Irányítási mód (Governance Mode): Megakadályozza, hogy a normál felhasználók töröljék vagy módosítsák az objektumokat. Azonban a meghatározott IAM-jogosultságokkal rendelkező felhasználók (pl. s3:BypassGovernanceRetention) felülbírálhatják a zárolást. Ez hasznos teszteléshez, de elégtelen a zsarolóvírusok elleni védelemhez, mivel a támadók gyakran emelik a jogosultságaikat tartományi rendszergazdai vagy root szintre.
  • Megfelelőségi mód (Compliance Mode): A zsarolóvírusok elleni védelem aranyszabványa. Miután egy objektumot zároltak Megfelelőségi módban, a megőrzési időtartama nem rövidíthető, és az objektumot senki nem törölheti, beleértve az AWS root fiókot sem. A zárolás a tárolófürt szintjén érvényesül.

Változtathatatlan biztonsági mentési folyamat tervezése

A robusztus adatbázis-archiválási architektúra elválasztja az aktív adatbázis-műveleteket a változtathatatlan archív rétegtől. A változtathatatlanságot nem alkalmazhatja aktív adatbázisfájlokra (például .mdf/.ldf az SQL Serverben vagy a pg_data könyvtár a PostgreSQL-ben), mivel az adatbázisok folyamatos olvasási/írási hozzáférést igényelnek.

Ehelyett a változtathatatlanságot a következőkre alkalmazzák:
1. Teljes és differenciális biztonsági mentési fájlok: Az adatbázis alapvonali pillanatképei.
2. Tranzakciónaplók / WAL-fájlok: Az adatbázis-változások folyamatos adatfolyama, amely az időpontra történő helyreállításhoz (PITR) szükséges.

Tárolási célhelyek a változtathatatlansághoz

A változtathatatlan tárolást különböző infrastruktúra-rétegeken valósíthatja meg:
* Felhőalapú objektumtárolás: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage megőrzési szabályzatok.
* Helyszíni objektumtárolás: MinIO, Cloudian vagy Pure Storage FlashBlade, amelyek támogatják az S3 Object Lock API-kat.
* Blokk/fájl tárolás: ZFS csak olvasható pillanatképekkel és delegált adminisztrációval, vagy Linux fájlattribútumok.

Változtathatatlan tárolás megvalósítása: Technikai útmutatók

1. Felhőalapú objektumtárolás: AWS S3 Object Lock

Az adatbázis-dumpok és tranzakciónaplók AWS-ben történő védelme érdekében a gyűjtő (bucket) létrehozásakor engedélyeznie kell az Object Lock funkciót.

Először hozza létre a gyűjtőt engedélyezett Object Lock funkcióval:

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

Ezután konfigurálja az alapértelmezett megőrzési szabályzatot. Adatbázis-archívumok esetén a 30 napos megfelelőségi zárolás az alapértelmezett kiindulópont, amely biztosítja, hogy egy hónapnyi módosíthatatlan biztonsági mentéssel rendelkezzen.

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

Amikor az adatbázis biztonsági mentési szkriptje vagy ügynöke fájlt küld ebbe a gyűjtőbe, az S3 automatikusan kiszámítja a Retain Until Date (megőrzés dátuma) értéket az objektum létrehozási időbélyege plusz 30 nap alapján.

2. Helyszíni változtathatatlanság: ZFS és Linux attribútumok

Ha az adatbázisokat egy helyszíni Linux biztonsági mentési szerverre archiválja, pszeudo-változtathatatlanságot érhet el a chattr paranccsal, vagy valódi változtathatatlanságot a ZFS pillanatképek használatával.

Linux chattr használata:
A +i (immutable) jelző megakadályozza a fájl módosítását, törlését vagy átnevezését.

# Adatbázis dumpolása
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# A biztonsági mentés változtathatatlanná tétele
sudo chattr +i /backups/mydb_$(date +%F).dump

# Az attribútum ellenőrzése
lsattr /backups/mydb_$(date +%F).dump
# Kimenet: ----i---------e------- /backups/mydb_2023-10-27.dump

Megjegyzés: Bár a chattr megállítja az alapvető zsarolóvírus-szkripteket, egy kifinomult, root hozzáféréssel rendelkező támadó egyszerűen futtathatja a chattr -i parancsot. Ezért ezt szigorú RBAC-vel és elszigetelt biztonsági mentési hálózatokkal kell kombinálni.

ZFS pillanatképek használata:
A ZFS sokkal erősebb védelmet nyújt. Ha pillanatképet készít, és „zárolást” (hold) helyez rá, megakadályozza a pillanatkép megsemmisítését.

# Pillanatkép készítése a biztonsági mentési adatkészletről
zfs snapshot tank/db_backups@archive_$(date +%F)

# Zárolás elhelyezése a pillanatképen a törlés megakadályozása érdekében
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Még a root sem tudja megsemmisíteni ezt a pillanatképet a zárolás feloldása nélkül
zfs destroy tank/db_backups@archive_$(date +%F)
# Kimenet: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Adatbázis-specifikus archiválási stratégiák

Az időpontra történő helyreállítás (PITR) eléréséhez folyamatosan archiválnia kell a tranzakciónaplókat a változtathatatlan tárolóhelyére.

PostgreSQL WAL archiválás pgBackRest-tel

A pgBackRest egy rendkívül megbízható biztonsági mentési eszköz a PostgreSQL-hez, amely natívan támogatja az S3-kompatibilis tárolást. A Write-Ahead Logs (WAL) védelme érdekében konfigurálja a pgBackRest-et úgy, hogy közvetlenül a változtathatatlan S3-gyűjtőjébe küldje az adatokat.

A pgbackrest.conf fájljában:

[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

# Győződjön meg arról, hogy a megőrzés összhangban van az S3 Object Lock konfigurációjával
repo1-retention-full=2
repo1-retention-archive=2

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

Fontos szempont: Ha az S3-gyűjtője 30 napos megfelelőségi zárolást ír elő, de a pgBackRest a repo1-retention-archive alapján 14 nap után megkísérli lejárttá tenni és törölni a WAL-fájlokat, a törlési API-hívások sikertelenek lesznek. Győződjön meg arról, hogy a biztonsági mentési szoftver megőrzési szabályzata nagyobb vagy egyenlő, mint a tárolási szintű változtathatatlan zárolás.

Microsoft SQL Server: Biztonsági mentés URL-re

Az SQL Server támogatja a natív biztonsági mentést közvetlenül S3-kompatibilis objektumtárolóra. Konfigurálhat egy SQL Server Agent feladatot, amely közvetlenül a változtathatatlan gyűjtőbe írja a .bak és .trn fájlokat.

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

Automatizálás és vezénylés a CloudSave-vel

A változtathatatlan megőrzési jelzők kezelése, a hozzáférési kulcsok rotálása, valamint az adatbázis-megőrzési szabályzatok és a tárolási zárolások közötti szinkronizálás egyedi szkriptekkel rendkívül hibára hajlamos. Egyetlen konfigurációs hiba egy cron feladatban vagy API-hívásban az archívumokat kiszolgáltatottá teheti, vagy az elárvult, zárolt objektumok miatt az egekbe szökő felhőalapú tárolási költségeket eredményezhet.

Az olyan vállalati biztonsági mentési platformok, mint a CloudSave, leegyszerűsítik ezt az architektúrát. A CloudSave natívan integrálódik az AWS S3 Object Lock, az Azure Blob Immutable Storage és a helyszíni S3-kompatibilis API-kkal.

Amikor adatbázis-mentési tervet konfigurál a CloudSave-ben:
1. A platform automatikusan kezeli a VSS (Volume Shadow Copy Service) nyugalmi állapotot az SQL Server esetében, vagy a pg_start_backup() API-t a PostgreSQL esetében.
2. A deduplikált, titkosított biztonsági mentési adatokat közvetlenül a tárolási célhelyre továbbítja.
3. A CloudSave dinamikusan alkalmazza a WORM API-hívásokat (pl. PutObjectRetention) objektumonként, tökéletesen összehangolva a tárolási zárolás időtartamát a szabályzat által meghatározott megőrzési ütemtervvel.
4. Ha egy támadó kompromittálja a CloudSave felügyeleti konzolt, akkor sem tudja törölni a biztonsági mentéseket, mivel a megfelelőségi zárolást a mögöttes tárolási infrastruktúra érvényesíti, nem a biztonsági mentési szoftver.

A változtathatatlan adatbázis-archívumok legjobb gyakorlatai

Annak érdekében, hogy változtathatatlan architektúrája valóban rugalmas legyen, tartsa be a következő rendszertervezési legjobb gyakorlatokat:

1. Szigorú NTP-szinkronizálás

A változtathatatlan zárolások matematikailag az időbélyegekhez kötődnek. Ha a tárolótömbön vagy a biztonsági mentési szerveren lévő NTP (Network Time Protocol) szolgáltatás kompromittálódik vagy elcsúszik, az a zárolások idő előtti lejáratát vagy soha be nem következő lejáratát okozhatja. Győződjön meg arról, hogy a tárolási infrastruktúra hitelesített, redundáns NTP-forrásokat használ.

2. IAM-szerepkörök és hitelesítő adatok elszigetelése

A változtathatatlan gyűjtőbe történő íráshoz használt hitelesítő adatok csak s3:PutObject és s3:PutObjectRetention jogosultságokkal rendelkezhetnek. Soha nem rendelkezhetnek s3:DeleteObject vagy s3:PutBucketObjectLockConfiguration jogosultságokkal.

Példa egy minimális jogosultságú IAM-szabályzatra egy adatbázis-mentési ügynök számára:

{
    "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. A megőrzési időtartam méretezése

Ne állítson be túlzottan hosszú ideig tartó megfelelőségi zárolást (pl. 7 év megfelelőségi okokból) az elsődleges, gyors helyreállítási rétegen. Az adatbázisok hatalmas mennyiségű WAL/tranzakciónapló-adatot generálnak. Ezen adatok évekig tartó zárolása exponenciális tárolási költségnövekedést eredményez.
Ehelyett használjon rétegzett megközelítést:
* Operatív helyreállítási réteg: 14–30 napos változtathatatlan megőrzés a teljes mentésekhez és naplókhoz.
* Hosszú távú archiválási réteg: Havi teljes biztonsági mentések, amelyeket Glacier/Deep Archive-ba helyeznek át Vault Lock-kal 1–7 évre.

4. Rendszeres helyreállítási tesztelés elszigetelt VPC-kben

A változtathatatlanság garantálja, hogy az adatok nem törölhetők, de nem garantálja, hogy az adatok mentesek a logikai sérülésektől. Automatizálnia kell a változtathatatlan adatbázis-archívumok visszaállítását egy elszigetelt, légmentesen zárt (air-gapped) VPC-be vagy VLAN-ba. Futtassa a DBCC CHECKDB (SQL Server) vagy pg_amcheck (PostgreSQL) parancsot a visszaállított adatokon a strukturális integritás ellenőrzéséhez.

Következtetés

A zsarolóvírusok elleni védelem a feltételezett jogsértés gyakorlata. Mire a SIEM-rendszerében riasztás érkezik, a fenyegetők valószínűleg már megkísérelték kompromittálni a biztonsági mentési infrastruktúráját. Az adatbázis-archívumok megfelelőségi módban történő, változtathatatlan tárolással történő megtervezésével megfosztja a támadókat az elsődleges befolyásuktól. Akár natív felhőalapú API-kat, ZFS-zárolásokat vagy egy vállalati vezénylési platformot, például a CloudSave-et használja, a WORM-tárolás megvalósítása már nem választható – a modern adatbázis-adminisztráció és katasztrófa-helyreállítás kötelező pillére.

Kategóriák