ERP güvenliği 2026: Fidye yazılımı çeteleri neden artık ERP'yi hedef alıyor

Birkaç yıl öncesine kadar ERP güvenliği denince akla genelde kullanıcı yetkilendirmesi ve şifre politikası gelirdi. 2026'da tablo değişti. Bir işletmenin finans, tedarik, stok ve müşteri verisinin tamamı tek bir sistemde toplandığı için ERP, saldırganların gözünde artık arka plandaki bir muhasebe programı değil, tek noktadan en yüksek getiriyi sağlayan bir hedef. Yılın ilk sekiz ayında art arda açığa çıkan olaylar bunu somut biçimde gösterdi: dünyanın en büyük ERP vendorlarından ikisi, birkaç ay arayla ciddi güvenlik açıkları ve gerçek saldırılarla gündeme geldi.

Bu yazı tek bir vendor'ı hedef almıyor; tersine, farklı büyük ERP'lerde 2026'da yaşanan somut olayları yan yana koyup ortak örüntüyü ve işletmelerin ERP seçimi ya da yönetimi sırasında sorması gereken soruları tarafsız biçimde topluyor.

Neden ERP artık birinci sıra hedef

ERP'yi diğer kurumsal yazılımlardan ayıran şey, verinin yoğunluğu ve yetkili kullanıcı sayısının genişliği. Finans, satın alma, İK ve müşteri kayıtları aynı platformda birleştiğinde, tek bir sızma noktası saldırgana orantısız büyüklükte bir veri seti açar. Aynı zamanda ERP'ye erişimi olan kullanıcı sayısı — muhasebeden depo personeline kadar — geleneksel "sadece BT ekibi erişir" modelinden çok daha geniş; bu da kimlik avı (phishing) saldırıları için daha zengin bir hedef kitlesi anlamına geliyor. Üretim, lojistik ve sağlık gibi operasyonel süreci doğrudan ERP'ye bağlı sektörlerde bir kesinti, yalnızca veri kaybı değil üretim durması riski de taşıyor; bu da fidye ödeme baskısını artırıyor.

Oracle E-Business Suite: bir yılda iki ayrı ciddi olay

2026'nın en çok konuşulan ERP güvenlik olayı Oracle E-Business Suite (EBS) üzerinden yaşandı — Oracle'ın uzun süredir kurumsal pazarda yaygın olan, şirket içi/hibrit kurulan ERP paketi. Bu ürün, Oracle'ın güncel bulut hatları olan Oracle Fusion Cloud ERP ve Oracle NetSuite'tan ayrı, daha eski bir mimariye sahip; ama aynı vendor'ın kurumsal müşteri tabanının önemli bölümünü hâlâ oluşturuyor.

İlk olay Ağustos 2025'te başladı: Clop adlı fidye yazılımı/gasp grubu, EBS içindeki bir sıfır-gün açığını (CVE-2025-61882, CVSS 9,8) sessizce istismar ederek çok sayıda kurumun verisine erişti. Eylül 2025 sonundan itibaren Harvard Üniversitesi, Pennsylvania Üniversitesi, Dartmouth College, Washington Post, Logitech ve GlobalLogic gibi kurumların yöneticilerine "verilerinizi çaldık, ödemezseniz yayınlarız" içerikli gasp e-postaları gönderildi — klasik şifreleme yerine doğrudan çifte şantaj modeli.

İkinci olay 2026 yazında geldi. Oracle Payments'ın dosya aktarım bileşeninde bulunan yeni bir açık (CVE-2026-46817, CVSS 9,8) için Oracle Mayıs 2026'da zaten bir yama yayımlamıştı; buna rağmen Temmuz 2026 başında güvenlik araştırmacıları aktif istismar tespit etti. Shadowserver'ın taramasına göre o tarihte hâlâ yaklaşık 900-950 EBS kurulumu internete açık ve güncellenmemiş durumdaydı. Yani asıl sorun bu ikinci olayda bir yamanın olmaması değil, yamanın aylarca uygulanmamasıydı.

SAP tarafında: aylık yama döngüsü ve somut örnekler

SAP, güvenlik yamalarını her ayın belirli bir gününde toplu olarak yayımlıyor ("SAP Security Patch Day"). Mayıs 2026 döngüsünde toplam 15 açık kapatıldı; bunlar arasında SAP S/4HANA tarafında bir SQL enjeksiyonu açığı (CVE-2026-34260) ve SAP Commerce Cloud'da kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya izin veren bir yapılandırma hatası (CVE-2026-34263) yer aldı. Ayrı bir kaynakta belgelenen S/4HANA Financials açığı (CVE-2026-0501, CVSS 9,9) ise dikkat çekici bir özelliğe sahip: istismar için yönetici değil, sıradan bir kullanıcı hesabı yeterli — yani saldırganın önce ayrıcalık yükseltmesi yapmasına gerek kalmıyor.

Bu örnekler SAP'nin diğer ERP'lerden daha güvensiz olduğu anlamına gelmiyor; tam tersine SAP'nin düzenli, öngörülebilir bir yama takvimi olması ve bu takvimin kamuya açık biçimde belgelenmesi, sorunların görünürlüğünü artırıyor. Aylık yama döngüsü olmayan ya da güncellemelerini daha kapalı biçimde duyuran vendorlarda benzer sorunların yaşanmadığı değil, yalnızca daha az izlendiği anlamına gelebilir.

Tedarik zinciri riski: saldırı artık uygulamanın kendisiyle sınırlı değil

Nisan 2026'da ortaya çıkan "mini Shai-Hulud" saldırısı, ERP güvenliğinin sadece çalışan sistemle değil, o sistemi geliştiren araç zinciriyle de ilgili olduğunu gösterdi. 29 Nisan 2026'da, birkaç saatlik bir pencerede, SAP'nin Cloud Application Programming Model'inde (CAP) kullanılan dört npm paketinin (mbt, @cap-js/db-service, @cap-js/postgres, @cap-js/sqlite) kötü amaçlı sürümleri yayınlandı. Bu paketleri kuran geliştiricilerin makinelerinde çalışan bir betik; yerel geliştirici kimlik bilgilerini, GitHub ve npm token'larını, GitHub Actions sırlarını, AWS/Azure/GCP/Kubernetes bulut anahtarlarını ve tarayıcı kayıtlı şifrelerini topladı.

Bu tür bir saldırı, ERP'nin kendi güvenlik açığından değil, onu özelleştiren veya genişleten geliştirici ekosisteminden geliyor. Kurum içinde ERP'ye özel geliştirme yapan ya da dış bir entegrasyon ortağıyla çalışan işletmeler için önemli bir sonuç doğuruyor: ERP güvenliği artık yalnızca vendor'ın sorumluluğunda değil, o ERP'yi özelleştiren her tarafın yazılım tedarik zincirini de kapsıyor.

Ortak örüntü: sorun çoğunlukla yamanın yokluğu değil, gecikmesi

Üç olayı yan yana koyduğunda ortaya net bir örüntü çıkıyor.

Ortak sonuç: en büyük risk çoğunlukla vendor'ın yama üretmemesi değil, o yamanın işletme tarafında zamanında uygulanmaması. Bu da ERP güvenliğini bir "vendor sorunu" olmaktan çıkarıp, işletmenin kendi yama yönetimi disiplinine bağlı bir konu haline getiriyor.

Bulutta mı, şirket içinde mi: yama sorumluluğu nasıl değişiyor

Bu noktada kurulum modeli fark yaratıyor. Tam bulut/SaaS bir ERP'de yama genelde vendor tarafından otomatik uygulanır; müşterinin buna müdahale şansı sınırlıdır ama gecikme riski de düşer. Şirket içi (on-premise) veya hibrit kurulan bir ERP'de ise yamanın ne zaman uygulanacağına işletmenin kendi BT ekibi ya da iş ortağı karar verir — Oracle EBS örneğinde görüldüğü gibi, bu karar aylarca ertelenebiliyor. Bulut/SaaS ve şirket içi ERP karşılaştırmamızda bu farkın maliyet ve esneklik boyutunu ele almıştık; güvenlik boyutu da benzer bir değiş tokuşa dayanıyor: kontrolü elde tutmak isteyen işletme, yama sorumluluğunu da üstleniyor.

ERP güvenliği için pratik kontrol listesi

Yeni bir ERP değerlendiriyor ya da mevcut sistemi gözden geçiriyorsanız, aşağıdaki sorular vendor'dan bağımsız olarak sorulmalı:

• Vendor, güvenlik açıklarını hangi sıklıkla ve ne kadar açık biçimde duyuruyor? Düzenli bir yama takvimi var mı?
• Şirket içi/hibrit kurulumda yamayı kim, ne kadar sürede uygulamakla yükümlü — sözleşmede bu süre net mi, yoksa "makul süre" gibi belirsiz bir ifadeyle mi geçiştiriliyor?
• Kritik seviye bir açık (CVSS 9 ve üzeri) duyurulduğunda işletmenin kendi acil müdahale süreci var mı, yoksa bir sonraki bakım penceresini mi bekliyor?
• ERP'ye özel geliştirme ya da entegrasyon yapan iç ekip veya dış ortak, kullandığı paket/kütüphanelerin kaynağını (npm, pip, vb.) düzenli denetliyor mu?
• Çok faktörlü kimlik doğrulama, en azından finans ve yönetici yetkili hesaplarda zorunlu mu?
• Ağ tarafında ERP sunucusu, internete doğrudan açık mı yoksa VPN/segment arkasında mı; sektör bazlı ERP ihtiyaçlarını değerlendirirken üretim gibi operasyonel kesintiye duyarlı sektörlerde bu ayrım özellikle önemli.
• Yedekleme ve olay müdahale planı, fidye senaryosunda (veri şifrelenmiş + gasp tehdidi) test edilmiş mi?

Türkiye'deki işletmeler için pratik anlamı

Bu olayların hiçbiri Türkiye'ye özgü değil, ama sonucu bağlamsız değil. Türkiye'de kullanılan hem küresel (SAP, Oracle, Microsoft Dynamics) hem yerli (Logo, DİA, Mikro, Qera, Birasyo ve benzerleri) ERP'lerin güvenlik olgunluğu ve yama disiplini birbirinden farklı olabilir; bu platformda yer alan hiçbir vendor için kesin bir güvenlik notu vermiyoruz, çünkü bu tür bir değerlendirme her vendor'ın kendi güvenlik danışma sayfası ve son 12 aydaki kayıtları incelenerek yapılmalı. Somut olarak yapılabilecek şey, ERP satın alma sürecine "vendor son 12 ayda hangi kritik açıkları, ne sürede kapattı" sorusunu değerlendirme kriterlerine eklemek — tıpkı ERP sözleşmesi imzalamadan önceki kontrol listesinde belirtilen mevzuat uyum maddeleri gibi, güvenlik güncelleme yükümlülüğünün de sözleşmede yazılı olması gerekiyor.

Yapay zekâ ajanlarının ERP'ye daha fazla otonomi kazandırdığı bir dönemde (bu trendi ayrı bir yazıda ele almıştık) güvenlik konusu daha da kritik hale geliyor: bir ajan, ödeme onaylıyor ya da tedarikçi seçiyorsa, o ajanın çalıştığı hesabın ele geçirilmesi klasik bir kullanıcı hesabından çok daha geniş bir yetki alanını riske atıyor. ERP seçimi ya da yenileme sürecindeki işletmeler için bağımsız bir keşif görüşmesi talep etmek ya da uygun ERP bul aracıyla ölçek ve sektöre uygun seçenekleri karşılaştırmak, güvenlik kriterini de değerlendirme sürecine dahil etmenin bir yolu olabilir.

Kaynaklar

• Over 900 Oracle E-Business instances exposed to ongoing attacks — BleepingComputer
• SAP fixes critical vulnerabilities in Commerce Cloud and S/4HANA — BleepingComputer
• SAP-Related npm Packages Compromised in Credential-Stealing Supply Chain Attack — The Hacker News
• What Are the Real Cybersecurity Risks to SAP Systems in 2026? — WMS
• ERP'de yapay zekâ ajanları: vaat ve saha gerçeği
• ERP sözleşmesi imzalamadan önce kontrol listesi