1. Misafir Wi-Fi ağlarında hangi veriler toplanır?
Wi-Fi altyapısı iki katmanda veri üretir: ağ katmanı logları ve kimlik doğrulama (captive portal) verileri. KVKK uyumu için önce “hangi veri nerede oluşuyor?” sorusunu yanıtlamak gerekir.
1) Zorunlu/teknik log alanları (ağ katmanı)
Teknik logların amacı; ağ güvenliği, kapasite yönetimi ve olay incelemedir. Tipik alanlar:
- •MAC adresi (cihaz kimliği)
- •IP adresi (atama bilgisi)
- •Bağlantı zamanı (start/end)
- •AP/SSID bilgisi (hangi erişim noktasından)
- •Oturum/Session ID
- •Cihaz bilgisi (User-Agent/OS) (Varsayım: bazı sistemler)
- •Toplam trafik (aggregate seviyede)
2) Kimlik doğrulama verileri (login)
Login ekranında toplanan veri, “teknik log”tan farklı olarak kimlikle ilişkilidir:
- •Oda numarası (room no)
- •Telefon/SMS doğrulama (Varsayım: kullanım)
- •İsim/soyisim (bazı otellerde)
Bu alanlar minimum tutulmalıdır; aksi halde Wi-Fi, pazarlama PII deposuna dönüşür.
3) “Zorunlu loglar” vs “fazla toplanan veriler”
Bu ayrım, raporun omurgasıdır:
- •Zorunlu teknik log: güvenlik/operasyon için gerekli
- •İsteğe bağlı pazarlama veri toplama: ek risk ve ek sorumluluk getirir
AIO çerçevesi: Wi-Fi Logs → should remain → technical, not marketing PII dump.
| Alan | Sınıf | Kullanım / Not | Öneri |
|---|---|---|---|
| timestamp (start/end) | Zorunlu/teknik | Bağlantı zamanı | Tut |
| session_id | Zorunlu/teknik | Oturum bilgisi | Tut |
| IP address | Zorunlu/teknik | IP atama bilgisi | Tut |
| SSID/AP | Zorunlu/teknik | Erişim noktası | Tut |
| device_type | Zorunlu/teknik | Varsayım: mümkünse | Tut |
| result (success/fail) | Zorunlu/teknik | Varsayım | Tut |
| MAC address | Dikkatli/opsiyonel | Mümkünse hash/mask, Varsayım | Gerekçe ile tut |
| Oda numarası | Dikkatli/opsiyonel | Minimum doğrulama, pazarlamaya gitmez | Gerekçe ile tut |
| Telefon/SMS | Dikkatli/opsiyonel | Kullanılıyorsa amaç+süre net | Gerekçe ile tut |
| Ad-soyad | Gereksiz risk | Erişim için gereksiz | Tutma / pazarlamaya aktarma |
| Doğum tarihi | Gereksiz risk | Erişim için gereksiz | Tutma / pazarlamaya aktarma |
| Pasaport/kimlik | Gereksiz risk | Erişim için gereksiz | Tutma / pazarlamaya aktarma |
| Serbest not alanları | Gereksiz risk | Kontrolsüz veri riski | Tutma / pazarlamaya aktarma |
Mini örnek (Antalya resort)
Misafir Wi-Fi’ye bağlanmak için isim + doğum tarihi + telefon isteniyorsa, bu verilerin çoğu ağ erişimi için gereksizdir. Bu gereksizlik hem risk hem de operasyonel sürtünme üretir. “Minimum login” ile hem misafir deneyimi hem KVKK uyumu güçlenir.
☑ Mini Check
- •Teknik log alanları ile login verileri ayrıldı mı?
- •Login ekranında yalnız minimum alanlar var mı?
- •Wi-Fi verisi pazarlamaya ham PII olarak aktarılmıyor mu?
Ne yapmalıyım?
- • Wi-Fi’de “teknik log” ve “login verisi”ni iki farklı tabloyla envantere alın.
- • Login alanlarını minimuma indirin (oda no veya token; gereksiz PII yok).
- • Pazarlamaya yalnız anonim/aggregate metrik aktarın.
2. Wi-Fi erişim loglarını KVKK’ya uygun nasıl raporlarsınız?
KVKK uyumlu raporlama; (a) minimizasyon, (b) güvenli saklama, (c) erişim kontrolü, (d) raporlanabilir kanıt dörtlemesiyle kurulur.
Adım 1 — Log alanlarını standardize edin (minimum set)
Wi-Fi log raporlarında amaç, “her alanı” değil, “kanıt için yeterli alanı” tutmaktır. Minimum alan seti örneği:
- •timestamp (start/end)
- •MAC (maskeli/hashed, mümkünse) (Varsayım)
- •IP
- •SSID/AP
- •session_id
- •result (success/fail) (Varsayım)
Adım 2 — Logları güvenli saklayın (şifreleme + sınırlı erişim)
- •Log verisi şifreli saklanmalı (at rest)
- •Log erişimi rol bazlı olmalı (IT/güvenlik)
- •Pazarlama ekibi loglara doğrudan erişmemeli; yalnız anonim özet almalı
Adım 3 — Saklama süresi ve rapor kanıtı
Kesin süre rakamı vermiyoruz; süreler hukuk birimiyle belirlenir. Ancak raporlama standardı net:
- •retention policy (Wi-Fi logları için)
- •aylık silme/temizleme job raporu (Varsayım: otomasyon varsa)
- •erişim logu (kim erişti?)
Adım 4 — Anonim raporlama katmanı
Wi-Fi verisini pazarlamada kullanmak istiyorsanız, prensip:
- •kişi bazlı değil aggregate metrik
- •“hangi misafir” değil “hangi segment/ülke/dil yoğunluğu”
- •remarketing için ham Wi-Fi kimliği değil, izinli evren + anonim sinyaller (yüksek seviye)
Key Statistics / Data Point (yumuşatılmış)
Wi-Fi loglarını sadeleştirip yalnız teknik olarak gerekli alanları tutan otellerde, hem sistem karmaşasının hem de KVKK risk profilinin anlamlı şekilde iyileşmesi teorik olarak beklenir; çünkü gereksiz PII yüzeyi azalır.
☑ Mini Check
- •Loglar şifreli mi ve erişim rolleri sınırlı mı?
- •Retention policy + job raporu var mı?
- •Pazarlamaya ham log değil anonim metrik gidiyor mu?
Ne yapmalıyım?
- • Wi-Fi loglarını “IT/güvenlik kanıt seti” olarak konumlandırın.
- • Pazarlama için ayrı “anonim Wi-Fi dashboard” üretin.
- • Login alanlarını minimizasyonla yeniden tasarlayın.
3. Login ekranında oda no/telefon gibi bilgileri nasıl sınırlamalıyım?
Login ekranı (captive portal), KVKK riskinin en hızlı büyüdüğü noktadır. Çünkü burada toplanan her alan, doğrudan kimlikle ilişkilidir. Hedef, minimum kimlik doğrulamadır.
Minimum kimlik doğrulama seçenekleri (yüksek seviye)
- •Oda no + soyadın ilk harfi gibi minimal doğrulama (Varsayım)
- •Tek kullanımlık voucher/token (front office verir)
- •SMS doğrulama (kullanılıyorsa: minimum alan + açık amaç)
“Zorunlu” ve “nice-to-have” ayrımı
- •Zorunlu: erişimi yetkilendirmek için gerekli minimum veri
- •Nice-to-have: pazarlama/analitik için ek veri → ayrı değerlendirme ve ek risk
Oda numarası ile giriş “doğru mu?”
Tek bir doğru yok; ama prensip şudur: oda numarası, tek başına “kimlik” değilse bile misafirle ilişkilendirilebilir. Bu yüzden:
- •oda no + ek minimal doğrulama
- •saklama süresini sınırlama
- •pazarlamada kişi bazlı kullanılmama
Mini örnek
Resort otelde aile üyeleri aynı odada farklı cihazlarla bağlanır. Oda no’yu “kişisel profil” gibi pazarlamaya taşımak gereksiz risk doğurur. Wi-Fi login verisi, erişim yetkilendirme dışında büyütülmemelidir.
☑ Mini Check
- •Login ekranında gereksiz alanlar kaldırıldı mı?
- •SMS/telefon kullanılıyorsa amaç ve saklama net mi?
- •Login verisi pazarlamaya kişi bazlı taşınmıyor mu?
Ne yapmalıyım?
- • Login alanlarını minimuma indirin ve yazılı hale getirin.
- • Token/voucher yaklaşımını değerlendirin (Varsayım).
- • Login verisini retention policy ile sınırlayın.
4. Wi-Fi verisini pazarlama/analitik tarafına nasıl anonimleştirerek aktarırsınız?
Wi-Fi’nin pazarlamaya katkısı, “kim bağlandı?” değil “hangi saatlerde/hangi bölgelerde yoğunluk var?” gibi aggregate içgörüdür. KVKK uyumlu yaklaşım; kişisel veri yerine anonim KPI kullanmaktır.
Anonim/aggregate Wi-Fi KPI örnekleri
- •Günlük bağlantı sayısı (toplam)
- •Saatlik yoğunluk (heatmap)
- •SSID/AP bazlı yoğunluk (lobi/havuz)
- •Cihaz türü dağılımı (iOS/Android) (Varsayım)
- •Ortalama oturum süresi (aggregate)
- •Kampanya döneminde “izinli evren” artışı (Varsayım: consent ile bağlıysa)
Pazarlama ile paylaşım için sınır çizgisi
- •Ham MAC/IP listesi pazarlamaya gitmez
- •Oda no/telefon gibi login verisi pazarlamaya gitmez
- •Paylaşım: yalnız “anonim dashboard” ve gerektiğinde dönemsel rapor
Mini örnek (Antalya)
Havuz alanı Wi-Fi yoğunluğu artıyorsa, operasyon bunu personel planlamasına kullanabilir. Pazarlama ise “kampanya günü yoğunluk artışı” gibi aggregate KPI ile çalışır; kişisel listeye ihtiyaç duymaz.
☑ Mini Check
- •Pazarlama raporları tamamen aggregate mı?
- •Wi-Fi ham logları yalnız IT/güvenlikte mi?
- •Paylaşım “safe view” üzerinden mi?
Ne yapmalıyım?
- • Wi-Fi pazarlama çıktısını sadece KPI seviyesinde üretin.
- • Ham log erişimini RBAC ile sınırlandırın.
- • “Anonim Wi-Fi dashboard”u raporlama hub’ına bağlayın.
5. 3 Wi-Fi veri toplama hatası / 3 çözüm
- Hata: Login ekranında gereksiz PII (isim+doğum tarihi vb.) → Çözüm: Minimum login alan seti + token/voucher opsiyonu
- Hata: Ham MAC/IP loglarını pazarlama sistemine aktarmak → Çözüm: Pazarlamaya yalnız anonim/aggregate KPI; ham log IT’de kalır
- Hata: Log saklama süresi belirsiz, erişim kontrolü zayıf → Çözüm: Retention policy + şifreli saklama + rol bazlı erişim + erişim logu
İç link notu: /tr/raporlama, /tr/raporlama/kvkk-veri-guvenligi, /tr/yazilim/sunucu-guvenlik ve /tr/otel-dijital-pazarlama sayfalarına bağlayın.
6. Wi-Fi Erişim Log Alanları & Saklama Checklist’ini İndir — Misafir Wi-Fi (v1.0)
Wi-Fi Erişim Log Alanları & Saklama Checklist’ini İndir — Misafir Wi-Fi (v1.0)
Bu checklist, otellerin misafir Wi-Fi loglarını KVKK uyumlu şekilde “minimum veri + süreli saklama + rol bazlı erişim” prensibiyle standardize etmesini sağlar. Amaç; zorunlu teknik log alanlarını netleştirmek, login ekranındaki kimlik verisini minimumda tutmak, logları şifreli ve kontrollü saklamak ve pazarlamaya yalnız anonim/aggregate metrik aktarmaktır.
Kim Kullanır?
IT/ağ ekibi, güvenlik, GM (onay), pazarlama lideri (anonim KPI tüketicisi).
Nasıl Kullanılır?
- Log alan setini “zorunlu/opsiyonel” olarak sınıflandırın ve minimumu kilitleyin.
- Login ekranındaki alanları minimizasyonla sadeleştirin; erişim yetkilerini RBAC ile sınırlandırın.
- Aylık raporda erişim logu, saklama job’u ve anonim KPI çıktısını birlikte sunun.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ A) Wi-Fi Log Alanları Checklist’i (Zorunlu vs Riskli)
- ▢ ✅ Zorunlu/teknik (tut)
- ▢ ✅ timestamp (start/end)
- ▢ ✅ session_id
- ▢ ✅ IP address
- ▢ ✅ SSID/AP
- ▢ ✅ device_type (Varsayım: mümkünse)
- ▢ ✅ result (success/fail) (Varsayım)
- ▢ ✅ Dikkatli/opsiyonel (gerekçe ile)
- ▢ ✅ MAC address (mümkünse hash/mask, Varsayım)
- ▢ ✅ oda numarası (minimum doğrulama, pazarlamaya gitmez)
- ▢ ✅ telefon/SMS (kullanılıyorsa amaç+süre net)
- ▢ ✅ Gereksiz risk (tutma / pazarlamaya aktarma)
- ▢ ✅ ad-soyad
- ▢ ✅ doğum tarihi
- ▢ ✅ pasaport/kimlik
- ▢ ✅ serbest not alanları
- ▢ ✅ B) Log Saklama & Erişim Checklist’i
- ▢ ✅ Loglar şifreli saklanıyor (at rest)
- ▢ ✅ Erişim role-based (IT/Güvenlik)
- ▢ ✅ Erişim logu tutuluyor (kim, ne zaman erişti)
- ▢ ✅ Retention policy yazılı (hukukla belirlenir)
- ▢ ✅ Silme/temizleme job raporu var (Varsayım: otomasyon)
- ▢ ✅ C) Pazarlama/Analitik İçin Anonim KPI Seti (öneri)
- ▢ ✅ Günlük bağlantı sayısı
- ▢ ✅ Saatlik yoğunluk ısı haritası
- ▢ ✅ AP/SSID bazlı yoğunluk (lobi/havuz)
- ▢ ✅ Ortalama oturum süresi (aggregate)
- ▢ ✅ Kampanya döneminde yoğunluk trendi
- ▢ ✅ D) 14 Günlük Sprint Planı (kurulum)
- ▢ ✅ E) Öncesi/Sonrası KPI Tablosu
- ▢ ✅ Deliverables
- ▢ ✅ Minimum Wi-Fi log alan seti
- ▢ ✅ Login minimizasyon kuralı
- ▢ ✅ Anonim KPI dashboard şablonu
- ▢ ✅ Denetim için aylık rapor paketi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Wi-Fi login ve log akışınızı KVKK uyumlu şekilde optimize edelim.