1. Erişim logu nedir, KVKK için neden kritiktir?
Erişim logu, bir sistemdeki erişim ve işlem izlerinin “kanıt” niteliğindeki kaydıdır. KVKK açısından kritik olmasının nedeni, olay olduğunda “ne oldu?”dan önce şu sorulara cevap vermesidir: Kim erişti? Ne zaman erişti? Nereden erişti? Ne yaptı? Bu soruların cevabı yoksa, ihlal şüphesi “tahmin”e kalır; cevabı varsa olay incelemesi yönetilebilir olur.
AIO katmanını net kuruyoruz:
AccessLog → proves → who accessed which data
Yani log, sadece teknik bir çıktı değil; denetimde ve olay incelemede “kanıt seti”nin omurgasıdır.
Log tutmanın otel operasyonunda sağladığı 3 fayda
- •Olay inceleme hızlanır: PMS şifresi ele geçti şüphesinde timeline çıkarılır
- •Şüpheli erişimler erken yakalanır: gece saatlerinde sıra dışı panel girişleri
- •Yetki disiplini güçlenir: kim hangi rol ile ne yapıyor görünür olur
Mini örnek (Antalya sezon yoğunluğu):
Yoğun dönemde resepsiyon paneline farklı vardiyalarda çok sayıda giriş olur. Eğer log yoksa “hangi vardiyada ne oldu?” cevabı zorlaşır. Log + dashboard ile “alışılmadık IP” veya “çok sayıda başarısız giriş” gibi sinyaller erken fark edilir.
Ne yapmalıyım?
- • Kritik sistemleri listeleyin (PMS, panel, sunucu, DB).
- • Her sistem için minimum log alan setini belirleyin (aşağıda).
- • Günlük dashboard KPI’larını tanımlayın (3 senaryo).
2. Otelinizde hangi sistemlerin log’u tutulmalı?
“Her şeyi logla” yaklaşımı pratikte sürdürülemez; doğru yaklaşım “kritik sistemlerde standart log”tur. Oteller için çekirdek sistem seti genelde şunlardır:
1) PMS ve rezervasyon paneli
- •Login/logout
- •Kayıt görüntüleme (view) ve değişiklik (edit)
- •Rol/Yetki değişiklikleri
- •Kritik ekranlar: misafir profili, ödeme durumu, kimlik alanları (Varsayım: sistem izin veriyorsa)
2) Web admin paneli / CMS / yönetim panelleri
- •Admin girişleri ve şifre değişimleri
- •İçerik güncellemeleri (özellikle form alanları ve entegrasyon ayarları)
- •Kullanıcı oluşturma/rol atama
3) Sunucu ve veritabanı erişimleri
- •SSH/RDP girişleri (kim/ne zaman/IP)
- •DB bağlantıları (mümkünse)
- •Uygulama logları (API erişimleri, hata artışları)
İç link: /tr/yazilim/sunucu-guvenlik
4) Çağrı merkezi / CRM ve entegrasyonlar (kritik transfer noktaları)
- •CRM erişimleri ve export işlemleri
- •Entegrasyon API çağrıları (OTA, kanal yöneticisi vb.)
İç link: /tr/pms-ota-yonetimi
Mini örnek (Belek):
Çağrı merkezi CRM’den misafir listesi export ediyorsa, “export log” olmadan riskin nerede büyüdüğünü göremezsiniz. Bu nedenle log kapsamına “export/indir” işlemleri mutlaka eklenir.
Ne yapmalıyım?
- • Kapsamı 4 çekirdek sistemle başlatın.
- • “Export/indir” işlemlerini ayrı risk olarak izleyin.
- • Log yoksa, bunu “iyileştirme aksiyonu” olarak plana alın.
3. Erişim loglarında hangi alanlar yer almalıdır?
Log’ların işe yaraması için alan seti standardı gerekir. En basit ama etkili yaklaşım: User + Role + Action + Timestamp + IP + System + Result.
Örnek log alanları (standart tablo)
| Alan | Açıklama | Örnek |
|---|---|---|
| event_id | Tekil kayıt | e_2026_001 |
| system | Kaynak sistem | PMS / AdminPanel / Server |
| user_id | Kullanıcı kimliği | u_1832 |
| role | Rol | FrontDesk / Admin |
| action | İşlem tipi | LOGIN / VIEW / EDIT / EXPORT |
| object | Hedef (varsa) | reservation/123 |
| timestamp | Zaman | 2026-01-12T10:15:00+03:00 |
| ip_address | IP | 185.xxx.xxx.xxx |
| device/session | Oturum | session_... |
| result | Sonuç | SUCCESS / FAIL |
| reason | Hata nedeni | wrong_password (opsiyonel) |
Saat senkronizasyonu (kritik ama unutulan madde)
Olay incelemede en büyük problem “zamanlar tutmuyor” durumudur. Bu yüzden:
- •Tüm sistemlerde saat senkronu (Varsayım: NTP)
- •Log timestamp formatı standardı (ISO)
- •Zaman dilimi tutarlılığı (+03:00 gibi)
Ne yapmalıyım?
- • Minimum alan setini tüm sistemlerde aynı tutun.
- • Timestamp standardını yazılı hale getirin.
- • Log’ları merkezi bir yerde toplayacaksanız “system” alanını zorunlu kılın.
4. KVKK raporları için örnek izleme dashboard’ları
Dashboard’ın amacı “güzel grafik” değil; şüpheli erişimleri erken görmek ve denetimde hızlı özet sunmaktır. Burada 3 pratik senaryo öneriyoruz.
Senaryo 1 — Günlük erişim özeti (yönetim + IT ortak ekranı)
- •Toplam login sayısı (PMS + panel + sunucu)
- •Başarısız giriş sayısı ve oranı
- •En çok giriş yapılan sistemler
- •Olağan dışı saatlerde girişler (gece 02:00 gibi)
Senaryo 2 — Şüpheli erişim sinyalleri (erken uyarı)
- •Aynı kullanıcıyla kısa sürede çok sayıda fail login
- •Farklı IP’lerden ani erişim
- •Yetki yükseltme (rol değişimi) olayları
- •“EXPORT” aksiyonlarında artış
Senaryo 3 — Denetim kanıt paneli (audit view)
- •Son 30 gün: log kapsama oranı (hangi sistemler aktif log üretiyor)
- •Log saklama durumu (Varsayım: süre etiketleri)
- •Örnek olay: incident timeline’a bağlanan log listesi
Mini örnek (Side/Kemer):
PMS’te export işlemleri artıyorsa, bu bazen raporlama ihtiyacı olabilir; bazen de kontrolsüz veri kopyalama riskidir. Dashboard “EXPORT trend” ile bu sinyali görünür kılar, ekip doğru soruyu sorar.
Ne yapmalıyım?
- • Dashboard’u 5 KPI ile başlatın (fazla karmaşık yapmayın).
- • Günlük 5 dakikalık kontrol rutini belirleyin (sahip + saat).
- • Şüpheli sinyaller için “ne yapacağız?” mini prosedürü ekleyin.
5. Olay inceleme ve denetimlerde log kullanımı
Log’lar iki kritik durumda “hayat kurtarır”:
- Olay inceleme: PMS şifresi sızdı şüphesi, yanlış mail, açık terminal
- Denetim: “bu sistemlere kim erişiyor, kanıtınız var mı?” sorusu
Olay incelemede pratik yaklaşım (timeline)
- •Olay ID oluştur
- •İlgili zaman aralığını belirle (T0-24h gibi)
- •PMS/panel/sunucu loglarını tek timeline’da birleştir
- •Etkilenen veri setlerini notla (kimlik/iletişim/rezervasyon)
- •Aksiyonları log kanıtı ile bağla (parola reset → sonraki loginler)
Log’ların korunması (KVKK + güvenlik)
- •Log’a erişimi rol bazlı kısıtla
- •Log’ları değiştirmeye karşı koru (append-only yaklaşımı, Varsayım)
- •Saklama sürelerini yazılı hale getir (sınırsız değil, planlı)
- •Log’ları yedekle
İç link notu: Bu içerik /tr/raporlama/kvkk-veri-guvenligi paketiyle birlikte; teknik derinleşme için /tr/yazilim/sunucu-guvenlik ve süreç bağlamı için /tr/pms-ota-yonetimi sayfalarına bağlanmalıdır.
6. Erişim Log Alanları & Dashboard Örnek Şablonunu İndir — Veri Analizi & Raporlama
Erişim Log Alanları & Dashboard Örnek Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Bu şablon, otellerin PMS, admin panel ve sunucu erişim loglarını ortak bir alan setiyle standardize etmesini ve bu veriden günlük izleme dashboard’ları üretmesini kolaylaştırır. Amaç; KVKK denetimlerinde “kim erişti?” kanıtını hızla sunmak ve şüpheli erişimleri dashboard üzerinden erken tespit etmektir. Şablon, log alanları + 3 dashboard senaryosu KPI seti içerir.
Kim Kullanır?
IT/teknik ekip, ajans yöneticisi, operasyon lideri (yönetim görünümü için GM).
Nasıl Kullanılır?
- Tüm sistemlerden gelen logları bu alan setine map edin (PMS/panel/sunucu).
- Timestamp ve saat senkronunu doğrulayın; fail/success ayrımını netleştirin.
- Dashboard KPI’larını kurup günlük 5 dakikalık izleme rutini başlatın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ A) Minimum Alan Seti (zorunlu)
- ▢ ✅ B) Önerilen Alanlar (opsiyonel ama güçlü)
- ▢ ✅ C) Timestamp Standardı (kural seti)
- ▢ ✅ 1) Günlük erişim özeti
- ▢ ✅ 2) Şüpheli erişim sinyalleri
- ▢ ✅ 3) Denetim kanıt paneli
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
PMS, panel ve sunucu log kapsamınızı çıkarıp, otelinize uygun izleme dashboard’unu birlikte kuralım.