Vaka çalışması · Sigorta · Kurum entegrasyonları
Bir sigorta şirketinin düzenleyici kurumlara giden çağrıları için tek ve kontrollü bir çıkış
Bir sigorta şirketinin uygulamaları, düzenleyici kurum servislerini her biri kendi başına, doğrudan çağırıyordu. DMZ'de kurulan tek bir gateway bu trafiği devraldı; kimlik bilgileri, token'lar, cache ve kurumun rate limit'leri her uygulamada ayrı ayrı değil, bir kez gateway'de ele alındı.
Sonuçlar
%100
log ve dashboard'larda görünen kurum trafiği
Cache
tekrarlanan istekler, kuruma yeniden gitmeden yanıtlandı
Kasada
kimlik bilgileri, uygulamalarda tutulmak yerine çalışma anında okundu
Bağlam
Sigorta şirketleri, poliçe ve hasar gibi temel süreçlerinde bir düzenleyici kurumun servislerine sıkı sıkıya bağlıdır: sorgulama, poliçe doğrulama ve benzeri işlemler birçok uygulama tarafından, çoğu zaman paralel olarak çağrılır. Bu çağrılar farklı uygulamalardan doğrudan internet üzerinden yapıldığında güvenliği, izlenebilirliği ve maliyeti kontrol etmek zorlaşır.
Bu projede durum tam olarak buydu. Sigorta şirketinin birçok uygulaması kurum servislerine doğrudan erişiyordu; dışa giden trafik için merkezi bir katman olmadığından bu trafik izlenemiyor ve kontrol edilemiyordu. Kurumun şirket bazında uyguladığı rate limit’ler ve her uygulamanın kuruma erişmek için ihtiyaç duyduğu kimlik bilgileri, merkezi ve daha güvenli bir yaklaşımı zorunlu kılıyordu.
Kısıtlar
- Kurum servislerine giden outbound trafiğin merkezi olarak izlenememesi
- Kurumun token alma için uyguladığı rate limit’lere yaklaşıldığının önceden görülememesi
- Kuruma erişimde kullanılan kullanıcı adı ve şifrelerin uygulama entegrasyonlarında statik olarak durması
- Aynı parametrelerle tekrarlanan çağrıların hem performansa hem maliyete yük getirmesi
- Kurum trafiğini loglayıp analiz etmek için merkezi bir dashboard olmaması
Yaklaşımımız
- DMZ’de bu işe ayrılmış bir gateway. DMZ’de, sanal makine üzerinde yalnızca bu trafiğe hizmet eden bir API gateway kuruldu. Kurum servislerine internet üzerinden gateway erişti ve yanıtları iç sistemlere iletti.
- Her uygulama gateway üzerinden. Uygulamalar, kurum servislerini doğrudan çağırmak yerine gateway’de yayımlanan kurum endpoint’lerine yönlendirildi.
- Kimlik bilgileri uygulamaların dışında. Gateway, kuruma ait kimlik bilgilerini çalışma anında bir ayrıcalıklı erişim yönetimi (PAM) kasasından okudu; kullanıcı adları ve şifreler uygulama kodundan tamamen ayrıldı. Bu bilgilerin rotasyonu hiçbir uygulamaya dokunmadan gerçekleştirilebiliyor.
- Token’lar ömürleri boyunca cache’te. Gateway, kurumun token servisinden aldığı token’ı cache’ledi ve token geçerli olduğu sürece yeni token istemedi.
- Tekrarlanan istekler cache’ten. Aynı parametrelerle gelen istekler response cache’ten yanıtlandı; mükerrer çağrılar kuruma gitmedi. Özellikle üçüncü taraf kanallar üzerinden yapılan sorgulara dönen ücretli yanıtlar da cache’lendi; böylece mükerrer sorguların ve ek maliyetin önüne geçildi.
- Kurumun limitleri gateway’de. Kurumun uyguladığı rate limit değerleri gateway üzerinde tanımlandı ve limitlere yaklaşılmadan alarm üretildi. Trafik uygulama bazında önceliklendirilebildiği için kurum kotasının tükenmesi kritik iş süreçlerini aksatmıyor.
- Tüm trafik için log ve dashboard. Kuruma giden tüm trafik için ayrıntılı loglama ve dashboard’lar kuruldu.
Sonuç
Kurum entegrasyonları, kontrolsüz bir outbound trafik yapısından merkezi, güvenli ve izlenebilir tek bir çıkışa taşındı. Rate limit’ler aşılmadan önce yönetildi, kimlik bilgileri uygulamalarda değil kasada tutuldu ve azalan mükerrer çağrılar hem performansı hem maliyeti iyileştirdi. Tekrarlanan sorguların cache’ten karşılanması, kurum tarafındaki rate limit tüketimini azalttığı gibi yanıt sürelerini de kısalttı. Operasyon ekipleri kurum trafiğini uçtan uca izleyebilir hale geldi.
Bu yapı bu kuruma özgü değil. Merkezi bir outbound gateway, kasada tutulan kimlik bilgileri, rate limiting ve response cache; bankalararası entegrasyonlar, ödeme altyapıları ya da diğer düzenleyici kurum servisleri gibi dışa giden her türlü API trafiğine uygulanabilir.