Zincir Otellerde Çoklu Lokasyon 5651

Zincir Otellerde Çoklu Lokasyon 5651 Loglama: Merkezi Yönetim ve Yasal Uyum Stratejisi

Türkiye genelinde on, yirmi veya daha fazla şubesi bulunan otel zincirleri, 5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi ve Bu Yayınlar Yoluyla İşlenen Suçlarla Mücadele Edilmesi Hakkında Kanun'un getirdiği log saklama yükümlülüğünü her lokasyonda ayrı ayrı yönetmek zorunda kalmaktadır. Ancak şube sayısı arttıkça, her tesiste farklı donanım, farklı operatör, farklı log formatı ve farklı saklama altyapısı kullanmak hem operasyonel karmaşıklığı katlar, hem de yasal denetim sırasında tutarsızlıklara yol açar. Bu yazıda, zincir otellerin çoklu lokasyonlarda 5651 loglama sürecini nasıl merkezileştireceğini, hangi teknik mimarinin en verimli sonucu verdiğini ve KVKK uyumunu nasıl sağlayacağını gerçek senaryolar, karşılaştırma tabloları ve adım adım kurulum önerileriyle inceleyeceğiz.

Çoklu Lokasyonda 5651 Loglama Neden Zorunlu ve Neden Zor?

5651 sayılı kanun, internet erişimi sağlayan her işletmenin—otel, kafe, AVM, kütüphane—kullanıcı bağlantı kayıtlarını (IP adresi, bağlantı zamanı, cihaz MAC adresi, oturum süresi) en az bir yıl boyunca saklamasını zorunlu kılar. Zincir otellerde bu yükümlülük her şube için ayrı ayrı geçerlidir; İstanbul Kadıköy'deki otel ile Antalya Belek'teki tesis arasında yasal fark yoktur. Her ikisi de BTK ve emniyet denetimlerine tabidir. Ancak pratikte şu sorunlar ortaya çıkar:

• Farklı donanım markaları: Bir şubede FortiGate 60F, diğerinde MikroTik hAP ac³, üçüncüsünde Sophos XG 106 kullanılıyorsa, her birinin syslog formatı, zaman damgası yapısı ve log alanları farklıdır. Merkezi bir raporlama için bu logları normalize etmek gerekir.
• Yerel sunucu maliyeti: Her otele ayrı log sunucusu kurmak, lisans, bakım, yedekleme ve güvenlik güncellemesi maliyetlerini şube sayısı kadar çoğaltır.
• Denetim tutarsızlığı: Emniyet veya BTK denetimi sırasında, bir şubede loglar düzgün saklanırken diğerinde disk dolmuş veya servis durmuşsa, zincir genelinde itibar kaybı ve ceza riski doğar.
• PMS entegrasyonu: Opera, Elektraweb, Amonra gibi otel ön büro sistemleriyle entegrasyon her şubede tekrarlanmalı, oda numarası–misafir eşleştirmesi merkezi bir veri tabanında toplanmalıdır.

Bu nedenle, zincir oteller için en akıllı yaklaşım bulut tabanlı merkezi loglama mimarisidir. Tüm şubeler loglarını tek bir bulut platformuna gönderir, merkez ofis veya IT ekibi tüm lokasyonları tek ekrandan izler, raporlar ve denetim taleplerini dakikalar içinde karşılar.

Merkezi Bulut Loglama ile Appliance Karşılaştırması

Yukarıdaki tablo, 10 şubeli bir otel zincirinin bulut çözümüyle yıllık 150.000-200.000 TL donanım ve işçilik maliyetinden tasarruf edebileceğini göstermektedir. Ayrıca, denetim sırasında tüm şubelerin loglarını birleşik formatta sunmak, BTK veya emniyet ekiplerinin işini kolaylaştırır ve işletmenin profesyonellik algısını güçlendirir.

Adım Adım: Çoklu Lokasyon 5651 Loglama Mimarisi Kurulumu

1. Merkezi Bulut Platformu Seçimi ve Hesap Yapılandırması

