Siber güvenlikte güncel içgörüler, araştırmalar ve hikayeler

SAP sistemleri, modern kurumların finansal omurgasıdır. ERP, finans muhasebesi, insan kaynakları, tedarik zinciri ve üretim planlaması gibi en kritik iş süreçleri SAP üzerinde çalışır. Bu da SAP sunucularını saldırganlar için son derece cazip bir hedef haline getirir: tek bir başarılı saldırı, bordro verilerinden banka transferlerine, müşteri bilgilerinden ticari sırlara kadar kurumun tüm hassas verisine erişim anlamına gelebilir. Ne yazık ki sahada gördüğümüz manzara çoğu zaman aynıdır. SAP kurulumları işlevsellik odaklı yapılandırılır, güvenlik ise sonradan ele alınır ya da hiç ele alınmaz.

Bu yazıda, sızma testlerimiz sırasında SAP ortamlarında en sık karşılaştığımız zafiyet sınıflarını ve her biri için uygulanabilir savunma stratejilerini ele alıyoruz. Hedef kitlemiz SAP/BASIS yöneticileri ve kurumsal güvenlik ekipleri, dolayısıyla hem riskleri hem de somut sertleştirme adımlarını teknik düzeyde inceleyeceğiz.

1. Varsayılan Standart Kullanıcılar ve Sabit Şifreler

SAP, kurulum sırasında bir dizi standart kullanıcıyı önceden tanımlı şifrelerle oluşturur. Bunların başında SAP* (süper kullanıcı, varsayılan şifresi geçmişte 06071992 veya PASS), DDIC (Veri Sözlüğü yöneticisi, varsayılan 19920706), EARLYWATCH (uzaktan izleme) ve istemci 000'de bulunan TMSADM (Transport Management System) hesapları gelir. Saldırganlar bu hesapları ilk denedikleri kapılardır. Çünkü çok sayıda kurumda bu şifreler hâlâ varsayılan durumda ya da zayıf şekilde değiştirilmiş haldedir.

Risk: SAP* özellikle tehlikelidir. İlgili kullanıcı tablosundan silinirse, kernel'in tanıdığı gömülü (hardcoded) bir SAP* hesabı varsayılan şifreyle devreye girebilir. Bu hesap, profil parametresi login/no_automatic_user_sapstar doğru ayarlanmamışsa tam yetkili erişim sağlar.

• Tüm standart hesapların şifrelerini değiştirin ve mümkün olanları kilitleyin (USR02 üzerinden durumu denetleyin).
• login/no_automatic_user_sapstar = 1 parametresini etkinleştirerek gömülü SAP* davranışını engelleyin.
• Tüm istemcileri (000, 001 ve özel istemciler dahil) tek tek denetleyin. Standart kullanıcı kontrolü için RSUSR003 raporunu düzenli olarak çalıştırın.
• Kritik hesapları SU01 ile referans/servis dışı kullanıcılara dönüştürerek interaktif oturum açmayı kapatın.

2. RFC ve RFC Gateway İstismarları

RFC (Remote Function Call), SAP sistemlerinin birbiriyle ve dış uygulamalarla konuştuğu temel protokoldür. RFC Gateway ise bu çağrıları yöneten bileşendir ve yanlış yapılandırıldığında SAP ortamındaki en ciddi açıklardan birini oluşturur. Asıl sorun, kayıtsız (registered) ve başlatılmış (started) harici programların denetimsiz biçimde Gateway üzerinden çalıştırılabilmesidir.

Risk: reg_info ve sec_info erişim kontrol listeleri eksik ya da fazla geniş tanımlanmışsa, kimliği doğrulanmamış bir saldırgan Gateway üzerinden kendi programını kaydedip işletim sistemi düzeyinde komut çalıştırabilir. Bu, doğrudan SAP sunucusunun ele geçirilmesine giden bir yoldur. Güvenilen RFC bağlantıları (trusted/trusting) ise yanlış kurulduğunda düşük yetkili bir sistemden yüksek yetkili sisteme yatay/dikey geçiş imkânı sunar.

• reg_info ve sec_info ACL dosyalarını "varsayılan reddet" mantığıyla yapılandırın, yalnızca bilinen program ve sunucuları beyaz listeye alın.
• gw/reg_no_conn_info ve gw/acl_mode profil parametrelerini sertleştirin, Gateway izlemeyi (SMGW) etkinleştirin.
• Güvenilen RFC bağlantılarını minimum yetkiyle kurun. S_RFCACL yetki nesnesini sıkı tanımlayın ve SM59 içinde gömülü kullanıcı/şifre saklamaktan kaçının.
• Gereksiz RFC hedeflerini kaldırın, düzenli olarak SM59 envanteri çıkarın.

3. SAP ICM / ICMAD ve Web Bileşeni Zafiyetleri

SAP Internet Communication Manager (ICM), SAP sistemlerinin HTTP, HTTPS ve SMTP trafiğini yöneten bileşendir ve SAP'ın dış dünyaya açılan web yüzeyidir. Son yıllarda bu katmanda, özellikle HTTP istek kaçakçılığı (request smuggling) ve bellek bozulması sınıfından ciddi zafiyetler açıklanmıştır (kamuoyunda "ICMAD" olarak anılan açık sınıfı bunlara örnektir).

Risk: Kimlik doğrulaması gerektirmeyen bu tür açıklar, internete açık SAP web uygulamalarında oturum ele geçirme, kimlik bilgisi sızdırma ve hizmet dışı bırakma (DoS) ile sonuçlanabilir. ICM doğrudan internete bakıyorsa etki alanı çok geniştir.

• ICM ve web dispatcher için yayımlanan SAP Security Notes'u öncelikli olarak uygulayın.
• SAP sistemlerini doğrudan internete açmayın. Önüne SAP Web Dispatcher ve WAF/ters proxy katmanı yerleştirin.
• Kullanılmayan ICM servislerini ve gereksiz HTTP uç noktalarını (SICF) devre dışı bırakın.

4. Solution Manager ve SAP Router Üzerinden Saldırı

SAP Solution Manager (SolMan), tüm SAP sistemlerini yöneten merkezi platformdur ve genellikle ortamdaki diğer sistemlere yüksek yetkili RFC bağlantılarıyla bağlıdır. Bu merkezi konumu onu kritik bir saldırı sıçrama tahtası yapar. SAP Router ise SAP ağ trafiğini yönlendiren ve sıklıkla DMZ'de internete bakan bir bileşendir.

Risk: Yamalanmamış bir SolMan örneği, kimlik doğrulamasız ele geçirildiğinde ona bağlı tüm uydu (satellite) sistemlere zincirleme erişim sağlayabilir. Yanlış yapılandırılmış bir SAP Router ise saprouttab kuralları gevşekse iç SAP ağına bir tünel görevi görür.

• SolMan'ı en güncel destek paketi ve Security Notes seviyesinde tutun, yönetim arayüzlerini ağ düzeyinde kısıtlayın.
• SAP Router için saprouttab kurallarını "varsayılan reddet" ilkesiyle yazın. SNC ile şifreli ve kimlik doğrulamalı yönlendirme zorunlu kılın.
• SolMan ile uydu sistemler arasındaki RFC kullanıcılarının yetkilerini gözden geçirin ve gereğinden fazla geniş profilleri (örn. SAP_ALL) kaldırın.

5. Eksik SAP Security Notes ve Yamalama Boşlukları

SAP her ay "Patch Tuesday" benzeri bir döngüyle güvenlik notları (SAP Security Notes) yayımlar. Sahada en yaygın temel sorun, bu notların aylarca hatta yıllarca uygulanmamasıdır. SAP sistemleri "çalışıyorsa dokunma" kültürüyle yönetildiğinde, bilinen ve kamuya açık zafiyetler uzun süre açık kalır.

Risk: Kamuya açıklanmış zafiyetler için genellikle hazır istismar kodu bulunur. Saldırgan için iş, yalnızca yamasız bir hedef bulmaya indirgenir.

• Düzenli bir yama döngüsü kurun ve SAP EarlyWatch Alert ile System Recommendations (SolMan içinde) raporlarını takip edin.
• Yüksek ve kritik (HotNews) notları en yakın acil bakım zamanında önceliklendirin.
• Yama uygulanamayan durumlarda telafi edici kontroller (ağ kısıtlama, izleme) devreye alın.

6. Yetkilendirme ve Görevler Ayrılığı (SoD) Sorunları

SAP'ın yetkilendirme modeli güçlü ama karmaşıktır. Roller, profiller ve yetki nesneleri (authorization objects) zamanla birikerek devasa ve denetlenemez hale gelir. En kritik bulgular, aşırı yetkili kullanıcılar ve Görevler Ayrılığı (Segregation of Duties) ihlalleridir.

Risk: SAP_ALL veya SAP_NEW profilini taşıyan kullanıcılar, sistemde sınırsız yetkiye sahiptir. SoD ihlallerinde ise tek bir kullanıcı hem satıcı oluşturup hem ödeme onaylayabildiği için iç dolandırıcılık (fraud) kapısı açılır. Ayrıca S_DEVELOP, S_TABU_DIS ve S_RFC gibi güçlü nesnelerin gevşek tanımlanması ayrıcalık yükseltmeye yol açar.

• Üretim ortamında SAP_ALL ve SAP_NEW profillerini kaldırın, geniş yetkileri olan kullanıcıları RSUSR002 ile düzenli tespit edin.
• SoD çatışma matrisi tanımlayın. SAP GRC Access Control veya eşdeğer araçlarla sürekli denetleyin.
• En az ayrıcalık (least privilege) ilkesini benimseyin. Hata ayıklama ve tablo erişim yetkilerini (S_DEVELOP, S_TABU_DIS) sıkı kısıtlayın.

7. Güvensiz Arayüzler ve Şifrelenmemiş İletişim

Varsayılan haliyle SAP'ın iki temel protokolü olan DIAG (SAP GUI ile sunucu arasındaki istemci protokolü) ve RFC, şifrelenmemiş çalışır. DIAG yalnızca zayıf bir gizleme (obfuscation) kullanır, gerçek bir şifreleme değildir.

Risk: Ağ trafiğini dinleyebilen bir saldırgan, DIAG/RFC oturumlarından kimlik bilgilerini, iş verilerini ve oturum bilgilerini açık metin olarak çözümleyebilir. İç ağda gerçekleştirilen ortadaki adam (MITM) saldırıları bu nedenle özellikle etkilidir.

• SNC (Secure Network Communications) ile DIAG ve RFC trafiğini uçtan uca şifreleyin.
• Web trafiği için TLS'i zorunlu kılın ve zayıf şifreleme paketlerini devre dışı bırakın.
• Parola politikalarını güçlendirin (login/min_password_lng, karmaşıklık parametreleri) ve mümkünse tek oturum açma (SSO) ile çok faktörlü doğrulamaya geçin.

8. Genel Savunma Stratejisi: Katmanlı Yaklaşım

SAP güvenliği tek bir ayarla sağlanmaz. Üst üste binen katmanlardan oluşan bir program gerektirir. Ağ segmentasyonu ile SAP sistemlerini ayrı bir güvenlik bölgesine alın, yönetim portlarını (32xx, 33xx, 36xx, 81xx serisi) yalnızca yetkili yönetim ağlarına açın ve hiçbir SAP endpoint bileşenini doğrudan internete bakacak şekilde konumlandırmayın. Yamalama döngüsünü kurumsal bir süreç olarak işletin, RFC ve Gateway yapılandırmasını sürekli denetleyin, yetki matrisini periyodik olarak gözden geçirin.

Bunların üzerine izleme ve tespit katmanını ekleyin: SAP denetim günlüğünü (SM19/SM20: Security Audit Log) etkinleştirin, kritik olayları (başarısız oturum denemeleri, yetki değişiklikleri, RFC çağrıları) merkezi bir SIEM'e aktarın. Güvenlik, "kur ve unut" değil, sürekli yönetilen bir döngüdür.

Hızlı kontrol listesi

• Tüm standart hesapların (SAP*, DDIC, EARLYWATCH, TMSADM) şifreleri değiştirildi ve gereksizler kilitlendi mi?
• login/no_automatic_user_sapstar = 1 parametresi tüm istemcilerde etkin mi?
• RFC Gateway reg_info/sec_info ACL'leri "varsayılan reddet" ile yapılandırıldı mı?
• Kritik ve HotNews SAP Security Notes güncel mi, düzenli bir yama döngüsü var mı?
• SAP_ALL/SAP_NEW profilleri üretimden kaldırıldı ve SoD çatışmaları denetleniyor mu?
• DIAG ve RFC trafiği SNC ile, web trafiği TLS ile şifreleniyor mu?
• SAP sistemleri ağ segmentasyonuyla izole edildi ve internete doğrudan açık değil mi?
• Security Audit Log etkin ve SIEM ile merkezi olarak izleniyor mu?

Raze yaklaşımı

Raze Security olarak SAP ortamlarını yalnızca otomatik tarama ile değil, gerçek saldırgan bakış açısıyla değerlendiriyoruz. RFC Gateway istismarından standart hesap denetimine, yetki ve SoD analizinden ICM/SolMan/SAP Router gibi dış yüzeyin test edilmesine kadar SAP'a özel bir metodolojiyle çalışıyor. Bulduğumuz her zafiyeti somut sertleştirme adımlarıyla raporluyoruz. SAP altyapınızın güvenlik duruşunu netleştirmek için sızma testi hizmetimizi inceleyebilir, kurumunuza özel bir değerlendirme için bizimle iletişime geçebilirsiniz.

KVKK uyumu, çoğu kurumun sandığının aksine, bir kez tamamlanıp rafa kaldırılan bir proje değil. Veri yaşam döngüsüyle birlikte sürekli yenilenen, idari ve teknik tedbirlerin iç içe geçtiği canlı bir süreçtir. 6698 sayılı Kişisel Verilerin Korunması Kanunu yürürlüğe gireli yıllar geçmiş olmasına rağmen, sahada yaptığımız denetim ve danışmanlık çalışmalarında aynı hataların tekrar ettiğini görüyoruz. Bu hataların çoğu kötü niyetten değil, uyumun yalnızca hukuki bir belge işi sanılmasından kaynaklanıyor. Oysa erişim kontrolü, şifreleme, loglama ve sızma testi gibi teknik tedbirler olmadan, en mükemmel aydınlatma metni bile kâğıt üzerinde kalır. Bu yazıda sahada en sık karşılaştığımız yedi hatayı ve her biri için kanıta dayalı doğru yaklaşımı ele alıyoruz.

1. Veri envanterini tek seferlik bir Excel sanmak

En yaygın hata, kişisel veri işleme envanterinin bir kez doldurulup unutulan statik bir tablo olarak görülmesidir. Gerçekte kurumlar her gün yeni uygulamalar devreye alır, yeni form alanları ekler, bulut servisleri entegre eder. Birkaç ay içinde envanter ile gerçek durum arasındaki uçurum açılır ve VERBİS kaydından aydınlatma metnine kadar her şey güncelliğini yitirir. Daha tehlikelisi, kimsenin haberi olmadan veri toplayan gölge BT (shadow IT) sistemleridir.

Doğru yaklaşım: Envanteri canlı bir varlık olarak ele alın. Mümkün olduğunca otomatik veri keşfi (data discovery) araçlarıyla veritabanlarını, dosya paylaşımlarını ve bulut depolarını periyodik tarayın. Kişisel veri içeren alanları sınıflandırın. Manuel anketleri yılda bir değil, her önemli sistem değişikliğinde tetikleyin. Envanteri, veri kategorisi, hukuki sebep, saklama süresi, alıcı grupları ve aktarım bilgileriyle ilişkisel tutun ki VERBİS ve aydınlatma metni buradan beslensin.

2. Aydınlatma metnini genel avukat şablonuyla geçiştirmek

İnternetten indirilen ya da her müşteriye aynı şekilde verilen genel şablon aydınlatma metinleri, Kanun'un 10. maddesindeki somutluk beklentisini karşılamaz. Hangi verinin, hangi amaçla, hangi hukuki sebebe dayanarak işlendiği belirsiz kalır. Aktarım alıcıları muğlak ifadelerle geçiştirilir. Kurul kararları, "ticari faaliyetlerin yürütülmesi" gibi genel-geçer amaç beyanlarını yetersiz bulmaktadır.

Doğru yaklaşım: Aydınlatma metnini her veri işleme faaliyeti ve her temas noktası (web formu, çağrı merkezi, İK başvurusu, kamera kaydı) için bağlamsal olarak hazırlayın. Metin, işlenen veri kategorilerini, somut amaçları, dayanılan hukuki sebebi, aktarım yapılan alıcı gruplarını ve saklama süresini açıkça belirtmelidir. Aydınlatma yükümlülüğü ile açık rızayı birbirinden ayrı tutun, aydınlatma her durumda gereklidir, rıza ise yalnızca belirli hallerde.

3. Açık rızayı gereksiz yere her yere koymak

"Ne olur ne olmaz, rıza alalım" yaklaşımı, KVKK'nın en yanlış anlaşılan noktalarından biridir. Açık rıza, Kanun'daki altı hukuki sebepten yalnızca biridir ve istisnai bir dayanaktır. Bir sözleşmenin ifası, kanuni yükümlülük, meşru menfaat ya da bir hakkın tesisi için zaten işlenebilen veriye rıza eklemek, hem hukuken hatalıdır hem de risk yaratır: Çünkü açık rıza her zaman geri alınabilir. Rıza ile işlediğinizi beyan ettiğiniz bir veriyi, kişi rızasını çekince işlemeye devam edemezsiniz.

Doğru yaklaşım: Her veri işleme faaliyeti için önce uygun hukuki sebebi belirleyin. Açık rızaya yalnızca başka hiçbir hukuki sebep uygulanamadığında başvurun (örneğin pazarlama amaçlı elektronik ileti, özel nitelikli veri işleme gibi haller). Rızayı diğer metin ve onaylardan ayrı, özgür iradeyle ve bilgilendirilmiş şekilde alın, "hizmeti almak için zorunlu" kıldığınız rıza geçersiz sayılır.

4. VERBİS kaydını bir kez yapıp güncellememek

Veri Sorumluları Sicil Bilgi Sistemi (VERBİS) kaydı, ilk başvuruyla bitmiş sayılan bir formalite değildir. Kayıt sırasında beyan edilen veri kategorileri, işleme amaçları, alıcı grupları, yurt dışı aktarım bilgileri ve alınan teknik-idari tedbirler zamanla değişir. Bu değişiklikler VERBİS'e yansıtılmazsa beyan ile gerçek durum çelişir. Bu da denetimlerde idari yaptırım riskidir.

Doğru yaklaşım: VERBİS beyanını veri envanterinizin bir çıktısı olarak konumlandırın, envanter değiştiğinde sicili güncelleyin. Yeni bir aktarım alıcısı, yeni bir bulut servisi ya da değişen saklama süreleri gibi durumları takip edecek bir periyodik gözden geçirme takvimi oluşturun. Beyan edilen tedbirlerin (erişim yetkilendirme, şifreleme, loglama) sahada gerçekten uygulandığından emin olun.

5. Yurt dışı aktarımda yetersiz koruma sağlamak

Verilerin yurt dışındaki bir bulut sağlayıcısında tutulması, KVKK'nın en hassas alanlarından biridir. Birçok kurum, sunucusu yurt dışında olan bir SaaS aracını kullanırken aktarımın hukuki zeminini hiç değerlendirmez. 2024'te yürürlüğe giren yeni aktarım rejimiyle birlikte, yeterlilik kararı bulunan ülkelere aktarım, uygun güvenceler (standart sözleşme hükümleri / SCC, bağlayıcı şirket kuralları / BCR, taahhütname) ve sınırlı arızi haller için istisnalar şeklinde kademeli bir çerçeve oluşmuştur.

Doğru yaklaşım: Her yurt dışı aktarım için önce bir aktarım etki değerlendirmesi (TIA) yapın, hedef ülkenin koruma düzeyini, sağlayıcının teknik tedbirlerini ve veri kategorisinin hassasiyetini değerlendirin. Uygun güvenceyi (SCC/BCR/taahhütname) belgeleyin ve gerekli hallerde Kurul'a bildirin. Aktarılan veriyi mümkünse uçtan uca şifreleyin, anahtar yönetimini kendi kontrolünüzde tutun ve veri yerelleştirme seçeneklerini değerlendirin.

6. Veri sorumlusu / veri işleyen ayrımını ve DPA'yı atlamak

Bir bordro firması, bulut sağlayıcısı ya da çağrı merkezi ile çalışırken, tarafların KVKK'daki rollerinin belirsiz bırakılması ciddi bir sorumluluk boşluğu yaratır. Veri sorumlusu işleme amaç ve vasıtalarını belirleyen taraftır. Veri işleyen ise sorumlunun talimatıyla veri işleyendir. Bu ayrım yapılmadan ve aradaki ilişki yazılı bir sözleşmeyle düzenlenmeden çalışmak, ihlal anında kimin neyden sorumlu olduğunu belirsizleştirir.

Doğru yaklaşım: Her tedarikçiyle veri işleyen sözleşmesi (DPA) imzalayın. DPA, işleyenin yalnızca talimatla hareket edeceğini, asgari teknik-idari tedbirleri uygulayacağını, gizlilik yükümlülüğünü, alt işleyen kullanımını, ihlal durumunda derhal bildirim yükümlülüğünü ve sözleşme sonunda verilerin imhası/iadesini açıkça düzenlemelidir. Tedarikçilerin güvenlik olgunluğunu periyodik olarak (denetim hakkı, sızma testi raporu talebi) doğrulayın.

7. İhlal bildirim sürecini kâğıt üzerinde bırakmak

Birçok kurumda bir veri ihlali müdahale prosedürü vardır. Ancak bu prosedür gerçek bir kriz anında işlemez. KVKK, ihlali öğrendiğiniz andan itibaren en kısa sürede ve 72 saat içinde Kurul'a bildirim yapmanızı bekler, etkilenen ilgili kişilere de makul sürede bildirim gerekir. Pratikte sorun, ihlalin tespit edildiği teknik ekip ile bildirimi yapacak hukuk/uyum ekibi arasındaki köprünün hiç kurulmamış olmasıdır. Loglar yetersizse, ihlalin kapsamı ve etkilenen kayıt sayısı 72 saat içinde tespit bile edilemez.

Doğru yaklaşım: Olay müdahale (IR) sürecinizi KVKK bildirim yükümlülüğüyle entegre edin. İhlali kimin nasıl tespit edeceğini, kimin sınıflandıracağını, hukukun ne zaman devreye gireceğini ve bildirimin kim tarafından yapılacağını net rollerle tanımlayın. Yeterli loglama ve izleme altyapısı kurun ki ihlalin kapsamı hızla belirlenebilsin. En önemlisi, bu süreci yılda en az bir kez masaüstü tatbikatla (tabletop exercise) deneyin. 72 saatlik süre ilk kez gerçek olayda değil, provada test edilmelidir.

Hızlı kontrol listesi

• Veri envanteriniz otomatik keşifle besleniyor ve sistem değişikliklerinde güncelleniyor mu?
• Aydınlatma metinleriniz her temas noktası için bağlamsal ve somut mu?
• Her işleme faaliyeti için doğru hukuki sebebi belirlediniz mi? Açık rızayı yalnızca gerçekten gerektiğinde mi alıyorsunuz?
• VERBİS kaydınız envanterle senkron ve güncel mi?
• Yurt dışı aktarımlar için TIA yaptınız ve uygun güvenceyi (SCC/BCR/taahhütname) belgelediniz mi?
• Tüm tedarikçilerle imzalı bir DPA var mı? Roller (sorumlu/işleyen) net mi?
• İhlal bildirim süreciniz 72 saatlik hedefe göre tatbikatla test edildi mi?
• Şifreleme, erişim kontrolü, loglama ve düzenli sızma testi gibi teknik tedbirler idari tedbirlerle birlikte uygulanıyor mu?

Raze yaklaşımı

Raze Security olarak KVKK uyumunu tek seferlik bir belge teslimi olarak değil, teknik ve idari tedbirlerin birlikte yönetildiği sürekli bir süreç olarak ele alıyoruz. Veri envanterinin çıkarılmasından aydınlatma ve rıza mimarisinin doğru kurgulanmasına, yurt dışı aktarım değerlendirmelerinden tedarikçi DPA'larına ve ihlal müdahale tatbikatlarına kadar tüm halkaları, erişim kontrolü, şifreleme, loglama ve düzenli sızma testleriyle destekleyerek bütünleştiriyoruz. Böylece uyum kâğıt üzerinde kalmıyor, gerçek bir güvenlik olgunluğuna dönüşüyor.

Kurumunuzun KVKK uyum olgunluğunu uçtan uca değerlendirmek ve bu yedi hatadan kaçınmak için KVKK uyum çözümümüzü inceleyebilir veya doğrudan bizimle iletişime geçebilirsiniz.

Fidye yazılımı saldırıları artık tekil, fırsatçı olaylar değil. Profesyonelleşmiş, iş bölümüne dayalı bir yeraltı ekonomisinin ürünü. DFIR (dijital adli analiz ve olay müdahale) ekibimiz son dönemde sahada gördüğü vakalarda, saldırganların hem teknik hem de operasyonel olarak ne kadar olgunlaştığına bizzat tanık oldu. Bu yazıda 2026 yılına girerken müdahale ettiğimiz olaylardan damıttığımız trendleri, hangi giriş noktalarının istismar edildiğini ve savunma tarafında neyin gerçekten fark yarattığını saha notları tonuyla paylaşıyoruz. Amacımız korku yaymak değil. Karşı tarafın oyun kitabını anlaşılır kılarak savunmanızı doğru yere konumlandırmanıza yardımcı olmak.

Başlangıç erişimi: kapı hâlâ aynı yerlerden açılıyor

Müdahale ettiğimiz vakaların büyük çoğunluğunda saldırganlar sıfırıncı gün bir açıktan değil, bilinen ve önlenebilir zayıflıklardan içeri girdi. Saha gözlemlerimizde tekrar tekrar karşımıza çıkan başlangıç erişimi yöntemleri şunlar:

• Oltalama ve sosyal mühendislik: Kötü amaçlı ek veya bağlantı içeren e-postalar, sahte giriş sayfaları ve son dönemde artan biçimde MFA yorgunluğu (push bombardımanı) ile çok faktörlü doğrulamanın aşılması.
• İnternete açık RDP ve VPN servisleri: Halka açık şekilde dinleyen Uzak Masaüstü ve zayıf yapılandırılmış VPN portalları, kaba kuvvet ve kimlik bilgisi püskürtme (password spraying) saldırılarına davetiye çıkarıyor.
• Yamasız edge ve VPN cihazları: Güvenlik duvarları, VPN ağ geçitleri ve diğer çevre cihazlarındaki yamalanmamış zafiyetler, kimlik doğrulaması bile gerektirmeden ağa giriş sağlayabiliyor. Bu cihazlar genellikle gözden kaçan kör noktalar.
• Çalınmış kimlik bilgileri: Bilgi hırsızı (infostealer) zararlıları ile toplanan oturum çerezleri ve parolalar, yeraltı pazarlarında alınıp satılıyor. Geçerli bir hesapla giren saldırgan birçok savunma katmanını sessizce atlayabiliyor.

Bu yöntemlerin ortak paydası, artık ayrı bir uzmanlık dalı hâline gelmiş olan başlangıç erişimi aracıları (initial access broker) ekosistemi. Bir aktör ağa giriyor, erişimi kataloglayıp satıyor. Fidye operatörü ise bu hazır erişimi satın alarak doğrudan saldırının sonraki aşamalarına geçiyor. Bu iş bölümü, saldırıların hem hızını hem de ölçeğini artırıyor.

Çifte ve üçlü haraç: artık sadece şifreleme değil

Birkaç yıl öncesine kadar fidye yazılımının tek kaldıracı verilerin şifrelenmesiydi. Sağlam bir yedeğiniz varsa pazarlık gücünüz yüksekti. Bugün durum farklı. Sahada gördüğümüz olayların neredeyse tamamında saldırganlar şifrelemeden önce veriyi sızdırıyor ve bunu ikinci bir baskı aracı olarak kullanıyor. Bu çifte haraç modelinde, yedekten geri dönseniz bile çalınan hassas verilerin ifşa edilme tehdidi masada kalıyor.

Üçlü haraç ise baskıyı bir adım öteye taşıyor:

• Sızdırılan verideki müşteri, hasta veya iş ortağı bilgileriyle üçüncü taraflara doğrudan baskı uygulanması.
• Pazarlık sürecinde DDoS saldırılarıyla kurumun çevrimiçi servislerinin baltalanması.
• Düzenleyici kurumlara, basına veya etkilenen bireylere ihbar tehdidi ile itibar ve uyum baskısının artırılması.

Bu çok katmanlı baskı, olay müdahalesini yalnızca teknik bir kurtarma operasyonu olmaktan çıkarıp hukuk, iletişim ve üst yönetimin eşgüdümünü gerektiren bir kriz yönetimine dönüştürüyor.

RaaS ve affiliate modeli: suçun franchise'laşması

Fidye yazılımı dünyasının en belirleyici yapısal değişimi hizmet olarak fidye yazılımı (Ransomware-as-a-Service) modeli. Bu modelde bir çekirdek ekip zararlı yazılımı, şifreleme altyapısını, sızıntı sitesini ve pazarlık panellerini geliştirip işletiyor. Affiliate adı verilen ortaklar ise bu araçları kullanarak saldırıları gerçekleştiriyor ve elde edilen fidyeyi belirli bir oran üzerinden paylaşıyor.

Bu yapının savunma açısından iki önemli sonucu var. Birincisi, teknik beceri eşiği düşüyor. Karmaşık zararlı geliştiremeyecek aktörler bile hazır araçlarla büyük zarar verebiliyor. İkincisi, aynı fidye ailesini kullanan farklı ortaklar çok farklı taktik, teknik ve prosedürler (TTP) sergileyebiliyor. Bu yüzden tek bir grup adına veya tek bir imzaya odaklanan savunma yaklaşımı yetersiz kalıyor. Davranış temelli tespit kritik hâle geliyor.

Şifrelemesiz gasp: sadece sızdırma yeterli

Dikkat çeken bir başka eğilim, bazı aktörlerin şifreleme aşamasını tümüyle atlaması. Şifreleme operasyonel olarak gürültülüdür, tespit edilme ve müdahaleyle kesintiye uğrama riski taşır. Bunun yerine saldırganlar sessizce büyük hacimli veriyi sızdırıp yalnızca ifşa tehdidiyle gasp yapmayı tercih ediyor.

Bu yaklaşım, klasik fidye savunmasının temel taşı olan yedeklemenin tek başına yeterli olmadığının altını çiziyor. Verileriniz hiç şifrelenmese, sistemleriniz hiç kesintiye uğramasa bile, çalınan veri başlı başına bir kriz olabilir. Bu da savunmanın ağırlık merkezini kurtarmadan önleme ve veri sızıntısı tespitine doğru kaydırıyor.

Yanal hareket ve Active Directory'nin ele geçirilmesi

İçeri sızan saldırganın hedefi tek bir makine değil. Mümkün olan en geniş etki alanı. Sahada gözlemlediğimiz tipik akışta saldırgan, ilk eriştiği uç noktadan sonra şu adımları izliyor:

1. Yerel ve bellekte tutulan kimlik bilgilerini toplayarak (credential dumping) ayrıcalık yükseltme.
2. Ağ keşfi yaparak yüksek değerli sunucuları ve Active Directory altyapısını haritalama.
3. Etki alanı yöneticisi (Domain Admin) yetkilerini ele geçirerek kimlik altyapısının kontrolünü alma.
4. Grup ilkeleri (GPO) veya merkezi yazılım dağıtım araçları üzerinden fidye yükünü tüm filoya tek seferde dağıtma.

Active Directory'nin ele geçirilmesi, tek bir makinenin ele geçirilmesi ile tüm kurumun felç olması arasındaki çizgidir. Bu nedenle ayrıcalıklı hesapların korunması, tier modeli ile yönetim katmanlarının ayrılması ve etki alanı yöneticisi oturumlarının sıkı denetimi savunmanın bel kemiğini oluşturur.

Hedefleme yön değiştiriyor: KOBİ, tedarik zinciri ve kritik sektörler

Büyük kurumların savunmaları güçlendikçe ve dikkat çeken saldırılar daha fazla soruşturma baskısı getirdikçe, aktörlerin bir kısmı odağını kaydırdı. Sahada gözlemlediğimiz eğilimler:

• KOBİ'ler: Sınırlı güvenlik bütçesi ve ekibi olan orta ölçekli işletmeler, görece kolay hedefler olarak öne çıkıyor.
• Tedarik zinciri: Tek bir yönetilen hizmet sağlayıcı (MSP) veya yazılım tedarikçisinin ele geçirilmesi, onun üzerinden çok sayıda müşteriye erişim anlamına geliyor. Bu çarpan etkisi saldırganlar için son derece cazip.
• Sağlık ve kamu: Hizmet kesintisinin tahammül edilemez olduğu bu sektörlerde fidye ödeme baskısı yüksek, bu da onları öncelikli birer hedef hâline getiriyor.

Hız: ilk erişimden şifrelemeye kalan süre kısalıyor

Belki de en kritik trend, saldırı zaman çizelgesinin dramatik biçimde kısalması. Eskiden bir saldırganın ağda haftalarca dolaştığını görürken, bugün ilk erişimden veri sızdırma ve şifrelemeye kadar geçen sürenin saatlere indiği vakalarla karşılaşıyoruz. Otomasyon, hazır araç setleri ve satın alınmış başlangıç erişimi bu hızı mümkün kılıyor.

Bu hız, savunma stratejisini doğrudan etkiliyor: günlerce sonra incelenen kayıtlara değil, gerçek zamanlı tespit ve otomatik yanıt yeteneğine ihtiyaç var. EDR/XDR çözümlerinin yalnızca kurulu olması yetmez. Uyarıların 7/24 izlenmesi ve hızlı müdahale edilmesi gerekir. Saldırgan dakikalar içinde hareket ediyorsa, savunmanın da o tempoyu yakalaması şart.

Savunma: temelleri sağlam, katmanları derin tutmak

İyi haber şu ki, sahada gördüğümüz başarılı saldırıların büyük kısmı egzotik tekniklerle değil, ihmal edilen temel kontrollerle gerçekleşiyor. Doğru uygulanmış temel hijyen, saldırganın işini çok zorlaştırıyor. Önceliklendirdiğimiz savunma katmanları:

• Dayanıklı ve izole yedekler: 3-2-1 kuralı (üç kopya, iki farklı ortam, biri çevrimdışı/ağdan izole). Değiştirilemez (immutable) yedekler ve düzenli geri yükleme testleri olmazsa olmaz.
• Her yerde MFA: Özellikle VPN, RDP, e-posta ve ayrıcalıklı hesaplarda, mümkün olduğunda kimlik avına dayanıklı (FIDO2 gibi) yöntemler.
• EDR/XDR ve sürekli izleme: Davranış temelli tespit ve 7/24 SOC desteğiyle erken müdahale.
• Ağ segmentasyonu: Düz (flat) ağlar yanal hareketi kolaylaştırır. Kritik sistemleri ve yönetim ağlarını ayırmak yayılmayı sınırlar.
• Yama yönetimi: Özellikle internete açık edge/VPN cihazlarına öncelik veren, hızlı ve disiplinli bir süreç.
• En az ayrıcalık ilkesi: Gereksiz yönetici hesaplarının kaldırılması, ayrıcalıklı erişimin sıkı denetimi.
• Olay müdahale hazırlığı: Yazılı bir plan, net roller ve düzenli masaüstü tatbikatlar (tabletop) ile kriz anında reflekslerin hazır olması.

Hızlı kontrol listesi

1. İnternete açık tüm RDP, VPN ve yönetim arayüzlerini envantere alın, gereksiz olanları kapatın, kalanları MFA arkasına alın.
2. Edge ve VPN cihazlarının yama durumunu kontrol edin, bilinen kritik zafiyetleri öncelikli kapatın.
3. Yedeklerinizin en az bir kopyasının çevrimdışı/değiştirilemez olduğunu doğrulayın ve geri yükleme testi yapın.
4. Tüm ayrıcalıklı hesaplarda ve uzaktan erişimde MFA'nın aktif olduğunu teyit edin.
5. EDR/XDR uyarılarının 7/24 izlendiğinden ve müdahale eşiğinin tanımlı olduğundan emin olun.
6. Active Directory'de Domain Admin sayısını azaltın, tier modeli ve ayrıcalıklı erişim yönetimi uygulayın.
7. Ağı segmentlere ayırın, kritik sunucuları ve yönetim ağını kullanıcı ağından izole edin.
8. Olay müdahale planınızı güncel tutun ve yılda en az bir kez tatbikat yapın.

Raze yaklaşımı

Raze Security olarak bu trendlere yalnızca rapor okuyarak değil, sahada bizzat olaylara müdahale ederek tanık oluyoruz. Yaklaşımımız, saldırganın oyun kitabını tersine çevirmek üzerine kurulu: en sık istismar edilen giriş noktalarını kapatmak, yanal hareketi zorlaştıran katmanlı bir savunma kurmak ve en kötü senaryoya hazırlıklı olmak. Müdahale ettiğimiz her vakadan çıkardığımız dersleri, kurumların önleme ve hazırlık çalışmalarına dönüştürüyoruz.

Bir olayla karşı karşıyaysanız ya da kurumunuzun fidye yazılımına karşı dayanıklılığını değerlendirmek istiyorsanız, olay müdahale hizmetimizi inceleyebilir veya doğrudan bizimle iletişime geçebilirsiniz. Saldırgan hızlanırken, hazırlıklı olmak en güçlü savunmadır.

Türkiye, siber güvenliği ilk kez müstakil bir kanunla düzenledi. Telefonlar çalmaya başladı: "Bu kanun bizi kapsıyor mu? Ne yapmamız gerekiyor? Ceza riski ne?" Bu yazıda kanunun getirdiği çerçeveyi, kimleri kapsadığını ve bir şirketin bugünden atması gereken somut adımları (hukuk diliyle boğmadan, uygulanabilir bir yol haritası olarak) ele alıyoruz.

Neden ayrı bir kanuna ihtiyaç duyuldu?

Bugüne kadar siber güvenlik, KVKK, sektörel düzenlemeler (BDDK, EPDK, BTK) ve çeşitli tebliğlerin arasına dağılmış parçalı bir alandı. Kritik altyapıların artan tehdit yüzeyi, fidye yazılımı saldırılarının kamu hizmetlerini durduracak boyuta gelmesi ve ulusal bir koordinasyon ihtiyacı, bütüncül ve bağlayıcı bir çerçeveyi zorunlu hale getirdi. Yeni kanun bu boşluğu doldurmayı, yetkiyi merkezileştirip yükümlülükleri netleştirmeyi hedefliyor.

1. Kanun esas olarak neyi düzenliyor?

Kanunun omurgası üç başlıkta toplanıyor:

• Merkezi bir otorite: Ulusal siber güvenlik politikalarını belirleyen, düzenleme yapma ve denetleme yetkisine sahip merkezi bir yapı (Siber Güvenlik Başkanlığı) kuruluyor. Bu otorite ikincil mevzuatla (yönetmelik, tebliğ) detayları belirleyecek. Yani kanun metni kadar, çıkacak yönetmelikleri de takip etmek gerekiyor.
• Yükümlülükler rejimi: Kapsamdaki kuruluşlar için güvenlik tedbirleri, olay bildirimi, denetim ve bilgi paylaşımı zorunlulukları tanımlanıyor.
• Yaptırımlar: İdari para cezalarından ağır suçlar için hapis cezalarına kadar uzanan bir yaptırım skalası getiriliyor. (Spesifik ceza tutarları ve süreler için kanunun güncel metni ve ikincil mevzuat esas alınmalıdır.)

2. Bu kanun beni kapsıyor mu?

En kritik soru bu. Kapsam tipik olarak şu halkalardan oluşuyor:

• Kamu kurum ve kuruluşları.
• Kritik altyapı işletmecileri: enerji, finans/bankacılık, elektronik haberleşme (telekom), su, ulaştırma, sağlık gibi bir kesintinin toplumsal/ekonomik düzeni etkileyeceği sektörler.
• Bu kuruluşlara hizmet/ürün veren tedarikçiler: Doğrudan kritik altyapı olmasanız bile, onlara yazılım, bulut, danışmanlık veya operasyon hizmeti veriyorsanız sözleşmesel olarak yükümlülük zincirine dahil olabilirsiniz.

Pratik öneri: "Kapsamda değiliz" kararını varsayım üzerine değil, belgelenmiş bir kapsam (applicability) değerlendirmesi üzerine verin. Denetimde "neden kapsamda olmadığınızı" gösterebilmeniz gerekir.

3. Temel yükümlülükler

Kapsamdaki kuruluşlar için öne çıkan başlıklar:

• Güvenlik tedbirlerini almak ve sürdürmek: Asgari teknik ve idari kontroller: erişim yönetimi, kayıt/izleme, güvenlik testleri, varlık ve risk yönetimi.
• Olay bildirimi: Siber olayların yetkili merciye, belirlenen süre ve formatta bildirilmesi. (KVKK'nın 72 saatlik ihlal bildirimine benzer bir operasyonel olgunluk gerektirir.)
• Denetime tabi olmak: Hem iç hem de otoritenin yürüteceği denetimlere hazır olmak. Kanıt ve kayıtları sunabilmek.
• Yerli/millî çözüm ve veri konumu tercihleri: Belirli kritik sistemlerde yerli ürün ve yurt içi veri tutma yönünde beklentiler gündeme gelebilir.
• Bilgi paylaşımı: Tehdit istihbaratı ve olay verilerinin ulusal koordinasyon için paylaşılması.

4. Yaptırımlar: neden ciddiye alınmalı?

Kanun, caydırıcılığı yüksek bir yaptırım skalası öngörüyor: kurallara uymayan kuruluşlar için idari para cezaları (kimi düzenlemelerde ciroya/gelire endekslenebilen), izinsiz faaliyetler ve kritik sistemlere yönelik ağır eylemler için ise hapis cezaları gündemde. Buradaki kritik nokta şu: ceza riski yalnızca bir "uyumsuzluk faturası" değil. Bir olay anında kurumun sorumluluğunu ağırlaştıran bir çarpan. (Net tutar ve süreler için güncel kanun metni esas alınmalı.)

5. Diğer mevzuatla ilişkisi: tekrar değil, katmanlı uyum

Yaygın bir yanılgı: "Zaten KVKK ve ISO 27001 var, bu da onun aynısı." Değil. Bunlar örtüşen ama farklı amaçlı katmanlar:

• KVKK kişisel veriyi korur. Bu kanun ulusal/kritik altyapı güvenliğini hedefler.
• ISO 27001 gönüllü bir yönetim sistemi çerçevesidir. Bu kanun bağlayıcı bir yasal yükümlülüktür.
• BDDK/EPDK gibi sektörel düzenlemeler kendi alanlarında devam eder. Yeni kanun bunların üzerine ulusal bir şemsiye ekler.

İyi haber: ISO 27001 veya sektörel uyum altyapınız varsa, yeni yükümlülüklerin önemli kısmını mevcut kontrollerinizi eşleyerek (mapping) karşılayabilirsiniz, sıfırdan başlamazsınız.

6. Şirketler bugün ne yapmalı? (Hazırlık yol haritası)

1. Kapsam değerlendirmesi: Kanunun ve ikincil mevzuatın sizi (ve tedarik zincirinizi) kapsayıp kapsamadığını belgeleyin.
2. Boşluk analizi (gap assessment): Mevcut kontrollerinizi beklenen yükümlülüklerle karşılaştırın, farkı çıkarın.
3. Güvenlik kontrollerini olgunlaştırın: Varlık envanteri, erişim yönetimi, log/izleme, düzenli sızma testi ve zafiyet yönetimi.
4. Olay müdahale ve bildirim sürecini kurun: Tespit→değerlendirme→bildirim akışını süreye uygun şekilde tatbik edin.
5. Tedarik zincirini dahil edin: Sözleşmelere güvenlik ve bildirim maddeleri ekleyin. Üçüncü tarafları değerlendirin.
6. Denetime hazır olun: Politikalar, kayıtlar ve kanıtları denetlenebilir biçimde tutun.
7. Yönetmelikleri takip edin: Asıl detaylar ikincil mevzuatta gelecek. Bir takip mekanizması kurun.

Hızlı kontrol listesi

• Kanunun bizi kapsayıp kapsamadığını belgeledik mi?
• Yükümlülüklere karşı bir boşluk analizi yaptık mı?
• Düzenli sızma testi ve zafiyet yönetimi programımız var mı?
• Olay bildirim sürecimiz tanımlı ve tatbik edilmiş mi?
• Tedarikçi sözleşmelerinde güvenlik/bildirim maddeleri var mı?
• Denetime sunulacak kayıt ve kanıtlar hazır mı?
• İkincil mevzuatı takip eden bir sorumlu/süreç belirledik mi?

Raze yaklaşımı

Mevzuat uyumunu bir "belge dosyalama" işi değil, denetlenebilir bir güvenlik programı olarak ele alıyoruz. Kapsam değerlendirmesi ve boşluk analiziyle başlıyor. Sızma testi, zafiyet yönetimi ve olay müdahale yetkinliklerini kurumunuza entegre ediyor. Denetime hazır bir kanıt zinciriyle tamamlıyoruz. Zafiyet yönetimi ve uyum çözümlerimizi inceleyebilir veya bizimle iletişime geçebilirsiniz.

Bu yazı genel bilgilendirme amaçlıdır. Hukuki danışmanlık yerine geçmez. Kanunun güncel metni ve ikincil mevzuat esas alınmalıdır.

Sızma testi sözleşmesini imzalamadan önce verilen tek bir kararın testin sonucunu baştan sona belirlediğini çoğu yönetici fark etmez: saldırgan ekibe ne kadar bilgi ve erişim vereceğiniz. Aynı sistem üzerinde, hiçbir şey bilmeyen bir ekiple yapılan test ile kaynak koda ve mimari dokümana sahip bir ekiple yapılan test, tamamen farklı sonuçlar üretir. Black box, grey box ve white box olarak adlandırılan bu üç yaklaşım birbirinin alternatifi değil. Her biri farklı bir soruya cevap verir. Doğru olanı seçmek, bütçenizi ve test süresini en yüksek değeri üretecek yere odaklamak demektir.

Temel ayrım: Saldırgana verilen bilgi seviyesi

Üç yaklaşımı ayıran tek değişken, test ekibine sağlanan ön bilgi ve erişim derecesidir. Bu değişken bir spektrum oluşturur: bir uçta hiçbir şey bilmeyen, dışarıdan saldıran bir aktör, diğer uçta sistemin tüm iç detaylarına hâkim bir denetçi vardır.

• Black box: Ekip yalnızca hedefin adını ya da IP aralığını bilir. İç yapı, kaynak kod ve hesap bilgisi verilmez.
• Grey box: Ekibe sınırlı bilgi verilir. Tipik olarak standart bir kullanıcı hesabı, kısmi mimari bilgisi veya API dokümantasyonu.
• White box: Ekip kaynak koda, mimari diyagramlarına, yapılandırma dosyalarına ve yönetici düzeyinde erişime sahip olur.

Bu üç yaklaşım arasındaki gerilim aslında iki temel ihtiyaç arasındaki dengedir: gerçekçilik (bir saldırı ne kadar gerçekçi simüle ediliyor) ile kapsam ve derinlik (sınırlı sürede ne kadar çok ve ne kadar derin zafiyet bulunabiliyor).

Black box: Gerçek saldırgan simülasyonu

Black box testte ekip, tıpkı internet üzerindeki bilinmeyen bir saldırgan gibi, sıfır iç bilgiyle başlar. Önce keşif (recon) yapar, açık portları ve servisleri haritalar, ardından dışarıdan görünen saldırı yüzeyini istismar etmeye çalışır. Bu yöntemin en güçlü yanı gerçekçiliğidir: dışarıdan bakan bir tehdit aktörünün gerçekte ne görebileceğini ve istismar edebileceğini en doğru biçimde gösterir.

Artıları: Gerçek dünya saldırısına en yakın senaryo, dış saldırı yüzeyini ve görünür ifşaları net ortaya koyar. İç bilgiye dayanmadığı için sonuçlar tarafsızdır.

Eksileri: Süre büyük ölçüde keşif aşamasına harcanır, bu da derinliği azaltır. Yetkilendirme katmanlarının arkasındaki zafiyetler, iç servisler ve ulaşılamayan kod yolları kör nokta olarak kalır. Aynı bütçeyle daha az kapsam taranabilir. Bulunamayan bir zafiyet, var olmadığı anlamına gelmez.

White box: Kaynak kod erişimiyle maksimum derinlik

White box testte ekip, savunma tarafının sahip olduğu her şeye erişir: kaynak kod, mimari, yapılandırmalar ve ayrıcalıklı hesaplar. Bu, ekibin tahmin etmek yerine doğrulamasını sağlar, istismar zincirlerini koddaki tam satırına kadar takip edebilir. Statik kod analizi ile dinamik testi birleştiren bu yaklaşım en yüksek kapsam ve derinliği sunar.

Artıları: İş mantığı hataları, kötü kriptografi kullanımı, gizli arka kapılar ve derin yetki yükseltme yolları gibi black box'ta neredeyse görünmez olan zafiyetleri ortaya çıkarır. Her bulgu kök nedenine kadar izlenebilir. Sınırlı süre keşfe değil, gerçek istismara harcanır.

Eksileri: Gerçek bir dış saldırganın bilgi seviyesini simüle etmez, dolayısıyla saldırının fizibilitesi konusunda yanıltıcı olabilir. Kaynak kod paylaşımı kurumsal ve hukuki hassasiyet gerektirir. Bulgu yoğunluğu yüksek olduğu için triyaj ve önceliklendirme yükü artar.

Grey box: Dengeli orta yol

Grey box, spektrumun ortasında durur ve pratikte en sık tercih edilen yaklaşımdır. Ekibe genellikle standart bir kullanıcı hesabı ve kısmi mimari bilgisi verilir. Bu, "kimlik bilgileri sızmış ya da kötü niyetli bir iç kullanıcı" senaryosunu modeller, ki bu gerçek ihlallerin büyük kısmının başlangıç noktasıdır.

Artıları: Keşif aşamasında zaman kaybetmeden, doğrudan yetkilendirme sonrası saldırı yüzeyine odaklanır. Gerçekçilik ile derinlik arasında en verimli dengeyi kurar. Aynı bütçeyle black box'a göre daha fazla anlamlı zafiyet bulma olasılığı yüksektir.

Eksileri: Ne tam bir dış saldırgan simülasyonu, ne de white box'ın eksiksiz kod görünürlüğüdür. Verilen erişimin seviyesi sonucu doğrudan etkilediği için kapsamın baştan net tanımlanması kritiktir.

Maliyet, süre ve değer dengesi

Bilgi seviyesi arttıkça, ekibin boşa harcadığı süre azalır. Black box'ta sürenin önemli bir kısmı keşfe gider ve bu süre doğrudan zafiyet bulgusuna dönüşmeyebilir. Grey ve white box'ta keşif yükü hafiflediği için aynı gün sayısı daha fazla gerçek test çalışmasına dönüşür. Yani birim maliyet başına bulunan zafiyet sayısı genellikle artar. Ancak white box, kaynak kod inceleme uzmanlığı ve daha geniş analiz gerektirdiği için toplam efor ve dolayısıyla maliyet açısından çoğunlukla en yüksek seçenektir. Karar, "en ucuzu hangisi" değil, "bütçemi nereye koyarsam en yüksek riski en hızlı düşürürüm" sorusudur.

Bir karar çerçevesi

Doğru yaklaşımı seçmek için testin amacını netleştirmekle başlayın. Aşağıdaki sıralı sorular sizi doğru seçeneğe yönlendirir:

1. Amaç ne? Gerçek bir dış saldırıya dayanıklılığı ölçmek istiyorsanız black box, sistemi olabildiğince kapsamlı sertleştirmek istiyorsanız white box, gerçekçi bir tehdit modelinde maksimum verim istiyorsanız grey box.
2. Hangi tehdit aktörünü modelliyorsunuz? Anonim dış saldırgan mı, sızmış kimlik bilgisine sahip bir aktör mü, yoksa kötü niyetli bir içeriden mi endişeleniyorsunuz?
3. Sistem ne kadar kritik? Finansal, sağlık veya kritik altyapı uygulamalarında white box'ın derinliği genellikle zorunluluktur.
4. Olgunluk seviyeniz ne? İlk testini yaptıran bir kurum için grey box hızlı ve yüksek getirili bir başlangıçtır. Olgun bir güvenlik programı white box'a ihtiyaç duyar.

Hızlı kontrol listesi

• İnternete açık bir uygulamanın dışarıdan ne kadar dirençli olduğunu görmek istiyorsanız: black box.
• Bir tehdit aktörünün medyada görünür ifşalardan ne çıkarabileceğini test ediyorsanız: black box.
• Kayıtlı bir kullanıcının ya da sızmış bir hesabın sisteme ne kadar zarar verebileceğini ölçüyorsanız: grey box.
• Sınırlı bütçeyle en yüksek gerçekçi kapsamı istiyorsanız: grey box.
• Yeni geliştirilen ya da yüksek kritikliğe sahip bir uygulamayı tüm derinliğiyle sertleştiriyorsanız: white box.
• İş mantığı, kriptografi veya yetkilendirme katmanını koda kadar doğrulamak istiyorsanız: white box.
• Mevzuat ya da uyumluluk en kapsamlı incelemeyi gerektiriyorsa: white box.
• Hangisinden emin değilseniz ve dengeli bir başlangıç arıyorsanız: grey box.

Raze yaklaşımı

Raze Security olarak hiçbir testi tek bir kalıba zorlamıyoruz. Önce sizinle birlikte tehdit modelinizi, sistemin kritikliğini ve güvenlik olgunluğunuzu netleştiriyor. Ardından kapsamı, bilgi seviyesini ve eforu bu hedeflere göre tasarlıyoruz. Çoğu kurum için pratikte en yüksek getiriyi grey box ile başlayıp kritik bileşenlerde white box derinliğine inen hibrit bir kurgu sağlar. TSE A seviye onaylı ekibimiz, hangi yaklaşımı seçerseniz seçin, her bulguyu kök nedenine kadar izleyen ve uygulanabilir bir çözüm yol haritası sunan bir rapor üretir.

Kuruluşunuz için doğru yaklaşımı birlikte belirlemek ve kapsamı netleştirmek üzere sızma testi hizmetimizi inceleyebilir, sorularınız için bizimle iletişime geçebilirsiniz.

Modern uygulamaların kalbinde artık tek parçalı sunucular değil, birbirleriyle ve mobil/web istemcilerle sürekli konuşan API'ler var. Bu mimari hız ve esneklik getirdi. Ancak beraberinde geleneksel güvenlik araçlarının çoğunlukla göremediği yepyeni bir saldırı yüzeyi de getirdi. Bir saldırgan için API, iş mantığınıza giden en doğrudan kapıdır: tahmin edilebilir uç noktalar, yapılandırılmış JSON yanıtları ve genellikle zayıf yetkilendirme kontrolleri. Bu yazıda API'lerin neden ayrı bir disiplin gerektirdiğini, OWASP API Security Top 10 (2023) listesinin en kritik başlıklarını gerçekçi istismar senaryolarıyla ve her biri için somut savunma önerileriyle ele alıyoruz.

API'ler Neden Ayrı Bir Saldırı Yüzeyidir?

Geleneksel web uygulama güvenliği büyük ölçüde sunucu tarafında üretilen HTML'i, form gönderimlerini ve oturum tabanlı akışları korumak üzere tasarlandı. API'ler bu varsayımların çoğunu kırar. İstemci tarafı (mobil uygulama, SPA, üçüncü taraf entegrasyon) iş mantığının büyük bölümünü taşır ve sunucuya doğrudan, ayrıştırılmış istekler gönderir. Bu da saldırganın hangi nesneye, hangi kaynağa ve hangi fonksiyona eriştiğini istek seviyesinde manipüle etmesini kolaylaştırır.

WAF neden yetmez? Geleneksel WAF'lar imza tabanlıdır. SQL injection veya XSS gibi sözdizimsel saldırı kalıplarını yakalamakta iyidir. Oysa API zafiyetlerinin çoğu iş mantığı ve yetkilendirme sorunlarıdır. GET /api/orders/124 isteği teknik olarak tamamen "temiz" ve geçerli bir HTTP isteğidir. WAF için bunda anormal hiçbir şey yoktur. Ancak o sipariş başka bir kullanıcıya aitse, bu istek ciddi bir veri sızıntısıdır. Bağlam ve kimlik olmadan yetkilendirme ihlallerini ağ katmanından tespit etmek neredeyse imkansızdır. İşte bu yüzden API güvenliği, uygulamanın kendisinde, kod ve tasarım seviyesinde ele alınmalıdır.

BOLA (API1): Nesne Seviyesi Yetkilendirme İhlali

Broken Object Level Authorization, OWASP listesinin bir numarasıdır ve sebepsiz değil: API ihlallerinin en yaygın ve en yüksek etkili nedenidir. Klasik IDOR'un (Insecure Direct Object Reference) API dünyasındaki karşılığıdır. Sorun, uç noktanın kimlik doğrulamasını yapması ama o kullanıcının istenen nesneye sahip olup olmadığını kontrol etmemesidir.

İstismar senaryosu: Bir e-ticaret uygulamasında giriş yapmış kullanıcı kendi faturasını GET /api/v1/invoices/4471 ile görüntüler. Saldırgan kimliği yalnızca ID'yi değiştirerek (4470, 4469...) art arda dener ve başka müşterilerin fatura, adres ve sipariş bilgilerine erişir. Sayaç mantığıyla ilerleyen ID'ler, tüm veri tabanını otomatik araçlarla "kazımayı" mümkün kılar.

Savunma: Her nesne erişiminde, oturumdaki kullanıcının o kaynağa sahipliğini sunucu tarafında doğrulayın (örneğin WHERE id = ? AND owner_id = current_user). Tahmin edilemez tanımlayıcılar (UUID) kullanmak yardımcı olur ama tek başına bir savunma değildir. Asıl çözüm yetkilendirme kontrolünün her uç noktada merkezî ve tutarlı uygulanmasıdır.

Broken Authentication (API2)

Kimlik doğrulama mekanizmaları API'lerde sıklıkla hatalı uygulanır: zayıf JWT doğrulaması, süresi dolmayan veya iptal edilemeyen token'lar, kaba kuvvet (brute force) korumasından yoksun giriş ve şifre sıfırlama uç noktaları, ya da kimlik bilgilerini istek gövdesinde açıkça taşıyan akışlar.

İstismar senaryosu: Bir API, JWT imza algoritmasını istemciden gelen başlıktaki değere göre kabul ediyorsa, saldırgan alg alanını none yaparak veya simetrik/asimetrik anahtar karışıklığını kötüye kullanarak kendi imzaladığı geçerli bir token üretebilir ve istediği kullanıcının kimliğine bürünebilir. Bir başka yaygın senaryo, OTP veya giriş uç noktasında hız sınırının olmaması nedeniyle hesapların kaba kuvvetle ele geçirilmesidir.

Savunma: JWT doğrulamasında algoritmayı sunucu tarafında sabitleyin, güçlü gizli anahtarlar ve kısa ömürler kullanın. Tüm kimlik akışlarına hız sınırlama ve hesap kilitleme ekleyin. Mümkün olan her yerde olgun, denetlenmiş bir kimlik standardı (OAuth 2.0 / OIDC) tercih edin, kimlik doğrulamayı kendiniz baştan yazmaktan kaçının.

BOPLA (API3): Özellik Seviyesi Yetkilendirme

Broken Object Property Level Authorization, iki eski riski (Excessive Data Exposure ve Mass Assignment) birleştirir. Sorun nesnenin tamamına değil, tekil özelliklerine erişim kontrolündedir.

• Aşırı veri ifşası: API, bir kullanıcı nesnesini dönerken tüm sütunları (parola hash'i, dahili roller, e-posta) JSON'a koyar ve filtrelemeyi istemciye bırakır. Saldırgan ham yanıtta bu alanları okur.
• Mass assignment: Profil güncelleme uç noktası gelen JSON'u doğrudan modele bağlar. Saldırgan istek gövdesine "role":"admin" veya "isVerified":true alanını ekleyerek yetkilerini yükseltir.

Savunma: Giren ve çıkan veride açık beyaz liste (allow-list) yaklaşımı kullanın. Yanıtları yalnızca gerekli alanları içeren DTO/serializer'larla şekillendirin, gelen istekte yalnızca istemcinin değiştirmesine izin verilen alanları kabul edin.

BFLA (API5): Fonksiyon Seviyesi Yetkilendirme

Broken Function Level Authorization, bir kullanıcının erişmemesi gereken fonksiyonları/eylemleri çağırabilmesidir. BOLA "hangi veriye" sorusuyla ilgilenirken, BFLA "hangi işlemi" sorusuyla ilgilenir.

İstismar senaryosu: Normal bir kullanıcı, yönetim panelinin yalnızca arayüzde gizlenmiş ama API'de korunmamış uç noktalarını keşfeder. GET /api/users sıradan kullanıcılara kapalıyken, DELETE /api/admin/users/55 veya POST /api/admin/promote gibi uç noktalar yetki kontrolü yapmadığı için doğrudan çağrılabilir ve saldırgan yönetici işlevlerini gerçekleştirir.

Savunma: Yetkilendirmeyi "varsayılan olarak reddet" (deny by default) ilkesiyle kurun. Yönetici ve ayrıcalıklı uç noktaları rol tabanlı kontrolle merkezî bir katmanda koruyun. Güvenliği istemci arayüzünde menü gizlemeye değil, sunucu tarafı kontrole dayandırın.

Unrestricted Resource Consumption (API4) ve SSRF (API7)

Sınırsız kaynak tüketimi (API4), hız sınırı, sayfalama veya boyut limiti olmayan uç noktaların kötüye kullanılmasıdır. Saldırgan, sayfa başına binlerce kayıt isteyerek, ağır sorguları tekrarlayarak ya da SMS/e-posta gönderen uç noktaları tetikleyerek hem servis kesintisine hem de doğrudan maliyet artışına yol açabilir.

Server-Side Request Forgery (SSRF, API7) ise API'nin istemciden aldığı bir URL'i doğrulamadan sunucu tarafında çağırmasıyla ortaya çıkar.

İstismar senaryosu: "URL'den resim içe aktar" özelliği olan bir uç nokta, kullanıcının verdiği adrese sunucudan istek atar. Saldırgan bu adresi bulut sağlayıcının metadata servisine (http://169.254.169.254/) yönlendirerek geçici kimlik bilgilerini veya iç ağdaki servisleri hedefleyebilir.

Savunma: Tüm uç noktalara hız sınırı, sayfalama ve istek boyutu/karmaşıklık limitleri uygulayın. SSRF'e karşı istemciden gelen URL'leri katı bir beyaz listeyle doğrulayın, iç IP aralıklarına çıkışı engelleyin ve mümkünse dışa giden istekleri ayrı, kısıtlı bir ağ segmentinden yapın.

REST ve GraphQL Notu

Buradaki risklerin hemen tamamı protokolden bağımsızdır. BOLA, BFLA ve BOPLA hem REST hem GraphQL API'lerini aynı şekilde etkiler. Ancak GraphQL kendine özgü bazı riskler de getirir: tek bir sorguda iç içe ilişkileri derinlemesine çağırarak (deeply nested queries) sunucuyu yoran sorgu karmaşıklığı saldırıları, ve introspection açıkken tüm şemanın saldırgana ifşa olması. GraphQL'de hız sınırını uç nokta yerine sorgu derinliği ve maliyet analizi üzerinden kurmak, üretimde introspection'ı kapatmak ve alan/çözücü (resolver) seviyesinde yetkilendirme uygulamak kritik öneme sahiptir.

Hızlı kontrol listesi

• Her nesne erişiminde sunucu tarafında sahiplik ve yetki kontrolü yapılıyor mu? (BOLA)
• Kimlik doğrulama OAuth 2.0 / OIDC gibi olgun standartlara mı dayanıyor. JWT algoritması sunucuda sabit mi?
• Yanıtlar DTO/serializer ile filtreleniyor, gelen istekler beyaz liste ile mass assignment'a karşı korunuyor mu? (BOPLA)
• Yönetici ve ayrıcalıklı uç noktalar deny-by-default rol kontrolüyle korunuyor mu? (BFLA)
• Tüm uç noktalarda hız sınırı, sayfalama ve istek boyutu limitleri var mı? (Kaynak tüketimi)
• Sunucu tarafı dış istekler beyaz listeyle doğrulanıp iç ağa erişim engelleniyor mu? (SSRF)
• GraphQL'de introspection üretimde kapalı, sorgu derinliği/maliyeti sınırlı mı?
• API envanteri güncel mi? Eski sürümler (/v1) ve test uç noktaları ifşa olmuş durumda mı?

Raze yaklaşımı

API güvenliği, otomatik tarayıcıların yüzeysel geçtiği ama gerçek riskin saklı olduğu bir alandır. Çünkü BOLA ve BFLA gibi zafiyetler iş mantığını ve yetkilendirme bağlamını anlamayı gerektirir. Raze Security olarak API testlerimizi yalnızca araç çıktısına değil, çoklu kullanıcı rolleriyle manuel yetkilendirme analizine, iş mantığı senaryolarına ve gerçek istismar denemelerine dayandırırız. OWASP API Security Top 10'u bir kontrol listesi olarak değil, derinlemesine bir metodolojinin başlangıç noktası olarak ele alırız.

API yüzeyinizin gerçek dünyada nasıl istismar edilebileceğini görmek istiyorsanız, uzman ekibimizin yürüttüğü sızma testi hizmetimizi inceleyebilir veya ihtiyaçlarınızı görüşmek için bizimle iletişime geçebilirsiniz.

Cuma günü, mesai bitimine yakın. Muhasebe ekibinden bir uzman, CFO'dan gelen bir e-posta alır: "Stratejik bir satın alma görüşmesi nihayete erdi, gizlilik kritik. Aşağıdaki hesaba bugün içinde acil ödeme yapılmalı, detayları kimseyle paylaşma." E-posta CFO'nun gerçek imza bloğunu taşımaktadır, dil tonu doğaldır, hatta önceki bir yazışmaya yanıt olarak gelmiştir. Uzman, otoriteye duyduğu saygı ve aciliyet baskısıyla ödemeyi başlatır. Hiçbir güvenlik duvarı alarm vermez, hiçbir antivirüs devreye girmez. Çünkü saldırgan sistemleri değil, insanı hedef almıştır. Bu senaryo, kurumsal kayıpların en hızlı büyüyen kategorilerinden biri olan BEC (Business Email Compromise / İş E-postası Ele Geçirme) saldırılarının tipik bir örneğidir.

Teknik kontroller olgunlaştıkça, saldırganlar en zayıf ve en öngörülemez katmana yöneliyor: insan. Bu yazıda, sosyal mühendisliğin anatomisini, arkasındaki ikna psikolojisini ve çalışanlarınızı "en zayıf halka" olmaktan çıkarıp "insan güvenlik duvarına" dönüştürecek katmanlı bir yaklaşımı ele alıyoruz.

Sosyal mühendislik neden bu kadar etkili?

Modern kurumlar güvenlik duvarları, EDR çözümleri, çok faktörlü kimlik doğrulama (MFA) ve düzenli yama yönetimine ciddi yatırımlar yapıyor. Bu yatırımlar teknik saldırı yüzeyini gerçekten daraltıyor. Ancak hiçbir teknik kontrol, ikna edilmiş bir çalışanın bilinçli olarak attığı adımı kolayca durduramaz. Bir kullanıcı kimlik bilgisini gönüllü olarak teslim ettiğinde, bir ödeme talebini onayladığında ya da bir eki çalıştırdığında, saldırgan çoğu teknik bariyeri meşru bir kullanıcı kimliğiyle aşar. Saldırganlar için insan, kırılması en pahalı şifreden çok daha düşük maliyetli bir hedeftir.

Saldırı türlerini tanımak

Sosyal mühendislik tek bir teknik değil, geniş bir saldırı ailesidir. En sık karşılaşılan türler:

• Oltalama (Phishing): Geniş kitleye gönderilen, meşru görünen sahte e-postalarla kimlik bilgisi veya zararlı yazılım yayma amacı taşıyan toplu saldırılar.
• Hedefli oltalama (Spear Phishing): Belirli bir kişiye ya da departmana özel olarak hazırlanmış, kurban hakkında toplanan bilgilerle kişiselleştirilmiş ve bu nedenle çok daha inandırıcı saldırılar.
• CEO dolandırıcılığı / BEC: Üst yönetim ya da finans yetkilisi kimliğine bürünerek acil para transferi veya hassas veri talep eden, genellikle zararlı bağlantı içermediği için teknik filtreleri kolayca atlatan saldırılar.
• Vishing (Sesli oltalama): Telefon aracılığıyla, örneğin BT destek ekibi ya da banka çalışanı gibi davranarak kurbandan bilgi veya işlem onayı koparmaya çalışan yöntem.
• Smishing (SMS oltalaması): Kısa mesaj yoluyla gönderilen sahte kargo, banka ya da kampanya bildirimleriyle kullanıcıyı zararlı bağlantıya yönlendiren saldırılar.
• Fiziksel saldırılar: Yetkili biriymiş gibi kapıdan birlikte geçme (tailgating), ofis ortamına zararlı yazılım yüklü USB bellekler bırakma (USB drop) gibi gerçek dünya teknikleri.
• Pretexting (Bahane üretme): İnandırıcı bir senaryo ve sahte kimlik kurgulayarak kurbanın güvenini kazanma ve bu güveni bilgi sızdırmak için kullanma tekniği. Çoğu saldırının temelinde bu kurgu yatar.

İkna psikolojisi: saldırganın gerçek silahı

Sosyal mühendislik saldırıları, insan davranışındaki köklü psikolojik eğilimleri istismar eder. Saldırganların en sık kullandığı kaldıraçlar şunlardır:

• Otorite: İnsanlar üst düzey bir yöneticiden ya da resmi bir kurumdan geldiğine inandıkları talepleri sorgulamadan yerine getirme eğilimindedir.
• Aciliyet: "Hemen", "bugün içinde", "son şans" gibi baskı ifadeleri, kurbanın durup düşünmesini ve doğrulama yapmasını engeller.
• Kıtlık: Sınırlı bir fırsatın ya da kaybedilecek bir şeyin varlığı hissi, hızlı ve dikkatsiz karar almayı tetikler.
• Güven: Tanıdık bir marka, bilinen bir meslektaş ya da yardımsever bir ton, kurbanın savunmasını düşürür.

Bu ilkeler birbirinden bağımsız değildir. Başarılı bir saldırı genellikle birkaçını aynı anda kullanır. Açılıştaki BEC senaryosunda otorite (CFO), aciliyet (bugün içinde) ve güven (gerçek imza bloğu) bir arada devreye girmiştir.

AI ve deepfake ile yükselen yeni tehdit

Yapay zekâ, sosyal mühendisliğin oyun kurallarını değiştiriyor. Üretken yapay zekâ araçları, kötü dil bilgisi ya da garip ifadeler gibi geleneksel "oltalama işaretlerini" ortadan kaldırıyor. Artık kusursuz, akıcı ve hedefe göre kişiselleştirilmiş metinler saniyeler içinde üretilebiliyor. Daha da endişe verici olan, deepfake ses ve görüntü teknolojileri. Bir yöneticinin sesini taklit eden sahte telefon görüşmeleri ya da canlı video konferanslarda sahte kimlikler, "kendi gözlerimle gördüm, kendi kulaklarımla duydum" güvenini bile silah haline getiriyor. Bu da doğrulamanın artık tek bir kanala (sesi tanıdım, yüzü gördüm) güvenemeyeceği anlamına geliyor.

Neden tek başına eğitim yetmez?

Birçok kurum sosyal mühendisliği "bir farkındalık eğitimi düzenleyip geçilecek" bir kutu olarak görür. Oysa yılda bir kez izlenen bir sunum, gerçek bir saldırı anındaki refleksleri kalıcı olarak değiştirmez. Bilgi ile davranış arasında büyük bir fark vardır: çalışanlar oltalamanın ne olduğunu "bildiği" halde, iyi kurgulanmış bir saldırıya yine de kanabilir. Üstelik insan davranışı asla yüzde yüz güvenilir bir kontrol değildir. En eğitimli ekip bile yorgun, dikkati dağılmış ya da baskı altında bir günde hata yapabilir. Bu yüzden eğitim gerekli ama tek başına yeterli değildir. Onu sürekli pekiştirme, ölçüm ve teknik destek katmanlarıyla sarmalamak gerekir.

Katmanlı savunma: insanı güçlendirmenin yolu

Etkili bir savunma, sorumluluğun tamamını çalışanın omuzlarına yüklemez. İnsanı destekleyen ve hatasının etkisini sınırlayan katmanlar inşa eder:

1. Teknik kontrol katmanı: SPF, DKIM ve DMARC ile e-posta sahteciliğinin önlenmesi, gelişmiş e-posta filtreleme, MFA ve en az ayrıcalık ilkesi. Bu katman, çalışana ulaşan saldırı sayısını ve başarılı bir aldatmanın olası etkisini azaltır.
2. Süreç katmanı: Para transferleri ve hassas veri talepleri için ikinci kanaldan doğrulama (geri arama), çift onay ve net eskalasyon yolları. İyi bir süreç, "acil" baskısını nötralize eder.
3. İnsan katmanı: Düzenli ve rol bazlı eğitimin yanı sıra kontrollü simülasyonlar. Gerçekçi oltalama, vishing ve fiziksel sızma simülasyonları, çalışana güvenli bir ortamda gerçek bir saldırıyı deneyimletir. Teorik bilgiyi kalıcı bir refleks haline dönüştürür.

Simülasyonların amacı çalışanı "yakalamak" ve cezalandırmak değildir. Amaç, kurumdaki gerçek zayıf noktaları ölçmek, eğitimi bu verilere göre hedeflemek ve raporlama kültürünü güçlendirmektir. Bir saldırıyı fark edip bildiren çalışan, bir alarm sensörüdür. Bu davranış cezalandırma değil takdir görmelidir. İşte çalışanın "zayıf halka"dan "insan güvenlik duvarına" dönüştüğü kırılma noktası tam olarak burasıdır.

Hızlı kontrol listesi

• Para transferi ve hassas veri talepleri için ikinci kanaldan doğrulama (geri arama) zorunlu bir süreç haline getirildi mi?
• E-posta alan adınızda SPF, DKIM ve DMARC kayıtları doğru yapılandırıldı mı?
• Tüm kritik sistemlerde ve uzaktan erişimde çok faktörlü kimlik doğrulama (MFA) aktif mi?
• Çalışanlara yönelik düzenli ve rol bazlı farkındalık eğitimleri veriliyor mu?
• Yılda en az birkaç kez gerçekçi oltalama ve vishing simülasyonları yapılıyor mu?
• Şüpheli e-posta ve aramaları bildirmek için kolay ve cezalandırmayan bir raporlama mekanizması var mı?
• Deepfake ve sesli dolandırıcılığa karşı, "tanıdık ses/yüz" tek başına yeterli sayılmayacak şekilde çok kanallı doğrulama kuralları tanımlandı mı?
• Fiziksel güvenlik (tailgating, ziyaretçi yönetimi, başıboş USB belleklere karşı politika) saldırı senaryolarınıza dahil mi?

Raze yaklaşımı

Raze Security olarak sosyal mühendisliğe tek seferlik bir test ya da bir farkındalık sunumu olarak değil, ölçülebilir ve sürekli bir program olarak yaklaşıyoruz. Gerçekçi oltalama kampanyaları, hedefli spear phishing, telefonla vishing ve fiziksel sızma senaryolarıyla kurumunuzun gerçek dayanıklılığını güvenli bir ortamda ölçüyor. Sonuçları somut metriklerle raporluyor ve eğitimi bu verilere göre hedefliyoruz. Amacımız çalışanlarınızı suçlamak değil, onları kurumunuzun en güçlü savunma katmanına dönüştürmektir.

Kurumunuzun insan katmanındaki dayanıklılığını ölçmek ve güçlendirmek için sosyal mühendislik testi hizmetimizi inceleyebilir, dilediğiniz zaman bizimle iletişime geçebilirsiniz.

Bulut altyapısına geçen kurumların çoğu, güvenliği büyük oranda bulut sağlayıcısına devrettiğini düşünür. Oysa gerçek tam tersidir: AWS, Azure ve GCP üzerinde yaşanan ihlallerin ezici çoğunluğu sağlayıcının altyapısındaki bir zafiyetten değil, müşterinin kendi tarafındaki yanlış yapılandırmadan kaynaklanır. Herkese açık unutulmuş bir depolama alanı, fazla geniş bir IAM izni ya da kapalı bir log servisi, bunların hiçbiri klasik anlamda bir "exploit" gerektirmez. Saldırgan zaten açık bırakılmış kapıdan girer.

Bu yazıda paylaşılan sorumluluk modelini netleştirip, üç büyük bulut sağlayıcısında en sık karşılaştığımız yanlış yapılandırmaları, bunların yarattığı riski ve pratik savunma yöntemlerini ele alıyoruz. Hedef kitlemiz bulut ve DevOps ekipleri ile güvenlik yöneticileri.

Paylaşılan sorumluluk modeli: Yanlış anlaşılan sözleşme

Her üç sağlayıcı da paylaşılan sorumluluk modeli (shared responsibility) uygular. Kabaca özetlersek: sağlayıcı bulutun güvenliğinden (fiziksel veri merkezi, hipervizör, ağ omurgası, yönetilen servislerin altyapısı) sorumludur. Müşteri ise buluttaki güvenlikten (kimlik ve erişim yönetimi, veri sınıflandırma ve şifreleme, ağ kuralları, işletim sistemi yamaları, uygulama güvenliği) sorumludur.

Sorumluluk sınırı servis tipine göre kayar. IaaS (örneğin EC2, Azure VM, GCE) modelinde işletim sistemi yaması, ağ kuralları ve erişim tamamen size aittir. PaaS ve SaaS modelinde sağlayıcı daha fazlasını üstlenir, ancak veriniz, kimlik yapılandırmanız ve erişim politikalarınız her zaman sizin sorumluluğunuzdadır. Bu sınırı bilmemek, en yaygın ihlal sebebidir.

1. Herkese açık depolama alanları

En klasik ve en çok manşete çıkan hata budur. Yanlış izinlerle yapılandırılmış bir Amazon S3 bucket, Azure Blob Storage container ya da Google Cloud Storage kovası, kimlik doğrulaması olmadan tüm internete açılabilir. Yedekler, müşteri verileri, loglar ve hatta gizli anahtarlar bu şekilde sızar.

• Risk: İnternetten anonim okuma/yazma erişimi, veri ihlali, fidye ve marka itibarı kaybı.
• Savunma: AWS'de hesap genelinde S3 Block Public Access açın, Azure'da depolama hesabında anonymous public access seçeneğini kapatın, GCS'de uniform bucket-level access ve public access prevention uygulayın. Erişimi her zaman IAM/SAS tabanlı, en az ayrıcalıkla verin.

2. Aşırı geniş IAM izinleri ve uzun ömürlü anahtarlar

Kimlik, bulutun yeni çevre güvenliğidir. *:* benzeri tam yetkili politikalar, gereğinden fazla izne sahip servis hesapları ve hiç rotasyon görmeyen uzun ömürlü erişim anahtarları, tek bir sızıntıyı tüm ortamın ele geçirilmesine dönüştürür.

• Risk: Sızan tek bir anahtarla yetki yükseltme (privilege escalation) ve yanal hareket, tüm hesabın devralınması.
• Savunma: En az ayrıcalık ilkesini uygulayın. AWS'de statik anahtar yerine IAM Roles ve geçici STS kimlik bilgileri, GCP'de Workload Identity Federation, Azure'da Managed Identity kullanın. Kullanılmayan izinleri AWS Access Analyzer / IAM Access Advisor ile tespit edip kaldırın, anahtarları düzenli rotasyona alın.

3. Açık güvenlik grupları ve yönetim portları

Ağ kurallarının 0.0.0.0/0 ile tüm internete açılması, özellikle SSH (22) ve RDP (3389) portlarında, kaba kuvvet ve otomatik tarama saldırılarına davetiyedir. AWS Security Group, Azure Network Security Group ve GCP firewall kuralları en sık bu şekilde gevşek bırakılır.

• Risk: Açık yönetim portlarına sürekli brute-force, veritabanı portlarının (3306, 5432, 27017) internete açık kalması ile doğrudan veri sızıntısı.
• Savunma: Yönetim erişimini bastion host, AWS Systems Manager Session Manager, Azure Bastion ya da kimlik tabanlı bir zero-trust ağ katmanı arkasına alın. Kaynak IP'leri daraltın, veritabanlarını yalnızca özel alt ağlarda tutun.

4. Şifreleme ve loglama eksiklikleri

İki kontrol genellikle birlikte ihmal edilir. Şifreleme tarafında veri durağan halde (at rest) ya da aktarım sırasında (in transit) açık kalır. Loglama tarafında ise olayları görecek hiçbir kayıt tutulmaz.

• Şifreleme savunması: Durağan veride KMS tabanlı şifrelemeyi varsayılan yapın (AWS KMS, Azure Key Vault, Google Cloud KMS). Aktarımda TLS'i zorunlu kılın, S3'te aws:SecureTransport koşuluyla HTTP'yi reddedin.
• Loglama savunması: AWS'de tüm bölgelerde CloudTrail, Azure'da Activity Log ve Microsoft Defender for Cloud, GCP'de Cloud Audit Logs açık olmalı. Logları değiştirilemez (immutable) ayrı bir hesapta toplayın ve anormallikler için alarm kurun. Görmediğiniz olaya müdahale edemezsiniz.

5. MFA olmayan ayrıcalıklı hesaplar

Kök (root) ya da global yönetici hesaplarının yalnızca parolayla korunması ciddi bir risktir. AWS root kullanıcısı, Azure Global Administrator ve GCP Organization Admin hesapları tek bir kimlik bilgisi sızıntısıyla ele geçirilebilir.

• Risk: Tüm tenant/hesap üzerinde geri dönüşü zor, sınırsız erişim.
• Savunma: Tüm ayrıcalıklı hesaplarda MFA'yı zorunlu kılın, tercihen donanım/FIDO2 anahtarı. AWS root kullanıcısını günlük işlerde hiç kullanmayın. Azure'da Conditional Access ve Privileged Identity Management ile yükseltilmiş yetkiyi süreli (just-in-time) verin.

6. Korunmasız metadata servisi ve yönetim panelleri

Bir uygulamada SSRF (Server-Side Request Forgery) zafiyeti varsa, saldırgan örnek metadata servisine (IMDS) ulaşıp geçici kimlik bilgilerini çalabilir. Bu, geçmişteki büyük çaplı bir bulut ihlalinin de temel mekanizmasıydı. Benzer şekilde Kubernetes dashboard, veritabanı yönetim arayüzleri gibi paneller internete açık bırakıldığında doğrudan giriş kapısı olur.

• Risk: SSRF üzerinden kimlik bilgisi hırsızlığı, açık yönetim panellerinden doğrudan ele geçirme.
• Savunma: AWS'de IMDSv2'yi (oturum tabanlı, token zorunlu) tüm örneklerde zorunlu kılın. GCP ve Azure metadata uç noktalarına erişimi uygulama düzeyinde kısıtlayın. Yönetim panellerini asla halka açmayın. VPN/bastion arkasına alın.

7. Yamasız ve halka açık yönetilen hizmetler

Yönetilen veritabanları (RDS, Azure SQL, Cloud SQL), Elasticsearch/OpenSearch kümeleri ve container imajları, güncel yamalarla ve özel ağda tutulmadığında saldırı yüzeyini büyütür. "Yönetilen" olması, yapılandırma sorumluluğunu sizden almaz.

• Risk: Bilinen CVE'lerin sömürülmesi, internete açık kümelerden toplu veri sızıntısı.
• Savunma: Otomatik yama pencerelerini etkinleştirin, herkese açık erişimi kapatın, özel uç noktalar (private endpoint / VPC peering) kullanın. Container tarafında imaj taraması ve güncel temel imaj politikası uygulayın.

CSPM ve süreç: Tek seferlik değil sürekli

Bu yanlış yapılandırmalar elle bir kez düzeltilse bile, hızlı değişen bulut ortamlarında yenileri sürekli oluşur. Burada CSPM (Cloud Security Posture Management) devreye girer: ortamı standartlara (CIS Benchmark gibi) göre sürekli tarayıp sapmaları raporlar. AWS Security Hub, Azure Defender for Cloud ve GCP Security Command Center bu işlevi yerel olarak sağlar.

Aynı şekilde altyapı kod ile (Terraform, CloudFormation, Bicep) tanımlanıyorsa, güvenliği dağıtımdan önce kaydırın: IaC tarama araçlarıyla (Checkov, tfsec, Trivy) yanlış yapılandırmaları daha CI/CD aşamasında yakalayın. Hatayı üretime çıkmadan önce durdurmak en ucuz savunmadır.

Hızlı kontrol listesi

• Hesap genelinde herkese açık depolama erişimini engelleyin (Block Public Access / public access prevention).
• En az ayrıcalık uygulayın. Statik anahtarları rol/federasyon tabanlı geçici kimliklerle değiştirin.
• SSH/RDP ve veritabanı portlarını internete kapatın, yönetim erişimini bastion/zero-trust arkasına alın.
• Durağan ve aktarım halindeki tüm veride şifrelemeyi varsayılan ve zorunlu yapın.
• CloudTrail / Activity Log / Cloud Audit Logs'u tüm bölgelerde açın ve değiştirilemez şekilde saklayın.
• Tüm root ve yönetici hesaplarında MFA'yı, tercihen FIDO2 ile zorunlu kılın.
• AWS'de IMDSv2'yi zorunlu kılın, yönetim panellerini halka açmayın.
• Yönetilen hizmetlerde otomatik yamayı açın, özel uç noktalar kullanın, IaC ve container'ı CI/CD'de tarayın.

Raze yaklaşımı

Raze Security olarak bulut güvenliğini bir ürün değil, sürekli bir disiplin olarak ele alıyoruz. Konfigürasyon denetimi, en az ayrıcalık tasarımı, kimlik ve ağ mimarisinin gözden geçirilmesi ve CSPM süreçlerinin kurulmasıyla yanlış yapılandırma kaynaklı riskleri kalıcı olarak azaltıyoruz. Saldırgan bakış açısıyla yaptığımız değerlendirmelerde, açık bırakılmış kapıları siz fark etmeden önce biz buluyoruz.

AWS, Azure ve GCP ortamınızın güvenlik duruşunu baştan sona değerlendirmek için bulut ve konteyner güvenliği hizmetimizi inceleyebilir, ihtiyaçlarınızı konuşmak için bizimle iletişime geçebilirsiniz.

Finans sektörü, siber suçluların gözünde en cazip hedeflerin başında gelir. Bunun nedeni basit ama acımasızdır: bir banka ya da fintech ihlali, saldırgan için doğrudan paraya, ödeme altyapısına ve milyonlarca insanın kimlik ve finansal verisine erişim anlamına gelir. Diğer sektörlerde veri sızıntısı bir itibar sorunuyken, finansta aynı olay anında dolandırıcılık zinciri, regülatör yaptırımı ve operasyonel kesinti olarak geri döner. Bu yazıda banka ve fintech kuruluşlarının karşı karşıya olduğu tehdit manzarasını, Türkiye ve uluslararası düzenleyici çerçeveyi ve sürekli güvenlik testinin bu denklemdeki kritik rolünü ele alıyoruz.

Finans neden bir numaralı hedef?

Saldırganlar yatırım getirisine göre hareket eder ve finans sektörü iki değerli varlığı aynı çatı altında barındırır: para ve veri. Bir e-ticaret sitesinin çalınan müşteri listesi karaborsada değer kaybederken, çalınan banka hesabı kimlik bilgileri anında nakde çevrilebilir. Üstelik finansal kuruluşlar yoğun şekilde dijitalleşmiş, birbirine bağlı ve üçüncü taraflara bağımlı bir ekosistemde çalışır.

Bu durum saldırı yüzeyini genişletir: mobil bankacılık uygulamaları, internet şubeleri, API'ler, ödeme ağ geçitleri, ATM ağları, çağrı merkezleri ve sayısız tedarikçi entegrasyonu. Her bağlantı noktası, bir saldırgan için potansiyel bir giriş kapısıdır. Ek olarak finansal hizmetlerin kesintisiz olması beklenir, bir saatlik kesinti bile ciddi finansal ve itibari kayıp doğurduğundan, saldırganlar bu baskıyı (özellikle fidye ve DDoS senaryolarında) bir kaldıraç olarak kullanır.

Tehdit manzarası: nelerle mücadele ediyorsunuz?

Finans sektörüne yönelik tehditler tek tip değildir. Finansal motivasyonlu organize gruplardan, gelişmiş kalıcı tehdit (APT) aktörlerine kadar geniş bir yelpazeye yayılır. Öne çıkan başlıklar şunlardır:

• Hesap ele geçirme (ATO): Çalınmış kimlik bilgileri, kimlik bilgisi doldurma (credential stuffing) ve SIM swap gibi tekniklerle müşteri hesaplarının ele geçirilmesi. Zayıf veya atlatılabilen çok faktörlü kimlik doğrulama (MFA) bu saldırıları kolaylaştırır.
• Kimlik avı ve BEC: Hedefli oltalama ve iş e-postası ele geçirme (Business Email Compromise) ile çalışanların ya da müşterilerin kandırılması, sahte havale talimatları en pahalı sonuçları doğuran vektörlerden biridir.
• Dolandırıcılık (fraud): Gerçek zamanlı ödeme sistemlerinin (örneğin anlık transferlerin) kötüye kullanımı, sosyal mühendislikle yönlendirilen yetkilendirilmiş ödeme dolandırıcılığı.
• API ve open banking riskleri: Bozuk nesne seviyesi yetkilendirme (BOLA/IDOR), zayıf kimlik doğrulama ve aşırı veri ifşası.
• Üçüncü taraf ve tedarik zinciri: Ödeme sağlayıcıları, KYC servisleri ve yazılım bağımlılıkları üzerinden dolaylı erişim.
• Fidye yazılımı: Veri şifrelemenin yanında sızdırma tehdidiyle çifte gasp, operasyonel sürekliliği doğrudan hedef alır.
• DDoS: İnternet şubesi ve ödeme servislerini erişilemez hale getirerek hem itibar zedeleme hem de başka saldırıları perdeleme amacı.
• ATM ve ödeme sistemleri: Kart kopyalama, ATM kötü amaçlı yazılımları ve POS/ödeme switch katmanına yönelik saldırılar.

Open banking ve API güvenliği: yeni cephe

Açık bankacılık (open banking) modeli, müşterinin onayıyla finansal verilerin üçüncü taraf sağlayıcılarla API'ler üzerinden paylaşılmasını mümkün kılar. Bu, inovasyon için güçlü bir kaldıraç olsa da güvenlik açısından yeni bir cephe açar. API'ler artık birçok finansal kuruluşun en büyük saldırı yüzeyidir ve klasik web uygulaması savunmaları bu katmanı tek başına korumaya yetmez.

En sık görülen sorunlar arasında bozuk nesne ve fonksiyon seviyesi yetkilendirme (bir kullanıcının başka bir müşterinin kaynağına erişebilmesi), zayıf token yönetimi, hız sınırlama eksikliği nedeniyle olanaklı hale gelen kaba kuvvet ve numaralandırma saldırıları, ve dokümante edilmemiş "gölge" API uç noktaları yer alır. Türkiye'de bankacılık ve ödeme servislerinin API entegrasyonları düzenleyici çerçeveye tabi olduğundan, bu uç noktaların hem güvenlik hem uyumluluk açısından düzenli olarak test edilmesi gerekir. API odaklı tehdit modellemesi ve yetkilendirme mantığının her uç noktada ayrı ayrı doğrulanması artık opsiyonel değildir.

Düzenleyici çerçeve: BDDK, SWIFT, PCI DSS ve KVKK

Finans sektörü, belki de en yoğun düzenlenmiş alandır. Türkiye'de ve uluslararası ölçekte uyulması gereken başlıca çerçeveler şunlardır:

• BDDK Bilgi Sistemleri Denetimi: Bankacılık Düzenleme ve Denetleme Kurumu, bankaların ve ilgili kuruluşların bilgi sistemleri ve elektronik bankacılık hizmetlerini düzenler. Bilgi sistemlerinin yönetimine ilişkin tebliğ kapsamında bağımsız denetim, sızma testi ve zafiyet yönetimi süreçleri beklenir.
• SWIFT CSP: SWIFT Müşteri Güvenlik Programı (Customer Security Programme), SWIFT ağına bağlı kuruluşlar için zorunlu ve tavsiye edilen kontrolleri (CSCF) tanımlar ve yıllık öz değerlendirme/bağımsız doğrulama gerektirir.
• PCI DSS: Kart sahibi verisini işleyen, saklayan veya ileten her kuruluş için geçerli olan Ödeme Kartı Endüstrisi Veri Güvenliği Standardı. Düzenli zafiyet taraması ve sızma testi gerektirir.
• KVKK: 6698 sayılı Kişisel Verilerin Korunması Kanunu, kişisel verilerin işlenmesi ve güvenliği için teknik ve idari tedbirleri zorunlu kılar, veri ihlallerinin Kurula bildirimi yükümlülüğü vardır.

Bu çerçeveler birbirinden bağımsız değildir. İyi tasarlanmış bir güvenlik programı, tek bir kontrol setiyle birden fazla yükümlülüğü karşılayacak şekilde kurgulanmalıdır. Uyumluluk bir bitiş çizgisi değil, sürekli sürdürülmesi gereken bir durumdur.

Uyumluluktan siber dayanıklılığa

Düzenleyici gerekliliklerin denetim listelerini karşılamak gerekli olsa da yeterli değildir. Modern finansal kuruluşların hedefi siber dayanıklılık olmalıdır: bir saldırı gerçekleştiğinde kritik hizmetleri sürdürebilme, hızlı tespit edip kuşatma altına alabilme ve kabul edilebilir sürede normale dönebilme yeteneği. Bu yaklaşım, "ihlal olmayacak" varsayımını terk eder ve "ihlal olduğunda ne kadar dayanabiliriz?" sorusunu merkeze koyar.

Operasyonel süreklilik, yedekleme ve geri yükleme stratejileri, olay müdahale planlarının düzenli tatbikatı, kritik sistemler için izolasyon ve segmentasyon, ve tedarikçi kesintilerine karşı plan B'ler ile sağlanır. Dayanıklılık bir kontrol değil, bir kültürdür.

Sürekli test, kırmızı takım ve zafiyet yönetimi

Yılda bir kez yapılan sızma testi, hızla değişen bir saldırı yüzeyi için yeterli değildir. Her yeni sürüm, her yeni API uç noktası ve her yeni entegrasyon, denetimden geçmemiş yeni riskler taşır. Bu nedenle finans sektöründe güvenlik testi sürekli bir disipline dönüşmelidir:

• Zafiyet yönetimi: Sürekli tarama, önceliklendirme ve giderme döngüsü, bulguların iş riskine göre sıralanması.
• Sürekli sızma testi: Önemli değişikliklerde tetiklenen, manuel derinliğe sahip testler.
• Kırmızı takım (red team): Gerçek saldırgan davranışını taklit ederek tespit ve müdahale (mavi takım) yeteneklerini sahada sınama, teknik açıkların ötesinde insan, süreç ve teknolojiyi bütünsel olarak değerlendirme.
• Sosyal mühendislik testleri: Oltalama ve BEC senaryolarına karşı insan faktörünün ölçülmesi.

Hızlı kontrol listesi

1. Müşteri ve yönetici hesaplarında atlatmaya dayanıklı, sağlam MFA uygulayın, ATO senaryolarını düzenli test edin.
2. Tüm API uç noktalarını envantere alın, "gölge" ve dokümante edilmemiş uç noktaları tespit edip yetkilendirme mantığını her uç noktada doğrulayın.
3. BDDK, SWIFT CSP, PCI DSS ve KVKK gerekliliklerini tek bir kontrol çerçevesinde haritalayın.
4. Üçüncü taraf ve tedarik zinciri risklerini sözleşmeden teknik denetime kadar düzenli değerlendirin.
5. Fidye yazılımına karşı izole, test edilmiş yedekler ve geri yükleme tatbikatları bulundurun.
6. İnternet şubesi ve ödeme servisleri için DDoS azaltma ve kapasite planı hazır tutun.
7. Olay müdahale planını masa başı tatbikatlarla yılda en az bir kez sınayın.
8. Sızma testini tek seferlik değil, sürekli zafiyet yönetimi ve periyodik kırmızı takım ile destekleyin.

Raze yaklaşımı

Raze Security olarak finans sektörünün hem düzenleyici baskıyı hem de gelişmiş tehdit aktörlerini aynı anda yönetmek zorunda olduğunu biliyoruz. TSE A seviye onaylı ekibimizle, sızma testi, kaynak kod analizi, kırmızı takım, zafiyet yönetimi, DDoS testi ve sosyal mühendislik testlerini bir araya getirerek banka ve fintech kuruluşlarına hem uyumluluğu sürdüren hem de gerçek dünya saldırılarına karşı dayanıklılığı artıran bütünsel bir program sunuyoruz. Amacımız, denetim listesini doldurmaktan öte, kuruluşunuzun bir saldırı anında ayakta kalma kapasitesini somut biçimde güçlendirmektir.

Finans sektörüne özel ihtiyaçlarınızı değerlendirmek için finansal hizmetler çözümümüzü inceleyebilir ya da kurumunuzun tehdit manzarasını birlikte ele almak için bizimle iletişime geçebilirsiniz.