Veritabanı Güvenliği ve KVKK Teknik Tedbirleri

Yasal uyum sürecinin veritabanı boyutuna odaklanıyoruz #

6698 sayılı Kişisel Verilerin Korunması Kanunu, veri sorumlularını kişisel verileri korumak amacıyla teknik ve idari tedbirler almakla yükümlü kılıyor. Biz bu kapsamda, veritabanı katmanındaki teknik gereksinimlerin gerçekleştirilmesinde destek ve danışmanlık sunuyoruz.

Bununla birlikte, teknik tedbirlerin devreye alınması tek başına kurumsal uyumu sağlamaz. Veri envanteri, açık rıza yönetimi ve idari süreçlerin de kurumun hukuk danışmanlarıyla birlikte tamamlanması gerekir. Denetimlerde teknik sorular yöneltildiğinde yanıtlar doğrudan veritabanı mimarisinden beklenir. Bu nedenle idari süreçler eksiksiz olsa bile veritabanı katmanında hazırlığı bulunmayan kurumlarda denetim bulgusu oluşabilir.

Dört temel teknik önlemi veritabanında uyguluyoruz #

Disk üzerinde şifreleme (TDE) #

Standart MySQL Community Edition, kurumsal anahtar yönetim sunucularıyla entegrasyon sağlayan gelişmiş keyring eklentilerini içermiyor. Şifreleme anahtarının veritabanı sunucusu üzerinde yerel bir dosyada saklandığı yapı ise şifrelemenin amacını büyük ölçüde ortadan kaldırıyor. Bu nedenle kurumsal anahtar sunucularıyla (Vault vb.) tam entegre bir TDE mimarisi için açık kaynaklı Percona Server for MySQL sürümüne geçişi öneriyoruz.

PostgreSQL tarafında da benzer bir durum geçerlidir. PostgreSQL çekirdeğinde yerleşik TDE desteği bulunmuyor. Şifreleme yeteneğini pg_tde bileşeniyle sisteme kazandırıyoruz. pg_tde, bağımsız bir eklenti olmak yerine Percona Server for PostgreSQL dağıtımının bir parçası olarak çalışıyor. Dolayısıyla hem MySQL hem de PostgreSQL ortamlarında kurumsal disk şifreleme ihtiyacı kontrollü bir dağıtım geçişi gerektiriyor. Bu geçiş süreçlerini çalışan üretim ortamlarınızda kesinti riskini en aza indirerek titizlikle yürütüyoruz. Sürüm geçişlerini ise MySQL 8.4 migrasyonu sayfasında ayrıca ele alıyoruz.

Denetim kaydı (audit logging) #

KVKK denetimlerinde veritabanında saklanan kişisel verilere yönelik tüm erişimlerin sorgu düzeyinde belgelenebilmesi için denetim kaydı (audit logging) altyapısı kuruyoruz. Bu sayede kişisel verilere hangi kullanıcının, ne zaman ve hangi sorguyla eriştiğini ayrıntılı ve filtrelenebilir biçimde kayıt altına alıyoruz.

Standart MySQL Community sürümünde açık kaynaklı denetim eklentisi yer almadığı için MySQL ortamlarında Percona Server audit log bileşenini, PostgreSQL ortamlarında ise pgaudit eklentisini yapılandırıyoruz. Denetim loglarının kendisi de çalıştırılan sorgu parametreleri nedeniyle kişisel veri barındırabildiğinden, kayıtların saklama sürelerini, tutulacağı güvenli alanları ve loglara erişim yetkilerini de aynı güvenlik kapsamında planlıyoruz.

Veri maskeleme (data masking) #

Veri maskeleme sürecini hem canlı üretim veritabanlarında hem de test ve geliştirme ortamlarında iki yönlü olarak ele alıyoruz.

Canlı sistemlerde destek, operasyon veya raporlama amacıyla veritabanına bağlanan yetkisi kısıtlı kullanıcıların sorgularında hassas kişisel verilerin açık biçimde görüntülenmesini önlüyoruz. Kullanıcı ve rol tanımlarına uygun maskeleme modelleri kurgulayarak kritik verilerin yalnızca yetkili roller tarafından görülmesini sağlıyoruz.

Aynı zamanda yazılım geliştirme, test ve analiz ortamlarına veri aktarırken gerçek kişisel verilerin bu ortamlara kontrolsüz yayılmasını engelliyoruz. MySQL tarafında Percona Server data masking fonksiyonlarını, PostgreSQL tarafında ise PostgreSQL Anonymizer eklentisini yapılandırıyoruz. Böylece yazılım testlerinin ihtiyaç duyduğu veri tutarlılığını bozmadan, kişisel verilerden arındırılmış güvenli ortamlar oluşturuyoruz.

