Bankacılık ve finans için kurum içi uygulama izleme

Wrentrix, başka denetimli kurumlarla birlikte bankalar düşünülerek tasarlandı. Bu bir tasarım hedefidir, müşteri listesi değildir. Bu sayfadaki hiçbir şey belirli bir bankayı anlatmaz.

Banka sistemini izlemek neden farklıdır?

Bir e-ticaret sepetini izlemekle bir para transferini izlemek aynı teknolojiyi kullanır. Değişen, etraftaki koşullardır.

Yol uzun ve karışıktır. Mobil bir havale uygulamadan ağ geçidine, API katmanına, sahtecilik kontrolüne, limit servisine, ana bankacılık sistemine, ödeme ağı bağlantısına ve bildirim servisine gidebilir. Bunların bir kısmı modern konteyner, bir kısmı onlarca yıllık sistemdir. Kubernetes sınırında biten izleme size "ana bankacılık çağrısı, 4 saniye" adlı bir span gösterir, ötesini göstermez.

Trafik takvimi izler. Maaş günleri, ay sonu, vergi dönemi ve gün sonu kapanışı olağan bir haftaya benzemeyen kalıplar üretir.

Değişiklik denetimlidir. Üretim değişiklikleri onaylardan, dondurma dönemlerinden ve görevler ayrılığından geçer. "Şu ajanı ekleyip her şeyi yeniden başlatın" diyen bir araç bu sürece hemen takılır.

Veri hassastır. Hesap numarası, T.C. kimlik numarası, kart verisi ve bakiye, kimse kontrol etmediyse loglara ve trace'lere girebilir.

Maaş gününde yavaşlayan havaleler: kurgu bir olay

Aşağıdaki olay kurgudur, parçaların birlikte nasıl çalıştığını göstermek için yazıldı.

Maaş gününde saat 09.20'de havale SLO'su olağanın çok üzerinde bir hızla tükenmeye başlıyor. Hızlı pencere burn-rate alarmları nöbetçi mühendisi arıyor. O gün trafik zaten yüksek olduğu için ilk soru, bunun yalnızca yük olup olmadığı.

1. Gruplama. Mobil ağ geçidi, API katmanı ve limit servisindeki alarmlar canlı bağımlılık haritası sayesinde tek problem olarak toplanıyor. Üç ekip üç ayrı konu için aranmıyor.
2. Trace. Süre limit servisinde birikiyor. Veritabanı çağrıları kısa görünüyor, ama server span uzun ve veritabanı çağrısından önce büyük bir boşluk var.
3. Metot verisi. Bekleme, veritabanı bağlantısı alan metotta. Bu metot taban çizgisinin çok dışında, sorgu çalıştırma ise normal. Sorgular sağlıklı, sadece bağlantı bulamıyorlar. Kod değiştirmeden metot düzeyi izleme bu görünümü verir.
4. Değişiklik korelasyonu. Bir hafta önceki ConfigMap düzenlemesinin havuz boyutunu küçülttüğü görülüyor. Normal yük yeni sınıra ulaşmadığı için kimse fark etmemiş. Değişikliği devreye sokan da dün geceki pod yeniden başlatması.
5. Müdahale. Daha önce incelenmiş değişikliği uygulayan onaylı bir Ansible AWX işi çalışıyor. Onaylayan kişi kanıtı görüyor, denetim kaydı kimin neyi onayladığını, AWX de işi kaydediyor.
6. Kısa burn-rate penceresi birkaç dakika sonra temizleniyor, alarm kendiliğinden kapanıyor.

İlginç olan 4. adım. Bir hafta önce yapılmış, yük ve yeniden başlatma denk gelene kadar etkisiz kalmış bir değişikliği hafızayla bulmak zordur. Zaman çizelgesi bunu mümkün kılar.

Takvim ve taban çizgileri