NextLog5651 gibi bir bulut loglama platformunda, önce zincir genelinde bir ana hesap (master account) oluşturulur. Bu hesap altında her otel şubesi için ayrı bir lokasyon profili tanımlanır. Örneğin:

• Lokasyon ID: IST-KDY-01 (İstanbul Kadıköy Şubesi)
• Lokasyon ID: AYT-BLK-02 (Antalya Belek Şubesi)
• Lokasyon ID: IZM-CSM-03 (İzmir Çeşme Şubesi)

Her lokasyon profili, o şubenin IP bloğu, zaman dilimi (TSI), PMS entegrasyon bilgileri ve yetkili personel listesini içerir. Böylece, İstanbul şubesinin IT sorumlusu yalnızca kendi lokasyonunun loglarını görebilir, merkez ofis IT yöneticisi ise tüm zincirleri görüntüleyebilir.

2. Şube Firewall/Router Syslog Yapılandırması

Her otelde mevcut firewall veya router cihazı, logları bulut platformuna göndermek üzere yapılandırılır. Örnekler:

• FortiGate 60F (Kadıköy şubesi): CLI üzerinden config log syslogd setting komutuyla bulut platformunun IP adresi ve port numarası (genellikle TCP 6514 veya UDP 514) girilir. Zaman damgası formatı UTC+3 olarak ayarlanır.
• MikroTik hAP ac³ (Belek şubesi): Winbox veya WebFig üzerinden System > Logging menüsünden yeni bir "Remote" action oluşturulur, hedef IP ve port belirlenir. Log türü olarak "info" ve "warning" seçilir, böylece gereksiz debug logları gönderilmez.
• Sophos XG 106 (Çeşme şubesi): Web admin panelinden Log Settings > Syslog bölümünde bulut sunucu IP'si eklenir, "Send all logs" yerine yalnızca "Firewall" ve "Web" kategorileri seçilerek bant genişliği optimize edilir.

Her cihazın syslog mesajı formatı farklı olduğundan, bulut platformu bu logları alırken parser (ayrıştırıcı) modülleri kullanır. NextLog5651, FortiGate, MikroTik, Sophos, SonicWall ve Cisco için hazır parser'lar sunar; bu sayede her marka logdan IP, MAC, zaman, kaynak/hedef port bilgileri otomatik çıkarılır ve standart bir veritabanı şemasına yazılır.

3. Otel PMS Entegrasyonu ve Oda-Misafir Eşleştirmesi

5651 loglama, yalnızca IP ve MAC kaydetmekle kalmaz; otel bağlamında hangi odanın hangi misafire ait olduğunu da bilmelidir. Bunun için PMS (Property Management System) entegrasyonu şarttır:

• Opera PMS: OPERA OVOS (Oracle Hospitality Integration Platform) üzerinden REST API ile check-in/check-out olayları bulut platforma push edilir. Misafir adı, TC kimlik numarası, pasaport numarası, oda numarası ve konaklama tarihleri JSON formatında gönderilir.
• Elektraweb: Elektraweb'in SQL veritabanına doğrudan bağlantı (read-only kullanıcı) veya Elektraweb API modülü kullanılarak, her saat başı yeni rezervasyonlar ve check-in'ler senkronize edilir.
• Amonra: Amonra'nın webhook özelliği etkinleştirilerek, yeni misafir kaydı oluştuğunda otomatik HTTP POST ile bulut platforma bildirim gönderilir.

Entegrasyon sonrası, bulut platformda her lokasyon için bir oda-IP mapping tablosu oluşur. Örneğin, Kadıköy şubesinde 201 numaralı odaya 10.20.1.50 IP'si atanmışsa ve bu oda 15-17 Ocak tarihleri arasında "Ahmet Yılmaz, TC: 12345678901" adlı misafirde ise, bu bilgiler zaman damgasıyla birlikte saklanır. Denetim sırasında, emniyet "15 Ocak 14:30'da 10.20.1.50 IP'sinden erişim yapan kişi kim?" sorusunu sorduğunda, sistem otomatik olarak "201 nolu oda, Ahmet Yılmaz" yanıtını verir.

