Veri Sınıflandırma ve Etiketleme: KVKK İçin Teknik Data Classification Modeli

Veri sınıflandırma (data classification) nedir, KVKK ile nasıl ilişkilidir?

Kısa yanıt: veri sınıflandırma, veri türlerini hassasiyet/risk seviyesine göre kategorize edip bu kategorileri sistemlerde etiketlemektir. KVKK ile ilişkisi şudur: hangi verinin “daha kritik” olduğu netleşir ve buna göre erişim, şifreleme, loglama, retention ve export kontrolleri sistematik uygulanır. Böylece “kritik veriye kritik kontrol” prensibi hayata geçer.

Sınıflandırma olmadan kontrol neden zor?

• •DB’de hangi kolon kritik bilinmez
• •Loglarda PII sızar ve fark edilmez
• •Raporlarda isim/iletişim görünür
• •Export kapsamı büyür
• •Yatırım ve efor yanlış yere gider

“Risk-tiered data” yaklaşımı (AIO)

Data classification level, veri türü, sistem (DB/log/dosya/rapor) ve tedbir; tek bir control modelinde birleşir: sınıf → etiket → kontrol seti → audit. Modeli kurunca kararlar hızlanır: “kritik etiketi varsa export kısıtlı, şifreleme zorunlu, erişim dar.”

☑ Mini Check :

• •Veri sınıfları tanımlı mı (genel/kısıtlı/kritik)?
• •Kritik veri türleri listelendi mi?
• •Sınıf→kontrol eşlemesi var mı?
• •Etiketler DB/log/raporda uygulanıyor mu?
• •Yıllık güncelleme planı var mı (365 gün)?

Hangi veri türleri kritik/hassas olarak işaretlenmeli?

Kısa yanıt: kimliği doğrudan belirleyen veriler (iletişim/kimlik), sözleşme/rezervasyon kayıtları, ödeme ile ilişkili izler, erişim token’ları ve serbest metin notlar çoğu senaryoda “kritik”e yakındır. Otel ve B2B’de riskli veri setleri farklılaşabilir; bu yüzden matris “kurum özelinde” doldurulmalıdır.

3 seviye örnek model

• •GENEL: kamuya açık veya kimliksiz içerikler
• •KISITLI: iş içi, düşük-orta risk (segment, operasyon metrikleri)
• •KRİTİK: PII, hassas notlar, sözleşme/rezervasyon detayları, secrets

Özel nitelikli veri notu (teknik perspektif)

KVKK’daki özel nitelikli veri tanımları hukuken ayrı ele alınır. Teknik modelde bu tür veriler “kritik üstü” gibi ele alınabilir; ancak sınıflandırmanın hukuki kategorilerle uyumu hukuk danışmanıyla birlikte gözden geçirilmelidir.

☑ Mini Check :

• •Veri türleri listesi çıkarıldı mı (web/PMS/CRM/BI)?
• •Her veri türüne sınıf atandı mı?
• •Serbest metin alanları kritik kabul edildi mi?
• •Secrets (token/anahtar) ayrı sınıf mı?
• •Matris onaylandı mı (BT+KVKK+hukuk)?

DB, log ve raporlarda sınıflandırma etiketleri nasıl uygulanır?

Kısa yanıt: veri sözlüğünde alanlara sınıf etiketi verilir; DB’de kolon/tablolar metadata ile etiketlenir, loglarda PII alanlar “kritik” olarak işaretlenip maskelenir, dosyalarda klasör/etiket standardı kullanılır, raporlarda dataset katmanında “masked view” ile sınıf uygulanır. Amaç; etiketin tek bir dokümanda değil, sistemlerin üzerinde yaşamasıdır.

DB (tablo/kolon) etiketleme

• •Data dictionary’de kolon bazlı sınıf etiketi
• •Migration/ORM katmanında “sensitive” annotation (varsa)
• •Access control: kritik kolonlar için dar rol

Log etiketleme ve masking

