Տվյալների բազայի արխիվների համար անփոփոխելի պահեստավորման ճարտարապետություն՝ ծրագիր-շորթիչներին հաղթելու համար

Ժամանակակից սպառնալիքների պայմաններում փրկագին պահանջող ծրագրերը (ransomware) հնարավորությունների որոնումից վերածվել են խիստ նպատակային, բազմակի շորթման արշավների: Ընդլայնված մշտական սպառնալիքները (APT) և ransomware սինդիկատներն այժմ ակտիվորեն որոնում են պահուստային ենթակառուցվածքներ և տվյալների բազայի արխիվներ՝ իրենց ներթափանցման ընթացքում: Եթե հարձակվողը վտանգում է ձեր հիմնական տվյալների բազան և միաժամանակ ջնջում կամ գաղտնագրում է ձեր պահուստային պահոցները, ձեր կազմակերպությունը կբախվի տվյալների աղետալի կորստի:

Տվյալների բազայի ադմինիստրատորների (DBA) և DevOps ինժեներների համար ավանդական 3-2-1 պահուստավորման ռազմավարությունն այլևս բավարար չէ: Տվյալների պահպանումը երաշխավորելու համար ենթակառուցվածքային թիմերը պետք է ընդունեն 3-2-1-1 կանոնը, որտեղ վերջին «1»-ը նշանակում է անփոփոխելի պահեստավորում (immutable storage):

Այս հոդվածը տրամադրում է համապարփակ, տեխնիկական խորը վերլուծություն տվյալների բազայի արխիվների համար անփոփոխելի պահեստավորման նախագծման, իրականացման և կառավարման վերաբերյալ՝ ransomware-ի նկատմամբ բացարձակ կայունություն ապահովելու համար:

Անփոփոխելի պահեստավորման մեխանիզմները

Անփոփոխելի պահեստավորումը հիմնված է «Գրել մեկ անգամ, կարդալ բազմիցս» (WORM) ճարտարապետության վրա: Երբ տվյալները գրվում են անփոփոխելի թիրախում, դրանք չեն կարող փոփոխվել, գաղտնագրվել կամ ջնջվել որևէ օգտատիրոջ կողմից, ներառյալ՝ root արտոնություններ ունեցող ադմինիստրատորները կամ վտանգված ծառայողական հաշիվները, մինչև մաթեմատիկորեն կիրառվող ժամանակային արգելափակման ժամկետի ավարտը:

Համապատասխանության ռեժիմ (Compliance Mode) ընդդեմ Կառավարման ռեժիմի (Governance Mode)

Անփոփոխելիությունը կիրառելիս, հատկապես ամպային օբյեկտային պահեստներում, ինչպիսիք են AWS S3-ը, Azure Blob-ը կամ S3-համատեղելի տեղային SAN-երը, դուք պետք է հասկանաք պահպանման ռեժիմների տարբերությունը.

• Կառավարման ռեժիմ (Governance Mode): Կանխում է ստանդարտ օգտատերերի կողմից օբյեկտների ջնջումը կամ փոփոխումը: Այնուամենայնիվ, հատուկ IAM թույլտվություններ ունեցող օգտատերերը (օրինակ՝ s3:BypassGovernanceRetention) կարող են շրջանցել արգելափակումը: Սա օգտակար է թեստավորման համար, բայց անբավարար է ransomware-ից պաշտպանվելու համար, քանի որ հարձակվողները հաճախ բարձրացնում են իրենց արտոնությունները մինչև դոմենի ադմինիստրատորի կամ root-ի մակարդակի:
• Համապատասխանության ռեժիմ (Compliance Mode): Ransomware-ի պաշտպանության ոսկե ստանդարտը: Երբ օբյեկտն արգելափակվում է Համապատասխանության ռեժիմում, դրա պահպանման ժամկետը չի կարող կրճատվել, և օբյեկտը չի կարող ջնջվել որևէ մեկի կողմից, ներառյալ՝ AWS root հաշիվը: Արգելափակումը կիրառվում է պահեստային կլաստերի մակարդակում:

Անփոփոխելի պահուստավորման խողովակաշարի նախագծում

Տվյալների բազայի արխիվացման ամուր ճարտարապետությունը տարանջատում է ակտիվ տվյալների բազայի գործողությունները անփոփոխելի արխիվային շերտից: Դուք չեք կարող անփոփոխելիություն կիրառել ակտիվ տվյալների բազայի ֆայլերի վրա (ինչպիսիք են .mdf/.ldf-ը SQL Server-ում կամ pg_data գրացուցակը PostgreSQL-ում), քանի որ տվյալների բազաները պահանջում են մշտական կարդալու/գրելու հասանելիություն:

Փոխարենը, անփոփոխելիությունը կիրառվում է հետևյալի վրա.
1. Լրիվ և դիֆերենցիալ պահուստային ֆայլեր. Տվյալների բազայի բազային պատկերները (snapshots):
2. Տրանզակցիոն մատյաններ / WAL ֆայլեր. Տվյալների բազայի փոփոխությունների շարունակական հոսքը, որն անհրաժեշտ է ժամանակի որոշակի կետում վերականգնման (PITR) համար:

Անփոփոխելիության պահեստային թիրախներ

Դուք կարող եք իրականացնել անփոփոխելի պահեստավորում տարբեր ենթակառուցվածքային շերտերում.
* Ամպային օբյեկտային պահեստ. AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies:
* Տեղային օբյեկտային պահեստ. MinIO, Cloudian կամ Pure Storage FlashBlade, որոնք աջակցում են S3 Object Lock API-ներին:
* Բլոկային/ֆայլային պահեստ. ZFS՝ միայն կարդալու համար նախատեսված պատկերներով (snapshots) և պատվիրակված կառավարմամբ, կամ Linux ֆայլային ատրիբուտներով:

Անփոփոխելի պահեստավորման իրականացում. տեխնիկական ուղեցույցներ

1. Ամպային օբյեկտային պահեստ. AWS S3 Object Lock

AWS-ում տվյալների բազայի դամփերը և տրանզակցիոն մատյանները պաշտպանելու համար դուք պետք է միացնեք Object Lock-ը բակետի (bucket) ստեղծման պահին:

Նախ, ստեղծեք բակետը՝ միացված Object Lock-ով.

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

Հաջորդիվ, կարգավորեք պահպանման լռելյայն քաղաքականությունը: Տվյալների բազայի արխիվների համար 30-օրյա համապատասխանության արգելափակումը ստանդարտ բազային մակարդակ է, որն ապահովում է մեկ ամսվա անփոփոխ պահուստային պատճեններ:

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

Երբ ձեր տվյալների բազայի պահուստավորման սկրիպտը կամ գործակալը ֆայլ է ուղարկում այս բակետ, S3-ը ավտոմատ կերպով հաշվարկում է Retain Until Date-ը՝ հիմնվելով օբյեկտի ստեղծման ժամանակի և 30 օրվա վրա:

2. Տեղային անփոփոխելիություն. ZFS և Linux ատրիբուտներ

Եթե դուք արխիվացնում եք տվյալների բազաները տեղային Linux պահուստային սերվերում, կարող եք հասնել կեղծ-անփոփոխելիության՝ օգտագործելով chattr հրամանը, կամ իրական անփոփոխելիության՝ օգտագործելով ZFS պատկերները (snapshots):

Օգտագործելով Linux chattr.
+i (immutable) դրոշը կանխում է ֆայլի փոփոխումը, ջնջումը կամ վերանվանումը:

# Տվյալների բազայի դամփ
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Պահուստային պատճենը դարձնել անփոփոխելի
sudo chattr +i /backups/mydb_$(date +%F).dump

# Ստուգել ատրիբուտը
lsattr /backups/mydb_$(date +%F).dump
# Արդյունք՝ ----i---------e------- /backups/mydb_2023-10-27.dump

Նշում. Թեև chattr-ը կանգնեցնում է հիմնական ransomware սկրիպտները, root հասանելիություն ունեցող բարդ հարձակվողը կարող է պարզապես գործարկել chattr -i: Հետևաբար, սա պետք է համակցվի խիստ RBAC-ի և մեկուսացված պահուստային ցանցերի հետ:

Օգտագործելով ZFS պատկերներ (snapshots).
ZFS-ն ապահովում է շատ ավելի ուժեղ պաշտպանություն: Պատկեր ստեղծելով և դրա վրա «պահում» (hold) դնելով՝ դուք կանխում եք պատկերի ոչնչացումը:

# Պահուստային տվյալների բազայի պատկերի ստեղծում
zfs snapshot tank/db_backups@archive_$(date +%F)

# Պատկերի վրա պահում դնել՝ ջնջումը կանխելու համար
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Նույնիսկ root-ը չի կարող ոչնչացնել այս պատկերը՝ առանց պահումը հանելու
zfs destroy tank/db_backups@archive_$(date +%F)
# Արդյունք՝ cannot destroy 'tank/db_backups@archive_...': dataset is busy

Տվյալների բազայի արխիվացման հատուկ ռազմավարություններ

Ժամանակի որոշակի կետում վերականգնման (PITR) հասնելու համար դուք պետք է շարունակաբար արխիվացնեք տրանզակցիոն մատյանները ձեր անփոփոխելի պահեստում:

PostgreSQL WAL արխիվացում pgBackRest-ով

pgBackRest-ը PostgreSQL-ի համար շատ հուսալի պահուստավորման գործիք է, որը բնիկ կերպով աջակցում է S3-համատեղելի պահեստավորմանը: Ձեր Write-Ahead Logs (WAL) ֆայլերը պաշտպանելու համար կարգավորեք pgBackRest-ը՝ ուղղակիորեն ձեր անփոփոխելի S3 բակետ ուղարկելու համար:

Ձեր 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

# Համոզվեք, որ պահպանման ժամկետը համապատասխանում է ձեր S3 Object Lock կոնֆիգուրացիային
repo1-retention-full=2
repo1-retention-archive=2

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

Կարևոր նկատառում. Եթե ձեր S3 բակետը կիրառում է 30-օրյա Համապատասխանության արգելափակում, բայց pgBackRest-ը փորձում է ժամկետանց դարձնել և ջնջել WAL ֆայլերը 14 օր հետո՝ հիմնվելով repo1-retention-archive-ի վրա, ջնջման API հարցումները կձախողվեն: Դուք պետք է համոզվեք, որ ձեր պահուստավորման ծրագրաշարի պահպանման քաղաքականությունը մեծ է կամ հավասար պահեստային մակարդակի անփոփոխելի արգելափակմանը:

Microsoft SQL Server. Պահուստավորում դեպի URL

SQL Server-ն աջակցում է բնիկ պահուստավորումներին ուղղակիորեն դեպի S3-համատեղելի օբյեկտային պահեստ: Դուք կարող եք կարգավորել SQL Server Agent-ի աշխատանքը՝ .bak և .trn ֆայլերը ուղղակիորեն անփոփոխելի բակետ գրելու համար:

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

Ավտոմատացում և համակարգում CloudSave-ի հետ

Անփոփոխելի պահպանման դրոշների կառավարումը, մուտքի բանալիների փոփոխումը և տվյալների բազայի պահպանման քաղաքականությունների ու պահեստային արգելափակումների միջև համաժամացման ապահովումը հատուկ սկրիպտների միջոցով շատ հակված է սխալների: Cron job-ում կամ API հարցման մեջ մեկ սխալ կարգավորումը կարող է ձեր արխիվները թողնել անպաշտպան կամ հանգեցնել ամպային պահեստավորման ծախսերի կտրուկ աճի՝ որբացած, արգելափակված օբյեկտների պատճառով:

CloudSave-ի նման ձեռնարկատիրական պահուստավորման հարթակները պարզեցնում են այս ճարտարապետությունը: CloudSave-ը բնիկ կերպով ինտեգրվում է AWS S3 Object Lock-ի, Azure Blob Immutable Storage-ի և տեղային S3-համատեղելի API-ների հետ:

CloudSave-ում տվյալների բազայի պահուստավորման պլան կարգավորելիս.
1. Հարթակը ավտոմատ կերպով կառավարում է VSS (Volume Shadow Copy Service) դադարեցումը SQL Server-ի համար կամ pg_start_backup() API-ն PostgreSQL-ի համար:
2. Այն հոսքով ուղարկում է դեդուպլիկացված, գաղտնագրված պահուստային տվյալները ուղղակիորեն դեպի պահեստային թիրախ:
3. CloudSave-ը դինամիկ կերպով կիրառում է WORM API հարցումները (օրինակ՝ PutObjectRetention) յուրաքանչյուր օբյեկտի համար՝ կատարելապես համապատասխանեցնելով պահեստային արգելափակման տևողությունը քաղաքականությամբ սահմանված պահպանման ժամանակացույցին:
4. Եթե հարձակվողը վտանգում է CloudSave կառավարման վահանակը, նրանք դեռ չեն կարող ջնջել պահուստային պատճենները, քանի որ համապատասխանության արգելափակումը կիրառվում է հիմքում ընկած պահեստային ենթակառուցվածքի, այլ ոչ թե պահուստավորման ծրագրաշարի կողմից:

Անփոփոխելի տվյալների բազայի արխիվների լավագույն փորձը

Համոզվելու համար, որ ձեր անփոփոխելի ճարտարապետությունը իսկապես կայուն է, հետևեք համակարգային ճարտարագիտության հետևյալ լավագույն փորձին.

1. NTP խիստ համաժամացում

Անփոփոխելի արգելափակումները մաթեմատիկորեն կապված են ժամանակային դրոշմների հետ: Եթե ձեր պահեստային զանգվածի կամ պահուստային սերվերի NTP (Network Time Protocol) ծառայությունը վտանգված է կամ շեղվում է, դա կարող է հանգեցնել արգելափակումների վաղաժամկետ ավարտին կամ ընդհանրապես չավարտվելուն: Համոզվեք, որ ձեր պահեստային ենթակառուցվածքն օգտագործում է վավերացված, ավելորդ NTP աղբյուրներ:

2. IAM դերերի և հավատարմագրերի մեկուսացում

Անփոփոխելի բակետ գրելու համար օգտագործվող հավատարմագրերը պետք է ունենան միայն s3:PutObject և s3:PutObjectRetention թույլտվություններ: Դրանք երբեք չպետք է ունենան s3:DeleteObject կամ s3:PutBucketObjectLockConfiguration թույլտվություններ:

Տվյալների բազայի պահուստավորման գործակալի համար նվազագույն արտոնությունների IAM քաղաքականության օրինակ.

{
    "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. Պահպանման ժամկետի չափորոշում

Մի սահմանեք համապատասխանության արգելափակումներ չափազանց երկար ժամանակով (օրինակ՝ 7 տարի համապատասխանության համար) ձեր հիմնական արագ վերականգնման շերտում: Տվյալների բազաները գեներացնում են WAL/տրանզակցիոն մատյանների հսկայական քանակություն: Այս տվյալների տարիներով արգելափակումը կհանգեցնի պահեստավորման ծախսերի էքսպոնենցիալ աճի:
Փոխարենը, օգտագործեք շերտավոր մոտեցում.
* Գործառնական վերականգնման շերտ. 14-ից 30 օր անփոփոխելի պահպանում լրիվ և մատյանների համար:
* Երկարաժամկետ արխիվացման շերտ. Ամսական լրիվ պահուստային պատճեններ, որոնք տեղափոխվում են Glacier/Deep Archive՝ Vault Lock-ով 1-7 տարի ժամկետով:

4. Կանոնավոր վերականգնման թեստավորում օդային բացակայությամբ (air-gapped) VPC-ներում

Անփոփոխելիությունը երաշխավորում է, որ տվյալները չեն կարող ջնջվել, բայց այն չի երաշխավորում, որ տվյալները զերծ են տրամաբանական կոռուպցիայից: Դուք պետք է ավտոմատացնեք ձեր անփոփոխելի տվյալների բազայի արխիվների վերականգնումը մեկուսացված, air-gapped VPC կամ VLAN միջավայրում: Գործարկեք DBCC CHECKDB (SQL Server) կամ pg_amcheck (PostgreSQL) վերականգնված տվյալների վրա՝ կառուցվածքային ամբողջականությունը ստուգելու համար:

Եզրակացություն

Ransomware-ի պաշտպանությունը ենթադրյալ խախտման վարժություն է: Այն պահին, երբ ձեր SIEM-ում ահազանգ է հնչում, սպառնալիքի դերակատարները, հավանաբար, արդեն փորձել են վտանգել ձեր պահուստային ենթակառուցվածքը: Ձեր տվյալների բազայի արխիվները նախագծելով անփոփոխելի պահեստավորման միջոցով Համապատասխանության ռեժիմում՝ դուք հարձակվողներին զրկում եք նրանց հիմնական լծակներից: Անկախ նրանից, թե դուք օգտագործում եք բնիկ ամպային API-ներ, ZFS պահումներ (holds), թե CloudSave-ի նման ձեռնարկատիրական համակարգման հարթակ, WORM պահեստավորման իրականացումն այլևս ընտրովի չէ. այն տվյալների բազայի ժամանակակից կառավարման և աղետներից վերականգնման պարտադիր հիմնասյուն է: