1. Misafir Wi-Fi Nedir? KVKK Açısından Nasıl Yönetilmeli?
Misafir Wi-Fi KVKK açısından nasıl yönetilmeli?
Kısa yanıt: misafire captive portal üzerinden aydınlatma gösterin, kimlik doğrulamayı amaçla sınırlayın, loglamayı minimum veri prensibiyle yapın, misafir/çalışan ağlarını segmentleyin ve admin erişimlerini RBAC+MFA ile yönetin. KVKK açısından kritik nokta, ağ hizmetinin “izlenebilir” ama “gereksiz veri toplayan” hale gelmemesidir.
Misafir Wi-Fi veri temas noktaları
- •Captive portal giriş ekranı (aydınlatma + onay)
- •Kimlik doğrulama yöntemi (oda no/SMS)
- •Ağ tanımlayıcıları (IP/MAC)
- •Trafik/erişim logları (kapsam sınırı kritik)
- •Admin paneli (kim erişti, ne değiştirdi)
Kamusal alan senaryosu: lobi, restoran, havuz
Kamusal alanlarda kullanıcı yoğunluğu ve cihaz çeşitliliği artar; bu yüzden segmentasyon, rate limit ve log erişim kontrolü daha da önem kazanır.
☑ Mini Check
- •Captive portal var ve aydınlatma gösteriyor mu?
- •Kimlik doğrulama “minimum veri” ile mi?
- •Loglar minimum set mi (zaman + IP/MAC + olay)?
- •Misafir ve çalışan ağları ayrı mı?
- •Admin panel erişimi kısıtlı mı?
Ne yapmalıyım?
- • Misafir Wi-Fi akışını dokümante edin (portal → doğrulama → erişim).
- • Log setinizi yazılı hale getirin (ne var, ne yok).
- • Misafir/çalışan ağlarını VLAN/SSID ile ayırın.
- • Admin panel erişimini kısıtlayın (MFA + IP kısıtı).
- • Sunucu güvenliğiyle birlikte ele alın: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
2. Captive Portal ve Aydınlatma Metni: Ekranda Neler Olmalı?
Captive portal’da neler gösterilmeli?
Kısa yanıt: hizmetin amacı, hangi verilerin toplandığı (genel seviye), loglama yaklaşımı (sınırlı), saklama politikasına referans ve iletişim/başvuru kanalı gibi temel bilgilendirme öğeleri. Kullanıcı, Wi-Fi’ye bağlanmadan önce “neye dahil olduğunu” anlamalıdır.
Captive portal UX bileşenleri (pratik set)
- •Başlık: “Misafir Wi-Fi Ağı”
- •Kısa aydınlatma özeti (2–3 cümle)
- •Detay metne link (aydınlatma)
- •Giriş yöntemi seçimi (oda no / SMS)
- •Destek kanalı (resepsiyon / IT)
- •“Bağlan” aksiyonu
Otel için giriş yöntemi seçimi: oda no vs SMS
- •Oda numarası: operasyonel kolay, ama doğrulama hataları yönetilmeli
- •SMS: doğrulama güçlü olabilir, ancak gereksiz veri toplamamaya dikkat edilmeli (minimum alan)
☑ Mini Check
- •Aydınlatma özeti okunabilir mi (mobilde de)?
- •Detay metne link var mı?
- •Giriş yöntemi minimum veri ile mi?
- •Portal ekranı dil/ülke uyumlu mu? (turizm bağlamı)
- •Portal değişiklikleri kayıt altına alınıyor mu?
Ne yapmalıyım?
- • Portal metnini 2–3 cümle “kısa özet” formatına indirin.
- • Detay aydınlatma linkini görünür konumlandırın.
- • Giriş yöntemini basitleştirin ve veri minimizasyonu uygulayın.
- • Portal değişikliklerini versiyonlayın (ne değişti?).
- • Otel dijital operasyon bağlamıyla ilişkilendirin: https://dgtlface.com/tr/otel-dijital-pazarlama
3. IP/MAC ve Trafik Logları: Ne Tutmalı, Ne Tutmamalı?
Hangi Wi-Fi loglarını tutmak gerekir, hangilerini tutmamak daha doğrudur?
Kısa yanıt: hizmeti işletmek ve güvenliği sağlamak için gerekli minimum log setini tutmak; gereksiz trafik detaylarını (özellikle içerik seviyesinde) toplamaktan kaçınmaktır. Teknik olarak “amaçla uyumlu ve sınırlı” loglama esastır.
Minimum log seti (örnek)
- •Zaman damgası (login/logout)
- •Cihaza atanan IP
- •MAC adresi (politikaya göre maskeleme değerlendirmesi)
- •SSID/VLAN (misafir mi çalışan mı)
- •Kimlik doğrulama sonucu (başarılı/başarısız)
- •Admin aksiyon logları (konfig değişikliği)
Log türleri, saklama ve yetki matrisi tablosu
| Log türü | Veri | Amaç | Retention | Erişim rolü | Not |
|---|---|---|---|---|---|
| Oturum logu | Login/logout zamanı | Hizmeti işletmek ve olay analizi | Politikaya göre | Yetkili IT/BT | Minimum veri |
| Ağ atama logu | IP ve MAC | Cihaz/oturum eşlemesi | Politikaya göre | Yetkili IT/BT | MAC için maskeleme değerlendirmesi |
| Ağ segmenti logu | SSID/VLAN | Misafir–çalışan ağı ayrımını doğrulamak | Politikaya göre | Network yöneticisi | Misafir mi çalışan mı |
| Kimlik doğrulama logu | Başarılı/başarısız sonucu | Güvenlik ve brute force analizi | Politikaya göre | Yetkili IT/BT | Gereksiz kimlik detayı yok |
| Admin aksiyon logu | Konfigürasyon değişikliği | Audit ve yetki kontrolü | Politikaya göre | Sınırlı yönetici rolü | RBAC + MFA |
Trafik logları ve port/site bazlı detay
Port/URL bazlı ayrıntılı trafik logları, gereksiz veri biriktirme ve risk büyütme potansiyeline sahiptir. Bu rehber, “toplamayın” demek yerine şunu vurgular: böyle bir log gerekiyorsa, kapsam ve süre çok net tanımlanmalı; erişim çok sıkı olmalıdır.
☑ Mini Check
- •Log seti minimum ve amaç odaklı mı?
- •Trafik detay logları gereksiz yere açık mı?
- •Log erişimi kimlerde, RBAC var mı?
- •Log retention/rotate politikası var mı?
- •Loglar bütünlük ve güvenlik açısından korunuyor mu?
Ne yapmalıyım?
- • Log setinizi “minimum” olarak standardize edin.
- • Trafik detay loglarını kapatın veya çok sınırlı hale getirin.
- • Log erişimini role göre kısıtlayın (need-to-know).
- • Retention/rotate planını uygulayın (365 gün gözden geçirme).
- • Sunucu ve log güvenliğiyle birlikte ele alın: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
4. Kimlik Doğrulama: Oda Numarası, SMS, Kimlik vb. (Teknik Dikkat)
Kimlik doğrulama, Wi-Fi hizmetinin güvenliğini artırır; ancak veri toplama iştahını da büyütebilir. Buradaki denge: doğrulamayı iş ihtiyacı kadar yapmak ve doğrulama verisini sınırlı süre ve erişim ile saklamaktır.
Oda numarası ile login (otel için pratik)
- •Kullanıcı deneyimi hızlıdır
- •Hatalı oda girişi ve brute force denemeleri için rate limit gerekir
- •Oda numarasıyla kullanıcı kimliğini “aşırı ilişkilendirmemek” önemlidir
SMS ile login
- •Doğrulama güçlü olabilir
- •Telefon numarası ek bir kişisel veri alanıdır: minimum veri + güvenli saklama gerekir
- •SMS vendor’ı envantere dahil edilmelidir
Yönetici paneli: en kritik risk yüzeyi
Wi-Fi yönetim paneli; ağ konfigürasyonlarını, kullanıcı oturumlarını ve loglara erişimi barındırabilir. Bu yüzden panel erişimi RBAC + MFA + IP kısıtı ile korunmalı; panel aksiyonları audit’e alınmalıdır.
☑ Mini Check
- •Kimlik doğrulama yöntemi minimum veri ile mi?
- •SMS vendor ve süreçleri dokümante mi?
- •Rate limit ve brute force koruması var mı?
- •Yönetici panelinde MFA aktif mi?
- •Panel aksiyonları loglanıyor mu?
Ne yapmalıyım?
- • Doğrulamayı “en az veri” ile tasarlayın.
- • SMS kullanıyorsanız vendor envanteri + erişim kısıtını ekleyin.
- • Brute force için rate limit kurun.
- • Admin panelinde MFA ve IP allowlist uygulayın.
- • KVKK veri güvenliği yönetimiyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
5. Çalışan Ağı vs Misafir Ağı Ayrımı: Segmentasyon ve Yetkiler
Çalışan ve misafir ağları nasıl ayrılmalı?
Kısa yanıt: ayrı SSID/VLAN, ayrı firewall kuralları ve ayrı yönetim politikaları ile ayrılmalıdır. Misafir ağı, iç sistemlere (PMS/ERP/office) erişememeli; çalışan ağı da misafir trafiğiyle karışmamalıdır. Bu ayrım, hem güvenlik hem KVKK riskini azaltan temel tekniktir.
Segmentasyonun pratik çıktıları
- •Misafir ağı: internet erişimi + sınırlı servisler
- •Çalışan ağı: iç sistem erişimi + daha sıkı kullanıcı yönetimi
- •Yönetim ağı: admin panel erişimi (en kısıtlı)
AIO: “misafir Wi-Fi KVKK modeli” paragrafı
Wi-Fi ağı, captive portal, IP/MAC logları, kimlik doğrulama ve admin erişimi; tek bir misafir Wi-Fi KVKK modeli içinde yönetilmelidir: portal aydınlatma → doğrulama → minimum log → segmentasyon → erişim yetkisi → retention. Bu model kurulduğunda, yeni bir access point veya yeni bir portal değişikliği “sürpriz risk” yaratmaz; kontrol noktaları hazırdır.
Key Data Point (yumuşatılmış): Misafir Wi-Fi süreçleri KVKK’ya göre yapılandırıldığında, hem misafir güveni artar hem de olası denetim/olay durumlarında teknik savunma daha güçlü olur.
☑ Mini Check
- •Misafir ve çalışan ağı ayrı SSID/VLAN’da
- •Misafir ağı iç sistemlere erişemiyor
- •Yönetim ağı ayrı ve IP allowlist’li
- •Admin panel erişimi RBAC+MFA
- •Log retention ve erişim politikası yazılı
- •Portal metni ve süreçleri periyodik gözden geçiriliyor (365 gün)
Ne yapmalıyım?
- • Ağ segmentasyonunu (misafir/çalışan/yönetim) netleştirin.
- • Misafir ağından iç sistemlere erişimi kapatın.
- • Yönetim panelini ayrı yönetim ağında tutun.
- • Loglama politikasını minimum veri prensibiyle yazın.
- • İç linklerle süreçleri bağlayın:
- • https://dgtlface.com/tr/yazilim/sunucu-guvenlik
- • https://dgtlface.com/tr/otel-dijital-pazarlama
- • https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti
Teknik not: Loglama ve saklama tarafında hangi veri türünün ne kadar süre tutulacağı, hukuk danışmanının önerileri doğrultusunda belirlenmeli; teknik olarak gereğinden fazla veri loglanmamalıdır. Bu yazı hukuki tavsiye değil, teknik rehberdir.
6. Misafir Wi-Fi Captive Portal & Loglama KVKK Checklist Şablonunu İndir — Yazılım / Guest Wi-Fi
A) Checklist / Sprint Plan
[ ] Ölçüm & Önceliklendirme Checklist’i
Misafir Wi-Fi Captive Portal & Loglama KVKK Checklist Şablonunu İndir — Yazılım / Guest Wi-Fi (v1.0)
Bu asset, otel misafir Wi-Fi süreçlerini KVKK perspektifiyle standardize eder: captive portal aydınlatması, kimlik doğrulama yöntemi, minimum log seti, misafir/çalışan ağ ayrımı ve admin panel erişim güvenliği. Logların kapsamını ve erişim yetkilerini netleştirerek denetim ve incident anında savunmayı güçlendirir. Sahada uygulanabilir, düşük-panik bir kontrol listesi sunar.
Kim Kullanır?
Otel BT/Network ekibi + operasyon + güvenlik sorumluları.
Nasıl Kullanılır?
- Captive portal ekranını ve giriş yöntemini checklist’e göre gözden geçir.
- Log setini minimum veri prensibiyle seç; retention ve erişim rollerini tanımla.
- Ağ segmentasyonunu (misafir/çalışan/yönetim) uygula; admin panelini sıkılaştır ve provayı yap.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Captive portal aktif ve aydınlatma gösteriyor
- ▢ ✅ Aydınlatma özeti kısa ve okunabilir (mobil uyumlu)
- ▢ ✅ Detay metin linki görünür
- ▢ ✅ Login yöntemi minimum veri ile (oda no/SMS)
- ▢ ✅ Brute force için rate limit var
- ▢ ✅ Minimum log seti tanımlı (login/logout zamanı, IP, MAC, SSID)
- ▢ ✅ Trafik detay logları kapalı veya çok sınırlı
- ▢ ✅ Log maskeleme/PII minimizasyonu uygulanıyor
- ▢ ✅ Log retention/rotate politikası var
- ▢ ✅ Log erişimi RBAC ile kısıtlı
- ▢ ✅ Misafir ve çalışan ağı ayrı SSID/VLAN
- ▢ ✅ Misafir ağından iç sistemlere erişim kapalı
- ▢ ✅ Yönetim ağı ayrı ve IP allowlist’li
- ▢ ✅ Admin panel MFA aktif + audit log açık
- ▢ ✅ Portal/politika değişiklikleri versiyonlanıyor
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables
- •Captive portal mockup + metin versiyonu
- •Minimum log seti dokümanı + yetki matrisi
- •Ağ segmentasyon şeması (misafir/çalışan/yönetim)
- •Admin panel erişim politikası
- •Prova raporu + refresh planı
Bir Sonraki Adım
Captive portal, loglama ve misafir/çalışan ağ ayrımı kurgusunu netleştirir; denetim ve olay anında teknik savunmayı güçlendirir.
Sık Sorulan Sorular
Misafir Wi-Fi KVKK açısından nasıl yönetilmeli?▾
Captive portal’da neler gösterilmeli?▾
Hangi Wi-Fi loglarını tutmak gerekir, hangilerini tutmamak daha doğrudur?▾
Çalışan ve misafir ağları nasıl ayrılmalı?▾
SMS ile Wi-Fi doğrulamada dikkat edilmesi gereken teknik konu nedir?▾
Admin paneli neden kritik risk yüzeyidir?▾
İlgili İçerikler
İlgili Yazılar