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.

Орчин үеийн аюул заналхийллийн орчинд ransomware буюу барьцаалагч вирус нь боломж олдсон үед өгөгдлийг шифрлэхээс эхлээд өндөр зорилтот, олон талт дарамт шахалт үзүүлэх кампанит ажил болон хувирчээ. Дэвшилтэт байнгын аюул заналхийлэл (APT) болон ransomware бүлэглэлүүд одоо өгөгдлийн сангийн нөөц хуулбар (backup) болон архивыг идэвхтэй хайж байна. Хэрэв халдагч таны үндсэн өгөгдлийн санг эвдэж, нэгэн зэрэг нөөц хуулбарын агуулахыг устгах эсвэл шифрлэх юм бол танай байгууллага өгөгдлийн гамшигт алдагдалтай нүүр тулах болно.

Өгөгдлийн сангийн администраторууд (DBA) болон DevOps инженерүүдийн хувьд уламжлалт 3-2-1 нөөцлөлтийн стратеги хангалтгүй болсон. Өгөгдлийн аюулгүй байдлыг хангахын тулд дэд бүтцийн багууд 3-2-1-1 дүрмийг баримтлах ёстой бөгөөд энд байгаа сүүлийн “1” нь өөрчлөгдөшгүй хадгалах сан (immutable storage)-ийг илэрхийлнэ.

Энэхүү нийтлэл нь ransomware-ийн эсрэг үнэмлэхүй тэсвэрлэх чадварыг хангахын тулд өгөгдлийн сангийн архивыг өөрчлөгдөшгүй хадгалах санд зохион байгуулах, хэрэгжүүлэх, удирдах талаар техникийн гүнзгий ойлголтыг өгөх болно.

Өөрчлөгдөшгүй хадгалах сангийн механизм

Өөрчлөгдөшгүй хадгалах сан нь “Нэг удаа бичиж, олон удаа унших” (WORM) архитектур дээр суурилдаг. Өгөгдлийг өөрчлөгдөшгүй зорилтот санд бичсэний дараа, математикийн аргаар тогтоосон хугацаа дуусах хүртэл root эрхтэй администраторууд эсвэл эвдэрсэн үйлчилгээний бүртгэлүүд ч үүнийг өөрчлөх, шифрлэх, устгах боломжгүй.

Нийцлийн горим (Compliance Mode) vs. Удирдлагын горим (Governance Mode)

Ялангуяа AWS S3, Azure Blob эсвэл S3-тэй нийцтэй дотоод SAN зэрэг үүлэн объектын хадгалах санд өөрчлөгдөхгүй байдлыг хэрэгжүүлэхдээ хадгалах горимуудын ялгааг ойлгох хэрэгтэй:

  • Удирдлагын горим (Governance Mode): Энгийн хэрэглэгчдийг объектыг устгах эсвэл өөрчлөхөөс сэргийлнэ. Гэсэн хэдий ч, тодорхой IAM зөвшөөрөлтэй хэрэглэгчид (жишээ нь, s3:BypassGovernanceRetention) түгжээг тойрч гарах боломжтой. Энэ нь туршилт хийхэд хэрэгтэй боловч ransomware-ээс хамгаалахад хангалтгүй, учир нь халдагчид ихэвчлэн эрхээ өсгөж, домэйны администратор эсвэл root эрхтэй болдог.
  • Нийцлийн горим (Compliance Mode): Ransomware-ийн эсрэг хамгаалалтын алтан стандарт. Объект нийцлийн горимд түгжигдсэний дараа түүний хадгалах хугацааг богиносгох боломжгүй бөгөөд AWS root бүртгэлийг оролцуулаад хэн ч объектыг устгах боломжгүй. Түгжээ нь хадгалах кластерийн түвшинд хэрэгждэг.

Өөрчлөгдөшгүй нөөцлөлтийн дамжуулах хоолойг зохион байгуулах

Өгөгдлийн сангийн бат бөх архивын архитектур нь идэвхтэй өгөгдлийн сангийн үйл ажиллагааг өөрчлөгдөшгүй архивын түвшнээс тусгаарладаг. Та идэвхтэй өгөгдлийн сангийн файлуудад (SQL Server дээрх .mdf/.ldf эсвэл PostgreSQL дээрх pg_data лавлах гэх мэт) өөрчлөгдөхгүй байдлыг хэрэглэж болохгүй, учир нь өгөгдлийн сангууд байнга унших/бичих хандалт шаарддаг.

Үүний оронд өөрчлөгдөхгүй байдлыг дараах зүйлсэд хэрэглэнэ:
1. Бүрэн болон ялгавартай нөөцлөлтийн файлууд: Өгөгдлийн сангийн үндсэн агшин зуурын зураг (snapshots).
2. Гүйлгээний бүртгэлүүд / WAL файлууд: Цаг хугацааны цэг дээр сэргээхэд (PITR) шаардлагатай өгөгдлийн сангийн өөрчлөлтийн тасралтгүй урсгал.

Өөрчлөгдөхгүй байдалд зориулсан хадгалах сангууд

Та өөрчлөгдөшгүй хадгалах санг дэд бүтцийн янз бүрийн түвшинд хэрэгжүүлж болно:
* Үүлэн объектын хадгалах сан: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Дотоод объектын хадгалах сан: S3 Object Lock API-г дэмждэг MinIO, Cloudian эсвэл Pure Storage FlashBlade.
* Блок/Файл хадгалах сан: Зөвхөн унших боломжтой агшин зуурын зураг (snapshots) болон төлөөлөн удирдах эрх бүхий ZFS, эсвэл Linux файлын шинж чанарууд.

Өөрчлөгдөшгүй хадгалах санг хэрэгжүүлэх: Техникийн алхам алхмаар заавар

1. Үүлэн объектын хадгалах сан: AWS S3 Object Lock

AWS дээр өгөгдлийн сангийн дампуу (dumps) болон гүйлгээний бүртгэлүүдийг хамгаалахын тулд та bucket үүсгэх үед Object Lock-ийг идэвхжүүлэх ёстой.

Эхлээд Object Lock идэвхжүүлсэн bucket үүсгэнэ:

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
            }
        }
    }'

Таны өгөгдлийн сангийн нөөцлөлтийн скрипт эсвэл агент энэ bucket руу файл илгээх үед S3 нь объектыг үүсгэсэн цагийн тэмдэг дээр 30 хоногийг нэмж Retain Until Date-ийг автоматаар тооцдог.

2. Дотоод өөрчлөгдөхгүй байдал: ZFS болон Linux шинж чанарууд

Хэрэв та өгөгдлийн санг дотоод Linux нөөцлөлтийн сервер рүү архивлаж байгаа бол chattr командыг ашиглан хуурамч өөрчлөгдөхгүй байдлыг, эсвэл ZFS агшин зуурын зургийг ашиглан жинхэнэ өөрчлөгдөхгүй байдлыг олж авах боломжтой.

Linux chattr ашиглах нь:
+i (immutable) туг нь файлыг өөрчлөх, устгах эсвэл нэрийг нь өөрчлөхөөс сэргийлдэг.

# Өгөгдлийн санг dump хийх
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)

# Устгахаас сэргийлэхийн тулд агшин зуурын зурагт hold тавих
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Root хэрэглэгч ч hold-ийг чөлөөлөхгүйгээр энэ агшин зуурын зургийг устгаж чадахгүй
zfs destroy tank/db_backups@archive_$(date +%F)
# Гаралт: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Өгөгдлийн санд зориулсан архивлалтын стратеги

Цаг хугацааны цэг дээр сэргээх (PITR) боломжтой байхын тулд та гүйлгээний бүртгэлүүдийг өөрчлөгдөшгүй хадгалах сан руугаа тасралтгүй архивлаж байх ёстой.

pgBackRest ашиглан PostgreSQL WAL архивлалт

pgBackRest нь S3-тэй нийцтэй хадгалах санг дэмждэг PostgreSQL-д зориулсан маш найдвартай нөөцлөлтийн хэрэгсэл юм. Write-Ahead Logs (WAL)-аа хамгаалахын тулд pgBackRest-ийг өөрчлөгдөшгүй S3 bucket руу шууд илгээхээр тохируулна уу.

Таны 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 bucket 30 хоногийн нийцлийн түгжээг шаарддаг боловч pgBackRest нь repo1-retention-archive-д үндэслэн 14 хоногийн дараа WAL файлуудыг устгахыг оролдвол устгах API дуудлага амжилтгүй болно. Та нөөцлөлтийн програм хангамжийн хадгалах бодлого нь хадгалах сангийн түвшний өөрчлөгдөшгүй түгжээнээс их буюу тэнцүү байхыг баталгаажуулах ёстой.

Microsoft SQL Server: URL руу нөөцлөх

SQL Server нь S3-тэй нийцтэй объектын хадгалах сан руу шууд нөөцлөхийг дэмждэг. Та SQL Server Agent ажлыг тохируулж .bak болон .trn файлуудыг өөрчлөгдөшгүй 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

CloudSave ашиглан автоматжуулалт болон зохион байгуулалт

Өөрчлөгдөшгүй хадгалах тугуудыг удирдах, хандалтын түлхүүрүүдийг эргүүлэх, өгөгдлийн сангийн хадгалах бодлого болон хадгалах сангийн түгжээг тусгай скриптүүдээр дамжуулан синхрончлох нь алдаа гаргах өндөр эрсдэлтэй. Cron ажил эсвэл API дуудлагад гарсан ганцхан буруу тохиргоо нь таны архивыг ил болгох эсвэл түгжигдсэн, эзэнгүй объектуудаас болж үүлэн хадгалах сангийн зардлыг огцом өсгөхөд хүргэж болзошгүй.

