Always Encrypted Nedir ve Nasıl Kullanılır?

Always Encrypted SQL Server 2016 ile gelen bir güvenlik çözümüdür. Bu çözüm ile uygulama geliştiriciler kolonları client tarafında şifreleyebiliyorlar. Böylece instance üzerinde sysadmin olan biri bile bu kolonların içeriğini göremiyor.

 

Daha öncesinde kolon bazlı şifreleme ile kolonlarımızı şifreleyebiliyorduk ama bu işlem server tarafında yapıldığı için instance üzerinde sysadmin hakkına sahip kullanıcılar veriye erişebiliyordu.

 

Kolon bazlı şifreleme hakkındaki detayları “Kolon Seviyesinde Şifreleme(Column Level Encryption)” isimli makalede bulabilirsiniz.

 

Kolon bazlı şifrelemenin bir adım ötesinde TDE kullanarak veritabanının tamamını da şifreleyebilirsiniz. TDE hakkında detaylı bilgiyi de “TDE(Transparent Data Encryption) Nedir ve Nasıl Oluşturulur” isimli makalemde bulabilirsiniz.

 

Şifrelemeyle ilgili diğer bir konuda şifreli backup almaktadır. “Şifreli(Encrypted) Backup Almak” isimli makalemde detaylarını bulabilirsiniz.

 

Veritabanındaki objeleri şifrelemek isterseniz “Objeleri Şifrelemek(SP,Function,View)” isimli makalemi okuyabilirsiniz.

 

Always Encrypted iki tip key ile çalışır.

Column Encryption Key

Kolonları şifrelemek için kullanılan key’dir. SQL Server üzerinde tutulur.

 

Column Master Key

Bir ya da birden fazla Column Encryption Key’leri şifreler.

 

Client’ın(Uygulama sunucusu) erişebileceği bir yerde tutulur. (Azure Key Vault, Uygulama Sunucusu üzerindeki Windows Certificate Store veya hardware security module.)

SQL Server üzerinde tutulmaz.

 

Column Master Key SQL Server üzerinde tutulmadığı için ve Column Encryption Key ile şifrelenmiş veride bu key olmadan açılamayacağı için bir üst seviye güvenlik çözümü sağlanmış olur. Veriler uygulama sunucusundan sql server’a şifreli bir şekilde gider ve sql server’dan uygulama sunucusuna şifreli bir şekilde gelir. Uygulama sunucusunda ADO.NET kütüphanesi Column Master Key’i kullanarak şifreyi çözer ve uygulamanın veriyi şifresiz haliyle görmesini sağlar. Bu şekilde verinin network üzerinden de şifreli akışı sağlanmış olur.

 

 

Konuyu daha detaylı anlayabilmeniz ve detayları inceleyebilmek için bir örnek yaparak devam edelim.

 

Kurulum işlemini gerçekçi olması açısından uygulama sunucusu üzerinden gerçekleştireceğiz.

 

Uygulama sunucusu üzerinden SSMS’i kullanarak veritabanı sunucusuna bağlanalım ve aşağıdaki script’i çalıştıralım.

USE Test
GO
CREATE TABLE AlwaysEncrypted
(
       Id int identity(1,1) PRIMARY KEY,
       AdSoyad varchar(250),
       TCKimlikNo varchar(11)
)
INSERT INTO AlwaysEncrypted VALUES ('Nurullah ÇAKIR','12345678901'),
                                   ('Faruk ERDEM','12345678902')
SELECT * FROM AlwaysEncrypted

 

Script’i çalıştırdıktan sonra gördüğünüz gibi kayıtlarımız şifresiz bir şekilde geldi. Bu tablodaki kişisel verilerin korunması kanunu gereğinde AdSoyad ve TCKimlikNo kolonlarını şifreleyelim.

 

Şifrelemek istediğimiz kolonların bulunduğu tabloya aşağıdaki gibi sağ tıklayarak Encrypt Columns… diyoruz.

 

Karşımıza gelen ekranda Always Encrypted’ın SQL Server veritabanında tutulan bazı bilgileri korumak için dizayn edildiğini ve şifrelemenin uygulama tarafında yapıldığını belirten bir açıklama yer alıyor. Do not show this page again diyerek ilerleyebilirsiniz.

 

Bir sonraki ekranda şifrelemek istediğimiz kolonları seçiyoruz.

 

Encryption Type kısmında Deterministic ya da Randomized seçenekleri karşımıza çıkıyor.

 

Deterministic: aynı verileri aynı şekilde şifreler. Örneğin veritabanında bir yerde Ahmet verisi varsa ve şifreleme işlemini ‘gferty’ olarak gerçekleştiriyorsa veritabanındaki başka bir Ahmet değerini de yine ‘gferty’ olarak şifreleyecektir. Eğer deterministic şifrelemeyi seçerseniz veriyi ele geçiren biri üzerinde çalışarak şifreleme modelini keşfedebilir. Diğer yandan sıralama, gruplama, birleştirme ve indeksleme işlemlerini gerçekleştirebilirsiniz.

 

Randomized: Veriyi daha az tahmin edilebilir bir şekilde şifreler fakat sıralama, gruplama, birleştirme ve indeksleme işlemlerini gerçekleştiremezsiniz. Örneğin veritabanında bir yerde Ahmet verisi varsa ve şifreleme işlemini ‘gferty’ olarak gerçekleştiriyorsa veritabanındaki başka bir Ahmet değerini bu sefer  başka bir değer olarak şifreleyecektir. Örneğin ‘dasdfg’

Encryption Key kısmında AdSoıyad ve TCKimlikNo için CEK_Auto1(New) isminde yeni bir Encryption Key oluşturacağını belirtiyor.

 

Bir sonraki ekranda master key’in windows certificate store üzerinde mi yoksa Azure Key Vault üzerinde mi tutulacağını soruyor. Örneğimizde default değer olan Windows certificate store’u seçiyoruz.

 

Master Key ile veriye sadece kurulumu yapan kullanıcımızla erişmek istersek Current User’ı, uygulama sunucusu üzerinde yetkisi olan tüm kullanıcılar ile erişmek istersek Local Machine’i seçiyoruz. Bir Current User’ı seçerek devam ediyoruz.

 

Encryption Key’i ve Master Key’i wizard yerine veritabanı altındaki Security sekmesinden aşağıdaki ekranda görüldüğü gibi de oluşturabilirsiniz.

 

 

Master Key’i wizard yerine SSMS üzerinden yukardaki gibi oluşturduğumuzda master key’in saklanabileceği alan olarak Windows Cetificate Store ve Azure Key Vault haricinde aşağıdaki gibi iki seçenek daha karşımıza çıkar.

 

Wizard’a geri dönerek işlemlerinizi next next diyerek tamamlayabilirsiniz.

 

Kurulum sonrasında Uygulama içersinden verilere şifresiz bir şekilde erişmek için connection string’e “Column Encryption Setting=ENABLED” ifadesini eklemelisiniz.

 

 

Uygulama sunucusundan SSMS ile verilerin şifresiz haline erişmek isterseniz SSMS üzerinde Options/Additional Connection Parameters sekmesine “Column Encryption Setting=ENABLED” ifadesini eklemelisiniz.

 

Biz örneğimizde sadece kurulum yaptığımız kullanıcı ile encryption işlemini gerçekleştirdiğimiz için başka bir kullanıcı ile SSMS üzerinden  Options/Additional Connection Parameters sekmesine “Column Encryption Setting=ENABLED” ifadesini eklediğimizde aşağıdaki gibi hata alırsınız.

 

Msg 0, Level 11, State 0, Line 0

Failed to decrypt column ‘AdSoyad’.

Msg 0, Level 11, State 0, Line 0

Failed to decrypt a column encryption key using key store provider: ‘MSSQL_CERTIFICATE_STORE’. The last 10 bytes of the encrypted column encryption key are: ’69-EE-09-F8-E3-90-F7-3A-84-FE’.

Msg 0, Level 11, State 0, Line 0

Certificate with thumbprint ” not found in certificate store ‘My’ in certificate location ‘CurrentUser’. Verify the certificate path in the column master key definition in the database is correct, and the certificate has been imported correctly into the certificate location/store.

Parameter name: masterKeyPath

 

Benim bütün DBA’lere tavsiyem tüm uygulama sahipleriyle görüşüp tüm kritik verilerini bu yapıya geçirmeleri olur. Çünkü veri hassas bir konudur ve veriye sadece verinin sahibinin erişmesi gerekir. Kısaca microsoft’un da bu özellikle ilgili söylediği gibi verinin sahibinin ve veriyi yönetenin ayrışması gerekmektedir.

  • ALTER ANY COLUMN MASTER KEY (master key’i oluşturmak ve silmek için gereklidir.)
  • ALTER ANY COLUMN ENCRYPTION KEY (column encryption key’i oluşturmak ve silmek için gereklidir.)
  • VIEW ANY COLUMN MASTER KEY DEFINITION (column master key’in metadata’sını okumak için gereklidir.)
  • VIEW ANY COLUMN ENCRYPTION KEY DEFINITION (column encryption key’in metadata’ını okumak için gereklidir.)

 

Always Encrypted çözümünde isterseniz column master key’i yeniden oluşturabilirsiniz. Detaylar için “Column Master Key Rotasyon İşlemi(Always Encrypted)” isimli makaleyi okuyabilirsiniz.

Loading

2 Comments

  1. Çok güzel bir makale olmuş, elinize sağlık.Ben sysadmin yetkisi olmayan başka bir kullanıcı ile SSMS üzerinden \”Column Encryption Setting=ENABLED\” yaptığımda hata almadım. Nedeni ne olabilir?

    1. NURULLAH ÇAKIR says:

      Masster Key ile veriye sadece kurulumu yapan kullanıcımızla erişmek istersek Current User’ı, uygulama sunucusu üzerinde yetkisi olan tüm kullanıcılar ile erişmek istersek Local Machine’i seçiyoruz. Siz burada hangi seçimi yaptınız?

Leave Your Comment