SQL Server Yedek Güvenliği: Fidye Yazılımına ve İnsan Hatasına Karşı 10 Kural

Yedek almak, veriyi korumanın yalnızca yarısıdır. Diğer yarısı, o yedeğin ihtiyaç duyulduğu gün gerçekten orada, sağlam ve geri yüklenebilir olmasıdır. Fidye yazılımları artık yalnızca veritabanlarını değil, aynı ağdaki yedek klasörlerini de hedef alıyor; yanlış sunucuda çalıştırılan bir DROP DATABASE ya da WHERE koşulu unutulmuş bir DELETE ise hâlâ en sık karşılaşılan felaket senaryoları arasında.

Bu rehber, hangi yedek türlerinin ne sıklıkla alınacağını değil (bunu backup planı rehberimizde anlatıyoruz), alınan yedeklerin nasıl korunacağını ele alıyor: saldırıya, insan hatasına ve fark edilmeyen bozulmalara karşı on kural.

1. Hedeften Başlayın: RPO ve RTO

Her veritabanı için iki soruyu iş birimiyle birlikte yanıtlayın: en fazla ne kadar veri kaybı kabul edilebilir (RPO) ve sistem en fazla ne kadar süre kapalı kalabilir (RTO)? Beş dakikalık RPO, en az beş dakikada bir log yedeği ve FULL recovery model demektir. İki saatlik RTO ise yedeğin iki saat içinde geri yüklenebilecek bir yerde ve hızda durması demektir. Yedek güvenliğine dair tüm diğer kararlar bu iki hedefe göre verilir.

2. 3-2-1 Kuralı ve Ötesi

Klasik kural: verinin en az 3 kopyası, 2 farklı ortamda, en az 1‘i başka bir lokasyonda. Fidye yazılımı döneminde buna iki madde eklemek gerekir: kopyalardan en az biri değiştirilemez (immutable) ya da çevrimdışı olmalı ve restore testleri sıfır hatayla tamamlanmalı.

3. Yedek Hedefine Erişimi Kısıtlayın

• Yedek paylaşımına yalnızca SQL Server servis hesabı yazabilmeli; etki alanı yöneticileri ve uygulama hesapları yazamamalıdır.
• Yedekleri uzun süreli saklayan ikinci katman (yedekleme sunucusu, nesne depolama, bant), üretim etki alanından ayrı kimlik bilgileriyle yönetilmelidir.
• Nesne depolamada (örneğin Azure Blob Storage) immutability politikaları, belirlenen süre boyunca yedeklerin silinmesini ve değiştirilmesini engeller. SQL Server BACKUP TO URL ile doğrudan bu hedeflere yazabilir.

4. Yedekleri Şifreleyin ve Anahtarları Ayrıca Saklayın

Yedek dosyası, veritabanının tamamının taşınabilir bir kopyasıdır. Şifrelenmemiş bir yedeği ele geçiren, veriyi başka bir sunucuya geri yükleyip okuyabilir. SQL Server 2014 ve sonrasında yedekler doğrudan şifrelenebilir:

-- Bir kez: master'da sertifika oluşturun (master'da bir database master key gerekir)
USE master;
IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name = N'##MS_DatabaseMasterKey##')
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = N'<güçlü parola>';
CREATE CERTIFICATE BackupCert WITH SUBJECT = N'Backup encryption';

-- Sertifikayı özel anahtarıyla birlikte hemen yedekleyin
BACKUP CERTIFICATE BackupCert TO FILE = N'D:\Keys\BackupCert.cer'
WITH PRIVATE KEY (FILE = N'D:\Keys\BackupCert.pvk',
                  ENCRYPTION BY PASSWORD = N'<güçlü parola>');

-- Şifreli, sıkıştırılmış ve checksum'lı yedek
BACKUP DATABASE SatisDB TO DISK = N'\\yedek\sql\SatisDB_full.bak'
WITH ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert),
     COMPRESSION, CHECKSUM;

5. Her Yedekte CHECKSUM Kullanın

WITH CHECKSUM, yedek sırasında sayfa checksum’larını doğrular ve yedeğin kendisi için de bir checksum üretir. Bozuk bir sayfa varsa yedek, bozulmayı sessizce kopyalamak yerine hata verir. Sunucu genelinde varsayılan yapmak için:

