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 modernom okruženju prijetnji, ransomware se razvio od oportunističkog šifriranja do visoko ciljanih kampanja višestruke iznude. Napredne trajne prijetnje (APT) i ransomware sindikati sada aktivno traže sigurnosnu infrastrukturu i arhive baza podataka tijekom svog vremena boravka u sustavu. Ako napadač kompromitira vašu primarnu bazu podataka i istovremeno izbriše ili šifrira vaše repozitorije sigurnosnih kopija, vaša se organizacija suočava s katastrofalnim gubitkom podataka.

Za administratore baza podataka (DBA) i DevOps inženjere, tradicionalna strategija sigurnosnog kopiranja 3-2-1 više nije dovoljna. Kako bi se zajamčila preživljavanje podataka, infrastrukturni timovi moraju usvojiti pravilo 3-2-1-1, gdje posljednja „1” predstavlja nepromjenjivu pohranu (immutable storage).

Ovaj članak pruža sveobuhvatan, tehnički dubinski pregled projektiranja, implementacije i upravljanja nepromjenjivom pohranom za arhive baza podataka kako bi se osigurala apsolutna otpornost na ransomware.

Mehanika nepromjenjive pohrane

Nepromjenjiva pohrana oslanja se na arhitekturu „piši jednom, čitaj mnogo puta” (WORM – Write-Once-Read-Many). Jednom kada se podaci zapišu na nepromjenjivo odredište, nijedan korisnik ih ne može mijenjati, šifrirati ili brisati—uključujući administratore s root privilegijama ili kompromitirane servisne račune—sve dok ne istekne matematički provedena vremenska blokada.

Način usklađenosti (Compliance Mode) naspram Načina upravljanja (Governance Mode)

Prilikom implementacije nepromjenjivosti, posebno u pohrani objekata u oblaku kao što su AWS S3, Azure Blob ili S3-kompatibilni lokalni SAN sustavi, morate razumjeti razliku između načina zadržavanja:

  • Način upravljanja (Governance Mode): Sprječava standardne korisnike da brišu ili mijenjaju objekte. Međutim, korisnici s određenim IAM dozvolama (npr. s3:BypassGovernanceRetention) mogu zaobići zaključavanje. Ovo je korisno za testiranje, ali nedovoljno za zaštitu od ransomwarea, jer napadači često eskaliraju privilegije do razine domenskog administratora ili roota.
  • Način usklađenosti (Compliance Mode): Zlatni standard za obranu od ransomwarea. Jednom kada je objekt zaključan u načinu usklađenosti, njegovo razdoblje zadržavanja se ne može skratiti, a objekt ne može izbrisati nitko, uključujući AWS root račun. Zaključavanje se provodi na razini klastera za pohranu.

Projektiranje nepromjenjivog cjevovoda sigurnosnih kopija

Robusna arhitektura arhiviranja baza podataka odvaja aktivne operacije baze podataka od nepromjenjivog arhivskog sloja. Ne možete primijeniti nepromjenjivost na aktivne datoteke baze podataka (poput .mdf/.ldf u SQL Serveru ili pg_data direktorija u PostgreSQL-u) jer baze podataka zahtijevaju stalan pristup čitanja/pisanja.

Umjesto toga, nepromjenjivost se primjenjuje na:
1. Datoteke potpunih i diferencijalnih sigurnosnih kopija: Osnovne snimke baze podataka.
2. Transakcijske logove / WAL datoteke: Kontinuirani tok promjena baze podataka potreban za oporavak do određene točke u vremenu (PITR).

Odredišta za nepromjenjivu pohranu

Nepromjenjivu pohranu možete implementirati kroz različite infrastrukturne slojeve:
* Pohrana objekata u oblaku: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Lokalna pohrana objekata (On-Premises): MinIO, Cloudian ili Pure Storage FlashBlade koji podržavaju S3 Object Lock API-je.
* Blok/datotečna pohrana: ZFS sa snimkama (snapshots) samo za čitanje i delegiranom administracijom, ili Linux atributi datoteka.

