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.

Mūsdienu apdraudējumu vidē izspiedējvīrusi ir attīstījušies no oportūnistiskas šifrēšanas līdz mērķtiecīgām, daudzpakāpju izspiešanas kampaņām. Uzlaboto pastāvīgo draudu (APT) grupas un izspiedējvīrusu sindikāti tagad aktīvi meklē rezerves kopiju infrastruktūru un datubāžu arhīvus savas uzturēšanās laikā sistēmā. Ja uzbrucējs kompromitē jūsu primāro datubāzi un vienlaikus izdzēš vai šifrē jūsu rezerves kopiju krātuves, jūsu organizācija saskaras ar katastrofālu datu zudumu.

Datubāžu administratoriem (DBA) un DevOps inženieriem tradicionālā 3-2-1 rezerves kopiju stratēģija vairs nav pietiekama. Lai garantētu datu izdzīvošanu, infrastruktūras komandām ir jāpieņem 3-2-1-1 noteikums, kur pēdējais “1” apzīmē nemainīgu (immutable) krātuvi.

Šajā rakstā ir sniegts visaptverošs, tehnisks ieskats nemainīgas krātuves arhitektūras izstrādē, ieviešanā un pārvaldībā datubāžu arhīviem, lai nodrošinātu absolūtu noturību pret izspiedējvīrusiem.

Nemainīgas krātuves mehānika

Nemainīga krātuve balstās uz WORM (Write-Once-Read-Many – rakstīt vienreiz, lasīt daudzkārt) arhitektūru. Kad dati ir ierakstīti nemainīgā mērķvietā, tos nevar modificēt, šifrēt vai izdzēst neviens lietotājs, tostarp administratori ar root privilēģijām vai kompromitēti pakalpojumu konti, līdz beidzas matemātiski noteiktais laika ierobežojums.

Atbilstības režīms (Compliance Mode) pret Pārvaldības režīmu (Governance Mode)

Ieviešot nemainīgumu, īpaši mākoņa objektu krātuvēs, piemēram, AWS S3, Azure Blob vai S3 saderīgās lokālās SAN sistēmās, ir jāsaprot atšķirība starp saglabāšanas režīmiem:

  • Pārvaldības režīms (Governance Mode): Neļauj standarta lietotājiem dzēst vai mainīt objektus. Tomēr lietotāji ar īpašām IAM atļaujām (piem., s3:BypassGovernanceRetention) var apiet šo bloķēšanu. Tas ir noderīgi testēšanai, bet nepietiekami aizsardzībai pret izspiedējvīrusiem, jo uzbrucēji bieži paaugstina privilēģijas līdz domēna administratora vai root līmenim.
  • Atbilstības režīms (Compliance Mode): Zelta standarts aizsardzībai pret izspiedējvīrusiem. Kad objekts ir bloķēts atbilstības režīmā, tā saglabāšanas periodu nevar saīsināt, un objektu nevar izdzēst neviens, tostarp AWS root konts. Bloķēšana tiek īstenota krātuves klastera līmenī.

Nemainīgas rezerves kopiju cauruļvada arhitektūra

Robustā datubāžu arhivēšanas arhitektūra atdala aktīvās datubāžu darbības no nemainīgā arhīva līmeņa. Jūs nevarat piemērot nemainīgumu aktīviem datubāžu failiem (piemēram, .mdf/.ldf SQL Server vai pg_data direktorijai PostgreSQL), jo datubāzēm ir nepieciešama pastāvīga lasīšanas/rakstīšanas piekļuve.

Tā vietā nemainīgums tiek piemērots:
1. Pilnām un diferenciālajām rezerves kopijām: Datubāzes bāzes momentuzņēmumiem.
2. Transakciju žurnāliem / WAL failiem: Pastāvīgai datubāzes izmaiņu plūsmai, kas nepieciešama atjaunošanai uz noteiktu laika punktu (Point-in-Time Recovery — PITR).

Krātuvju mērķi nemainīgumam

Jūs varat ieviest nemainīgu krātuvi dažādos infrastruktūras līmeņos:
* Mākoņa objektu krātuve: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Lokālā objektu krātuve: MinIO, Cloudian vai Pure Storage FlashBlade, kas atbalsta S3 Object Lock API.
* Bloku/failu krātuve: ZFS ar tikai lasāmiem momentuzņēmumiem un deleģētu administrēšanu vai Linux failu atribūtiem.

Nemainīgas krātuves ieviešana: Tehniskie norādījumi

1. Mākoņa objektu krātuve: AWS S3 Object Lock

Lai aizsargātu datubāžu izgāzumus (dumps) un transakciju žurnālus AWS, jums ir jāiespējo Object Lock brīdī, kad tiek izveidots “bucket” (krātuves konteiners).

