1. Ana Sayfa
  2. SQL Server
  3. SQL Server 2016 Güvenlik Özellikleri : Always Encrypted – Bölüm 1

SQL Server 2016 Güvenlik Özellikleri : Always Encrypted – Bölüm 1

2016 Güvenlik Özellikleri : Always Encrypted. Özellikle son dönemlerde daha da çok önem kazanan veri güvenliği konusunda 2016’da öne çıkan özelliği, adından da anlaşılacağı üzere verilerin her zaman şifreli olması ve bu sayede verilerinize veritabanında yetkili kişilerin bile erişememesini sağlar. En büyük artılarından biri kolon bazlı şifrelemeye olanak sağlamasıdır.

Always Encrypted Nasıl Çalışır?

Always Encryted aslında çok basit bir mantık üzerine kurulu: Verimi şifrelediğin anahtarı da başka bir anahtar ile şifrele ve bu anahtarları farklı bir yerde sakla.


Resim-1

Daha açıklayıcı olması için bir örnek üzerinden ilerleyelim:

Customers adında basit bir tablomuz olsun. Burada tahmin edeceğiniz üzere CitizenshipNo kolonundaki verileri şifrelemek istiyoruz.


Resim-2

NOT : Bu isimleri çok aradın mı diye merak edenler varsa RandomNameGenerator kullandım. https://github.com/jtuttle87/RandomNameGenerator

Bunun için öncelikle bir Column Master Key, yani verileri şifreleyeceğimiz anahtarı şifreleyeceğimiz diğer anahtarı oluşturacağız. Security / Always Encrypted Keys / New Column Master Key seçeneğini seçerek işleme devam ediyoruz.


Resim-3

NOT : Bu işlemler T- üzerinden de yapılabiliyor ancak makalenin daha anlaşılabilir olması için SSMS üzerinden ilerliyoruz.

New Column Master Key ekranında bizden Column Master Key’e vereceğimiz isim ile bunu nerede saklayacağımız bilgisini gireceğiz. Burada bize 4 seçenek sunuyor (Resim-4):

  1. Windows Certificate Store – Current User
  2. Windows Certificate Store – Local Machine
  3. Azure Key Vault
  4. Key Storage Provider (CNG)


Resim-4

Örnek üzerinde sertifikaya kolay erişmek için current user üzerinden CMK adında bir sertifika oluşturalım. Sertifikayı kaybetmeniz verileri de tekrar Decrypt edemeyeceğiniz anlamına geldiğini de hatırlatmakta fayda var.


Resim-5

Windows Certificate Manager (certmgr.msc) üzerinden de oluşturduğumuz sertifikayı görebilirsiniz (Resim-6)


Resim-6

Column Master Key’i oluşturduktan sonra, verilerinizi asıl şifreleyecek olan anahtarı da oluşturalım. Column Master Key’e benzer şekilde SSMS üzerinden yeni bir Column Encryption Key oluşturalım.


Resim-7

CMK ve CEK oluşturduktan sonra sıra tablodaki kolonu şifrelemeye geldi. SSMS üzerinden tabloya sağ tıklayarak Encrypt Columns seçeneğini seçiyoruz.


Resim-8

Karşımıza çıkan ekran üzerinde (Resim-9) şifreleyeceğimiz kolonları seçeceğiz. Burada bize şifreleme tipini ve şifreleme anahtarını soruyor. Şifreleme tipi olarak 2 seçeceğimiz var:

1. Deterministic: Bu tipte şifrelediğimiz veriden hep aynı şifrelenmiş değeri elde ederiz. Örnek olarak 12345’I şifrelediğimiz zaman abcde oluyorsa, şifreli kolonda geçen bütün 12345 verileri abcde olarak şifrelenecektir. Bunun dezavantajı ise şifreli bir satırdaki veriyi tahmin edebilir ya da şifresiz halini öğrenebilirseniz tablodaki diğer benzer verilerin de şifresiz halini öğrenmiş olursunuz.

2. Randomized: Bu tipte de adından da anlaşılacağı üzere veriden her seferinde farklı bir şifrelenmiş değer elde ediyoruz. Böylece şifreli bir veri eğer deşifre olursa diğer satırlardaki verileri tahmin etme şansı olmuyor. Dezavantajı ise deterministic şifrelemenin aksine equality lookup, join ve group by desteklenmiyor. Bu nedenle bu tipin gerçekten çok önemli verilerin şifrelenmesi için kullanılması tavsiye ediliyor.

NOT : Always Encrypted aşağıdaki veri tiplerini desteklemiyor.

xml,

timestamp/rowversion,

image,

ntext/text,

sql_variant,

hierarchyid,

geography,

geometry,

alias,

user defined-types.


Resim-9

