Architektūriniai nekintamos saugyklos sprendimai duomenų bazių archyvams, skirti apsisaugoti nuo išpirkos reikalaujančių programų

Šiuolaikinėje grėsmių aplinkoje išpirkos reikalaujanti programinė įranga (angl. ransomware) evoliucionavo nuo oportunistinio šifravimo iki itin tikslinių, daugialypio turto prievartavimo kampanijų. Pažangios nuolatinės grėsmės (APT) ir išpirkos reikalaujančios grupuotės dabar aktyviai ieško atsarginių kopijų infrastruktūros ir duomenų bazių archyvų, kol yra įsilaužusios į sistemą. Jei užpuolikas kompromituoja jūsų pagrindinę duomenų bazę ir tuo pat metu ištrina arba užšifruoja jūsų atsarginių kopijų saugyklas, jūsų organizacijai gresia katastrofiškas duomenų praradimas.

Duomenų bazių administratoriams (DBA) ir „DevOps“ inžinieriams tradicinės 3-2-1 atsarginių kopijų strategijos nebepakanka. Norint užtikrinti duomenų išlikimą, infrastruktūros komandos turi taikyti 3-2-1-1 taisyklę, kurioje paskutinis „1“ reiškia nekintamą saugyklą (angl. immutable storage).

Šiame straipsnyje pateikiama išsami techninė analizė apie nekintamos saugyklos projektavimą, diegimą ir valdymą duomenų bazių archyvams, siekiant užtikrinti visišką atsparumą išpirkos reikalaujančioms programoms.

Nekintamos saugyklos mechanika

Nekintama saugykla remiasi „įrašyti vieną kartą, skaityti daug kartų“ (WORM) architektūra. Kai duomenys įrašomi į nekintamą tikslinę vietą, jų negali modifikuoti, užšifruoti ar ištrinti joks vartotojas – įskaitant administratorius su „root“ teisėmis ar kompromituotas paslaugų paskyras – kol nesibaigia matematiškai užtikrintas laiko užraktas.

Atitikties režimas (Compliance Mode) vs. Valdymo režimas (Governance Mode)

Diegiant nekintamumą, ypač debesijos objektų saugyklose, tokiose kaip AWS S3, „Azure Blob“ ar S3 suderinamuose vietiniuose SAN, būtina suprasti skirtumą tarp saugojimo režimų:

• Valdymo režimas (Governance Mode): Neleidžia standartiniams vartotojams ištrinti ar keisti objektų. Tačiau vartotojai su tam tikrais IAM leidimais (pvz., s3:BypassGovernanceRetention) gali apeiti užraktą. Tai naudinga testavimui, bet nepakankama apsaugai nuo išpirkos reikalaujančių programų, nes užpuolikai dažnai padidina savo teises iki domeno administratoriaus ar „root“ lygio.
• Atitikties režimas (Compliance Mode): Auksinis standartas apsaugai nuo išpirkos reikalaujančių programų. Kai objektas užrakinamas atitikties režimu, jo saugojimo laikotarpis negali būti sutrumpintas, o objekto negali ištrinti niekas, įskaitant AWS „root“ paskyrą. Užraktas vykdomas saugyklų klasterio lygiu.

Nekintamo atsarginių kopijų konvejerio projektavimas

Patikima duomenų bazių archyvavimo architektūra atskiria aktyvias duomenų bazių operacijas nuo nekintamo archyvo lygmens. Nekintamumo negalima taikyti aktyviems duomenų bazių failams (pvz., .mdf/.ldf SQL serveryje arba pg_data katalogui „PostgreSQL“), nes duomenų bazėms reikalinga nuolatinė skaitymo/rašymo prieiga.

Vietoj to, nekintamumas taikomas:
1. Pilnoms ir diferencialinėms atsarginėms kopijoms: Bazinėms duomenų bazės momentinėms kopijoms (angl. snapshots).
2. Operacijų žurnalams / WAL failams: Nuolatiniam duomenų bazės pakeitimų srautui, reikalingam atkūrimui tam tikru laiko momentu (PITR).

Nekintamumo saugyklos tikslai

Nekintamą saugyklą galite įdiegti įvairiuose infrastruktūros lygmenyse:
* Debesijos objektų saugykla: „AWS S3 Object Lock“, „Azure Blob Immutable Storage“, „Google Cloud Storage“ saugojimo politikos.
* Vietinė objektų saugykla: „MinIO“, „Cloudian“ arba „Pure Storage FlashBlade“, palaikantys S3 „Object Lock“ API.
* Blokinė/failų saugykla: ZFS su tik skaitymui skirtomis momentinėmis kopijomis ir deleguotu administravimu arba „Linux“ failų atributais.

Nekintamos saugyklos diegimas: techninės instrukcijos

1. Debesijos objektų saugykla: AWS S3 Object Lock

Norėdami apsaugoti duomenų bazių kopijas ir operacijų žurnalus AWS, turite įjungti „Object Lock“ kuriant kaupyklą (bucket).

Pirmiausia sukurkite kaupyklą su įjungtu „Object Lock“:

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

Tada sukonfigūruokite numatytąją saugojimo politiką. Duomenų bazių archyvams 30 dienų atitikties užraktas yra standartinė bazinė linija, užtikrinanti, kad turėsite mėnesio trukmės nekeičiamas atsargines kopijas.

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

Kai jūsų duomenų bazės atsarginių kopijų scenarijus ar agentas įkelia failą į šią kaupyklą, S3 automatiškai apskaičiuoja Retain Until Date (saugojimo iki datos) pagal objekto sukūrimo laiko žymą plius 30 dienų.

2. Vietinis nekintamumas: ZFS ir „Linux“ atributai

Jei archyvuojate duomenų bazes į vietinį „Linux“ atsarginių kopijų serverį, galite pasiekti pseudo-nekintamumą naudodami chattr komandą arba tikrą nekintamumą naudodami ZFS momentines kopijas.

Naudojant „Linux“ chattr:
Žyma +i (nekintamas) neleidžia modifikuoti, ištrinti ar pervadinti failo.

# Iškelkite duomenų bazę
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Padarykite atsarginę kopiją nekintamą
sudo chattr +i /backups/mydb_$(date +%F).dump

# Patikrinkite atributą
lsattr /backups/mydb_$(date +%F).dump
# Išvestis: ----i---------e------- /backups/mydb_2023-10-27.dump

Pastaba: Nors chattr sustabdo paprastus išpirkos reikalaujančių programų scenarijus, patyręs užpuolikas su „root“ prieiga gali tiesiog paleisti chattr -i. Todėl tai turi būti derinama su griežta RBAC (prieigos kontrolė) ir izoliuotais atsarginių kopijų tinklais.

Naudojant ZFS momentines kopijas:
ZFS suteikia daug stipresnę apsaugą. Sukūrus momentinę kopiją ir uždėjus jai „laikymą“ (hold), užkertate kelią jos sunaikinimui.

# Sukurkite atsarginių kopijų duomenų rinkinio momentinę kopiją
zfs snapshot tank/db_backups@archive_$(date +%F)

# Uždėkite „laikymą“ ant momentinės kopijos, kad išvengtumėte ištrynimo
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Net „root“ negali sunaikinti šios momentinės kopijos neatšaukęs „laikymo“
zfs destroy tank/db_backups@archive_$(date +%F)
# Išvestis: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Duomenų bazėms skirtos archyvavimo strategijos

Norint pasiekti atkūrimą tam tikru laiko momentu (PITR), turite nuolat archyvuoti operacijų žurnalus į savo nekintamą saugyklą.

„PostgreSQL“ WAL archyvavimas su „pgBackRest“

pgBackRest yra itin patikimas atsarginių kopijų įrankis, skirtas „PostgreSQL“, kuris natūraliai palaiko S3 suderinamas saugyklas. Norėdami apsaugoti savo „Write-Ahead Logs“ (WAL), sukonfigūruokite pgBackRest tiesiogiai įkelti duomenis į jūsų nekintamą S3 kaupyklą.

Jūsų pgbackrest.conf faile:

[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

# Užtikrinkite, kad saugojimo laikotarpis atitiktų jūsų S3 Object Lock konfigūraciją
repo1-retention-full=2
repo1-retention-archive=2

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

Svarbus aspektas: Jei jūsų S3 kaupykla taiko 30 dienų atitikties užraktą, bet pgBackRest bando ištrinti WAL failus po 14 dienų pagal repo1-retention-archive, ištrynimo API užklausos nepavyks. Turite užtikrinti, kad jūsų atsarginių kopijų programinės įrangos saugojimo politika būtų ilgesnė arba lygi saugyklos lygmens nekintamam užraktui.

„Microsoft SQL Server“: atsarginė kopija į URL

SQL Server palaiko natūralias atsargines kopijas tiesiai į S3 suderinamą objektų saugyklą. Galite sukonfigūruoti „SQL Server Agent“ užduotį, kad .bak ir .trn failai būtų rašomi tiesiai į nekintamą kaupyklą.

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

Automatizavimas ir orkestravimas su „CloudSave“

Nekintamų saugojimo vėliavėlių valdymas, prieigos raktų keitimas ir sinchronizacijos tarp duomenų bazių saugojimo politikų bei saugyklų užraktų užtikrinimas naudojant pasirinktinius scenarijus yra labai linkęs į klaidas. Viena neteisinga konfigūracija „cron“ užduotyje ar API iškvietime gali palikti jūsų archyvus pažeidžiamus arba sukelti sparčiai augančias debesijos saugyklos išlaidas dėl paliktų, užrakintų objektų.

Įmonių lygio atsarginių kopijų platformos, tokios kaip „CloudSave“, supaprastina šią architektūrą. „CloudSave“ natūraliai integruojasi su „AWS S3 Object Lock“, „Azure Blob Immutable Storage“ ir vietiniais S3 suderinamais API.

Konfigūruojant duomenų bazės atsarginių kopijų planą „CloudSave“ platformoje:
1. Platforma automatiškai tvarko VSS („Volume Shadow Copy Service“) ramybės būseną SQL Serveriui arba pg_start_backup() API „PostgreSQL“ duomenų bazei.
2. Ji perduoda deduplikuotus, užšifruotus atsarginių kopijų duomenis tiesiai į saugyklą.
3. „CloudSave“ dinamiškai taiko WORM API iškvietimus (pvz., PutObjectRetention) kiekvienam objektui atskirai, puikiai suderindama saugyklos užrakto trukmę su politikoje nustatytu saugojimo grafiku.
4. Jei užpuolikas kompromituoja „CloudSave“ valdymo konsolę, jis vis tiek negali ištrinti atsarginių kopijų, nes atitikties užraktą vykdo pagrindinė saugyklos infrastruktūra, o ne atsarginių kopijų programinė įranga.

Geriausia nekintamų duomenų bazių archyvų praktika

Norėdami užtikrinti, kad jūsų nekintama architektūra būtų tikrai atspari, laikykitės šių sistemų inžinerijos geriausių praktikų:

1. Griežta NTP sinchronizacija

Nekintami užraktai yra matematiškai susieti su laiko žymomis. Jei NTP (tinklo laiko protokolo) paslauga jūsų saugyklų masyve ar atsarginių kopijų serveryje yra kompromituota arba išsiderina, tai gali sukelti užraktų per ankstyvą pasibaigimą arba jų visiško nepasibaigimo problemą. Užtikrinkite, kad jūsų saugyklų infrastruktūra naudoja autentifikuotus, perteklinius NTP šaltinius.

2. IAM vaidmenų ir kredencialų izoliavimas

Kredencialai, naudojami rašymui į nekintamą kaupyklą, turi turėti tik s3:PutObject ir s3:PutObjectRetention leidimus. Jie niekada neturėtų turėti s3:DeleteObject ar s3:PutBucketObjectLockConfiguration leidimų.

Mažiausių privilegijų IAM politikos pavyzdys duomenų bazės atsarginių kopijų agentui:

{
    "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. Saugojimo laikotarpio nustatymas

Nenustatykite atitikties užraktų itin ilgiems laikotarpiams (pvz., 7 metams dėl atitikties) savo pirminiame greito atkūrimo lygmenyje. Duomenų bazės generuoja didžiulius WAL/operacijų žurnalų duomenų kiekius. Šių duomenų užrakinimas metams sukels eksponentinį saugyklos išlaidų augimą.
Vietoj to naudokite pakopinį požiūrį:
* Operatyvinio atkūrimo lygmuo: 14–30 dienų nekintamas saugojimas pilnoms kopijoms ir žurnalams.
* Ilgalaikio archyvavimo lygmuo: Mėnesinės pilnos atsarginės kopijos, perkeltos į „Glacier“/„Deep Archive“ su „Vault Lock“ 1–7 metams.

4. Reguliarus atkūrimo testavimas izoliuotuose (air-gapped) VPC

Nekintamumas garantuoja, kad duomenys negali būti ištrinti, bet negarantuoja, kad duomenyse nėra loginės korupcijos. Turite automatizuoti savo nekintamų duomenų bazių archyvų atkūrimą į izoliuotą, nuo tinklo atjungtą VPC arba VLAN. Vykdykite DBCC CHECKDB (SQL Server) arba pg_amcheck („PostgreSQL“) atkurtiems duomenims, kad patikrintumėte struktūrinį vientisumą.

Išvada

Apsauga nuo išpirkos reikalaujančių programų yra pratybos, kuriose daroma prielaida, kad įsilaužimas jau įvyko. Iki to laiko, kai jūsų SIEM sistemoje suveikia įspėjimas, grėsmių veikėjai tikriausiai jau bandė kompromituoti jūsų atsarginių kopijų infrastruktūrą. Suprojektuodami savo duomenų bazių archyvus naudodami nekintamą saugyklą atitikties režimu, atimate iš užpuolikų jų pagrindinį svertą. Nesvarbu, ar naudojate vietinius debesijos API, ZFS „laikymus“, ar įmonės orkestravimo platformą, tokią kaip „CloudSave“, WORM saugyklos diegimas nebėra pasirinktinis – tai privalomas šiuolaikinio duomenų bazių administravimo ir atkūrimo po nelaimių ramstis.