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.
http://abdullahkise.blogspot.com.tr/2013/05/sifrelemeencryption-esaslar-bolum-1.html
Yedekleri nasıl şifreliyoruz?
İ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önder