Şimdi de gelelim işin çok da hoşunuza gitmeyeceğini düşündüğüm kısmına. Resim-10‘da göreceğiniz üzere şifreleme işlemi Collation değişikliği gerekiyor, şifrelenmiş kolonun Latin1_General_BIN2 olması isteniyor. Bu nedenle mevcut tablolarınızda bu işlemi yapacaksanız kolon bazlı da olsa Collation değiştirmek zorunda kalacağınızı unutmayın.


Resim-10

Master Key Configuration işlemini daha önce yaptığımız için direkt geçebiliriz. Collation da değiştirdik daha ne olsun derken bir uyarı daha alıyoruz. Yazma işlemi olan aktif bir tabloda bu işlemi yaparsanız veri kaybından sorumlu değilim diye bizi uyarıyor.


Resim-11

Şifreleme işlemi bittikten sonra SSMS üzerinden tablomuza sorgu çektiğimizde CitizenshipNo değerlerini Resim-12‘deki gibi deterministic olarak şifrelenmiş bir şekilde geldiğini görebilirsiniz. Her iki satırdaki CitizenshipNo verileri aynı.

Resim-12

Resim-13‘de ise randomized olarak şifrelenmiş halini görebilirsiniz. Her iki satırda da CitizenshipNo aynı değer olmasına rağmen farklı bir veri gibi görünüyor.


Resim-13

Verileri Şifreledik Peki Ya Sonra?

Veriler SSMS üzerinden de şifreli geliyor, ben verileri nasıl Decrypt edeceğim? İşte Always Encrypted’ın güzelliği tam burada başlıyor. Bu kısmı da uygulama üzerinden örnekle ilerleyelim.

Bu özellik ile çalışacak uygulamanızın mutlaka .NET Framework 4.6 ve üzeri ile derlenmesi gerekiyor. Çünkü Decrypt işini yapan aslında .NET Framework 4.6 ile gelen Enhanced ADO.NET. Özelliği aktif etmek için de ConnectionString üzerinde ColumnEncryptionSetting değerini SqlConnectionColumnEncryptionSetting.Enabled olarak yazmanız yeterli.


Resim-14

Şifreli kolonla ilgili sorguyu SQL Server’a gönderdiğimiz zaman bize CEK‘in şifreli halini ve CMK‘in nerede olduğu bilgisini gönderiyor. Eğer uygulamanın CMK‘in olduğu yere erişimi yoksa Resim-14‘deki hatayı alıyoruz. Söylenen yerde öyle bir anahtar bulamadığını belirtiyor. Örneğimizde console uygulamasını farklı bir sunucuda çalıştırdık.


Resim-15

Şimdi de uygulamayı SQL Server sunucusu üzerinde aynı kullanıcı ile çalıştıralım. CurrentUser altında belirtilen CMK‘e ulaşabildiği için bize şifreli verileri Decrypt ederek gösterebiliyor.


Resim-16

Biz bu uygulamayı çalıştırırken de meraklı DBA’imiz profiler üzerinden bizi izliyor olsun. Decrypt işlemini ADO.NET yaptığı için göreceği veriler de şifreli olacak.


Resim-17

SSMS üzerinden de verileri şifresiz olarak görmek için ise Resim-18‘deki gibi bağlanırken Additional Connection Parameters’a Column Encryption Setting=Enabled yazmamız ve tabi ki SSMS’i çalıştırdığımız kullanıcının CMK‘e erişebilir olması gerekiyor.


Resim-18

Bu özelliğin özellikle yine ile gelen Stretch Database özelliğini destekleyen; Azure’a sıcak bakan, kanunen bir kısıtlaması olmayan ama gizli verilerimi Azure adminler görülebilir endişesi taşıyanlar için oldukça kullanışlı olacağını düşünüyorum.

Bu konuyla ilgili sorularınızı https://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

https://www.mshowto.org

Yorum Yap

Yazar Hakkında

Mert Yeter, lisans eğitimini Yıldız Teknik Üniversitesi Gemi İnşaatı Mühendisliği bölümünde, yüksek lisans eğitimini ise Bahçeşehir Üniversitesi Bilgi Teknolojileri bölümünde tamamlamıştır. Yazılım dünyasına üniversitenin ilk yıllarında aldığı QBasic ile başlayan Mert, .NET ve SQL Server gibi Microsoft teknolojileri ile devam etmiş; yüksek lisans tezini ise Linux konusunda yapmıştır. Netaş ve Ziraat Teknoloji gibi sektörün önde gelen firmalarında C#, .NET, SQL Server, Cisco Contact Center ürünleri ve Linux üzerine çalışmış, bir çok firmaya da bu konularda danışmanlık vermiştir. Şu anda da Done'de Cloud Development Manager olarak Azure, .NET Core, SQL Server, Docker vb güncel teknolojiler üzerinde çalışmaktadır.

Yorum Yap

Yorumlar (1)

  1. Hocam dediklerinizin aynısını yapmama rağmen column şifrelenmiyor uyarısı alıyorum.