Implementacija nepromjenjive pohrane: Tehnički vodiči

1. Pohrana objekata u oblaku: AWS S3 Object Lock

Da biste zaštitili dumpove baza podataka i transakcijske logove u AWS-u, morate omogućiti Object Lock u trenutku stvaranja spremnika (bucket).

Prvo, stvorite spremnik s omogućenim Object Lockom:

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

Zatim konfigurirajte zadanu politiku zadržavanja. Za arhive baza podataka, 30-dnevno zaključavanje usklađenosti je standardna osnovica, osiguravajući da imate mjesec dana nepromjenjivih sigurnosnih 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 sigurnosno kopiranje baze podataka pošalje datoteku u ovaj spremnik, S3 automatski izračunava Retain Until Date na temelju vremenske oznake stvaranja objekta plus 30 dana.

2. Lokalna nepromjenjivost: ZFS i Linux atributi

Ako arhivirate baze podataka na lokalni Linux poslužitelj za sigurnosne kopije, možete postići pseudo-nepromjenjivost pomoću naredbe chattr ili pravu nepromjenjivost pomoću ZFS snimki.

Korištenje Linux chattr:
Oznaka +i (immutable) sprječava izmjenu, brisanje ili preimenovanje datoteke.

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

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

# Provjerite 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č s root pristupom može jednostavno pokrenuti chattr -i. Stoga se ovo mora kombinirati sa strogim RBAC-om i izoliranim mrežama za sigurnosne kopije.

Korištenje ZFS snimki:
ZFS pruža puno jaču obranu. Uzimanjem snimke i postavljanjem “zadržavanja” (hold) na nju, sprječavate njezino brisanje.

# Uzmite snimku skupa podataka sigurnosnih kopija
zfs snapshot tank/db_backups@archive_$(date +%F)

# Postavite zadržavanje na snimku kako biste spriječili brisanje
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Čak ni root ne može uništiti ovu snimku bez uklanjanja zadržavanja
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 točke u vremenu (PITR), morate kontinuirano arhivirati transakcijske logove u svoju nepromjenjivu pohranu.

PostgreSQL WAL arhiviranje s pgBackRest

pgBackRest je vrlo pouzdan alat za sigurnosno kopiranje PostgreSQL-a koji izvorno podržava S3-kompatibilnu pohranu. Kako biste zaštitili svoje Write-Ahead logove (WAL), konfigurirajte pgBackRest da ih šalje izravno u vaš nepromjenjivi S3 spremnik.

U vašoj pgbackrest.conf datoteci:

[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 uskladi s vašom konfiguracijom S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2

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

Ključno razmatranje: Ako vaš S3 spremnik provodi 30-dnevno zaključavanje usklađenosti, a pgBackRest pokuša isteći i izbrisati WAL datoteke nakon 14 dana na temelju repo1-retention-archive, API pozivi za brisanje neće uspjeti. Morate osigurati da je politika zadržavanja vašeg softvera za sigurnosno kopiranje jednaka ili dulja od nepromjenjivog zaključavanja na razini pohrane.

Microsoft SQL Server: Sigurnosno kopiranje na URL

SQL Server podržava izvorno sigurnosno kopiranje izravno na S3-kompatibilnu pohranu objekata. Možete konfigurirati posao SQL Server Agenta za pisanje .bak i .trn datoteka izravno u nepromjenjivi spremnik.

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 s CloudSave

Upravljanje oznakama nepromjenjivog zadržavanja, rotiranje pristupnih ključeva i osiguravanje sinkronizacije između politika zadržavanja baze podataka i zaključavanja pohrane putem prilagođenih skripti vrlo je podložno pogreškama. Jedna pogrešna konfiguracija u cron poslu ili API pozivu može ostaviti vaše arhive izloženima ili rezultirati vrtoglavim troškovima pohrane u oblaku zbog napuštenih, zaključanih objekata.

Enterprise platforme za sigurnosno kopiranje kao što je CloudSave pojednostavljuju ovu arhitekturu. CloudSave se izvorno integrira s AWS S3 Object Lock, Azure Blob Immutable Storage i lokalnim S3-kompatibilnim API-jima.

Prilikom konfiguriranja plana sigurnosnog kopiranja baze podataka u CloudSave:
1. Platforma automatski upravlja VSS (Volume Shadow Copy Service) mirovanjem za SQL Server ili pg_start_backup() API-jem za PostgreSQL.
2. Prenosi deduplicirane, šifrirane podatke sigurnosne kopije izravno na odredište pohrane.
3. CloudSave dinamički primjenjuje WORM API pozive (npr. PutObjectRetention) na razini svakog objekta, savršeno usklađujući trajanje zaključavanja pohrane s rasporedom zadržavanja definiranim politikom.
4. Ako napadač kompromitira upravljačku konzolu CloudSave, i dalje ne može izbrisati sigurnosne kopije, jer zaključavanje usklađenosti provodi temeljna infrastrukturna pohrana, a ne softver za sigurnosno kopiranje.

Najbolje prakse za nepromjenjive arhive baza podataka

Kako biste osigurali da je vaša nepromjenjiva arhitektura uistinu otporna, pridržavajte se sljedećih inženjerskih najboljih praksi:

1. Stroga NTP sinkronizacija

Nepromjenjiva zaključavanja matematički su vezana uz vremenske oznake. Ako je NTP (Network Time Protocol) usluga na vašem nizu za pohranu ili poslužitelju za sigurnosne kopije kompromitirana ili odstupa, to može uzrokovati prerano istjecanje zaključavanja ili da ona nikada ne isteknu. Osigurajte da vaša infrastrukturna pohrana koristi autentificirane, redundantne NTP izvore.

2. Izolacija IAM uloga i vjerodajnica

Vjerodajnice koje se koriste za pisanje u nepromjenjivi spremnik moraju imati samo s3:PutObject i s3:PutObjectRetention dozvole. One nikada ne smiju imati s3:DeleteObject ili s3:PutBucketObjectLockConfiguration dozvole.

Primjer IAM politike s najmanjim privilegijama za agenta sigurnosnog kopiranja 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 razdoblja zadržavanja

Ne postavljajte zaključavanja usklađenosti na pretjerano duga razdoblja (npr. 7 godina za usklađenost) na vašem primarnom sloju za brzi oporavak. Baze podataka generiraju ogromne količine WAL/transakcijskih log podataka. Zaključavanje ovih podataka godinama rezultirat će eksponencijalnim rastom troškova pohrane.
Umjesto toga, koristite slojeviti pristup:
* Sloj operativnog oporavka: 14 do 30 dana nepromjenjivog zadržavanja za potpune sigurnosne kopije i logove.
* Sloj dugoročnog arhiviranja: Mjesečne potpune sigurnosne kopije premještene u Glacier/Deep Archive s Vault Lockom na 1-7 godina.

4. Redovito testiranje oporavka u izoliranim (air-gapped) VPC-ovima

Nepromjenjivost jamči da se podaci ne mogu izbrisati, ali ne jamči da su podaci bez logičke korupcije. Morate automatizirati vraćanje svojih nepromjenjivih arhiva baza podataka u izolirani, air-gapped VPC ili VLAN. Pokrenite DBCC CHECKDB (SQL Server) ili pg_amcheck (PostgreSQL) na vraćenim podacima kako biste provjerili strukturni integritet.

Zaključak

Obrana od ransomwarea je vježba u pretpostavci proboja. Do trenutka kada se aktivira upozorenje u vašem SIEM-u, napadači su vjerojatno već pokušali kompromitirati vašu infrastrukturu za sigurnosno kopiranje. Projektiranjem arhiva baza podataka pomoću nepromjenjive pohrane u načinu usklađenosti, napadačima oduzimate njihovu glavnu polugu. Bez obzira koristite li izvorne API-je u oblaku, ZFS zadržavanja ili platformu za orkestraciju kao što je CloudSave, implementacija WORM pohrane više nije opcionalna—to je obvezan stup moderne administracije baza podataka i oporavka od katastrofe.