CloudSave гэх мэт байгууллагын нөөцлөлтийн платформууд энэ архитектурыг хялбаршуулдаг. CloudSave нь AWS S3 Object Lock, Azure Blob Immutable Storage болон дотоод S3-тэй нийцтэй API-уудтай шууд нэгддэг.

CloudSave-д өгөгдлийн сангийн нөөцлөлтийн төлөвлөгөөг тохируулахдаа:
1. Платформ нь SQL Server-д зориулсан VSS (Volume Shadow Copy Service) эсвэл PostgreSQL-д зориулсан pg_start_backup() API-г автоматаар зохицуулдаг.
2. Энэ нь давхардалгүй, шифрлэгдсэн нөөцлөлтийн өгөгдлийг хадгалах зорилтот сан руу шууд дамжуулдаг.
3. CloudSave нь WORM API дуудлагыг (жишээ нь, PutObjectRetention) объект тус бүр дээр динамикаар хэрэгжүүлж, хадгалах сангийн түгжээний хугацааг бодлогоор тодорхойлсон хадгалах хуваарьтай төгс нийцүүлдэг.
4. Хэрэв халдагч CloudSave удирдлагын консолыг эвдсэн ч гэсэн нөөцлөлтийг устгаж чадахгүй, учир нь нийцлийн түгжээг нөөцлөлтийн програм хангамж биш, харин доод түвшний хадгалах дэд бүтэц хэрэгжүүлдэг.

Өөрчлөгдөшгүй өгөгдлийн сангийн архивын шилдэг туршлагууд

Таны өөрчлөгдөшгүй архитектур үнэхээр тэсвэртэй байхын тулд системийн инженерийн дараах шилдэг туршлагуудыг дагаж мөрдөөрэй:

1. NTP синхрончлолыг чанд мөрдөх

Өөрчлөгдөшгүй түгжээнүүд нь цагийн тэмдэгтэй математикийн хувьд холбоотой байдаг. Хэрэв таны хадгалах массив эсвэл нөөцлөлтийн сервер дээрх NTP (Network Time Protocol) үйлчилгээ эвдэрсэн эсвэл гажуудсан бол энэ нь түгжээг хугацаанаас нь өмнө дуусгах эсвэл огт дуусгахгүй байхад хүргэж болзошгүй. Таны хадгалах дэд бүтэц баталгаажсан, нөөц NTP эх сурвалжуудыг ашиглаж байгаа эсэхийг шалгаарай.

2. IAM үүрэг болон итгэмжлэлүүдийг тусгаарлах

Өөрчлөгдөшгүй bucket руу бичихэд ашигладаг итгэмжлэлүүд нь зөвхөн 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 хоногийн өөрчлөгдөшгүй хадгалалт.
* Урт хугацааны архивын түвшин: 1-7 жилийн турш Vault Lock-той Glacier/Deep Archive руу шилжүүлсэн сарын бүрэн нөөцлөлтүүд.

4. Air-Gapped VPC-д тогтмол сэргээлтийн туршилт хийх

Өөрчлөгдөхгүй байдал нь өгөгдлийг устгах боломжгүй гэдгийг баталгаажуулдаг боловч өгөгдөл нь логик гэмтэлгүй гэдгийг баталгаажуулдаггүй. Та өөрчлөгдөшгүй өгөгдлийн сангийн архиваа тусгаарлагдсан, air-gapped VPC эсвэл VLAN руу автоматаар сэргээх ёстой. Сэргээгдсэн өгөгдлийн бүтцийн бүрэн бүтэн байдлыг шалгахын тулд DBCC CHECKDB (SQL Server) эсвэл pg_amcheck (PostgreSQL)-ийг ажиллуулна уу.

Дүгнэлт

Ransomware-ийн эсрэг хамгаалалт бол халдлагад өртсөн гэж үзэх дасгал юм. Таны SIEM-д сэрэмжлүүлэг ирэх үед халдагчид таны нөөцлөлтийн дэд бүтцийг аль хэдийн эвдэхийг оролдсон байх магадлалтай. Өгөгдлийн сангийн архиваа нийцлийн горимд (Compliance Mode) өөрчлөгдөшгүй хадгалах санг ашиглан зохион байгуулснаар та халдагчдын гол хөшүүргийг үгүй хийнэ. Та үүлэн API, ZFS hold, эсвэл CloudSave гэх мэт байгууллагын зохион байгуулалтын платформыг ашигладаг эсэхээс үл хамааран WORM хадгалах санг хэрэгжүүлэх нь сонголт биш, харин орчин үеийн өгөгдлийн сангийн удирдлага болон гамшгаас сэргээх үйл ажиллагааны заавал байх ёстой тулгуур багана юм.

Ангилал