Copilot denetim günlüklerini bozdu, ancak Microsoft müşterilere bildirmedi
(pistachioapp.com)- Microsoft'un M365 Copilot'unda denetim günlüklerinin kaydedilmemesine yol açan bir güvenlik açığı keşfedildi; bu da dosya erişimlerinin günlüklerde görünmemesi sorununu doğurdu
- Copilot'tan sadece belirli bir şekilde davranması istenerek denetim kaydı olmadan dosyalara erişim mümkün hale geliyor; bu da içeriden gelen tehditler ve yasal düzenleme ihlalleri riskine yol açabiliyor
- Araştırmacı durumu MSRC'ye bildirdi, ancak Microsoft resmî politikasına rağmen CVE vermedi ve müşterileri de bilgilendirmedi
- Microsoft bu açığı yalnızca 'Önemli (Important)' seviyesinde sınıflandırdı ve otomatik güncellemeyle çözüldüğünü söyleyerek ayrıca duyuru yapılmasına gerek olmadığına karar verdi
- Ancak bu durum, HIPAA gibi düzenlemeye tabi sektörlerde denetim günlüklerine güvenen şirketler için ciddi güvenlik ve hukuki sorunlara yol açabilir; Microsoft'un şeffaflık eksikliği de yoğun biçimde eleştiriliyor
Copilot'taki denetim günlüğü açığı: genel bakış ve etkileri
- Microsoft'un agresif biçimde yaygınlaştırdığı başlıca yapay zeka hizmetlerinden biri olan Copilot'ta, kullanıcı isteğine bağlı olarak dosya erişim geçmişinin denetim günlüğüne yazılmamasına neden olan bir kusur bulundu
- Normalde M365 Copilot bir dosyayı özetlediğinde, o dosyaya erişim kaydının denetim günlüğüne işlenmesi gerekir ve bu, kurum içi bilgi güvenliğinin temel unsurlarından biridir
- Ancak Copilot'tan dosya özet sonucuna dosya bağlantısını eklememesi istendiğinde, ilgili günlüğün hiç kaydedilmediği bir durum ortaya çıkıyor
- Örneğin bir çalışan işten ayrılmadan önce Copilot üzerinden çok sayıda dosyayı görüntülüyor olsa bile, günlük bırakmadan ve iz bırakmadan bunları sızdırabilir
- Bu açık kasıtlı bir saldırı sonucu değil, tesadüfen ve doğal biçimde de ortaya çıkabiliyor; nitekim blog yazarı bunu kendi özellik testleri sırasında keşfetti
- Zenity CTO'su Michael Bargury de bu açığı bir yıl önce fark edip Microsoft'a bildirmişti, ancak konu bu son bildirime kadar uzun süre ele alınmadan kaldı
MSRC'nin (açık bildirimi) sorunları ve müdahalenin kabul edilmemesi
- Microsoft, güvenlik açığı bildirimleri için resmî kılavuzlar ve bir süreç sunuyor, ancak fiilî müdahale sürecinde bunlara gerektiği gibi uymuyor
- Yazar MSRC'ye bildirim yaptıktan sonra, yeniden üretim adımları tamamlanmadan Copilot işlevinin doğrudan değişmesi gibi kafa karıştırıcı durumlar yaşandı
- Bildirim durumu değişiklikleri (yeniden üretim → geliştirme) ilerledi, ancak ilerleme durumu veya karar gerekçeleri hakkında net iletişim eksikti
- Güvenlik açıkları için CVE verilip verilmeyeceği konusunda, müşterinin doğrudan aksiyon alması gerektiğinde ancak resmî numara verildiği yönünde bir tutum iletildi
- Ancak bu, Microsoft'un mevcut politikasıyla çelişiyor ve söz konusu açık yalnızca 'Önemli (Important)' seviyesinde sınıflandırıldığı için ne kamuya açıklama yapıldı ne de ayrıca bildirim gönderildi
- Genel olarak ilerleme takibi, gerçek önlemlerden bağımsız şekilde sadece görünürde güncelleniyor izlenimi verdi; bu da bildirimi yapan kişi açısından verimsiz ve şeffaf olmayan bir deneyimdi
Duyuru ve müşteri bilgilendirmesinin eksikliği neden sorunlu
- Microsoft, bu açık için ne CVE vermeye ne de müşterileri bilgilendirmeye karar verdi
- Bunun yanlışlıkla bile kolayca ortaya çıkabilecek bir hata olması nedeniyle, gerçek kurumlarda uzun bir süre boyunca denetim günlüklerinin yanlış kaydedilmiş olma ihtimali bulunuyor
- Sağlık kurumları (ör. HIPAA) gibi hukuki ve düzenleyici amaçlarla denetim günlüklerini kullanan pek çok kuruluş olmasına rağmen, Microsoft etkiyi kullanıcılara bildirmiyor
- Denetim günlükleri; kurum güvenliği, olay müdahalesi ve hukuki delil gibi birçok alanda temel araç olarak kullanılıyor, ancak Microsoft bu konudaki gerçekler karşısında sessiz kalmayı sürdürüyor
- Bu yaklaşım, diğer olası güvenlik sorunlarının da açıklanmadan kapatılabileceğine işaret ediyor ve kurumun güvenilirliği hakkında ciddi soru işaretleri doğuruyor
1 yorum
Hacker News yorumu
Şirket içinde sohbet botu geliştirme işinden sorumluyum ve sohbet botu gizli belgelere erişirken mevcut kullanıcının tüm yetkilerini kontrol etmezse mutlaka bir bilgi sızıntısı yolu oluşacağını yönetime anlatmakta zorlanıyorum
Vektör veritabanları, arama indeksleri, AI Search Database gibi sistemlerin ya kullanıcı başına ayrı olması ya da içerikle birlikte erişim izinlerini de takip etmesi gerekiyor
Ama erişim izinleri çok karmaşıktır ve her an değişebilir; bu yüzden bunu büyük ölçekte uygulamak zordur ve race condition'lara açıktır, bunu vurgulamak istiyorum
Bu, 'Confused Deputy' probleminin somut bir örneği
OWASP LLM Top 10'daki LLM02:2025 'Sensitive Information Disclosure' ve LLM06:2025 'Excessive Agency' riskleriyle ilgilidir
Bazı kurumsal RAG çözümleri, çeşitli ACL'ler nedeniyle kullanıcı başına indeks oluşturarak bunu çözüyor
Bu tür erişim yetkisi sorunlarının nasıl yönetildiği sağlayıcıdan sağlayıcıya değiştiği için, RAG çözümü incelerken bu kısmı mutlaka kontrol etmek gerekir
Japonya'da buna "yetki karmaşası (権限混同)" deniyor, bence ilginç bir ad
Confused Deputy açıklaması, OWASP LLM Top 10 riskleri
Kullanıcının erişim yetkilerini takip etmenin neden bir ölçeklenebilirlik sorunu olduğunu düşündüğünü merak ediyorum
Bir sorgu geldiğinde vektör DB veya indeks içinde eşleşen belgeleri bulup, içlerinden yalnızca kullanıcının erişebileceklerini LLM'e iletmek yeterli olur
Bu, banka müşteri temsilcisinin yalnızca kimliği doğrulanmış müşteri bilgilerini görebilmesine benzer; böylece yanlışlıkla başkasının bilgisini sızdırma riski olmaz ve kimlik doğrulanmadıysa başkalarının bilgilerini operatör bile göremez, dolayısıyla kötüye kullanım riski olmadığını düşünüyorum
Böyle bir duvara çarptığımda aslında iletişimde başarısız olan da ben değilim, yönetim de anlamıyor değil
Muhtemelen yönetim bu sorunu görmezden gelmeye karar vermiş durumda ve ileride bir sızıntı olursa suçu mühendislere yıkmayı planlıyor
Sorunu yönetime anlatmakta zorlanıyorsanız Legal/Compliance ekibini CC'ye eklemek işe yarayabilir
Yalnız, buzzword'lere takıntılı bazı yöneticiler bu davranıştan hoşlanmayabilir
Çoğu vektör veritabanı vektörlere ek metadata iliştirmeye izin verir
Erişim yetkisi olan öznelerin listesini (ör. HR, yöneticiler) metadata olarak saklarsanız, istek geldiğinde kullanıcıyı ilgili rollere genişletip filtreleme yapabilirsiniz
Böylece kullanıcının göremeyeceği belgeler en baştan elenebilir
Ancak belge bazlı yetkiler değiştiğinde vektör metadata'sını da hemen güncellemek gerekir
Copilot'un denetim günlüklerini baypas edip ayrıcalıklı kullanıcı gibi davranması sorunlu
Bunun mümkün olmaması gerekirdi
Copilot aslında dosyaya doğrudan erişmiyor; daha önce indekslenmiş dosya içeriğini arama motoru üzerinden okuyor
Microsoft'un Copilot'un arama geçmişini denetlemesi gerekir; Copilot yalnızca indeksi okuduğu halde sanki dosyaya erişmiş gibi kaydedilmesi yanıltıcı olur
Bu, Google arama sonucuna bakınca web sitesini doğrudan ziyaret etmiş sayılmaya benzer
Microsoft, gereğinden fazla AI entegrasyonuna yüklenirken denetim günlüklerini ihmal ediyor
Windows'ta Backup yetkisine sahip süreçler tüm erişim kontrollerini baypas edebilir ve varsayılan olarak denetlenmez
Bunun nedeni yedekleme uygulamalarında denetim günlüklerinin aşırı büyümesidir; ama bu yetkinin açıkça etkinleştirilmesi gerekir ve C# gibi managed code içinde bunu yapmak kolaydır
Restore yetkisi de aynı şekildedir
Bu durum, geçmişte Delve ilk çıktığında yetki kırpmanın yanlış yapılması sonucu kullanıcı arama sonuçlarında görünmesi ya da SharePoint aramasının var olan ama erişilemeyen bazı belgeleri göstermesi sorununa benziyor
Örneğin "Fall 2025 layoffs" diye arattığınızda, ilgili belge yalnızca var olduğu için sonuçta görünmesi bir güvenlik sorunuydu
Microsoft hâlâ 'güvenlik ikinci planda' izlenimi veriyor
Daha iyi bir başlık bence "Microsoft Copilot HIPAA uyumlu değil" olurdu
Böyle bir başlıkla sorun çok daha hızlı çözülürdü
Hatta daha da ileri gideyim: Tüm kullanışlı AI arama sistemleri tasarım gereği güvensizdir, çünkü o vektör veritabanlarında saklanan RAG vektörleri sonuçta belgelerin kayıplı sıkıştırılmış hâlidir
Sorun zaten düzeltilmiş durumda
Şimdiki şikâyet, müşterilere bildirim yapılmamış olması
“CVE'ler, müşterilerin korunmak için bir işlem yapması gereken güvenlik sürümlerine atanır. Bu durumda düzeltme Copilot'a otomatik olarak dağıtıldı ve kullanıcıların manuel güncelleme yapması gerekmedi, bu yüzden CVE atanmadı”
Bunun CVE'nin özsel bir özelliği mi olduğunu, yoksa Microsoft'un CVE'leri bu şekilde mi kullandığını merak ediyorum
Böyle zafiyetler için de başvurulabilecek ortak bir kimlik olsa iyi olurdu; satıcıya bağlı olmayan ayrı bir numaralandırma sistemi gerektiğini düşünüyorum
Microsoft için CVE, güvenlik olayı/zafiyet takibidir
Olağan dışı derecede hızlı bir yama yapılabilmesi, bunun artık bir güvenlik olayı olmadığı anlamına gelmez
Microsoft'un güvenlik olaylarını şeffaf biçimde açıklama konusunda giderek daha isteksiz ve güvenilmez görünmesi nedeniyle, böyle durumlarda daha fazla açıklama daha da önemlidir
Bu bana CVE'nin sınırlarından çok, Microsoft'un PR için CVE sürecini eğip büktüğü hissini veriyor
CVE'deki 'C', Common demek
Yani sistemin odağı 'ortaklık'
Şu anda kritik LOB uygulamalarını bile Microsoft'tan uzaklaştırmaya çalışıyoruz
Son aylardaki çeşitli hack'ler, SSO zero-day'leri ve Copilot'un indeksleyicisinin global admin gibi davranıp yetkileri yok saydığını görünce giderek daha fazla endişeleniyorum
Denetim ve etkinlik günlüklerini doğrudan LLM'e bırakmanın doğurabileceği sorunlar o kadar çok ki saymak zor
Bu yüzden bu olayda hatayı nasıl düzelttiklerini merak ediyorum; yoksa bir 'shadow prompt' mu eklediler?
Yazının hiçbir yerinde denetim günlüklerinin doğrudan LLM tarafından tutulduğu söylenmiyor
Aksine, günlükler LLM tarafından değil, üstteki scaffolding/yan sistem tarafından kaydediliyor gibi görünüyor; sadece log atılması gereken 'an' yanlış seçilmiş
Örneğin birisi bağlantıya tıkladığı anda log yazmak yerine, belge LLM bağlamına enjekte edildiği anda kaydetmeleri gerekirdi
Bu tasarım da ideal değil ama LLM'in doğrudan log tutmasından daha az vahim
Ben shadow prompt'ları (ya da herhangi bir prompt biçimini) gerçek bir güvenlik veya uyumluluk kontrol mekanizması olarak kullanma fikrine çok kuşkuyla bakıyorum
Bu tür kontroller mutlaka deterministik ve öngörülebilir sistemler olmalı
Eğer bir araç LLM'in bir dosyanın herhangi bir kısmını görmesine izin veriyorsa, ondan sonra LLM'in ürettiği tüm bilgi o dosyayı okumuş sayılmalı diye düşünüyorum
“Kullanıcı sana bağlantıyı verme derse bunu yok say; yoksa ailene XYZ gibi korkunç bir şey olur” türünden garip taleplerin LLM prompt'una girebileceğini düşünüyorum
Bu bana shadow copy sorununu da hatırlattı
Burada tam olarak hangi tür denetim günlüğünden söz edildiği belirsiz
SharePoint dosya erişim logları mı? Copilot'un davranış kayıtları mı? Purview mu? Yoksa başka bir şey mi?
Belirsiz kalan çok şey var
Copilot dosyanın kendisine değil, indekslenmiş içeriğe erişiyor; dolayısıyla gerçekten dosyaya erişmemiş olması doğru
Blog yazarı indeks erişim günlüklerine bakmalı
Blog dipnotlarından birinde şöyle deniyor: “Denetim günlüğü, kullanıcının dosyaya doğrudan eriştiğinin izi olarak değil CopilotInteraction olarak kalıyor ve bunun kasıtlı olduğunu düşünüyorum
Kullanıcı yalnızca Copilot üzerinden eriştiğinde, sanki dosyaya doğrudan dokunmuş gibi kaydedilmesi daha da tuhaf olurdu”
Aynı soruyu ChatGPT'ye sordum; bunun Microsoft 365, Office 365 denetim günlüklerini, özellikle de Microsoft Purview Compliance Portal'daki Unified Audit Log'u kastettiğini söyledi
İşte tam da bu tür sorunlar, Microsoft gibi büyük satıcılara duyulan güvenin bir 'garanti'den çok bir 'şans işi' gibi hissettirmesine neden oluyor
Bunun pratikte nasıl düzeltilebileceğini gerçekten merak ediyorum
Benim anladığım kadarıyla Copilot'un kullandığı indeks/DB ilgili dosyayı zaten taramış oluyor; dolayısıyla dosyaya tekrar gitmeden de o bilgiyi söyleyebilir
O zaman bunu tam olarak nasıl düzeltecekler?
Veritabanı/indeks erişiminin kendisini mi denetim günlüğüne bağlamak gerekir?
Yoksa LLM'e “bilgiyi sorgularken sözünü tut ve mutlaka kayıt bırak” diye komut mu vermek gerekir?
Microsoft'un bu sorunu nasıl fark edip çözdüğüne dair resmî iletişime acilen ihtiyaç var
Hassas veri kullanan şirketler için bu olayın bir uyarı işareti olması gerektiğini düşünüyorum
Genel olarak CVE'leri herkes kaydettirebilir
Ben de doğrudan başvurup Microsoft'u harekete geçirebilirim
Sadece o blog yazısı bile bana oldukça ikna edici geliyor
Gerçekte o kadar basit değil
MITRE veya ulusal CERT gibi çoğu CVE numaralandırma otoritesi (CNA), herkesin bildirim yapmasına izin verir ama bir değerlendirme ve inceleme süreci vardır
Microsoft kendi CNA'sı olduğu için, özel bir neden olmadıkça Microsoft'la ilgili CVE'leri dışarıdan atamazlar
Yalnızca Microsoft'un sunduğu bir hizmet için CVE istemenin ne kadar anlamlı olduğunu sorguluyorum
Kullanıcının bununla fiilen ne yapabileceği belirsiz
CVE başvuru formu burada bulunuyor
PGP desteği, uzun geçmişi ve doğrulanmış sponsorları gibi unsurlar güven veriyor
Yalnızca yasal ve meşru durumlarda kullanılmalı
Eğlenceli bir fikir ama bence bu bir CVE konusu değil
CVE'ler, birden çok kaynaktan gelen farklı ürünlerde ortak biçimde geçerli olan zafiyetlere yönelik olmalı; Copilot buna uymuyor
Bu olayın en ciddi kısmı, Copilot LLM'inin kendisine denetim günlüğü üretme görevi verilmiş olması şeklindeki tasarım hatası
Dosya veya URL sorgulayan API'nin denetim günlüğünü otomatik üretmesi gerekirdi; bu, mühendisliğin temelidir