Vispirms izveidojiet “bucket” ar iespējotu Object Lock:

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

Pēc tam konfigurējiet noklusējuma saglabāšanas politiku. Datubāžu arhīviem 30 dienu atbilstības bloķēšana ir standarta bāzes līnija, kas nodrošina, ka jums ir mēnesi ilgas nemainīgas rezerves kopijas.

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

Kad jūsu datubāzes rezerves kopiju skripts vai aģents nosūta failu uz šo “bucket”, S3 automātiski aprēķina Retain Until Date (saglabāt līdz datumam), pamatojoties uz objekta izveides laika zīmogu plus 30 dienām.

2. Lokālā nemainība: ZFS un Linux atribūti

Ja arhivējat datubāzes uz lokāla Linux rezerves kopiju servera, varat panākt pseido-nemainību, izmantojot chattr komandu, vai patiesu nemainību, izmantojot ZFS momentuzņēmumus.

Izmantojot Linux chattr:
+i (immutable) karodziņš novērš faila modificēšanu, dzēšanu vai pārdēvēšanu.

# Izveidot datubāzes izgāzumu
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Padarīt rezerves kopiju nemainīgu
sudo chattr +i /backups/mydb_$(date +%F).dump

# Pārbaudīt atribūtu
lsattr /backups/mydb_$(date +%F).dump
# Izvade: ----i---------e------- /backups/mydb_2023-10-27.dump

Piezīme: Lai gan chattr aptur pamata izspiedējvīrusu skriptus, izsmalcināts uzbrucējs ar root piekļuvi var vienkārši izpildīt chattr -i. Tāpēc tas ir jāapvieno ar stingru RBAC un izolētiem rezerves kopiju tīkliem.

Izmantojot ZFS momentuzņēmumus:
ZFS nodrošina daudz spēcīgāku aizsardzību. Izveidojot momentuzņēmumu un uzliekot tam “aizturi” (hold), jūs novēršat momentuzņēmuma iznīcināšanu.

# Izveidot rezerves kopiju datu kopas momentuzņēmumu
zfs snapshot tank/db_backups@archive_$(date +%F)

# Uzlikt aizturi momentuzņēmumam, lai novērstu dzēšanu
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Pat root nevar iznīcināt šo momentuzņēmumu, neatbrīvojot aizturi
zfs destroy tank/db_backups@archive_$(date +%F)
# Izvade: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Datubāzēm specifiskas arhivēšanas stratēģijas

Lai panāktu atjaunošanu uz noteiktu laika punktu (PITR), jums ir nepārtraukti jāarhivē transakciju žurnāli savā nemainīgajā krātuvē.

PostgreSQL WAL arhivēšana ar pgBackRest

pgBackRest ir ļoti uzticams rezerves kopiju rīks PostgreSQL, kas natīvi atbalsta S3 saderīgu krātuvi. Lai aizsargātu savus Write-Ahead Logs (WAL), konfigurējiet pgBackRest sūtīt datus tieši uz jūsu nemainīgo S3 “bucket”.

Jūsu pgbackrest.conf failā:

