2026’daki Trivy saldırısı, yazılım dünyasında yeni bir tehlikeyi ortaya çıkardı

Şirketler sistemlerini korumak için antivirüs, güvenlik tarayıcısı, bulut güvenliği ve yazılım kontrol araçları kullanıyor.

Peki, güvendiğiniz bir güvenlik aracı saldırganlar tarafından ele geçirilirse ne olur?

19 Mart 2026 tarihinde ortaya çıkan Trivy tedarik zinciri saldırısı, bu sorunun artık yalnızca teorik olmadığını gösterdi.

Saldırganlar, birçok yazılım ekibinin kullandığı güvenilir bir güvenlik aracının dağıtım sistemine zararlı kod yerleştirdi. Araç dışarıdan bakıldığında normal şekilde çalışmaya devam ederken arka planda şirketlerin erişim bilgilerini ve gizli verilerini toplamaya başladı.

En tehlikeli saldırı, zararlı olduğu açıkça görülen değil, güvenilir bir aracın içinde saklanan saldırıdır.

30 Saniyede Ne Oldu?

Trivy, yazılımlardaki ve sistemlerdeki güvenlik açıklarını bulmak için kullanılan açık kaynaklı bir güvenlik tarayıcısıdır.

2026 yılındaki saldırıda kötü niyetli kişiler:

• Güvenilir sürüm dosyalarını değiştirdi,
• GitHub Actions üzerinden kullanılan araçlara zararlı kod ekledi,
• Geliştirici bilgisayarlarını ve otomatik yazılım sistemlerini hedef aldı,
• Bulut erişim bilgilerini toplamaya çalıştı,
• Veritabanı parolalarını ve gizli anahtarları aradı,
• Topladığı bilgileri saldırganların kontrolündeki sunuculara gönderdi.

Daha da önemlisi, güvenlik taraması tamamlanıyor ve sistem normal çalışıyor gibi görünüyordu.

Bu nedenle saldırının fark edilmesi kolay değildi.

Yazılım Tedarik Zinciri Saldırısı Nedir?

Bir işletme kullandığı her yazılımı sıfırdan geliştirmez.

Hazır kütüphaneler, eklentiler, açık kaynaklı projeler, bulut servisleri ve üçüncü taraf araçlardan yararlanır.

Bu araçlardan biri saldırganlar tarafından ele geçirilirse, o aracı kullanan bütün şirketler dolaylı olarak risk altına girebilir.

Bu duruma yazılım tedarik zinciri saldırısı adı verilir.

Bunu günlük hayattan basit bir örnekle açıklayabiliriz:

Bir fabrikaya dışarıdan gelen ambalajların içine zararlı bir madde yerleştirildiğini düşünün. Fabrika kendi üretim sürecini doğru yönetse bile, güvendiği tedarikçi üzerinden zarar görebilir.

Yazılım dünyasında da benzer bir durum yaşanır.

Şirket kendi sistemini iyi korusa bile kullandığı bir yazılım, eklenti veya güncelleme kanalı ele geçirildiğinde saldırı içeriden geliyormuş gibi çalışabilir.

Trivy Saldırısı Neden Bu Kadar Tehlikeliydi?

Güvenilir bir araç kullanıldı

Kötü amaçlı yazılım, tanınmayan bir dosya olarak gelmedi. Güvenlik ekiplerinin zaten güvendiği bir aracın içine yerleştirildi.

Araç normal çalışmaya devam etti

Trivy güvenlik taramasını tamamlıyor, rapor üretiyor ve işlem başarılı görünüyordu.

Arka planda ise erişim bilgileri toplanıyordu.

Sürüm adı değişmeden içerik değiştirildi

GitHub üzerinde kullanılan sürüm etiketleri farklı bir kodu gösterecek şekilde değiştirildi.

Örneğin şirketin sistemi aynı sürümü kullandığını düşünürken, o sürümün arkasındaki içerik saldırganlar tarafından değiştirilmiş olabiliyordu.

Otomatik sistemler hedef alındı

Saldırı özellikle yazılımların otomatik olarak test edildiği, paketlendiği ve yayımlandığı CI/CD sistemlerini hedef aldı.

Bu sistemler genellikle çok sayıda gizli bilgiye erişebilir:

• GitHub erişim anahtarları,
• Bulut hesapları,
• Sunucu şifreleri,
• Veritabanı bağlantıları,
• API anahtarları,
• Kubernetes sırları,
• Yazılım yayınlama yetkileri.

Bir CI/CD sistemi ele geçirildiğinde saldırgan yalnızca bir bilgisayara değil, şirketin bütün yazılım üretim zincirine erişebilir.

Saldırganlar Hangi Bilgileri Aradı?

Saldırı sırasında özellikle şu tür bilgiler hedef alındı:

• AWS, Azure ve Google Cloud erişim bilgileri,
• GitHub ve NPM erişim anahtarları,
• Veritabanı kullanıcı adları ve parolaları,
• Kubernetes sistemlerindeki gizli bilgiler,
• SSH anahtarları,
• VPN yapılandırmaları,
• API anahtarları,
• Ortam değişkenlerinde saklanan parolalar,
• Yazılım yayınlama yetkileri.

Bu bilgiler ele geçirildiğinde saldırgan:

• Şirketin bulut sistemlerine girebilir,
• Veritabanlarına erişebilir,
• Yazılım paketlerini değiştirebilir,
• Yeni zararlı sürümler yayımlayabilir,
• Diğer müşterilere kadar uzanan yeni saldırılar başlatabilir.

Saldırı Nasıl Yayılıyor?

Bu tür saldırıların en tehlikeli yönlerinden biri, kendi kendini büyütebilmesidir.

Saldırgan bir geliştiricinin erişim anahtarını çaldığında, bu anahtarla başka bir yazılım paketini değiştirebilir.

Değiştirilen paket başka şirketler tarafından indirildiğinde yeni erişim bilgileri toplanır.

