PMS Kullanıcı Rolleri, Yetkiler ve Güvenlik: Kim Ne Görebilmeli?

Şifre politikası önemlidir ama tek başına yeterli değildir. Güvenliğin temel bileşenleri; erişim kontrolü (Access Control), hesap yaşam döngüsü, izleme/loglama ve denetimdir. Şifre güçlü olsa bile, “yanlış rol” verilmiş bir kullanıcı fiyatı değiştirebiliyorsa veya hassas misafir verisine erişebiliyorsa risk devam eder.

Saha gözlemi (yumuşak ifade, sheet data point ile uyumlu): Hesap paylaşımı ve belirsiz rol tanımları olan otellerde yanlış fiyat değişikliği ve yetkisiz veri görüntüleme riski artarken; rol tabanlı yetki, güçlü parola ve loglama süreçleri uygulanan yapılarda bu tür olayların ve sonradan düzeltme ihtiyacının azaldığı görülüyor.

RBAC’in mantığı basit: kullanıcıya “tek tek izin” vermek yerine, işi temsil eden rol setleri tanımlarsınız. Böylece yeni personel geldiğinde doğru rol atanır; ayrıldığında rol kapatılır; yetki kargaşası azalır. RBAC’te iki kritik prensip vardır: en az yetki (least privilege) ve görev ayrımı (segregation of duties).

RBAC kurulum adımları

• •Kritik süreçleri çıkar: check-in/out, fiyat yönetimi, fatura, iade, rapor
• •Rol kataloğu oluştur: reception, reservation, sales, revenue, accounting, IT
• •Her rol için “görür” ve “yapar” sınırını yaz
• •Hassas alanlar için ek kontrol: iki aşamalı onay (Varsayım: PMS destekliyorsa)
• •Yetki test senaryoları oluştur (yanlış rol ile deneme)
• •Log ve alarm kurallarıyla bağla (aşağıda)
• •Periyodik gözden geçirme takvimi koy (aylık/çeyreklik)

Tek bir “admin–user” ayrımı otellerde işe yaramaz; çünkü departmanların ihtiyaçları farklıdır. Örneğin resepsiyon fiyat planlarını görmeli ama değiştirmemeli; revenue fiyat yönetir ama misafir kimlik bilgilerine sınırsız erişmemelidir (KVKK). Muhasebe folyo ve finans raporlarına erişir ama günlük operasyon ekranlarını gereksiz görmemelidir.

Aşağıdaki matris, pratik bir başlangıç noktasıdır (otelinize göre uyarlanır).

Loglama olmadan güvenlik “iddia”dır. PMS’te hangi işlemlerin loglanacağı, nerede saklanacağı ve kim tarafından denetleneceği net olmalıdır. İyi bir yaklaşım; kritik işlemler için “alarm eşiği” koymak ve düzenli denetim rutini oluşturmaktır.

Kritik log alanları

• •Fiyat planı / rate değişikliği
• •İade/iptal ve tarih değişikliği işlemleri
• •Misafir kartı görüntüleme/export (Varsayım: sistem destekliyorsa)
• •Kullanıcı açma/kapatma, rol değişikliği
• •Yetkisiz deneme / başarısız login
• •Uzaktan erişim / VPN oturumları
• •Night audit kapanış adımları (audit trail)

PMS, misafir verisi açısından KVKK kapsamındadır: kimlik bilgileri, iletişim verisi, tercih/notlar, işlem geçmişi gibi alanlar hassas olabilir. Burada hedef iki şeydir: gereksiz erişimi azaltmak ve erişimi izlenebilir kılmak. “Herkes görsün kolay olsun” yaklaşımı kısa vadede operasyonu kolaylaştırsa da uzun vadede KVKK ve itibar riskini büyütür.

Kısa teknik notlar

• •Misafir kartında “zorunlu alanlar” dışında aşırı veri toplamayın (Varsayım: süreç düzeni)
• •Hassas alanları rol bazlı maskeleyin/limit koyun
• •Veri export/rapor indirme yetkisini kısıtlayın ve loglayın
• •Hesap kapatma/ayrılan personel prosedürünü aynı gün uygulayın

• •KVKK uyum hizmeti: /tr/yazilim/kvkk-uyum-hizmeti
• •KVKK & veri güvenliği raporlama: /tr/raporlama/kvkk-veri-guvenligi
• •Sunucu & güvenlik bağlamı: /tr/yazilim/sunucu-guvenlik

1. Rol kataloğu çıkarın: departman bazlı roller (resepsiyon, rezervasyon, gelir, muhasebe, IT)
2. En az yetki ilkesini uygulayın: fiyat/rapor/misafir verisini sınırlayın
3. Görev ayrımı kurun: fiyat değişikliği ile iade/iptal gibi işlemleri aynı rolde toplamayın
4. Kullanıcı yaşam döngüsü tanımlayın: açılış–değişiklik–kapatma prosedürü
5. Loglama ve denetimi kurun: kritik işlemler için audit trail + aylık inceleme
6. KVKK perspektifi ekleyin: export izinleri, maskeleme, erişim kayıtları

Önce departman rollerini çıkarın ve RBAC ile rol setleri tanımlayın. Fiyat, rapor ve misafir kartı gibi hassas alanları yalnız ilgili rollere açın; export/indir yetkisini kısıtlayıp loglayın. Hesap paylaşımını bitirin ve ayrılan personelin hesabını aynı gün kapatın. Son olarak kritik işlemler için log + aylık denetim rutini kurun.

Dokümantasyonlar genelde “yetki ekranı nerede?”yi gösterir; ama otellerin ihtiyacı “hangi rol ne yapmalı?” tasarımıdır. Bu yüzden üç çıktıyı birlikte üretin:

• •Rol & yetki matrisi (ekran/işlem bazlı)
• •Kullanıcı yaşam döngüsü SOP’u (açılış–değişiklik–kapatma)
• •Denetim paketi (kritik log raporu + aylık inceleme)

Antalya, Belek ve Bodrum gibi yüksek hacimli otellerde kullanıcı sayısı arttıkça, yanlış yetki verilmesi “fiyat değişikliği” ve hassas misafir verisi riski doğurabilir. Vardiya değişimleri ve sezon personeli nedeniyle “hesap paylaşımı” eğilimi artarsa, izlenebilirlik kaybolur. Bu yüzden sezon öncesi RBAC gözden geçirme ve kullanıcı hijyeni (kapatma/yenileme) sprint’i yapmak faydalıdır.

PMS güvenliği yalnızca güçlü şifre veya admin hesabını korumakla kurulmaz. Asıl güvenlik; departman bazlı rol tasarımı, en az yetki ilkesi, görev ayrımı, kullanıcı yaşam döngüsü ve düzenli log denetimiyle sürdürülebilir hale gelir.

Fiyat yönetimi, raporlar ve misafir verisi gibi hassas alanlar ayrı katmanlarda yönetildiğinde; hem operasyon hataları azalır hem de KVKK ve bilgi güvenliği açısından daha kontrollü bir yapı oluşur. Özellikle çok kullanıcılı otellerde sezon öncesi rol/yetki temizliği ve hesap hijyeni sprint’i, riskleri büyümeden azaltır.