Dans le paysage actuel des menaces, les ransomwares ont \u00e9volu\u00e9, passant du chiffrement opportuniste \u00e0 des campagnes de multi-extorsion hautement cibl\u00e9es. Les menaces persistantes avanc\u00e9es (APT) et les syndicats de ransomwares recherchent d\u00e9sormais activement les infrastructures de sauvegarde et les archives de bases de donn\u00e9es pendant leur temps de pr\u00e9sence sur le r\u00e9seau. Si un attaquant compromet votre base de donn\u00e9es principale et supprime ou chiffre simultan\u00e9ment vos r\u00e9f\u00e9rentiels de sauvegarde, votre organisation fait face \u00e0 une perte de donn\u00e9es catastrophique.<\/p>\n
Pour les administrateurs de bases de donn\u00e9es (DBA) et les ing\u00e9nieurs DevOps, la strat\u00e9gie de sauvegarde traditionnelle 3-2-1 n’est plus suffisante. Pour garantir la survie des donn\u00e9es, les \u00e9quipes d’infrastructure doivent adopter la r\u00e8gle 3-2-1-1, o\u00f9 le dernier \u00ab 1 \u00bb repr\u00e9sente le stockage immuable<\/strong>.<\/p>\n Cet article propose une analyse technique approfondie de la conception, de la mise en \u0153uvre et de la gestion du stockage immuable pour les archives de bases de donn\u00e9es afin d’assurer une r\u00e9silience absolue face aux ransomwares.<\/p>\n Le stockage immuable repose sur une architecture WORM (Write-Once-Read-Many, ou \u00ab \u00e9crire une fois, lire plusieurs fois \u00bb). Une fois les donn\u00e9es \u00e9crites sur une cible immuable, elles ne peuvent \u00eatre ni modifi\u00e9es, ni chiffr\u00e9es, ni supprim\u00e9es par aucun utilisateur \u2014 y compris les administrateurs disposant de privil\u00e8ges root ou les comptes de service compromis \u2014 jusqu’\u00e0 l’expiration d’un verrouillage temporel math\u00e9matiquement appliqu\u00e9.<\/p>\n Lors de la mise en \u0153uvre de l’immuabilit\u00e9, en particulier dans le stockage objet cloud comme AWS S3, Azure Blob ou les SAN sur site compatibles S3, vous devez comprendre la distinction entre les modes de r\u00e9tention :<\/p>\n Une architecture d’archivage de base de donn\u00e9es robuste s\u00e9pare les op\u00e9rations de base de donn\u00e9es actives du niveau d’archivage immuable. Vous ne pouvez pas appliquer l’immuabilit\u00e9 aux fichiers de base de donn\u00e9es actifs (comme Au lieu de cela, l’immuabilit\u00e9 est appliqu\u00e9e aux : Vous pouvez impl\u00e9menter le stockage immuable sur diff\u00e9rents niveaux d’infrastructure : Pour prot\u00e9ger les dumps de bases de donn\u00e9es et les journaux de transactions dans AWS, vous devez activer Object Lock lors de la cr\u00e9ation du bucket.<\/p>\n Tout d’abord, cr\u00e9ez le bucket avec Object Lock activ\u00e9 :<\/p>\n Ensuite, configurez la politique de r\u00e9tention par d\u00e9faut. Pour les archives de bases de donn\u00e9es, un verrouillage de conformit\u00e9 de 30 jours est une base standard, garantissant que vous disposez d’un mois de sauvegardes inalt\u00e9rables.<\/p>\n Lorsque votre script ou agent de sauvegarde de base de donn\u00e9es envoie un fichier vers ce bucket, S3 calcule automatiquement la Si vous archivez des bases de donn\u00e9es sur un serveur de sauvegarde Linux sur site, vous pouvez obtenir une pseudo-immuabilit\u00e9 en utilisant la commande Utilisation de Note : Bien que Utilisation des instantan\u00e9s ZFS :<\/strong> Pour obtenir une r\u00e9cup\u00e9ration \u00e0 un instant T (PITR), vous devez archiver en continu les journaux de transactions vers votre stockage immuable.<\/p>\n Dans votre Consid\u00e9ration cruciale :<\/em> Si votre bucket S3 applique un verrouillage de conformit\u00e9 de 30 jours, mais que SQL Server prend en charge les sauvegardes natives directement vers un stockage objet compatible S3. Vous pouvez configurer un travail SQL Server Agent pour \u00e9crire les fichiers La gestion des indicateurs de r\u00e9tention immuable, la rotation des cl\u00e9s d’acc\u00e8s et la synchronisation entre les politiques de r\u00e9tention des bases de donn\u00e9es et les verrouillages de stockage via des scripts personnalis\u00e9s sont tr\u00e8s sujettes aux erreurs. Une seule mauvaise configuration dans une t\u00e2che cron ou un appel API peut laisser vos archives expos\u00e9es ou entra\u00eener une explosion des co\u00fbts de stockage cloud en raison d’objets verrouill\u00e9s orphelins.<\/p>\n Les plateformes de sauvegarde d’entreprise comme CloudSave simplifient cette architecture. CloudSave s’int\u00e8gre nativement avec AWS S3 Object Lock, Azure Blob Immutable Storage et les API compatibles S3 sur site.<\/p>\n Lors de la configuration d’un plan de sauvegarde de base de donn\u00e9es dans CloudSave : Pour garantir que votre architecture immuable est r\u00e9ellement r\u00e9siliente, respectez les meilleures pratiques d’ing\u00e9nierie syst\u00e8me suivantes :<\/p>\n Les verrouillages immuables sont math\u00e9matiquement li\u00e9s \u00e0 des horodatages. Si le service NTP (Network Time Protocol) sur votre baie de stockage ou votre serveur de sauvegarde est compromis ou d\u00e9rive, cela peut entra\u00eener l’expiration pr\u00e9matur\u00e9e des verrouillages ou emp\u00eacher leur expiration. Assurez-vous que votre infrastructure de stockage utilise des sources NTP authentifi\u00e9es et redondantes.<\/p>\n Les identifiants utilis\u00e9s pour \u00e9crire dans le bucket immuable ne doivent avoir que les autorisations Exemple de politique IAM \u00e0 privil\u00e8ges minimaux pour un agent de sauvegarde de base de donn\u00e9es :<\/p>\n Ne d\u00e9finissez pas de verrouillages de conformit\u00e9 pour des p\u00e9riodes excessivement longues (par exemple, 7 ans pour la conformit\u00e9) sur votre niveau de r\u00e9cup\u00e9ration rapide primaire. Les bases de donn\u00e9es g\u00e9n\u00e8rent des quantit\u00e9s massives de donn\u00e9es de journaux WAL\/transactions. Verrouiller ces donn\u00e9es pendant des ann\u00e9es entra\u00eenera une croissance exponentielle des co\u00fbts de stockage. L’immuabilit\u00e9 garantit que les donn\u00e9es ne peuvent pas \u00eatre supprim\u00e9es, mais elle ne garantit pas que les donn\u00e9es sont exemptes de corruption logique. Vous devez automatiser la restauration de vos archives de bases de donn\u00e9es immuables dans un VPC ou un VLAN isol\u00e9 et d\u00e9connect\u00e9 (air-gapped). Ex\u00e9cutez La d\u00e9fense contre les ransomwares consiste \u00e0 partir du principe que la br\u00e8che est in\u00e9vitable. Au moment o\u00f9 une alerte se d\u00e9clenche dans votre SIEM, les acteurs malveillants ont probablement d\u00e9j\u00e0 tent\u00e9 de compromettre votre infrastructure de sauvegarde. En concevant vos archives de bases de donn\u00e9es \u00e0 l’aide d’un stockage immuable en mode Conformit\u00e9, vous privez les attaquants de leur principal levier. Que vous utilisiez des API cloud natives, des retenues ZFS ou une plateforme d’orchestration d’entreprise comme CloudSave, la mise en \u0153uvre d’un stockage WORM n’est plus facultative : c’est un pilier obligatoire de l’administration moderne des bases de donn\u00e9es et de la reprise apr\u00e8s sinistre.<\/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":[431],"tags":[4600,4601,4602,1293,4603,4604],"class_list":["post-6367","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":"\nLe fonctionnement du stockage immuable<\/h2>\n
Mode Conformit\u00e9 vs Mode Gouvernance<\/h3>\n
\n
s3:BypassGovernanceRetention<\/code>) peuvent contourner le verrouillage. C’est utile pour les tests mais insuffisant pour la protection contre les ransomwares<\/strong>, car les attaquants \u00e9l\u00e8vent souvent leurs privil\u00e8ges jusqu’au niveau administrateur de domaine ou root.<\/li>\nConcevoir un pipeline de sauvegarde immuable<\/h2>\n
.mdf<\/code>\/.ldf<\/code> dans SQL Server ou le r\u00e9pertoire pg_data<\/code> dans PostgreSQL) car les bases de donn\u00e9es n\u00e9cessitent un acc\u00e8s constant en lecture\/\u00e9criture.<\/p>\n
\n1. Fichiers de sauvegarde complets et diff\u00e9rentiels :<\/strong> Les instantan\u00e9s de r\u00e9f\u00e9rence de la base de donn\u00e9es.
\n2. Journaux de transactions \/ Fichiers WAL :<\/strong> Le flux continu de modifications de la base de donn\u00e9es requis pour la r\u00e9cup\u00e9ration \u00e0 un instant T (PITR).<\/p>\nCibles de stockage pour l’immuabilit\u00e9<\/h3>\n
\n* Stockage objet cloud :<\/strong> AWS S3 Object Lock, Azure Blob Immutable Storage, politiques de r\u00e9tention Google Cloud Storage.
\n* Stockage objet sur site :<\/strong> MinIO, Cloudian ou Pure Storage FlashBlade prenant en charge les API S3 Object Lock.
\n* Stockage bloc\/fichier :<\/strong> ZFS avec instantan\u00e9s en lecture seule et administration d\u00e9l\u00e9gu\u00e9e, ou attributs de fichier Linux.<\/p>\nMise en \u0153uvre du stockage immuable : guides techniques<\/h2>\n
1. Stockage objet cloud : 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> (date de conservation) bas\u00e9e sur l’horodatage de cr\u00e9ation de l’objet plus 30 jours.<\/p>\n2. Immuabilit\u00e9 sur site : ZFS et attributs Linux<\/h3>\n
chattr<\/code>, ou une v\u00e9ritable immuabilit\u00e9 en utilisant les instantan\u00e9s ZFS.<\/p>\nchattr<\/code> sous Linux :<\/strong>
\nL’indicateur +i<\/code> (immuable) emp\u00eache la modification, la suppression ou le renommage de fichiers.<\/p>\n# Dump de la base de donn\u00e9es\npg_dump -U postgres -Fc mydb > \/backups\/mydb_$(date +%F).dump\n\n# Rendre la sauvegarde immuable\nsudo chattr +i \/backups\/mydb_$(date +%F).dump\n\n# V\u00e9rifier l'attribut\nlsattr \/backups\/mydb_$(date +%F).dump\n# Sortie : ----i---------e------- \/backups\/mydb_2023-10-27.dump\n<\/code><\/pre>\nchattr<\/code> arr\u00eate les scripts de ransomware basiques, un attaquant sophistiqu\u00e9 ayant un acc\u00e8s root peut simplement ex\u00e9cuter chattr -i<\/code>. Par cons\u00e9quent, cela doit \u00eatre combin\u00e9 avec un contr\u00f4le d’acc\u00e8s bas\u00e9 sur les r\u00f4les (RBAC) strict et des r\u00e9seaux de sauvegarde isol\u00e9s.<\/em><\/p>\n
\nZFS offre une d\u00e9fense beaucoup plus solide. En prenant un instantan\u00e9 et en y pla\u00e7ant une \u00ab retenue \u00bb (hold), vous emp\u00eachez la destruction de cet instantan\u00e9.<\/p>\n# Prendre un instantan\u00e9 du jeu de donn\u00e9es de sauvegarde\nzfs snapshot tank\/db_backups@archive_$(date +%F)\n\n# Placer une retenue sur l'instantan\u00e9 pour emp\u00eacher la suppression\nzfs hold keep_30_days tank\/db_backups@archive_$(date +%F)\n\n# M\u00eame root ne peut pas d\u00e9truire cet instantan\u00e9 sans lib\u00e9rer la retenue\nzfs destroy tank\/db_backups@archive_$(date +%F)\n# Sortie : cannot destroy 'tank\/db_backups@archive_...': dataset is busy\n<\/code><\/pre>\nStrat\u00e9gies d’archivage sp\u00e9cifiques aux bases de donn\u00e9es<\/h2>\n
Archivage WAL PostgreSQL avec pgBackRest<\/h3>\n
pgBackRest<\/code> est un outil de sauvegarde tr\u00e8s fiable pour PostgreSQL qui prend nativement en charge le stockage compatible S3. Pour prot\u00e9ger vos journaux Write-Ahead (WAL), configurez pgBackRest<\/code> pour envoyer les donn\u00e9es directement vers votre bucket S3 immuable.<\/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# Assurez-vous que la r\u00e9tention s'aligne avec votre configuration 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> tente d’expirer et de supprimer les fichiers WAL apr\u00e8s 14 jours en fonction de repo1-retention-archive<\/code>, les appels d’API de suppression \u00e9choueront. Vous devez vous assurer que la politique de r\u00e9tention de votre logiciel de sauvegarde est sup\u00e9rieure ou \u00e9gale au verrouillage immuable au niveau du stockage.<\/p>\nMicrosoft SQL Server : Sauvegarde vers URL<\/h3>\n
.bak<\/code> et .trn<\/code> directement dans un bucket immuable.<\/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>\nAutomatisation et orchestration avec CloudSave<\/h2>\n
\n1. La plateforme g\u00e8re automatiquement la mise en quiescence VSS (Volume Shadow Copy Service) pour SQL Server ou l’API pg_start_backup()<\/code> pour PostgreSQL.
\n2. Elle diffuse les donn\u00e9es de sauvegarde d\u00e9dupliqu\u00e9es et chiffr\u00e9es directement vers la cible de stockage.
\n3. CloudSave applique dynamiquement les appels d’API WORM (par exemple, PutObjectRetention<\/code>) objet par objet, alignant parfaitement la dur\u00e9e du verrouillage de stockage avec le calendrier de r\u00e9tention d\u00e9fini par la politique.
\n4. Si un attaquant compromet la console de gestion CloudSave, il ne peut toujours pas supprimer les sauvegardes, car le verrouillage de conformit\u00e9 est appliqu\u00e9 par l’infrastructure de stockage sous-jacente, et non par le logiciel de sauvegarde.<\/p>\nMeilleures pratiques pour les archives de bases de donn\u00e9es immuables<\/h2>\n
1. Synchronisation NTP stricte<\/h3>\n
2. Isoler les r\u00f4les et identifiants IAM<\/h3>\n
s3:PutObject<\/code> et s3:PutObjectRetention<\/code>. Ils ne doivent jamais<\/strong> avoir les autorisations s3:DeleteObject<\/code> ou 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. Dimensionnement de la p\u00e9riode de r\u00e9tention<\/h3>\n
\nUtilisez plut\u00f4t une approche par niveaux :
\n* Niveau de r\u00e9cup\u00e9ration op\u00e9rationnelle :<\/strong> 14 \u00e0 30 jours de r\u00e9tention immuable pour les sauvegardes compl\u00e8tes et les journaux.
\n* Niveau d’archivage \u00e0 long terme :<\/strong> Sauvegardes compl\u00e8tes mensuelles d\u00e9plac\u00e9es vers Glacier\/Deep Archive avec Vault Lock pour 1 \u00e0 7 ans.<\/p>\n4. Tests de r\u00e9cup\u00e9ration r\u00e9guliers dans des VPC isol\u00e9s (Air-Gapped)<\/h3>\n
DBCC CHECKDB<\/code> (SQL Server) ou pg_amcheck<\/code> (PostgreSQL) sur les donn\u00e9es restaur\u00e9es pour v\u00e9rifier l’int\u00e9grit\u00e9 structurelle.<\/p>\nConclusion<\/h2>\n