Böylece şu döngü oluşur:

Bir araç ele geçirilir → erişim bilgileri çalınır → başka araçlar değiştirilir → yeni şirketler etkilenir.

Bu nedenle tedarik zinciri saldırıları tek bir şirketle sınırlı kalmayabilir.

Sadece Büyük Yazılım Şirketleri mi Risk Altında?

Hayır.

Aşağıdaki işletmeler de risk altında olabilir:

• GitHub veya GitLab kullanan yazılım ekipleri,
• WordPress eklentisi geliştiren şirketler,
• Mobil uygulama üreten ekipler,
• Bulut sistemleri kullanan işletmeler,
• Otomatik yazılım yayımlama sistemi bulunan firmalar,
• Mikro, ERP, CRM veya özel entegrasyon geliştiren yazılım firmaları,
• Docker ve Kubernetes kullanan şirketler,
• Dışarıdan yazılım veya teknik hizmet alan işletmeler.

Kısacası, üçüncü taraf yazılım kullanan her işletmenin bu riski dikkate alması gerekir.

Şirketler Kendilerini Nasıl Koruyabilir?

1. Yalnızca sürüm adına güvenmeyin

Bir yazılımı yalnızca v1, latest veya benzeri sürüm etiketleriyle çağırmak risk oluşturabilir.

Çünkü bazı platformlarda bu etiketlerin arkasındaki kod sonradan değiştirilebilir.

Mümkün olduğunda kullanılan sürümün değiştirilemez kod kimliği doğrulanmalıdır.

2. Üçüncü taraf araçları sınırlandırın

Her geliştirici veya her proje istediği harici aracı sisteme ekleyememelidir.

Kullanılacak araçlar:

• Önceden onaylanmalı,
• Kaynağı doğrulanmalı,
• Düzenli olarak kontrol edilmeli,
• Gereksiz olanlar kaldırılmalıdır.

3. Erişim anahtarlarına sınırsız yetki vermeyin

Bir erişim anahtarı yalnızca ihtiyaç duyduğu işlemleri yapabilmelidir.

Örneğin sadece dosya okuması gereken bir sistemin:

• Kod değiştirme,
• Yeni sürüm yayımlama,
• Kullanıcı ekleme,
• Gizli bilgileri görüntüleme

yetkisi olmamalıdır.

4. Gizli bilgileri kodun içinde saklamayın

Parolalar, API anahtarları ve bulut erişim bilgileri:

• Kaynak kodun içine yazılmamalı,
• Açık metin dosyalarında tutulmamalı,
• Her işlemde ortam değişkenlerine aktarılmamalı,
• Geliştirici bilgisayarlarında kalıcı olarak saklanmamalıdır.

Bu bilgiler güvenli bir parola veya sır yönetim sistemi içinde tutulmalıdır.

5. Geçici çalışma ortamları kullanın

Otomatik yazılım süreçlerinde kullanılan çalışma ortamları, işlem tamamlandıktan sonra temizlenmelidir.

Aynı çalışma ortamının farklı projelerde tekrar kullanılması, bir projeden kalan gizli bilgilerin başka bir işleme sızmasına neden olabilir.

6. Günlük kayıtlarını düzenli olarak inceleyin

Şu durumlar şüpheli kabul edilmelidir:

• Daha önce kullanılmayan bir sunucuya bağlantı kurulması,
• Beklenmedik büyüklükte veri gönderilmesi,
• Yazılım sürümünün aniden değiştirilmesi,
• Yeni bir GitHub Action eklenmesi,
• Erişim anahtarlarının olağan dışı kullanılması,
• Veritabanı bağlantılarının beklenmedik biçimde okunması,
• Ortam değişkenlerinin toplu şekilde listelenmesi.

7. Erişim bilgilerini düzenli olarak yenileyin

Bir saldırı şüphesi varsa yalnızca zararlı yazılımı silmek yeterli değildir.

Şunlar değiştirilmelidir:

• GitHub erişim anahtarları,
• Bulut hesaplarının anahtarları,
• Veritabanı parolaları,
• API anahtarları,
• SSH anahtarları,
• Yazılım yayınlama yetkileri.

Çünkü saldırgan sistemden çıkarılmış olsa bile daha önce çaldığı bilgilerle tekrar erişebilir.

Kendinizi Hızlıca Test Edin

Aşağıdaki sorulara evet veya hayır cevabı verin:

1. Şirketinizde kullanılan açık kaynaklı yazılımların bir listesi var mı?
2. GitHub Actions ve benzeri araçlar merkezi olarak kontrol ediliyor mu?
3. Erişim anahtarlarının hangi yetkilere sahip olduğu biliniyor mu?
4. Veritabanı parolaları kaynak kodun dışında tutuluyor mu?
5. Kullanılan yazılım sürümleri değiştirilemez kimliklerle doğrulanıyor mu?
6. Kullanılmayan erişim anahtarları düzenli olarak iptal ediliyor mu?
7. Otomatik yazılım sistemlerinin ağ trafiği izleniyor mu?
8. Bir tedarik zinciri saldırısı yaşanırsa uygulanacak müdahale planınız var mı?

Sonucunuzu Değerlendirin

• 7–8 evet: Güvenlik yaklaşımınız güçlü, ancak düzenli denetim sürdürülmeli.
• 4–6 evet: Temel önlemler var fakat önemli açıklar bulunabilir.
• 0–3 evet: Yazılım tedarik zinciriniz ciddi risk altında olabilir.

Bir Güvenlik Aracı Ele Geçirilirse Ne Yapılmalı?

Şüpheli bir yazılım veya güncelleme tespit edildiğinde:

1. İlgili yazılımın çalışması durdurulmalıdır.
2. Etkilenen sistemler ağdan ayrılmalıdır.
3. Kullanılan sürüm ve indirme kaynağı kontrol edilmelidir.
4. Erişim anahtarları değiştirilmelidir.
5. Bulut ve veritabanı hareketleri incelenmelidir.
6. Şüpheli ağ bağlantıları araştırılmalıdır.
7. Temiz olduğu doğrulanmış sürüme geçilmelidir.
8. Diğer sistemlerde aynı aracın kullanılıp kullanılmadığı kontrol edilmelidir.

Burada en önemli nokta şudur:

Sadece zararlı dosyayı kaldırmak yeterli değildir. Saldırganın erişmiş olabileceği bütün hesaplar ve sistemler değerlendirilmelidir.

Bu Olaydan Çıkarılması Gereken En Önemli Ders

Geçmişte şirketler daha çok bilinmeyen dosyalardan, sahte e-postalardan ve dışarıdan gelen zararlı yazılımlardan korkuyordu.

Yeni saldırı yöntemlerinde ise tehdit, şirketin zaten güvendiği araçlardan gelebiliyor.

Bu nedenle modern siber güvenlik yaklaşımı yalnızca “Bu yazılım güvenilir mi?” sorusunu sormamalıdır.

Şu sorular da sorulmalıdır:

• Bu yazılımın güncellemelerini kim yayımlıyor?
• Sürüm sonradan değiştirilebilir mi?
• Yazılım hangi verilere erişiyor?
• Ele geçirilirse ne kadar zarar verebilir?
• İşlemleri kayıt altına alınıyor mu?
• Alternatif bir geri dönüş planımız var mı?

Sonuç

Trivy saldırısı, güvenlik araçlarının bile tedarik zinciri saldırılarında kullanılabileceğini gösterdi.

Bir aracın tanınmış, açık kaynaklı veya daha önce güvenilir olması, gelecekte de tamamen güvenli kalacağı anlamına gelmez.

Şirketlerin:

• Kullandığı üçüncü taraf araçları envanter altında tutması,
• Erişim yetkilerini sınırlandırması,
• Gizli bilgileri güvenli sistemlerde saklaması,
• Yazılım güncellemelerini doğrulaması,
• Sistem hareketlerini düzenli izlemesi,
• Olası saldırılara karşı müdahale planı oluşturması

gerekmektedir.

Siber güvenlik artık yalnızca cihazlara antivirüs kurmak değildir. Kullanılan yazılımların, güncelleme kanallarının, erişim anahtarlarının ve tedarikçilerin tamamı güvenlik sisteminin bir parçasıdır.

EMS Teknoloji, şirketlerin yazılım, sunucu, veritabanı ve bulut altyapılarındaki risklerin değerlendirilmesine yardımcı olur. Kullandığınız sistemlerin erişim yetkilerini, yedekleme yapısını ve veri güvenliği süreçlerini saldırı yaşanmadan önce gözden geçirmek büyük kayıpların önüne geçebilir.

Kaynak: Microsoft Defender Güvenlik Araştırmaları tarafından yayımlanan 2026 Trivy ve yazılım tedarik zinciri saldırısı incelemesi.

Yapay zekâ sistemleri artık yalnızca soru cevaplamıyor veya metin özetlemiyor. Yeni nesil yapay zekâ ajanları e-posta gönderebiliyor, belge oluşturabiliyor, takvimleri güncelleyebiliyor ve şirket sistemlerinde işlem yapabiliyor.

Bu gelişme iş süreçlerini hızlandırırken yeni güvenlik risklerini de beraberinde getiriyor.

Özellikle yapay zekâ ajanlarının şirket yazılımlarına bağlanmasını sağlayan harici araçlar, saldırganların yeni hedeflerinden biri hâline geliyor.

Yapay Zekâ Ajanı Nedir?

Geleneksel yapay zekâ uygulamaları çoğunlukla verilen bilgileri okur ve bir cevap üretir.

Yapay zekâ ajanları ise bunun ötesine geçebilir. Kullanıcı adına:

• E-posta hazırlayabilir ve gönderebilir,
• Belgeler oluşturabilir,
• Takvim kayıtlarını değiştirebilir,
• Veritabanlarından bilgi alabilir,
• Müşteri veya tedarikçi kayıtlarını kontrol edebilir,
• Fatura ve ödeme süreçlerinde işlem yapabilir.

Buradaki önemli fark şudur:

Normal bir yapay zekâ yanlış cevap verebilir. Yapay zekâ ajanı ise yanlış veya kötü niyetli bir talimat nedeniyle gerçek bir işlem gerçekleştirebilir.

MCP Nedir?

MCP, yani Model Bağlam Protokolü, yapay zekâ ajanlarının farklı yazılımlar ve veri kaynaklarıyla bağlantı kurmasını sağlayan bir iletişim yöntemidir.

Basit bir ifadeyle MCP, yapay zekâ ile şirket sistemleri arasında köprü görevi görür.

Örneğin bir yapay zekâ ajanı MCP aracılığıyla:

• Muhasebe sistemine,
• CRM yazılımına,
• E-posta hesabına,
• Dosya sunucusuna,
• Veritabanına,
• Harici bir doğrulama servisine

bağlanabilir.

Ancak bu bağlantılar doğru yönetilmezse yapay zekâ ajanı, güvenilir görünen kötü niyetli bir araç tarafından yönlendirilebilir.

MCP Araç Zehirleme Saldırısı Nedir?

MCP araç zehirleme saldırısında saldırgan, yapay zekâ ajanının kullandığı bir aracın açıklamasını veya çalışma talimatlarını değiştirir.

Araç dışarıdan bakıldığında aynı şekilde çalışıyor gibi görünür. Ancak arka plandaki açıklamanın içine gizli bir talimat eklenmiş olabilir.

Yapay zekâ ajanı bu gizli talimatı, sistem yöneticisi tarafından verilmiş normal bir görev gibi değerlendirebilir.

Böylece ajan:

• Kullanıcının istemediği bilgilere erişebilir,
• Daha fazla kayıt toplayabilir,
• Hassas verileri harici bir sisteme gönderebilir,
• Yetkisi dahilinde yanlış işlemler gerçekleştirebilir.

