בידוד אפליקציות Win32 נמצא כעת בתצוגה מקדימה ציבורית, הנה מה שהוא עושה

בכנס Build השנתי שלה בחודש שעבר, הודיעה מיקרוסופט על היכולת לעשות זאת הפעל אפליקציות Win32 בבידוד ב-Windows 11. החברה לא נכנסה לפרטים רבים בפוסט הבלוג הראשוני שלה, אבל היא הדגישה את האפשרות להפעיל את Win32 יישומים בסביבת ארגז חול כך ששאר מערכת ההפעלה מאובטחת מפני זדוני פוטנציאלי תוֹכנָה. כעת, הוא חשף מידע נוסף על היכולת המסוימת הזו, כולל כיצד היא פועלת ומשתלבת בשאר תשתית האבטחה של Windows.

סגן נשיא מיקרוסופט לאבטחת מערכת ההפעלה והארגונית דייוויד ווסטון כתב משפט ארוך פוסט בבלוג, מסביר את אופיו של בידוד אפליקציות Win32. התכונה היא עוד אפשרות אבטחת ארגז חול בדיוק כמו ארגז חול של Windows ו-Microsoft Defender Application Guard, אבל הוא מבוסס על AppContainers, לא תוכנה מבוססת וירטואליזציה כמו שני אמצעי האבטחה האחרים. עבור אלה שלא מודעים לכך, AppContainers משמשים כדרך לשלוט בביצוע של תהליך על ידי עטיפה שלו והבטחה שהוא פועל ברמות הרשאות ויושרה נמוכות מאוד.

מיקרוסופט המליצה בחום להשתמש בקרת אפליקציות חכמה (SAC)

ובידוד אפליקציות Win32 במקביל תוך אבטחת סביבת Windows שלך מפני אפליקציות לא מהימנות המנצלות נקודות תורפה של 0 ימים. מנגנון האבטחה הקודם עוצר התקפות על ידי התקנת אפליקציות מהימנות בלבד בעוד שהאחרון יכול להיות משמש להפעלת אפליקציות בסביבה מבודדת ומאובטחת כדי להגביל את הנזק הפוטנציאלי ולהגן על המשתמש פְּרָטִיוּת. הסיבה לכך היא שלאפליקציה של Win32 הפועלת בבידוד אין את אותה רמת הרשאות כמו למשתמש של המערכת.

חברת הטכנולוגיה רדמונד זיהתה מספר מטרות מפתח של בידוד אפליקציות Win32. בתור התחלה, זה מגביל את ההשפעה של אפליקציה שנפרצה מכיוון שלתוקפים יש גישה נמוכה לחלק מה מערכת ההפעלה, והם יצטרכו לשרשר מתקפה מורכבת מרובת שלבים כדי לפרוץ את ארגז החול שלהם. גם אם הם מצליחים, זה נותן יותר תובנה גם לגבי התהליך שלהם, מה שהופך אותו למהיר הרבה יותר ליישם ולספק תיקוני הפחתה.

הדרך שבה זה עובד היא שאפליקציה מושקת לראשונה ברמות שלמות נמוכות דרך AppContainer, כלומר שיש להם גישה לממשקי API נבחרים של Windows ואינם יכולים להפעיל קוד זדוני הדורש הרשאות גבוהות יותר רמות. בשלב הבא והאחרון, עקרונות המינימום ההרשאות נאכפים על ידי מתן גישה מורשית לאפליקציה לאובייקטים הניתנים לאבטחה של Windows, אשר שווה ערך ליישום רשימת בקרת גישה לפי שיקול דעת (DACL) ב-Windows.

יתרון נוסף של בידוד אפליקציות Win32 הוא מאמץ מופחת של מפתחים מכיוון שיוצרי אפליקציות יכולים למנף את פרופיל יכולות האפליקציות (ACP) זמין ב-GitHub כדי להבין אילו הרשאות הם בדיוק צריכים. הם יכולים להפעיל את ACP ולהפעיל את האפליקציה שלהם ב"מצב למידה" בבידוד אפליקציות Win32 כדי לקבל יומנים על היכולות הנוספות שהם צריכים כדי להפעיל את התוכנה שלהם. ACP מופעל על ידי מנתח הביצועים של Windows (WPA) אחורי של שכבת הנתונים ויומני מעקב אחר אירועים (ETL). ניתן פשוט להוסיף את המידע מהיומנים שנוצרו בתהליך זה לקובץ המניפסט של החבילה של האפליקציה.

לבסוף, בידוד אפליקציות Win32 שואף להציע חווית משתמש חלקה. בידוד אפליקציות Win32 מקל על כך על ידי דרישה מאפליקציות להשתמש ביכולת "isolatedWin32-promptForAccess" להנחות את המשתמש במקרה שהוא זקוק לגישה לנתונים שלו כגון ספריות NET ורישום מוגן מפתחות. ההנחיה צריכה להיות משמעותית עבור המשתמש שממנו מתקבלת הסכמה. לאחר מתן גישה למשאב, זה מה שקורה לאחר מכן:

כאשר המשתמש נותן הסכמה לקובץ ספציפי עבור האפליקציה המבודדת, האפליקציה המבודדת מתממשקת עם Windows מערכת קבצים תיווך (BFS) ומעניק גישה לקבצים באמצעות מנהל התקן מסנן מיני. BFS פשוט פותח את הקובץ ומשמש כממשק בין האפליקציה המבודדת ל-BFS.

וירטואליזציה של קבצים ורישום עוזרת להבטיח שהאפליקציות ימשיכו לעבוד מבלי לעדכן את קובץ הבסיס או הרישום. זה גם ממזער כל חיכוך חווית משתמש תוך שמירה על תאימות יישומים. מרחבי שמות מוגנים נוצרים כדי לאפשר גישה רק לאפליקציה ואינם דורשים הסכמת משתמש. לדוגמה, ניתן להעניק גישה לתיקיה שיש לה מאפיין המוכר רק לאפליקציית Win32 ונדרש לתאימות אפליקציה.

מיקרוסופט הדגישה שכדי לקבל שוויון תכונה בין מבודד ללא מבודד יישומי Win32, הראשונים יכולים ליצור אינטראקציה עם מערכת הקבצים וממשקי API אחרים של Windows על ידי מינוף של Windows BFS. יתרה מכך, ערכים במניפסט של האפליקציה גם מבטיחים שהאפליקציה יכולה ליצור אינטראקציה בטוחה עם רכיבי Windows כמו התראות מעטפת וסמלים במגש המערכת. אתה יכול למד עוד על היוזמה ב-GitHub כאן.