Veritabanlarında Kişisel Veri: Oracle, SQL Server ve PostgreSQL

Veritabanları, kişisel verinin en yoğun ve en yapılandırılmış biçimde durduğu yerdir; aynı zamanda keşif araçlarının en çok ihmal ettiği yerdir. Bir dosya sunucusundaki bordro tablosu tek bir belgedir; bir Oracle şemasındaki “MUSTERI” tablosu ise sekiz milyon satır, altmış sütun ve bu sütunların hangisinin TCKN, hangisinin IBAN taşıdığına dair çoğu zaman eskimiş bir belgelemedir. Veritabanında kişisel veri keşfi, belge taramak değil, sütun sütun sormaktır: burada ne var, kim okuyabiliyor, bulamadığımızda ne söylüyoruz.

Veritabanı neden ayrı bir sorun

Dosya tabanlı keşif, bir belgeyi açar, içeriğini çıkarır ve desen arar. Veritabanında bu yaklaşım iki nedenle çalışmaz. Birincisi ölçektir: tek bir tablo, tüm dosya paylaşımından daha fazla kayıt içerebilir ve tam okuma üretim sistemine yük bindirir. İkincisi yapıdır: kişisel veri bir metnin içinde değil, belirli bir sütunda, belirli bir veri türüyle durur. “TCKN” sütunu adıyla kendini belli edebilir; “REF_NO” ya da “EXT_ID” sütunu da TCKN taşıyabilir ve adı hiçbir şey söylemez.

Üçüncü bir fark, erişim modelidir. Dosya sunucusunda izin dosya ya da klasör düzeyinde verilir; veritabanında rol ve tablo düzeyinde verilir ve sütun düzeyinde nadiren kısıtlanır. Bir role “MUSTERI tablosunu oku” yetkisi verildiğinde, rol altmış sütunun tamamını okur; TCKN sütunu için ayrı bir karar verilmemiştir.

Bu üç fark, veritabanı keşfinin kendi yöntemini gerektirdiği anlamına gelir: sütun düzeyinde örnekleme, veri türü ve ad ipuçlarıyla birleştirilmiş desen tespiti ve rol-tablo izin eşlemesi. VERBİS envanteri açısından sonuç doğrudan ilgilidir: Kurum’un Veri Sorumluları Sicili sayfasında anlatılan envanter, hangi veri kategorisinin hangi amaçla tutulduğunu sorar; “MUSTERI tablosunda TCKN var” bulgusu bu sorunun gerçek keşiften gelen yanıtıdır. Bu yazı hukuki tavsiye değildir.

Sütun düzeyinde örnekleme nasıl çalışır

Seratus veritabanını tablo (kapsayıcı) ve sütun (taranan birim) modeliyle ele alır. Her tablo için sütun listesi ve veri türleri meta veriden okunur. Ardından her sütun için bir örneklem alınır: tüm satırlar değil, belirlenmiş sayıda satırın o sütundaki değerleri. Örneklem üzerinde Türkçeye özel tespit kuralları çalıştırılır: TCKN, vergi kimlik numarası, TR IBAN, kart numarası, e-posta, TR telefon, araç plakası, ICD kodu gibi.

Örnekleme üç şeyi sağlar. Üretim veritabanına yük bindirmez; sekiz milyon satırlık tablonun tamamını okumak yerine sınırlı satır okunur. Tarama süresi tablo boyutundan büyük ölçüde bağımsız hale gelir; büyük şemalar makul sürede taranır. Bağlantı salt okunur kaldığından tarama hiçbir veriyi değiştirmez.

Örnekleme sonucu her sütun için bir bulgu üretir: hangi desenin, örneklemdeki değerlerin ne kadarında, hangi güven yüzdesiyle görüldüğü. Bulgu, maskeli örnek değerlerle sunulur; inceleyen kişi tam TCKN’yi görmeden sütunun ne taşıdığını doğrular. Her kuralın doğruluk ve yanlış-pozitif azaltma programı vardır: on bir haneli bir sayı dizisi TCKN olabilir ama kontrol basamağı tutmayan dizi TCKN değildir; bu doğrulama yanlış pozitifi azaltır. Ayrıntı Türkçeye özel tespit doğruluğu sayfasındadır.

Sütun adı ve veri türü, tespiti destekleyen bağlam ipuçlarıdır. “DOGUM_TARIHI” adlı DATE sütunu içerik örneklemesi olmadan da kişisel veri adayıdır; “NOTLAR” adlı CLOB sütunu ise yapılandırılmamış metin taşır ve içinde her şey olabilir. Seratus bu ipuçlarını bulgunun yanında gösterir; karar insan onayıyla kesinleşir.

Maskelenmemiş TCKN ve IBAN sütunları

