API çağrılarında kimlik ve müşteri veri izolasyonu

Denetçinin sorusu genellikle teknik değildir: “Bu veriyi 14 Mart’ta dışarı çıkaran çağrıyı kim yaptı?” Cevap bir isim olmalı. Çoğu kurumda ise cevap bir sistemin adı oluyor — “entegrasyon kullanıcısı”.

O noktada soru kapanmaz, büyür. Aynı kullanıcıyı kaç entegrasyon paylaşıyor, hangisi o gün çalıştı, hangi IP’den geldi? Kimlikler ayrılmadığı için tek bir çağrının izi sürülemiyor.

Dört kimlik, dört ayrı kontrol

Bir kurulumda aynı anda dört kimlik dolaşıyor:

  • Ekranı kullanan kişi.
  • Arka planda çalışan görev.
  • API’yi çağıran dış sistem.
  • Paylaşım bağlantısıyla gelen ziyaretçi.

Her biri farklı katmanda denetlendiği için “erişim güvenli mi?” sorusu bu dördü ayrılmadan cevaplanamaz.

Ekran tarafında oturum yönetimi Spring Security üzerinde kurulur, parolalar BCrypt ile saklanır ve ön yüz route’ları yetki nesnesi kontrol eden bir katmanla sınırlandırılır; modül erişimi ayrıca müşteri ve modül etkinliğiyle eşlenir. Bir ekranı açabilmek ile o ekranda SAP verisini görebilmek iki ayrı karar: birincisi uygulama rolü, ikincisi SAP tarafındaki yetki.

Servis tarafında giden API çağrıları Basic Authentication ister; yalnız servis tipi aktif kullanıcı kabul edilir ve müşteri/sistem ataması doğrulanır. Üzerine servis bazlı kullanıcı listesi, izin verilen ve engellenen IP kuralları, dakika ve saat bazlı istek limitleri ve istek/yanıt logları eklenir.

Bir yanlış anlamayı burada kapatmak gerekiyor: servis adresindeki kimlik değeri bir parola değildir, yalnızca servis ve sistem bağlamını çözer. Erişimi kontrol eden şey kimlik doğrulama, kullanıcı listesi ve IP kuralıdır.

Müşteri ve sistem bağlamının çizdiği sınır

Veri erişimi müşteri ve sistem bilgisine göre filtrelenir. Geliştirme, kalite ve canlı sistem ilişkileri tanımlanabildiği için birden fazla bağlam aynı kurulumda yönetilir; kalite sisteminde yapılan bir test canlı bağlamdaki kayıtlarla karışmaz.

Bunu mutlak bir izolasyon iddiası olarak sunmuyoruz. Söylediğimiz dar ve kontrol edilebilir: erişim müşteri ve sistem bağlamıyla filtrelenir, ayrımın doğru kurulması ise kurulum yapılandırmasına bağlıdır.

Dördüncü kimlik en çok şaşırtan taraf. BI paylaşım bağlantısı oturum açmadan, ayrı bir kimlikle çalışır ve paylaşan kullanıcının satır yetkilerini devralmaz. Güvenlik açısından iyi haber; operasyon açısından dikkat gerektiren bir davranış, çünkü kapsam boş gelebilir. Bağlantıyı yayımlamadan önce oturumsuz bir tarayıcıda açmak gerekiyor.

Ağ tarafında kapatılması gerekenler

Dürüst olmak gerekirse listenin bir de eksik tarafı var. Bazı iç ve servis uçları uygulama katmanında açıktır ve ağ ya da güvenlik duvarı kuralıyla sınırlandırılmaları gerekir. Bunu devreye alma kontrol listesine yazmayan bir kurulum, var olmayan bir kontrole güvenmiş olur.

Bu dört katman bir sertifika ya da uyum beyanı değil. Somut olan daha dar: hangi kimliğin hangi kontrolle sınırlandığı yazılabilir — denetimde işe yarayan da bu yazılabilirlik oluyor.

Şu soruyla başlamanızı öneriyoruz: bugün kaç entegrasyon aynı servis kullanıcısını paylaşıyor? Listeyi çıkarın; her biri için ayrı kullanıcı, IP kuralı ve istek limiti tanımını birlikte kuralım.