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.

Í nútíma ógnarlandslagi hefur lausnarhugbúnaður (ransomware) þróast úr tækifærissinnuðum dulkóðunarárásum yfir í mjög markvissar herferðir með margþættum fjárkúgunum. Háþróaðar viðvarandi ógnir (APT) og lausnarhugbúnaðarhópar leita nú virkt að afritunarinnviðum og gagnagrunnssöfnum á meðan þeir eru inni í kerfum. Ef árásaraðili kemst yfir aðalgagnagrunninn þinn og eyðir eða dulkóðar afritunargeymslur þínar samtímis, stendur fyrirtækið þitt frammi fyrir skelfilegu gagnatapi.

Fyrir gagnagrunnsstjóra (DBA) og DevOps-verkfræðinga er hefðbundna 3-2-1 afritunarstefnan ekki lengur nægjanleg. Til að tryggja að gögn lifi af verða innviðateymi að taka upp 3-2-1-1 regluna, þar sem síðasti „1“-inn stendur fyrir óbreytanlega geymslu (immutable storage).

Þessi grein veitir yfirgripsmikla, tæknilega dýfu í hönnun, innleiðingu og stjórnun á óbreytanlegri geymslu fyrir gagnagrunnssöfn til að tryggja algjöra viðnámsþrótt gegn lausnarhugbúnaði.

Vélfræði óbreytanlegrar geymslu

Óbreytanleg geymsla byggir á WORM-arkitektúr (Write-Once-Read-Many). Þegar gögn hafa verið skrifuð á óbreytanlegan áfangastað er ekki hægt að breyta þeim, dulkóða eða eyða af neinum notanda – þar með talið stjórnendum með rótaraðgang (root) eða kompromitteruðum þjónustureikningum – fyrr en stærðfræðilega útfærð tímalás rennur út.

Samræmisstilling (Compliance Mode) vs. Stjórnunarstilling (Governance Mode)

Þegar óbreytanleiki er innleiddur, sérstaklega í skýjageymslum eins og AWS S3, Azure Blob eða S3-samhæfðum SAN-kerfum á staðnum, verður þú að skilja muninn á varðveislustillingum:

  • Stjórnunarstilling (Governance Mode): Kemur í veg fyrir að venjulegir notendur eyði eða breyti hlutum. Hins vegar geta notendur með sérstakar IAM-heimildir (t.d. s3:BypassGovernanceRetention) sniðgengið lásinn. Þetta er gagnlegt við prófanir en ófullnægjandi fyrir vörn gegn lausnarhugbúnaði, þar sem árásaraðilar hækka oft heimildir sínar í lénsstjóra eða rótaraðgang.
  • Samræmisstilling (Compliance Mode): Gullstaðallinn fyrir vörn gegn lausnarhugbúnaði. Þegar hlutur er læstur í samræmisstillingu er ekki hægt að stytta varðveislutímann og enginn getur eytt hlutnum, þar með talið AWS-rótareikningurinn. Lásinn er framfylgt á stigi geymsluklasans.

Hönnun á óbreytanlegu afritunarferli

Öflugur arkitektúr fyrir gagnagrunnssöfn aðskilur virka gagnagrunnsstarfsemi frá óbreytanlega geymslulaginu. Þú getur ekki beitt óbreytanleika á virkar gagnagrunnsskrár (eins og .mdf/.ldf í SQL Server eða pg_data möppuna í PostgreSQL) vegna þess að gagnagrunnar krefjast stöðugs les-/skrifaðgangs.

Í staðinn er óbreytanleika beitt á:
1. Full og mismunadrifin afrit (Full and Differential Backup Files): Grunnmyndir af gagnagrunninum.
2. Færsluskrár / WAL-skrár: Stöðugur straumur gagnagrunnsbreytinga sem þarf fyrir endurheimt á ákveðnum tímapunkti (Point-in-Time Recovery – PITR).

Geymsluáfangastaðir fyrir óbreytanleika

Þú getur innleitt óbreytanlega geymslu á mismunandi innviðastigum:
* Skýjageymsla (Object Storage): AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Geymsla á staðnum (On-Premises Object Storage): MinIO, Cloudian eða Pure Storage FlashBlade sem styðja S3 Object Lock API.
* Blokk-/skráageymsla: ZFS með skrifvörðum skyndimyndum (snapshots) og framseldri stjórnun, eða Linux skráareiginleikar.