Haftanın saatine göre öğrenilen taban çizgileri haftalık ritmi yakalar: pazartesi sabahı pazar gecesine benzemez. Ama bankanın takvimini bilmez. Şunları hesaba katın:

• Maaş günleri belirli tarihlere düşer, dolayısıyla hafta içinde kayar. Haftanın saati dilimi bunları ancak ara sıra görür, o günlerde anomali işareti bekleyin. SLO'larınız doğru okunmaya devam eder, çünkü neyin normal olduğuna bağlı değildir.
• Ay ve çeyrek sonu toplu işleri haftalık modele olağandışı görünür. Nöbet devrinde not edin.
• Resmi tatiller, özellikle tarihi kayan dini bayramlar, olağandışı düşüşler üretir. Arife günü görülen düşük trafik anomalisi arıza değildir.
• Gün sonu kapanışı genellikle aynı haftalık dilimlere düşer, taban çizgisi bunu iyi karşılar.

Doğru tepki sisteme güvenmemek değildir. İki sinyal türünü birlikte kullanın: burn rate ile arayın, bilinen takvim günlerindeki anomali işaretlerini bağlam sayın.

Değişiklik sürecine uyum

Aşağıdakilerin her biri doğrulayabileceğiniz bir özelliktir ve değişiklik kurulunun soracağı bir soruya karşılık gelir.

Onay modu üzerinde ayrıca düşünmek gerekir. Birçok banka üretimi değiştiren her şeyde onay moduyla başlamak ister. Otomatik eylemlere ancak önceden onaylanmış standart değişiklik kategorisindeyse izin vermek makul bir sınırdır. Bunu kendi değişiklik yönetimi politikanızla hizalayın, risk veya iç denetimden birine tasarımı erkenden gösterin.

Mevzuat, genel hatlarıyla

Bu bölüm hukuki görüş değildir, ayrıntılar kuruma göre değişir. Uyum biriminize danışın. Wrentrix'in herhangi bir sertifikaya sahip olduğunu veya bir kurumu uyumlu yaptığını iddia etmiyoruz.

• BDDK. Bankaların bilgi sistemlerine ilişkin düzenlemeler, diğer konuların yanında birincil ve ikincil sistemlerin yeri, dış hizmet alımı ve denetim izlerine değinir. Müşteriyle ilgili veri tutan bir izleme sistemi bu başlıklarda soru doğurur. Birincil sistem veya dış hizmet sayılıp sayılmayacağı kurumunuzun değerlendirmesidir.
• KVKK. Kişisel veri kuralları telemetri için de geçerlidir. Veriyi bulmak ve azaltmak için KVKK ve veri yerelliği sayfasına bakın.
• PCI DSS. Kart verisi korunmalı ve gerekmedikçe saklanmamalıdır, kapsamdaki sistemlerin loglanması ve izlenmesi de ayrıca gerekir. Trace veya loglarınız kart verisi yakalarsa izleme platformu kapsama girebilir. Veriyi dışarıda tutun, platformun nasıl ele alınacağına denetçinizle karar verin.
• DORA. AB'de faaliyeti olan finans kuruluşları için BT riski, olay bildirimi ve üçüncü taraf gözetimi konularında beklentiler koyar.

Ağ bölgelerine oturtmak

Bankalarda genellikle sıkı bir ayrım vardır: DMZ, uygulama katmanı, veritabanı katmanı, ana sistemler. Temel tasarım sorusu, neyin nereyi geçtiğidir.