4. Zaman Senkronizasyonu ve NTP Yapılandırması

Çoklu lokasyonda en kritik teknik detaylardan biri zaman damgası tutarlılığıdır. Kadıköy şubesindeki firewall yerel saat kullanıyorsa, Belek şubesi UTC kullanıyorsa, Çeşme şubesi ise yanlış yapılandırılmış bir NTP sunucusundan saat alıyorsa, aynı olayın farklı lokasyonlarda farklı zaman damgalarıyla kaydedilmesi hukuki sorun yaratır. Çözüm:

• Tüm şubelerde aynı NTP sunucusu kullanılmalı (örneğin, TÜBİTAK UME ntp.ulakbim.gov.tr veya Google Public NTP time.google.com).
• Firewall/router cihazlarında zaman dilimi UTC+3 (Europe/Istanbul) olarak ayarlanmalı.
• Bulut platformu, gelen logları UTC formatında saklamalı, raporlarda ise Türkiye saati (TSI) ile göstermeli.
• Her ay, merkez IT ekibi tüm cihazların NTP senkronizasyon durumunu kontrol etmeli; 1 saniyeden fazla sapma varsa alarm üretilmeli.

Örnek kontrol komutu (FortiGate CLI): execute time komutuyla cihaz saati görüntülenir, config system ntp ile NTP sunucusu doğrulanır. MikroTik'te /system ntp client print komutu kullanılır.

5. Merkezi Raporlama ve Denetim Hazırlığı

Bulut platformun en büyük avantajı, tüm lokasyonları kapsayan birleşik raporlar oluşturabilmesidir. Zincir IT yöneticisi, web panelinden:

• Lokasyon bazlı log hacmi: Hangi şubenin ne kadar log ürettiğini, hangi şubede anormal trafik artışı olduğunu görür.
• Kullanıcı aktivite özeti: Belirli bir tarih aralığında tüm zincirlerde kaç misafirin internet kullandığını, ortalama oturum süresini, en çok ziyaret edilen siteleri listeler.
• Uyumluluk kontrol listesi: Her lokasyon için "son 365 günün logu tam mı?", "PMS entegrasyonu çalışıyor mu?", "disk kullanımı %80'i aşmış mı?" gibi kriterleri otomatik kontrol eder.
• Denetim raporu: BTK veya emniyet talebi geldiğinde, talep edilen tarih aralığı, IP adresi veya misafir adı girilerek, tüm ilgili lokasyonların logları tek bir PDF veya Excel dosyasında birleştirilir. Rapor, dijital imza (e-imza) ile imzalanarak resmi kurumlara sunulur.

Örnek senaryo: Emniyet, 10 Ocak 2025 tarihinde saat 22:15'te belirli bir IP adresinden yapılan bir işlemi soruşturuyor. Merkezi panelde IP adresi aranır, sistem otomatik olarak "Antalya Belek şubesi, 305 nolu oda, Mehmet Kaya, TC: 98765432109" bilgisini getirir. Aynı rapor, o IP'nin 22:10-22:30 arasındaki tüm bağlantı loglarını (hedef IP, port, protokol) içerir. Süreç 5 dakikadan kısa sürer; appliance tabanlı sistemde ise Belek şubesine gidip yerel sunucudan log çekmek saatler alabilir.

KVKK Uyumu: Veri Minimizasyonu ve Erişim Kontrolü

Zincir otellerde çoklu lokasyon loglama, KVKK'nın 4. ve 12. maddelerinde belirtilen veri minimizasyonu ve veri güvenliği ilkelerine özel dikkat gerektirir. Şu önlemler alınmalıdır:

