1. PMS’de Güvenlik ve KVKK Neden Bu Kadar Kritik?
PMS; rezervasyon, misafir profili ve finansal hareketlere yakın duran bir sistemdir. Entegrasyonlarla birlikte bu veri, farklı uygulamalara (web, call center, BI, OTA araçları) yayılır. Yayılım, değer üretir; ama kontrolsüz olursa risk üretir.
PMS’de Saklanan Veriler ve Riskler
Hassas veri örnekleri:
- •Misafir kimlik ve iletişim bilgileri (ad, telefon, e-posta, kimlik/pasaport)
- •Rezervasyon detayları (tarih, oda tipi, fiyat, notlar)
- •Ödeme/garanti/fatura bilgileri (kart verisi doğrudan tutulmamalı—Varsayım: token/işlem referansı)
- •Özel istekler/notlar (yanlış yazılırsa “hassas bilgi” barındırabilir)
Risk örnekleri:
- •gereğinden geniş erişim (herkes her şeyi görür)
- •API anahtarının sızması
- •logların eksik olması (kim yaptı bilinmez)
- •retention yok → gereksiz veri birikir
- •BI/dashboard’da “maskesiz” veri
Mini Check
- • PMS’te hangi veri “hassas” tanımlandı mı?
- • Entegrasyonların veri kapsamı (minimizasyon) belirlendi mi?
- • Loglama “kim/ne zaman/ne yaptı” seviyesinde mi?
- • Retention/silme politikası var mı?
- • Dashboard’larda maskeleme uygulanıyor mu?
Ne yapmalıyım?
- • Hassas veri envanteri çıkarın (PMS + entegrasyonlar).
- • Veri minimizasyonu yapın: ihtiyaç olmayan alanı taşımayın.
- • Log ve retention’ı tasarıma gömün.
- • Maskelenmiş raporlama standardı belirleyin.
2. Rol Bazlı Erişim (Role-Based Access) Nasıl Tasarlanmalı?
Rol bazlı erişim (RBAC), “kim neyi görür ve neyi yapar?” sorusunu sistemleştirir. Otellerde en sık hata, operasyon hızını düşünerek “herkese admin” vermektir. RBAC’ın hedefi operasyonu yavaşlatmak değil; hatayı ve suistimal riskini azaltmaktır.
Rol tasarım mantığı: minimum yetki + ayrıştırma
- •Minimum yetki (least privilege): rolün işi için gerekli en az erişim
- •Ayrıştırma (segregation): kritik işlemler tek kişide toplanmaz
- •Onay (approval): kritik değişikliklerde supervisor onayı (Varsayım: mümkünse)
Örnek roller ve tipik yetki çerçevesi
- •Ön Büro (Front Office): rezervasyon görüntüle/oluştur, oda atama; finansal detay sınırlı
- •Sales/Revenue: fiyat planlarını yönetme; misafir kişisel detayları sınırlı
- •Muhasebe: fatura/ödeme/iadeler; misafir profili minimum
- •Call Center: teklif ve rezervasyon; hassas kimlik/finans verisi maskeli
- •Yönetim: KPI rapor; kişisel veri maskeli/anonim
| Rol | Görüntüleme | Düzenleme | Dışa Aktarma | Finans | Not |
|---|---|---|---|---|---|
| Ön Büro | rezervasyon/oda | oda atama | sınırlı | sınırlı | günlük operasyon |
| Call Center | müsaitlik/fiyat | rezervasyon | sınırlı | yok/maskeli | satış akışı |
| Sales/Revenue | performans/fiyat | rate plan | rapor | sınırlı | onaylı değişim |
| Muhasebe | fatura/işlem | iade/kapama | kontrollü | yüksek | log zorunlu |
| Yönetim | KPI panel | yok | rapor | yok | maskeli veri |
Varsayım: PMS’inize göre yetki isimleri değişebilir; prensip sabit.
Mini Check
- • “Admin sayısı” minimumda mı?
- • Kritik işlemler (iade, iptal, export) loglanıyor mu?
- • Call center ekranda maskeli veri görüyor mu?
- • Rol değişikliği/işten ayrılma süreçleri var mı?
- • Yetki denetimi periyodik yapılıyor mu?
Ne yapmalıyım?
- • Rol matrisi çıkarın ve onaylatın (operasyon + IT).
- • Kritik işlemler için onay + log zorunlu kılın.
- • Maskeleme standardı tanımlayın (özellikle call center/raporlar).
- • Yetki denetimini 90/180 günlük rutin yapın.
3. API ve Entegrasyonlarda Güvenlik Katmanları
Entegrasyon güvenliği, “API çalışıyor mu?”dan çok “API kontrollü mü?” sorusudur. En iyi pratik, birden fazla katmanla korumaktır: anahtar yönetimi + ağ kısıtları + log + hız limiti + veri minimizasyonu.
API anahtarları ve kimlik doğrulama
- •API anahtarları gizli tutulur, mümkünse sık rotasyon (Varsayım: 90 gün)
- •Anahtarlar ortam bazlı ayrılır (test/prod)
- •Sızma şüphesinde iptal/yenileme prosedürü hazırdır
IP kısıtlama, rate limit ve kapsam sınırlama
- •IP allowlist: sadece bilinen sunucular erişsin
- •Rate limit: brute force ve anomaliyi azaltır
- •Scope: her entegrasyon sadece gereken endpoint’lere erişsin
Loglama ve izleme
- •API çağrısı: kim, hangi endpoint, ne zaman, sonuç kodu
- •Başarısız giriş denemeleri ve anomali alarmı
- •Loglar değiştirilemez formatta saklanır (Varsayım: mümkünse)
Mini Check
- • API anahtarları ortam bazlı ayrıldı mı?
- • IP allowlist aktif mi?
- • Rate limit ve anomali alarmı var mı?
- • Scope/endpoint kısıtları tanımlı mı?
- • API logları dashboard’a akıyor mu?
Ne yapmalıyım?
- • API anahtar yönetimi SOP’u yazın (rotasyon, iptal).
- • IP allowlist + scope kısıtı kurun.
- • Rate limit ve anomali alarmları ekleyin.
- • Logları merkezi bir yerde toplayın ve periyodik kontrol edin.
4. KVKK ve Veri Saklama Politikaları
KVKK perspektifinde temel yaklaşım: gereksiz veri tutma, gereksiz süre saklama, gereksiz kopya üretme. Teknik tarafta bu “veri yaşam döngüsü” tasarımıyla yönetilir.
Veri yaşam döngüsü: toplama → işleme → saklama → silme/anonim
- •Toplama: sadece gerekli alanlar
- •İşleme: amaçla sınırlı kullanım
- •Saklama: süre tanımı (retention)
- •Silme/anonim: süreç ve kanıt (log)
Maskeleme ve anonimleştirme
- •Call center ve raporlama ekranında maskeleme (örn. telefonun son 4 hanesi)
- •BI tarafında anonimleştirme/aggregate raporlar
- •Dışa aktarmalarda (export) kontrol + onay
Hukuki not (kapsam sınırlaması)
Bu içerik, hukuki tavsiye vermez; teknik/organizasyonel önlemleri çerçeveler. KVKK kapsamı, saklama süreleri ve kurumunuza özel yorumlar için hukuk danışmanına başvurulmalıdır.
Mini Check
- • Retention süreleri yazılı mı?
- • Silme/anonim süreçleri loglanıyor mu?
- • Dashboard’lar maskeli mi?
- • Export işlemleri kontrollü mü?
- • KVKK talepleri için iş akışı var mı?
Ne yapmalıyım?
- • Veri yaşam döngüsü dokümanını çıkarın.
- • Maskeleme standardını belirleyin (ekran/rapor/export).
- • Silme/anonim süreçlerini log ve onayla yürütün.
- • KVKK talep (erişim/silme) iş akışını operasyonla birlikte kurun.
5. Güvenlik İhlallerini Tespit Etmek ve Raporlamak
Güvenlik “duvar” değil “erken uyarı” sistemidir. İhlal her zaman “büyük hack” değildir; yetkisiz export, şüpheli login, sıra dışı API çağrısı gibi küçük sinyallerle başlar.
Tespit sinyalleri: anomali kartları
- •başarısız login artışı
- •olağandışı saatlerde admin işlemi
- •kısa sürede toplu export
- •API rate limit patlaması
- •beklenmeyen IP’den erişim
Raporlama ve olay yönetimi
- •olay sınıflandırması (kritik/orta/düşük)
- •ilk yanıt adımları (anahtar iptali, erişim kesme, log inceleme)
- •kök neden analizi ve düzeltici aksiyon
Key Statistics / Data Point (sheet – senaryo): Güvenlik ve rol yapısı güçlü olan otellerde, yetki suistimali ve veri sızıntısı riskinin azalabildiği; KVKK denetimlerinde teknik tarafta daha az sorun yaşanabildiği senaryo bazlı olarak anlatılabilir. Buradaki farkı yaratan unsur “RBAC + log + retention” üçlüsünün birlikte işletilmesidir.
Mini Check
- • Anomali alarmları var mı?
- • Admin işlemleri izleniyor mu?
- • Export işlemleri onaylı mı?
- • API key rotasyonu yapılıyor mu?
- • Olay yönetimi playbook’u var mı?
Ne yapmalıyım?
- • Anomali alarmlarını kurun ve sorumlu atayın.
- • Admin ve export işlemlerini sıkılaştırın.
- • API key rotasyon SOP’u uygulayın.
- • Olay yönetimi playbook’u oluşturun ve tatbikat yapın.
6. PMS Rol & Güvenlik Kontrol Listesini İndir — Otel / PMS Security & KVKK
PMS Rol & Güvenlik Kontrol Listesini İndir — Otel / PMS Security & KVKK (v1.0)
Bu kontrol listesi, PMS entegrasyonlarında rol bazlı erişimi (RBAC), API güvenliğini, loglama ve KVKK veri yaşam döngüsünü tek çerçevede standardize eder. Amaç; gereğinden geniş erişim, anahtar sızıntısı, log eksikliği ve retention belirsizliği gibi riskleri azaltmak ve denetimlerde teknik tarafta hazırlıklı olmaktır.
Kim Kullanır?
IT/BI + ön büro + muhasebe + call center + yönetim birlikte.
Nasıl Kullanılır?
- Rol matrisi çıkarıp minimum yetki prensibiyle onaylatın.
- API güvenlik katmanlarını (key/IP/scope/log/rate limit) uygulayın.
- Retention–silme–anonimleştirme süreçlerini dokümante edip periyodik denetim rutini kurun.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Hassas veri envanteri çıkarıldı (misafir/rezervasyon/ödeme)
- ▢ ✅ Veri minimizasyonu yapıldı (entegrasyonlarda gereksiz alan yok)
- ▢ ✅ RBAC rol matrisi hazır ve onaylı
- ▢ ✅ Admin sayısı minimumda; kritik işlemler ayrıştırıldı
- ▢ ✅ Maskeleme standardı tanımlı (call center/rapor/export)
- ▢ ✅ API key’ler ortam bazlı ayrıldı (test/prod)
- ▢ ✅ IP allowlist aktif
- ▢ ✅ Scope/endpoint kısıtları tanımlı
- ▢ ✅ Rate limit + anomali alarmları var
- ▢ ✅ Retention & silme/anonim süreçleri loglanıyor
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7. Sonuç: PMS güvenliği ve KVKK uyumu entegrasyon sonrası değil, entegrasyon tasarımının içindedir
PMS entegrasyonlarında risk, akışın çalışmasıyla bitmez; tam tersine veri dolaşımı arttıkça başlar. Bu nedenle RBAC, API katmanları, loglama ve retention yaklaşımı sistemin sonradan eklenen güvenlik yamaları değil, tasarımın temel parçaları olmalıdır.
Doğru kurguda otel; misafir verisini daha kontrollü yönetir, operasyonu yavaşlatmadan erişimi sınırlar, ihlal sinyallerini daha erken fark eder ve KVKK denetimlerinde teknik tarafta daha hazırlıklı hale gelir.
Bir Sonraki Adım
Entegrasyonlarda misafir verisini korumak isteyen oteller için.
Sık Sorulan Sorular
PMS’te hangi veriler en hassastır, nasıl korunmalıdır?▾
Rol bazlı erişim ve yetki yapısı nasıl kurulmalı?▾
API ve entegrasyonlarda PMS güvenliği nasıl sağlanır?▾
KVKK’ya göre PMS veri saklama ve silme politikası nasıl olmalı?▾
Güvenlik ihlallerini nasıl tespit edip raporlarım?▾
İlgili İçerikler