Veritabanı Güvenliği ve KVKK Teknik Tedbirleri

Bir KVKK denetiminde yöneltilen teknik sorular veritabanı katmanında yanıtlanır: veri disk üzerinde şifreli mi, kişisel veriye kim erişti, üretim dışı ortamlarda gerçek veri bulunuyor mu, saklama süresi dolan kayıtlar imha edildi mi?

Sinan Alyuruk Kurucu — MySQL ve PostgreSQL danışmanı

KVKK teknik tedbirlerini uçtan uca kuruyoruz

Şifreleme, denetim kaydı, veri maskeleme ve imha; bir denetimde tek tek değil birlikte sorulur. Dördünü MySQL ve PostgreSQL üzerinde tek bir mimari olarak kurgularız.

Şifreleme (TDE)

Veri, disk üzerinde şifrelenmiş olarak saklanır. MySQL tarafında InnoDB şifrelemesi ve keyring yönetimini, PostgreSQL tarafında pg_tde bileşenini yapılandırıyoruz. Anahtar yönetimini kurumsal anahtar sunucunuza entegre ediyoruz.

Denetim kaydı (audit logging)

Kişisel veriye kimin, ne zaman ve hangi sorguyla eriştiği kayıt altına alınır. MySQL tarafında Percona Server audit log, PostgreSQL tarafında pgaudit kullanıyoruz. Kayıtların saklanması ve erişim denetimi de aynı kapsamda yapılandırılır.

Veri maskeleme (data masking)

Test, geliştirme ve analiz ortamlarına gerçek kişisel veri kopyalanmaz. MySQL tarafında Percona Server data masking, PostgreSQL tarafında PostgreSQL Anonymizer ile üretim dışı ortamları gerçekçi ancak kimliksizleştirilmiş veriyle besliyoruz.

Saklama ve imha

Saklama süresi dolan kişisel veri, ilişkili kayıtlarıyla birlikte ve doğrulanabilir biçimde sistemden çıkarılır. MySQL tarafında süreci kendi ürünümüz GoArchive ile yürütüyoruz.

Teknik tedbirler, uyumun tamamını oluşturmaz

6698 sayılı Kişisel Verilerin Korunması Kanunu, veri sorumlusunu kişisel veriyi korumak amacıyla teknik ve idari tedbirler almakla yükümlü kılar. Kişisel Verileri Koruma Kurulu’nun yayımladığı rehberler iki tedbir grubunu ayrı ayrı ele alır. Bu sayfa yalnızca teknik tedbirlerin veritabanı katmanına düşen bölümünü kapsar.

Kapsamı baştan belirtmemizin nedeni, sahada en sık karşılaştığımız yanlış değerlendirmedir: şifreleme etkinleştirildiği için uyumun sağlandığının varsayılması. Şifreleme tek başına uyum sağlamaz. Ancak bir denetimde teknik sorular yöneltildiğinde yanıtların büyük bölümü veritabanı katmanında verilir; kurum veritabanı katmanına hazırlıksız girdiğinde, diğer tüm süreçler eksiksiz olsa dahi bulgu yazılır.

Dört teknik tedbir nasıl uygulanır

Şifreleme

MySQL tarafında InnoDB şifrelemesi çekirdekte yer aldığı için çalışma, anahtar yönetiminin doğru kurgulanmasına odaklanır. Şifreleme anahtarının veritabanı sunucusu üzerinde saklandığı bir kurulum, şifrelemenin amacını büyük ölçüde ortadan kaldırır.

PostgreSQL tarafı farklı bir yaklaşım gerektirir: PostgreSQL çekirdeği TDE (Transparent Data Encryption) desteği içermez. Şifreleme yeteneği pg_tde bileşeniyle sağlanır ve pg_tde, Percona Server for PostgreSQL dağıtımının parçasıdır. Dolayısıyla “PostgreSQL tarafında şifrelemeyi etkinleştirelim” talebi, çoğu senaryoda bir dağıtım geçişi projesine karşılık gelir. Geçiş sürecini uçtan uca yürütüyoruz.

Denetim kaydı

Denetimlerde yöneltilen soru “kayıt tutuyor musunuz” değil, “ilgili kişinin verisine kim erişti” biçimindedir. Yanıt verebilmek için sorgu düzeyinde kayıt tutulması ve kayıtların okunabilir biçimde saklanması gerekir. MySQL tarafında Percona Server’ın audit log bileşenini, PostgreSQL tarafında pgaudit eklentisini yapılandırıyoruz. Kayıtların nereye yazıldığını, ne kadar süreyle saklandığını ve kimlerin erişebileceğini de aynı kapsamda kurguluyoruz; denetim kayıtlarının kendisi de kişisel veri içerdiği için ayrı bir koruma gerektirir.

Veri maskeleme

Üretim yedeğinin test ortamına açılması, kişisel verinin kontrolsüz çoğaltılmasının en yaygın yoludur ve genellikle risk olarak değerlendirilmez. MySQL tarafında Percona Server’ın maskeleme fonksiyonlarını, PostgreSQL tarafında PostgreSQL Anonymizer eklentisini kullanarak üretim dışı (non-production) ortamları gerçekçi ancak kimliksizleştirilmiş veriyle besliyoruz. Maskeleme kurgusunun temel şartı, veri dağılımının korunması ve test süreçlerinin bozulmamasıdır.

Saklama ve imha

Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik, saklama süresi dolan veriler için periyodik imha yükümlülüğü öngörür. Veritabanı katmanında zorluk silme işleminin kendisinde değil, verinin ilişkili kayıtlarıyla birlikte ve doğrulanarak silinmesindedir: bir kayıt silinirken ona bağlı satırlar sistemde bırakıldığında hem yetim veri hem de eksik bir imha süreci ortaya çıkar.

MySQL tarafında saklama süresi dolan verilerin arşivlenmesini kendi ürünümüz GoArchive ile yürütüyoruz. GoArchive ilişkili kayıtları birlikte taşır, hedef sisteme eksiksiz ulaştığını doğrular ve yalnızca doğrulama başarılı olduğunda kaynaktan siler. İmha yükümlülüğünün gerektirdiği denetlenebilir iz de bu doğrulama adımından doğar. PostgreSQL tarafında eşdeğer bir ürünümüz bulunmuyor. İlgili saklama süreçlerini mevcut araçlarla kurguluyoruz.

MongoDB tarafında teknik tedbirler

MongoDB kurulumlarında aynı dört başlık geçerlidir, ancak araçlar farklıdır. Denetim kaydı ve disk üzerinde şifreleme MongoDB Community Edition’da yer almaz; her ikisi de Percona Server for MongoDB dağıtımı üzerinden yapılandırılır. Dağıtım aynı çekirdek üzerine kuruludur ve geçiş uygulama tarafında değişiklik gerektirmez.

Erişim denetimini rol tabanlı olarak, en az yetki ilkesine göre kuruyoruz. Sahada en sık karşılaştığımız bulgu, uygulamanın veritabanına yönetici yetkisiyle bağlanmasıdır; koleksiyon düzeyinde yetkilendirme yapılmadığında denetim kayıtları da kimin ne yaptığını ayırt edemez hâle gelir. Düğümler arası ve istemci bağlantılarında TLS’i zorunlu hâle getiriyoruz.

Saklama ve imha tarafında MongoDB’nin belge modeli işi bir yönden kolaylaştırır: ilişkili verinin belgeye gömülü olduğu tasarımlarda tek bir silme işlemi tüm kaydı kapsar. Referansla ayrıştırılmış tasarımlarda ise ilişkili kayıtların birlikte ve doğrulanarak silinmesi, ilişkisel veritabanlarındaki kadar dikkatli planlama gerektirir.

Dağıtım geçişi neden gündeme gelir

Yukarıdaki teknik tedbirlerin bir bölümü, MySQL Community Edition ve standart PostgreSQL kurulumlarında yer almaz. Şifreleme, denetim kaydı ve veri maskeleme yetenekleri çoğunlukla Percona dağıtımlarının açık kaynak bileşenleriyle veya pgaudit ve PostgreSQL Anonymizer gibi topluluk eklentileriyle sağlanır.

Bu nedenle çalışmanın önemli bir bölümünü geçiş süreci oluşturur: MySQL Community Edition’dan Percona Server’a, standart PostgreSQL’den Percona Distribution for PostgreSQL dağıtımına veya MongoDB Community Edition’dan Percona Server for MongoDB dağıtımına geçiş. Bu geçişleri üretim sistemlerinde, veri kaybı olmadan, planlanmış bakım pencerelerinde ve geri dönüş senaryosu tanımlanmış şekilde yürütüyoruz. Sürüm geçişleri konusunda MySQL 8.0’dan 8.4’e migrasyon sayfamız da ilgili olabilir.

Kullandığımız bileşenlerin hiçbirinin üreticisiyle ticari ilişkimiz bulunmamaktadır. Tüm bileşenler açık kaynak lisansa sahiptir; firmamızın sunduğu hizmet, bileşenleri çalışan bir sisteme doğru biçimde yerleştirmek ve sonrasında işletilebilir durumda tutmaktır.

İlgili hizmetler

Şifrelenmiş bir veritabanının yedek dosyaları da şifrelenmelidir. Denetimlerde en sık tespit edilen bulgulardan biri, üretim veritabanı şifreliyken yedeklerin korumasız saklanmasıdır: Veritabanı Yedekleme ve Kurtarma

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

Veritabanı destek hizmetlerimiz

KVKK teknik tedbirlerini uyguladığımız veritabanlarında destek ve danışmanlık hizmetlerimizin tamamını sunuyoruz.

MySQL Destek

Performans, cluster, yedekleme ve güvenlik başlıklarının tamamı tek kapsamda; Percona Server geçişi dahil.

PostgreSQL Destek

Patroni cluster kurulumu ve yönetimi, pgBackRest ile yedekleme, sorgu ve yapılandırma optimizasyonu.

MongoDB Destek

ReplicaSet ve sharding kurulumu, indeks ve şema tasarımı, izleme altyapısı ve bakım.

Sık sorulan sorular

Hayır. KVKK uyumu teknik tedbirlerden ibaret değildir; veri envanteri, aydınlatma yükümlülüğü, açık rıza yönetimi, idari tedbirler ve kurumsal süreçler de uyumun ayrılmaz parçalarıdır. Firmamız, teknik tedbirlerin veritabanı katmanına düşen bölümünü kurar ve işletir. Uyum değerlendirmesi veri sorumlusunun ve hukuk müşavirinin sorumluluğundadır. Firmamız hukuk bürosu değildir ve hukuki danışmanlık hizmeti vermez.

PostgreSQL çekirdeği TDE (Transparent Data Encryption) desteği içermez. Şifreleme yeteneği pg_tde bileşeni ile sağlanır; bu bileşen mevcut bir kuruluma eklenti olarak takılmaz, Percona Server for PostgreSQL dağıtımının parçası olarak gelir. Dolayısıyla PostgreSQL tarafında şifreleme çoğu zaman bir dağıtım geçişi projesi anlamına gelir. MySQL tarafında InnoDB şifrelemesi çekirdekte yer aldığı için benzer bir geçiş adımı gerekmez.

Hayır. Hiçbir yazılım üreticisi ile ticari ilişkimiz bulunmamaktadır. Percona bileşenleri ve pgaudit gibi topluluk eklentileri açık kaynak lisansa sahiptir; firmamız bu bileşenleri müşterinin çalışan sistemine kurar, yapılandırır ve entegre eder. Sunduğumuz hizmet, entegrasyon ve sonrasındaki operasyonel destektir.

Her tedbirin operasyonel maliyeti farklıdır. Denetim kaydı ve veri maskeleme genellikle kesintisiz devreye alınabilir. Şifreleme ve dağıtım geçişi ise planlama gerektirir; replika sunucular üzerinden ilerleyip yükü devrederek kesintiyi bakım penceresine sığdırmak çoğu senaryoda mümkündür. Mevcut topolojinizi incelemeden kesinti süresi taahhüdünde bulunmayız.

Evet. Projelerin büyük bölümü tek bir denetim bulgusuyla başlar; en sık karşılaşılan bulgular denetim kaydının bulunmaması ve üretim dışı ortamlarda gerçek kişisel veri saklanmasıdır. Dört tedbirin tamamının aynı anda devreye alınması zorunlu değildir.

Denetimde hangi bulguyla karşılaştınız?

Mevcut kurulumunuzu birlikte inceleyelim; hangi teknik tedbirin ne düzeyde çalışma gerektirdiğini ve önceliklendirmenin nasıl yapılacağını ortaya koyalım.

İletişime geçin