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.

U savremenom okruženju pretnji, ransomware je evoluirao od oportunističkog šifrovanja do visoko ciljanih kampanja višestruke iznude. Napredne uporne pretnje (APT) i ransomware sindikati sada aktivno tragaju za infrastrukturom za rezervne kopije i arhivama baza podataka tokom vremena provedenog u sistemu. Ako napadač kompromituje vašu primarnu bazu podataka i istovremeno izbriše ili šifruje vaše repozitorijume rezervnih kopija, vaša organizacija se suočava sa katastrofalnim gubitkom podataka.

Za administratore baza podataka (DBA) i DevOps inženjere, tradicionalna 3-2-1 strategija rezervnih kopija više nije dovoljna. Da bi garantovali preživljavanje podataka, infrastrukturni timovi moraju usvojiti pravilo 3-2-1-1, gde poslednja „1“ predstavlja nepromenljivo skladište (immutable storage).

Ovaj članak pruža sveobuhvatan, tehnički dubinski pregled projektovanja, implementacije i upravljanja nepromenljivim skladištem za arhive baza podataka kako bi se osigurala apsolutna otpornost na ransomware.

Mehanika nepromenljivog skladišta

Nepromenljivo skladište se oslanja na arhitekturu „piši jednom, čitaj mnogo“ (WORM – Write-Once-Read-Many). Kada se podaci zapišu na nepromenljivu lokaciju, nijedan korisnik ih ne može modifikovati, šifrovati ili izbrisati—uključujući administratore sa root privilegijama ili kompromitovane servisne naloge—sve dok ne istekne matematički nametnuto vremensko zaključavanje.

Režim usaglašenosti (Compliance Mode) naspram režima upravljanja (Governance Mode)

Prilikom implementacije nepromenljivosti, posebno u objektno skladište u oblaku kao što su AWS S3, Azure Blob ili S3-kompatibilni lokalni SAN sistemi, morate razumeti razliku između režima zadržavanja:

  • Režim upravljanja (Governance Mode): Sprečava standardne korisnike da brišu ili menjaju objekte. Međutim, korisnici sa specifičnim IAM dozvolama (npr. s3:BypassGovernanceRetention) mogu zaobići zaključavanje. Ovo je korisno za testiranje, ali nedovoljno za zaštitu od ransomware-a, jer napadači često eskaliraju privilegije do nivoa administratora domena ili root-a.
  • Režim usaglašenosti (Compliance Mode): Zlatni standard za odbranu od ransomware-a. Kada je objekat zaključan u režimu usaglašenosti, njegov period zadržavanja se ne može skratiti, a objekat ne može izbrisati niko, uključujući AWS root nalog. Zaključavanje se sprovodi na nivou skladišnog klastera.

Projektovanje nepromenljivog cjevovoda rezervnih kopija

Robusna arhitektura arhiviranja baza podataka odvaja aktivne operacije baze podataka od nepromenljivog nivoa arhive. Ne možete primeniti nepromenljivost na aktivne datoteke baze podataka (kao što su .mdf/.ldf u SQL Serveru ili pg_data direktorijum u PostgreSQL-u) jer baze podataka zahtevaju stalan pristup za čitanje/pisanje.

Umesto toga, nepromenljivost se primenjuje na:
1. Datoteke punih i diferencijalnih rezervnih kopija: Osnovni snimci baze podataka.
2. Transakcione logove / WAL datoteke: Kontinuirani tok promena u bazi podataka potreban za oporavak do određene tačke u vremenu (PITR).

Skladišne lokacije za nepromenljivost

Nepromenljivo skladište možete implementirati na različitim infrastrukturnim nivoima:
* Objektno skladište u oblaku: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Lokalno objektno skladište: MinIO, Cloudian ili Pure Storage FlashBlade koji podržavaju S3 Object Lock API-je.
* Blok/fajl skladište: ZFS sa snimcima samo za čitanje i delegiranom administracijom, ili Linux atributi datoteka.

Implementacija nepromenljivog skladišta: Tehnički vodiči

1. Objektno skladište u oblaku: AWS S3 Object Lock

Da biste zaštitili dumpove baza podataka i transakcione logove u AWS-u, morate omogućiti Object Lock u trenutku kreiranja bucket-a.

