Windows 11'in Win32 uygulama izolasyonunu tek seferlik bir anahtar değil, yetenek bütçesi olarak görün

Yönetilmesi gereken bir sandbox

dev.to'da yayımlanan bir yazı, Windows 11'in Win32 uygulama izolasyonunun gerçek bir güvenlik değeri sağlamasının, her uygulamaya verilen yeteneklerin (capability) sürekli gözden geçirilen bir bütçe olarak ele alınmasına bağlı olduğunu, dağıtım sırasında bir kez belirlenip unutulmaması gerektiğini savunuyor.

Özellik, Microsoft'un dokümantasyonuna göre Windows 11 sürüm 24H2 ve sonrasında kullanılabilir ve geleneksel masaüstü uygulamalarını bir sandbox içine alıyor. Uygulama sıradan bir Windows süreci olarak çalışmaya devam ediyor, ancak dosyalara, cihazlara ve diğer kaynaklara erişimi yetenekler aracılığıyla düzenleniyor. Yazarın temel noktası şudur: güvenlik sonucu neredeyse tamamen hangi yetenekleri devrettiğinize bağlıdır ve çok fazla yetenek devretmek bu faydayı ortadan kaldırır.

Profiler önerir, yönetici karar verir

Microsoft, bir uygulamayı öğrenme modunda çalıştırabilen bir Application Capability Profiler ile geliyor; bu araç, izolasyon altında normalde reddedilecek işlemlere izin verirken uygulamanın ihtiyaç duyacağı ek yetenekleri kayıt altına alıyor. dev.to yazısı bu çıktıyı doğrudan içe aktarılacak bir politika değil, bir taslak olarak ele alıyor: her yetenek, yazılımın gerçekte ne yaptığıyla gerekçelendirilmeli. Bir medya düzenleyicisinin kullanıcı tarafından seçilen bir klasöre ihtiyaç duyması makuldür; bir build aracının bir çalışma dizinine ve bir ağ hedefine ihtiyacı vardır; bir belge dönüştürücünün kullanıcının tüm profilini veya çıkarılabilir sürücüleri okuması için görünür bir nedeni yoktur.

Onay istemleri de benzer bir dikkatle ele alınıyor. Yazıda atıf yapılan Microsoft'un onay (consent) dokümantasyonu, bazı kaynak erişimlerinin kullanıcı kararını içerebileceğini gösteriyor. Ancak bir istem yalnızca talebi görünür kılar — talebi uygun hale getirmez ve en az ayrıcalık ilkesinin yerine geçmez.

Paket kimliği davranışı değiştirir

İzolasyon ayrıca uygulamaya bir package identity ve bir application identity atar ve bu da zemini değiştirir: log konumları, dosya yolları ve registry konumları paketlenmemiş bir build'den farklı olabilir. Kendi çalıştırılabilir dosyasının yanına yazan yazılım, rastgele yollardan plug-in yükleyen veya global bileşenler kaydeden yazılım, dağıtım ayarlanana kadar başarısız olabilir.

Yazıya göre dağıtımların genellikle tam bu noktada ters gittiği görülüyor. Giriş ekranında sona eren testler, updater'ı, dışa aktarma yolunu, tarayıcı entegrasyonunu ve crash handler'ı — yani daha sonra farklı bir yetenek kümesi altında çalışan bileşenleri — gözden kaçırıyor. Tek bir başarısızlık çoğu zaman bir yöneticiyi geniş yeteneklere itmek için yeterlidir ve bu da izolasyonu sessizce etkisiz hale getirir.

Çalıştırılabilir dosyayı değil, iş akışını test edin

Önerilen uygulama, tek bir uygulama seçip gerçekte dokunduğu verileri haritalamaktır: dosyaları açma ve kaydetme, donanım cihazlarını kullanma, güncellemeleri çalıştırma, dış yardımcıları çağırma, ağ paylaşımlarına erişme. Testleri standart kullanıcı ve yönetici olarak tekrarlayın, çünkü bir yönetici hesabı üretimdeki davranış hakkında hiçbir şey kanıtlamaz.

Profiler'ın ekledikleri, uygulama sahibinin yazılımın ne yaptığı söylediğiyle karşılaştırılmalıdır. Bir yeteneğin uygulamanın işiyle ilgisi yoksa soru şu haline gelir: özellik devre dışı bırakılabilir mi ya da ayrı bir sürece bölünebilir mi — bir plug-in host, bir okuyucudan meşru olarak daha fazla erişime ihtiyaç duyabilir. Windows event log'ları ve uygulamanın kendi tanılama araçları reddedilen işlemleri görünür kılmalıdır ve her reddedilme önce bir daraltma sorusu sormalıdır: işlem gerekli mi, yol kısıtlanabilir mi, kullanıcı tarafından seçilen bir dosya ya da bir broker aracılığıyla yapılan bir işlem yerine geçebilir mi? Geniş yetenekler son çaredir.

Bir program değil, bir katman

Yazı sınırlar hakkında açık sözlü. İzolasyon; yama yönetimini, uygulama denetimini, EDR'yi ve ağ segmentasyonunu tamamlar; onların yerine geçmez. Ayrıca bir uygulamaya meşru olarak erişim verildikten sonra koruma sunmaz — ele geçirilmiş izole bir süreç, elindeki hangi yetenek varsa onları hâlâ kötüye kullanabilir.

Pratik öneri, package identity, yetenekler, sahip ve test kanıtını kaydeden uygulama başına bir manifesto'dur; updater'lar yeni çalıştırılabilir dosyalar ekleyebileceği veya uygulamanın ağa erişim biçimini değiştirebileceği için her yükseltmeden sonra yeniden denetlenmelidir. Dağıtım için, en olası şekilde kırılacak uygulamalardan oluşan bir pilotla başlayın: tarayıcılar, işbirliği istemcileri, geliştirici araçları ve yerel yardımcıları olan iş uygulamaları. Cihaz sayısına göre değil, uygulama sahibine göre genişletin ve her sürümü dört soruya bağlayın: uygulama geniş yetenekler olmadan temel iş akışını tamamlayabiliyor mu, updater aynı izolasyon politikasını izliyor mu, reddedilen işlemler loglanıp doğru sürece atanıyor mu ve sahip, kullanıcıyı bozmadan bir yeteneği kaldırabiliyor mu?

Neden önemli

Paketli uygulama çağından çok önce yazılmış masaüstü yazılımları, Windows'taki en yaygın ve en az kontrol altına alınmış saldırı yüzeylerinden biri olmaya devam ediyor. Win32 uygulama izolasyonu, örtük güveni açık ve denetlenebilir yetenek kararlarına dönüştürüyor — gerçek bir iyileştirme, ancak dev.to yazarının uyardığı gibi, bu fayda yalnızca yetenek listesi dar kaldığı, test edildiği ve yazılım her değiştiğinde yeniden gözden geçirildiği sürece sürer. Tek seferlik bir anahtar olarak ele alındığında, sandbox bir uyumluluk geçici çözümüne dönüşür.