Kullanıcı ise ekranda yalnızca normal bir cevap görebilir.

Basit Bir Örnek

Bir şirketin finans ekibinin, tedarikçi faturalarını kontrol eden bir yapay zekâ ajanı kullandığını düşünelim.

Bu ajan üç sisteme bağlı olsun:

1. Onaylı tedarikçi kayıtlarının bulunduğu veritabanı,
2. Tedarikçi e-postalarının bulunduğu e-posta sistemi,
3. Banka bilgilerini kontrol eden harici bir doğrulama servisi.

Başlangıçta harici doğrulama servisi güvenli olabilir. Ancak daha sonra aracın açıklamasına gizli bir talimat eklenirse yapay zekâ ajanı farkında olmadan son ödenmemiş faturaları toplayabilir ve bu bilgileri harici servise gönderebilir.

Harici servis kullanıcıya “Bilgiler doğrulandı” şeklinde normal bir cevap verirken, arka planda hassas finansal verileri kaydedebilir.

Bu olayda:

• Kullanıcı şüpheli bir bağlantıya tıklamamıştır,
• Kullanıcının parolası çalınmamıştır,
• Yapay zekâ sistemine doğrudan saldırılmamıştır,
• Yapay zekâ ajanının güvendiği harici araç kötüye kullanılmıştır.

Bu nedenle risk yalnızca yapay zekâ uygulamasında değil, uygulamanın bağlı olduğu bütün araçlarda bulunmaktadır.

Bu Saldırı Neden Zor Fark Edilir?

MCP araç zehirleme saldırılarının tespit edilmesi zor olabilir. Çünkü yapay zekâ ajanının yaptığı işlemler teknik olarak kendi yetkileri içindedir.

Örneğin:

• Araç daha önce onaylanmış olabilir,
• Veritabanı sorgusu kullanıcının mevcut yetkileriyle yapılabilir,
• Veri, izin verilen bir sunucuya gönderilebilir,
• Kullanıcıya normal bir sonuç gösterilebilir.

Güvenlik sistemleri tek tek işlemlere baktığında olağan dışı bir durum görmeyebilir.

Asıl sorun, normal görünen işlemlerin kötü niyetli bir amaç doğrultusunda bir araya getirilmesidir.

Şirketler Hangi Önlemleri Almalı?

1. Her yapay zekâ aracına güvenmeyin

Bir yapay zekâ ajanına bağlanan her harici araç, şirketin yazılım tedarik zincirinin bir parçası olarak değerlendirilmelidir.

Aracın yalnızca adına veya tanıtım açıklamasına bakmak yeterli değildir.

Şunlar kontrol edilmelidir:

• Aracı kim geliştirdi?
• Veriler hangi sunucuya gönderiliyor?
• Sunucunun sahibi kim?
• Araç hangi bilgilere erişebiliyor?
• Güvenlik güncellemeleri nasıl yapılıyor?
• Değişiklikler kim tarafından takip ediliyor?

2. Yapay zekâ ajanına yalnızca gerekli araçları verin

Bir ajanın bütün sistemlere erişmesine izin verilmemelidir.

Örneğin yalnızca fatura kontrolü yapan bir ajan:

• Personel kayıtlarına,
• Tüm müşteri verilerine,
• Şirketin bütün e-postalarına,
• Banka ödeme talimatlarına

erişememelidir.

Her yapay zekâ ajanına yalnızca görevini yerine getirmek için ihtiyaç duyduğu en düşük erişim yetkisi verilmelidir.

3. Kritik işlemlerde insan onayı kullanın

Yapay zekâ ajanları şu işlemleri insan onayı olmadan gerçekleştirmemelidir:

• Para transferi,
• Banka hesabı değişikliği,
• Yeni tedarikçi oluşturulması,
• Toplu veri aktarımı,
• Hassas dosyaların paylaşılması,
• Kullanıcı yetkilerinin değiştirilmesi,
• Müşterilere otomatik mesaj gönderilmesi.

Yapay zekâ işlemi hazırlayabilir ancak son onay yetkili bir çalışan tarafından verilmelidir.

4. Araç açıklamalarındaki değişiklikleri takip edin

Bir MCP aracının açıklamasındaki değişiklik, basit bir metin güncellemesi olarak görülmemelidir.

Çünkü yapay zekâ ajanı bu açıklamaları çalışma talimatı olarak kullanabilir.

Üretimde kullanılan araçların:

• Açıklamaları,
• Parametreleri,
• Erişim izinleri,
• Bağlandığı sunucular,
• Gönderdiği veri türleri

düzenli olarak kontrol edilmelidir.

Değişiklik yapıldığında aracın yeniden güvenlik incelemesinden geçirilmesi gerekir.

5. Giden verileri denetleyin

Yapay zekâ ajanının harici sistemlere hangi verileri gönderdiği takip edilmelidir.

Özellikle şu bilgiler için koruma uygulanmalıdır:

• Müşteri bilgileri,
• Finansal kayıtlar,
• Fatura bilgileri,
• Kimlik bilgileri,
• Personel verileri,
• Sağlık bilgileri,
• Parolalar ve erişim anahtarları.

Veri kaybı önleme sistemleri, hassas bilgilerin izinsiz şekilde dışarı gönderilmesini engelleyebilir.

6. Yapay zekâ ajanlarının işlemlerini kaydedin

Ajanın hangi kullanıcı adına, hangi aracı, ne zaman ve hangi verilerle kullandığı kayıt altına alınmalıdır.

Takip edilmesi gereken bazı durumlar şunlardır:

• Daha önce kullanılmayan bir harici sunucuya bağlantı kurulması,
• Normalden çok daha fazla verinin sorgulanması,
• Kullanıcının talebiyle ilgisiz bilgilerin alınması,
• Alışılmadık saatlerde işlem yapılması,
• Araç parametrelerinin beklenmedik şekilde büyümesi,
• Aynı ajanın kısa sürede çok sayıda sisteme erişmesi.

Bu kayıtlar olası bir güvenlik olayının araştırılmasını kolaylaştırır.

7. Yapay zekâ ajanlarını düzenli olarak test edin

Yapay zekâ ajanları kullanıma alınmadan önce yalnızca işlevsel olarak değil, güvenlik açısından da test edilmelidir.

Testlerde şu sorulara cevap aranmalıdır:

• Ajan gizli bir talimatla yönlendirilebilir mi?
• Kullanıcının istemediği verilere ulaşabilir mi?
• Hassas verileri harici bir servise gönderebilir mi?
• Yetkisinin dışına çıkmaya çalışıyor mu?
• Kritik işlemlerde insan onayı istiyor mu?
• Harici araç değiştiğinde uyarı oluşuyor mu?

En Az Yetki Tek Başına Yeterli Değildir

Geleneksel güvenlik yaklaşımında kullanıcılara ve uygulamalara mümkün olan en düşük yetkinin verilmesi önerilir.

Bu yaklaşım yapay zekâ ajanları için de önemlidir. Ancak tek başına yeterli olmayabilir.

Bir yapay zekâ ajanı sınırlı yetkiye sahip olsa bile çok fazla hareket özgürlüğü verilirse zarar verebilir.

Bu nedenle iki ayrı sınır uygulanmalıdır:

• En az yetki: Ajan yalnızca gerekli verilere erişebilmelidir.
• En az özerklik: Ajan yalnızca gerekli işlemleri kendi başına yapabilmelidir.

Kritik işlemler mutlaka insan kontrolünde olmalıdır.

Bu Bir Yapay Zekâ Hatası mı?

MCP araç zehirleme saldırısı, doğrudan yapay zekâ sisteminin bozuk olduğu anlamına gelmez.

Sorun genellikle yapay zekâ ajanının güvendiği üçüncü taraf araçlardan, yetersiz erişim kontrollerinden ve takip edilmeyen değişikliklerden kaynaklanır.

Bu nedenle şirketlerin yalnızca kullandıkları yapay zekâ modelini değil, yapay zekânın bağlandığı bütün sistemleri de güvenlik kapsamına alması gerekir.

Sonuç

Yapay zekâ ajanları şirketlerin iş süreçlerini hızlandırabilir, çalışanların yükünü azaltabilir ve birçok işlemi otomatikleştirebilir.

Ancak e-posta gönderen, veritabanına bağlanan veya finansal işlem gerçekleştiren bir yapay zekâ ajanı, normal bir sohbet robotundan çok daha yüksek risk taşır.

Şirketlerin yapay zekâ ajanlarını kullanırken:

• Harici araçları dikkatle seçmesi,
• Yetkileri sınırlandırması,
• Kritik işlemlerde insan onayı istemesi,
• Araç değişikliklerini takip etmesi,
• Giden verileri denetlemesi,
• Bütün işlemleri kayıt altına alması

gerekir.

Yapay zekâ güvenliği yalnızca güçlü bir parola kullanmakla sağlanamaz. Yapay zekânın hangi verilere eriştiği, hangi araçlara güvendiği ve kullanıcı adına hangi işlemleri yapabildiği de sürekli olarak kontrol edilmelidir.

Kaynak: Microsoft Olay Müdahale ve Güvenlik Araştırmaları tarafından yayımlanan yapay zekâ ajanları ve MCP araç güvenliği çalışması.

Fidye yazılımı saldırıları artık yalnızca bilgisayardaki dosyaları şifrelemekle sınırlı değil. Saldırganlar şirket verilerini çalabiliyor, yedekleri silebiliyor ve ele geçirdikleri bilgileri yayımlamakla tehdit edebiliyor.

Bu nedenle şirketlerin yalnızca yedek alması değil, aldığı yedeği saldırılara karşı koruması da gerekiyor.

Fidye Yazılımı Nedir?

Fidye yazılımı, bilgisayarlardaki ve sunuculardaki dosyaları şifreleyerek kullanılamaz duruma getiren zararlı bir yazılım türüdür.

Saldırganlar, dosyaları tekrar açmak için şirketten para talep eder. Bazı saldırılarda ise veriler önce çalınır, ardından:

• Verilerin internette yayımlanacağı,
• Müşterilere gönderileceği,
• Rakip firmalarla paylaşılacağı

söylenerek şirket üzerinde baskı oluşturulur.

Bu saldırı yöntemi çift şantaj olarak adlandırılır.

Yedek Almak Neden Tek Başına Yeterli Değil?

Birçok işletme düzenli yedek aldığı için güvende olduğunu düşünür. Ancak fidye yazılımları, bilgisayarlarla birlikte erişebildiği yedekleri de şifreleyebilir veya silebilir.

Örneğin yedek diski sürekli sunucuya bağlıysa saldırgan bu diske de ulaşabilir. Aynı şekilde, yedekleme hesabının şifresi ele geçirilirse buluttaki yedekler de silinebilir.

Bu nedenle güvenli bir yedekleme sistemi şu özelliklere sahip olmalıdır:

• Ana sistemden ayrı tutulmalıdır.
• Şifrelenmiş olmalıdır.
• Yetkisiz kişiler tarafından silinememelidir.
• Eski sürümlere geri dönüş imkânı sağlamalıdır.
• Geri yükleme testleri düzenli olarak yapılmalıdır.

Unutulmamalıdır ki geri yüklenemeyen bir yedek, gerçek bir yedek değildir.

Şirketlerin Alması Gereken 7 Temel Önlem

1. Kritik verileri düzenli olarak yedekleyin

Muhasebe verileri, SQL veritabanları, müşteri bilgileri, belgeler ve şirket için önemli dosyalar düzenli olarak yedeklenmelidir.

Yedeklerin yalnızca alınması değil, belirli aralıklarla açılarak kontrol edilmesi de gerekir.

2. Yedekleri ana sistemden ayırın

Yedeklerin tamamını aynı sunucuda veya sürekli bağlı bir diskte tutmak risklidir.

Mümkün olduğunca çevrimdışı, farklı bir sistemde veya güvenli bir bulut ortamında ikinci bir yedek bulundurulmalıdır.

3. Silinemez yedekleme kullanın

Değiştirilemez veya silinemez yedekleme sistemleri, saldırganların yedekleri silmesini zorlaştırır.

Bu sistemlerde yedekler belirlenen süre boyunca değiştirilemez ve silinemez şekilde korunur.

4. Uzaktan erişimleri sınırlandırın

RDP ve benzeri uzaktan bağlantı hizmetlerinin doğrudan internete açılması ciddi risk oluşturur.

Uzaktan erişim gerekiyorsa:

• VPN kullanılmalı,
• Çok faktörlü doğrulama etkinleştirilmeli,
• Güçlü ve uzun parolalar belirlenmeli,
• Başarısız giriş denemeleri takip edilmelidir.

5. Yazılımları ve sunucuları güncel tutun

Saldırganlar çoğu zaman eski yazılımlardaki bilinen güvenlik açıklarından yararlanır.

Windows, SQL Server, WordPress, güvenlik yazılımları ve kullanılan diğer uygulamalar düzenli olarak güncellenmelidir.

Kritik güvenlik güncellemeleri geciktirilmemelidir.

6. Kullanıcılara ihtiyaçlarından fazla yetki vermeyin

Her kullanıcı yalnızca işi için gerekli dosyalara ve sistemlere erişebilmelidir.

Günlük işlemler yönetici hesabıyla yapılmamalı, kullanılmayan hesaplar kapatılmalı ve eski çalışanlara ait erişimler kaldırılmalıdır.

Bir kullanıcının hesabı ele geçirildiğinde, sınırlı yetki saldırının yayılmasını da sınırlar.

7. Çalışanları sahte e-postalara karşı bilgilendirin

Fidye yazılımlarının önemli bir bölümü sahte e-postalar, zararlı bağlantılar ve şüpheli ekler üzerinden sisteme girer.

Çalışanlar özellikle şu konularda dikkatli olmalıdır:

• Tanımadıkları kişilerden gelen dosyaları açmamak,
• Şüpheli bağlantılara tıklamamak,
• E-posta üzerinden gelen parola taleplerine güvenmemek,
• Office dosyalarında makroları etkinleştirmemek,
• Şüpheli durumları hemen teknik ekibe bildirmek.

Fidye Yazılımı Saldırısı Yaşanırsa Ne Yapılmalı?

Bir bilgisayarda dosyaların uzantısı değişmeye, dosyalar açılmamaya veya ekranda fidye mesajı görünmeye başladıysa hızlı hareket edilmelidir.

İlk olarak şu işlemler uygulanmalıdır:

1. Etkilenen bilgisayarın ağ ve internet bağlantısı kesilmelidir.
2. Ortak klasörlere ve sunuculara erişimi durdurulmalıdır.
3. Diğer bilgisayarlarda benzer belirtiler olup olmadığı kontrol edilmelidir.
4. Yedeklerin saldırıdan etkilenip etkilenmediği incelenmelidir.
5. Teknik destek ve siber güvenlik ekibine haber verilmelidir.
6. Temizliği doğrulanmadan sistemler yeniden ağa bağlanmamalıdır.

Cihazı doğrudan kapatmak bazı teknik inceleme kayıtlarının kaybolmasına neden olabilir. Ancak cihaz ağdan ayrılamıyorsa saldırının yayılmasını durdurmak için kapatılması gerekebilir.

Yedeklerden Geri Dönmeden Önce Dikkat

Saldırı sonrasında yalnızca dosyaları geri yüklemek yeterli değildir. Saldırganın sisteme nasıl girdiği bulunmadan geri yükleme yapılırsa aynı saldırı tekrar yaşanabilir.

Geri yükleme öncesinde:

• Zararlı yazılım temizlenmeli,
• Kullanıcı parolaları değiştirilmelidir,
• Güvenlik açıkları kapatılmalıdır,
• Yazılımlar güncellenmelidir,
• Yetkisiz kullanıcı hesapları kaldırılmalıdır,
• Temiz bir sistem üzerinde geri yükleme yapılmalıdır.

Sonuç: Yedeğiniz Var mı, Yoksa Gerçekten Güvende mi?

Fidye yazılımlarına karşı en önemli savunmalardan biri düzenli yedeklemedir. Ancak yedeğin ana sistemden ayrı, şifrelenmiş, silinmeye karşı korumalı ve düzenli olarak test edilmiş olması gerekir.

Şirketinizin verilerini korumak için saldırı yaşanmasını beklemeyin. Yedekleme yapınızı, uzaktan erişimlerinizi, kullanıcı yetkilerinizi ve geri yükleme planınızı bugünden kontrol edin.

EMS Bulut, dosyalarınızın, e-postalarınızın ve veritabanlarınızın düzenli ve güvenli şekilde yedeklenmesine yardımcı olur. Mevcut yedekleme sisteminizin yeterli olup olmadığını birlikte değerlendirebiliriz.

Kaynak: CISA, NSA, FBI ve MS-ISAC tarafından hazırlanan StopRansomware Fidye Yazılımı Rehberi.

Yedeğiniz Başarılı Görünebilir, Ancak Geri Yüklenemeyebilir

Klasik fidye yazılımlarında saldırganlar dosyaları şifreler, sistemleri erişilemez hâle getirir ve fidye talep eder. Güncel saldırı yöntemlerinde ise saldırganlar doğrudan dosyaları şifrelemek yerine, veritabanı sunucusunun kendi meşru şifreleme mekanizmasını kullanabilir.

TDE Suistimali olarak adlandırılan bu yöntemde saldırgan:

