MSSQL Server Backup Encryption

SQL Server tarafında veri güvenliği denince akla gelen iki dev yapı vardır: Backup Encryption ve Transparent Data Encryption (TDE). İkisi de veriyi şifreler ancak koruma hedefleri ve çalışma prensipleri oldukça farklıdır.

Backup Encryption, SQL Server 2014 ile hayatımıza giren ve yedekleme (backup) işlemi sırasında verinin şifrelenmesini sağlayan bir özelliktir.

Eskiden yedek dosyalarımız (.bak) çalınırsa, bu dosyayı herhangi bir SQL instance’ına geri yüklemek (restore) çocuk oyuncağıydı. Backup Encryption ile bu dosya, doğru sertifika veya anahtar olmadan tamamen okunamaz hale gelir.

Avantajları

  • Yedek dosyası buluta veya harici bir diske taşınırken çalınsa bile içi açılamaz.
  • Şifreleme işlemi yedekleme sırasında yapıldığı için CPU üzerinde bir miktar yük oluşturur ancak TDE gibi sürekli bir disk I/O yükü bindirmez.
  • Veritabanının kendisini şifrelemeden sadece dışarıya çıkan kopyasını (yedeği) korumanıza olanak tanır.

Bu işlemi yapabilmek için önce bir anahtar hiyerarşisi kurmanız gerekir.

İlk olarak bir master oluşturuyoruz.

USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Parola23+-+-';

İkinci olarak sertifika oluşturulması gerekmektedir.

CREATE CERTIFICATE MyBackupCert 
WITH SUBJECT = 'Yedekleme Sertifikasi';

Yedek alırken ENCRYPTION parametresini ve kullanacağınız algoritmayı (genelde AES 256) belirtmeniz yeterlidir. Backup işleminde Encryption yapıda oluşturabilmek için SSMS arayüzünde aşağıdaki bölümün aktif edilmesi gerekmektedir. Herhangi bir şey yazılmasına gerek yoktur.

İlgili bölüm seçildikten sonra Backup Options kısmında ilgili bölümün seçildiği görülmektedir.

AES(Advanced Encryption Standard) günümüzün dünya standardıdır. Çok güvenli ve hızlıdır. Yanındaki sayılar (128, 192, 256) şifreleme anahtarının uzunluğunu (güç seviyesini) temsil eder.

  • AES 128: Standart güvenlik için yeterlidir, hızlı çalışır.
  • AES 256: “Askeri düzey” koruma sağlar. Kırılması günümüz teknolojisiyle imkansız kabul edilir; en yüksek güvenliği sağlar ancak biraz daha fazla işlem gücü gerektirir.

Triple DES (3DES): Eski bir yöntemdir. Veriyi üç kez üst üste şifreler. AES’e göre hem daha yavaş hem de daha az güvenli olduğu için günümüzde pek tercih edilmez, genelde eski sistemlerle uyumluluk için listede yer alır.

Yukarıdaki açıklamalardan sonra oluşturduğumuz sertifika ve hangi şifreleme metoduyla şifrelemek istersek şifreleyebiliriz.

Yapılan işlemlerin scripti alınır:

BACKUP DATABASE [AdventureWorks2017] TO  DISK = N'C:\Backup\Ecrypted.bak' WITH FORMAT, INIT,  MEDIANAME = N'Şifreli Backup Alma',  
NAME = N'AdventureWorks2017-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, ENCRYPTION(ALGORITHM = AES_256, SERVER CERTIFICATE = [MyBackupCert]), 
STATS = 10
GO

Backup işlemimi başarılı aldıktan sonra başka bir ortama restore edilmek istediğinde ilgili ortamda sertifika ve master key olmadığı için hata vermektedir.

Restore edilecek ortama oluşturulan sertifikanın yedeğinin restore edilmesi gerekmektedir. Bunun için ilk olarak backup alınan ortamda sertifikanın yedeğinin alınması gerekmektedir.

 Use Master;
 Go
BACKUP CERTIFICATE MyBackupCert   TO FILE = 'C:\sertifika\sertifika' 
WITH PRIVATE KEY ( FILE = 'C:\sertifika\sertifikaPrivateKey' ,
ENCRYPTION BY PASSWORD = 'Elazig23+-+-+-+-' );  

Restore edilecek ortama sertifikanın oluşturulması gerekmektedir. Önceden alınmış sertifika backup dizininin belirtilmesi gerekmektedir.

İlk olarak master key oluşturulur.

USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Parola23+-+-';

Sertifika restore edilir.

   CREATE  CERTIFICATE MyBackupCert
   FROM  FILE = 'C:\sertifika\sertifika'  
    WITH PRIVATE KEY ( 
	FILE = 'C:\sertifika\sertifikaPrivateKey' ,   
    DECRYPTION  BY PASSWORD = 'Elazig23+-+-+-+-' );  

Sertifika oluştururken yukarıdaki gibi bir hata mesajıyla karşılaşırsa sertifikanın yapılacak dosyada bağlantı sağlayan sql servis hesabının yetkisi olmamasından dolayıdır. Bu sebepten ilgili klasörlere restore yapılacak ortamdaki sql server servis hesabının yetkilendirilmesi gerekmektedir.

Aşağıdaki komut ile sertifikanın olup olmadığı gözlemlenir.

SELECT * FROM sys.certificates WHERE name = 'MyBackupCert';

Farklı bir ortama restore işlemini tekrardan gerçekleştirdiğimizde başarılı bir şekilde işlemlerimiz tamamlanmaktadır.

Backup Encryption ve TDE Karşılaştırma

Birçok kişi bu ikisini karıştırır ancak aralarındaki fark “Durağan Veri” (At Rest) ve “Yedek Veri” koruması arasındaki farktır.

ÖzellikBackup EncryptionTDE (Transparent Data Encryption)
KapsamSadece oluşturulan yedek dosyası (.bak)Veritabanı dosyaları (.mdf, .ndf, .ldf)
Çalışma ZamanıSadece yedekleme işlemi sırasındaVeri diske yazılırken ve okunurken (Sürekli)
TempDBEtkilemezTempDB’yi de şifreler (Kritik fark!)
CPU YüküSadece backup anında artarSürekli düşük-orta düzeyde yük bindirir
Restore DurumuSertifika olmadan başka sunucuya kurulamazSertifika olmadan başka sunucuya eklenemez (Attach/Restore)

Kritik Teknik Farklar

  1. TempDB Etkisi: TDE aktif edildiğinde, sunucudaki tüm veritabanları için tempdb otomatik olarak şifrelenir. Çünkü şifreli bir veritabanından tempdb’ye sızan veri de şifreli kalmalıdır. Backup Encryption’da böyle bir durum yoktur.
  2. Sıkıştırma (Compression): TDE kullanan bir veritabanında yedek alırken sıkıştırma yapmak zordur (önce şifrelendiği için veri küçülmez). Ancak SQL Server 2016 CU8 ve sonrasında MAXTRANSFERSIZE ayarlarıyla bu aşılabilir. Backup Encryption’da ise sıkıştırma ve şifreleme aynı anda verimli çalışabilir.
  3. Performans: Eğer disk yazma hızınız (I/O) darboğazdaysa TDE sistemi yavaşlatabilir. Eğer işlemci (CPU) darboğazdaysa Backup Encryption yedekleme süresini uzatabilir.

Eğer MyBackupCert sertifikasını ve anahtarını (Master Key) kaybederseniz, aldığınız yedekleri asla geri yükleyemezsiniz. SQL Server bu konuda affedici değildir. Sertifikanızı mutlaka fiziksel olarak farklı ve güvenli bir yerde saklayın.

Bu makale backup alınırken aldığımız bak uzantısının nasıl şifrelendiğini görmüş olduk.

Başka makalede görüşmek dileğiyle..

“Mutlu olanlar ise cennettedirler.” (Hud, 11/108)

Author: Yunus YÜCEL

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir