Oda numarası kimlik değil, geçici bir konum bilgisidir
Otelde oda numarası her konaklama döneminde başka kişiye verilebilir. Bu nedenle yalnız “305 numarada kalıyorum” ifadesini doğrulamak, misafirin kimliğini ve hangi işlemleri yapabileceğini kanıtlamaz. Misafir uygulaması oda, tesis, giriş ve çıkış tarihini, oturumun kim tarafından açıldığını ve hangi verilerin gösterilebileceğini ayrı değerlendirmelidir.
Sıradan bir restoran rezervasyonu akışıyla konaklamanın tam kimlik bilgilerini değiştiren işlem aynı güvenlik düzeyine sahip olmamalıdır. Sistem misafire ne kadar hassas veya mali etkili işlem sunuyorsa gereken kimlik doğrulama gücü de o kadar artmalıdır. Güvenlik tasarımı misafiri gereksiz alanlarla yormadan riskli işlemlere ek doğrulama koymalıdır.
Giriş yolunu ve korumalarını birbirinden ayırın
Bir tesiste misafir odadaki QR koduyla veya oda numarasıyla tarihlerini girerek giriş yapabilir. QR kodu her zaman kişiye özel güvenli kanıt demek değildir: odadaki statik bağlantının fotoğrafı paylaşılabilir. Buna karşılık imzalı ve sınırlı süreli kişisel bağlantı farklı güvenlik özelliklerine sahiptir. Uygulama ekibi hangi QR tipini kullandığını açıkça belgelemelidir.
Oda ve tarihle girişte kötü niyetli otomatik denemelere karşı hız sınırlama, riskli girişleri izleme ve gerektiğinde ek güvenlik doğrulaması uygulayın. Güvenlik kontrollerinin ayrıntılı eşiklerini kamuya açık içerikte açıklamadan, misafir kimliğinin ve yetkisinin nasıl korunduğunu anlaşılır şekilde anlatın. Hiçbir tek doğrulama yöntemi hassas işlemler için tek başına yeterli sayılmamalıdır.
- Oda + konaklama tarihi eşleşmesi hangi kaynaktan geliyor?
- QR kodu genel otel bağlantısı mı, odaya özel mi, kişiye özel imzalı mı?
- Aşırı deneme halinde gerçek misafir kilitlenmeden nasıl kurtarılıyor?
- Oturumun çıkış tarihinde nasıl sona erdiği test edildi mi?
- Hassas işlem öncesinde ek doğrulama gerektiren adımlar belirlendi mi?
Çıkış, oda değişikliği ve cihaz paylaşımı testleri yapın
En tehlikeli senaryo, önceki misafirin oturumunun yeni konuk geldiğinde açık kalmasıdır. Çıkış günü ve konaklama bittiğinde yeni işlem izinleri kaldırılmalıdır. Aynı kişi otel içinde oda değiştirirse sistem eski odaya ait yeni bir konaklama açmamalı; mümkünse aynı konaklama kimliğiyle oda ilişkisini güncellemelidir.
Paylaşılan tablet, aynı odada birden fazla yetişkin, aile üyelerinin kendi telefonları ve oda sayısı birden çok olan rezervasyonlar için ayrı erişim kararları alınmalıdır. Bir misafirin aynı odayı paylaşması, diğer yetişkinin kişisel ödeme geçmişini veya özel talebini görme hakkı doğurmaz. Ekip tasarım aşamasında bu riskleri açık senaryolarla sınamalıdır.
Kullanıcıya güvenliği anlaşılır biçimde gösterin
Yanlış oda bilgisi ve insan doğrulama başarısızlığının hata metinleri ayrılmalı, ancak saldırgana hangi oda ve tarihin doğru olduğu açıklanmamalıdır. Ödeme gibi kritik adımlarda başarısız işlem net biçimde iletilmeli; yeniden denemeye izin verilse bile çift tahsilat oluşturulmamalıdır. Oturum süresi dolduğunda misafir yaptığı işlemi kaybetmemeli, gerektiğinde yeniden girişe yönlendirilmelidir.
Kimlik ve iletişim verilerini gerekli olandan fazla göstermeyin. Loglarda tam kart bilgisi, kimlik numarası ve güvenlik tokenı yer almamalıdır. İşlem için saklanan veriyle pazarlama amacıyla toplanan izin birbirine karıştırılmamalıdır.
Stay, PMS ve ürünlerin yetki sınırını kontrol edin
Rezervem Stay misafir oturumunu ve gösterim yetkilerini yönetirken konaklama gerçeği desteklenen PMS kaynağından doğrulanmalıdır. Manager restoran rezervasyonunun, Pay tahsilatın, Hospitality ise departman talebinin yetkisini kendi alanında yeniden denetlemelidir.
Pilot öncesi en az şu olumsuz testleri çalıştırın: başka odaya giriş denemesi, çıkış sonrası eski bağlantı, tahmin edilen oda numarası, başka tesis kimliği, tekrar kullanılan ödeme isteği ve başka misafirin geçmiş kayıtlarını görme. Güvenlik ancak kötü senaryolar sınandığında somut hâle gelir.
