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.

I det moderne trusselsbillede har ransomware udviklet sig fra opportunistisk kryptering til højt målrettede kampagner med afpresning i flere led. Advanced Persistent Threats (APT’er) og ransomware-syndikater leder nu aktivt efter backup-infrastruktur og databasearkiver, mens de befinder sig i netværket. Hvis en angriber kompromitterer din primære database og samtidig sletter eller krypterer dine backup-lagre, står din organisation over for et katastrofalt datatab.

For databaseadministratorer (DBA’er) og DevOps-ingeniører er den traditionelle 3-2-1 backup-strategi ikke længere tilstrækkelig. For at garantere dataoverlevelse skal infrastrukturelle teams adoptere 3-2-1-1-reglen, hvor det sidste “1-tal” repræsenterer uforanderlig lagring (immutable storage).

Denne artikel giver et omfattende, teknisk dyk ned i arkitektur, implementering og styring af uforanderlig lagring til databasearkiver for at sikre absolut modstandsdygtighed over for ransomware.

Mekanikken bag uforanderlig lagring

Uforanderlig lagring er baseret på en WORM-arkitektur (Write-Once-Read-Many). Når data er skrevet til et uforanderligt mål, kan de ikke ændres, krypteres eller slettes af nogen bruger – herunder administratorer med root-rettigheder eller kompromitterede tjenestekonti – før en matematisk håndhævet tidslås udløber.

Compliance Mode vs. Governance Mode

Når du implementerer uforanderlighed, især i cloud-objektlagring som AWS S3, Azure Blob eller S3-kompatible on-premises SAN’er, skal du forstå forskellen på opbevaringstilstande:

  • Governance Mode: Forhindrer standardbrugere i at slette eller ændre objekter. Brugere med specifikke IAM-tilladelser (f.eks. s3:BypassGovernanceRetention) kan dog tilsidesætte låsen. Dette er nyttigt til test, men utilstrækkeligt til ransomware-beskyttelse, da angribere ofte eskalerer rettigheder til domæneadministrator eller root.
  • Compliance Mode: Guldstandarden for ransomware-forsvar. Når et objekt er låst i Compliance Mode, kan dets opbevaringsperiode ikke forkortes, og objektet kan ikke slettes af nogen, heller ikke af AWS-root-kontoen. Låsen håndhæves på lagringsklyngeniveau.

Arkitektur af en uforanderlig backup-pipeline

En robust databasearkiveringsarkitektur adskiller aktive databaseoperationer fra det uforanderlige arkivlag. Du kan ikke anvende uforanderlighed på aktive databasefiler (som .mdf/.ldf i SQL Server eller pg_data-mappen i PostgreSQL), fordi databaser kræver konstant læse/skrive-adgang.

I stedet anvendes uforanderlighed på:
1. Fuldstændige og differentielle backup-filer: Basis-snapshots af databasen.
2. Transaktionslogs / WAL-filer: Den kontinuerlige strøm af databaseændringer, der kræves til Point-in-Time Recovery (PITR).

Lagringsmål for uforanderlighed

Du kan implementere uforanderlig lagring på tværs af forskellige infrastrukturlag:
* Cloud Object Storage: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* On-Premises Object Storage: MinIO, Cloudian eller Pure Storage FlashBlade, der understøtter S3 Object Lock API’er.
* Block/File Storage: ZFS med skrivebeskyttede snapshots og delegeret administration, eller Linux-filattributter.

Implementering af uforanderlig lagring: Tekniske gennemgange

1. Cloud Object Storage: AWS S3 Object Lock

For at beskytte databasedumps og transaktionslogs i AWS skal du aktivere Object Lock, når bucket’en oprettes.

Først oprettes bucket’en med Object Lock aktiveret:

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

Konfigurer derefter standardopbevaringspolitikken. For databasearkiver er en 30-dages compliance-lås en standard-baseline, der sikrer, at du har en måneds uforanderlige backups.

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

Når dit database-backup-script eller din agent sender en fil til denne bucket, beregner S3 automatisk Retain Until Date baseret på objektets oprettelsestidsstempel plus 30 dage.

2. On-Premises uforanderlighed: ZFS og Linux-attributter

Hvis du arkiverer databaser til en on-premises Linux-backupserver, kan du opnå pseudo-uforanderlighed ved hjælp af chattr-kommandoen eller sand uforanderlighed ved hjælp af ZFS-snapshots.

Brug af Linux chattr:
+i (immutable) flaget forhindrer filændring, sletning eller omdøbning.

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

# Gør backuppen uforanderlig
sudo chattr +i /backups/mydb_$(date +%F).dump

# Bekræft attributten
lsattr /backups/mydb_$(date +%F).dump
# Output: ----i---------e------- /backups/mydb_2023-10-27.dump

Bemærk: Selvom chattr stopper grundlæggende ransomware-scripts, kan en sofistikeret angriber med root-adgang blot køre chattr -i. Derfor skal dette kombineres med streng RBAC og isolerede backup-netværk.

Brug af ZFS-snapshots:
ZFS giver et meget stærkere forsvar. Ved at tage et snapshot og placere et “hold” på det, forhindrer du, at snapshot’et bliver slettet.

# Tag et snapshot af backup-datasættet
zfs snapshot tank/db_backups@archive_$(date +%F)

# Placer et hold på snapshot'et for at forhindre sletning
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Selv root kan ikke slette dette snapshot uden at frigive hold'et
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Database-specifikke arkiveringsstrategier

