20 Ağustos 2014 Çarşamba

SQL Server 2014 Yenilikleri - 5 (Backup Encyrption)

Veritabanları üzerinde çalışan hemen hemen herkes bir şekilde backup/restore işlemleriyle muhatap olmuştur. Yedekler çoğu zaman farklı lokasyonlara taşınır. Zaten işi sağlama almak için yedeklerin kopyalarının farklı lokasyonlarda tutulması iyi bir şeydir.

Ancak farklı lokasyonlara dağıtılan yedekler veri güvenliğini riske atar. Eğer bilgilerin gizli kalması önemli ise, belli alanların okunamamasını arzu ederiz. Hatta veritabanının farklı bir serverda açılamamasını isteriz. Bu tür istekler Microsoft Azure Storageler gibi bulut teknolojileri kullanılmaya başlandıkça daha da artmaktadır. Microsoft Azure tarafında yeterli güvenlik alınmasına rağmen içi rahat etmeyenler için şifreleme yoğun şekilde başvurulabilecek bir konu haline gelecektir.

Veri güvenliğini, şifreleme yaparak sağlamamız gereken durumlar olduğunda; Önemli verilerin kolayca okunamamasını istiyorsak Column-Level Encrytpion yöntemini, veritabanının farklı bir serverda komple açılamamasını istiyorsak TDE (Transparent Data Encryption) yöntemini tercih ederiz.

TDE yöntemi ile şifreleme yaptığımızda pageler diskte encyrpt edilmiş, memoryde decrypt edilmiş olarak tutulur. Bu işlem sürekli tekrarlandığı için CPU’ya %5-10 civarı yük biner. Zamanla CPU konusunda zaten problemi olan serverlar için tercih edilemeyecek bir yöntem haline gelir. Eğer önemli olan sadece yedeklerin şifreli olarak saklanabilmesi ise o zaman SQL Server 2014 ile birlikte gelen backup encyrption özelliği tam ihtiyacımız olan şey demektir.

Hem veritabanın başka serverda kullanılamamasını hem de yedeklerin şifrelenmesini istiyorsak, bu durumda TDE ve Backup Encyrption özelliklerini birlikte kullanabiliriz. Tabi her şeyden önce şifrelemede kullanılan sertifika ve keylerin yedeklerini sağlıklı yerlerde saklamamız gerekir. Aksi halde şifreleme yaptığımız veritabanlarını tekrar kullanamayız.

Şifreleme konusu ile ilgili 5 bölümlük bir makale serisi hazırlamıştım. İlgililer son bölüm olan TDE yöntemine şu linkten bir göz atabilirler.


Biz bu yazımızda SQL Server 2014 ile birlikte gelen Backup Encyrption özelliğine yoğunlaşalım ve yedeklerimizi nasıl şifreleyeceğimizi inceleyelim.

Yedeklerimizi bir certificate veya asimetrik key yardımıyla şifrelemekteyiz. Yedek alırken WITH seçeneklerinden ENCRYPTION ifadesi ile şifreleme algoritmasını ve certificate veya asymmetric keyi belirtiyoruz. Tabi bu certificate veya asymmetric keyinde korunmaya ihtiyacı var. Bunları da master veritabanının Database Master Key’i (DMK)  ile şifreliyoruz. Database Master Key kolayca oluşturulabilen private bir keydir.

Database Master Key (DMK), certificate ve asymmetric key hakkında daha fazla bilgi almak isterseniz şifreleme serimizdeki ilk yazıdan başlayabilirsiniz.

İlk adım olan master veritabanın Database Master Keyini oluşturalım:

--master veritabanının "Database Master Key"i :
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password1';

Burdaki Password, DMK’yı korumak için kullanılır ve Windows Password Policy mekanizmasına uygun olmalıdır.

DMK oluşturduktan hemen sonra bir certificate veya asymmetrik key oluşturuyoruz. Biz burada certificate ile ilerliyor olacağız.

--Yedeklemede kullanılacak sertifika:
USE Master;
GO
CREATE CERTIFICATE YedekSifrelemeCert
   WITH SUBJECT = 'yedekleme sertifikası;

Sertifikaların da korunmaya(şifrelenmeye) ihtiyacı vardır. Çeşitli şekillerde şifrelenebilirler. Eğer bu konuda bir şey belirtilmezse otomatik olarak DMK yardımıyla şifrelenmiş olurlar. Bizim oluşturduğumuz certificate master veritabanın DMK’sı ile korunmaktadır.

Şimdi sıra geldi backup alırken bu sertifikayı göstermeye ve şifreleme algoritmasını seçmeye.

BACKUP DATABASE veritabani
TO  DISK = N'C:\yedeklerim\veritabani_enc.bak'

WITH
      ENCRYPTION
         (
              ALGORITHM = AES_128, --AES_192, AES_256, Triple DES kullanılabilir.
              SERVER CERTIFICATE = [YedekSifrelemeCert]
         )

Bu örneğimizde AES_128 algoritmasını kullandık. Siz ihtiyaca göre sisteminiz için diğer algoritmaları da (AES_192, AES_256, Triple DES) tercih edebilirsiniz.

