16 Ocak 2017 Pazartesi

Transparent Data Encryption ile tempdb ilişkisi

Transparent Data Encryption (TDE) özelliğini sanırım tüm SQL Server veritabanı yöneticileri duymuştur. SQL Server 2008 ile gelen bir özellik. Veritabanı dosyalarını ve yedek dosyalarını şifrelemek için kullanılan bir güvenlik yöntemi.

Geçenlerde ingilizce SQL Server Database Engine Microsoft forumunda bir kullanıcı test ortamındaki bazı veritabanları için TDE'yi etkinleştirdiğini fakat testlerden sonra TDE özelliğini ilgili veritabanlarından kaldırdığı halde tempdb'nin hala şifreli olduğunu ve bunu nasıl kaldıracağını sordu. Ben de test ortamımda bunun testini yaptım, kullanıcıya cevabını verdim ve bu konuda kısa bir blog yazısıyla sizlerle de paylaşmak istedim. Bu yazımda TDE'nin nasıl etkinleştirileceğine veya kullanılacağına değil, tempdb ile olan ilişkisine değineceğim.

"TDE veritabanı bazında etkinleştirilen bir özellik, tempdb ile ne alakası var?" diye soracak olursanız "sonuç itibariyle tempdb tüm veritabanları tarafından ve SQL Server tarafından kullanılan ortak bir alan, eğer bir veritabanını TDE ile şifreliyorsanız o zaman demek ki kayıtlar hassastır ve yanlış ellere geçmesini istemiyorsunuzdur, bu nedenle de verinin işlenme sürecinin bir kısmının şifresiz yapılmasını da istemezsiniz" derim. Bu iş bir bütün nihayetinde, bu nedenle TDE ile şifrelediğiniz bir veritabanındaki bir kod ile tempdb veritabanında temp bir tablodaki kayıtların da şifreli olması gerekir ve sonuç itibariyle SQL Server Instance'ında tek bir tane tempdb vardır. Bu nedenle bir SQL Server Instance'ında eğer bir tane veritabanını bile TDE ile şifrelerseniz, tempdb de otomatik olarak şifrelenir.

Peki SQL Server Instance'ınızda TDE ile şifrelenmiş veritabanlarını nasıl görebilirsiniz?

SELECT [is_encrypted], [name] FROM sys.databases WHERE [is_encrypted] = 1;
GO

Eğer SQL Server 2014 SP2 (ve muhtemelen bazı başka versiyonlar da) kullanıyorsanız "Ama sen daha az önce 'bir veritabanı TDE ile şifrelendiyse tempdb de şifrelenir' demiştin? Bu listede tempdb'yi göremiyorum?" diyebilirsiniz diye tedbirliyim, çünkü benim test ortamımda SQL Server 2014 SP2 var ve bende tempdb veritabanı yukarıdaki sorgu ile [is_encrypted] = 1 olarak görünmüyor... Bu hata için de açılan hata kaydı burada

Peki diyelim ki önceden TDE'yi etkinleştirdiğiniz, ama sonra herhangi bir sebeple bundan vazgeçip kaldırdığınız bir üretim ortamınız var. TDE'yi ilgili tüm canlı veritabanlarından kaldırdınız, peki ya tempdb? tempdb'nin şifrelemesi de kalktı mı dersiniz? Eğer SQL Server Database Engine servisinizi henüz kapatıp açmadıysanız kalkmadı efendim! "Peki yukarıdaki sorgu da işe yaramıyor, nereden anlayacağım bunu?" diye soruyorsunuz haliyle "aşağıdaki sorguyu kullanabilirsiniz" diyorum.

SELECT DB_NAME(database_id) AS [database_name], [encryption_state] FROM sys.dm_database_encryption_keys WHERE [encryption_state] = 3;

Eğer yukarıdaki sorgu sonucunda tempdb yoksa, o zaman demektir ki bu SQL Server Instance'ında TDE ile şifrelenmiş hiçbir veritabanı yoktur ve tempdb'niz de şifreli değildir. Eğer [encryption_state] = 1 olan veritabanınız varsa ise o zaman veritabanında Database Encryption Key var, ama veritabanı TDE ile aktif olarak şifrelenmemiş demektir. Eğer olur da daha farklı rakamlar görürseniz o zaman daha fazla bilgi için sizi dokümantasyona davet ediyorum.

Bunca curcunadan sonra gelgelelim "TDE'yi veritabanları için kapattıysak neden tempdb için bu kadar kaygılanalım ki?" sorusunun cevabına. Efendim baştan da dediğim gibi, tempdb ortak bir alan ve siz başka veritabanları için TDE'yi etkinleştirmemiş olsanız bile, hatta tüm veritabanlarından TDE'yi kaldırmış olsanız bile tempdb hala şifrelenmeye devam edecek, şayet SQL Server Database Engine servisi yeniden başlatılana kadar. Yani artık o SQL Server Instance'ında kaç tane veritabanınız varsa, tempdb'de ne kadar işlem yapılıyorsa, tüm o işlemler şifrelenerek yapılacak. Bunun tabii ki bir performans bedeli var. Durduk yere, TDE kullanmıyorken bu bedeli neden ödeyesiniz? Bu yazı da işte bu konuda sizleri uyarmak içindi.

Bu yazıyı yazdıktan sonra Microsoft Azure'da test amacıyla bulunan ve üstünde SQL Server 2016 SP1 olan sanal makinemde de aynı testi yaptım. Aynı test, SQL Server 2014 SP2 ve SQL Server 2016 SP1'de ayrı ayrı hataları (Bug) ortaya çıkardı. Microsoft'tan yapılan yorumlara göre bu hatalar "metadata" düzeyindeki hatalar. Yani [is_encrypted]'ın sonucu 0 olacağına 1 oluyor, ama aslında arkaplanda her şey düzgün çalışıyor şeklinde oldu. Bu konuda Microsoft'a açtığım hata kaydının ayrıntıların buradan ulaşabilirsiniz.

Sevgiler,
Ekrem Önsoy

Hiç yorum yok: