Win32 აპლიკაციის იზოლაცია არის უსაფრთხოების შესანიშნავი შესაძლებლობა, რომელიც Microsoft-მა გასულ თვეში შემოიტანა Windows 11-ში, ასე მუშაობს.
გასულ თვეში ყოველწლიურ Build კონფერენციაზე Microsoft-მა გამოაცხადა ამის შესაძლებლობა გაუშვით Win32 აპლიკაციები იზოლირებულად Windows 11-ზე. კომპანია თავის თავდაპირველ ბლოგ პოსტში ბევრ დეტალს არ შეუდგებოდა, მაგრამ მან ხაზი გაუსვა Win32-ის გაშვების ვარიანტს. აპლიკაციები sandbox გარემოში, რათა დანარჩენი ოპერაციული სისტემა დაცული იყოს პოტენციურად მავნე ზემოქმედებისგან პროგრამული უზრუნველყოფა. ახლა მან გამოავლინა მეტი ინფორმაცია ამ კონკრეტული შესაძლებლობის შესახებ, მათ შორის, თუ როგორ მუშაობს და ჯდება Windows-ის უსაფრთხოების დანარჩენ ინფრასტრუქტურაში.
Microsoft-ის OS უსაფრთხოებისა და საწარმოს ვიცე-პრეზიდენტმა დევიდ ვესტონმა დაწერა ხანგრძლივი ბლოგის პოსტი, განმარტავს Win32 აპლიკაციის იზოლაციის ბუნებას. ფუნქცია არის კიდევ ერთი Sandbox უსაფრთხოების ვარიანტი, ისევე როგორც Windows Sandbox და Microsoft Defender Application Guard, მაგრამ ის ეფუძნება AppContainers-ს და არა ვირტუალიზაციაზე დაფუძნებულ პროგრამულ უზრუნველყოფას, როგორც დანარჩენი ორი უსაფრთხოების ზომა. მათთვის, ვინც არ იცის, AppContainers ემსახურება როგორც პროცესის შესრულების კონტროლის გზას მისი ინკაფსულაციის გზით და იმის უზრუნველსაყოფად, რომ ის მუშაობს ძალიან დაბალ პრივილეგიასა და მთლიანობის დონეზე.
Microsoft მკაცრად გირჩევთ გამოიყენოთ Smart App Control (SAC) და Win32 აპის იზოლაცია ტანდემში, ხოლო თქვენი Windows გარემოს დაცვა არასანდო აპებისგან, რომლებიც იყენებენ 0-დღიან დაუცველობას. ყოფილი უსაფრთხოების მექანიზმი აჩერებს შეტევებს მხოლოდ სანდო აპლიკაციების დაყენებით, ხოლო მეორე შეიძლება იყოს გამოიყენება აპების იზოლირებულ და უსაფრთხო გარემოში გასაშვებად, პოტენციური ზიანის შესაზღუდად და მომხმარებლის დასაცავად კონფიდენციალურობა. ეს იმიტომ ხდება, რომ Win32 აპს, რომელიც მუშაობს იზოლირებულად, არ აქვს იგივე პრივილეგიის დონე, როგორც სისტემის მომხმარებელს.
Redmond ტექნიკურმა ფირმამ დაადგინა Win32 აპლიკაციის იზოლაციის რამდენიმე ძირითადი მიზანი. დასაწყისისთვის, ის ზღუდავს ზემოქმედებას კომპრომეტირებული აპისგან, რადგან თავდამსხმელებს აქვთ დაბალი პრივილეგიით წვდომა ნაწილზე. ოპერაციული სისტემა და მათ დასჭირდებათ კომპლექსური, მრავალსაფეხურიანი შეტევა, რათა გაარღვიონ თავიანთი ქვიშის ყუთი. მაშინაც კი, თუ ისინი წარმატებულები არიან, ეს უფრო მეტ ხედვას აძლევს მათ პროცესს, რაც ბევრად უფრო აჩქარებს შემარბილებელი პატჩების დანერგვას და მიწოდებას.
ეს არის ის, რომ აპლიკაცია პირველად იხსნება დაბალ მთლიანობის დონეზე AppContainer-ის მეშვეობით, რაც ნიშნავს რომ მათ აქვთ წვდომა Windows-ის შერჩეულ API-ებზე და არ შეუძლიათ მავნე კოდის შესრულება, რომელიც მოითხოვს უფრო მაღალ პრივილეგიას დონეები. შემდეგ და ბოლო ეტაპზე, მინიმალური პრივილეგიის პრინციპები სრულდება Windows-ის უსაფრთხო ობიექტებზე აპისთვის ავტორიზებული წვდომის მინიჭებით, რაც ექვივალენტურია დისკრეციული წვდომის კონტროლის სია (DACL) Windows-ზე.
Win32 აპლიკაციის იზოლაციის კიდევ ერთი უპირატესობა არის დეველოპერის ძალისხმევა, რადგან აპლიკაციის შემქმნელებს შეუძლიათ გამოიყენონ აპლიკაციის შესაძლებლობების პროფილი (ACP) ხელმისაწვდომია GitHub-ზე იმის გასაგებად, თუ რა ნებართვები სჭირდებათ მათ. მათ შეუძლიათ ჩართონ ACP და გაუშვან თავიანთი აპი "სწავლის რეჟიმში" Win32 აპლიკაციის იზოლაციაში, რათა მიიღონ ჟურნალები დამატებითი შესაძლებლობების შესახებ, რაც მათ სჭირდებათ პროგრამული უზრუნველყოფის გასაშვებად. ACP იკვებება Windows Performance Analyzer (WPA) მონაცემთა ფენის ფენით და მოვლენის კვალის ჟურნალებით (ETL). ამ პროცესით გენერირებული ჟურნალებიდან ინფორმაცია უბრალოდ შეიძლება დაემატოს აპლიკაციის პაკეტის მანიფესტის ფაილს.
დაბოლოს, Win32 აპლიკაციის იზოლაცია მიზნად ისახავს მომხმარებლის უწყვეტი გამოცდილების შეთავაზებას. Win32 აპლიკაციის იზოლაცია ხელს უწყობს ამას იმით, რომ აპებს სთხოვს გამოიყენონ "isolatedWin32-promptForAccess" შესაძლებლობა მომხმარებლის მოთხოვნით იმ შემთხვევაში, თუ ისინი მოითხოვენ წვდომას მის მონაცემებზე, როგორიცაა .NET ბიბლიოთეკები და დაცული რეესტრი გასაღებები. მოთხოვნა უნდა იყოს მნიშვნელოვანი მომხმარებლისთვის, ვისგანაც თანხმობა მიიღება. რესურსზე წვდომის მინიჭების შემდეგ, ეს ხდება შემდეგში:
როდესაც მომხმარებელი თანხმობას ანიჭებს კონკრეტულ ფაილს იზოლირებული აპლიკაციისთვის, იზოლირებული აპლიკაცია Windows-თან ინტერფეისი ხდება საბროკერო ფაილური სისტემა (BFS) და ანიჭებს ფაილებზე წვდომას მინი ფილტრის დრაივერის მეშვეობით. BFS უბრალოდ ხსნის ფაილს და ემსახურება როგორც ინტერფეისს იზოლირებულ აპლიკაციასა და BFS-ს შორის.
ფაილისა და რეესტრის ვირტუალიზაცია ეხმარება აპებმა გააგრძელონ მუშაობა და არ განახლდეს საბაზისო ფაილი ან რეესტრი. ეს ასევე ამცირებს მომხმარებლის გამოცდილების ნებისმიერ ხახუნს აპლიკაციის თავსებადობის შენარჩუნებისას. დაცული სახელთა სივრცეები იქმნება მხოლოდ აპზე წვდომის დასაშვებად და არ საჭიროებს მომხმარებლის თანხმობას. მაგალითად, შეიძლება მიენიჭოს წვდომა საქაღალდეზე, რომელსაც აქვს თვისება, რომელიც ცნობილია მხოლოდ Win32 აპისთვის და საჭიროა აპის თავსებადობისთვის.
Microsoft-მა ხაზგასმით აღნიშნა, რომ იზოლირებულ და არაიზოლირებულ მახასიათებლებს შორის თანასწორობის არსებობის მიზნით Win32 აპებს, პირველს, შეუძლიათ ურთიერთქმედება ფაილურ სისტემასთან და Windows-ის სხვა API-ებთან Windows-ის გამოყენებით BFS. უფრო მეტიც, აპლიკაციის მანიფესტში ჩანაწერები ასევე უზრუნველყოფს, რომ აპს შეუძლია უსაფრთხოდ დაუკავშირდეს Windows ელემენტებს, როგორიცაა shell შეტყობინებები და ხატულები სისტემის უჯრაში. Შენ შეგიძლია შეიტყვეთ მეტი GitHub-ის ინიციატივის შესახებ აქ.