Hangi Veritabanımda Hangi Kişisel Veri Var? Otomatik PII Keşfi Rehberi

Uyum sorumlusu olarak envanter formunu doldurduğunuzda genellikle şu soruya yanıt verirsiniz: "Müşteri verilerini CRM'de, personel verilerini İK sisteminde işliyoruz." Bu cevap doğru olabilir; ancak denetimde veya ihlal sonrası sorulan asıl soru farklıdır: "Bu veriler fiilen hangi tabloda, hangi sütunda duruyor?" Çoğu kurumda bu soruya güvenilir bir yanıt yoktur.

6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), veri sorumlusundan işlenen kişisel verilere ilişkin kayıtları tutmasını ve uygun güvenlik tedbirlerini almasını ister (m.10, m.12). Veri işleme envanterinin nasıl hazırlanacağı ayrı bir rehber konusudur; fakat envanterin en zor adımı kategori yazmak değil, dağınık veri kaynaklarında neyin nerede olduğunu tespit etmektir. İşte bu noktada otomatik kişisel veri keşfi (data discovery) ve PII taraması devreye girer.

Manuel envanterin kör noktaları

Excel veya form tabanlı envanter, süreç sahiplerinin bildirdiği bilgiye dayanır. Bu yaklaşım pratik görünse de sistematik olarak şu kör noktaları üretir:

1. Gölge IT ve unutulmuş veritabanları

Birimler kendi ihtiyaçları için ayrı veritabanları, Access dosyaları veya eski ERP modülleri kullanabilir. Uyum ekibi yalnızca "resmi" sistemleri envantere yazar; IT envanterinde görünmeyen bir PostgreSQL örneği veya test sunucusundaki MSSQL kopyası listede yer almaz. Yıllar içinde biriken legacy tablolar — örneğin eski bir e-ticaret modülünden kalan customers_backup_2019 — genellikle kimsenin sorumluluğunda değildir.

2. Yanıltıcı sütun adları

field_03, user_attr, note_text gibi jenerik sütun adları, içerikte TCKN, e-posta veya telefon barındırabilir. Süreç sahibi "bu tabloda kişisel veri yok" der; çünkü sütun adına bakarak karar vermiştir. Manuel envanter, içerik analizi yapmadığı sürece bu tür alanları kaçırır.

3. Mikroservis ve entegrasyon kopyaları

Ana sistemde tutulan veri, raporlama amacıyla ayrı bir veri ambarına, mesaj kuyruğuna veya üçüncü taraf entegrasyon tablosuna kopyalanmış olabilir. Her kopya ayrı bir işleme faaliyeti ve ayrı bir güvenlik yüzeyi demektir. Envanter yalnızca "kaynak sistem"i kapsıyorsa, kopyalar görünmez kalır.

4. Üretim dışı ortamlar

Geliştirme, test ve staging ortamlarında üretim verisinin anonimleştirilmemiş kopyaları sık görülür. Bu ortamlar genellikle daha zayıf erişim kontrolüne sahiptir; fakat içerdikleri veri aynı kişisel veridir. Manuel envanterde "sadece prod" odaklı çalışmak, en büyük risk alanlarından birini dışarıda bırakır.

5. Güncellik sorunu

Manuel envanter bir kez doldurulup aylarca güncellenmez. Yeni bir özellik devreye girdiğinde, yeni bir tablo eklendiğinde veya bir entegrasyon değiştiğinde envanter geride kalır. KVKK m.12 kapsamındaki teknik tedbirlerin "fiilen uygulandığını" göstermek için kayıtların güncel olması gerekir; statik bir Excel dosyası bunu karşılamaz.

Bu kör noktalar, Kurul kararlarında sıkça "veri güvenliğine ilişkin yükümlülüklerin ihlali" (KVKK m.18) gerekçesiyle cezalandırılan ihlallerin altında yatar. Sorun çoğu zaman kötü niyet değil; görünmeyen veridir.

PII metadata taraması nasıl çalışır?

Otomatik veri keşfi, ham veriyi dışarı aktarmadan metadata üzerinden kişisel veri izlerini tespit eder. Tipik bir tarama akışı şu adımlardan oluşur:

Bu yaklaşım, "CRM'de müşteri verisi var" düzeyindeki genellemeyi "erp_db.public.orders.ship_note sütununda telefon numarası tespit edildi" düzeyine indirir. Uyum ekibi hangi süreçle ilişkilendireceğini bilir; IT ekibi hangi tabloya erişim kısıtı veya şifreleme uygulayacağını belirler.

Önemli bir ayrım: Metadata taraması, veri kategorisinin hukuki sınıflandırmasını (örneğin sağlık verisi, özel nitelikli veri) otomatik vermez. Tespit edilen PII tipi, envanterdeki "işlenen veri kategorisi" alanını doldurmak için teknik kanıt sağlar; nihai hukuki değerlendirme uyum sorumlusuna aittir.

On-prem agent: Veri ağınızdan çıkmadan tarama

KVKK perspektifinden veri keşfi aracı seçerken en kritik soru şudur: Tarama sırasında kişisel veriler kurum dışına çıkıyor mu?

