1. Raporlama ve BI’da Kişisel Veri Riski: Neden “Görünmez” Tehdit?
Data warehouse ve dashboard’larda KVKK uyumu teknik olarak nasıl sağlanır?
Kısa yanıt: (1) PII alanlarını envantere al, (2) anon/pseudo katmanı tasarla, (3) maskeleme ve rol bazlı erişim uygula, (4) export ve paylaşım süreçlerini denetle, (5) düzenli audit ile güncelle. BI katmanında risk “sessiz” büyür; çünkü raporlar çok kişiye yayılır ve kopyalanır.
BI riskinin 3 kaynağı
- PII’nin rapora sızması: isim/telefon/e-posta gibi alanlar
- Geniş erişim: dashboard’ların “herkes görsün” mantığıyla paylaşılması
- Export/indir: Excel/CSV dosyaları kontrolsüz dağıtılır
Otel ve B2B’de tipik riskli rapor örnekleri
- •Otel: “misafir listesi”, “pazar bazlı rezervasyon” raporuna isim eklemek
- •B2B: “müşteri listesi” dashboard’unda e-posta/telefonun görünmesi
☑ Mini Check
- •Dashboard’larda isim/e-posta/telefon görünen alan var mı?
- •BI erişimleri rol bazlı mı?
- •Excel export’lar takip ediliyor mu?
- •Warehouse katmanında PII alanlar işaretli mi?
- •Masking/ID yaklaşımı standard mı?
Ne yapmalıyım?
- • BI envanteri çıkarın: dashboard + dataset + export noktaları.
- • PII alanları işaretleyin ve “kaldır/maskele” kararı verin.
- • ID bazlı analiz yaklaşımına geçin (ad/soyad yerine ID).
- • Export yetkilerini kısıtlayın ve audit’e alın.
- • KVKK veri güvenliği modeliyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. Anonimizasyon vs Pseudonimizasyon: Teknik Çerçeve
Anonimizasyon ve pseudonimizasyon nedir, farkları nelerdir?
Kısa yanıt: anonimleştirme, veriyi kişiyle ilişkilendirilemeyecek hale getirir; pseudonimizasyon ise kişiyi doğrudan göstermez ama bir pseudo-ID ile tutarlı analiz yapmanı sağlar. BI ve raporlama katmanında en pratik yaklaşım; günlük raporlama için pseudonimizasyon (ID), dışa açık paylaşımlar için daha güçlü anonimleştirme/toplulaştırma kullanmaktır.
Teknik pratikler (örnek set)
- •Pseudonimizasyon: ad/soyad → customer_id, e-posta → hash/ID (politikaya göre)
- •Anonimizasyon: lokasyon → bölge/ülke, tarih → hafta/ay, yaş → aralık, tutar → band
Neden ikisi birlikte kullanılır?
Çünkü BI’da çoğu analiz “trend ve segment” ister; kişi adının görünmesine gerek yoktur. Fakat kişi bazlı takibi gerektiren durumlarda (sadece yetkili ekip) pseudo-ID ile kontrollü izleme yapılabilir.
Anon/pseudo örnekleri tablosu
| Alan | Risk | Yaklaşım | Örnek dönüşüm | Not |
|---|---|---|---|---|
| Ad/soyad | Doğrudan kimlik | Pseudo-ID / Kaldır | customer_id | Yönetim KPI raporlarında kaldır; operasyonel raporlarda pseudo-ID kullan |
| E-posta | İletişim | Maskele / Pseudo-ID | e***@domain.com veya customer_id | Export yetkisini rol bazlı kısıtla |
| Telefon | İletişim | Maskele / Pseudo-ID | +90 5** *** ** ** veya customer_id | Dashboard görünürlüğünü minimumda tut |
| TCKN / pasaport | Doğrudan kimlik | Kaldır / Maskele | *********** | Varsa raporlarda görünür yüzeyden çıkar |
| Açık adres | Adres | Toplulaştır / Maskele | İl / bölge / ülke | KPI ihtiyacına göre genelleştir |
| Cihaz ID / cookie ID | Tanımlayıcı | Pseudo-ID / Hash | hashed_device_id | Kullanım amacına göre kontrol et |
| Serbest metin notu | Serbest metin | Kaldır / Çok sınırla | Rapor dışı | En riskli alanlardan biridir |
| Tarih / lokasyon / yaş / tutar | Dolaylı tanımlama | Toplulaştır | Hafta/ay, bölge, yaş aralığı, tutar bandı | Dışa açık ve yönetim raporlarında tercih et |
☑ Mini Check
- •Hangi raporlar kişi bazlı, hangileri toplu? ayrıldı mı?
- •Kişi bazlı raporlar pseudo-ID üzerinden mi?
- •Toplu raporlarda anonimleştirme/toplulaştırma var mı?
- •PII alanlar için masking kuralı var mı?
- •Yetkisiz kullanıcılar ad/iletişim göremiyor mu?
Ne yapmalıyım?
- • Raporları “operasyonel kişi bazlı” ve “yönetim KPI” diye ayırın.
- • KPI raporlarında kişi alanlarını tamamen kaldırın.
- • Operasyonel raporlarda pseudo-ID kullanın (ad yerine).
- • Erişim rollerini netleştirin (who sees what).
- • Veri analiz/raporlama süreçleriyle bağlayın: https://dgtlface.com/tr/veri-analiz-ve-raporlama
3. Dashboard ve Data Warehouse’ta Hangi Alanlar Maskeleme Gerektirir?
BI katmanında maskeleme, iki katmanda ele alınmalıdır:
- Warehouse katmanı: PII’nin “kaynağa yakın” kontrolü
- Dashboard katmanı: görsel erişim ve export kontrolü
Maskeleme gerektiren alan tipleri (pratik sınıflar)
- •Doğrudan kimlik: ad/soyad, TCKN (varsa), pasaport (varsa)
- •İletişim: e-posta, telefon
- •Adres: açık adres
- •Tanımlayıcılar: cihaz ID, cookie ID (analitik bağlamında)
- •Serbest metin: not alanları (en riskli)
Excel/CSV export riskini “tasarımla” azaltın
En iyi pratik: dashboard’da export opsiyonu herkes için açık olmamalı; ayrıca export edilen dataset zaten maskeleme katmanından beslenmeli. Böylece export olsa bile içerik kontrollü kalır.
☑ Mini Check
- •PII alanlar warehouse’da etiketli mi?
- •Dashboard dataset’leri masking katmanından mı geliyor?
- •Serbest metin alanları raporlarda kapalı mı?
- •Export yetkileri rol bazlı mı?
- •Export olayları loglanıyor mu?
Ne yapmalıyım?
- • Warehouse’da PII alan sözlüğü çıkarın (field catalog).
- • “Masked view” katmanı üretin ve dashboard’ları buna bağlayın.
- • Serbest metin alanlarını raporlardan kaldırın veya çok sınırlayın.
- • Export yetkisini kısıtlayın ve audit’e alın.
- • KVKK veri güvenliğiyle hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
4. Otel ve B2B İçin Örnek Uygulamalar: “ID Bazlı Analiz” Şablonu
Bu bölüm, teoriyi somutlaştırır: hangi raporda neyi nasıl değiştiriyoruz?
Otel örneği: misafir raporları
- •Yönetim dashboard: doluluk, ADR, kanal payı → kişi alanı yok
- •Operasyon raporu: misafir segmentleri → guest_id ile
- •Kampanya raporu: e-posta/telefon yerine segment ve ID
B2B örneği: müşteri ve sözleşme raporları
- •Yönetim dashboard: pipeline, win rate → müşteri adı yerine account_id (veya kısaltma)
- •Satış operasyon: müşteri detay → sadece yetkili rolde, minimum alanla
- •Sözleşme raporu: doküman linkleri kontrollü, export kısıtlı
“Warehouse hygiene” fark yaratan mini bölüm (Competitor gap)
TR’de KVKK ve analitik ayrı dünyalar gibi anlatılır. Oysa raporlama katmanında bir “hijyen” standardı koymak (PII sözlüğü, masked view, export governance) hem güvenliği hem analitik kalitesini artırır: gereksiz alanlar temizlenir, veri modeli sadeleşir.
Key Data Point (yumuşatılmış): Sadece üretim sistemini değil BI katmanını da KVKK’ya göre gözden geçirmek, veri sızıntısı riskini anlamlı şekilde azaltabilir; çünkü raporlar en çok kopyalanan yüzeydir.
☑ Mini Check
- •Yönetim raporlarında kişi alanı tamamen kaldırıldı mı?
- •Operasyon raporları pseudo-ID ile mi?
- •Masked view dashboard’larda default mu?
- •Export governance var mı?
- •Raporlar/alanlar değişince kurallar güncelleniyor mu?
Ne yapmalıyım?
- • “Yönetim KPI” raporlarından kişi alanlarını kaldırın.
- • Operasyon raporlarını ID bazına taşıyın.
- • Masked view’ı default yapın, ham tablo erişimini kısıtlayın.
- • Export’ları role bağlayın ve loglayın.
- • Veri analiz ekipleriyle süreçleştirin: https://dgtlface.com/tr/veri-analiz-ve-raporlama
5. BI Mimarisinde Anon/Pseudo Katmanı: Uygulama Planı ve Governance
BI uyumu “tek seferlik” değil; alanlar değiştikçe güncellenen bir yönetim işidir. Bu yüzden mimaride anon/pseudo katmanı bir standarda bağlanmalıdır.
Önerilen katmanlar
- •Raw (ham): kaynaktan gelen veri (kısıtlı erişim)
- •Curated: temizlenmiş ve standardize edilmiş veri
- •Masked/Privacy View: anon/pseudo + masking uygulanmış görünüm (dashboard default)
- •Exports: kontrollü ve loglanan çıktı katmanı
AIO: “raporlama KVKK modeli” (tek model)
Data warehouse, BI, anonymisation/pseudonymisation ve masking; tek bir raporlama KVKK modeli içinde birleşir: alan sözlüğü → privacy view → rol bazlı erişim → export governance → düzenli audit. Bu model, hem otel hem B2B’de aynı çalışır; sadece veri alanları değişir.
☑ Mini Check
- •Raw/curated/masked katmanları tanımlı
- •Masked view dashboard’ların default kaynağı
- •Rol bazlı erişim ve export yetkisi kurgulu
- •Export işlemleri audit log’a giriyor
- •Yıllık (365 gün) alan ve kural gözden geçirme var
Ne yapmalıyım?
- • PII alan kataloğunu çıkarın (field catalog).
- • Privacy view (masked) katmanı oluşturun ve dashboard’ları buna taşıyın.
- • Export yetkisini role bağlayın ve loglayın.
- • “Rapor isteyen → dataset owner → onay → export” akışı tanımlayın.
- • İç linklerle ekipleri hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi — https://dgtlface.com/tr/veri-analiz-ve-raporlama — https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti
Teknik not: Anonim ve pseudo yöntemlerinin hangi hukuki standarda tam uyduğu kısmı hukukla netleştirilmeli; bu yazı teknik mimari önerileri sunduğunu, hukuki yorum olmadığını vurgular.
6. BI Alan Maskeleme & Anonim/Pseudo Model Planlama Şablonunu İndir
Template İçeriği
BI Alan Maskeleme & Anonim/Pseudo Model Planlama Şablonunu İndir — Yazılım / BI Privacy (v1.0)
Bu şablon, BI ve data warehouse katmanında hangi alanların maskeleme gerektirdiğini ve anonim/pseudonimizasyon yaklaşımını tek tabloda tanımlar. Dashboard’ların default olarak privacy view üzerinden çalışmasını ve export governance kurgusunu standardize eder. Otel ve B2B raporlarında analiz ihtiyacını bozmadan kişisel veri riskini azaltmayı hedefler.
Kim Kullanır?
Veri/BI ekibi + IT/BT + dashboard owner’ları (otel ve B2B).
Nasıl Kullanılır?
- PII alan kataloğunu çıkar (field catalog) ve risk sınıfı ata.
- Her alan için yaklaşım seç (kaldır/maskele/pseudo-ID/toplulaştır).
- Privacy view katmanını oluştur, dashboard’ları buna taşı ve export’ları audit ile yönet.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ PII alan kataloğu çıkarıldı
- ▢ ✅ Maskeleme/anon/pseudo yaklaşımı alan bazında belirlendi
- ▢ ✅ Privacy view oluşturuldu ve dashboard’lar taşındı
- ▢ ✅ Export yetkileri kısıtlı ve audit’li
- ▢ ✅ Yıllık gözden geçirme planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
5) Kontrol listesi
- •PII alan kataloğu çıkarıldı
- •Maskeleme/anon/pseudo yaklaşımı alan bazında belirlendi
- •Privacy view oluşturuldu ve dashboard’lar taşındı
- •Export yetkileri kısıtlı ve audit’li
- •Yıllık gözden geçirme planı var
Deliverables + “Buraya:” notları
Bir Sonraki Adım
BI/warehouse katmanında PII riskini tarar; anonim/pseudo model ve maskeleme kurallarıyla raporlamayı KVKK’ya daha dayanıklı hale getirir.