Finans teknolojisi şirketi Revolut, 12 Eylül 2026 tarihinde gelişmiş bir dış kimlik taklidi dolandırıcılığı olarak nitelendirdiği olayı doğruladı: Yetkisiz bir taraf, meşru bir devlet kurumunun alan adındaki bir e-posta adresini kullanarak müşteri bilgileri için sahte talepler gönderdi. Talepler, düzen fark edilmeden önce yerine getirildi.

Bu olayı dikkatinize değer kılan şey, alışılmış anlamda bir sızma içermemesidir. Yazılım açığı yok, sızdırılmış parola yok, kötü amaçlı yazılım yok. Revolut'un kendisi, sistemlerinin ve müşteri fonlarının etkilenmediğini açıkladı. Biri verileri doğru yoldan, doğru kanal üzerinden istedi ve aldı. İşte tam da bu nedenle konu yalnızca bankaları değil, müşteri kayıtları tutan her işletmeyi ilgilendiriyor.

Gerçekte doğrulanan nedir

Soruşturma sürdüğü ve pek çok şey henüz açıklanmadığı için, kendimizi şirketin duyurduklarıyla ve uzman yayın organlarının aktardıklarıyla sınırlıyoruz:

  • Yöntem: Gerçek bir devlet kurumuna ait bir alan adının içindeki yetkisiz bir hesaptan, resmî bir bilgi talebinin ağırlığını taşıyan e-postalar gönderildi.
  • Veriler: Doğum tarihi, posta adresi, e-posta adresi ve telefon numarası dahil kimlik ve iletişim bilgileri; ayrıca pasaport ve sürücü belgesi gibi kimlik belgelerinin kopyaları ile "müşterini tanı" kontrolleri sırasında toplanan yüz doğrulama görüntüleri.
  • Ölçek: Şirket sınırlı sayıda müşteriden söz etti ve herhangi bir rakam açıklamadı.
  • Kurum: Revolut, devam eden soruşturmayı gerekçe göstererek alan adı kullanılan devlet kurumunun adını vermeyi reddetti.
  • Müdahale: Adres engellendi, etkilenen müşteriler doğrudan bilgilendirildi ve şirket ilgili devlet kurumunu, kolluk kuvvetlerini, finansal düzenleyicileri ve veri koruma otoritelerini uyardı.

ZachXBT olarak bilinen bir kripto güvenlik araştırmacısı, hedeflemenin yüksek varlıklı müşterilere yönelik göründüğünü değerlendirdi; bu da rastgele toplamadan çok ayrıntılı profiller oluşturulduğuna işaret ediyor. Bu bir şirket açıklaması değil, bir araştırmacının değerlendirmesidir ve onu bu şekilde aktarıyoruz.

Talep neden işe yaradı: Kimlik doğrulama yetkilendirme değildir

Kurumsal e-posta sistemlerinin çoğu, bir mesajın gerçekten iddia ettiği alan adından geldiğini doğrulayan teknik kontrollere dayanır. Bu kontroller sıradan sahteciliğe karşı iyi çalışır: Kontrol etmediği bir alan adını taklit eden herkes reddedilir. Ancak bu kontroller tam olarak tek bir soruyu yanıtlamak için tasarlanmıştır: Bu mesaj o alan adından mı çıktı?

Sizin yanıtlanmasına ihtiyaç duyduğunuz soru bu değil. Sizin sorunuz, mesajı yazan kişinin istediği şeyi isteme yetkisine sahip olup olmadığıdır. Hiçbir e-posta kontrolü bunu yanıtlamaz. İki soru arasındaki mesafe, kimlik doğrulama ile yetkilendirme arasındaki mesafedir ve bu operasyonun tamamı bu boşluktan geçti. Gönderen hesap gerçek alan adının içinde olduğunda, ister ele geçirilmiş ister yanlış tanımlanmış olsun, ekibinizin görebildiği her güven göstergesi yeşil yanar.

Pratik sonuç şu: E-posta ağ geçidinizin görevi, talebi eksiksiz teslim etmekle biter. Talebi değerlendirmek insan işidir ve bireysel sezgi yerine yazılı bir prosedür gerektirir.

İşletmeniz aynı talebi daha basit bir biçimde alıyor

Bunu uzak bir Avrupa fintek hikâyesi olarak bir kenara koymak kolaydır. Ancak Suudi işletmelerine her gün ulaşan talepler, daha sade bir kılıkta aynı şeydir: bir müşteri ekstresi isteyen bir e-posta, düzenleyici bir amaçla çalışan bilgilerini talep eden bir mesaj, sözleşme ayrıntılarını teyit etmenizi isteyen bir telefon, bir işlemi tamamlamak için belge isteyen, tanıdık resmî bir ad taşıyan bir adresten gelen yazışma.

Küçük ve orta ölçekli firmaların çoğunda böyle bir talep şöyle ele alınır: Bir çalışanın önüne düşer, gönderen resmî görünür, resmî bir kurumu reddetmek uymaktan daha riskli gelir ve dosya gönderilir. Kimin istediğine, neyin çıktığına ya da ne zaman çıktığına dair hiçbir kayıt yoktur. Bağımsız bir doğrulama adımı yoktur. Sorun daha sonra ortaya çıktığında, şirketin olayları yeniden kurgulayabileceği hiçbir şeyi yoktur.

Uygulanan baskıya da dikkat edin. Doğrulamayı devre dışı bırakan şey, aciliyet ile resmî görünümün bir araya gelmesidir. Bir devlet işlemini engellemekle suçlanmaktan korkan bir çalışan teyit telefonunu atlar; bu da yaklaşımın bir yan etkisi değil, tasarlanmış etkisidir.

Suudi hukuku sizden ne istiyor

Kişisel Verilerin Korunması Kanunu (PDPL) bu konuyu açık bırakmaz. İşletmenize iki katlı bir yükümlülük yükler: yalnızca izin verilen durumlarda açıklamak ve hata yaptığınızda bildirmek.

  • 15. madde, kişisel verilerin açıklanabileceği durumları belirler; bunlar arasında talepte bulunan tarafın bir kamu kurumu olduğu ve talebin, yönetmelikte belirtildiği şekliyle, bir güvenlik amacına hizmet ettiği, başka bir kanunu uyguladığı veya yargısal gereklilikleri karşıladığı durumlar yer alır.
  • 16. madde, açıklamanın engellenmesi gereken durumları düzenler; bunlar arasında açıklamanın ulusal güvenliği etkileyeceği, kişilerin güvenliğini tehlikeye atacağı veya devam eden bir soruşturmaya müdahale edeceği durumlar bulunur.
  • 20. madde, veri sorumlusunu bir ihlali veya hukuka aykırı bir açıklamayı yetkili makama ve ilgili kişilere bildirmekle yükümlü kılar. Uygulama yönetmeliği, National Data Governance Platform üzerinden yetkili makama bildirim için 72 saatlik bir süre öngörür.

Üçü birlikte okunduğunda belirleyici nokta ortaya çıkar: Kanun hakkı e-postaya değil, kamu kurumuna tanır. Bir kamu kurumunun alan adından gelen bir talep, bu nedenle o kurumun talebi olmaz. Yasal doğrulama yükümlülüğü veri sorumlusu olarak sizde kalır ve yalnızca resmî göründüğü için bir gönderene geçmez.

Origami'nin bakışı

Origami, Suudi işletmeleri için sistemler geliştiren bir teknoloji şirketidir ve sürekli gördüğümüz bir örüntü, güvenlik yatırımlarının neredeyse tamamının yetkisiz girişi önlemeye gitmesidir: parolalar, iki faktörlü kimlik doğrulama, güvenlik duvarları. Bunlar gereklidir, ancak yalnızca bir kapıyı korurlar. Ele aldığımız olay hiçbir zaman kapıdan girmedi. Kapıyı çaldı, verileri istedi ve verileri eline aldı. Hiçbir teknik ayar, yetkili bir çalışanın, doğru görünen bir şekilde dosyayı isteyen birine o dosyayı göndermesini engellemez.

Bu yüzden işletmeden çıkan verileri bir el kitabında yazılı bir yönerge olarak değil, sisteme yerleşik bir prosedür olarak ele alıyoruz: Müşteri verilerini dışa aktarma yetkisi kimde, her dışa aktarım kimin yaptığı, ne zaman ve neden yapıldığıyla birlikte kaydediliyor mu, üçüncü taraf talepleri bir onay yolunu izliyor mu? Geçen ay hangi verilerin buradan çıktığını ve nedenini bir dakika içinde yanıtlayabilen bir şirketin kendini savunacak bir dayanağı vardır. Bunu yapamayan bir şirket ise boşluğu, yanıta ihtiyaç duyduğu gün keşfeder.

Bu hafta benimsenecek tek sayfalık bir prosedür

Bunun için ne bir proje ne de bir bütçe gerekir. Çalışanınızı baskı altında tek başına karar vermek zorunda kalmaktan koruyan, yazılı ve duyurulmuş bir kural gerekir:

  • Hiçbir müşteri veya çalışan verisi yalnızca gelen bir mesaja dayanarak dışarı çıkmaz. Mesaj talebi başlatır; gönderen ne kadar resmî görünürse görünsün ve üslup ne kadar acil olursa olsun, talebi yerine getirmez.
  • Bağımsız bir kanal üzerinden doğrulayın. Mesaja yanıt vermeyin ve içinde yazan bir numarayı aramayın. Kurumun resmî web sitesinde yayımlanan numarayı arayın. Bu tek adım, operasyonun tamamını durdururdu.
  • Adı belirlenmiş tek bir onaylayıcı. Verileri harici bir tarafa vermeye yetkili tek bir kişi ve yokluklar için adı belirlenmiş bir vekil. Yetkiyi herkese dağıtmak, kimsenin hesap vermemesi demektir.
  • Her talep için yazılı bir kayıt. Kim istedi, hangi sıfatla, hangi veriler, kim onayladı, nasıl doğrulandı ve tarih. Bir tabloda tek bir satır yeterlidir ve değeri bugün değil, bir yıl sonra ortaya çıkar.
  • Asgarisini gönderin. Talep meşruysa, dosyanın tamamını ya da tablonun bütününü değil, tam olarak isteneni gönderin. Gönderdiğiniz hacim, talebin sahte çıkması durumunda zararın büyüklüğüdür.
  • Bildirim yolunu ihtiyaç duymadan önce bilin. SDAIA'ya 72 saat içinde kim bildirecek, hangi platform üzerinden, hangi ayrıntılarla? Prosedürü aramakla geçen süre doğrudan sürenin içinden yenir.

Tüm bunların altında yatan ilke, doğrulamanın engelleme olmadığıdır. Gerçek bir resmî kurum, kendi yayımladığı numaraya yapılan bir teyit aramasına itiraz etmez; doğrulanmaya itiraz eden ise tam da doğrulanması gereken kişidir. Bunu ekibiniz için yazıya dökün ki bir talebi reddetmek, hiçbir zaman tek bir çalışanın tek başına taşımak zorunda olduğu kişisel bir risk olmasın.

Kaynaklar