Forex broker’ları için veri güvenliği soyut bir BT meselesi değildir — operasyonel ve düzenleyici bir gerekliliktir. Broker’lar hassas müşteri verilerini işler: kimlik belgeleri, finansal kayıtlar, işlem geçmişi, ödeme detayları ve KYC dokümantasyonu. Bu kategorilerden herhangi birini etkileyen bir ihlal; düzenleyici risk, itibar kaybı ve birçok yargı alanında, platformdaki her müşteriyi etkileyen zorunlu ihlal bildirim yükümlülükleri doğurur.
Forex sektöründeki çoğu veri sızıntısı, iyi korunmuş altyapıya yönelik sofistike dış saldırılardan kaynaklanmaz. Sorun içeriden gelir: yetersiz erişim kontrollerinden, yamalanmamış sistemlerden, güvensiz üçüncü taraf entegrasyonlardan ve zamanla biriken operasyonel kısayollardan. Bu makale, her forex aracı kurumunun sahip olması gereken pratik güvenlik önlemlerini altyapı katmanlarına göre ele alır.
Yedekleme Stratejisi — İhlal Kurtarmanın Temeli
Önleme konusuna girmeden önce azaltmayı ele alın. Güncel yedekleri olmayan bir broker, fidye yazılımı saldırısından veya sunucu arızasından kurtaramıyorsa; ihlal yaşansa bile birkaç saat içinde toparlanan bir kuruluşa kıyasla çok daha kötü bir senaryoyla karşı karşıya kalır. Yedekleme altyapısı, gelecekte yapılacak bir proje değil; vazgeçilemez bir operasyonel yük olarak değerlendirilmelidir.
Çalışan iş istasyonları için: Windows’ta EaseUS, Mac’te Time Machine gibi özel yedekleme yazılımı ile harici sürücülere otomatik artımlı yedekleme, en yaygın arıza senaryosunu karşılar — tekil makinelerde sabit disk arızası veya fidye yazılımı. Fidye yazılımı yerel dosyaları şifrelediğinde, yakın tarihli bir yedek çevrimdışı olarak mevcutsa saldırganlar verileri rehin tutamaz. Bu, müşteri verisi veya iş açısından kritik dokümanlarla ilgilenen her çalışan için geçerlidir.
Sunucular için: Bulut üzerinden barındırılan sunucular, barındırma sağlayıcısının snapshot (anlık görüntü) hizmeti aracılığıyla yedeklenebilir — donanım ya da ek yazılım gerekmez. Bulut dışı (on-premises) veya bulut olmayan sunucular için de iş istasyonlarında kullanılan aynı artımlı yedekleme yaklaşımı geçerlidir. Kritik şart, en az bir yedek kopyasının çevrimdışı olarak veya birincil sunucudan erişilemeyen bir ağ segmentinde saklanmasıdır — ele geçirilmiş bir sunucuya bağlanan (mount edilen) bir çevrim içi yedek, yedek değildir.
Yedek testleri: Hiç geri yüklenmemiş yedekler test edilmemiş varsayımlardır. Kurtarma prosedürleri en az çeyreklik olarak test edilmelidir — yedek dosyalarının bozuk olmadığını, geri yükleme işleminin kabul edilebilir bir zaman dilimi içinde tamamlandığını ve geri yüklenen sistemin çalışır durumda olduğunu doğrulamak. Gerçek bir olay sırasında kullanılabilir olmadığı fark edilen bir yedek; diğer kurtarma seçeneklerine geçme kararını geciktirdiği için, hiç yedek olmamasından daha kötüdür.
Web Sitesi Güvenliği — WordPress ve Eklenti Riski
Çoğu aracı kurum web sitesi WordPress veya benzeri bir CMS üzerinde çalışır. WordPress’in kendisi olgun, iyi bakımı yapılan bir platformdur; güvenlik riski çekirdek kod tabanında değil, eklenti ve tema ekosistemindedir. WordPress sitesine yüklenen her eklenti potansiyel bir saldırı vektörüdür. Yamalanmamış açıkları olan eklentiler, otomatik tarama ve istismar botları aracılığıyla binlerce siteyi aynı anda ihlal etmek için kullanılabilir.
Aracı kurum web siteleri için en önemli kural: WordPress ile temas eden hiçbir sistemde herhangi bir müşteri verisini saklamayın. Web sitesi yalnızca pazarlama içeriğini, kayıt formu sunumunu ve herkese açık bilgileri yönetmelidir. Müşteri verileri — hesaplar, KYC dokümanları, işlem geçmişi, ödeme kayıtları — web sitesi veritabanında değil, CRM ve back-office sisteminde yaşar. Bu mimari ayrım, sitenin kendisi bozulmuş (defaced) ya da çevrimdışı alınmış olsa bile müşteri verilerinin açığa çıkmasını engeller.
WordPress aracı kurum siteleri için operasyonel gereksinimler:
- Plugin ve tema güncellemelerini zamanında izlemek ve uygulamak üzere sorumlu bir kişi ya da ajans görevlendirin — çoğu WordPress ihlali, yamalanmış ama henüz uygulanmamış açıkları kullanır
- Her güncelleme döngüsünden önce eksiksiz bir site yedeği alın
- Site hazırlanıp yayına geçmeden önce ve herhangi bir önemli eklenti ya da tema güncellemesinden sonra penetrasyon ve zafiyet testleri gerçekleştirin
- DDoS koruması, WAF (Web Uygulama Güvenlik Duvarı) ve bot filtreleme için Cloudflare veya eşdeğer bir CDN uygulayın
- Kullanılmayan eklentileri ve temaları kaldırın — yüklü kalıp pasif olan her eklenti, hiçbir değer üretmeyen bir zafiyettir
İşlem Platformu Güvenliği
MT4, MT5 ve diğer işlem platformları, tasarım gereği IP’leri ve portları herkese açık olarak gösterir — yatırımcıların ve köprülerin (bridges) bunlara bağlanması gerekir. Bu açık erişim kaçınılmazdır ancak dikkatle yönetilmelidir.
İşlem platformu sunucu güvenliği için temel hususlar:
- Güvenlik duvarı yapılandırması— Yönetim portlarına yalnızca bilinen IP adreslerinden erişime izin verin. Yöneticinin (admin) ve yöneticilik (manager) erişimi, IP izin listesi (allowlisting) yapılmadan asla genel internetin açık erişimine sunulmamalıdır
- Güçlü kimlik bilgileri— yönetici API kimlik bilgileri ve admin şifreleri karmaşık, benzersiz olmalı ve bir parola yöneticisinde saklanmalıdır — e-posta yazışmalarında veya paylaşılan dokümanlarda değil
- Sağlama (provisioning) öncesi sunucu sertleştirme— internete bağlanmadan önce sertleştirilmemiş, yeni sağlanmış bir sunucu; yeni IP’leri tarayan otomatik botlar tarafından dakikalar içinde ele geçirilebilir. Varsayılan kimlik bilgileri, açık portlar ve yamalanmamış temel OS paketleri otomatik olarak istismar edilir. Yeni bir sunucuya herhangi bir uygulama yüklenmeden önce sertleştirme yapılmalıdır.
- Düzenli yamalama— altta çalışan sunucu işletim sisteminin, üzerinde çalışan işlem platformu yazılımından bağımsız olarak güvenlik güncellemeleri alması gerekir
- Yönetim ağı (management network) ayrımı— altyapı uygunsa, işlem platformu yönetim erişimi doğrudan internete açık olmak yerine VPN üzerinden kullanılmalıdır
İşlem platformu sağlayıcıları yazılım satar ve sunucu kurulumunu broker’a bırakır. Bu, işlem platformu sunucusunun güvenliğinin broker’ın sorumluluğu olduğu anlamına gelir — platform sağlayıcısının değil. Birçok broker bunu hafife alır ve sunucu sağlama işini, devam eden bir güvenlik yükümlülüğü yerine tek seferlik bir görev gibi ele alır.
CRM ve Üçüncü Taraf Sistem Güvenliği
Bir broker’ın CRM’i ve back-office sistemi birden fazla üçüncü taraf servistle entegredir — PSP’ler, ödeme toplayıcıları, KYC sağlayıcıları, IB sistemleri, raporlama araçları, pazarlama platformları. Her entegrasyon, güvence altına alınması gereken bir veri bağlantısı demektir. Bu bağlantıları ortadan kaldırmanın bir yolu yoktur — operasyonel olarak gereklidir — ancak maruziyeti en aza indirecek şekilde yönetilebilir.
Kendi kendine barındırmaya (self-hosting) karşı üçüncü taraf barındırmaya göre: Hassas verileri kendi sunucunuzda barındırma içgüdüsü anlaşılır, ancak çoğu zaman ters tepen bir yaklaşım olur. Güvenli bir sunucu ortamını sürdürmek sürekli emek gerektirir — OS yamalama, güvenlik duvarı yönetimi, izinsiz giriş tespiti, erişim kontrolü, depolamada şifreleme (encryption at rest) ve olay müdahale yeteneği. Çoğu broker’ın, bu işi kendini bu altyapı sağlayıcılığının temel işi olarak yapan özel altyapı sağlayıcılarının sürdürdüğü standartta yapacak dahili kaynağı yoktur.
Yeni sağlanan bir bulut sunucusu, yalnızca birkaç dakika bile gözetimsiz bırakıldığında, yeni IP’leri tarayan ve varsayılan kimlik bilgileri ya da yamalanmamış güvenlik açıklarını arayan otomatik botlar tarafından ele geçirilebilir. Bu teorik bir risk değildir — rutin bir durumdur. Sorun, sunucunuzun taranıp taranmayacağı değil; ilk tarama gelmeden önce sunucunuzun sağlamlaştırılıp sağlamlaştırılmadığıdır.
Kendi kendine barındırma gerekiyorsa: Minimum mimari, uygulama sunucusunu veritabanı sunucusundan ayırır — yalnızca ayrı dizinler değil; fiziksel olarak ayrı sunucu örneklerinde. Veritabanına erişim, yalnızca uygulama sunucusunun IP adresi ve belirlenmiş bir VPN uç noktasıyla sınırlandırılmalıdır. Veritabanı sunucusuna doğrudan internet erişimine asla izin verilmemelidir. Uygulama, dururken veri şifrelemesini destekliyorsa bunu uygulayın — ve şifreleme anahtarlarını, uygulama ve veritabanının ikisinden de ayrı, üçüncü bir sunucuda saklayın. Bu, şifresi çözülebilir verilere erişmek için saldırganın en az iki ayrı sistemi ele geçirmesini zorunlu kılar.
API güvenliği: CRM, trading platformu ve üçüncü taraf hizmetler arasındaki tüm API entegrasyonları şifreli bağlantılar (HTTPS/TLS) kullanmalı, API anahtarlarını belirli bir takvime göre döndürmeli ve sağlayıcı destekliyorsa IP izin listesi (allowlisting) uygulamalıdır. Uygulama kodunda sabitlenmiş veya şifrelenmemiş yapılandırma dosyalarında saklanmış API kimlik bilgileri, yaygın ve kaçınılabilir bir güvenlik açığıdır.
Erişim Kontrolü ve Dahili Tehdit Azaltımı
Çoğu forex sektörü veri sızıntısı içeriden kaynaklanır — rolünün gerektirdiğinden fazla erişime sahip olan veya kimlik bilgilerini paylaşan ya da üçüncü taraflara erişim sağlama konusunda sosyal mühendislikle kandırılan mevcut ya da eski çalışanlardan. Teknik güvenlik önlemleri gereklidir ancak, herhangi bir tek ele geçirilmiş hesabın etkisini (blast radius) sınırlayan erişim kontrolü uygulamaları olmadan yetersiz kalır.
- En Az Ayrıcalık İlkesi — her personel yalnızca rolünün gerektirdiği sistemlere ve verilere erişmelidir. Pazarlama ekibi üyesinin tüm müşteri veritabanına erişmesine gerek yoktur. Bir destek temsilcisinin ödeme işleme yönetici paneline erişmesine gerek yoktur.
- Çok Faktörlü Kimlik Doğrulama (MFA) — CRM, trading platformu yönetimi, barındırma kontrol panelleri ve ödeme sistemi gösterge panellerine yapılacak tüm yönetici erişimleri için zorunludur. MFA, ele geçirilmiş parolaların etkisini ciddi ölçüde azaltır.
- İşten Çıkış (Offboarding) Prosedürleri — bir çalışan ayrıldığında erişim iptali derhal ve sistematik olarak yapılmalıdır. Çalışan ayrıldıktan sonra aktif kalmaya devam eden hesaplar, önlenmesi kolay ama sıkça gözden kaçan kalıcı bir zafiyettir.
- Denetim Günlüğü (Audit logging) — CRM ve back-office sisteminde yapılan yönetici işlemleri zaman damgaları ve kullanıcı kimliğiyle birlikte kaydedilmelidir. Denetim günlükleri kötüye kullanımı caydırır, olay incelemesini destekler ve düzenlenmiş yargı bölgelerinde erişim izleme için uyumluluk gerekliliklerini sağlar.
Prop Firmalar için Veri Güvenliği Hususları
Prop firmalar, brokerların yaşamadığı özel bir veri güvenliği konusu ile karşı karşıyadır: ödemeler öncesinde KYC kapsamında toplanan kimlik belgelerinin hacmi. Bir prop firma, ayda binlerce ödeme talebi işlediğinde pasaportları, ulusal kimlik kartlarını ve adres kanıtı belgelerini ölçekli şekilde toplar. Bu kimlik belgesi koleksiyonu, veri hırsızlığı için yüksek değerli bir hedeftir — hem kimlik verilerinin kendisi hem de doğrulanmış kimliklerin sahte kullanımına yönelik olarak.
Prop firma belge işlemesi için özel gereksinimler:
- Kimlik belgeleri, dururken şifreli olarak saklanmalı ve erişim yalnızca uyumluluk (compliance) personeliyle sınırlandırılmalı
- Belge saklama politikaları; KYC belgelerinin ne kadar süre tutulacağını ve ne zaman silineceğini tanımlamalıdır — GDPR ve eşdeğer düzenlemeler bunu çoğu yargı bölgesinde zorunlu kılar
- Otomatik KYC sağlayıcıları (Sumsub, Onfido) belge doğrulamasını ve saklamayı kendi uyumlu altyapılarında gerçekleştirir — bu da prop firmanın belge saklama kaynaklı riskle doğrudan maruziyetini azaltır
- Biyometrik veya belge eşleştirme kullanan mükerrer hesap tespit sistemleri, sahte kimliklerin birden fazla meydan okuma (challenge) hesabında yeniden kullanılma riskini azaltır
Müşteriyle Yüz Yüze Uygulamalar için Güvenlik Kontrol Listesi
- DDoS koruması, WAF ve SSL sonlandırma için Cloudflare veya eşdeğer bir CDN kullanın
- Tüm katmanlarda şifreli bağlantıları zorunlu kılın — web trafiği için SSL/TLS, sunucu erişimi için SSH, dosya aktarımları için SFTP
- Tüm ödeme işleme bileşenleri için PCI DSS uyumluluğunu doğrulayın
- Müşteriyle yüz yüze sistemlere yapılan tüm yönetici ve personel erişimleri için MFA’yı zorunlu kılın
- Mümkün olduğunda Linux’ta barındırın — web’e bakan uygulamalar için Linux sunucularının saldırı yüzeyi Windows’a göre belirgin biçimde daha küçüktür
- Go-live öncesinde ve önemli altyapı değişikliklerinden sonra sızma testi (penetration testing) yapın
- Olay müdahale prosedürünü güncel tutun — bir ihlal tespit edildiğinde kim ne yapacak, düzenleyici bildirim gereklilikleri dahil olmak üzere belgelenmiş bir plan
- API anahtarlarını ve kimlik bilgilerini tanımlı bir takvime göre gözden geçirin ve döndürün
Sonuç
Bir forex aracı kurumu (broker) ya da prop firma için veri güvenliği tek seferlik bir proje değildir — devam eden bir operasyonel uygulamadır. 2026’daki tehdit ortamı, çoğu broker ilk altyapısını kurduğunda olduğundan daha otomatik ve daha hedeflidir. Botlar, sunucu sağlanır sağlanmaz dakikalar içinde savunmasız sistemleri tarar. Erişime açıldıktan sonraki saatler içinde eklenti (plugin) güvenlik açıkları ölçekte istismar edilir. On çalışan varken yeterli olan iç erişim kontrolleri, elli çalışanla birlikte yetersiz hale gelir.
Bu makalede açıklanan güvenlik önlemleri ileri seviye değil — temel (baseline) seviyededir. Hepsini uygulayan bir broker saldırılara karşı bağışık değildir; ancak güvenliği gelecekte ele almayı düşünen bir broker’a kıyasla çok daha dayanıklıdır. Özellikle Kenmore Design CRM açısından, müşteri verileri, birincil sorumluluğu bu altyapıyı güvenli tutmak olan bir ekip tarafından sürdürülen altyapıda barındırılır — broker’ın sorumluluğu erişim kontrollerini yönetmek, kendi sistemlerini doğru şekilde sürdürmek ve entegrasyon tarafındaki güvenlik uygulamalarını uygulamaktır.
Forex Broker’ları için Veri Güvenliği Üzerine Danışmanlık Talep Edin
Forex broker’ınızdaki altyapı genelinde veri güvenliğini güçlendirmek için uzman desteği alın. Yedekleme stratejilerinizi, barındırma mimarinizi, CRM entegrasyonlarınızı ve istemciye dönük sistemlerinizi gözden geçirmenize yardımcı olarak veri sızıntısı ve operasyonel kesinti riskini azaltacağız.
Birlikte mevcut güvenlik kurulumunuzu değerlendirip hassas istemci verilerini korumak, güveni sürdürmek ve broker’ınızın itibarını güvence altına almak için uygulanabilir adımları belirleyeceğiz.
