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.

In het moderne dreigingslandschap is ransomware geëvolueerd 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.

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).

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.

De werking van onveranderlijke opslag

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—inclusief beheerders met root-rechten of gecompromitteerde service-accounts—totdat een wiskundig afgedwongen tijdslot verloopt.

Compliance-modus versus Governance-modus

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:

  • Governance-modus: Voorkomt dat standaardgebruikers objecten verwijderen of wijzigen. Gebruikers met specifieke IAM-rechten (bijv. s3:BypassGovernanceRetention) kunnen de vergrendeling echter omzeilen. Dit is nuttig voor tests, maar onvoldoende voor ransomware-bescherming, aangezien aanvallers vaak hun rechten escaleren naar domeinbeheerder of root.
  • Compliance-modus: De gouden standaard voor ransomware-verdediging. Zodra een object is vergrendeld in de Compliance-modus, kan de retentieperiode niet worden verkort en kan het object door niemand worden verwijderd, inclusief het AWS-rootaccount. De vergrendeling wordt afgedwongen op het niveau van het opslagcluster.

Het ontwerpen van een onveranderlijke back-uppijplijn

Een robuuste database-archiveringsarchitectuur scheidt actieve databaseactiviteiten van de onveranderlijke archieflaag. U kunt onveranderlijkheid niet toepassen op actieve databasebestanden (zoals .mdf/.ldf in SQL Server of de pg_data-directory in PostgreSQL) omdat databases constant lees-/schrijftoegang vereisen.

In plaats daarvan wordt onveranderlijkheid toegepast op:
1. Volledige en differentiële back-upbestanden: De basis-snapshots van de database.
2. Transactielogboeken / WAL-bestanden: De continue stroom van database-wijzigingen die nodig is voor Point-in-Time Recovery (PITR).

Opslagdoelen voor onveranderlijkheid

U kunt onveranderlijke opslag implementeren over verschillende infrastructuurlagen:
* Cloud Object Storage: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* On-premises Object Storage: MinIO, Cloudian of Pure Storage FlashBlade met ondersteuning voor S3 Object Lock API’s.
* Block/File Storage: ZFS met alleen-lezen snapshots en gedelegeerd beheer, of Linux-bestandskenmerken.

Onveranderlijke opslag implementeren: Technische handleidingen

1. Cloud Object Storage: AWS S3 Object Lock

Om database-dumps en transactielogboeken in AWS te beschermen, moet u Object Lock inschakelen op het moment dat de bucket wordt aangemaakt.

Maak eerst de bucket aan met Object Lock ingeschakeld:

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

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.

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

Wanneer uw database-back-upscript of -agent een bestand naar deze bucket pusht, berekent S3 automatisch de Retain Until Date op basis van de tijdstempel van het aanmaken van het object plus 30 dagen.

2. On-premises onveranderlijkheid: ZFS en Linux-kenmerken

Als u databases archiveert naar een on-premises Linux-back-upserver, kunt u pseudo-onveranderlijkheid bereiken met het chattr-commando, of echte onveranderlijkheid met ZFS-snapshots.

Gebruik van Linux chattr:
De +i (immutable) vlag voorkomt het wijzigen, verwijderen of hernoemen van bestanden.

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

# Maak de back-up onveranderlijk
sudo chattr +i /backups/mydb_$(date +%F).dump

# Controleer het kenmerk
lsattr /backups/mydb_$(date +%F).dump
# Output: ----i---------e------- /backups/mydb_2023-10-27.dump

Opmerking: Hoewel chattr eenvoudige ransomware-scripts stopt, kan een geavanceerde aanvaller met root-toegang simpelweg chattr -i uitvoeren. Daarom moet dit worden gecombineerd met strikte RBAC en geïsoleerde back-upnetwerken.

Gebruik van ZFS-snapshots:
ZFS biedt een veel sterkere verdediging. Door een snapshot te maken en er een “hold” op te plaatsen, voorkomt u dat de snapshot wordt vernietigd.

# Maak een snapshot van de back-up dataset
zfs snapshot tank/db_backups@archive_$(date +%F)

# Plaats een hold op de snapshot om verwijdering te voorkomen
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Zelfs root kan deze snapshot niet vernietigen zonder de hold op te heffen
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Database-specifieke archiveringsstrategieën

Om Point-in-Time Recovery (PITR) te bereiken, moet u continu transactielogboeken archiveren naar uw onveranderlijke opslag.

PostgreSQL WAL-archivering met pgBackRest

pgBackRest 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 om direct naar uw onveranderlijke S3-bucket te pushen.

In uw 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

# Zorg ervoor dat de retentie overeenkomt met uw S3 Object Lock-configuratie
repo1-retention-full=2
repo1-retention-archive=2

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

Cruciale overweging: Als uw S3-bucket een compliance-vergrendeling van 30 dagen afdwingt, maar pgBackRest probeert WAL-bestanden na 14 dagen te laten verlopen en te verwijderen op basis van repo1-retention-archive, 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.

Microsoft SQL Server: Back-up naar URL

SQL Server ondersteunt native back-ups direct naar S3-compatibele objectopslag. U kunt een SQL Server Agent-taak configureren om .bak– en .trn-bestanden direct naar een onveranderlijke bucket te schrijven.

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

Automatiseren en orkestreren met CloudSave

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.

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.

Bij het configureren van een database-back-upplan in CloudSave:
1. Het platform regelt automatisch de VSS (Volume Shadow Copy Service) quiescence voor SQL Server of de pg_start_backup() API voor PostgreSQL.
2. Het streamt de gede-dupliceerde, versleutelde back-upgegevens direct naar het opslagdoel.
3. CloudSave past dynamisch de WORM API-aanroepen (bijv. PutObjectRetention) toe op objectbasis, waarbij de duur van de opslagvergrendeling perfect wordt afgestemd op het retentieschema van het beleid.
4. 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.

Best practices voor onveranderlijke database-archieven

Om ervoor te zorgen dat uw onveranderlijke architectuur echt veerkrachtig is, moet u zich houden aan de volgende best practices voor systeemengineering:

1. Strikte NTP-synchronisatie

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.

2. Isoleer IAM-rollen en inloggegevens

De inloggegevens die worden gebruikt om naar de onveranderlijke bucket te schrijven, mogen alleen s3:PutObject en s3:PutObjectRetention rechten hebben. Ze mogen nooit s3:DeleteObject of s3:PutBucketObjectLockConfiguration rechten hebben.

Voorbeeld van een IAM-beleid met minimale rechten voor een database-back-upagent:

{
    "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. De retentieperiode bepalen

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ële groei van de opslagkosten.
Gebruik in plaats daarvan een gelaagde aanpak:
* Operationele herstellaag: 14 tot 30 dagen onveranderlijke retentie voor Fulls en Logs.
* Lange-termijn archief-laag: Maandelijkse volledige back-ups verplaatst naar Glacier/Deep Archive met Vault Lock voor 1-7 jaar.

4. Regelmatige hersteltests in air-gapped VPC’s

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ïsoleerde, air-gapped VPC of VLAN. Voer DBCC CHECKDB (SQL Server) of pg_amcheck (PostgreSQL) uit op de herstelde gegevens om de structurele integriteit te verifiëren.

Conclusie

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—het is een verplichte pijler van modern databasebeheer en disaster recovery.

Categorieën