Yakın zamanda meydana gelen bir olayda, Microsoft AI araştırma ekibi yanlışlıkla GitHub depolarında 38 terabaytlık şaşırtıcı miktarda özel veriyi açığa çıkardı.
Bu risk, Azure Depolama hesaplarından veri paylaşmak için kullanılan, SAS belirteçleri olarak bilinen bir Azure özelliğinin yanlış yapılandırılmasından kaynaklanmıştır.
Yanlış yapılandırma, kişisel bilgisayar yedeklemeleri, parolalar, gizli anahtarlar gibi hassas bilgiler ve 359 Microsoft çalışanından gelen 30.000’den fazla dahili Microsoft Teams mesajı dahil olmak üzere depolama hesabının tamamına erişime izin verdi.
Çeşitli saldırı türleri ve bunların nasıl önleneceği hakkında bilgi edinmek için Canlı DDoS Web Sitesi ve API Saldırı Simülasyonu web seminerine katılın.
Şimdi Katıl
Özellikle endişe verici olan, erişim düzeyinin “tam kontrol” olarak ayarlanmış olması, dosyaların yalnızca görüntülenmesini değil aynı zamanda silinmesini ve üzerine yazılmasını da mümkün kılıyor.
Bu olay, kuruluşların yapay zekadan yararlanırken ve büyük hacimli eğitim verileriyle çalışırken karşılaştıkları yeni güvenlik zorluklarının altını çiziyor.
Olay, yanlış yapılandırılmış depolama kapları için interneti tarayan Wiz Araştırma Ekibi tarafından keşfedildi.
Wiz, şirketlerin genel bulut altyapısındaki güvenlik sorunlarını bulmasına olanak tanıyan bir siber güvenlik şirketidir.
Microsoft’un yapay zeka araştırma bölümüne ait olan ve kullanıcılara bir Azure Depolama URL’sinden modelleri indirmeleri talimatı verilen bir GitHub deposuna rastladılar.
Maalesef bu URL, amaçlanan açık kaynak modellerinden çok daha fazlasına erişim sağladı.
Azure dünyasında, Paylaşılan Erişim İmzası (SAS) belirteçleri, Azure Depolama verilerine erişim verilmesinde çok önemli bir rol oynar.
Bu belirteçler krallığın anahtarları gibidir; salt okunurdan tam kontrole kadar çeşitli düzeylerde erişim sunar ve kapsamı tek bir dosyaya, konteynere ve hatta depolama hesabının tamamına kadar genişletilebilir.
Esneklikleri SAS belirteçlerini diğerlerinden ayırır; bunları istediğiniz zaman sona erecek şekilde ayarlayabilir veya neredeyse sonsuz hale getirebilirsiniz.
Ancak büyük güç, büyük sorumluluğu da beraberinde getirir ve aşırıya kaçma potansiyeli gerçektir.
En izin verici haliyle, bir SAS belirteci tüm hesap anahtarının erişim yeteneklerini taklit ederek depolama hesabınızı süresiz olarak açık bırakabilir.
SAS belirteçlerinin üç türü vardır: Hesap SAS, Hizmet SAS ve Kullanıcı Yetkisi SAS. Bu yazıda, popüler bir seçim olan ve Microsoft’un deposunda kullanılan tür olan Hesap SAS tokenlerini inceleyeceğiz.
Hesap SAS jetonu oluşturmak nispeten basittir. Kullanıcılar tokenın kapsamını, izinlerini ve son kullanma tarihini yapılandırır ve işte, token doğmuş olur.
Tüm bu sürecin Azure sunucularında değil istemci tarafında gerçekleştiğini unutmamak önemlidir. Sonuç olarak ortaya çıkan belirteç başlı başına bir Azure varlığı değildir.
Yüksek ayrıcalıklı, kalıcı SAS tokenleri yaratmanın kolaylığı da güvenlik endişelerini artırıyor. Bir kullanıcı farkında olmadan aşırı izin veren, süresi dolmayan bir jeton oluşturursa, yöneticiler bunun varlığından veya nerede kullanıldığından bile haberdar olmayabilir.
Böyle bir tokenı iptal etmek, parkta yürümekten çok uzaktır; bu, onu imzalayan hesap anahtarının döndürülmesini ve o anahtar tarafından imzalanan tüm tokenların etkili bir şekilde işe yaramaz hale getirilmesini gerektirir.
Bu benzersiz zorluk, açığa çıkan verileri arayan saldırganların dikkatini çeken bir güvenlik açığı yaratır.
Dahası, Azure’un SAS belirteç sistemi sağlam izleme yeteneklerinden yoksundur; bu da onu, güvenliği ihlal edilmiş depolama hesaplarında kalıcı bir yer edinmeyi amaçlayan saldırganlar için cazip bir araç haline getiriyor.
Bu tür riskleri azaltmak için kuruluşlara, Hesap SAS belirteçlerinin harici paylaşım için kullanımını sınırlamaları ve Hizmet SAS belirteçlerini, Depolanmış Erişim İlkeleri veya zaman sınırlı paylaşım için Kullanıcı Yetkisi SAS belirteçleri ile kullanmayı düşünmeleri önerilir.
Harici paylaşım için özel depolama hesapları oluşturmak da potansiyel hasarın kontrol altına alınmasına yardımcı olabilir.
Güvenlik ekipleri, veri paylaşımı ve olası tedarik zinciri saldırılarıyla ilişkili güvenlik risklerini ele alarak Microsoft AI geliştirme süreçlerine aktif olarak katılmalıdır.
Yapay zeka geliştirme yaşam döngüsü boyunca uygun güvenlik önlemlerinin alınması için güvenlik, veri bilimi ve araştırma ekipleri arasındaki farkındalık ve işbirliği önemlidir.
Microsoft, SAS belirtecinin geçersiz kılınması ve GitHub’da değiştirilmesi de dahil olmak üzere sorunu çözmek için adımlar attı.
Bizi Google Haberler, Linkedin’den takip ederek en son Siber Güvenlik Haberlerinden haberdar olun, heyecanve Facebook.