In het moderne dreigingslandschap is ransomware ge\u00ebvolueerd van opportunistische versleuteling naar zeer gerichte campagnes met meervoudige afpersing. Advanced Persistent Threats (APT’s) en ransomware-syndicaten zoeken nu actief naar back-upinfrastructuur en database-archieven tijdens hun verblijfsduur in het netwerk. Als een aanvaller uw primaire database compromitteert en tegelijkertijd uw back-upopslagplaatsen verwijdert of versleutelt, wordt uw organisatie geconfronteerd met catastrofaal gegevensverlies.<\/p>\n
Voor databasebeheerders (DBA’s) en DevOps-engineers is de traditionele 3-2-1 back-upstrategie niet langer voldoende. Om de overlevingskans van gegevens te garanderen, moeten infrastructuurteams de 3-2-1-1-regel hanteren, waarbij de laatste “1” staat voor onveranderlijke opslag (immutable storage)<\/strong>.<\/p>\n Dit artikel biedt een uitgebreide, technische diepgaande blik op het ontwerpen, implementeren en beheren van onveranderlijke opslag voor database-archieven om absolute ransomware-resistentie te garanderen.<\/p>\n Onveranderlijke opslag is gebaseerd op een Write-Once-Read-Many (WORM)-architectuur. Zodra gegevens naar een onveranderlijk doel zijn geschreven, kunnen ze door geen enkele gebruiker worden gewijzigd, versleuteld of verwijderd\u2014inclusief beheerders met root-rechten of gecompromitteerde service-accounts\u2014totdat een wiskundig afgedwongen tijdslot verloopt.<\/p>\n Bij het implementeren van onveranderlijkheid, met name in cloud-objectopslag zoals AWS S3, Azure Blob of S3-compatibele on-premises SAN’s, moet u het onderscheid begrijpen tussen retentiemodi:<\/p>\n Een robuuste database-archiveringsarchitectuur scheidt actieve databaseactiviteiten van de onveranderlijke archieflaag. U kunt onveranderlijkheid niet toepassen op actieve databasebestanden (zoals In plaats daarvan wordt onveranderlijkheid toegepast op: U kunt onveranderlijke opslag implementeren over verschillende infrastructuurlagen: Om database-dumps en transactielogboeken in AWS te beschermen, moet u Object Lock inschakelen op het moment dat de bucket wordt aangemaakt.<\/p>\n Maak eerst de bucket aan met Object Lock ingeschakeld:<\/p>\n Configureer vervolgens het standaard retentiebeleid. Voor database-archieven is een compliance-vergrendeling van 30 dagen een standaard basislijn, zodat u een maand aan onveranderlijke back-ups hebt.<\/p>\n Wanneer uw database-back-upscript of -agent een bestand naar deze bucket pusht, berekent S3 automatisch de Als u databases archiveert naar een on-premises Linux-back-upserver, kunt u pseudo-onveranderlijkheid bereiken met het Gebruik van Linux Opmerking: Hoewel Gebruik van ZFS-snapshots:<\/strong> Om Point-in-Time Recovery (PITR) te bereiken, moet u continu transactielogboeken archiveren naar uw onveranderlijke opslag.<\/p>\n In uw Cruciale overweging:<\/em> Als uw S3-bucket een compliance-vergrendeling van 30 dagen afdwingt, maar SQL Server ondersteunt native back-ups direct naar S3-compatibele objectopslag. U kunt een SQL Server Agent-taak configureren om Het beheren van onveranderlijke retentievlaggen, het roteren van toegangssleutels en het waarborgen van synchronisatie tussen database-retentiebeleid en opslagvergrendelingen via aangepaste scripts is zeer foutgevoelig. Een enkele verkeerde configuratie in een cron-job of API-aanroep kan uw archieven blootstellen of leiden tot torenhoge cloudopslagkosten door verweesde, vergrendelde objecten.<\/p>\n Enterprise back-upplatforms zoals CloudSave vereenvoudigen deze architectuur. CloudSave integreert native met AWS S3 Object Lock, Azure Blob Immutable Storage en on-premises S3-compatibele API’s.<\/p>\n Bij het configureren van een database-back-upplan in CloudSave: Om ervoor te zorgen dat uw onveranderlijke architectuur echt veerkrachtig is, moet u zich houden aan de volgende best practices voor systeemengineering:<\/p>\n Onveranderlijke vergrendelingen zijn wiskundig gebonden aan tijdstempels. Als de NTP-service (Network Time Protocol) op uw opslagarray of back-upserver wordt gecompromitteerd of afwijkt, kan dit ertoe leiden dat vergrendelingen voortijdig verlopen of helemaal nooit verlopen. Zorg ervoor dat uw opslaginfrastructuur gebruikmaakt van geauthenticeerde, redundante NTP-bronnen.<\/p>\n De inloggegevens die worden gebruikt om naar de onveranderlijke bucket te schrijven, mogen alleen Voorbeeld van een IAM-beleid met minimale rechten voor een database-back-upagent:<\/p>\n Stel geen compliance-vergrendelingen in voor extreem lange perioden (bijv. 7 jaar voor compliance) op uw primaire laag voor snel herstel. Databases genereren enorme hoeveelheden WAL\/transactielogboekgegevens. Het jarenlang vergrendelen van deze gegevens zal leiden tot een exponenti\u00eble groei van de opslagkosten. Onveranderlijkheid garandeert dat de gegevens niet kunnen worden verwijderd, maar het garandeert niet dat de gegevens vrij zijn van logische corruptie. U moet het herstel van uw onveranderlijke database-archieven automatiseren in een ge\u00efsoleerde, air-gapped VPC of VLAN. Voer Ransomware-verdediging is een oefening in het aannemen van een inbreuk. Tegen de tijd dat er een waarschuwing afgaat in uw SIEM, hebben dreigingsactoren waarschijnlijk al geprobeerd uw back-upinfrastructuur te compromitteren. Door uw database-archieven te ontwerpen met onveranderlijke opslag in Compliance-modus, ontneemt u aanvallers hun belangrijkste hefboom. Of u nu gebruikmaakt van native cloud-API’s, ZFS-holds of een enterprise-orkestratieplatform zoals CloudSave, het implementeren van WORM-opslag is niet langer optioneel\u2014het is een verplichte pijler van modern databasebeheer en 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":[399],"tags":[4580,4581,4582,1285,4583,4584],"class_list":["post-6362","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":"\nDe werking van onveranderlijke opslag<\/h2>\n
Compliance-modus versus Governance-modus<\/h3>\n
\n
s3:BypassGovernanceRetention<\/code>) kunnen de vergrendeling echter omzeilen. Dit is nuttig voor tests, maar onvoldoende voor ransomware-bescherming<\/strong>, aangezien aanvallers vaak hun rechten escaleren naar domeinbeheerder of root.<\/li>\nHet ontwerpen van een onveranderlijke back-uppijplijn<\/h2>\n
.mdf<\/code>\/.ldf<\/code> in SQL Server of de pg_data<\/code>-directory in PostgreSQL) omdat databases constant lees-\/schrijftoegang vereisen.<\/p>\n
\n1. Volledige en differenti\u00eble back-upbestanden:<\/strong> De basis-snapshots van de database.
\n2. Transactielogboeken \/ WAL-bestanden:<\/strong> De continue stroom van database-wijzigingen die nodig is voor Point-in-Time Recovery (PITR).<\/p>\nOpslagdoelen voor onveranderlijkheid<\/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 of Pure Storage FlashBlade met ondersteuning voor S3 Object Lock API’s.
\n* Block\/File Storage:<\/strong> ZFS met alleen-lezen snapshots en gedelegeerd beheer, of Linux-bestandskenmerken.<\/p>\nOnveranderlijke opslag implementeren: Technische handleidingen<\/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> op basis van de tijdstempel van het aanmaken van het object plus 30 dagen.<\/p>\n2. On-premises onveranderlijkheid: ZFS en Linux-kenmerken<\/h3>\n
chattr<\/code>-commando, of echte onveranderlijkheid met ZFS-snapshots.<\/p>\nchattr<\/code>:<\/strong>
\nDe +i<\/code> (immutable) vlag voorkomt het wijzigen, verwijderen of hernoemen van bestanden.<\/p>\n# Dump de database\npg_dump -U postgres -Fc mydb > \/backups\/mydb_$(date +%F).dump\n\n# Maak de back-up onveranderlijk\nsudo chattr +i \/backups\/mydb_$(date +%F).dump\n\n# Controleer het kenmerk\nlsattr \/backups\/mydb_$(date +%F).dump\n# Output: ----i---------e------- \/backups\/mydb_2023-10-27.dump\n<\/code><\/pre>\nchattr<\/code> eenvoudige ransomware-scripts stopt, kan een geavanceerde aanvaller met root-toegang simpelweg chattr -i<\/code> uitvoeren. Daarom moet dit worden gecombineerd met strikte RBAC en ge\u00efsoleerde back-upnetwerken.<\/em><\/p>\n
\nZFS biedt een veel sterkere verdediging. Door een snapshot te maken en er een “hold” op te plaatsen, voorkomt u dat de snapshot wordt vernietigd.<\/p>\n# Maak een snapshot van de back-up dataset\nzfs snapshot tank\/db_backups@archive_$(date +%F)\n\n# Plaats een hold op de snapshot om verwijdering te voorkomen\nzfs hold keep_30_days tank\/db_backups@archive_$(date +%F)\n\n# Zelfs root kan deze snapshot niet vernietigen zonder de hold op te heffen\nzfs destroy tank\/db_backups@archive_$(date +%F)\n# Output: cannot destroy 'tank\/db_backups@archive_...': dataset is busy\n<\/code><\/pre>\nDatabase-specifieke archiveringsstrategie\u00ebn<\/h2>\n
PostgreSQL WAL-archivering met pgBackRest<\/h3>\n
pgBackRest<\/code> is een zeer betrouwbare back-uptool voor PostgreSQL die standaard S3-compatibele opslag ondersteunt. Om uw Write-Ahead Logs (WAL) te beschermen, configureert u pgBackRest<\/code> om direct naar uw onveranderlijke S3-bucket te pushen.<\/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# Zorg ervoor dat de retentie overeenkomt met uw S3 Object Lock-configuratie\nrepo1-retention-full=2\nrepo1-retention-archive=2\n\n[prod_cluster]\npg1-path=\/var\/lib\/postgresql\/14\/main\n<\/code><\/pre>\npgBackRest<\/code> probeert WAL-bestanden na 14 dagen te laten verlopen en te verwijderen op basis van repo1-retention-archive<\/code>, zullen de API-aanroepen voor verwijdering mislukken. U moet ervoor zorgen dat het retentiebeleid van uw back-upsoftware groter is dan of gelijk is aan de onveranderlijke vergrendeling op opslagniveau.<\/p>\nMicrosoft SQL Server: Back-up naar URL<\/h3>\n
.bak<\/code>– en .trn<\/code>-bestanden direct naar een onveranderlijke bucket te schrijven.<\/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>\nAutomatiseren en orkestreren met CloudSave<\/h2>\n
\n1. Het platform regelt automatisch de VSS (Volume Shadow Copy Service) quiescence voor SQL Server of de pg_start_backup()<\/code> API voor PostgreSQL.
\n2. Het streamt de gede-dupliceerde, versleutelde back-upgegevens direct naar het opslagdoel.
\n3. CloudSave past dynamisch de WORM API-aanroepen (bijv. PutObjectRetention<\/code>) toe op objectbasis, waarbij de duur van de opslagvergrendeling perfect wordt afgestemd op het retentieschema van het beleid.
\n4. Als een aanvaller de CloudSave-beheerconsole compromitteert, kunnen ze nog steeds de back-ups niet verwijderen, aangezien de compliance-vergrendeling wordt afgedwongen door de onderliggende opslaginfrastructuur, niet door de back-upsoftware.<\/p>\nBest practices voor onveranderlijke database-archieven<\/h2>\n
1. Strikte NTP-synchronisatie<\/h3>\n
2. Isoleer IAM-rollen en inloggegevens<\/h3>\n
s3:PutObject<\/code> en s3:PutObjectRetention<\/code> rechten hebben. Ze mogen nooit<\/strong> s3:DeleteObject<\/code> of s3:PutBucketObjectLockConfiguration<\/code> rechten hebben.<\/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. De retentieperiode bepalen<\/h3>\n
\nGebruik in plaats daarvan een gelaagde aanpak:
\n* Operationele herstellaag:<\/strong> 14 tot 30 dagen onveranderlijke retentie voor Fulls en Logs.
\n* Lange-termijn archief-laag:<\/strong> Maandelijkse volledige back-ups verplaatst naar Glacier\/Deep Archive met Vault Lock voor 1-7 jaar.<\/p>\n4. Regelmatige hersteltests in air-gapped VPC’s<\/h3>\n
DBCC CHECKDB<\/code> (SQL Server) of pg_amcheck<\/code> (PostgreSQL) uit op de herstelde gegevens om de structurele integriteit te verifi\u00ebren.<\/p>\nConclusie<\/h2>\n