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 trusselbildet har løsepengevirus (ransomware) utviklet seg fra opportunistisk kryptering til svært målrettede kampanjer med flere former for utpressing. Avanserte vedvarende trusler (APT-er) og løsepengevirus-syndikater leter nå aktivt etter sikkerhetskopieringsinfrastruktur og databasearkiver mens de befinner seg i nettverket. Hvis en angriper kompromitterer hoveddatabasen din og samtidig sletter eller krypterer sikkerhetskopiene dine, står organisasjonen din overfor et katastrofalt datatap.

For databaseadministratorer (DBA-er) og DevOps-ingeniører er den tradisjonelle 3-2-1-strategien for sikkerhetskopiering ikke lenger tilstrekkelig. For å garantere at data overlever, må infrastruktureteam ta i bruk 3-2-1-1-regelen, der det siste «1-tallet» representerer uforanderlig lagring (immutable storage).

Denne artikkelen gir en omfattende, teknisk gjennomgang av hvordan man arkitekterer, implementerer og administrerer uforanderlig lagring for databasearkiver for å sikre absolutt motstandskraft mot løsepengevirus.

Mekanismene bak uforanderlig lagring

Uforanderlig lagring baserer seg på en WORM-arkitektur (Write-Once-Read-Many). Når data er skrevet til et uforanderlig mål, kan de ikke endres, krypteres eller slettes av noen brukere – inkludert administratorer med root-tilgang eller kompromitterte tjenestekontoer – før en matematisk håndhevet tidslås utløper.

Samsvarsmodus (Compliance Mode) vs. Styringsmodus (Governance Mode)

Når du implementerer uforanderlighet, spesielt i nettskybasert objektlagring som AWS S3, Azure Blob eller S3-kompatible lokale SAN-løsninger, må du forstå forskjellen mellom oppbevaringsmoduser:

  • Styringsmodus (Governance Mode): Hindrer standardbrukere i å slette eller endre objekter. Brukere med spesifikke IAM-tillatelser (f.eks. s3:BypassGovernanceRetention) kan imidlertid overstyre låsen. Dette er nyttig for testing, men utilstrekkelig for beskyttelse mot løsepengevirus, ettersom angripere ofte eskalerer rettigheter til domeneadministrator eller root.
  • Samsvarsmodus (Compliance Mode): Gullstandarden for forsvar mot løsepengevirus. Når et objekt er låst i samsvarsmodus, kan ikke oppbevaringsperioden forkortes, og objektet kan ikke slettes av noen, inkludert AWS-root-kontoen. Låsen håndheves på lagringsklyngenivå.

Arkitektur for en uforanderlig sikkerhetskopieringspipeline

En robust arkitektur for databasearkivering skiller aktive databaseoperasjoner fra det uforanderlige arkivlaget. Du kan ikke bruke uforanderlighet på aktive databasefiler (som .mdf/.ldf i SQL Server eller pg_data-katalogen i PostgreSQL) fordi databaser krever konstant lese-/skrivetilgang.

I stedet brukes uforanderlighet på:
1. Fullstendige og differensielle sikkerhetskopifiler: Basis-øyeblikksbilder (snapshots) av databasen.
2. Transaksjonslogger / WAL-filer: Den kontinuerlige strømmen av databaseendringer som kreves for gjenoppretting til et bestemt tidspunkt (Point-in-Time Recovery – PITR).

Lagringsmål for uforanderlighet

Du kan implementere uforanderlig lagring på tvers av ulike infrastrukturlag:
* Nettskybasert objektlagring: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Lokal objektlagring: MinIO, Cloudian eller Pure Storage FlashBlade som støtter S3 Object Lock-API-er.
* Blokk-/fillagring: ZFS med skrivebeskyttede øyeblikksbilder og delegert administrasjon, eller Linux-filattributter.

Implementering av uforanderlig lagring: Tekniske gjennomganger

1. Nettskybasert objektlagring: AWS S3 Object Lock

For å beskytte databasedumper og transaksjonslogger i AWS, må du aktivere Object Lock når bøtten (bucket) opprettes.

Først oppretter du bøtten med Object Lock aktivert:

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

Deretter konfigurerer du standard oppbevaringspolicy. For databasearkiver er en 30-dagers samsvarslås en standard basislinje, som sikrer at du har en måned med uforanderlige sikkerhetskopier.

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

Når skriptet eller agenten for sikkerhetskopiering sender en fil til denne bøtten, beregner S3 automatisk Retain Until Date basert på tidsstempelet for opprettelse pluss 30 dager.

2. Lokal uforanderlighet: ZFS og Linux-attributter

Hvis du arkiverer databaser til en lokal Linux-server for sikkerhetskopiering, kan du oppnå pseudo-uforanderlighet ved å bruke chattr-kommandoen, eller ekte uforanderlighet ved hjelp av ZFS-øyeblikksbilder.

Bruk av Linux chattr:
+i-flagget (immutable) hindrer endring, sletting eller endring av filnavn.

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

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

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

Merk: Selv om chattr stopper enkle løsepengevirus-skript, kan en sofistikert angriper med root-tilgang ganske enkelt kjøre chattr -i. Derfor må dette kombineres med streng RBAC og isolerte nettverk for sikkerhetskopiering.

Bruk av ZFS-øyeblikksbilder:
ZFS gir et mye sterkere forsvar. Ved å ta et øyeblikksbilde og legge en «hold» på det, hindrer du at øyeblikksbildet blir slettet.

# Ta et øyeblikksbilde av datasettet for sikkerhetskopiering
zfs snapshot tank/db_backups@archive_$(date +%F)

# Legg en hold på øyeblikksbildet for å hindre sletting
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Selv root kan ikke slette dette øyeblikksbildet uten å fjerne hold-en
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Database-spesifikke arkiveringsstrategier

For å oppnå gjenoppretting til et bestemt tidspunkt (PITR), må du kontinuerlig arkivere transaksjonslogger til din uforanderlige lagring.

PostgreSQL WAL-arkivering med pgBackRest

pgBackRest er et svært pålitelig verktøy for sikkerhetskopiering av PostgreSQL som støtter S3-kompatibel lagring. For å beskytte dine Write-Ahead Logs (WAL), konfigurer pgBackRest til å sende data direkte til din uforanderlige S3-bøtte.

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 oppbevaring samsvarer med din S3 Object Lock-konfigurasjon
repo1-retention-full=2
repo1-retention-archive=2

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

Viktig vurdering: Hvis S3-bøtten din håndhever en 30-dagers samsvarslås, men pgBackRest forsøker å utløpe og slette WAL-filer etter 14 dager basert på repo1-retention-archive, vil API-kallene for sletting feile. Du må sikre at sikkerhetskopieringsprogramvarens oppbevaringspolicy er lik eller lengre enn den uforanderlige låsen på lagringsnivå.

Microsoft SQL Server: Sikkerhetskopiering til URL

SQL Server støtter innebygd sikkerhetskopiering direkte til S3-kompatibel objektlagring. Du kan konfigurere en SQL Server Agent-jobb til å skrive .bak– og .trn-filer direkte til en uforanderlig bøtte.

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

Å administrere uforanderlige oppbevaringsflagg, rotere tilgangsnøkler og sikre synkronisering mellom database-oppbevaringspolicyer og lagringslåser via egendefinerte skript er svært utsatt for feil. En enkelt feilkonfigurasjon i en cron-jobb eller et API-kall kan etterlate arkivene dine eksponert eller føre til skyhøye lagringskostnader på grunn av foreldreløse, låste objekter.

Bedriftsplattformer for sikkerhetskopiering som CloudSave forenkler denne arkitekturen. CloudSave integreres innebygd med AWS S3 Object Lock, Azure Blob Immutable Storage og lokale S3-kompatible API-er.