Innleiðing á óbreytanlegri geymslu: Tæknilegar leiðbeiningar

1. Skýjageymsla: AWS S3 Object Lock

Til að vernda gagnagrunnssöfn og færsluskrár í AWS verður þú að virkja Object Lock þegar fötu (bucket) er búið til.

Fyrst skaltu búa til fötuna með Object Lock virkt:

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

Næst skaltu stilla sjálfgefna varðveislustefnu. Fyrir gagnagrunnssöfn er 30 daga samræmislás staðlaður grunnur, sem tryggir að þú hafir mánaðar afrit sem ekki er hægt að breyta.

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

Þegar afritunarforskriftin þín eða umboðsmaður sendir skrá í þessa fötu, reiknar S3 sjálfkrafa út Retain Until Date byggt á tímastimpli skráarstofnunar plús 30 dagar.

2. Óbreytanleiki á staðnum: ZFS og Linux eiginleikar

Ef þú ert að geyma gagnagrunna á Linux-afritunarþjóni á staðnum geturðu náð „gervi-óbreytanleika“ með chattr skipuninni, eða raunverulegum óbreytanleika með ZFS-skyndimyndum.

Notkun á Linux chattr:
+i (immutable) fáninn kemur í veg fyrir breytingar, eyðingu eða endurnefningu skráa.

# Taka afrit af gagnagrunni
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Gera afritið óbreytanlegt
sudo chattr +i /backups/mydb_$(date +%F).dump

# Staðfesta eiginleikann
lsattr /backups/mydb_$(date +%F).dump
# Úttak: ----i---------e------- /backups/mydb_2023-10-27.dump

Athugið: Þótt chattr stöðvi einfaldar lausnarhugbúnaðarforskriftir, getur háþróaður árásaraðili með rótaraðgang einfaldlega keyrt chattr -i. Þess vegna verður þetta að vera sameinað ströngu RBAC og einangruðum afritunarnetum.

Notkun á ZFS-skyndimyndum:
ZFS veitir mun sterkari vörn. Með því að taka skyndimynd og setja „hold“ á hana kemurðu í veg fyrir að henni sé eytt.

# Taka skyndimynd af afritunargagnasafninu
zfs snapshot tank/db_backups@archive_$(date +%F)

# Setja hold á skyndimyndina til að koma í veg fyrir eyðingu
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Jafnvel rótarnotandi getur ekki eytt þessari skyndimynd án þess að losa hold-ið
zfs destroy tank/db_backups@archive_$(date +%F)
# Úttak: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Afritunarstefnur fyrir gagnagrunna

Til að ná endurheimt á ákveðnum tímapunkti (PITR) verður þú stöðugt að geyma færsluskrár í óbreytanlegri geymslu.

PostgreSQL WAL-geymsla með pgBackRest

pgBackRest er mjög áreiðanlegt afritunartól fyrir PostgreSQL sem styður innbyggt S3-samhæfða geymslu. Til að vernda Write-Ahead Logs (WAL) skráarnar þínar skaltu stilla pgBackRest til að senda þær beint í óbreytanlegu S3-fötuna þína.

Í pgbackrest.conf skránni þinni:

[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

# Gakktu úr skugga um að varðveisla samræmist S3 Object Lock stillingum þínum
repo1-retention-full=2
repo1-retention-archive=2

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

Mikilvægt atriði: Ef S3-fatan þín framfylgir 30 daga samræmislás, en pgBackRest reynir að láta WAL-skrár renna út og eyða þeim eftir 14 daga byggt á repo1-retention-archive, munu eyðingarköllin mistakast. Þú verður að tryggja að varðveislustefna afritunarhugbúnaðarins sé jöfn eða lengri en óbreytanlegi lásinn á geymslustiginu.

Microsoft SQL Server: Afritun á URL

SQL Server styður innfædd afrit beint á S3-samhæfða geymslu. Þú getur stillt SQL Server Agent verk til að skrifa .bak og .trn skrár beint í óbreytanlega fötu.

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

Sjálfvirkni og stjórnun með CloudSave

Að stjórna óbreytanlegum varðveislufánum, snúa aðgangslyklum og tryggja samstillingu milli varðveislustefna gagnagrunna og geymslulása með sérsniðnum forskriftum er mjög villugjarnt. Ein röng stilling í cron-verki eða API-kalli getur skilið afritin þín eftir óvarin eða leitt til himinhárra skýjageymslukostnaðar vegna munaðarlausra, læstra hluta.

Afritunarvettvangar fyrir fyrirtæki eins og CloudSave einfalda þennan arkitektúr. CloudSave samþættist innbyggt við AWS S3 Object Lock, Azure Blob Immutable Storage og S3-samhæfð API á staðnum.

Þegar þú stillir afritunaráætlun fyrir gagnagrunn í CloudSave:
1. Vettvangurinn sér sjálfkrafa um VSS (Volume Shadow Copy Service) fyrir SQL Server eða pg_start_backup() API fyrir PostgreSQL.
2. Hann streymir afafrituðum, dulkóðuðum afritunargögnum beint á geymsluáfangastaðinn.
3. CloudSave beitir WORM API-köllunum (t.d. PutObjectRetention) á hverja skrá fyrir sig, sem samræmir láslengd geymslunnar fullkomlega við varðveislutímabilið sem skilgreint er í stefnunni.
4. Ef árásaraðili kemst yfir CloudSave-stjórnborðið getur hann samt ekki eytt afritunum, þar sem samræmislásnum er framfylgt af undirliggjandi geymsluinnviðum, ekki afritunarhugbúnaðinum.

Bestu starfsvenjur fyrir óbreytanleg gagnagrunnssöfn

Til að tryggja að óbreytanlegur arkitektúr þinn sé sannarlega viðnámsþróttur, skaltu fylgja eftirfarandi verkfræðilegum bestu starfsvenjum:

1. Ströng NTP-samstilling

Óbreytanlegir lásar eru stærðfræðilega bundnir við tímastimpla. Ef NTP (Network Time Protocol) þjónustan á geymsluklasanum þínum eða afritunarþjóni er kompromitteruð eða skekkjast, getur það valdið því að lásar renni út fyrir tímann eða renni aldrei út. Gakktu úr skugga um að geymsluinnviðir þínir noti staðfesta, óþarfa NTP-gjafa.

2. Einangra IAM-hlutverk og skilríki

Skilríkin sem notuð eru til að skrifa í óbreytanlegu fötuna mega aðeins hafa s3:PutObject og s3:PutObjectRetention heimildir. Þau ættu aldrei að hafa s3:DeleteObject eða s3:PutBucketObjectLockConfiguration heimildir.

Dæmi um IAM-stefnu með lágmarksréttindum fyrir afritunarumboðsmann gagnagrunns:

{
    "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. Stærð varðveislutímabilsins

Ekki setja samræmislása í óhóflega langan tíma (t.d. 7 ár fyrir samræmi) á aðal-endurheimtarlaginu þínu. Gagnagrunnar búa til gríðarlegt magn af WAL/færsluskráargögnum. Að læsa þessum gögnum í mörg ár mun leiða til veldisvaxandi geymslukostnaðar.
Notaðu frekar lagskipta nálgun:
* Rekstrarendurheimtarlag: 14 til 30 daga óbreytanleg varðveisla fyrir full afrit og skrár.
* Langtímageymslulag: Mánaðarleg full afrit flutt í Glacier/Deep Archive með Vault Lock í 1-7 ár.

4. Reglulegar endurheimtarprófanir í einangruðum VPC-um

Óbreytanleiki tryggir að gögnunum verði ekki eytt, en hann tryggir ekki að gögnin séu laus við rökréttar skemmdir. Þú verður að gera sjálfvirka endurheimt á óbreytanlegum gagnagrunnssöfnum þínum í einangrað, loftgirt (air-gapped) VPC eða VLAN. Keyrðu DBCC CHECKDB (SQL Server) eða pg_amcheck (PostgreSQL) á endurheimtu gögnunum til að staðfesta burðarvirki.

Niðurstaða

Vörn gegn lausnarhugbúnaði snýst um að gera ráð fyrir broti. Þegar viðvörun fer í gang í SIEM-kerfinu þínu hafa ógnaraðilar líklega þegar reynt að komast yfir afritunarinnviði þína. Með því að hanna gagnagrunnssöfnin þín með óbreytanlegri geymslu í samræmisstillingu, sviptir þú árásaraðila helsta vopni þeirra. Hvort sem þú notar innbyggð skýja-API, ZFS-hold eða fyrirtækjastjórnunarvettvang eins og CloudSave, þá er innleiðing á WORM-geymslu ekki lengur valfrjáls—hún er ófrávíkjanlegur hluti af nútíma gagnagrunnsstjórnun og hamfarabata.

Flokkar