EXEC sys.sp_configure N'backup checksum default', 1;
EXEC sys.sp_configure N'backup compression default', 1;
RECONFIGURE;

Sıkıştırmanın CPU ve süre üzerindeki etkisini backup compression rehberimizde anlatıyoruz.

6. Yedeklerin Durumunu İzleyin

Sessizce başarısız olan bir yedek job’ı, hiç olmayan bir yedekten daha tehlikelidir; çünkü herkes yedeğin alındığını varsayar. Son yedekleri, checksum ve şifreleme durumlarıyla birlikte kontrol edin:

SELECT d.name AS database_name, d.recovery_model_desc,
       b.type, b.backup_finish_date,
       b.has_backup_checksums, b.is_copy_only,
       b.encryptor_type, b.compressed_backup_size / 1048576 AS size_mb
FROM sys.databases AS d
OUTER APPLY (SELECT TOP (1) *
             FROM msdb.dbo.backupset AS bs
             WHERE bs.database_name = d.name AND bs.type = 'D'
             ORDER BY bs.backup_finish_date DESC) AS b
WHERE d.database_id <> 2
ORDER BY b.backup_finish_date;

Başarısız yedek job’ları için bildirim kurun ve “son 24 saatte yedeği alınmamış veritabanı” için ayrı bir uyarı tanımlayın.

7. Restore Testi: Tek Gerçek Kanıt

RESTORE VERIFYONLY, yedek dosyasının okunabilir olduğunu ve yapısının bütün olduğunu kontrol eder; ama içindeki verinin kullanılabilir olduğunu kanıtlamaz. Tek gerçek kanıt, yedeği ayrı bir sunucuya geri yükleyip üzerinde DBCC CHECKDB çalıştırmaktır.

• En az ayda bir, kritik veritabanlarından birini düzenli olarak geri yükleyin.
• Testin süresini kaydedin; bu süre gerçek RTO’nuzdur.
• Point-in-time restore’u da test edin: full, differential ve log zincirinin eksiksiz olduğunu ancak böyle görürsünüz.

Restore adımlarını restore rehberimizde ayrıntılı anlatıyoruz.

8. Elle Alınan Yedeklerde COPY_ONLY

Bir geliştiricinin test ortamına veri taşımak için aldığı sıradan bir full yedek, differential zincirinin tabanını değiştirir. O yedek dosyası sonra silinirse, sonraki differential yedekler işe yaramaz hale gelir. Plan dışı yedeklerin her zaman WITH COPY_ONLY ile alınmasını kural haline getirin.

9. İnsan Hatasına Karşı Önlemler

• Üretim ve test sunucularını SSMS’te farklı renklerle ve açık adlarla kaydedin; yanlış sunucuda çalıştırılan komutların çoğu bu karışıklıktan doğar.
• Üretimde DROP, büyük DELETE ve UPDATE işlemlerinden önce bir log yedeği alın; geri dönüş noktası dakikalar içinde hazır olur.
• Kalıcı yetkileri en aza indirin; üretimde kimin neyi silebileceğini bilinçli belirleyin.

10. Belgeleyin

Yedeklerin nerede durduğu, nasıl şifrelendiği, sertifikaların nerede saklandığı, saklama süreleri ve adım adım geri dönüş prosedürü bir belgede olmalıdır. Kriz anında bu bilgiyi aramak zorunda kalmak, RTO’nun en büyük düşmanıdır.

Yedek Güvenliği Kontrol Listesi

• Her veritabanı için RPO ve RTO tanımlı; yedek sıklığı bunlarla uyumlu.
• 3-2-1 uygulanıyor; en az bir kopya değiştirilemez ya da çevrimdışı.
• Yedek hedefine yalnızca servis hesabı yazabiliyor.
• Yedekler şifreli; sertifika ve parolası ayrı yerde, geri yükleme test edilmiş.
• Tüm yedekler CHECKSUM ile alınıyor.
• Başarısız ve eksik yedekler için uyarı var.
• Aylık restore ve CHECKDB testi yapılıyor, süresi kaydediliyor.
• Plan dışı yedekler COPY_ONLY ile alınıyor.