database master key etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
database master key etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

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…


22 Eylül 2013 Pazar

Kolon-Satır Bazlı Şifreleme (Column Level Encrypyion) - Bölüm 4

Şifreleme konusunun devamı olan Kolon-Satır Bazlı Şifreleme (Column Level Encrypyion) - Bölüm 4  isimli yazımı sqlserveronculeri.com adresinden de inceleyebilirsiniz.
Bu yazımla kolon bazlı şifrelemeyi sıfırdan bir örnekle somutlaştırmış olduk. 
Faydalı olması dileğiyle...


Encryption esasları ve Column-Level Encryption kapsamındaki mekanizmaları önceki yazılarımızda incelemiştik. Önceki 3 makaleyi okuyarak konu hakkında daha fazla bilgi edinmek isteyebilirsiniz. Bu bölümde sıfırdan bir örnek ile bu mekanizmaları karma bir şekilde kullanarak şifreleme teorisini pratiğe döküyor olacağız.

Bir önceki yazımı şu linkten ulaşabilirsiniz.

Daha önce de benzerini paylaşmış olduğum aşağıdaki resme bakarak şifreleme için gerekli kombinasyonları rahatça oluşturabiliriz.

Msdn’den aldığım bu resme bakarak sadece password ile verileri şifreleyebildiğim gibi bir certificate veya password ile korunan bir asymmetric key yardımı ile encrypt ettiğimiz symmetric keyi kullanarak da şifreleme yapılabileceğini söyleyebilirim. Buraya bakarak çeşitli kombinasyonları oluşturmak size kalmış.
Biz örneğimizde verileri şifrelemek için certificate ile korunacak bir symmetric key kullanacağız.
Öncelikle EncryptDB isimli bir test veri tabanı ile Musteri isimli bir tablo oluşturalım ve birkaç kayıt girelim.
--test veritabanı oluşturalım
CREATE DATABASE EncyptDB
GO

USE EncyptDB
GO
--Önemli bilgilerin bulunduğu bir tablo oluşturalım
CREATE TABLE Musteri
(
     Id int identity(1,1),
     Ad nvarchar(50),
     KartNum nvarchar(100)
)
GO

--Bir kaç test kaydı
INSERT INTO Musteri VALUES ('Ali','213-123-123-123'),
                                  ('Veli','675-456-345-234')

GO
SELECT * FROM Musteri


Hemen ardından şifreleme için gerekli alt yapıyı oluşturacağız. Bunun için her veri tabanında yalnızca bir tane oluşturulabilen Database Master Key(DMK) create etmeliyiz. DMK ile ilgili bilgileri Şifreleme(Encryption) Esasları – Bölüm 1 isimli yazımda bulabilirsiniz.
--Database Master Key(DMK) oluşturalım
CREATE MASTER KEY
ENCRYPTION BY PASSWORD='pass@word1'
GO

Sonrasında certificate ve bu sertifika ile korunacak symmetric key oluşturuyoruz. Ceriticate ve symmetric key oluşturma ile ilgili bilgileri ise Kolon-Satır Bazlı Şifreleme (Column Level Encrypyion) - Bölüm 3 isimli yazımdan edinebilirsiniz.
--symmetric key korumak için certificate oluşturalım
--bu sertifikanın korunması için DMK kullanılır.
CREATE CERTIFICATE enc_cert
     WITH SUBJECT='Sifreleme Test'

GO

--encryption için gerekli symmetrik key oluşturalım
--bu keyi yukarıdaki certificate ile koruyalım
CREATE SYMMETRIC KEY enc_sym_key
     WITH ALGORITHM=DES
     ENCRYPTION BY CERTIFICATE enc_cert

Şifreleme için gerekli altyapı hazır durumda. Artık şifrelenmiş metni tabloda tutmak için varbinary bir kolona ihtiyacımız olacak.
--Şifrelenmiş verileri tutmak için yeni kolon ekleyelim
ALTER TABLE Musteri
ADD EncKartNum varbinary(max)

Ve işte şifrelemeye başlıyoruz.
Symmetric key kullandığımız için encryption ve decryption işlemlerinden önce mutlaka key açılmalıdır. Aksi halde fonksiyonlarımızdan sürekli NULL döner.
OPEN SYMMETRIC KEY enc_sym_key
     DECRYPTION BY CERTIFICATE enc_cert

Şifrelenmemiş metnin bulunduğu KartNum kolonundaki veriyi EncryptByKey fonksiyonu ile şifreleyip yeni olşturduğumuz EncKartNum isimli varbinary kolona basalım.
UPDATE Musteri
     SET EncKartNum=EncryptByKey(
                                          Key_GUID('enc_sym_key'),
                                          KartNum);
--bakalım
SELECT * FROM Musteri


Artık verinin şifrelenmiş hali de tablomuzda tutulmakta.
Açık olan symmetric key session düştüğünde kapanır. Öncesinde kapatmak isterseniz şu komutu kullanabilirsiniz.
--açık symmetrik keyi kapatmak için
CLOSE SYMMETRIC KEY enc_sym_key;

Artık temiz metnin bulunduğu KartNum isimli kolona ihtiyacımız yok. Kaldırmamız şifrelemeyi anlamlı hale getirecektir.
--temiz metnin bulunduğu KartNum kolonunu kaldırmak için
ALTER TABLE Musteri
DROP COLUMN KartNum

--bakalım
SELECT * FROM Musteri


Şifreleme işlemini başarıyla tamamladık. Artık temiz metin resimdeki gibi görünecek.
Peki şifreli metni okumak için neler yapmalıyız?
Öncelikle symmetric key kullandığımız için decryption işleminden önce mutlaka keyi açmalıyız.
--Şifreli metni çözmek için
--öncelikle symmetric key açılır
OPEN SYMMETRIC KEY enc_sym_key
     DECRYPTION BY CERTIFICATE enc_cert

Varbinary tipindeki EncKartNum isimli kolonu DecryptByKey fonksiyonu ile çözüyoruz ve nvcarchar tipine convert ediyoruz.
SELECT
     Id,
     Ad,
     CONVERT(NVARCHAR, DecryptByKey(EncKartNum)) as 'Kart Numarası'
FROM Musteri


Böylece şifrelenmiş veriden temiz metni elde etmiş olduk.
Açtığımız symmetric keyi session kapanmadan önce kapatmak istersek şu ifadeyi kullanıyoruz.
--açık symmetrik keyi kapatmak için
CLOSE SYMMETRIC KEY enc_sym_key;

Bu tarz bir şifreleme örnekten de anlaşılacağı gibi şifrelenen alan adedine paralel olarak development iş yükünü arttıracaktır. Ancak ihtiyaca göre az sayıda alanının şifrelenmesi, tüm veri tabanını şifreleyen TDE’ye göre daha az kaynak tüketeceğinden bu yöntemin tercih edilmesi mantıklı olacaktır.
Sizler de Column-Level Encryption mekanizmalarıyla farklı kombinasyonları oluşturarak belli bir metinsel alana odaklanıp yüksek seviyede koruma sağlayabilirsiniz.
Bir sonraki yazımda tüm veri tabanın şifrelenmesi için kullanılan Transparent Data Encryption(TDE) yöntemini inceliyor olacağız. Bu yöntem sayesinde veri tabanının başka serverlara taşınması halinde normal yollarla okunamayacağı garanti altına alınabilmektedir.
Faydalı olması dileğiyle,

Keyifli günler