Firmalar müşterileri, personelleri, finansal geçmişleri ve
stratejileri ile bilgilerini yetkisiz gözlerden korumak için birçok seviyede çeşitli
adımlar atabilmektedirler. Veri tabanı yönetim sistemini göz önünde bulundurarak,
örneğin müşterilerin kredi kartı numaralarının bulunduğu bir tabloyu ele
alalım. Bu tablodaki güvenlik bakımından risk oluşturmayacak kolonları genel
kullanıma açmak için kolayca, kredi kartı kolonunu içermeyecek bir view tanımlayabilir
ve istenilen yetkilendirmeyi bu view üzerinden yapabiliriz. Ancak bu sandığımız
kadar ciddi bir koruma sağlamayacaktır.
Sadece view’e SELECT yetkisi verdiğimiz bir Local Admin kullanıcısı
rahatlıkla SQL Service’i durdurabilir ve sysadmin rolüne sahip olduğu başka bir
servera bu veri tabanını taşıyabilir. Dolayısıyla yaptığımız yetkilendirmenin
hiç bir anlamı kalmaz.
Datalar bizim için gerçekten çok önemliyse ve bu tarz taşıma
işleminde bile kolayca okunamamasını istiyorsak o zaman daha cesur adımlar
atmamız gerekir. Bu adımlar “Data Encryption” yani veri şifreleme kapsamındaki
adımlardır.
Encryption çeşitli seviyelerde ve şekillerde yapılabilen
maliyetli bir işlemdir. Bu maliyet bakım, performans ve geliştirme gibi
konuları kapsamaktadır. İlerleyen yazılarımda yeri geldikçe yöntemler
arasındaki karşılaştırmalara da yer vermeyi planlıyorum.
Bu konuyu bir kaç bölüme ayırmayı düşünüyorum. İlk bölümde
şifreleme esaslarını kuş bakışı inceliyor olacağız. Sonra sırasıyla bir
kolondaki verilerin şifrelenmesi(Column-Level), databasein tümden (Transparent
Data Encryption) dosya seviyesinde şifrelenmesi ve bu yöntemlerin
maliyetlerinin karşılaştırılması gibi konuları içeren bölümleri hazırlamayı
hedefliyorum.
Encryption(şifreleme) ilk olarak SQL Server 2005 ve SQL
Server 2008 ile birlikte yeni özelliklerle desteklenmeye başlandı. Peki, son
durumda SQL Server 2012 Encryption konusunda nelerle karşılaşıyoruz bir
bakalım.
Genel olarak veri güvenliği şu 3 seviyede sağlanabilir:
1- Windows Level
Microsoft, Windows 2000 işletim sistemi
ile birlikte veri şifrelemesi konusunda bir API yardımıyla destek vermeye
başladı. Data Protection API (DAPI) isimli bu kütüphane sayesinde geliştiriciler
kullanıcı bilgilerinden türetilen bir anahtar(symmetric key) sayesinde verileri şifreleyebiliyor ve bunları aynı
anahtarla çözebiliyor durumdalar. Crypt32.lib
isimli bu kütüphaneye C:\Windows\System32
altında Crypt32.dll içerisinden
erişebilirsiniz. Şifreleme için CryptProtectData fonksiyonu,
çözmek için CryptUnprotectData fonksiyonunu
kullanmanız yeterli. .NET developer olan arkadaşlar yine bu dll’i kapsülleyen ProtectedData class’ı altındaki ProtectedData.Protect ve ProtectedData.Unprotect metotlarını
kullanarak kullanıcı bilgilerini temel alan bir şifreleme yapabilirler.
2- Server Level
MSSQL Server servicei kurulurken
Windows DPAPI tarafından Service Master Key oluşturulur. Bu key master veri tabanındaki
Security düğümü altında bulunan Symmetric Key klasörünün içinde yer alır. Sys.symmetric_keys sistem viewi
yardımıyla ne zaman oluşturulduğu ve kullanılan algoritma ile ilgili bilgileri şu
şekilde görüntüleyebiliriz.
SELECT
*
FROM sys.symmetric_keys
WHERE
name = '##MS_ServiceMasterKey##';
Service Master Key tamamen
kaldırılamaz. Ancak yeni bir key üretilmesini sağlayabilirsiniz.
ALTER SERVICE MASTER KEY REGENERATE
Bu keyin ileride kullanılmak
üzere yedeği (Backup) alınabilir.
--Backup Service
Master Key
BACKUP SERVICE MASTER KEY
TO FILE = 'c:\birYol\service_master_key'
ENCRYPTION BY PASSWORD = 'pass@word1';
Gerektiğinde bu yedekten
dönülebilir(Restore).
--Restore Service
Master Key
RESTORE SERVICE MASTER KEY
FROM FILE = 'c:\birYol\service_master_key'
DECRYPTION BY PASSWORD =
'pass@word1';
“Service Master Key”, veri tabanı
üzerinde üreteceğimiz “Database Master Key” i şifrelemektedir. Bu nedenle
yedeğinin tutulması oldukça önemlidir. Aksi halde bir felaket durumundan sonra
şifrelenen veri tabanlarına bir daha erişilemeyebilir.
3- Database Level
Her database tek bir “Database Master Key” e sahiptir. Verileri
şifrelemek için kullanacağımız Certificate ve Asymmetric Key’leri bu anahtar
yardımıyla şifreleyip koruyabiliriz.
Eğer Certificate ve Asymmetric Key’leri oluştururken nasıl
şifreleneceğini belirtmezsek otomatik olarak bunların korunması için “Database
Master Key” kullanılır.
“Database Master Key”, “Service Master Key” tarafından korunan bir Symmetric
Key’dir. Bu key AES_256 algoritması ve kullanıcı tarafından belirtilen bir password
yardımı ile korunur.
DMK, Key elde edilmek istenen database üzerinde şu script ile
oluşturulur.
CREATE
MASTER KEY
ENCRYPTION
BY PASSWORD ='pass@word1'
Database
Master Key’i görmek için. İlgili database üzerinde şu script kullanılabilir.
SELECT
*
FROM sys.symmetric_keys
WHERE
name='##MS_DatabaseMasterKey##'
Güvenlik seviyelerine ve bu seviyelerde hangi keylerin
kullanıldığına bir göz attık. Şimdi de
verileri şifrelemek için kullanacağımız yapılara ve şifrelemeyi tetikleyecek
mekanizmalara bir göz atalım.
Şu 4 çeşit yapı sayesinde veriler şifrelenebilir:
1- Password:
a.
Belirleyeceğimiz güvenli bir parola yardımıyla.
Örneğin “pass@word1”
2- Symmetric Key
a.
Veriler tek bir binary key yardımıyla şifrelenip
çözülebilir.
3- Asymmetric Key
a.
Bu yapıda private key ve public key bulunur.
b.
Public key şifreli metin ile paylaşılan bir anahtartır.
c.
Private key ise özeldir, paylaşılmaz.
d.
Her bir key ya sadece şifreler ya da sadece
şifreli metni çözer.
4- Certificate
a.
Şifreleme işlemi sertifika yardımıyla da
yapılabilir.
b.
Sertifikalar kişilerin, cihazların ve
hizmetlerin kimlik bilgilerini tutar.
c.
Dijital imza ve priavate key ile konuşacak
public key bilgisini barındırır.
Veri şifreleme mekanizması şu 4 yolla(fonksiyonlar)
çalıştırılabilir:
1-
T-SQL
fonksiyonu
EncryptByPassPhrase - DecryptByPassPhrase
2-
Asymmetric
Keys
EncrypByAsymKey - DecryptByAsymKey
3-
Symmetric
Keys
EncrypByKey - DecryptByKey
4-
Certificates
EncrypByCert - DecryptByCert
Genel olarak Sql Server 2012 içerisinde 2 çeşit
Encryption(şifreleme) yapılabilir:
1- Column-Level (kolon veya satır seviyesinde)
a.
Veriler fonksiyonlar yardımıyla şifrelenip
çözülebilir. Diskte ve memoryde şifreli halde durur. Database başka bir
serverda normal yollarla açılıp kullanılamaz.
b.
Bu yöntem kullanılacaksa client tarafındaki
scriptlerin değişeceği unutulmamalıdır. İlgili fonksiyonların sql ifadelerinde
kullanılması gerekecektir.
c.
Güvenlik bakımından düşünürsek; bilgileri
herkesin gözünden saklamış oluruz.
d.
Bu yöntemle sadece gerekli alanları
şifreleyebiliriz . Böylece CPU’ya çok fazla yük binmemiş olur. Indexler hızla
bozulsa da az sayıda alan üzerinde kullanıldığında sistem TDE ye göre daha performanslı çalışılır.
2- File – Level (dosya veya database
seviyesinde)
a.
Burada yapılacak şifreleme Transparent Data Encryption (TDE) olarak bilinmektedir.
b.
Veriler server dahilinde normal şekilde görünür.
Yani sadece pagelere yazılırken şifreli yazılır. Bilgiler belleğe şifresi
çözülerek çıkartılır. DB ye erişen herkes bilgileri temiz haliyle okuyabilir.
Ancak database başka serverda direk açılıp kullanılamaz.
c.
Verinin boyutu şifrelendikten sonra artmaz.
Ancak indexlerin bozulma hızı normale göre çok yüksektir. Database genelinde
bilgiler sürekli şifrelenip çözüldüğü için CPU kullanımı %5-%10 oranında artar.
CPU ve IO sıkıntısı çeken makinelerde kullanılmamalıdır. İlerde belirteceğim
nedenlerden dolayı server genelinde de performans kaybına sebep olabilir.
Bu bölümde güvenlik seviyelerine, şifrelemede kullanılacak
yapılara, şifreleme mekanizmasını tetikleyen fonksiyonlara ve SQL Server
içerisinde kurulabilecek şifreleme yöntemlerine çoğunlukla teorik olarak değinmiş
olduk.
Bir sonraki bölümde Column-Level (Kolon veya Satır Bazlı)
şifrelemeye odaklanıp verileri yukarıda belirttiğimiz fonksiyonlar yardımıyla
nasıl şifreleyeceğimizi ve bu şifreli verileri nasıl çözebileceğimizi
örneklendirmiş olacağız.
Pratiğin daha ağır bastığı ilerleyen yazılarda görüşmek
üzere,
Faydalı olması dileğiyle…
Çok Güzel ve Türkiyede çok bilinmeyen bir konuya değinmişsiniz. Anlatım İçin Teşekkürler.
YanıtlaSil