• Bölge başına collector kullanın. Böylece her bölgeler arası akış, tek uç noktaya tek portta belgelenmiş tek bir yol olur, güvenlik duvarı ekibi daha az akış inceler.
• Ajanlar ve sunucular kurulumunuza içeriden raporlar, internete değil. Ağdan 0 bayt telemetri çıkar, dış yolu olmayan bölgeler için kapalı ağ çalışması desteklenir.
• İnternet bankacılığı için gerçek kullanıcı izleme müşteri tarayıcılarından bir toplayıcıya gelen yol gerektirir. Bu yeni ve internete açık bir uç noktadır, güvenlik ekibiniz toplayıcının ne yakaladığıyla birlikte inceleyecektir.
• Problar önemli yolları kontrol eder. Uygulama bölgesinden ödeme bağlantısına giden bir TCP probu, kaldırılan bir güvenlik duvarı kuralını yakalar. TLS bitiş uyarıları da karşılıklı TLS kullanılan kurumlar arası hatlardaki sertifikaları yakalar. Bu sertifikalar önlenebilir olayların sık bir kaynağıdır.

Görünürlüğün bittiği yer

Bu sınırları değerlendirmenin başında konuşun.

• Ana bilgisayarlar ve eski ana bankacılık sistemleri. Bir platform OpenTelemetry SDK çalıştıramıyorsa çağrıyı yine çağıran taraftan görürsünüz: süre, hata, etkilenen istekler. Sistemin içi için kendi araçlarına dayanırsınız. Platformlarınızı bize sorun.
• Diğer işletim sistemleri. Sunucu izlemesi için tarif edilen Linux'tur. Başka sistemleri sorun.
• Kapalı kaynaklı ara katmanlar. Trace bağlam geçebiliyorsa devam eder, geçemiyorsa orada biter.
• Ödeme ağları ve iş ortakları. Çağrının sizin tarafınızı görürsünüz, o kadar. Gecikmenin sizde olmadığını göstermek için yine de işe yarar.
• Ölçek. Kıyas rakamı yayınlamıyoruz. Kendi trafik şeklinizle ve yoğun günleri dahil ederek test edin.

Yapay zekâ konusunda bir not: yerel model çıkarımı kendi donanımınızda tutar, finansal telemetriyi dış servise göndermez. Model risk biriminiz yine de kullanımı incelemek isteyebilir, özellikle otomatik eylemlere bağlıysa. Yapay zekâ tümüyle kapatılabilir. Kendi senaryonuzu konuşmak için demo talebi bırakabilirsiniz, ekranlara önce canlı demodan da bakabilirsiniz.

Sık sorulan sorular

APM ana bankacılık sisteminin içini izleyebilir mi?

Bağlamın geçtiği ve enstrümantasyonun bulunduğu yere kadar izleyebilir. Ana sistem enstrümante edilemiyorsa çağıran servisten çağrı süresini ve hataları yine görürsünüz. Daha fazlasının mümkün olup olmadığı platforma bağlıdır, kendi sisteminizi bize sorun.

Wrentrix banka verisini buluta gönderir mi?

Hayır. Kendi altyapınızda çalışır, ağdan 0 bayt telemetri çıkar ve yapay zekâ yerel modelle çalışır. Lisans çağrısı olmadan tamamen kapalı ağda da çalışır.

Wrentrix BDDK'ya uygun mudur?

Bu sayfada böyle bir iddiamız yok. BDDK düzenlemeleri, DORA ve PCI DSS kurumunuza ve süreçlerinize uygulanır, bir araç yaklaşımınızı destekleyebilir ama sizi uyumlu yapamaz. Güvenlik soru formları için info@wrentrix.com adresine yazın.

Ajan kurulumu servisleri yeniden başlatan bir üretim değişikliği midir?

Kurulum, sürecinizin incelemesi gereken bir değişikliktir, ama Wrentrix iş yüklerini yeniden başlatmaz. Enstrümantasyon, pod'lar normal sürümlerinizle yeniden başladıkça gelir. Ajan erişilemezse admission webhook fail-open çalışır ve pod'lar normal başlar.

Otomatik müdahale görevler ayrılığını karşılar mı?

Bunu destekleyecek biçimde kurulabilir. Onay modunda eylemi bir kişi onaylar, denetim kaydı ve AWX iş geçmişi ne olduğunu kaydeder. Tasarımın politikanızı karşılayıp karşılamadığına risk ve denetim birimleriniz karar verir.