Veritabanında Kişisel Verilerin Saklanması

Merhaba, bu makalemde kişisel verilerin veritabanında nasıl saklanması gerektiğinden ve bu konuda MSSQL Server’ın hangi seçenekleri sunduğundan bahsedeceğim.

Avrupa Birliği ülkelerinde uygulanmaya başlanan GDPR‘a karşılık olarak ülkemizde hayata geçirilen KVKK kapsamında kişisel verilerin işlenmesiyle alakalı yasalar uygulamaya konuldu. Bir işletmenin müşterilerine veya kullanıcılarına ait bilgilerinin hiç kimseyle (sözleşmede aksi belirtilmedikçe) paylaşılmaması gerekiyor. Bu kapsamda, örneğin development ortamında geliştirme yapan bir yazılımcı veya veritabanı yöneticisi bu bilgilere erişemiyor olmalıdır. Bu tarz durumlarda genelde veriler anlamsızlaştırılır. Yani örneğin kişinin adı ve soyadı bilgilerine “Ad Soyad” gibi gerçek olmayan isimler yazılabilir veya “K*** K***” şeklinde maskeleme uygulanabilir; ancak bazı durumlarda gerçek bilgi kullanılması zorunludur veya söz konusu ortam production, yani canlı ortamdır. Canlı ortamda “Ad Soyad” veya “K*** K***” şeklinde veri saklayamazsınız. Dolayısıyla veritabanındaki verilerin, hem veritabanına erişimi olan kullanıcılardan hem de oluşabilecek veri ihlali gibi durumlardan korunabilmesi için şifrelenmesi gerekmektedir.

SQL Server veritabanında bu konu için iki farklı çözüm sunulmaktadır: server side (sunucu tarafında) ve client side (istemci tarafında). Sunucu tarafında sunulan sistem nispeten daha eski ve daha olgun (SQL Server 2008’den beri) olan Transparent Database Encryption (TDE) veya Cell Level Encryption (CLE). Diğer taraftan, istemci tarafında ve daha yeni olan yöntem ise Always Encrypted. İki yöntemde de uygulama tarafında büyük değişiklikler yapmak gerekmiyor. Basit bir connection string değişikliği ve/veya sunucuya sertifika yüklenmesi gibi bazı operasyonel işlemler yeterli oluyor. Şimdi bu yöntemleri biraz daha yakından inceleyelim.

Transparent Database Encryption

Bu yöntemde veritabanının tamamı veya seçilen kolonlar şifrelenir. Tüm veritabanı şifrelenirse TDE, bazı kolonlar şifrelenirse CLE adını alır. Tüm şifreleme ve şifre çözme işlemleri SQL Server veritabanı tarafından gerçekleştirilir. Dolayısıyla uygulama sunucusundan açık şekilde çıkan veriler tüm ağ boyunca açık olarak iletilir ve en son veritabanına şifrelenmiş olarak yazılır. Ağ üzerinde açık olarak iletilmesinden kasıt, verinin şifrelenmemiş olmasıdır; ancak sunucular arasındaki iletişim https veya alternatif bir şifrelenmiş bağlantı ile sağlanıyor olabilir.

Şifreleme işlemi veritabanı üzerinde yapıldığından şifreli tablo veya kolonlarda karmaşık sorgular çalıştırılabilir. Şifrelenmiş kolonlarda eşitlik araması yapılabilir; ancak diğer aramalar (büyüktür, küçüktür veya like ifadesi gibi) full table scan yapacağı için yani tüm tablo taranacağı için sorgular oldukça yavaş çalışacaktır.

Always Encrypted

Bu yöntemde veri, veritabanına gönderilmeden önce şifrelenir. SQL sunucusuna gönderilen tüm isteklerde araya giren bir Windows sürücüsü bulunur. Bu sürücü, ilgili kolonlara ait verilerin şifrelenmesinden ve şifrelerinin çözülmesinden sorumludur. Yani veritabanına gönderilen sorgular değiştirilir. Dolayısıyla veriler uygulama sunucusundan şifrelenmiş şekilde çıkar ve ağ üzerinde şifrelenmiş olarak iletilir.

Şifreleme işlemi uygulama sunucusu üzerinde yapıldığından ve sql cümlelerinin yeniden oluşturulması gerektiğinden çok karmaşık sorgular için bu yöntemi kullanmak pek uygun değildir. Bu yöntemle şifrelenmiş kolonlarda eşitlik haricinde arama yapılamaz (where koşulu yazılamaz). Yani büyüktür (>), küçüktür (<) veya “like” gibi ifadeler kullanılamaz. Ayrıca eğer deterministik şifreleme kullanılmamışsa eşitlik araması da yapılamaz.

Sonuç

KVKK kapsamında bazı aksiyonlar alınması gerektiği kesin ve bu kapsamda mecburen bazı kolonların şifrelenmesi gerekiyor. Yukarıdaki iki yöntem de şifreleme için kullanılabilir; ancak her zamanki gibi güvenlikten kazanırken performanstan ödün vermeniz gerekiyor. Buradaki ve buradaki linklerde şifrelemenin performansa etkisini görebilirsiniz. İki yöntemde de neredeyse %60 civarında performans kaybı yaşanıyor. Dolayısıyla kolaya kaçıp tüm kolonları şifrelemek yerine detaylı bir analiz yapıp gerçekten gerekli olan kolonların şifrelenmesi gerekmekte. Ayrıca şifreleme işlemleri sonrasında geniş çaplı bir yük testi yapmakta da fayda var.

Benzer Makaleler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*

warning
www.kemalkefeli.com.tr üzerindeki herhangi bir yazının veya kodun izinsiz olarak başka bir yerde kullanılması yasaktır.