Soru altı ay sonra geliyor. İç denetim masaya oturuyor ve tek bir şey soruyor: “Bu servis nasıl korunuyor?”
O anda verilecek en kötü cevap bir sıfat. “Güvenli” kelimesi denetçiye hiçbir şey anlatmaz; çünkü denetçi kontrolün adını, kapsamını ve sahibini arar. En iyi cevap ise servisi yayına almadan önceki yarım saatte yazılmış bir ayar listesidir.
Atlanan yarım saat de tam olarak o. Servis cevap verdiği anda iş bitmiş sayılır, kontroller sonraya kalır ve sonra gelmez.
Yayın öncesi erişim kontrolleri listesi
Aşağıdaki maddelerin her biri ayrı bir riski kapatır ve hiçbiri diğerinin yerine geçmez.
- Her entegrasyona ayrı servis kullanıcısı. Paylaşılan bir kullanıcı, “bu çağrıyı kim yaptı?” sorusunu cevapsız bırakır. Kullanıcı ve sistem ataması servis bazında tanımlanır.
- Kullanıcı kapsamını daraltın. Servise erişebilecek kullanıcıları listeleyin; “şimdilik herkes” ayarı kalıcı olma eğilimindedir.
- İzin verilen ve engellenen IP listeleri. Tüketici sabit bir çıkış IP’sinden çağırıyorsa bunu kullanın. Çağırmıyorsa, bu kontrolün devrede olmadığını yazılı hâle getirin.
- Dakika ve saat bazlı istek limitleri. Limiti tahminle değil, ilk günlerin çağrı kayıtlarına bakarak belirleyin. Dar konmuş bir limit, üretimde en zor teşhis edilen hatalardan birini üretir.
- Sabit parametreler. Çağrı anında değiştirilebilecek parametreleri bilinçli seçin; şirket kodu veya iş yılı gibi alanların sabitlenmesi genellikle doğru karardır.
- Kayıtları okuyacak bir isim. İstek ve yanıt kayıtları kimse bakmıyorsa kontrol değil, arşivdir.
- Kapanış tarihi. Geçici bir entegrasyon için açılan erişimin kapanma tarihini şimdi yazın; sistem bunu sizin yerinize hatırlatmaz.
Basic Authentication neyi, IP kuralı neyi karşılıyor
Kontrolleri aynı torbaya atmak, denetimde ilk dağılan şey. /app/api çağrısı Basic Authentication ile kimlik doğrulamasından geçer ve yalnız SERVICE tipindeki aktif kullanıcıyı kabul eder: bu, çağıranın kim olduğu sorusudur. Servis kullanıcı listesi ve SAP nesne yetkisi, o kimliğin neye erişebileceğini belirler. IP kuralı çağrının nereden geldiğini, dakika ve saat limitleri ne sıklıkla geldiğini sınırlar.
İki sınırı bilerek kurun. İstek limiti hesabı günlük kayıtlarındaki son dakika ve saat verisine dayanır; dağıtık bir geçit algoritması değildir. IP bilgisi alınamadığında ise denetleyici geriye uyumluluk için IP kontrolünü atlayabilir.
Kendi ortamınızda yapabileceğiniz bir deneme var: servisi izin listesinde bulunmayan bir adresten çağırın ve isteğin reddedildiğini kayıtlarda görün. Bir kontrolün varlığını ayarı okuyarak değil, çalıştığını görerek doğrularsınız.
Servis kullanıcısının süresi kendiliğinden dolmaz
Bu kontroller somut ve denetlenebilir. Ama bir sertifika, uyum belgesi ya da mutlak güvenlik iddiası değil. İki noktayı net tutmak gerekir: servis GUID’i kimlik doğrulama bilgisi değildir ve bir API kullanıcısının süresi kendiliğinden dolmaz. Erişimi kapatma işi, onu açan ekibin görev listesinde kalır.
Listeyi yeni bir servise değil, hâlihazırda üretimde çalışan bir servisinize uygulayın. Yedi maddeyi tek tek okuyun; cevaplayamadığınız ilk madde hangisiyse, birlikte onu kapatmakla başlayalım.