# Finansal Hizmetlere DDoS Saldırıları: Düzenleyici Gereksinimler ve Savunma > Bankalar ve fintech'ler devlet aktörlerinden, siber suç gruplarından ve aktivistlerden DDoS saldırılarıyla karşılaşır. AB ve ABD'deki düzenleyiciler artık belirli dayanıklılık gereksinimleri dayatıyor. - Category: Uyumluluk - Author: Akarguard Ekibi, Güvenlik Ekibi - Published: Sep 25, 2024 - Canonical: https://akarguard.net/tr/blog/finans-sektoru-ddos --- Finansal kurumlar DDoS tehdidinin en keskin ucundadır: neredeyse diğer her sektörden daha sık, daha çeşitli düşmanlar tarafından ve daha fazla düzenleyici denetim altında saldırıya uğrarlar. Bir banka ya da fintech; jeopolitik mesaj için devlet destekli bir kampanyayla, bir seli dolandırıcılığa perde olarak kullanan bir suç grubuyla ve bir kesintiyi siyasi bir ana göre zamanlayan bir aktivist grupla karşılaşabilir — bazen aynı hafta içinde. Ve çoğu sektörün aksine, site düştüğünde düzenleyici nedenini bilmek ister. ## Finansa Kim, Neden Saldırır? - Devlet destekli aktörler, jeopolitik gerilim sırasında DDoS'u görünür, inkâr edilebilir bir aksatma olarak kullanır. - Siber suç grupları bir seli sis perdesi olarak başlatır — müdahaleciler kesintiyle boğuşurken, altta dolandırıcı işlemler ya da hesap ele geçirmeler işler. - Hacktivistler, kamu ilgisinin en yüksek olduğu anda tartışmalı politika ya da olaylara bağlı bankaları hedef alır. - Şantajcılar (fidye DDoS), her dakika kesintinin somut parasal maliyeti olan ödeme ya da işlem altyapısını tehdit eder. ## Düzenleyici Ağırlık Finansta DDoS'a karşı dayanıklılık, benimseyebileceğiniz bir en iyi uygulama değildir — giderek bağlayıcı kurallara yazılmaktadır. - DORA (AB Dijital Operasyonel Dayanıklılık Yasası): DDoS senaryoları dahil belgelenmiş BİT risk yönetimi, Ocak 2025'ten itibaren bağlayıcı uygulamayla. - FFIEC kılavuzu (ABD): finansal kurumlar DDoS'a karşı dayanıklılığı test etmeli ve olay-müdahale kılavuzları tutmalıdır. - PSD2 / açık bankacılık: üçüncü taraf API uçları, savunulması gereken saldırı yüzeyini çarpıcı biçimde genişletir. - Basel III operasyonel risk: DDoS kaynaklı kesinti, operasyonel-risk sermaye hesaplamalarına dahil olur. ## DORA Gerçekte Ne Talep Ediyor? DORA, finansal kuruluşların BİT tehditlerine dayanmasını, yanıt vermesini ve bunlardan kurtulmasını — ve kritik olarak — bunu kanıtlamasını gerektirir. Koruma belgelenmiş, test edilmiş ve denetlenebilir olmalıdır ve bir üçüncü taraf sağladığında, o sağlayıcı kendi yükümlülükleri olan hesap verebilir bir BİT hizmet sağlayıcısı hâline gelir. Pratikte bu, yalnızca çalışan bir korumaya değil bir kâğıt izine de ihtiyacınız olduğu anlamına gelir: neyin devrede olduğu, nasıl test edildiği ve her olayda ne olduğu. > **Denetim izi gereksinimin yarısıdır** — Düzenlemeye tabi bir firma için bir saldırıyı azaltmak işin yalnızca yarısıdır. Bir kayıt üretemezseniz — neyin, ne zaman saldırıya uğradığı, nasıl ele alındığı — savunma ne kadar iyi çalışmış olursa olsun gereksinimi karşılamamışsınızdır. Raporlama sonradan akla gelen bir şey değil, birinci sınıf bir özelliktir. ## Akarguard Düzenlemeye Tabi Bir Yığına Nasıl Uyar? Akarguard bir Layer 7 ters vekilidir: uygulama katmanı saldırılarını filtreler, WAF'ınızı ve hız limitlerinizi uygular ve sunucunuzu gizler ki doğrudan vurulamasın. Koruma, birinin çevirmesi gereken bir düğme yerine bir DNS değişikliğiyle her zaman açıktır, bir saldırı tespit edilir edilmez otomatik azaltma yükselir ve her olay indirilebilir bir PDF rapor üretir — zaman çizelgesi, tepe hızları, saldırı türü, kaynak ASN dağılımı — ki bu DORA ve FFIEC'in beklediği belgelemeyi besler. GDPR tarafı için bir DPA mevcuttur ve veri AB'de kalır. Dürüst bir sınır: Akarguard uygulama katmanını savunur ve sunucuyu gizler; ağdaki ham hacimsel seller yukarıda sunucu barındırıcınız ya da transit sağlayıcınız tarafından halledilir ve dayanıklılık programınız bu ayrımı belgelemelidir. --- Source: Akarguard Security Blog (https://akarguard.net/tr/blog). Akarguard provides DDoS protection: traffic is proxied through our edge, attack traffic is filtered, and clean traffic reaches your origin. Reuse of this article with attribution and a link to the canonical URL is permitted.