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üasir təhdid mühitində ransomware (fidyə proqramları) fürsətçi şifrələmədən yüksək hədəfli, çoxşaxəli şantaj kampaniyalarına çevrilmişdir. Qabaqcıl Davamlı Təhdidlər (APT) və ransomware sindikatları artıq sistemdə olduqları müddət ərzində aktiv şəkildə ehtiyat nüsxə infrastrukturu və verilənlər bazası arxivlərini axtarırlar. Əgər bir hücumçu əsas verilənlər bazanızı ələ keçirərsə və eyni zamanda ehtiyat nüsxə anbarlarınızı silə və ya şifrələyərsə, təşkilatınız fəlakətli məlumat itkisi ilə üzləşəcək.

Verilənlər Bazası İnzibatçıları (DBA) və DevOps mühəndisləri üçün ənənəvi 3-2-1 ehtiyat nüsxə strategiyası artıq kifayət deyil. Məlumatların sağ qalmasını təmin etmək üçün infrastruktur komandaları 3-2-1-1 qaydasını tətbiq etməlidirlər, burada sonuncu “1” dəyişməz (immutable) yaddaşı təmsil edir.

Bu məqalə, mütləq ransomware dayanıqlılığını təmin etmək üçün verilənlər bazası arxivləri üçün dəyişməz yaddaşın layihələndirilməsi, tətbiqi və idarə olunması haqqında hərtərəfli, texniki bir bələdçidir.

Dəyişməz Yaddaşın Mexanikası

Dəyişməz yaddaş, “Bir dəfə yaz, çox oxu” (WORM) arxitekturasına əsaslanır. Məlumat dəyişməz bir hədəfə yazıldıqdan sonra, riyazi olaraq tətbiq olunan vaxt kilidi bitənə qədər heç bir istifadəçi, o cümlədən root imtiyazlarına malik inzibatçılar və ya ələ keçirilmiş xidmət hesabları tərəfindən dəyişdirilə, şifrələnə və ya silinə bilməz.

Uyğunluq Rejimi (Compliance Mode) və İdarəetmə Rejimi (Governance Mode)

Xüsusilə AWS S3, Azure Blob və ya S3-uyğun yerli SAN-lar kimi bulud obyekt yaddaşında dəyişməzliyi tətbiq edərkən, saxlama rejimləri arasındakı fərqi başa düşməlisiniz:

  • İdarəetmə Rejimi (Governance Mode): Standart istifadəçilərin obyektləri silməsinin və ya dəyişməsinin qarşısını alır. Bununla belə, xüsusi IAM icazələrinə malik istifadəçilər (məsələn, s3:BypassGovernanceRetention) kilidi ləğv edə bilərlər. Bu, sınaq üçün faydalıdır, lakin ransomware müdafiəsi üçün kifayət deyil, çünki hücumçular tez-tez imtiyazlarını domen admini və ya root səviyyəsinə qədər yüksəldirlər.
  • Uyğunluq Rejimi (Compliance Mode): Ransomware müdafiəsi üçün qızıl standartdır. Bir obyekt Uyğunluq Rejimində kilidləndikdən sonra, onun saxlama müddəti qısaldıla bilməz və obyekt AWS root hesabı daxil olmaqla heç kim tərəfindən silinə bilməz. Kilid yaddaş klasteri səviyyəsində tətbiq edilir.

Dəyişməz Ehtiyat Nüsxə Boru Kəmərinin Layihələndirilməsi

Güclü verilənlər bazası arxivləşdirmə arxitekturası aktiv verilənlər bazası əməliyyatlarını dəyişməz arxiv səviyyəsindən ayırır. Siz aktiv verilənlər bazası fayllarına (SQL Server-də .mdf/.ldf və ya PostgreSQL-də pg_data qovluğu kimi) dəyişməzliyi tətbiq edə bilməzsiniz, çünki verilənlər bazaları daimi oxuma/yazma girişi tələb edir.

Bunun əvəzinə, dəyişməzlik aşağıdakılara tətbiq olunur:
1. Tam və Diferensial Ehtiyat Nüsxə Faylları: Verilənlər bazasının baza snapshotları.
2. Tranzaksiya Jurnalları / WAL Faylları: Müəyyən bir vaxta bərpa (PITR) üçün tələb olunan daimi verilənlər bazası dəyişiklikləri axını.

Dəyişməzlik üçün Yaddaş Hədəfləri

Dəyişməz yaddaşı müxtəlif infrastruktur səviyyələrində tətbiq edə bilərsiniz:
* Bulud Obyekt Yaddaşı: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Yerli Obyekt Yaddaşı: S3 Object Lock API-lərini dəstəkləyən MinIO, Cloudian və ya Pure Storage FlashBlade.
* Blok/Fayl Yaddaşı: Yalnız oxuna bilən snapshotlar və nümayəndəli idarəetmə ilə ZFS və ya Linux fayl atributları.

Dəyişməz Yaddaşın Tətbiqi: Texniki İzahlar

1. Bulud Obyekt Yaddaşı: AWS S3 Object Lock

AWS-də verilənlər bazası dump-larını və tranzaksiya jurnallarını qorumaq üçün bucket yaradılarkən Object Lock-u aktivləşdirməlisiniz.

Əvvəlcə, Object Lock aktivləşdirilmiş bucket-i yaradın:

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

Daha sonra, standart saxlama siyasətini konfiqurasiya edin. Verilənlər bazası arxivləri üçün 30 günlük uyğunluq kilidi standart bir bazadır və bir aylıq dəyişdirilə bilməyən ehtiyat nüsxələrinizə sahib olmağınızı təmin edir.

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

Verilənlər bazası ehtiyat nüsxə skriptiniz və ya agentiniz bu bucket-ə fayl göndərdikdə, S3 avtomatik olaraq obyektin yaradılma vaxtı üstəgəl 30 gün əsasında Retain Until Date (Saxlama Tarixi) hesablayır.

2. Yerli Dəyişməzlik: ZFS və Linux Atributları

Əgər verilənlər bazalarını yerli Linux ehtiyat nüsxə serverinə arxivləşdirirsinizsə, chattr əmri ilə psevdo-dəyişməzliyə və ya ZFS snapshotları ilə əsl dəyişməzliyə nail ola bilərsiniz.

Linux chattr istifadə edərək:
+i (immutable) bayrağı faylın dəyişdirilməsinin, silinməsinin və ya adının dəyişdirilməsinin qarşısını alır.

# Verilənlər bazasını dump edin
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Ehtiyat nüsxəni dəyişməz edin
sudo chattr +i /backups/mydb_$(date +%F).dump

# Atributu yoxlayın
lsattr /backups/mydb_$(date +%F).dump
# Çıxış: ----i---------e------- /backups/mydb_2023-10-27.dump

Qeyd: chattr əsas ransomware skriptlərini dayandırsa da, root girişinə malik təcrübəli bir hücumçu sadəcə chattr -i əmrini işlədə bilər. Buna görə də, bu, ciddi RBAC və təcrid olunmuş ehtiyat nüsxə şəbəkələri ilə birləşdirilməlidir.

ZFS Snapshotlarından istifadə edərək:
ZFS daha güclü müdafiə təmin edir. Snapshot alaraq və ona “hold” (saxlama) qoyaraq, snapshotun silinməsinin qarşısını alırsınız.

# Ehtiyat nüsxə verilənlər dəstinin snapshotunu alın
zfs snapshot tank/db_backups@archive_$(date +%F)

# Silinmənin qarşısını almaq üçün snapshot-a hold qoyun
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Hətta root belə hold-u buraxmadan bu snapshotu silə bilməz
zfs destroy tank/db_backups@archive_$(date +%F)
# Çıxış: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Verilənlər Bazasına Xüsusi Arxivləşdirmə Strategiyaları

Müəyyən bir vaxta bərpa (PITR) üçün tranzaksiya jurnallarını dəyişməz yaddaşınıza davamlı olaraq arxivləşdirməlisiniz.

pgBackRest ilə PostgreSQL WAL Arxivləşdirməsi

pgBackRest, S3-uyğun yaddaşı yerli olaraq dəstəkləyən, PostgreSQL üçün yüksək etibarlı ehtiyat nüsxə vasitəsidir. Write-Ahead Logs (WAL) fayllarınızı qorumaq üçün pgBackRest-i birbaşa dəyişməz S3 bucket-inizə göndərəcək şəkildə konfiqurasiya edin.

pgbackrest.conf faylınızda:

[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

# Saxlama müddətinin S3 Object Lock konfiqurasiyanızla uyğun olduğundan əmin olun
repo1-retention-full=2
repo1-retention-archive=2

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

Vacib Qeyd: Əgər S3 bucket-iniz 30 günlük Uyğunluq kilidi tətbiq edirsə, lakin pgBackRest repo1-retention-archive əsasında 14 gündən sonra WAL fayllarını silməyə çalışırsa, silmə API çağırışları uğursuz olacaq. Ehtiyat nüsxə proqramınızın saxlama siyasətinin yaddaş səviyyəsindəki dəyişməz kilidə bərabər və ya ondan böyük olduğundan əmin olmalısınız.

Microsoft SQL Server: URL-ə Ehtiyat Nüsxə

SQL Server birbaşa S3-uyğun obyekt yaddaşına ehtiyat nüsxələri dəstəkləyir. SQL Server Agent işini .bak və .trn fayllarını birbaşa dəyişməz bucket-ə yazacaq şəkildə konfiqurasiya edə bilərsiniz.

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 ilə Avtomatlaşdırma və Orkestrləmə

Dəyişməz saxlama bayraqlarını idarə etmək, giriş açarlarını dəyişdirmək və xüsusi skriptlər vasitəsilə verilənlər bazası saxlama siyasətləri ilə yaddaş kilidləri arasında sinxronizasiyanı təmin etmək yüksək dərəcədə səhvə meyillidir. Cron işində və ya API çağırışında edilən tək bir səhv konfiqurasiya arxivlərinizi açıq qoya bilər və ya sahibsiz, kilidli obyektlər səbəbindən bulud yaddaşı xərclərinin kəskin artmasına səbəb ola bilər.

CloudSave kimi müəssisə ehtiyat nüsxə platformaları bu arxitekturanı sadələşdirir. CloudSave AWS S3 Object Lock, Azure Blob Immutable Storage və yerli S3-uyğun API-lərlə yerli olaraq inteqrasiya olunur.

CloudSave-də verilənlər bazası ehtiyat nüsxə planını konfiqurasiya edərkən:
1. Platforma avtomatik olaraq SQL Server üçün VSS (Volume Shadow Copy Service) və ya PostgreSQL üçün pg_start_backup() API-ni idarə edir.
2. Deduplikasiya edilmiş, şifrələnmiş ehtiyat nüsxə məlumatlarını birbaşa yaddaş hədəfinə ötürür.
3. CloudSave dinamik olaraq WORM API çağırışlarını (məsələn, PutObjectRetention) hər obyekt üçün tətbiq edir və yaddaş kilidinin müddətini siyasətlə müəyyən edilmiş saxlama cədvəli ilə mükəmməl şəkildə uyğunlaşdırır.
4. Əgər hücumçu CloudSave idarəetmə konsolunu ələ keçirərsə, onlar yenə də ehtiyat nüsxələri silə bilməzlər, çünki uyğunluq kilidi ehtiyat nüsxə proqramı tərəfindən deyil, altda yatan yaddaş infrastrukturu tərəfindən tətbiq edilir.

Dəyişməz Verilənlər Bazası Arxivləri üçün Ən Yaxşı Təcrübələr

Dəyişməz arxitekturanızın həqiqətən dayanıqlı olduğundan əmin olmaq üçün aşağıdakı sistem mühəndisliyi ən yaxşı təcrübələrinə riayət edin:

1. Ciddi NTP Sinxronizasiyası

Dəyişməz kilidlər riyazi olaraq zaman damğalarına bağlıdır. Əgər yaddaş massivinizdə və ya ehtiyat nüsxə serverinizdə NTP (Network Time Protocol) xidməti ələ keçirilərsə və ya sürüşərsə, bu, kilidlərin vaxtından əvvəl bitməsinə və ya heç vaxt bitməməsinə səbəb ola bilər. Yaddaş infrastrukturunuzun autentifikasiya edilmiş, artıq NTP mənbələrindən istifadə etdiyinə əmin olun.

2. IAM Rollarını və Etimadnamələrini Təcrid edin

Dəyişməz bucket-ə yazmaq üçün istifadə olunan etimadnamələr yalnız s3:PutObject və s3:PutObjectRetention icazələrinə malik olmalıdır. Onların heç vaxt s3:DeleteObject və ya s3:PutBucketObjectLockConfiguration icazələri olmamalıdır.

Verilənlər bazası ehtiyat nüsxə agenti üçün ən az imtiyazlı IAM siyasəti nümunəsi:

{
    "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. Saxlama Müddətinin Ölçülməsi

Əsas sürətli bərpa səviyyənizdə uyğunluq kilidlərini həddindən artıq uzun müddətə (məsələn, uyğunluq üçün 7 il) təyin etməyin. Verilənlər bazaları böyük miqdarda WAL/tranzaksiya jurnalı məlumatları yaradır. Bu məlumatları illərlə kilidləmək yaddaş xərclərinin eksponensial artmasına səbəb olacaq.
Bunun əvəzinə, pilləli bir yanaşmadan istifadə edin:
* Əməliyyat Bərpası Səviyyəsi: Tam nüsxələr və jurnallar üçün 14-30 günlük dəyişməz saxlama.
* Uzunmüddətli Arxiv Səviyyəsi: 1-7 il müddətinə Vault Lock ilə Glacier/Deep Archive-ə köçürülən aylıq tam ehtiyat nüsxələr.

4. Hava boşluğu olan (Air-Gapped) VPC-lərdə Müntəzəm Bərpa Sınaqları

Dəyişməzlik məlumatların silinə bilməyəcəyinə zəmanət verir, lakin məlumatların məntiqi korrupsiyadan azad olduğuna zəmanət vermir. Dəyişməz verilənlər bazası arxivlərinizin bərpasını təcrid olunmuş, hava boşluğu olan VPC və ya VLAN-a avtomatlaşdırmalısınız. Struktur bütövlüyünü yoxlamaq üçün bərpa edilmiş məlumatlar üzərində DBCC CHECKDB (SQL Server) və ya pg_amcheck (PostgreSQL) işlədin.

Nəticə

Ransomware müdafiəsi, pozuntunun baş verdiyini qəbul etmək məşqidir. SIEM-inizdə xəbərdarlıq işə düşənə qədər, təhdid aktorları çox güman ki, artıq ehtiyat nüsxə infrastrukturunuzu ələ keçirməyə çalışıblar. Verilənlər bazası arxivlərinizi Uyğunluq Rejimində dəyişməz yaddaşdan istifadə edərək layihələndirməklə, siz hücumçuları əsas rıçaqlarından məhrum edirsiniz. İstər yerli bulud API-lərindən, ZFS hold-larından, istərsə də CloudSave kimi müəssisə orkestrləmə platformasından istifadə etməyinizdən asılı olmayaraq, WORM yaddaşını tətbiq etmək artıq seçim deyil—bu, müasir verilənlər bazası idarəetməsi və fəlakətdən bərpa üçün məcburi bir sütundur.

Kateqoriyalar