Nel panorama delle minacce moderno, il ransomware si è evoluto da crittografia opportunistica a campagne di multi-estorsione altamente mirate. Le minacce persistenti avanzate (APT) e i sindacati ransomware ora cercano attivamente infrastrutture di backup e archivi di database durante il loro tempo di permanenza nel sistema. Se un attaccante compromette il tuo database principale e contemporaneamente elimina o crittografa i tuoi repository di backup, la tua organizzazione dovrà affrontare una perdita di dati catastrofica.
Per gli amministratori di database (DBA) e gli ingegneri DevOps, la tradizionale strategia di backup 3-2-1 non è più sufficiente. Per garantire la sopravvivenza dei dati, i team di infrastruttura devono adottare la regola 3-2-1-1, dove l’ultimo “1” rappresenta lo storage immutabile.
Questo articolo fornisce un approfondimento tecnico completo sull’architettura, l’implementazione e la gestione dello storage immutabile per gli archivi di database, al fine di garantire un’assoluta resilienza contro i ransomware.
I meccanismi dello storage immutabile
Lo storage immutabile si basa su un’architettura WORM (Write-Once-Read-Many). Una volta che i dati vengono scritti su una destinazione immutabile, non possono essere modificati, crittografati o eliminati da alcun utente, inclusi gli amministratori con privilegi di root o account di servizio compromessi, fino alla scadenza di un blocco temporale applicato matematicamente.
Modalità Compliance vs. Modalità Governance
Quando si implementa l’immutabilità, in particolare nello storage a oggetti cloud come AWS S3, Azure Blob o SAN on-premise compatibili con S3, è necessario comprendere la distinzione tra le modalità di conservazione:
- Modalità Governance: Impedisce agli utenti standard di eliminare o modificare gli oggetti. Tuttavia, gli utenti con autorizzazioni IAM specifiche (ad esempio,
s3:BypassGovernanceRetention) possono ignorare il blocco. Questo è utile per i test ma insufficiente per la protezione contro i ransomware, poiché gli attaccanti spesso elevano i privilegi a domain admin o root. - Modalità Compliance: Il gold standard per la difesa contro i ransomware. Una volta che un oggetto è bloccato in modalità Compliance, il suo periodo di conservazione non può essere ridotto e l’oggetto non può essere eliminato da nessuno, incluso l’account root di AWS. Il blocco viene applicato a livello di cluster di storage.
Architettare una pipeline di backup immutabile
Un’architettura di archiviazione database robusta separa le operazioni attive del database dal livello di archivio immutabile. Non è possibile applicare l’immutabilità ai file di database attivi (come .mdf/.ldf in SQL Server o la directory pg_data in PostgreSQL) perché i database richiedono un accesso costante in lettura/scrittura.
Invece, l’immutabilità viene applicata a:
1. File di backup completi e differenziali: Gli snapshot di base del database.
2. Log delle transazioni / File WAL: Il flusso continuo di modifiche al database necessario per il ripristino Point-in-Time (PITR).
Destinazioni di storage per l’immutabilità
È possibile implementare lo storage immutabile su diversi livelli di infrastruttura:
* Cloud Object Storage: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* On-Premises Object Storage: MinIO, Cloudian o Pure Storage FlashBlade che supportano le API S3 Object Lock.
* Block/File Storage: ZFS con snapshot in sola lettura e amministrazione delegata, o attributi di file Linux.
Implementazione dello storage immutabile: procedure tecniche
1. Cloud Object Storage: AWS S3 Object Lock
Per proteggere i dump del database e i log delle transazioni in AWS, è necessario abilitare Object Lock al momento della creazione del bucket.
Per prima cosa, crea il bucket con Object Lock abilitato:
aws s3api create-bucket
--bucket prod-db-archive-immutable
--region us-east-1
--object-lock-enabled-for-bucket
Successivamente, configura la policy di conservazione predefinita. Per gli archivi di database, un blocco di conformità di 30 giorni è una base standard, garantendo un mese di backup inalterabili.
aws s3api put-object-lock-configuration
--bucket prod-db-archive-immutable
--object-lock-configuration '{
"ObjectLockEnabled": "Enabled",
"Rule": {
"DefaultRetention": {
"Mode": "COMPLIANCE",
"Days": 30
}
}
}'
Quando lo script o l’agente di backup del database invia un file a questo bucket, S3 calcola automaticamente la Retain Until Date basandosi sul timestamp di creazione dell’oggetto più 30 giorni.
2. Immutabilità On-Premises: ZFS e attributi Linux
Se stai archiviando database su un server di backup Linux on-premise, puoi ottenere una pseudo-immutabilità usando il comando chattr, o una vera immutabilità usando gli snapshot ZFS.
Utilizzo di Linux chattr:
Il flag +i (immutabile) impedisce la modifica, l’eliminazione o la ridenominazione dei file.
# Dump del database
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump
# Rendi il backup immutabile
sudo chattr +i /backups/mydb_$(date +%F).dump
# Verifica l'attributo
lsattr /backups/mydb_$(date +%F).dump
# Output: ----i---------e------- /backups/mydb_2023-10-27.dump
Nota: Sebbene chattr blocchi gli script ransomware di base, un attaccante sofisticato con accesso root può semplicemente eseguire chattr -i. Pertanto, questo deve essere combinato con un rigoroso RBAC e reti di backup isolate.
Utilizzo di snapshot ZFS:
ZFS fornisce una difesa molto più forte. Prendendo uno snapshot e applicando un “hold” su di esso, impedisci che lo snapshot venga distrutto.
# Crea uno snapshot del dataset di backup
zfs snapshot tank/db_backups@archive_$(date +%F)
# Applica un hold sullo snapshot per impedirne l'eliminazione
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)
# Nemmeno root può distruggere questo snapshot senza rilasciare l'hold
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy
Strategie di archiviazione specifiche per database
Per ottenere il ripristino Point-in-Time (PITR), è necessario archiviare continuamente i log delle transazioni nello storage immutabile.
Archiviazione WAL di PostgreSQL con pgBackRest
pgBackRest è uno strumento di backup altamente affidabile per PostgreSQL che supporta nativamente lo storage compatibile con S3. Per proteggere i tuoi Write-Ahead Logs (WAL), configura pgBackRest per inviarli direttamente al tuo bucket S3 immutabile.
Nel tuo 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
# Assicurati che la conservazione sia allineata con la configurazione S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2
[prod_cluster]
pg1-path=/var/lib/postgresql/14/main
Considerazione cruciale: Se il tuo bucket S3 applica un blocco di conformità di 30 giorni, ma pgBackRest tenta di far scadere ed eliminare i file WAL dopo 14 giorni in base a repo1-retention-archive, le chiamate API di eliminazione falliranno. Devi assicurarti che la policy di conservazione del tuo software di backup sia maggiore o uguale al blocco immutabile a livello di storage.
Microsoft SQL Server: Backup su URL
SQL Server supporta backup nativi direttamente su storage a oggetti compatibile con S3. Puoi configurare un job di SQL Server Agent per scrivere file .bak e .trn direttamente in un bucket immutabile.
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
Automazione e orchestrazione con CloudSave
Gestire i flag di conservazione immutabili, ruotare le chiavi di accesso e garantire la sincronizzazione tra le policy di conservazione del database e i blocchi di storage tramite script personalizzati è altamente soggetto a errori. Una singola configurazione errata in un cron job o in una chiamata API può lasciare i tuoi archivi esposti o causare costi di storage cloud alle stelle a causa di oggetti bloccati e orfani.
Le piattaforme di backup aziendali come CloudSave semplificano questa architettura. CloudSave si integra nativamente con AWS S3 Object Lock, Azure Blob Immutable Storage e API on-premise compatibili con S3.
Quando configuri un piano di backup del database in CloudSave:
1. La piattaforma gestisce automaticamente la quiescenza VSS (Volume Shadow Copy Service) per SQL Server o l’API pg_start_backup() per PostgreSQL.
2. Trasmette i dati di backup deduplicati e crittografati direttamente alla destinazione di storage.
3. CloudSave applica dinamicamente le chiamate API WORM (ad esempio, PutObjectRetention) su base per-oggetto, allineando perfettamente la durata del blocco di storage con la pianificazione di conservazione definita dalla policy.
4. Se un attaccante compromette la console di gestione di CloudSave, non potrà comunque eliminare i backup, poiché il blocco di conformità è applicato dall’infrastruttura di storage sottostante, non dal software di backup.
Best practice per archivi di database immutabili
Per garantire che la tua architettura immutabile sia veramente resiliente, attieniti alle seguenti best practice di ingegneria dei sistemi:
1. Sincronizzazione NTP rigorosa
I blocchi immutabili sono legati matematicamente ai timestamp. Se il servizio NTP (Network Time Protocol) sul tuo array di storage o server di backup viene compromesso o subisce derive, può causare la scadenza prematura dei blocchi o impedirne la scadenza. Assicurati che la tua infrastruttura di storage utilizzi fonti NTP autenticate e ridondanti.
2. Isolare ruoli e credenziali IAM
Le credenziali utilizzate per scrivere nel bucket immutabile devono avere solo le autorizzazioni s3:PutObject e s3:PutObjectRetention. Non dovrebbero mai avere autorizzazioni s3:DeleteObject o s3:PutBucketObjectLockConfiguration.
Esempio di una policy IAM con privilegi minimi per un agente di backup del database:
{
"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. Dimensionamento del periodo di conservazione
Non impostare blocchi di conformità per periodi eccessivamente lunghi (ad esempio, 7 anni per conformità) sul tuo livello di ripristino rapido primario. I database generano enormi quantità di dati WAL/log delle transazioni. Bloccare questi dati per anni comporterà una crescita esponenziale dei costi di storage.
Utilizza invece un approccio a livelli:
* Livello di ripristino operativo: da 14 a 30 giorni di conservazione immutabile per backup completi e log.
* Livello di archiviazione a lungo termine: backup completi mensili spostati su Glacier/Deep Archive con Vault Lock per 1-7 anni.
4. Test di ripristino regolari in VPC air-gapped
L’immutabilità garantisce che i dati non possano essere eliminati, ma non garantisce che i dati siano privi di corruzione logica. Devi automatizzare il ripristino dei tuoi archivi di database immutabili in un VPC o VLAN isolato e air-gapped. Esegui DBCC CHECKDB (SQL Server) o pg_amcheck (PostgreSQL) sui dati ripristinati per verificarne l’integrità strutturale.
Conclusione
La difesa contro i ransomware è un esercizio che parte dal presupposto di una violazione avvenuta. Nel momento in cui scatta un avviso nel tuo SIEM, gli attori delle minacce hanno probabilmente già tentato di compromettere la tua infrastruttura di backup. Architettando i tuoi archivi di database utilizzando lo storage immutabile in modalità Compliance, privi gli attaccanti della loro principale leva. Che tu utilizzi API cloud native, hold ZFS o una piattaforma di orchestrazione aziendale come CloudSave, implementare lo storage WORM non è più facoltativo: è un pilastro obbligatorio dell’amministrazione moderna dei database e del disaster recovery.