For at opnå Point-in-Time Recovery (PITR) skal du løbende arkivere transaktionslogs til din uforanderlige lagring.

PostgreSQL WAL-arkivering med pgBackRest

pgBackRest er et meget pålideligt backup-værktøj til PostgreSQL, der understøtter S3-kompatibel lagring. For at beskytte dine Write-Ahead Logs (WAL), skal du konfigurere pgBackRest til at sende direkte til din uforanderlige S3-bucket.

I din 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

# Sørg for, at opbevaring stemmer overens med din S3 Object Lock-konfiguration
repo1-retention-full=2
repo1-retention-archive=2

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

Vigtig overvejelse: Hvis din S3-bucket håndhæver en 30-dages Compliance-lås, men pgBackRest forsøger at udløbe og slette WAL-filer efter 14 dage baseret på repo1-retention-archive, vil sletnings-API-kaldene fejle. Du skal sikre dig, at din backup-softwares opbevaringspolitik er lig med eller længere end den uforanderlige lås på lagringsniveau.

Microsoft SQL Server: Backup til URL

SQL Server understøtter native backups direkte til S3-kompatibel objektlagring. Du kan konfigurere et SQL Server Agent-job til at skrive .bak– og .trn-filer direkte til en uforanderlig bucket.

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

Automatisering og orkestrering med CloudSave

Håndtering af uforanderlige opbevaringsflag, rotation af adgangsnøgler og sikring af synkronisering mellem database-opbevaringspolitikker og lagringslåse via brugerdefinerede scripts er meget fejlbehæftet. En enkelt fejlkonfiguration i et cron-job eller API-kald kan efterlade dine arkiver eksponerede eller resultere i eksploderende cloud-lagringsomkostninger på grund af forældreløse, låste objekter.

Enterprise backup-platforme som CloudSave forenkler denne arkitektur. CloudSave integreres native med AWS S3 Object Lock, Azure Blob Immutable Storage og on-premises S3-kompatible API’er.

Når du konfigurerer en database-backupplan i CloudSave:
1. Platformen håndterer automatisk VSS (Volume Shadow Copy Service) quiescence for SQL Server eller pg_start_backup() API’et for PostgreSQL.
2. Den streamer de deduplikerede, krypterede backup-data direkte til lagringsmålet.
3. CloudSave anvender dynamisk WORM API-kald (f.eks. PutObjectRetention) på objektbasis, hvilket perfekt tilpasser lagringslåsens varighed til den politikdefinerede opbevaringsplan.
4. Hvis en angriber kompromitterer CloudSave-administrationskonsollen, kan de stadig ikke slette backuppen, da compliance-låsen håndhæves af den underliggende lagringsinfrastruktur, ikke af backup-softwaren.

Best practices for uforanderlige databasearkiver

For at sikre, at din uforanderlige arkitektur er virkelig modstandsdygtig, bør du følge disse best practices for systemteknik:

1. Streng NTP-synkronisering

Uforanderlige låse er matematisk bundet til tidsstempler. Hvis NTP-tjenesten (Network Time Protocol) på din lagrings-array eller backupserver er kompromitteret eller driver, kan det medføre, at låse udløber for tidligt eller aldrig udløber. Sørg for, at din lagringsinfrastruktur bruger autentificerede, redundante NTP-kilder.

2. Isoler IAM-roller og legitimationsoplysninger

De legitimationsoplysninger, der bruges til at skrive til den uforanderlige bucket, må kun have s3:PutObject og s3:PutObjectRetention-tilladelser. De bør aldrig have s3:DeleteObject eller s3:PutBucketObjectLockConfiguration-tilladelser.

Eksempel på en IAM-politik med mindste privilegier til en database-backupagent:

{
    "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. Dimensionering af opbevaringsperioden

Sæt ikke compliance-låse i ekstremt lange perioder (f.eks. 7 år for compliance) på dit primære lag til hurtig genopretning. Databaser genererer enorme mængder WAL/transaktionslog-data. At låse disse data i årevis vil resultere i eksponentiel vækst i lagringsomkostninger.
Brug i stedet en lagdelt tilgang:
* Operationelt genopretningslag: 14 til 30 dages uforanderlig opbevaring for fulde backups og logs.
* Langtidsarkiveringslag: Månedlige fulde backups flyttet til Glacier/Deep Archive med Vault Lock i 1-7 år.

4. Regelmæssig genopretningstest i air-gapped VPC’er

Uforanderlighed garanterer, at data ikke kan slettes, men det garanterer ikke, at data er fri for logisk korruption. Du skal automatisere gendannelsen af dine uforanderlige databasearkiver til en isoleret, air-gapped VPC eller VLAN. Kør DBCC CHECKDB (SQL Server) eller pg_amcheck (PostgreSQL) på de gendannede data for at verificere den strukturelle integritet.

Konklusion

Ransomware-forsvar er en øvelse i at antage, at et brud vil ske. Når en alarm lyder i din SIEM, har trusselsaktører sandsynligvis allerede forsøgt at kompromittere din backup-infrastruktur. Ved at arkitektere dine databasearkiver ved hjælp af uforanderlig lagring i Compliance Mode, fratager du angribere deres primære løftestang. Uanset om du benytter native cloud-API’er, ZFS-holds eller en enterprise-orkestreringsplatform som CloudSave, er implementering af WORM-lagring ikke længere valgfrit – det er en obligatorisk søjle i moderne databaseadministration og disaster recovery.

Kategorier