Veritabanlarında en sık görülen bulgu, maskelenmemiş kimlik ve finans sütunlarıdır. Üç tipik örüntü vardır.

Birincil tabloda açık değer. Müşteri ya da personel tablosunda TCKN düz metin olarak durur. Bu, uygulamanın gereksinimi olabilir; ancak aynı sütunun raporlama rolüne, test ortamına ve analitik kopyaya aynı açıklıkla gittiği çoğu zaman gözden kaçar.

Türev tablolarda tekrarlanan değer. Entegrasyon tabloları, log tabloları ve geçici tablolar, birincil tablodaki TCKN’yi kopyalar. “STG_MUSTERI_2021” adlı bir aşama tablosu, dört yıl önceki bir göçten kalmıştır ve hâlâ sekiz milyon TCKN taşır; hiçbir uygulama okumaz ama her raporlama rolü okuyabilir.

Yanlış adlı sütunlar. TCKN, “REF_NO”, “EXT_ID” ya da “ACIKLAMA” gibi sütunlarda, bazen bir metnin içinde durur. Sütun adına dayalı envanter bunları hiç görmez; yalnız içerik örneklemesi bulur.

IBAN için örüntü benzerdir: bordro, tedarikçi ödeme ve iade tablolarında TR IBAN’lar açık durur ve bu tabloların kopyaları muhasebe entegrasyonlarında çoğalır. Bir sigorta şirketinde hasar ödeme tablosunun aylık dışa aktarmaları bir aşama şemasında yıllarca birikmişse, IBAN sayısı birincil tablonun katlarına çıkar.

Bu bulgular için iyileştirme maskeleme, erişim daraltma ya da imha olabilir. Hangisinin seçileceği, sütunun hangi amaçla ve hangi süreyle tutulduğuna bağlıdır; bu kararın KVKK uyum modülündeki saklama takvimiyle verilmesi gerekir. Aşama tablosundaki dört yıllık TCKN kopyası için doğru eylem maskeleme değil, imhadır.

Rol-tablo izin grafiği

Bir sütunda TCKN bulunması, tek başına bir risk sıralaması üretmez. Sıralama, o tabloyu kimin okuyabildiğiyle oluşur. Seratus her veritabanı için rol-tablo izin grafiğini çıkarır: hangi kullanıcı hangi role sahip, hangi rol hangi tabloyu okuyabiliyor, bu tablolarda hangi sütunlar kişisel veri taşıyor.

Platformlar arasında model farklıdır ama soru aynıdır. Oracle’da roller, sistem ayrıcalıkları ve nesne ayrıcalıkları birlikte değerlendirilir; “SELECT ANY TABLE” gibi geniş bir sistem ayrıcalığı, nesne ayrıcalığı hiç verilmemiş olsa da tüm tablolara erişim demektir. SQL Server’da db_datareader sabit rolü veritabanındaki tüm tabloları okur; şema düzeyinde verilmiş SELECT izinleri ve sunucu düzeyindeki sysadmin üyeliği ayrıca hesaplanır. PostgreSQL’de roller iç içe geçer ve GRANT ifadeleri şema, tablo ve sütun düzeyinde verilebilir; “PUBLIC” rolüne verilmiş bir izin herkese verilmiş demektir. MySQL ve MariaDB’de kullanıcı-ana makine çiftleri ve küresel, veritabanı, tablo düzeyinde ayrıcalıklar vardır.

Grafikte öne çıkan bulgular tanıdıktır: tüm şemayı okuyan uygulama servis hesabı, herkese verilmiş raporlama rolü, yıllar önce ayrılmış bir yöneticinin hâlâ tam yetkili hesabı, PUBLIC’e verilmiş SELECT. Bu bulgular, kişisel veri taşıyan sütunlarla eşlendiğinde “TCKN sütununa 140 kullanıcı erişebiliyor” biçiminde ifade edilir ve dosya sunucusu ACL’leri ile Microsoft 365 paylaşım linkleriyle aynı erişim ve maruziyet grafiğinde yer alır.

“Örneklemde bulunmadı” nüansı

Örnekleme temelli tespitin açıkça söylenmesi gereken bir sınırı vardır: örneklemde görülmeyen bir desen hakkında kesin yargı verilemez. Bir sütunun ilk bin satırında TCKN yoksa bu, sütunun TCKN içermediği anlamına gelmez; yalnız o örneklemde desene rastlanmadığı anlamına gelir. Sütun, çoğunlukla boş olup belirli kayıtlarda dolu olabilir; eski kayıtlar farklı formatta olabilir; TCKN yalnız belirli bir müşteri segmentinde tutuluyor olabilir.

Seratus bu durumu “örneklemde bulunmadı” olarak ayrı bir sonuç türüyle gösterir ve ürün içinde açıkça belirtir: bu teknik bir bulgudur, bir risk kararı değildir. Sütunun kişisel veri içermediğine karar vermek, örneklemin yanında sütun adı, veri türü, uygulama belgelemesi ve veri sahibinin bilgisiyle verilen bir insan kararıdır. Ürün bu kararı almaz; kararı destekleyen bağlamı gösterir ve verilen kararı kim, ne zaman, neden bilgisiyle kaydeder.

Bu nüansın denetim açısından sonucu önemlidir. “Veritabanlarımızı taradık, kişisel veri bulunmadı” cümlesi, yöntem belirtilmeden söylendiğinde yanıltıcıdır. Doğru ifade şudur: “Şu tabloların şu sütunları şu örnekleme oranıyla tarandı; şu sütunlarda şu desenler bulundu; şu sütunlarda örneklemde bulunmadı ve şu gerekçeyle kişisel veri taşımadığına karar verildi.” Seratus’un kaynak bazlı detay raporu bu ifadeyi üretir.

Salt okunur bağlantı ve operasyonel etki

Veritabanı yöneticilerinin bir keşif aracına yönelttiği ilk soru “üretime ne yapar” sorusudur. Yanıt üç parçalıdır. Bağlantı salt okunurdur: Oracle’da ince istemci ile ek sürücü gerektirmeden, SQL Server’da db_datareader sabit rolüyle, PostgreSQL ve MySQL/MariaDB’de yalnız SELECT yetkisi olan bir hesapla. Hiçbir yazma, DDL ya da yapılandırma değişikliği yapılmaz; tarama sorguları yalnız meta veri ve sınırlı örneklem okur.

Yük sınırlıdır: örnekleme, tam tablo taramasının yerini alır ve tarama bakım pencerelerine zamanlanabilir. Kesilen tarama kaldığı yerden devam eder; bir bağlantı kopması ya da yeniden başlatma, şemanın baştan taranmasına yol açmaz.

Ajan yoktur. Veritabanı sunucusuna hiçbir şey kurulmaz; Seratus kurum içindeki kendi sunucusundan ağ üzerinden bağlanır. Veri, Seratus sunucusu dışına, hiçbir dış servise gitmez; kurulum yerinde ve air-gap uyumludur. Platform ayrıntıları Oracle, SQL Server ve PostgreSQL/MySQL sayfalarındadır.

Seratus bu açıkları nasıl kapatır

Açık: Hangi sütunun TCKN, IBAN ya da sağlık verisi taşıdığının eskimiş belgelemeye dayanması. Seratus sütun düzeyinde örnekleme ile Türkçeye özel tespit kurallarını çalıştırır; her bulgu güven yüzdesi ve maskeli örnekle sunulur, sütun adı ve veri türü ipuçlarıyla birlikte insan onayına gider.

Açık: Aşama, log ve entegrasyon tablolarındaki unutulmuş kopyalar. Tüm şema taranır; yalnız uygulamanın bildiği tablolar değil, yıllar önce kalmış türev tablolar da bulgu üretir ve saklama takvimine bağlanır.

Açık: Tabloya erişimin sütun içeriğiyle eşlenmemesi. Rol-tablo izin grafiği, her rolün erişebildiği tabloları kişisel veri bulunan sütunlarla eşler; geniş sistem ayrıcalıkları, PUBLIC izinleri ve ayrılmış kullanıcı hesapları ayrı bulgu olarak işaretlenir.

Açık: “Bulunmadı” sonucunun “temiz” sayılması. “Örneklemde bulunmadı” ayrı bir sonuç türüdür ve ürün bunun bir risk kararı olmadığını açıkça belirtir; karar insan tarafından, kaydedilerek verilir.

Açık: Keşif için yazma yetkisi istenmesi. Bağlantılar salt okunurdur (ince istemci, db_datareader, SELECT); maskeleme, erişim daraltma ve imha gibi eylemler ayrı yetkiyle, sorumluya atanarak ve onayla yürütülür, denetim kaydına yazılır.

Açık: VERBİS envanterinin veritabanı gerçeğini yansıtmaması. Veritabanı bulguları, dosya ve Microsoft 365 bulgularıyla birlikte VERBİS envanterine gerçek keşiften girer; “envanterde olmayan veri” açığı KVKK hazırlık puanında görünür.

Sonuç

Veritabanında kişisel veri keşfi, sütun sütun yapılan bir sorgulamadır: burada ne var, kim okuyabiliyor, bulamadığımızda ne söylüyoruz. Örnekleme bu sorgulamayı üretim sistemine yük bindirmeden mümkün kılar; rol-tablo izin grafiği bulguyu riske çevirir; “örneklemde bulunmadı” nüansı ise kurumun denetimde söylediği cümlenin doğru olmasını sağlar. Salt okunur bağlantı, bütün bunların veritabanına dokunmadan yapıldığını garanti eder.