Yedek almak için scripti çalıştırdıktan hemen sonra bir uyarı ile karşılaşacaksınız. Bu uyarı yedek almaya engel değil ancak çok önemli bir hatırlatmayı içeriyor. Şifrelemede kullandığımız sertifikanın bir yedeği alınmadı. Sertifika kullanılamaz hale gelirse yedek de açılamaz hale gelir. Yani certificate ve onu koruyan private keyin (bu örnekteki DMK) yedeğinin felaket durumunda veya başka bir servera taşınma durumunda kullanılmak üzere alınması gerekir. Bu konuya birazdan döneceğiz.

Artık yedeklerimizi şifrelenmiş olarak saklayabiliyoruz. Oluşan yedek dosyası üzerine başka yedekler alamıyoruz. Yeni bir media set oluşturmamız ve içeriği ezmemiz gerekir. Bu yedek dosyasında bulunan bir önceki yedeğin silineceği anlamına gelir.

Peki, yedekten nasıl döneceğiz?

Eğer yedek alırken kullandığınız DMK ve certificatenın bulunduğu serverda iseniz yedekten dönmek için normalden farklı bir şey yapmanıza gerek yok. En basit haliyle aşağıdaki scripti kullanarak veritabanını yedekten döndürebilirsiniz.

USE [master]
RESTORE DATABASE [veritabani]
FROM  DISK = N'C:\yedeklerim\veritabani_enc.bak'

Eğer veritabanının yedeğini farklı bir serverda açmak istiyorsanız veya şifrelemede kullandığınız certificate silinmiş ise yukarıdaki scriptten daha fazlasını yapmanız gerekecek.

Sertifikaları nasıl koruyup yedekleyebilirim?

Şifrelemede kullandığımız sertifikanın yedeğini güvenli bir ortama almamız gerekir. Yedek alırken WITH PRIVATE KEY ifadesi ile sertifikayı koruyan private key de belirttiğimiz password yardımıyla şifrelenmelidir. Bu ifade kullanılmadan sertifika yedeği alınabilir ancak bu esnada sertifikanın private keyi diske alınmadığından sertifikadaki PrivateKeyEncryptionType özelliği NoKey olarak işaretlenir. Bu da sertifikayı restore işleminde kullanılamayacak hale getirir. Bu konuda çeşitli derinliklerde çalışmalar yapılabilmektedir. Biz amacımızın dışına çıkmadan aşağıdaki şekilde yedekleme yapmamızın doğru olacağını kabul etmiş olalım.

Sertifikaların yedeğini şu script yardımıyla alıyoruz:

--sertifikanın yedeğini alalım
USE master
GO
BACKUP CERTIFICATE YedekSifrelemeCert
TO FILE ='C:\yedeklerim\YedekSifrelemeCert.cer'

WITH PRIVATE KEY
     (
          FILE ='C:\yedeklerim\YedekSifrelemeCert.pvk',
          ENCRYPTION BY PASSWORD=N'pass@word1'
     )

Sertifikayı tekrar(yedekten) oluşturmak için şu komutu kullanmamız gerekecek:

--sertifikayı yedekten dönelim
USE master
GO
CREATE CERTIFICATE YedekSifrelemeCert
FROM FILE = 'C:\yedeklerim\YedekSifrelemeCert.cer'


WITH PRIVATE KEY
     (
          FILE ='C:\yedeklerim\YedekSifrelemeCert.pvk',
          DECRYPTION BY PASSWORD='pass@word1'
     )

DMK silinmiş ise öncesinde mutlaka DMK oluşturulmalıdır. Çünkü bu şekilde yedek aldığımızda sertifikanın, MasterKey olarak işaretlenen PrivateKeyEncryptionType özelliği DMK’yı isteyecektir.

Eğer ihtiyaç duyarsanız, DMK’nın yedeklenmesi ile ilgili bilgilere şu linklerden ulaşabilirsiniz.


Eğer Certificate ve DMK’yı kaldırmak isterseniz şu drop komutları işinizi görecektir.

USE master;
GO
--Certificate yı kaldırmak için
DROP CERTIFICATE YedekSifrelemeCert

-- DMK yı kaldırmak için
DROP MASTER KEY

Master veritabanı altında konumlanan sertifikamızın PrivateKeyEncryptionType özelliğini şuradan görüntüleyebilirsiniz:



Sertifikayı kullanılabilir hale getirdiğinizde klasik restore scriptini kullanarak yedeklerinizi istediğiniz serverda açabilirsiniz.

Tabi ki backup encrption özelliği sadece SQL Server 2014’ün desteklediği bir özelliktir. Hatta bu versiyondaki Web ve Express editionlarda backup encription desteklenmemektedir.

Eğer yedeklerin şifrelenmesi ilginizi çektiyse ve SQL Server 2014 öncesi versiyonlarda kullanmak isterseniz Microsoft Download Centerdan indireceğiniz Microsoft SQL Server Backup to Windows Azure Tool’u kullanabilirsiniz. Bu araç yardımıyla SQL Server 2014 yedeklerindeki tüm özellikler SQL Server 2005, 2008, 2008 R2 ve 2012 yedeklerine de uygulanabilir. Bu konuda gereken tüm bilgiye şu yazımdan erişebilirsiniz:


Yedeklerin şifrelenmesi ilerleyen günlerde bir hayli önem kazanacak bir konu.

Faydalı olması dileğiyle…


Hiç yorum yok:

Yorum Gönderme