Saklama ve imha #

Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik, saklama süresi tamamlanan kişisel veriler için periyodik imha süreçlerinin işletilmesini öngörüyor. Veritabanı katmanında asıl teknik zorluk basit bir silme komutu çalıştırmak değil, veritabanının ilişkisel veri yapısını ve bütünlüğünü bozmadan bu işlemi gerçekleştirebilmektir.

Özellikle yüksek hacimli üretim veritabanlarında performans nedeniyle foreign key (FK) kısıtlamaları tanımlanmadığında, ana tablodan silinen bir kaydın ilişkili diğer tablolardaki kişisel verileri sistemde kalabiliyor. Bu durumda kurumlar, ilişkili tüm tablolardan verileri tutarlı biçimde temizleyecek özel arşivleme ve imha mekanizmaları geliştirmek zorunda kalıyor.

MySQL ortamlarında saklama süresi dolan verilerin arşivlenmesi ve imhası süreçlerini kendi geliştirdiğimiz açık kaynak ürünümüz GoArchive ile çözüyoruz. GoArchive, tablolar arasındaki ilişkisel bağı takip ederek ilgili kayıtları hedef sisteme eksiksiz taşıyor ve verinin ulaştığını doğruladıktan sonra ana tablolardan güvenle temizliyor. Yönetmeliğin zorunlu kıldığı denetlenebilir imha kaydı, bu doğrulama adımıyla sağlanabilmektedir. PostgreSQL ve MongoDB altyapılarında ise saklama ve imha süreçlerini sistemlerin yerleşik araçları ve planlı bakım senaryolarıyla kurguluyoruz.

MongoDB sistemlerinde teknik önlemleri yapılandırıyoruz #

MongoDB altyapılarında da şifreleme, denetim kaydı, erişim yetkilendirmesi ve imha gereksinimleri aynı önemle geçerliliğini koruyor. Ancak standart MongoDB Community sürümünde yerel denetim kaydı ve disk üzerinde şifreleme yetenekleri yer almıyor. Bu güvenlik özelliklerini Percona Server for MongoDB dağıtımı üzerinden açık kaynaklı olarak müşterilerimizin sistemlerine kazandırıyoruz. Dağıtım orijinal MongoDB ile tam uyumlu çalıştığı için geçiş aşamasında uygulama katmanında herhangi bir kod değişikliği gerekmiyor.

Erişim denetimini en az yetki (least privilege) kuralına göre rol tabanlı olarak kuruyoruz. Sahada sıklıkla karşılaştığımız sorunlardan biri, uygulamaların veritabanına yönetici yetkileriyle bağlanmasıdır. Koleksiyon düzeyinde yetkilendirme yapılmadığında, denetim kayıtları da hangi işlemin kim tarafından yapıldığını ayırt edemez duruma geliyor. Ayrıca düğümler arası ve istemci bağlantılarında TLS şifrelemesini yapılandırarak ağ trafiğini koruma altına alıyoruz.

Veri saklama ve imha süreçlerinde ise MongoDB’nin belge (document) modeli belirli operasyonel kolaylıklar sağlıyor. İlişkili verilerin tek bir belge içinde toplandığı (embedded) tasarımlarda belgenin silinmesi ilişkili tüm verileri kapsıyor. Buna karşılık, verilerin referanslarla ayrıştırıldığı modellerde ilişkili kayıtların birlikte ve doğrulanarak silinmesi için ilişkisel sistemlerdeki gibi dikkatli bir imha planı uyguluyoruz.

İlgili hizmetler #

TDE ile şifrelenen veritabanlarında yedekleme türüne göre güvenlik ve kurtarma süreçleri farklılık gösterir:

• Fiziksel yedeklerde (XtraBackup, pgBackRest, pg_basebackup): Veritabanında TDE aktif olduğunda diskteki veri blokları doğrudan kopyalandığı için alınan yedek dosyaları da otomatik olarak şifreli oluşturulur. Ancak bu yedeklerin geri yüklenebilmesi (restore) için şifreleme anahtarlarının (keyring) da kurtarma planına dahil edilmesi ve güvenle saklanması gerekir.
• Mantıksal yedeklerde (mysqldump, pg_dump, mydumper): Veri SQL istemcisi üzerinden sorgulanarak çekildiği için dump dosyalarına açık metin (şifresiz) olarak yazılır. Bu nedenle alınan mantıksal yedeklerin depolama alanında ayrıca şifrelenmesi ve erişim yetkilerinin sıkı şekilde kurgulanması zorunludur.

Şifreli veritabanlarının yedekleme ve kurtarma planını bu ayrımı gözeterek kurguluyoruz: Veritabanı Yedekleme ve Kurtarma

Şifreleme ve denetim kaydı yapılandırmalarının cluster düğümlerinin tamamına tutarlı biçimde dağıtılması gerekir: Yüksek Erişilebilirlik ve Cluster Çözümleri

Güvenlik eklentilerinin ve denetim kayıtlarının sistem performansına etkisini düzenli ölçümlerle takip ediyoruz: Performans Optimizasyonu ve İzleme