Nel panorama delle minacce moderno, il ransomware si \u00e8 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\u00e0 affrontare una perdita di dati catastrofica.<\/p>\n
Per gli amministratori di database (DBA) e gli ingegneri DevOps, la tradizionale strategia di backup 3-2-1 non \u00e8 pi\u00f9 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<\/strong>.<\/p>\n 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.<\/p>\n 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.<\/p>\n Quando si implementa l’immutabilit\u00e0, in particolare nello storage a oggetti cloud come AWS S3, Azure Blob o SAN on-premise compatibili con S3, \u00e8 necessario comprendere la distinzione tra le modalit\u00e0 di conservazione:<\/p>\n Un’architettura di archiviazione database robusta separa le operazioni attive del database dal livello di archivio immutabile. Non \u00e8 possibile applicare l’immutabilit\u00e0 ai file di database attivi (come Invece, l’immutabilit\u00e0 viene applicata a: \u00c8 possibile implementare lo storage immutabile su diversi livelli di infrastruttura: Per proteggere i dump del database e i log delle transazioni in AWS, \u00e8 necessario abilitare Object Lock al momento della creazione del bucket.<\/p>\n Per prima cosa, crea il bucket con Object Lock abilitato:<\/p>\n Successivamente, configura la policy di conservazione predefinita. Per gli archivi di database, un blocco di conformit\u00e0 di 30 giorni \u00e8 una base standard, garantendo un mese di backup inalterabili.<\/p>\n Quando lo script o l’agente di backup del database invia un file a questo bucket, S3 calcola automaticamente la Se stai archiviando database su un server di backup Linux on-premise, puoi ottenere una pseudo-immutabilit\u00e0 usando il comando Utilizzo di Linux Nota: Sebbene Utilizzo di snapshot ZFS:<\/strong> Per ottenere il ripristino Point-in-Time (PITR), \u00e8 necessario archiviare continuamente i log delle transazioni nello storage immutabile.<\/p>\n Nel tuo Considerazione cruciale:<\/em> Se il tuo bucket S3 applica un blocco di conformit\u00e0 di 30 giorni, ma SQL Server supporta backup nativi direttamente su storage a oggetti compatibile con S3. Puoi configurare un job di SQL Server Agent per scrivere file 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 \u00e8 altamente soggetto a errori. Una singola configurazione errata in un cron job o in una chiamata API pu\u00f2 lasciare i tuoi archivi esposti o causare costi di storage cloud alle stelle a causa di oggetti bloccati e orfani.<\/p>\n 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.<\/p>\n Quando configuri un piano di backup del database in CloudSave: Per garantire che la tua architettura immutabile sia veramente resiliente, attieniti alle seguenti best practice di ingegneria dei sistemi:<\/p>\n 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\u00f2 causare la scadenza prematura dei blocchi o impedirne la scadenza. Assicurati che la tua infrastruttura di storage utilizzi fonti NTP autenticate e ridondanti.<\/p>\n Le credenziali utilizzate per scrivere nel bucket immutabile devono avere solo le autorizzazioni Esempio di una policy IAM con privilegi minimi per un agente di backup del database:<\/p>\n Non impostare blocchi di conformit\u00e0 per periodi eccessivamente lunghi (ad esempio, 7 anni per conformit\u00e0) sul tuo livello di ripristino rapido primario. I database generano enormi quantit\u00e0 di dati WAL\/log delle transazioni. Bloccare questi dati per anni comporter\u00e0 una crescita esponenziale dei costi di storage. L’immutabilit\u00e0 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 La difesa contro i ransomware \u00e8 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\u00e0 tentato di compromettere la tua infrastruttura di backup. Architettando i tuoi archivi di database utilizzando lo storage immutabile in modalit\u00e0 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 \u00e8 pi\u00f9 facoltativo: \u00e8 un pilastro obbligatorio dell’amministrazione moderna dei database e del disaster recovery.<\/p>\n","protected":false},"excerpt":{"rendered":" ** 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Immutable Database Storage to Defeat Ransomware","rank_math_description":"** 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.","rank_math_focus_keyword":"immutable database storage","footnotes":""},"categories":[503],"tags":[4645,4646,4647,1311,4648,4649],"class_list":["post-6377","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-3-2-1-1-backup","tag-data-survivability","tag-database-archives","tag-enterprise-backup","tag-immutable-storage","tag-ransomware-protection"],"yoast_head":"\nI meccanismi dello storage immutabile<\/h2>\n
Modalit\u00e0 Compliance vs. Modalit\u00e0 Governance<\/h3>\n
\n
s3:BypassGovernanceRetention<\/code>) possono ignorare il blocco. Questo \u00e8 utile per i test ma insufficiente per la protezione contro i ransomware<\/strong>, poich\u00e9 gli attaccanti spesso elevano i privilegi a domain admin o root.<\/li>\nArchitettare una pipeline di backup immutabile<\/h2>\n
.mdf<\/code>\/.ldf<\/code> in SQL Server o la directory pg_data<\/code> in PostgreSQL) perch\u00e9 i database richiedono un accesso costante in lettura\/scrittura.<\/p>\n
\n1. File di backup completi e differenziali:<\/strong> Gli snapshot di base del database.
\n2. Log delle transazioni \/ File WAL:<\/strong> Il flusso continuo di modifiche al database necessario per il ripristino Point-in-Time (PITR).<\/p>\nDestinazioni di storage per l’immutabilit\u00e0<\/h3>\n
\n* Cloud Object Storage:<\/strong> AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
\n* On-Premises Object Storage:<\/strong> MinIO, Cloudian o Pure Storage FlashBlade che supportano le API S3 Object Lock.
\n* Block\/File Storage:<\/strong> ZFS con snapshot in sola lettura e amministrazione delegata, o attributi di file Linux.<\/p>\nImplementazione dello storage immutabile: procedure tecniche<\/h2>\n
1. Cloud Object Storage: AWS S3 Object Lock<\/h3>\n
aws s3api create-bucket \n --bucket prod-db-archive-immutable \n --region us-east-1 \n --object-lock-enabled-for-bucket\n<\/code><\/pre>\naws s3api put-object-lock-configuration \n --bucket prod-db-archive-immutable \n --object-lock-configuration '{\n "ObjectLockEnabled": "Enabled",\n "Rule": {\n "DefaultRetention": {\n "Mode": "COMPLIANCE",\n "Days": 30\n }\n }\n }'\n<\/code><\/pre>\nRetain Until Date<\/code> basandosi sul timestamp di creazione dell’oggetto pi\u00f9 30 giorni.<\/p>\n2. Immutabilit\u00e0 On-Premises: ZFS e attributi Linux<\/h3>\n
chattr<\/code>, o una vera immutabilit\u00e0 usando gli snapshot ZFS.<\/p>\nchattr<\/code>:<\/strong>
\nIl flag +i<\/code> (immutabile) impedisce la modifica, l’eliminazione o la ridenominazione dei file.<\/p>\n# Dump del database\npg_dump -U postgres -Fc mydb > \/backups\/mydb_$(date +%F).dump\n\n# Rendi il backup immutabile\nsudo chattr +i \/backups\/mydb_$(date +%F).dump\n\n# Verifica l'attributo\nlsattr \/backups\/mydb_$(date +%F).dump\n# Output: ----i---------e------- \/backups\/mydb_2023-10-27.dump\n<\/code><\/pre>\nchattr<\/code> blocchi gli script ransomware di base, un attaccante sofisticato con accesso root pu\u00f2 semplicemente eseguire chattr -i<\/code>. Pertanto, questo deve essere combinato con un rigoroso RBAC e reti di backup isolate.<\/em><\/p>\n
\nZFS fornisce una difesa molto pi\u00f9 forte. Prendendo uno snapshot e applicando un “hold” su di esso, impedisci che lo snapshot venga distrutto.<\/p>\n# Crea uno snapshot del dataset di backup\nzfs snapshot tank\/db_backups@archive_$(date +%F)\n\n# Applica un hold sullo snapshot per impedirne l'eliminazione\nzfs hold keep_30_days tank\/db_backups@archive_$(date +%F)\n\n# Nemmeno root pu\u00f2 distruggere questo snapshot senza rilasciare l'hold\nzfs destroy tank\/db_backups@archive_$(date +%F)\n# Output: cannot destroy 'tank\/db_backups@archive_...': dataset is busy\n<\/code><\/pre>\nStrategie di archiviazione specifiche per database<\/h2>\n
Archiviazione WAL di PostgreSQL con pgBackRest<\/h3>\n
pgBackRest<\/code> \u00e8 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<\/code> per inviarli direttamente al tuo bucket S3 immutabile.<\/p>\npgbackrest.conf<\/code>:<\/p>\n[global]\nrepo1-type=s3\nrepo1-s3-bucket=prod-db-archive-immutable\nrepo1-s3-region=us-east-1\nrepo1-s3-endpoint=s3.amazonaws.com\nrepo1-s3-key=AKIAIOSFODNN7EXAMPLE\nrepo1-s3-key-secret=wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\n\n# Assicurati che la conservazione sia allineata con la configurazione S3 Object Lock\nrepo1-retention-full=2\nrepo1-retention-archive=2\n\n[prod_cluster]\npg1-path=\/var\/lib\/postgresql\/14\/main\n<\/code><\/pre>\npgBackRest<\/code> tenta di far scadere ed eliminare i file WAL dopo 14 giorni in base a repo1-retention-archive<\/code>, 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.<\/p>\nMicrosoft SQL Server: Backup su URL<\/h3>\n
.bak<\/code> e .trn<\/code> direttamente in un bucket immutabile.<\/p>\nCREATE CREDENTIAL [s3:\/\/prod-db-archive-immutable.s3.us-east-1.amazonaws.com]\nWITH IDENTITY = 'S3 Access Key',\nSECRET = 'AccessKeyID:SecretAccessKey';\nGO\n\nBACKUP DATABASE [ProductionDB]\nTO URL = 's3:\/\/prod-db-archive-immutable.s3.us-east-1.amazonaws.com\/ProductionDB_Full.bak'\nWITH FORMAT, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\nAutomazione e orchestrazione con CloudSave<\/h2>\n
\n1. La piattaforma gestisce automaticamente la quiescenza VSS (Volume Shadow Copy Service) per SQL Server o l’API pg_start_backup()<\/code> per PostgreSQL.
\n2. Trasmette i dati di backup deduplicati e crittografati direttamente alla destinazione di storage.
\n3. CloudSave applica dinamicamente le chiamate API WORM (ad esempio, PutObjectRetention<\/code>) su base per-oggetto, allineando perfettamente la durata del blocco di storage con la pianificazione di conservazione definita dalla policy.
\n4. Se un attaccante compromette la console di gestione di CloudSave, non potr\u00e0 comunque eliminare i backup, poich\u00e9 il blocco di conformit\u00e0 \u00e8 applicato dall’infrastruttura di storage sottostante, non dal software di backup.<\/p>\nBest practice per archivi di database immutabili<\/h2>\n
1. Sincronizzazione NTP rigorosa<\/h3>\n
2. Isolare ruoli e credenziali IAM<\/h3>\n
s3:PutObject<\/code> e s3:PutObjectRetention<\/code>. Non dovrebbero mai<\/strong> avere autorizzazioni s3:DeleteObject<\/code> o s3:PutBucketObjectLockConfiguration<\/code>.<\/p>\n{\n "Version": "2012-10-17",\n "Statement": [\n {\n "Effect": "Allow",\n "Action": [\n "s3:PutObject",\n "s3:GetBucketObjectLockConfiguration"\n ],\n "Resource": [\n "arn:aws:s3:::prod-db-archive-immutable",\n "arn:aws:s3:::prod-db-archive-immutable\/*"\n ]\n }\n ]\n}\n<\/code><\/pre>\n3. Dimensionamento del periodo di conservazione<\/h3>\n
\nUtilizza invece un approccio a livelli:
\n* Livello di ripristino operativo:<\/strong> da 14 a 30 giorni di conservazione immutabile per backup completi e log.
\n* Livello di archiviazione a lungo termine:<\/strong> backup completi mensili spostati su Glacier\/Deep Archive con Vault Lock per 1-7 anni.<\/p>\n4. Test di ripristino regolari in VPC air-gapped<\/h3>\n
DBCC CHECKDB<\/code> (SQL Server) o pg_amcheck<\/code> (PostgreSQL) sui dati ripristinati per verificarne l’integrit\u00e0 strutturale.<\/p>\nConclusione<\/h2>\n