Når du konfigurerer en plan for databasesikkerhetskopiering i CloudSave:
1. Plattformen håndterer automatisk VSS (Volume Shadow Copy Service) for SQL Server eller pg_start_backup()-API-et for PostgreSQL.
2. Den strømmer de dedupliserte, krypterte sikkerhetskopidataene direkte til lagringsmålet.
3. CloudSave bruker dynamisk WORM API-kall (f.eks. PutObjectRetention) per objekt, og justerer lagringslåsens varighet perfekt med den policy-definerte oppbevaringsplanen.
4. Hvis en angriper kompromitterer CloudSave-administrasjonskonsollen, kan de fortsatt ikke slette sikkerhetskopiene, ettersom samsvarslåsen håndheves av den underliggende lagringsinfrastrukturen, ikke av sikkerhetskopieringsprogramvaren.

Beste praksis for uforanderlige databasearkiver

For å sikre at din uforanderlige arkitektur er genuint motstandsdyktig, bør du følge disse beste praksisene for systemutvikling:

1. Streng NTP-synkronisering

Uforanderlige låser er matematisk bundet til tidsstempler. Hvis NTP-tjenesten (Network Time Protocol) på lagringsmatrisen eller sikkerhetskopieringsserveren din blir kompromittert eller driver, kan det føre til at låser utløper for tidlig eller aldri utløper i det hele tatt. Sørg for at lagringsinfrastrukturen din bruker autentiserte, redundante NTP-kilder.

2. Isoler IAM-roller og legitimasjon

Legitimasjonen som brukes til å skrive til den uforanderlige bøtten må kun ha s3:PutObject– og s3:PutObjectRetention-tillatelser. De skal aldri ha s3:DeleteObject– eller s3:PutBucketObjectLockConfiguration-tillatelser.

Eksempel på en IAM-policy med laveste privilegier for en database-sikkerhetskopieringsagent:

{
    "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. Dimensjonering av oppbevaringsperioden

Ikke sett samsvarslåser for ekstremt lange perioder (f.eks. 7 år for samsvar) på ditt primære lag for rask gjenoppretting. Databaser genererer enorme mengder WAL-/transaksjonsloggdata. Å låse disse dataene i årevis vil føre til eksponentiell vekst i lagringskostnader.
Bruk heller en lagdelt tilnærming:
* Operasjonelt gjenopprettingslag: 14 til 30 dagers uforanderlig oppbevaring for fullstendige sikkerhetskopier og logger.
* Langtidsarkiveringslag: Månedlige fullstendige sikkerhetskopier flyttet til Glacier/Deep Archive med Vault Lock i 1–7 år.

4. Regelmessig gjenopprettingstesting i isolerte VPC-er

Uforanderlighet garanterer at dataene ikke kan slettes, men det garanterer ikke at dataene er fri for logisk korrupsjon. Du må automatisere gjenopprettingen av dine uforanderlige databasearkiver til en isolert, luftgappet VPC eller VLAN. Kjør DBCC CHECKDB (SQL Server) eller pg_amcheck (PostgreSQL) på de gjenopprettede dataene for å verifisere strukturell integritet.

Konklusjon

Forsvar mot løsepengevirus handler om å anta at et innbrudd vil skje. Innen et varsel utløses i din SIEM, har trusselaktører sannsynligvis allerede forsøkt å kompromittere infrastrukturen din for sikkerhetskopiering. Ved å arkitektere databasearkivene dine ved hjelp av uforanderlig lagring i samsvarsmodus, frarøver du angripere deres primære pressmiddel. Enten du bruker innebygde sky-API-er, ZFS-holds eller en orkestreringsplattform for bedrifter som CloudSave, er implementering av WORM-lagring ikke lenger valgfritt – det er en obligatorisk pilar i moderne databaseadministrasjon og katastrofegjenoppretting.

Kategorier