1. SQL Server üzerinde yüksek yetkili erişim elde eder.
2. Kendi kontrolündeki bir sertifika ve şifreleme anahtarı oluşturur.
3. Veritabanlarında TDE özelliğini etkinleştirir.
4. Sertifika ve özel anahtarları kendi sistemine aktarır.
5. Yedeklerin haftalarca veya aylarca şifreli şekilde alınmasını bekler.
6. Temiz yedekler silindikten sonra anahtar karşılığında fidye talep eder.

Bu süre boyunca yedekleme sistemi “yedekleme başarılı” raporu vermeye devam edebilir. Ancak gerekli TDE sertifikası bulunmadığında alınan yedekler farklı bir sunucuya geri yüklenemez.

TDE Nedir?

Transparent Data Encryption, veritabanı dosyalarının disk üzerinde şifreli tutulmasını sağlayan bir güvenlik özelliğidir.

Microsoft SQL Server tarafında şifreleme yapısı genel olarak şu bileşenlerden oluşur:

• Service Master Key
• Database Master Key
• Sertifika veya asimetrik anahtar
• Database Encryption Key
• Şifrelenen veritabanı dosyaları

TDE doğru yapılandırıldığında önemli bir güvenlik katmanı sağlar. Ancak sertifika ve özel anahtarların kaybedilmesi durumunda, şifrelenmiş veritabanı yedeklerinin geri yüklenmesi mümkün olmayabilir.

Tipik geri yükleme hatası şöyledir:

Cannot find server certificate with thumbprint...

Bu hata, yedeğin bozuk olduğu anlamına gelmez. Yedek teknik olarak sağlam olabilir; ancak veriyi açabilecek sertifika hedef SQL Server üzerinde bulunmamaktadır.

Saldırı Neden Uzun Süre Fark Edilmeyebilir?

Saldırgan TDE’yi etkinleştirdikten sonra hemen fidye talep etmeyebilir. Bunun yerine yedek saklama süresini analiz ederek 30, 60 veya 90 gün bekleyebilir.

Bu bekleme süresinde:

• Full yedekler şifreli veriyi içerir.
• Differential yedekler aynı şifreleme zincirine bağlıdır.
• Transaction log yedekleri etkilenir.
• Replikasyon ve felaket kurtarma sunucuları şifreli veriyi devralır.
• Eski ve temiz yedekler saklama süresi dolduğu için silinir.

Saldırgan daha sonra veritabanını silebilir, SQL Server’ı yeniden başlatabilir veya sertifikayı erişilemez hâle getirebilir.

Sonuç olarak kurumun elinde çok sayıda başarılı yedek bulunmasına rağmen, bu yedeklerin hiçbiri kullanılamayabilir.

Geleneksel Yedekleme Kontrolleri Neden Yeterli Değildir?

Yedek bütünlüğü, verinin okunabilir olduğu anlamına gelmez

RESTORE VERIFYONLY gibi kontroller, yedek dosyasının fiziksel ve mantıksal yapısını doğrular. Ancak yedek içindeki verinin gerekli sertifikalar olmadan açılıp açılamayacağını garanti etmez.

TDE yedekleme yazılımı için şeffaftır

SQL Server veriyi disk üzerinde şifreli tuttuğu için, yedekleme sistemi bu veriyi olduğu şekilde yedekler. İşlem başarısız olmaz ve standart kontroller alarm üretmeyebilir.

Kullanılan komutlar meşru SQL komutlarıdır

Saldırıda kullanılabilecek komutlar şunlardır:

CREATE CERTIFICATE
CREATE DATABASE ENCRYPTION KEY
ALTER DATABASE SET ENCRYPTION ON

Bu komutlar SQL Server’ın standart yönetim komutlarıdır. Kötü amaçlı yazılım imzası taşımadıkları için klasik antivirüs ve EDR çözümleri tarafından her zaman tehdit olarak algılanmayabilir.

EMSBulut Backup Now Nasıl Koruma Sağlar?

EMSBulut Backup Now, SQL yedekleme işlemi başlamadan önce veritabanlarının TDE şifreleme durumunu kontrol eder.

Beklenmeyen bir şifreleme durumu tespit edildiğinde sistem yöneticisi bilgilendirilir.

Örneğin:

Bu veritabanında TDE şifrelemesi etkinleştirilmiştir. Bu işlem kurumunuz tarafından planlı olarak mı gerçekleştirilmiştir?

Bu kontrol sayesinde saldırganın şifrelemeyi etkinleştirip haftalarca sessizce yedeklerin üzerine yazılmasını beklemesi zorlaşır.

EMSBulut Backup Now yaklaşımının temel amacı yalnızca yedek almak değil, alınan yedeğin şifreleme durumu hakkında sistem yöneticisine görünürlük sağlamaktır.

Böylece:

• Yeni etkinleştirilen TDE durumu erken fark edilebilir.
• Şifreli veritabanları takip edilebilir.
• Sistem yöneticileri beklenmeyen değişiklikleri araştırabilir.
• Temiz yedekler saklama süresi dolmadan koruma altına alınabilir.
• Olası bir fidye saldırısının hazırlık aşaması kesintiye uğratılabilir.

SQL Server’da TDE Durumu Nasıl Kontrol Edilir?

Sistem yöneticileri aşağıdaki sorguyu SQL Server Management Studio üzerinden çalıştırabilir:

SELECT
    db.name AS [Veritabanı Adı],
    db.is_encrypted AS [TDE İşaretli mi? (1=Evet)],
    CASE dek.encryption_state
        WHEN 0 THEN 'Anahtar Yok / Şifreleme Yok'
        WHEN 1 THEN 'Şifrelenmemiş'
        WHEN 2 THEN 'Şifreleme Devam Ediyor'
        WHEN 3 THEN 'Şifrelenmiş (Aktif)'
        WHEN 4 THEN 'Anahtar Değişimi Devam Ediyor'
        WHEN 5 THEN 'Şifre Çözme Devam Ediyor'
        WHEN 6 THEN 'Koruma Değişikliği Yapılıyor'
        ELSE 'Bilinmiyor'
    END AS [Detaylı Durum],
    dek.percent_complete AS [İşlem Tamamlanma Yüzdesi]
FROM sys.databases db
LEFT JOIN sys.dm_database_encryption_keys dek
    ON db.database_id = dek.database_id;

Sonuçların yorumlanması

is_encrypted = 0

Veritabanında TDE etkin değildir. Kurumunuz TDE kullanmıyorsa beklenen durum budur.

is_encrypted = 1 ve encryption_state = 3

Veritabanı aktif olarak şifrelenmiştir. TDE kurumunuz tarafından planlı şekilde etkinleştirilmediyse acil inceleme yapılmalıdır.

encryption_state = 2

Şifreleme işlemi devam etmektedir. İşlem sistem yöneticileri tarafından başlatılmadıysa sunucuda aktif bir saldırı ihtimali değerlendirilmelidir.

encryption_state = 4 veya 6

Anahtar veya koruma yöntemi değiştirilmektedir. Planlı bir bakım işlemi bulunmuyorsa şüpheli durum olarak ele alınmalıdır.

Beklenmeyen Bir Şifreleme Tespit Edilirse

Sunucuyu hemen kapatmak doğru olmayabilir. SQL Server bazı şifreleme anahtarlarını bellekte tutuyor olabilir. Kontrolsüz bir yeniden başlatma, bellekte bulunan anahtarların kaybedilmesine neden olabilir.

Önerilen ilk adımlar:

1. Sunucunun dış ağ bağlantısını kesin veya ağı kontrollü şekilde izole edin.
2. SQL Server hizmetini plansız şekilde durdurmayın.
3. Olay müdahale ve adli bilişim ekibini devreye alın.
4. Erişilebiliyorsa master key ve TDE sertifikalarını yedekleyin.
5. SQL Server Audit, Extended Events ve Windows güvenlik kayıtlarını koruma altına alın.
6. TDE’nin hangi tarihte etkinleştirildiğini belirleyin.
7. Bu tarihten önce alınmış temiz yedekleri ayrı bir ortamda koruyun.
8. İzole bir SQL Server üzerinde gerçek geri yükleme testi gerçekleştirin.

Erişilebilir durumda olan master key ve sertifikalar aşağıdaki komutlarla yedeklenebilir:

BACKUP MASTER KEY
TO FILE = 'C:\SecureBackup\master_key.snk'
ENCRYPTION BY PASSWORD = 'Guclu-Bir-Parola-Kullanin';

BACKUP CERTIFICATE [SertifikaAdi]
TO FILE = 'C:\SecureBackup\certificate.cer'
WITH PRIVATE KEY
(
    FILE = 'C:\SecureBackup\certificate.pvk',
    ENCRYPTION BY PASSWORD = 'Guclu-Bir-Parola-Kullanin'
);

Anahtar ve sertifika dosyaları, SQL Server’ın bulunduğu sistemden ayrı ve erişimi sınırlandırılmış güvenli bir ortamda saklanmalıdır.

Kurumlar İçin Önerilen Önlemler

TDE işlemlerini izleyin

Aşağıdaki işlemler için SQL Server Audit veya Extended Events üzerinden alarm oluşturun:

• Sertifika oluşturulması
• Database Encryption Key oluşturulması
• TDE’nin etkinleştirilmesi
• Sertifika veya anahtar yedeklenmesi
• Master key değişiklikleri
• Sertifika silme işlemleri

SQL sysadmin hesaplarını sınırlandırın

Günlük kullanılan hesaplara kalıcı sysadmin yetkisi verilmemelidir.

Mümkünse:

• Çok faktörlü kimlik doğrulama
• Bastion sunucu
• Just-in-time yetkilendirme
• Ayrı yönetici hesapları
• IP ve ağ segmenti kısıtlamaları

kullanılmalıdır.

Gerçek geri yükleme testi yapın

Yalnızca yedekleme işleminin başarılı olmasına veya VERIFYONLY sonucuna güvenilmemelidir.

Belirli aralıklarla:

1. Yedek izole bir SQL Server’a geri yüklenmeli,
2. TDE sertifikaları doğrulanmalı,
3. Kritik tablolar sorgulanmalı,
4. Uygulama seviyesinde veri erişimi test edilmelidir.

Anahtarları yedeklerden ayrı saklayın

TDE sertifikası ve özel anahtarı yalnızca SQL Server üzerinde tutulmamalıdır.

Kritik sistemlerde HSM, Azure Key Vault, AWS KMS veya kurumsal anahtar yönetim çözümleri değerlendirilmelidir.

İnternete açık SQL portlarını kapatın

SQL Server’ın 1433 portu doğrudan internete açılmamalıdır.

Uzak erişim gerektiğinde VPN, Zero Trust erişim, güvenli ağ geçidi veya IP beyaz listeleme kullanılmalıdır.

Sonuç

TDE Suistimali saldırısı, klasik fidye saldırılarından farklı olarak yedekleri silmeden veya yedekleme işini durdurmadan ilerleyebilir.

Bu nedenle “yedekleme başarılı” mesajı tek başına yeterli güvence değildir.

Modern bir yedekleme stratejisi şu üç soruya cevap verebilmelidir:

• Yedek dosyası sağlam mı?
• Veritabanı beklenmeyen şekilde şifrelenmiş mi?
• Yedek, farklı bir sistem üzerinde gerçekten geri yüklenip okunabiliyor mu?

EMSBulut Backup Now, yedekleme öncesinde TDE durumunu kontrol ederek beklenmeyen şifreleme değişikliklerinin erken fark edilmesine yardımcı olur.

Amaç yalnızca veriyi yedeklemek değil, ihtiyaç anında geri yüklenebilecek ve kullanılabilecek bir veri kopyasını güvence altına almaktır.