PMS API ve Otel Entegrasyonlarında API Güvenliği

API güvenliği; sadece “token koyduk” demek değildir. Amaç; kimlerin, hangi koşulda, hangi kaynağa, ne kadar ve ne sıklıkla erişebileceğini kontrol etmektir. Otel entegrasyonlarında bu kontrol; PMS/OTA sağlayıcıları, web sunucu, rezervasyon motoru, çağrı merkezi ekranları ve üçüncü servisler arasında oluşan “çoklu temas noktası” nedeniyle daha kritik hale gelir.

API güvenliği nedir, PMS/OTA entegrasyonlarında neden kritiktir?

API güvenliği; kimlik doğrulama, yetkilendirme (scope/izin), ağ kısıtları ve kötüye kullanım önleme (rate limit) ile API erişimini kontrol etmektir. PMS/OTA entegrasyonlarında kritiktir çünkü bu API’ler fiyat/müsaitlik/rezervasyon gibi gelir kritik verileri taşır; bir sızıntı veya kötüye kullanım doğrudan operasyonu ve geliri etkileyebilir.

Tehdit modeli (otel ve B2B entegrasyonlarda gerçek riskler)

• •Anahtar sızıntısı: kod deposu, CI log’u, hata log’u, ekran görüntüsü, yanlış paylaşım
• •Aşırı yetki: gereksiz scope’lar açık (least privilege yok)
• •Ağ yüzeyi geniş: IP kısıtı yok, her yerden istek atılabiliyor
• •Sınırsız trafik: rate limit yok → brute force / scraping / abuse
• •Zayıf gözlemlenebilirlik: log var ama secret’lar maskelenmemiş veya audit yok

PMS ve OTA API’leri genellikle iki tür riski bir arada taşır: (1) Gelir kritik işlevler (fiyat/müsaitlik/rezervasyon) ve (2) kişisel/operasyonel veri (misafir detayları, iptal politikaları, call center notları). Bu yüzden güvenlik; yalnızca “dış saldırı” değil, aynı zamanda “yanlış yapılandırma” riskini de kapsar.

PMS–Web–Call Center akışında risk noktaları

• •Web sitenin rezervasyon akışı PMS/Channel Manager’a dokunur
• •Çağrı merkezi ekranı aynı veriyi okur/yazar
• •Üçüncü taraf servisler (CRM, e-posta, analitik) log/olay taşır
• •Bu zincirde en zayıf halka genelde “secret saklama ve loglama” olur.

B2B CRM/ERP entegrasyonlarında ek risk

B2B’de risk, API’nin sadece “okuma” değil “yazma” (update/create) yapabilmesidir. Burada scope tasarımı ve audit logging daha kritik hale gelir.

Anti-pattern (Competitor Gap): “Anahtar sızdıysa sadece web etkilenir” yanılgısı

API anahtarlarının sızdığı vakalarda saldırganlar sadece siteyi değil PMS/rezervasyon sistemlerini de hedefleyebilir; çünkü entegrasyon anahtarı çoğu zaman “arka kapı” gibi çalışır. Bu yüzden erişim daraltma (IP/scope/rate limit) ve hızlı rotasyon (anahtar yenileme) bir “opsiyon” değil, zorunlu kontrol setidir.

Kimlik doğrulama, “kim erişiyor?” sorusunu cevaplar. PMS/OTA dünyasında bazen API key, bazen bearer token, bazen OAuth akışı görülür. Buradaki ana prensip: kimliği doğrula + erişimi daralt + anahtarı güvenli sakla.

Token/OAuth seçimi için pratik yaklaşım

• •Sağlayıcı OAuth veriyorsa: token ömrü, refresh akışı, scope yönetimi iyi bir çerçeve sağlar
• •API key kullanılıyorsa: key’i “secret” gibi yönetmek zorunludur (rotasyon, sızma önlemi)

API anahtarları nasıl saklanmalı?

API anahtarları secret manager veya en azından environment variable içinde tutulmalı; kod deposuna asla düz metin olarak yazılmamalıdır. CI/CD ve loglarda anahtar görünmemeli, uygulama hata çıktılarında maskelenmelidir. Ayrıca her ortam (dev/stage/prod) için ayrı anahtar kullanılmalı ve rotasyon planı bulunmalıdır.

IP allowlist / VPN ile erişimi daraltma

IP kısıtı, “kimlik doğru olsa bile” erişim yüzeyini daraltır. Uygulamada: API sağlayıcı allowlist destekliyorsa, sadece belirli çıkış IP’lerinden erişim; gerekirse VPN/jump host üzerinden kontrollü erişim; ortam bazlı (prod ayrı, stage ayrı) IP tanımları.

Bu bölüm, kötüye kullanım riskini kapatan “operasyonel güvenlik” kısmıdır. Scope yönetimi, “neye erişebilir?”; rate limit ise “ne kadar ve ne hızla erişebilir?” sorusunu yanıtlar. Birlikte tasarlanmadığında ya gereksiz risk alırsınız (fazla yetki) ya da sistemi gereksiz kırarsınız (aşırı limit).

IP kısıtı ve rate limiting ile entegrasyon güvenliğini nasıl artırırım?

IP kısıtı, erişimi belirli ağlardan sınırlandırarak yüzeyi küçültür. Rate limit ise anormal istek patlamalarını kısıtlayarak brute force ve abuse riskini azaltır. En iyi sonuç; kritik endpoint’lerde daha sıkı limit, normal operasyon uçlarında daha esnek limit ve tümünde audit log/alert ile birlikte gelir.

Least privilege — scope/izin tasarımı

• •“Her şeyi açma” anti-pattern’ini bitirin
• •Okuma ve yazmayı ayırın
• •Sadece kullanılan endpoint’leri açın
• •“Scope sözleşmesini” dokümante edin (hangi servis neye erişiyor?)

Throttle ve hata yönetimi

Rate limit sonrası 429 gibi yanıtlar kaçınılmazdır; önemli olan sistemin bunu doğru yönetmesidir: retry/backoff stratejisi, alarm eşikleri (429 patlaması = abuse veya yanlış limit) ve “kritik akışların” limit profili (rezervasyon ≠ raporlama).

Bu bölüm, “nasıl olmalı?”yı iki örnekle somutlaştırır: otel (PMS–web–call center) ve B2B (CRM/ERP).

Otel örneği — PMS–Web–Call Center güvenli akışı

• •Web sunucu, PMS/Channel Manager’a “sadece gerekli” uçlarla erişir
• •Call center ekranı ayrı kimlikle/ayrı scope ile çalışır
• •Secret’lar secret manager’da, loglarda maskeli
• •IP allowlist ile sadece belirli çıkışlardan erişim
• •Rate limit ile rezervasyon arama ve güncelleme uçları korunur

B2B örneği — CRM/ERP entegrasyonu

• •Okuma ve yazma anahtarları ayrılır
• •“İş ortağı profili” ile farklı rate limit ve scope uygulanır
• •Audit log: kim, ne zaman, hangi kaydı değiştirdi
• •Incident anında hızlı rotasyon + erişim iptali

Otel ve B2B için güvenli API entegrasyon akışı nasıl olmalı?

Güvenli akış; secret’ların doğru saklandığı, scope’ların minimal olduğu, IP allowlist ile erişimin daraltıldığı ve rate limit ile kötüye kullanımın sınırlandığı bir düzendir. Buna ek olarak loglar maskelenmeli, audit tutulmalı ve anahtar rotasyonu/iptal prosedürü hazır olmalıdır.

PMS/OTA entegrasyon güvenliği; secret yönetimi, scope/izin tasarımı, IP kısıtları, rate limit ve güvenli loglama/audit’in birlikte çalıştığı bir kontrol setidir. Bu set doğru kurulmadığında bir anahtar sızıntısı “yalnız web” etkisi yaratmaz; gelir ve operasyon akışlarını da riske atabilir.