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.

Modern tehdit ortamında fidye yazılımları, fırsatçı şifreleme yöntemlerinden oldukça hedef odaklı, çoklu gasp kampanyalarına evrilmiştir. Gelişmiş Kalıcı Tehditler (APT’ler) ve fidye yazılımı sendikaları, sistemde kaldıkları süre boyunca artık aktif olarak yedekleme altyapısını ve veritabanı arşivlerini avlamaktadır. Bir saldırgan birincil veritabanınızı ele geçirir ve aynı anda yedekleme depolarınızı siler veya şifrelerse, kuruluşunuz felaket boyutunda bir veri kaybıyla karşı karşıya kalır.

Veritabanı Yöneticileri (DBA’lar) ve DevOps mühendisleri için geleneksel 3-2-1 yedekleme stratejisi artık yeterli değildir. Veri sürekliliğini garanti altına almak için altyapı ekipleri, son “1”in değiştirilemez (immutable) depolamayı temsil ettiği 3-2-1-1 kuralını benimsemelidir.

Bu makale, mutlak fidye yazılımı dayanıklılığı sağlamak amacıyla veritabanı arşivleri için değiştirilemez depolama mimarisinin oluşturulması, uygulanması ve yönetilmesi konusunda kapsamlı, teknik bir derinlemesine inceleme sunmaktadır.

Değiştirilemez Depolamanın Mekanizması

Değiştirilemez depolama, Yaz-Bir-Oku-Çok (WORM) mimarisine dayanır. Veriler değiştirilemez bir hedefe yazıldığında, matematiksel olarak uygulanan bir zaman kilidi dolana kadar kök (root) ayrıcalıklarına sahip yöneticiler veya ele geçirilmiş hizmet hesapları dahil olmak üzere hiçbir kullanıcı tarafından değiştirilemez, şifrelenemez veya silinemez.

Uyumluluk Modu vs. Yönetişim Modu

Özellikle AWS S3, Azure Blob veya S3 uyumlu şirket içi SAN’lar gibi bulut nesne depolama birimlerinde değiştirilemezliği uygularken, saklama modları arasındaki farkı anlamanız gerekir:

  • Yönetişim Modu (Governance Mode): Standart kullanıcıların nesneleri silmesini veya değiştirmesini engeller. Ancak, belirli IAM izinlerine (örneğin s3:BypassGovernanceRetention) sahip kullanıcılar kilidi geçersiz kılabilir. Bu, test işlemleri için yararlıdır ancak saldırganlar genellikle ayrıcalıklarını etki alanı yöneticisi veya kök kullanıcı seviyesine yükselttikleri için fidye yazılımı koruması için yetersizdir.
  • Uyumluluk Modu (Compliance Mode): Fidye yazılımı savunması için altın standarttır. Bir nesne Uyumluluk Modunda kilitlendiğinde, saklama süresi kısaltılamaz ve nesne, AWS kök hesabı dahil hiç kimse tarafından silinemez. Kilit, depolama kümesi düzeyinde uygulanır.

Değiştirilemez Bir Yedekleme Hattı Mimari Tasarımı

Güçlü bir veritabanı arşivleme mimarisi, aktif veritabanı işlemlerini değiştirilemez arşiv katmanından ayırır. Veritabanları sürekli okuma/yazma erişimi gerektirdiğinden, değiştirilemezliği aktif veritabanı dosyalarına (SQL Server’daki .mdf/.ldf veya PostgreSQL’deki pg_data dizini gibi) uygulayamazsınız.

Bunun yerine, değiştirilemezlik şunlara uygulanır:
1. Tam ve Diferansiyel Yedekleme Dosyaları: Veritabanının temel anlık görüntüleri.
2. İşlem Günlükleri / WAL Dosyaları: Belirli Bir Zamana Geri Dönüş (PITR) için gereken sürekli veritabanı değişiklik akışı.

Değiştirilemezlik için Depolama Hedefleri

Değiştirilemez depolamayı farklı altyapı katmanlarında uygulayabilirsiniz:
* Bulut Nesne Depolama: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Saklama Politikaları.
* Şirket İçi Nesne Depolama: S3 Object Lock API’lerini destekleyen MinIO, Cloudian veya Pure Storage FlashBlade.
* Blok/Dosya Depolama: Salt okunur anlık görüntülere ve yetkilendirilmiş yönetime sahip ZFS veya Linux dosya öznitelikleri.

Değiştirilemez Depolama Uygulama: Teknik İzlenecek Yollar

1. Bulut Nesne Depolama: AWS S3 Object Lock

Veritabanı dökümlerini ve işlem günlüklerini AWS’de korumak için, kova (bucket) oluşturma sırasında Object Lock’u etkinleştirmeniz gerekir.

Öncelikle, Object Lock etkinleştirilmiş kovayı oluşturun:

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

Ardından, varsayılan saklama politikasını yapılandırın. Veritabanı arşivleri için 30 günlük bir uyumluluk kilidi, bir aylık değiştirilemez yedeğinizin olmasını sağlayan standart bir temeldir.

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

Veritabanı yedekleme betiğiniz veya aracınız bu kovaya bir dosya gönderdiğinde, S3 otomatik olarak nesne oluşturma zaman damgasına 30 gün ekleyerek Retain Until Date (Şu Tarihe Kadar Sakla) değerini hesaplar.

2. Şirket İçi Değiştirilemezlik: ZFS ve Linux Öznitelikleri

Veritabanlarını şirket içi bir Linux yedekleme sunucusuna arşivliyorsanız, chattr komutunu kullanarak sözde değiştirilemezlik veya ZFS anlık görüntülerini kullanarak gerçek değiştirilemezlik elde edebilirsiniz.

Linux chattr Kullanımı:
+i (değiştirilemez) bayrağı, dosyanın değiştirilmesini, silinmesini veya yeniden adlandırılmasını engeller.

# Veritabanını dökün
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Yedeği değiştirilemez yapın
sudo chattr +i /backups/mydb_$(date +%F).dump

# Özniteliği doğrulayın
lsattr /backups/mydb_$(date +%F).dump
# Çıktı: ----i---------e------- /backups/mydb_2023-10-27.dump

Not: chattr temel fidye yazılımı betiklerini durdursa da, kök erişimine sahip gelişmiş bir saldırgan kolayca chattr -i komutunu çalıştırabilir. Bu nedenle, bu yöntem sıkı RBAC ve izole yedekleme ağları ile birleştirilmelidir.

ZFS Anlık Görüntüleri Kullanımı:
ZFS çok daha güçlü bir savunma sağlar. Bir anlık görüntü alıp üzerine bir “tutma” (hold) koyarak, anlık görüntünün silinmesini engellersiniz.

# Yedekleme veri kümesinin anlık görüntüsünü alın
zfs snapshot tank/db_backups@archive_$(date +%F)

# Silinmesini önlemek için anlık görüntüye bir tutma koyun
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Kök kullanıcı bile tutmayı kaldırmadan bu anlık görüntüyü yok edemez
zfs destroy tank/db_backups@archive_$(date +%F)
# Çıktı: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Veritabanına Özel Arşivleme Stratejileri

Belirli Bir Zamana Geri Dönüş (PITR) elde etmek için işlem günlüklerini sürekli olarak değiştirilemez depolama alanınıza arşivlemelisiniz.

pgBackRest ile PostgreSQL WAL Arşivleme

pgBackRest, S3 uyumlu depolamayı yerel olarak destekleyen, PostgreSQL için oldukça güvenilir bir yedekleme aracıdır. Yazma Öncesi Günlüklerinizi (WAL) korumak için pgBackRest‘i doğrudan değiştirilemez S3 kovanıza gönderecek şekilde yapılandırın.

pgbackrest.conf dosyanı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

# Saklama süresinin S3 Object Lock yapılandırmanızla uyumlu olduğundan emin olun
repo1-retention-full=2
repo1-retention-archive=2

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

Kritik Husus: S3 kovanız 30 günlük bir Uyumluluk kilidi uyguluyorsa ancak pgBackRest, repo1-retention-archive değerine dayanarak 14 gün sonra WAL dosyalarının süresini doldurup silmeye çalışırsa, silme API çağrıları başarısız olacaktır. Yedekleme yazılımınızın saklama politikasının, depolama düzeyindeki değiştirilemez kilit süresine eşit veya ondan daha büyük olduğundan emin olmalısınız.

Microsoft SQL Server: URL’ye Yedekleme

SQL Server, doğrudan S3 uyumlu nesne depolamaya yerel yedeklemeyi destekler. .bak ve .trn dosyalarını doğrudan değiştirilemez bir kovaya yazmak için bir SQL Server Agent işi yapılandırabilirsiniz.

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 ile Otomasyon ve Orkestrasyon

Değiştirilemez saklama bayraklarını yönetmek, erişim anahtarlarını döndürmek ve veritabanı saklama politikaları ile depolama kilitleri arasındaki senkronizasyonu özel betiklerle sağlamak oldukça hataya açıktır. Bir cron işindeki veya API çağrısındaki tek bir yanlış yapılandırma, arşivlerinizi savunmasız bırakabilir veya sahipsiz, kilitli nesneler nedeniyle bulut depolama maliyetlerinin hızla artmasına neden olabilir.

CloudSave gibi kurumsal yedekleme platformları bu mimariyi basitleştirir. CloudSave; AWS S3 Object Lock, Azure Blob Immutable Storage ve şirket içi S3 uyumlu API’lerle yerel olarak entegre olur.

CloudSave’de bir veritabanı yedekleme planı yapılandırırken:
1. Platform, SQL Server için VSS (Volume Shadow Copy Service) sessizliğini veya PostgreSQL için pg_start_backup() API’sini otomatik olarak yönetir.
2. Tekilleştirilmiş, şifrelenmiş yedekleme verilerini doğrudan depolama hedefine aktarır.
3. CloudSave, WORM API çağrılarını (örneğin PutObjectRetention) nesne bazında dinamik olarak uygular ve depolama kilidi süresini politika tarafından tanımlanan saklama programıyla mükemmel bir şekilde hizalar.
4. Bir saldırgan CloudSave yönetim konsolunu ele geçirse bile, uyumluluk kilidi yedekleme yazılımı tarafından değil, altta yatan depolama altyapısı tarafından uygulandığı için yedekleri silemez.

Değiştirilemez Veritabanı Arşivleri için En İyi Uygulamalar

Değiştirilemez mimarinizin gerçekten dayanıklı olduğundan emin olmak için aşağıdaki sistem mühendisliği en iyi uygulamalarına uyun:

1. Sıkı NTP Senkronizasyonu

Değiştirilemez kilitler matematiksel olarak zaman damgalarına bağlıdır. Depolama dizinizdeki veya yedekleme sunucunuzdaki NTP (Ağ Zaman Protokolü) hizmeti ele geçirilirse veya sapma gösterirse, kilitlerin vaktinden önce dolmasına veya hiç dolmamasına neden olabilir. Depolama altyapınızın doğrulanmış, yedekli NTP kaynakları kullandığından emin olun.

2. IAM Rollerini ve Kimlik Bilgilerini İzole Edin

Değiştirilemez kovaya yazmak için kullanılan kimlik bilgileri yalnızca s3:PutObject ve s3:PutObjectRetention izinlerine sahip olmalıdır. Bu kimlik bilgileri asla s3:DeleteObject veya s3:PutBucketObjectLockConfiguration izinlerine sahip olmamalıdır.

Bir veritabanı yedekleme aracısı için en az ayrıcalıklı IAM politikası örneği:

{
    "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. Saklama Süresini Boyutlandırma

Birincil hızlı kurtarma katmanınızda uyumluluk kilitlerini aşırı uzun süreler (örneğin uyumluluk için 7 yıl) için ayarlamayın. Veritabanları devasa miktarda WAL/işlem günlüğü verisi üretir. Bu verileri yıllarca kilitlemek, depolama maliyetlerinin katlanarak artmasına neden olur.
Bunun yerine, kademeli bir yaklaşım kullanın:
* Operasyonel Kurtarma Katmanı: Tam yedekler ve günlükler için 14 ila 30 günlük değiştirilemez saklama.
* Uzun Vadeli Arşivleme Katmanı: 1-7 yıl boyunca Vault Lock ile Glacier/Deep Archive’a taşınan aylık tam yedekler.

4. Hava Boşluklu (Air-Gapped) VPC’lerde Düzenli Kurtarma Testleri

Değiştirilemezlik, verilerin silinemeyeceğini garanti eder ancak verilerin mantıksal bozulmalardan arınmış olduğunu garanti etmez. Değiştirilemez veritabanı arşivlerinizin geri yüklenmesini izole edilmiş, hava boşluklu bir VPC veya VLAN içinde otomatikleştirmelisiniz. Yapısal bütünlüğü doğrulamak için geri yüklenen veriler üzerinde DBCC CHECKDB (SQL Server) veya pg_amcheck (PostgreSQL) çalıştırın.

Sonuç

Fidye yazılımı savunması, bir ihlal olduğunu varsayma egzersizidir. SIEM sisteminizde bir uyarı tetiklendiğinde, tehdit aktörleri muhtemelen yedekleme altyapınızı çoktan ele geçirmeye çalışmış olacaktır. Veritabanı arşivlerinizi Uyumluluk Modunda değiştirilemez depolama kullanarak mimari olarak tasarladığınızda, saldırganların elindeki temel kozu almış olursunuz. İster yerel bulut API’lerini, ister ZFS tutma işlemlerini veya CloudSave gibi kurumsal bir orkestrasyon platformunu kullanın, WORM depolamayı uygulamak artık isteğe bağlı değil; modern veritabanı yönetimi ve felaket kurtarmanın zorunlu bir sütunudur.

Kategoriler