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.

În peisajul actual al amenințărilor, ransomware-ul a evoluat de la criptarea oportunistă la campanii extrem de țintite, de tip multi-extorcare. Amenințările persistente avansate (APT) și sindicatele de ransomware caută acum în mod activ infrastructura de backup și arhivele bazelor de date în timpul perioadei de persistență în rețea. Dacă un atacator compromite baza de date principală și, simultan, șterge sau criptează depozitele de backup, organizația dumneavoastră se confruntă cu o pierdere catastrofală de date.

Pentru administratorii de baze de date (DBA) și inginerii DevOps, strategia tradițională de backup 3-2-1 nu mai este suficientă. Pentru a garanta supraviețuirea datelor, echipele de infrastructură trebuie să adopte regula 3-2-1-1, unde ultimul „1” reprezintă stocarea imuabilă.

Acest articol oferă o analiză tehnică detaliată și cuprinzătoare despre arhitecturarea, implementarea și gestionarea stocării imuabile pentru arhivele bazelor de date, pentru a asigura o reziliență absolută împotriva ransomware-ului.

Mecanismele stocării imuabile

Stocarea imuabilă se bazează pe o arhitectură de tip Write-Once-Read-Many (WORM). Odată ce datele sunt scrise într-o destinație imuabilă, acestea nu pot fi modificate, criptate sau șterse de niciun utilizator—inclusiv de administratori cu privilegii root sau conturi de serviciu compromise—până la expirarea unui blocaj temporal impus matematic.

Modul de conformitate vs. Modul de guvernanță

Atunci când implementați imuabilitatea, în special în stocarea de obiecte în cloud precum AWS S3, Azure Blob sau SAN-uri on-premises compatibile cu S3, trebuie să înțelegeți distincția dintre modurile de retenție:

  • Modul de guvernanță (Governance Mode): Împiedică utilizatorii standard să șteargă sau să modifice obiecte. Totuși, utilizatorii cu permisiuni IAM specifice (de exemplu, s3:BypassGovernanceRetention) pot suprascrie blocajul. Acest lucru este util pentru testare, dar insuficient pentru protecția împotriva ransomware-ului, deoarece atacatorii escaladează adesea privilegiile până la nivel de administrator de domeniu sau root.
  • Modul de conformitate (Compliance Mode): Standardul de aur pentru apărarea împotriva ransomware-ului. Odată ce un obiect este blocat în modul de conformitate, perioada sa de retenție nu poate fi scurtată, iar obiectul nu poate fi șters de nimeni, inclusiv de contul root AWS. Blocajul este impus la nivelul clusterului de stocare.

Arhitecturarea unui flux de backup imuabil

O arhitectură robustă de arhivare a bazelor de date separă operațiunile active ale bazei de date de nivelul de arhivare imuabil. Nu puteți aplica imuabilitatea fișierelor active ale bazei de date (cum ar fi .mdf/.ldf în SQL Server sau directorul pg_data în PostgreSQL), deoarece bazele de date necesită acces constant de citire/scriere.

În schimb, imuabilitatea se aplică pentru:
1. Fișiere de backup complete și diferențiale: Snapshot-urile de bază ale bazei de date.
2. Jurnale de tranzacții / Fișiere WAL: Fluxul continuu de modificări ale bazei de date necesar pentru recuperarea la un moment dat (Point-in-Time Recovery – PITR).

Destinații de stocare pentru imuabilitate

Puteți implementa stocarea imuabilă pe diferite niveluri de infrastructură:
* Stocare de obiecte în cloud: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Stocare de obiecte on-premises: MinIO, Cloudian sau Pure Storage FlashBlade care suportă API-urile S3 Object Lock.
* Stocare de tip Block/File: ZFS cu snapshot-uri read-only și administrare delegată sau atribute de fișiere Linux.

Implementarea stocării imuabile: Ghiduri tehnice

1. Stocare de obiecte în cloud: AWS S3 Object Lock

Pentru a proteja dump-urile bazelor de date și jurnalele de tranzacții în AWS, trebuie să activați Object Lock în momentul creării bucket-ului.

Mai întâi, creați bucket-ul cu Object Lock activat:

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

Apoi, configurați politica de retenție implicită. Pentru arhivele bazelor de date, un blocaj de conformitate de 30 de zile este un standard de bază, asigurându-vă că aveți o lună de backup-uri inalterabile.

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

Când scriptul sau agentul de backup al bazei de date trimite un fișier în acest bucket, S3 calculează automat Retain Until Date pe baza marcajului temporal de creare a obiectului plus 30 de zile.

2. Imuabilitate on-premises: ZFS și atribute Linux

Dacă arhivați bazele de date pe un server de backup Linux on-premises, puteți obține o pseudo-imuabilitate folosind comanda chattr sau o imuabilitate reală folosind snapshot-uri ZFS.

Folosind chattr în Linux:
Indicatorul +i (imuabil) previne modificarea, ștergerea sau redenumirea fișierului.

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

# Faceți backup-ul imuabil
sudo chattr +i /backups/mydb_$(date +%F).dump

# Verificați atributul
lsattr /backups/mydb_$(date +%F).dump
# Output: ----i---------e------- /backups/mydb_2023-10-27.dump

Notă: Deși chattr oprește scripturile ransomware de bază, un atacator sofisticat cu acces root poate pur și simplu să ruleze chattr -i. Prin urmare, acest lucru trebuie combinat cu un control strict al accesului (RBAC) și rețele de backup izolate.

Folosind snapshot-uri ZFS:
ZFS oferă o apărare mult mai puternică. Prin realizarea unui snapshot și aplicarea unei „rețineri” (hold) pe acesta, împiedicați distrugerea snapshot-ului.

# Realizați un snapshot al setului de date de backup
zfs snapshot tank/db_backups@archive_$(date +%F)

# Aplicați o reținere pe snapshot pentru a preveni ștergerea
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Chiar și root nu poate distruge acest snapshot fără a elimina reținerea
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Strategii de arhivare specifice bazelor de date

Pentru a obține recuperarea la un moment dat (PITR), trebuie să arhivați continuu jurnalele de tranzacții în stocarea imuabilă.

Arhivarea WAL PostgreSQL cu pgBackRest

pgBackRest este un instrument de backup extrem de fiabil pentru PostgreSQL care suportă nativ stocarea compatibilă cu S3. Pentru a vă proteja jurnalele Write-Ahead (WAL), configurați pgBackRest să trimită datele direct în bucket-ul S3 imuabil.

În fișierul 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

# Asigurați-vă că retenția se aliniază cu configurația S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2

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

Considerație crucială: Dacă bucket-ul S3 impune un blocaj de conformitate de 30 de zile, dar pgBackRest încearcă să expire și să șteargă fișierele WAL după 14 zile pe baza repo1-retention-archive, apelurile API de ștergere vor eșua. Trebuie să vă asigurați că politica de retenție a software-ului de backup este mai mare sau egală cu blocajul imuabil la nivel de stocare.

Microsoft SQL Server: Backup to URL

SQL Server suportă backup-uri native direct către stocarea de obiecte compatibilă cu S3. Puteți configura un job SQL Server Agent pentru a scrie fișiere .bak și .trn direct într-un bucket imuabil.

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

Automatizarea și orchestrarea cu CloudSave

Gestionarea indicatorilor de retenție imuabili, rotirea cheilor de acces și asigurarea sincronizării între politicile de retenție ale bazei de date și blocajele de stocare prin scripturi personalizate este extrem de predispusă la erori. O singură configurare greșită într-un job cron sau apel API poate lăsa arhivele expuse sau poate duce la costuri de stocare în cloud exorbitante din cauza obiectelor blocate orfane.

Platformele de backup enterprise precum CloudSave simplifică această arhitectură. CloudSave se integrează nativ cu AWS S3 Object Lock, Azure Blob Immutable Storage și API-urile on-premises compatibile cu S3.

Atunci când configurați un plan de backup pentru baze de date în CloudSave:
1. Platforma gestionează automat starea de repaus VSS (Volume Shadow Copy Service) pentru SQL Server sau API-ul pg_start_backup() pentru PostgreSQL.
2. Transmite datele de backup deduplicate și criptate direct către destinația de stocare.
3. CloudSave aplică dinamic apelurile API WORM (de exemplu, PutObjectRetention) pentru fiecare obiect, aliniind perfect durata blocajului de stocare cu programul de retenție definit prin politică.
4. Dacă un atacator compromite consola de management CloudSave, acesta tot nu poate șterge backup-urile, deoarece blocajul de conformitate este impus de infrastructura de stocare subiacentă, nu de software-ul de backup.

Cele mai bune practici pentru arhivele imuabile ale bazelor de date

Pentru a vă asigura că arhitectura imuabilă este cu adevărat rezilientă, respectați următoarele bune practici de inginerie a sistemelor:

1. Sincronizare NTP strictă

Blocajele imuabile sunt legate matematic de marcajele temporale. Dacă serviciul NTP (Network Time Protocol) de pe matricea de stocare sau serverul de backup este compromis sau suferă derive, poate cauza expirarea prematură a blocajelor sau imposibilitatea expirării acestora. Asigurați-vă că infrastructura de stocare utilizează surse NTP autentificate și redundante.

2. Izolarea rolurilor și credențialelor IAM

Credențialele utilizate pentru scrierea în bucket-ul imuabil trebuie să aibă doar permisiunile s3:PutObject și s3:PutObjectRetention. Acestea nu trebuie niciodată să aibă permisiuni s3:DeleteObject sau s3:PutBucketObjectLockConfiguration.

Exemplu de politică IAM cu privilegii minime pentru un agent de backup al bazei de date:

{
    "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. Dimensionarea perioadei de retenție

Nu setați blocaje de conformitate pentru perioade excesiv de lungi (de exemplu, 7 ani pentru conformitate) pe nivelul principal de recuperare rapidă. Bazele de date generează cantități masive de date WAL/jurnale de tranzacții. Blocarea acestor date timp de ani de zile va duce la o creștere exponențială a costurilor de stocare.
În schimb, utilizați o abordare pe niveluri:
* Nivel de recuperare operațională: 14 până la 30 de zile de retenție imuabilă pentru backup-uri complete și jurnale.
* Nivel de arhivare pe termen lung: Backup-uri complete lunare mutate în Glacier/Deep Archive cu Vault Lock pentru 1-7 ani.

4. Testarea regulată a recuperării în VPC-uri izolate (Air-Gapped)

Imuabilitatea garantează că datele nu pot fi șterse, dar nu garantează că datele sunt libere de corupere logică. Trebuie să automatizați restaurarea arhivelor imuabile ale bazei de date într-un VPC sau VLAN izolat (air-gapped). Rulați DBCC CHECKDB (SQL Server) sau pg_amcheck (PostgreSQL) pe datele restaurate pentru a verifica integritatea structurală.

Concluzie

Apărarea împotriva ransomware-ului este un exercițiu de asumare a breșei. Până când o alertă este declanșată în SIEM-ul dumneavoastră, actorii amenințători probabil au încercat deja să compromită infrastructura de backup. Prin arhitecturarea arhivelor bazelor de date folosind stocarea imuabilă în modul de conformitate, îi privați pe atacatori de principala lor pârghie. Indiferent dacă utilizați API-uri cloud native, rețineri ZFS sau o platformă de orchestrare enterprise precum CloudSave, implementarea stocării WORM nu mai este opțională—este un pilon obligatoriu al administrării moderne a bazelor de date și al recuperării în caz de dezastru.

Categorii