[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

# Nodrošiniet, ka saglabāšanas termiņš atbilst jūsu S3 Object Lock konfigurācijai
repo1-retention-full=2
repo1-retention-archive=2

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

Svarīgs apsvērums: Ja jūsu S3 “bucket” piemēro 30 dienu atbilstības bloķēšanu, bet pgBackRest mēģina izbeigt un izdzēst WAL failus pēc 14 dienām, pamatojoties uz repo1-retention-archive, dzēšanas API izsaukumi neizdosies. Jums ir jāpārliecinās, ka jūsu rezerves kopiju programmatūras saglabāšanas politika ir vienāda vai garāka par krātuves līmeņa nemainīgo bloķēšanu.

Microsoft SQL Server: Rezerves kopija uz URL

SQL Server atbalsta natīvas rezerves kopijas tieši uz S3 saderīgu objektu krātuvi. Varat konfigurēt SQL Server Agent darbu, lai rakstītu .bak un .trn failus tieši uz nemainīgu “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

Automatizācija un orķestrēšana ar CloudSave

Nemainīgo saglabāšanas karodziņu pārvaldība, piekļuves atslēgu rotācija un sinhronizācijas nodrošināšana starp datubāžu saglabāšanas politikām un krātuvju bloķēšanu, izmantojot pielāgotus skriptus, ir ļoti pakļauta kļūdām. Viena nepareiza konfigurācija cron darbā vai API izsaukumā var atstāt jūsu arhīvus neaizsargātus vai izraisīt strauju mākoņa krātuves izmaksu pieaugumu dēļ atstātiem, bloķētiem objektiem.

Uzņēmuma līmeņa rezerves kopiju platformas, piemēram, CloudSave, vienkāršo šo arhitektūru. CloudSave natīvi integrējas ar AWS S3 Object Lock, Azure Blob Immutable Storage un lokālām S3 saderīgām API.

Konfigurējot datubāzes rezerves kopiju plānu CloudSave:
1. Platforma automātiski apstrādā VSS (Volume Shadow Copy Service) klusēšanu SQL Server vai pg_start_backup() API PostgreSQL.
2. Tā straumē dedublētus, šifrētus rezerves kopiju datus tieši uz krātuves mērķi.
3. CloudSave dinamiski piemēro WORM API izsaukumus (piem., PutObjectRetention) katram objektam atsevišķi, perfekti saskaņojot krātuves bloķēšanas ilgumu ar politikā definēto saglabāšanas grafiku.
4. Ja uzbrucējs kompromitē CloudSave pārvaldības konsoli, viņš joprojām nevar izdzēst rezerves kopijas, jo atbilstības bloķēšanu īsteno pamatā esošā krātuves infrastruktūra, nevis rezerves kopiju programmatūra.

Labākā prakse nemainīgiem datubāžu arhīviem

Lai nodrošinātu, ka jūsu nemainīgā arhitektūra ir patiesi noturīga, ievērojiet šādu sistēmu inženierijas labāko praksi:

1. Stingra NTP sinhronizācija

Nemainīgās bloķēšanas ir matemātiski piesaistītas laika zīmogiem. Ja NTP (Network Time Protocol) pakalpojums jūsu krātuvju masīvā vai rezerves kopiju serverī ir kompromitēts vai nobīdās, tas var izraisīt bloķēšanas priekšlaicīgu beigšanos vai to, ka tās nekad nebeidzas. Nodrošiniet, ka jūsu krātuvju infrastruktūra izmanto autentificētus, redundantus NTP avotus.

2. Izolējiet IAM lomas un akreditācijas datus

Akreditācijas datiem, ko izmanto rakstīšanai uz nemainīgo “bucket”, jābūt tikai s3:PutObject un s3:PutObjectRetention atļaujām. Tiem nekad nevajadzētu būt s3:DeleteObject vai s3:PutBucketObjectLockConfiguration atļaujām.

Piemērs minimālo privilēģiju IAM politikai datubāzes rezerves kopiju aģentam:

{
    "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. Saglabāšanas perioda noteikšana

Neiestatiet atbilstības bloķēšanu uz pārmērīgi ilgiem periodiem (piem., 7 gadiem atbilstības nodrošināšanai) savā primārajā ātrās atjaunošanas līmenī. Datubāzes ģenerē milzīgu daudzumu WAL/transakciju žurnālu datu. Šo datu bloķēšana gadiem ilgi radīs eksponenciālu krātuves izmaksu pieaugumu.
Tā vietā izmantojiet līmeņveida pieeju:
* Operatīvās atjaunošanas līmenis: 14 līdz 30 dienu nemainīga saglabāšana pilnām kopijām un žurnāliem.
* Ilgtermiņa arhivēšanas līmenis: Ikmēneša pilnas rezerves kopijas, kas pārvietotas uz Glacier/Deep Archive ar Vault Lock uz 1-7 gadiem.

4. Regulāra atjaunošanas testēšana izolētos (air-gapped) VPC

Nemainīgums garantē, ka datus nevar izdzēst, bet tas negarantē, ka dati ir brīvi no loģiskiem bojājumiem. Jums ir jāautomatizē savu nemainīgo datubāžu arhīvu atjaunošana izolētā, no tīkla atdalītā (air-gapped) VPC vai VLAN. Palaidiet DBCC CHECKDB (SQL Server) vai pg_amcheck (PostgreSQL) uz atjaunotajiem datiem, lai pārbaudītu strukturālo integritāti.

Secinājums

Aizsardzība pret izspiedējvīrusiem ir vingrinājums, pieņemot, ka ielaušanās notiks. Līdz brīdim, kad jūsu SIEM sistēmā atskan brīdinājums, draudu dalībnieki, visticamāk, jau ir mēģinājuši kompromitēt jūsu rezerves kopiju infrastruktūru. Izstrādājot savu datubāžu arhīvu arhitektūru, izmantojot nemainīgu krātuvi atbilstības režīmā, jūs atņemat uzbrucējiem to galveno sviru. Neatkarīgi no tā, vai izmantojat natīvas mākoņa API, ZFS aiztures vai uzņēmuma orķestrēšanas platformu, piemēram, CloudSave, WORM krātuves ieviešana vairs nav izvēles iespēja — tas ir obligāts mūsdienu datubāžu administrēšanas un katastrofu seku novēršanas pīlārs.

Kategorijas