• Anonimleştirme: Misafir adı ve kimlik numarası, yalnızca resmi talep olduğunda görüntülenir. Günlük raporlarda "Misafir #12345" gibi anonim kimlikler kullanılır.
• Rol tabanlı erişim: Kadıköy şubesinin resepsiyon müdürü, yalnızca kendi şubesinin loglarını görebilir; Belek şubesinin loglarına erişemez. Merkez IT yöneticisi tüm lokasyonlara erişebilir, ancak her erişim audit log olarak kaydedilir.
• Otomatik silme: 5651 kanunu 1 yıl saklama zorunluluğu getirir, ancak KVKK veriyi "amacı ortadan kalktığında" silmeyi önerir. Bulut platform, 366. günde logları otomatik siler veya anonim hale getirir (IP son oktetini maskeler, kimlik bilgilerini kaldırır).
• Şifreleme: Loglar, şubeden buluta iletilirken TLS 1.3 ile şifrelenir. Bulutta ise AES-256 ile şifrelenmiş disklerde saklanır. Yedekler, farklı bir coğrafi bölgede (örneğin, birincil İstanbul, yedek Frankfurt) tutulur.
• Veri işleme sözleşmesi: Bulut sağlayıcı (NextLog5651) ile otel zinciri arasında KVKK uyumlu bir veri işleyen sözleşmesi imzalanır. Sözleşme, bulut sağlayıcının verileri üçüncü taraflarla paylaşamayacağını, yalnızca otel talimatıyla işleyeceğini taahhüt eder.

Operasyonel İpuçları: Yeni Şube Ekleme ve Sorun Giderme

Yeni Şube Entegrasyonu (Örnek: Bodrum Şubesi Açılışı)

1. Gün -7: Merkezi platformda "IZM-BDR-04" lokasyon profili oluşturulur. Şubenin IP bloğu (örneğin 10.30.0.0/24) ve PMS tipi (Opera) kaydedilir.
2. Gün -3: Bodrum şubesine firewall (örneğin SonicWall TZ370) kurulur. IT ekibi, cihazı merkezi platform IP'sine syslog gönderecek şekilde yapılandırır.
3. Gün -1: Opera PMS kurulumu tamamlanır, API anahtarı oluşturulur ve bulut platforma girilir.
4. Gün 0 (açılış): İlk misafir check-in yapar. Sistem, PMS'ten gelen bilgiyi alır, misafirin cihazı WiFi'ye bağlanır, firewall logu buluta gönderilir. Merkezi panelde "IZM-BDR-04 aktif" durumu görünür.
5. Gün +1: IT ekibi, Bodrum şubesinin son 24 saatlik loglarını kontrol eder, herhangi bir eksik veya hata olmadığını doğrular.

Tüm süreç 1 hafta içinde tamamlanır; appliance tabanlı sistemde ise yeni sunucu tedariki, kurulum ve test 3-4 hafta alır.

Sık Karşılaşılan Sorunlar ve Çözümleri

• Sorun: Çeşme şubesinden log gelmiyor. Çözüm: Firewall'da syslog servisinin aktif olduğunu doğrulayın (show log setting komutu). Bulut platform IP'sine ping atarak ağ bağlantısını test edin. Firewall'un outbound 514 veya 6514 portunu engellemediğinden emin olun.
• Sorun: PMS entegrasyonu çalışmıyor, oda-IP eşleşmesi yok. Çözüm: PMS API anahtarının süresi dolmuş olabilir; yeni anahtar oluşturun. Elektraweb'de SQL kullanıcısının read yetkisi olduğunu kontrol edin. Webhook URL'sinin doğru girildiğinden emin olun.
• Sorun: Zaman damgaları tutarsız, bir şubede 2 saat fark var. Çözüm: NTP sunucusunu kontrol edin. Firewall'da zaman dilimini UTC+3 olarak ayarlayın. Yaz saati uygulaması (DST) devre dışı bırakılmalı, çünkü Türkiye 2016'dan beri sabit UTC+3 kullanıyor.
• Sorun: Disk doldu, eski loglar silinmiyor. Çözüm: Bulut platformda otomatik silme politikası aktif mi kontrol edin. Yerel appliance kullanıyorsanız, log rotation (logrotate) yapılandırması yapın veya eski logları arşiv diskine taşıyın.

Maliyet-Fayda Analizi: 15 Şubeli Zincir Örneği

15 şubesi olan orta ölçekli bir otel zinciri için 3 yıllık maliyet karşılaştırması: