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.

Tänapäeva ohumaastikul on lunavara arenenud oportunistlikust krüpteerimisest kõrgelt sihitud mitmekordse väljapressimise kampaaniateks. Täiustatud püsiohud (APT-d) ja lunavara sündikaadid otsivad nüüd oma viibimise ajal aktiivselt varundusinfrastruktuuri ja andmebaasi arhiive. Kui ründaja kompromiteerib teie peamise andmebaasi ning kustutab või krüpteerib samaaegselt teie varukoopiate hoidlad, seisab teie organisatsioon silmitsi katastroofilise andmekaoga.

Andmebaasiadministraatorite (DBA) ja DevOps-inseneride jaoks ei ole traditsiooniline 3-2-1 varundusstrateegia enam piisav. Andmete säilimise tagamiseks peavad infrastruktuurimeeskonnad kasutusele võtma 3-2-1-1 reegli, kus viimane „1“ tähistab muutumatut salvestusruumi (immutable storage).

See artikkel pakub põhjaliku tehnilise ülevaate andmebaasiarhiivide jaoks mõeldud muutumatu salvestusruumi kavandamisest, juurutamisest ja haldamisest, et tagada absoluutne vastupidavus lunavarale.

Muutumatu salvestusruumi toimimispõhimõtted

Muutumatu salvestusruum põhineb WORM-arhitektuuril (Write-Once-Read-Many – kirjuta üks kord, loe mitu korda). Kui andmed on muutumatusse sihtkohta kirjutatud, ei saa neid ükski kasutaja – sealhulgas juurõigustega administraatorid või kompromiteeritud teenusekontod – muuta, krüpteerida ega kustutada enne, kui matemaatiliselt jõustatud ajaline lukk aegub.

Vastavusrežiim (Compliance Mode) vs. Haldusrežiim (Governance Mode)

Muutumatuse juurutamisel, eriti pilveobjektide salvestusruumides nagu AWS S3, Azure Blob või S3-ühilduvad kohapealsed SAN-id, peate mõistma erinevust säilitusrežiimide vahel:

  • Haldusrežiim (Governance Mode): Takistab tavakasutajatel objekte kustutamast või muutmast. Siiski saavad kasutajad, kellel on spetsiaalsed IAM-õigused (nt s3:BypassGovernanceRetention), luku tühistada. See on kasulik testimiseks, kuid lunavarakaitseks ebapiisav, kuna ründajad tõstavad sageli oma õigusi domeeniadministraatori või juurkasutaja tasemele.
  • Vastavusrežiim (Compliance Mode): Lunavarakaitse kuldstandard. Kui objekt on vastavusrežiimis lukustatud, ei saa selle säilitusperioodi lühendada ja objekti ei saa kustutada keegi, sealhulgas AWS-i juurkasutaja. Lukk jõustatakse salvestusklastri tasemel.

Muutumatu varunduskonveieri kavandamine

Tugev andmebaasi arhiveerimise arhitektuur eraldab aktiivsed andmebaasitoimingud muutumatust arhiivikihist. Te ei saa rakendada muutumatust aktiivsetele andmebaasifailidele (nagu .mdf/.ldf SQL Serveris või pg_data kataloog PostgreSQL-is), kuna andmebaasid vajavad pidevat lugemis- ja kirjutamisjuurdepääsu.

Selle asemel rakendatakse muutumatust järgmistele:
1. Täielikud ja diferentsiaalsed varufailid: Andmebaasi baastaseme hetktõmmised.
2. Tehingulogid / WAL-failid: Pidev andmebaasimuudatuste voog, mis on vajalik ajapunkti taastamiseks (Point-in-Time Recovery, PITR).

Muutumatuse salvestussihtkohad

Muutumatut salvestusruumi saate juurutada erinevatel infrastruktuurikihtidel:
* Pilveobjektide salvestusruum: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Kohapealne objektide salvestusruum: MinIO, Cloudian või Pure Storage FlashBlade, mis toetavad S3 Object Lock API-sid.
* Plokk-/failisalvestusruum: ZFS kirjutuskaitstud hetktõmmiste ja delegeeritud haldusega või Linuxi failiatribuudid.

Muutumatu salvestusruumi juurutamine: tehnilised juhised

1. Pilveobjektide salvestusruum: AWS S3 Object Lock

Andmebaasidumpide ja tehingulogide kaitsmiseks AWS-is peate ämbri (bucket) loomisel lubama Object Locki.

Esmalt looge ämber koos lubatud Object Lockiga:

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

Järgmisena konfigureerige vaikesäilituspoliitika. Andmebaasiarhiivide jaoks on 30-päevane vastavuslukk standardne baastase, mis tagab, et teil on kuu aja jagu muudetamatuid varukoopiaid.

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

Kui teie andmebaasi varundusskript või agent saadab faili sellesse ämbrisse, arvutab S3 automaatselt Retain Until Date (säilitamise tähtaeg), lähtudes objekti loomise ajatemplist pluss 30 päeva.

2. Kohapealne muutumatus: ZFS ja Linuxi atribuudid

Kui arhiveerite andmebaase kohapealsesse Linuxi varundusserverisse, saate saavutada pseudomuutumatuse chattr käsu abil või tõelise muutumatuse ZFS-i hetktõmmiste abil.

Linuxi chattr kasutamine:
+i (immutable) lipp takistab faili muutmist, kustutamist või ümbernimetamist.

# Andmebaasi dumpimine
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Varukoopia muutumatuks muutmine
sudo chattr +i /backups/mydb_$(date +%F).dump

# Atribuudi kontrollimine
lsattr /backups/mydb_$(date +%F).dump
# Väljund: ----i---------e------- /backups/mydb_2023-10-27.dump

Märkus: Kuigi chattr peatab lihtsad lunavara skriptid, saab kogenud ründaja juurõigustega lihtsalt käivitada chattr -i. Seetõttu tuleb seda kombineerida range RBAC-i ja isoleeritud varundusvõrkudega.

ZFS-i hetktõmmiste kasutamine:
ZFS pakub palju tugevamat kaitset. Tehes hetktõmmise ja seades sellele „hoidmise“ (hold), takistate hetktõmmise hävitamist.

# Varundusandmekogumi hetktõmmise tegemine
zfs snapshot tank/db_backups@archive_$(date +%F)

# Hoidmise seadmine hetktõmmisele, et vältida kustutamist
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Isegi juurkasutaja ei saa seda hetktõmmist hävitada ilma hoidmist vabastamata
zfs destroy tank/db_backups@archive_$(date +%F)
# Väljund: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Andmebaasispetsiifilised arhiveerimisstrateegiad

Ajapunkti taastamise (PITR) saavutamiseks peate pidevalt arhiveerima tehingulogisid oma muutumatusse salvestusruumi.

PostgreSQL WAL-i arhiveerimine pgBackRestiga

pgBackRest on väga usaldusväärne PostgreSQL-i varundustööriist, mis toetab natiivselt S3-ühilduvat salvestusruumi. Oma Write-Ahead logide (WAL) kaitsmiseks konfigureerige pgBackRest saatma andmed otse teie muutumatusse S3 ämbrisse.

Teie pgbackrest.conf failis:

[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

# Veenduge, et säilitusperiood ühtib teie S3 Object Locki konfiguratsiooniga
repo1-retention-full=2
repo1-retention-archive=2

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

Oluline märkus: Kui teie S3 ämber jõustab 30-päevase vastavusluku, kuid pgBackRest üritab repo1-retention-archive põhjal WAL-faile 14 päeva pärast aegunuks lugeda ja kustutada, siis kustutamise API-kutsed ebaõnnestuvad. Peate tagama, et teie varundustarkvara säilituspoliitika on pikem või võrdne salvestustaseme muutumatu lukuga.

Microsoft SQL Server: Varundamine URL-ile

SQL Server toetab natiivseid varukoopiaid otse S3-ühilduvasse objektide salvestusruumi. Saate konfigureerida SQL Server Agenti töö kirjutama .bak ja .trn faile otse muutumatusse ämbrisse.

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

Automatiseerimine ja orkestreerimine CloudSave’iga

Muutumatute säilituslippude haldamine, juurdepääsuvõtmete roteerimine ning andmebaasi säilituspoliitikate ja salvestuslukkude sünkroniseerimine kohandatud skriptide kaudu on väga vigaderohke. Üksainus valekonfiguratsioon cron-töös või API-kutses võib jätta teie arhiivid kaitsetuks või põhjustada pilvesalvestuskulude hüppelise kasvu orvuks jäänud lukustatud objektide tõttu.

Ettevõtte tasemel varundusplatvormid nagu CloudSave lihtsustavad seda arhitektuuri. CloudSave integreerub natiivselt AWS S3 Object Locki, Azure Blob Immutable Storage’i ja kohapealsete S3-ühilduvate API-dega.

Andmebaasi varundusplaani konfigureerimisel CloudSave’is:
1. Platvorm haldab automaatselt VSS-i (Volume Shadow Copy Service) vaikimist SQL Serveri jaoks või pg_start_backup() API-t PostgreSQL-i jaoks.
2. See voogedastab deduplikeeritud ja krüpteeritud varundusandmed otse salvestussihtkohta.
3. CloudSave rakendab dünaamiliselt WORM API-kutseid (nt PutObjectRetention) objekti kaupa, viies salvestusluku kestuse täiuslikult vastavusse poliitikaga määratletud säilitusgraafikuga.
4. Kui ründaja kompromiteerib CloudSave’i halduskonsooli, ei saa ta ikkagi varukoopiaid kustutada, kuna vastavusluku jõustab aluseks olev salvestusinfrastruktuur, mitte varundustarkvara.

Parimad tavad muutumatute andmebaasiarhiivide jaoks

Tagamaks, et teie muutumatu arhitektuur on tõeliselt vastupidav, järgige järgmisi süsteemitehnilisi parimaid tavasid:

1. Range NTP sünkroniseerimine

Muutumatud lukud on matemaatiliselt seotud ajatemplitega. Kui teie salvestusmassiivi või varundusserveri NTP (Network Time Protocol) teenus on kompromiteeritud või triivib, võib see põhjustada lukkude enneaegset aegumist või nende üldse mitte aegumist. Veenduge, et teie salvestusinfrastruktuur kasutab autentitud ja koondatud NTP-allikaid.

2. IAM-rollide ja mandaatide isoleerimine

Muutumatule ämbrile kirjutamiseks kasutatavatel mandaatidel peavad olema ainult s3:PutObject ja s3:PutObjectRetention õigused. Neil ei tohi kunagi olla s3:DeleteObject või s3:PutBucketObjectLockConfiguration õigusi.

Näide andmebaasi varundusagendi vähimate õiguste IAM-poliitikast:

{
    "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. Säilitusperioodi suuruse määramine

Ärge määrake oma peamise kiire taastamise kihi jaoks liiga pikki vastavuslukke (nt 7 aastat vastavuse tagamiseks). Andmebaasid genereerivad tohutul hulgal WAL/tehingulogide andmeid. Nende andmete aastateks lukustamine toob kaasa salvestuskulude eksponentsiaalse kasvu.
Selle asemel kasutage kihilist lähenemist:
* Operatiivse taastamise kiht: 14 kuni 30 päeva muutumatut säilitamist täielikele varukoopiatele ja logidele.
* Pikaajaline arhiivikiht: Igakuised täielikud varukoopiad, mis liigutatakse Glacier/Deep Archive’i koos Vault Lockiga 1–7 aastaks.

4. Regulaarne taastamise testimine isoleeritud VPC-des

Muutumatus garanteerib, et andmeid ei saa kustutada, kuid see ei garanteeri, et andmed on vabad loogilistest rikkumistest. Peate automatiseerima oma muutumatute andmebaasiarhiivide taastamise isoleeritud, õhulukustatud (air-gapped) VPC-sse või VLAN-i. Käivitage taastatud andmetel DBCC CHECKDB (SQL Server) või pg_amcheck (PostgreSQL), et kontrollida struktuurilist terviklikkust.

Kokkuvõte

Lunavarakaitse on harjutus, kus eeldatakse rikkumist. Ajaks, mil teie SIEM-is alarm kõlab, on ohutegurid tõenäoliselt juba üritanud teie varundusinfrastruktuuri kompromiteerida. Kavandades oma andmebaasiarhiivid vastavusrežiimis muutumatu salvestusruumi abil, võtate ründajatelt nende peamise hoova. Ükskõik, kas kasutate natiivseid pilve API-sid, ZFS-i hoidmisi või ettevõtte orkestreerimisplatvormi nagu CloudSave, ei ole WORM-salvestusruumi juurutamine enam valikuline – see on kaasaegse andmebaasihalduse ja katastroofi taastamise kohustuslik sammas.

Rubriigid