Datu-baseen artxiboetarako biltegiratze aldaezina arkitektatzea ransomware-ari aurre egiteko

Mehatxuen egungo paisaian, ransomware-a enkriptatze oportunistatik estortsio anitzeko kanpaina oso zuzenduetara eboluzionatu da. Mehatxu Iraunkor Aurreratuek (APT) eta ransomware sindikatuek aktiboki bilatzen dituzte babeskopien azpiegiturak eta datu-baseen artxiboak beren egonaldian. Erasotzaile batek zure datu-base nagusia konprometitzen badu eta, aldi berean, zure babeskopien biltegiak ezabatu edo enkriptatzen baditu, zure erakundeak datuen galera katastrofikoa jasango du.

Datu-baseen administratzaileentzat (DBA) eta DevOps ingeniarientzat, 3-2-1 babeskopia estrategia tradizionala jada ez da nahikoa. Datuen biziraupena bermatzeko, azpiegitura-taldeek 3-2-1-1 araua hartu behar dute, non azken “1” horrek biltegiratze aldaezina (immutable storage) adierazten duen.

Artikulu honek datu-baseen artxiboetarako biltegiratze aldaezina diseinatzeko, ezartzeko eta kudeatzeko ikuspegi tekniko sakona eskaintzen du, ransomwarearen aurkako erresilientzia absolutua bermatzeko.

Biltegiratze aldaezinaren mekanika

Biltegiratze aldaezina Write-Once-Read-Many (WORM) arkitekturan oinarritzen da. Datuak helburu aldaezin batean idazten direnean, ezin dira aldatu, enkriptatu edo ezabatu inongo erabiltzailek—root pribilegioak dituzten administratzaileek edo konprometitutako zerbitzu-kontuek barne—, matematikoki behartutako denbora-blokeoa iraungi arte.

Betetze-modua vs. Gobernantza-modua

Aldaezintasuna ezartzerakoan, bereziki AWS S3, Azure Blob edo S3-rekin bateragarriak diren lokaleko SAN bezalako hodeiko objektu-biltegiratzeetan, atxikipen-moduen arteko aldea ulertu behar duzu:

• Gobernantza-modua: Erabiltzaile estandarrei objektuak ezabatzea edo aldatzea eragozten die. Hala ere, IAM baimen zehatzak dituzten erabiltzaileek (adibidez, s3:BypassGovernanceRetention) blokeoa gainidatzi dezakete. Hau probak egiteko baliagarria da, baina ez da nahikoa ransomwarearen aurkako babeserako, erasotzaileek sarritan pribilegioak domeinu-administratzaile edo root mailara igotzen baitituzte.
• Betetze-modua (Compliance Mode): Ransomwarearen aurkako defentsarako urrezko estandarra. Objektu bat Betetze-moduan blokeatuta dagoenean, bere atxikipen-epea ezin da laburtu, eta objektua ezin du inork ezabatu, AWS root kontuak barne. Blokeoa biltegiratze-kluster mailan behartzen da.

Babeskopia-kanal aldaezin bat diseinatzea

Datu-baseen artxibatzeko arkitektura sendo batek datu-baseen eragiketa aktiboak artxibo-maila aldaezinetik bereizten ditu. Ezin duzu aldaezintasuna aplikatu datu-baseen fitxategi aktiboei (SQL Server-eko .mdf/.ldf edo PostgreSQL-ko pg_data direktorioa bezalakoak), datu-baseek irakurtzeko/idazteko sarbide etengabea behar dutelako.

Horren ordez, aldaezintasuna honako hauei aplikatzen zaie:
1. Babeskopia-fitxategi osoak eta diferentzialak: Datu-basearen oinarrizko argazkiak (snapshots).
2. Transakzio-erregistroak / WAL fitxategiak: Point-in-Time Recovery (PITR) egiteko beharrezkoak diren datu-baseen aldaketen fluxu jarraitua.

Aldaezintasunerako biltegiratze-helburuak

Biltegiratze aldaezina azpiegitura-maila ezberdinetan ezar dezakezu:
* Hodeiko objektu-biltegiratzea: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Lokaleko objektu-biltegiratzea: MinIO, Cloudian edo Pure Storage FlashBlade, S3 Object Lock APIak onartzen dituztenak.
* Bloke/Fitxategi biltegiratzea: ZFS, irakurtzeko soilik diren argazkiekin eta administrazio delegatuarekin, edo Linux fitxategi-atributuak.

Biltegiratze aldaezina ezartzea: Gida teknikoak

1. Hodeiko objektu-biltegiratzea: AWS S3 Object Lock

AWS-n datu-baseen dump-ak eta transakzio-erregistroak babesteko, Object Lock gaitu behar duzu ontzia (bucket) sortzerakoan.

Lehenik, sortu ontzia Object Lock gaituta duela:

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

Ondoren, konfiguratu atxikipen-politika lehenetsia. Datu-baseen artxiboetarako, 30 eguneko betetze-blokeoa oinarrizko estandar bat da, aldaezinak diren hilabeteko babeskopiak dituzula ziurtatuz.

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

Zure datu-basearen babeskopia-scriptak edo agenteak fitxategi bat ontzi honetara bidaltzen duenean, S3-k automatikoki kalkulatzen du Retain Until Date, objektua sortu zeneko denbora-zigiluari 30 egun gehituz.

2. Lokaleko aldaezintasuna: ZFS eta Linux atributuak

Datu-baseak lokaleko Linux babeskopia-zerbitzari batean artxibatzen ari bazara, pseudo-aldaezintasuna lor dezakezu chattr komandoa erabiliz, edo benetako aldaezintasuna ZFS argazkiak erabiliz.

Linux chattr erabiliz:
+i (aldaezina) banderak fitxategia aldatzea, ezabatzea edo izena aldatzea eragozten du.

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

# Babeskopia aldaezin bihurtu
sudo chattr +i /backups/mydb_$(date +%F).dump

# Atributua egiaztatu
lsattr /backups/mydb_$(date +%F).dump
# Irteera: ----i---------e------- /backups/mydb_2023-10-27.dump

Oharra: chattr-ek oinarrizko ransomware scriptak gelditzen dituen arren, root sarbidea duen erasotzaile sofistikatu batek chattr -i exekutatu dezake. Hori dela eta, hau RBAC zorrotzarekin eta isolatutako babeskopia-sareekin konbinatu behar da.

ZFS argazkiak (Snapshots) erabiliz:
ZFS-k defentsa askoz sendoagoa eskaintzen du. Argazki bat ateraz eta “hold” bat jarriz, argazkia ezabatzea eragozten duzu.

# Babeskopiaren datu-multzoaren argazkia atera
zfs snapshot tank/db_backups@archive_$(date +%F)

# Argazkiari hold bat jarri ezabatzea eragozteko
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Root-ak ere ezin du argazki hau suntsitu hold-a askatu gabe
zfs destroy tank/db_backups@archive_$(date +%F)
# Irteera: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Datu-baseetarako artxibatze-estrategia espezifikoak

Point-in-Time Recovery (PITR) lortzeko, transakzio-erregistroak etengabe artxibatu behar dituzu zure biltegiratze aldaezinean.

PostgreSQL WAL artxibatzea pgBackRest-ekin

pgBackRest PostgreSQL-rako babeskopia-tresna oso fidagarria da, S3-rekin bateragarria den biltegiratzea modu natiboan onartzen duena. Zure Write-Ahead Logs (WAL) babesteko, konfiguratu pgBackRest zuzenean zure S3 ontzi aldaezinera bidaltzeko.

Zure pgbackrest.conf fitxategian:

[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

# Ziurtatu atxikipena zure S3 Object Lock konfigurazioarekin bat datorrela
repo1-retention-full=2
repo1-retention-archive=2

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

Kontuan hartu beharrekoa: Zure S3 ontziak 30 eguneko Betetze-blokeoa behartzen badu, baina pgBackRest-ek WAL fitxategiak 14 egunen buruan iraungitzen eta ezabatzen saiatzen bada repo1-retention-archive-n oinarrituta, ezabatzeko API deiak huts egingo dute. Ziurtatu behar duzu zure babeskopia-softwarearen atxikipen-politika biltegiratze-mailako blokeo aldaezina baino handiagoa edo berdina dela.

Microsoft SQL Server: Backup to URL

SQL Server-ek babeskopia natiboak onartzen ditu zuzenean S3-rekin bateragarria den objektu-biltegiratzera. SQL Server Agent lan bat konfigura dezakezu .bak eta .trn fitxategiak zuzenean ontzi aldaezin batean idazteko.

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

CloudSave-rekin automatizatzea eta orkestratzea

Atxikipen-bandera aldaezinak kudeatzea, sarbide-gakoak biratzea eta datu-baseen atxikipen-politiken eta biltegiratze-blokeoen arteko sinkronizazioa script pertsonalizatuen bidez ziurtatzea akatsetarako joera handia du. Cron lan batean edo API dei batean egindako konfigurazio oker bakar batek zure artxiboak agerian utzi ditzake edo hodeiko biltegiratze-kostuak izugarri handitu ditzake, umezurtz geratu diren blokeatutako objektuengatik.

CloudSave bezalako babeskopia-plataforma korporatiboek arkitektura hau sinplifikatzen dute. CloudSave-k modu natiboan integratzen du AWS S3 Object Lock, Azure Blob Immutable Storage eta lokaleko S3-rekin bateragarriak diren APIekin.

CloudSave-n datu-baseen babeskopia-plan bat konfiguratzean:
1. Plataformak automatikoki kudeatzen du VSS (Volume Shadow Copy Service) lasaitasuna SQL Server-erako edo pg_start_backup() APIa PostgreSQL-rako.
2. Deduplikatutako eta enkriptatutako babeskopia-datuak zuzenean biltegiratze-helburura igortzen ditu.
3. CloudSave-k dinamikoki aplikatzen ditu WORM API deiak (adibidez, PutObjectRetention) objektuz objektu, biltegiratze-blokeoaren iraupena politikak definitutako atxikipen-egutegiarekin ezin hobeto lerrokatuz.
4. Erasotzaile batek CloudSave kudeaketa-kontsola konprometitzen badu ere, ezin ditu babeskopiak ezabatu, betetze-blokeoa azpiko biltegiratze-azpiegiturak behartzen duelako, ez babeskopia-softwareak.

Datu-baseen artxibo aldaezinetarako praktika onenak

Zure arkitektura aldaezina benetan erresilientea dela ziurtatzeko, jarraitu sistema-ingeniaritzako praktika on hauei:

1. NTP sinkronizazio zorrotza

Blokeo aldaezinak matematikoki denbora-zigiluei lotuta daude. Zure biltegiratze-matrizean edo babeskopia-zerbitzarian NTP (Network Time Protocol) zerbitzua konprometitzen bada edo desbideratzen bada, blokeoak goizegi iraungitzea edo inoiz ez iraungitzea eragin dezake. Ziurtatu zure biltegiratze-azpiegiturak NTP iturri autentifikatu eta erredundanteak erabiltzen dituela.

2. IAM rolak eta kredentzialak isolatzea

Ontzi aldaezinean idazteko erabiltzen diren kredentzialek s3:PutObject eta s3:PutObjectRetention baimenak soilik izan behar dituzte. Inoiz ez dute s3:DeleteObject edo s3:PutBucketObjectLockConfiguration baimenik izan behar.

Datu-baseen babeskopia-agente baterako gutxieneko pribilegioen IAM politika baten adibidea:

{
    "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. Atxikipen-epea dimentsionatzea

Ez ezarri betetze-blokeoak epe luzeegietarako (adibidez, 7 urte betetzerako) zure berreskuratze azkarreko maila nagusian. Datu-baseek WAL/transakzio-erregistroen datu kopuru izugarriak sortzen dituzte. Datu horiek urte luzez blokeatzeak biltegiratze-kostuen hazkunde esponentziala ekarriko du.
Horren ordez, erabili mailakatutako ikuspegia:
* Berreskuratze Operatiboaren Maila: 14-30 eguneko atxikipen aldaezina babeskopia osoetarako eta erregistroetarako.
* Epe Luzerako Artxibatze Maila: Hilero egiten diren babeskopia osoak Glacier/Deep Archive-ra mugituta, Vault Lock-arekin 1-7 urterako.

4. Berreskuratze-probak aldizka egitea Air-Gapped VPC-etan

Aldaezintasunak datuak ezin direla ezabatu bermatzen du, baina ez du bermatzen datuak ustelkeria logikorik gabe daudenik. Zure datu-baseen artxibo aldaezinen berreskuratzea automatizatu behar duzu isolatutako, air-gapped VPC edo VLAN batean. Exekutatu DBCC CHECKDB (SQL Server) edo pg_amcheck (PostgreSQL) berreskuratutako datuetan, osotasun estrukturala egiaztatzeko.

Ondorioa

Ransomwarearen aurkako defentsa urraketa bat gertatuko dela suposatzean datza. Zure SIEM-ean alerta bat pizten denerako, mehatxu-eragileek ziurrenik zure babeskopia-azpiegitura konprometitzen saiatu dira jada. Zure datu-baseen artxiboak Betetze-moduan biltegiratze aldaezina erabiliz diseinatuz, erasotzaileei beren palanka nagusia kentzen diezu. Hodeiko API natiboak, ZFS hold-ak edo CloudSave bezalako orkestrazio-plataforma korporatibo bat erabili, WORM biltegiratzea ezartzea jada ez da aukerakoa; datu-baseen administrazio modernoaren eta hondamendien berreskurapenaren ezinbesteko zutabea da.