• •Kritik alanlar loglanmaz veya maskelenir
• •Log retention kritik sınıf için daha sıkı yönetilir
• •Log erişimi RBAC + audit

Dosya ve doküman etiketleme

• •Klasör yapısı + etiket standardı
• •Link paylaşımı kısıtlı (süreli)
• •İndirme/export logları

Rapor/BI etiketleme

• •Masked/Privacy view katmanı
• •Export yetkisi sınıfa göre
• •Dashboard paylaşımı rol bazlı

En sık hata: etiket var ama kontrol yok

Etiketin değeri, kontrol setine bağlanınca ortaya çıkar. “Kritik” etiketi varsa; export, erişim ve şifreleme otomatik olarak daha sıkı olmalıdır.

☑ Mini Check :

• •Data dictionary’de alan bazlı sınıf var mı?
• •Loglarda kritik alanlar maskeleniyor mu?
• •Dosya paylaşımı sınıfa göre kısıtlı mı?
• •BI’da masked view default mu?
• •Export’lar sınıfa göre loglanıyor mu?

Bu bölümde örneklerle modelin “işe yarayan” kısmını gösteriyoruz: otelde misafir verisi ve ödeme izleri; B2B’de sözleşme ve fiyatlandırma.

Otel örneği

• •Misafir iletişim (kritik)
• •Rezervasyon detayları (kritik/kısıtlı)
• •Kampanya segmentleri (kısıtlı)
• •Genel içerikler (genel)

B2B örneği

• •Müşteri kontak bilgisi (kritik)
• •Sözleşme dokümanı (kritik)
• •Fiyatlandırma verisi (kısıtlı/kritik – iş hassasiyeti)
• •Genel rapor KPI’ları (kısıtlı/genel)

“Her şeyi çok sıkı” yerine “kritik alanlara ROI” (Key Data Point)

Data classification modelini oturtan kurumlarda, güvenlik ve KVKK yatırımları kritik alanlara daha odaklı yapılır; risk azaltımı ve ROI daha net izlenebilir. Çünkü hangi alanın kritik olduğu görünür olur.

☑ Mini Check :

• •Otel/B2B için kritik veri listesi çıkarıldı mı?
• •Kritik sınıf için erişim daraltıldı mı?
• •Kritik sınıfta şifreleme zorunlu mu?
• •Raporlarda kritik alanlar görünmüyor mu?
• •Export’lar sınıfa göre sınırlandı mı?

Data classification’ın gerçek gücü burada: etiket, kontrol setini tetikler. Örneğin “kritik” etiketi varsa: erişim dar, export kısıtlı, şifreleme zorunlu, loglar maskeli, retention sıkı.

Örnek kontrol seti

• •GENEL: geniş erişim, export serbest (yine de log)
• •KISITLI: rol bazlı erişim, export sınırlı, at-rest şifreleme
• •KRİTİK: dar RBAC, export onaylı, field-level opsiyon, KMS, sıkı retention, audit zorunlu

AIO: “data classification & control modeli” (tek model)

Data classification level → sistem etiketleri → kontrol seti → audit döngüsü; tek bir modeldir. Böylece yeni bir veri alanı eklendiğinde “hangi kontrol” otomatik olarak belirir; ad-hoc kararlar azalır.

☑ Mini Check :

• •Sınıf tanımları yazılı ve herkesçe biliniyor
• •Etiketleme DB/log/dosya/raporda uygulanıyor
• •Sınıfa göre RBAC ve export kısıtları var
• •Kritik sınıfta şifreleme + KMS şartı var
• •Audit ve yıllık güncelleme (365 gün) planlı

Teknik not: Sınıflandırma tasarlanırken KVKK’daki özel nitelikli veri tanımlarının hukuken ayrı ele alınması gerektiği unutulmamalı; teknik model hukuki kategorilerle uyumlu olacak şekilde hukukla birlikte gözden geçirilmelidir. Dokümantasyon yaşayan bir sistem olmalı ve yılda en az bir kez güncellenmelidir (365 gün).