Prvo, kreirajte bucket sa omogućenim Object Lock-om:

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

Zatim, konfigurišite podrazumevanu politiku zadržavanja. Za arhive baza podataka, 30-dnevno zaključavanje usaglašenosti je standardna osnova, koja osigurava da imate mesec dana nepromenljivih rezervnih kopija.

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

Kada vaša skripta ili agent za rezervne kopije baze podataka pošalje datoteku u ovaj bucket, S3 automatski izračunava Retain Until Date na osnovu vremenske oznake kreiranja objekta plus 30 dana.

2. Lokalna nepromenljivost: ZFS i Linux atributi

Ako arhivirate baze podataka na lokalni Linux server za rezervne kopije, možete postići pseudo-nepromenljivost koristeći chattr komandu, ili pravu nepromenljivost koristeći ZFS snimke.

Korišćenje Linux chattr:
+i (immutable) fleg sprečava modifikaciju, brisanje ili preimenovanje datoteke.

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

# Učinite rezervnu kopiju nepromenljivom
sudo chattr +i /backups/mydb_$(date +%F).dump

# Proverite atribut
lsattr /backups/mydb_$(date +%F).dump
# Izlaz: ----i---------e------- /backups/mydb_2023-10-27.dump

Napomena: Iako chattr zaustavlja osnovne ransomware skripte, sofisticirani napadač sa root pristupom može jednostavno pokrenuti chattr -i. Stoga se ovo mora kombinovati sa strogim RBAC-om i izolovanim mrežama za rezervne kopije.

Korišćenje ZFS snimaka:
ZFS pruža mnogo jaču odbranu. Pravljenjem snimka i postavljanjem „zadrške“ (hold) na njega, sprečavate njegovo brisanje.

# Napravite snimak dataseta rezervnih kopija
zfs snapshot tank/db_backups@archive_$(date +%F)

# Postavite zadršku na snimak da sprečite brisanje
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Čak ni root ne može uništiti ovaj snimak bez uklanjanja zadrške
zfs destroy tank/db_backups@archive_$(date +%F)
# Izlaz: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Strategije arhiviranja specifične za baze podataka

Da biste postigli oporavak do određene tačke u vremenu (PITR), morate kontinuirano arhivirati transakcione logove u svoje nepromenljivo skladište.

PostgreSQL WAL arhiviranje sa pgBackRest

pgBackRest je veoma pouzdan alat za rezervne kopije za PostgreSQL koji izvorno podržava S3-kompatibilno skladište. Da biste zaštitili svoje Write-Ahead logove (WAL), konfigurišite pgBackRest da ih šalje direktno u vaš nepromenljivi S3 bucket.

U 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

# Osigurajte da se zadržavanje poklapa sa vašom S3 Object Lock konfiguracijom
repo1-retention-full=2
repo1-retention-archive=2

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

Ključno razmatranje: Ako vaš S3 bucket nameće 30-dnevno zaključavanje usaglašenosti, a pgBackRest pokuša da istekne i izbriše WAL datoteke nakon 14 dana na osnovu repo1-retention-archive, API pozivi za brisanje će neuspeti. Morate osigurati da je politika zadržavanja vašeg softvera za rezervne kopije jednaka ili duža od nepromenljivog zaključavanja na nivou skladišta.

Microsoft SQL Server: Backup to URL

SQL Server podržava izvorne rezervne kopije direktno na S3-kompatibilno objektno skladište. Možete konfigurisati SQL Server Agent posao da piše .bak i .trn datoteke direktno u nepromenljivi 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

Automatizacija i orkestracija sa CloudSave

Upravljanje flegovima nepromenljivog zadržavanja, rotiranje pristupnih ključeva i osiguravanje sinhronizacije između politika zadržavanja baze podataka i zaključavanja skladišta putem prilagođenih skripti je veoma podložno greškama. Jedna pogrešna konfiguracija u cron poslu ili API pozivu može ostaviti vaše arhive izloženim ili rezultirati drastičnim povećanjem troškova skladištenja u oblaku zbog napuštenih, zaključanih objekata.

Enterprise platforme za rezervne kopije kao što je CloudSave pojednostavljuju ovu arhitekturu. CloudSave se izvorno integriše sa AWS S3 Object Lock, Azure Blob Immutable Storage i lokalnim S3-kompatibilnim API-jima.

Prilikom konfigurisanja plana rezervnih kopija baze podataka u CloudSave-u:
1. Platforma automatski upravlja VSS (Volume Shadow Copy Service) mirovanjem za SQL Server ili pg_start_backup() API-jem za PostgreSQL.
2. Prenosi deduplikovane, šifrovane podatke rezervnih kopija direktno na skladišnu lokaciju.
3. CloudSave dinamički primenjuje WORM API pozive (npr. PutObjectRetention) na nivou svakog objekta, savršeno usklađujući trajanje zaključavanja skladišta sa rasporedom zadržavanja definisanim politikom.
4. Ako napadač kompromituje CloudSave konzolu za upravljanje, i dalje ne može izbrisati rezervne kopije, jer zaključavanje usaglašenosti sprovodi osnovna infrastrukturna skladišna tehnologija, a ne softver za rezervne kopije.

Najbolje prakse za nepromenljive arhive baza podataka

Da biste osigurali da je vaša nepromenljiva arhitektura zaista otporna, pridržavajte se sledećih inženjerskih najboljih praksi:

1. Stroga NTP sinhronizacija

Nepromenljiva zaključavanja su matematički vezana za vremenske oznake. Ako je NTP (Network Time Protocol) servis na vašem skladišnom nizu ili serveru za rezervne kopije kompromitovan ili odstupa, to može uzrokovati prevremeno isticanje zaključavanja ili da ona nikada ne isteknu. Osigurajte da vaša skladišna infrastruktura koristi autentifikovane, redundantne NTP izvore.

2. Izolacija IAM uloga i akreditiva

Akreditive koji se koriste za pisanje u nepromenljivi bucket moraju imati samo s3:PutObject i s3:PutObjectRetention dozvole. Oni nikada ne smeju imati s3:DeleteObject ili s3:PutBucketObjectLockConfiguration dozvole.

Primer IAM politike sa najmanjim privilegijama za agenta rezervnih kopija baze podataka:

{
    "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. Određivanje perioda zadržavanja

Ne postavljajte zaključavanja usaglašenosti na preduge periode (npr. 7 godina za usaglašenost) na vašem primarnom nivou za brzi oporavak. Baze podataka generišu ogromne količine WAL/transakcionih log podataka. Zaključavanje ovih podataka godinama će rezultirati eksponencijalnim rastom troškova skladištenja.
Umesto toga, koristite višeslojni pristup:
* Nivo operativnog oporavka: 14 do 30 dana nepromenljivog zadržavanja za pune kopije i logove.
* Nivo dugoročnog arhiviranja: Mesečne pune rezervne kopije premeštene u Glacier/Deep Archive sa Vault Lock-om na 1-7 godina.

4. Redovno testiranje oporavka u izolovanim VPC-ovima

Nepromenljivost garantuje da se podaci ne mogu izbrisati, ali ne garantuje da su podaci bez logičke korupcije. Morate automatizovati restauraciju vaših nepromenljivih arhiva baza podataka u izolovani, vazdušno odvojeni (air-gapped) VPC ili VLAN. Pokrenite DBCC CHECKDB (SQL Server) ili pg_amcheck (PostgreSQL) na restauriranim podacima da biste potvrdili strukturni integritet.

Zaključak

Odbrana od ransomware-a je vežba u pretpostavci proboja. Do trenutka kada se aktivira upozorenje u vašem SIEM-u, napadači su verovatno već pokušali da kompromituju vašu infrastrukturu za rezervne kopije. Projektovanjem arhiva vaših baza podataka korišćenjem nepromenljivog skladišta u režimu usaglašenosti, oduzimate napadačima njihovu glavnu polugu. Bez obzira da li koristite izvorne API-je u oblaku, ZFS zadrške ili enterprise platformu za orkestraciju kao što je CloudSave, implementacija WORM skladišta više nije opciona—to je obavezan stub moderne administracije baza podataka i oporavka od katastrofa.

Категорије