Bulut tabanlı keşif araçları, veritabanı bağlantı bilgisini ve çoğu zaman örnek veriyi kendi sunucularında işler. Bu, özellikle finans, sağlık ve kamu sektöründe güvenlik ve tedarikçi değerlendirmesi açısından sorun yaratır. Veri sorumlusu, veri işleyen sıfatıyla yeni bir tedarikçiye bağlantı dizesi ve örnek veri aktarmış olur; bu da KVKK m.9 ve m.12 kapsamında ek yükümlülük doğurur.

LexiAgent yaklaşımı bu sorunu mimari düzeyde çözer:

┌─────────────────────────────┐         ┌──────────────────────┐
│     Kurum ağı (on-prem)     │   TLS   │   Lexidata SaaS      │
│                             │ ──────▶ │                      │
│  LexiAgent (Docker)         │         │  Bulgu paneli        │
│    ↓ read-only              │         │  Tarama geçmişi      │
│  MSSQL / PostgreSQL / MySQL │         │  Risk uyarıları      │
└─────────────────────────────┘         └──────────────────────┘
        Ham veri dışarı çıkmaz.
        Yalnızca metadata + maskelenmiş örnek gönderilir.

Temel kurallar:

• Bağlantı bilgisi panelde saklanmaz. Connection string yalnızca kurum ağındaki Docker container ortam değişkeninde tanımlanır.
• Agent read-only bağlanır. Tarama, information schema ve örneklem sorgularıyla sınırlıdır; veri değiştirilmez.
• Ham veri Lexidata'ya gitmez. Platforma iletilen bilgi: tablo adı, sütun adı, PII tipi, tahmini satır sayısı ve maskelenmiş örnekler.
• Off-peak pencere. Üretim veritabanları yoğun saatler dışında taranır; throttle ile sorgu yükü kontrol edilir.
• Periyodik tekrar. Cron ile zamanlanmış taramalar, yeni tabloların veya veri sızıntılarının zamanla ortaya çıkmasını sağlar.

Desteklenen kaynaklar MVP kapsamında MSSQL, PostgreSQL ve MySQL'dir. Kurum birden fazla veritabanına sahipse her kaynak için ayrı agent veya tek agent altında çoklu kaynak tanımı yapılabilir.

Envanterle entegrasyon: Keşiften kayda

PII taramasının değeri, bulguların veri işleme envanterine bağlanmasıyla ortaya çıkar. Keşif sonucu olmadan doldurulan envanter "süreç odaklı" kalır; keşif sonucuyla zenginleştirilen envanter ise "sistem odaklı kanıt" taşır.

Pratik entegrasyon adımları:

1. İlk tarama: Tüm bilinen veritabanlarında LexiAgent kurulumu ve tam tarama.
2. Bulgu inceleme: Uyum ekibi her bulguyu ilgili işleme faaliyetiyle eşleştirir; gereksiz veri için silme veya anonimleştirme planı oluşturur.
3. Envanter güncelleme: Tespit edilen veri kategorileri, alıcılar ve teknik tedbirler envanter kaydına işlenir.
4. Periyodik kontrol: Yeni taramalarda ortaya çıkan farklar (yeni tablo, yeni PII tipi) envanter revizyonunu tetikler.

Bu döngü, KVKK m.10'daki kayıt tutma yükümlülüğünü "bir kerelik dokümantasyon" olmaktan çıkarıp sürdürülebilir uyum sürecine dönüştürür. VERBİS bildirimi veya Kurul denetiminde "envanteriniz ile fiili durum uyumlu mu?" sorusuna somut yanıt verebilirsiniz.

Ne zaman otomatik keşif gerekir?

Her kurumun ihtiyacı farklıdır; ancak şu senaryolarda manuel envanter tek başına yetersiz kalır:

• 10'dan fazla veritabanı veya mikroservis mimarisi
• Son 3 yılda birleşme, devralma veya ERP değişimi yaşanmış olması
• Üçüncü taraf yazılım entegrasyonlarının (ödeme, kargo, pazarlama) çok sayıda tablo oluşturması
• Denetim veya ihlal sonrası "tüm kişisel verileri gösterin" talebi
• VERBİS kayıt yükümlülüğü kapsamında detaylı bildirim gerekliliği

Küçük ve tek veritabanlı bir yapıda manuel envanter yeterli olabilir. Ölçek büyüdükçe "bilmiyoruz" maliyeti, tarama maliyetini aşar.

Sonuç ve Lexidata Veri Keşfi

Kişisel veri keşfi, KVKK uyumunun teknik temelidir. Manuel envanter süreçleri anlatır; otomatik PII taraması ise fiilen neyin nerede durduğunu gösterir. On-prem agent modeliyle bu tespit, ham veriyi kurum dışına çıkarmadan yapılabilir.

Lexidata Veri Keşfi modülü, LexiAgent ile MSSQL, PostgreSQL ve MySQL kaynaklarınızı tarar; bulguları panelde tablo/sütun düzeyinde listeler. Tarama geçmişi, periyodik schedule ve maskelenmiş örneklerle denetimde kanıt üretmenizi kolaylaştırır. Bulgular, uyum panelindeki canlı veri envanteriyle birlikte değerlendirildiğinde "ölü Excel" yerine güncel bir uyum görünümü oluşur.

Lexidata Veri Keşfi modülünü inceleyin veya platform.lexidata.io üzerinden demo talep edin.

İç linkler

• Veri işleme envanteri nasıl hazırlanır? — Envanter alanları, VERBİS bağlantısı ve canlı envanter yaklaşımı