AppLocker, App Control for Business (WDAC) והפצת אפליקציות עסקיות — לפני ש-execution control חוסם אתכם

“התקנו את זה במחשב של הלקוח והאפליקציה לא עולה. לחיצה כפולה לא עושה כלום.” כשמפיצים אפליקציה עסקית, הסיבה יכולה להיות לא רק פגם באפליקציה עצמה אלא application execution control בסביבה של הלקוח. לפעמים ה-exe עולה ורק ה-DLLים או ה-scripts שנשלחים איתו נעצרים.

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

המאמר הזה מסדר את ה-execution control של Windows מנקודת המבט של מי שבונה ומפיץ את האפליקציה. אחרי שמבהירים את ההבדלים בין AppLocker, App Control for Business (לשעבר WDAC = Windows Defender Application Control), Smart App Control ו-SmartScreen, עוברים לחסימות האופייניות, לאופן קריאת ה-event logs ולהכנה שצריך לעשות לפני ההפצה. בסוף מובא גם נוהל למחלקת ה-IT שמטמיעה את הבקרות האלה במחשבים שלה.

1. קודם כל השורה התחתונה

• מתחילים בהבחנה בין ארבעת המנגנונים, ואז מזהים את היעד ב-log. אזהרה של SmartScreen, בקרה per-user ו-per-group של AppLocker, בקרה machine-wide של App Control וההגנה של Smart App Control למחשבים אישיים — אלה לא אותו דבר. ב-exe או DLL תחת AppLocker החקירה מתמקדת ב-8004; תחת App Control היא מתמקדת ב-3077 ובפרטי החתימה ב-3089. ב-scripts וב-MSI בודקים גם את ה-log האחר.¹²
• בצד שמפיץ — בונים אפליקציה שכללי ההרשאה שלה עדיין תואמים אחרי עדכון. הליבה היא חתימה עקבית שמכסה לא רק את ה-exe אלא גם את ה-DLLים, את ה-installer ואת ה-scripts הנלווים. מסדרים גם את פרטי ה-publisher, את מאפייני הקבצים, את תיקיית ההתקנה ואת זרימת ה-auto-update. גם במחשב שאינו בניהול ארגוני, Smart App Control עלול לעצור אפליקציה לא חתומה.³⁴
• בצד שמטמיע — מריצים מחזור עסקי מלא במצב audit לפני המעבר לאכיפה. בוחרים App Control היכן שאפשר, ומשתמשים ב-AppLocker כשנדרשת בקרה per-user. אי אפשר להניח ש”המחשבים של הלקוח הם Pro, אז זה לא נוגע לנו”. ב-Windows 10 2004 ומעלה עם KB 5024351 וב-Windows 11, אכיפת AppLocker אינה דורשת מהדורה מסוימת, ו-App Control תומך בכל מהדורות ה-client.³⁵

איך לקרוא את המאמר לפי מטרה

ב-PowerShell קורה לעיתים ש-script לא נחסם לגמרי אלא רץ ב-Constrained Language Mode, ורק חלק מהעיבוד נכשל. על ההבדל הזה עוסק גם פרק 4.²

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 36, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. להבחין בין ארבעת המנגנונים

למוצרים האלה יש שמות דומים ומבלבלים, ולכן מפרידים ביניהם לפי “היעד”, “איך זה נכנס לתוקף” ו”מי מנהל את זה”. קודם כל מבררים אם מה שלפניכם הוא אזהרה שצריך לטפל בה, או השוואה מול כללי ההרשאה של מנהל.

2.1. SmartScreen — המנגנון היחיד שעוצר באזהרה

SmartScreen מתריע על סמך ה-reputation של הקובץ. הוא פועל כברירת מחדל בלי שאף מנהל כותב כללים, ובאופן רגיל המשתמש יכול לעבור את האזהרה ולהריץ את הקובץ.

עם זאת, אם policy ניהולי שאוסר לעבור את האזהרה נמצא בתוקף, גם SmartScreen הופך בפועל לחסימה. המסקנה “זו רק אזהרה, אז תמיד אפשר להריץ” אינה נכונה.

את הצעדים בצד שמפיץ מפרידים מלבקש מהלקוח לכתוב כללי הרשאה ל-AppLocker וכדומה. ב-SmartScreen מה שמרכזי הוא חתימה וצבירת reputation. הנושא מכוסה בהרחבה ב”Windows SmartScreen וחתימת קוד”. הסעיפים 2.2 עד 2.4 הם מנגנונים שחוסמים הרצה ולא מתריעים.

2.2. AppLocker — הוותיק שמאפשר בקרה per-user

על סמך מה, ואת ההרצה של מי, הוא מבקר

AppLocker הוצג ב-Windows 7. הכללים שלו מבוססים על מאפייני certificate חתימת הקוד (ה-publisher), מאפייני קבצים שמגיעים מה-metadata של החתימה (שם הקובץ המקורי והגרסה), ה-hash ונתיב הקובץ. אפשר להחיל policy לא רק על כל המחשב אלא גם על users ו-groups מסוימים.³

להפריד בין “אפשר ליצור כללים” ל”אפשר לאכוף אותם”

דרישות המהדורה קלות יותר להבנה כשמפרידים בין השניים. מ-KB 5024351 ואילך, אכיפת policy של AppLocker אינה דורשת מהדורה מסוימת ב-Windows 10 גרסה 2004 ומעלה, ובאף מהדורה של Windows 11.⁵

ב-Windows ישן יותר, לעומת זאת, נשאר הבדל לפי שיטת ההפצה. בסביבה שכוללת גרסאות Windows 10 שלפני 2004 או Windows Server 2019, התנאים הקודמים עדיין תקפים: אכיפה של policy שמופץ ב-Group Policy מוגבלת למהדורות Enterprise ו-Server, ואילו הפצה ב-MDM עובדת בכל מהדורה.⁵

אפשר ליצור כללים גם ב-Pro. המגבלה הקודמת נגעה בעיקר לאם הם נאכפים, ובהפצה ב-MDM גם Pro יכול היה לאכוף אותם אז. גם אוספי הכללים — קובצי הרצה, קובצי Windows Installer, scripts, DLLים ו-packaged apps — אינם משתנים לפי מהדורה.⁵

יש גם תנאי מוקדם שאינו קשור למהדורה. אם שירות Application Identity (AppIDSvc) אינו פועל, הכללים אינם נבחנים. על זה ועל ההכנה ל-audit עוסק פרק 6.

המקום שלו כתכונת אבטחה

Microsoft מצהירה במפורש ש-AppLocker אינו עומד בקריטריוני ה-servicing של MSRC לתכונת אבטחה. כלומר, אם נמצאה טכניקת עקיפה, העובדה הזאת לבדה אינה מטופלת כפגיעות אבטחה. זו עוד נקודה שבה הוא שונה מ-App Control, שיידון בהמשך.³

2.3. App Control for Business — הפתרון המרכזי כתכונת אבטחה

מנגנון שחל על כל המחשב

App Control for Business הוא השם הנוכחי של המנגנון שנקרא ב-Windows 10 “configurable code integrity” כחלק מ-Device Guard. במשך זמן רב הוא נקרא WDAC. ה-policies שלו חלות על כל המחשב ומשפיעות על כל משתמש במכשיר. זה מנגנון שתוכנן כתכונת אבטחה לפי הגדרת ה-servicing criteria של MSRC.³

אפשר לפרק את סוגי הבסיס לכללים כך.³

תנאי שימוש ודרכי הפצה

אפשר ליצור ולהחיל policies ב-כל מהדורת client של Windows 10/11, או ב-Windows Server 2016 ומעלה. להפצה אפשר להשתמש ב-MDM כמו Intune, ב-Configuration Manager או ב-PowerShell. אפשר גם ב-Group Policy, אבל שימו לב שהוא מוגבל לפורמט ה-single policy שעובד ב-Windows Server 2016/2019.³

איך בוחרים בינו לבין AppLocker

Microsoft ממליצה להשתמש ב-App Control בכל מקום שבו אפשר לממש בו את מה שצריך. App Control ממשיך להשתפר, ואילו AppLocker מקבל תיקוני אבטחה אבל לא תכונות חדשות.³

AppLocker מתאים כשרוצים להפיץ את אותה policy בסביבה מעורבת שכוללת Windows ישן, או כשצריך כללים שונים per-user ו-per-group במחשב משותף. אפשר להשתמש בו גם כהשלמה ל-App Control, כדי להוסיף הגבלות per-user.³

2.4. Smart App Control — execution control שכבר נמצא במחשבים אישיים

Smart App Control הוא תכונת הגנה למשתמשים פרטיים ב-Windows 11. בזמן הרצה הוא בודק את התחזית של שירות אבטחה בענן לגבי בטיחות האפליקציה, ומחפש חתימה תקפה. הוא חוסם אפליקציות שנקבע שהן זדוניות, וגם אפליקציות שאין להן חתימה תקפה ואי אפשר לאמת את מהימנותן.⁴

במחשב חדש הוא מתחיל במצב הערכה, ו-Windows מחליט אם הוא מתאים למשתמש הזה לפני שהוא מדליק או מכבה אותו. במשתמשים שצפויים להיתקל בחסימות לעיתים קרובות, כמו מפתחים, הוא נכבה אוטומטית.⁴

הנקודה עבור מי שמפיץ היא שexecution control פועל גם במחשבים שבהם מחלקת IT לא כתבה שום policy. עסקים קטנים ועצמאיים בין הלקוחות שלכם אינם פטורים. אפליקציות לא חתומות עלולות להיעצר, ו-Microsoft עצמה מפנה מפתחים לחתום ב-certificate תקף. איך בוחרים certificate — בפרק 5.⁴

3. הדפוסים האופייניים שבהם האפליקציה שלכם נחסמת

בודקים לא רק “האם התוכנית הראשית עולה”, אלא גם התקנה, טעינת DLLים, scripts, plug-ins ו-auto-update. הדפוסים שהכי שכיח לגרום לבעיות בפיתוח מוזמן ובהפצת חבילות הם אלה.

הסיבה המשותפת היא שהבסיס לכללי ההרשאה אינו יציב

המשותף לטבלה הוא שהצד שמפיץ לא מספק, בצורה יציבה, את הבסיס שמי שמתיר צריך: החתימה, הנתיב או ה-hash.

חתימה על ה-exe בלבד, למשל, פירושה שאי אפשר להשתמש באותו publisher rule עבור DLLים לא חתומים. התרה שלהם בכללי hash נפרדים פירושה שצריך לעדכן את הכללים בכל פעם שעדכון משנה את ה-binaries. זה יכול להיראות כאילו הבקרות של הלקוח הן הסיבה, כשבפועל תוצרי ההפצה או שיטת העדכון הם שהופכים את הכללים לשבירים.

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

4. לקבוע מה קרה מתוך ה-logs

ב-event log קוראים את “העובדה שמשהו נעצר” ואת “מה צריך לתקן” כשני דברים נפרדים. שתי נקודות הכניסה הן ה-logs תחת AppLocker וה-log של CodeIntegrity, אבל החשוב הוא שגם אירועים של App Control נרשמים תחת log בשם AppLocker.²

4.1. אירועים של AppLocker

לפתוח את ה-log ולבחור את סוג היעד

פותחים את Event Viewer על ידי חיפוש “Event Viewer” בתפריט Start, או על ידי הקלדת eventvwr.msc בחלון Run.¹

Event Viewer > Applications and Services Logs > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

בסביבה באנגלית הנתיב הוא Applications and Services Logs > Microsoft > Windows > AppLocker, וכל מה שמתחת לשם ה-provider של AppLocker, כולל EXE and DLL, נשאר באנגלית.

כדי לשלוף אותם ב-PowerShell, פותחים סשן עם הרשאות מנהל ומריצים את הפקודה הבאה. הדוגמה הזאת מוציאה רק audit וחסימות של exe/DLL מ-24 השעות האחרונות. scripts ו-MSI לא נכללים.

# שליפת חסימות (8004) ו-audit (8003) של AppLocker מ-24 השעות האחרונות
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

זה תאם כלל חסימה, או שחסר כלל הרשאה?

האירוע רושם את נתיב הקובץ הנדון, אם הוא הותר או נחסם, את סוג הכלל (path, hash או publisher), את שם הכלל ואת ה-SID של המשתמש או הקבוצה.¹

בעבודה עם allow-list, לעומת זאת, רוב המקרים הם חסימה משתמעת, שבה הקובץ לא תאם שום כלל הרשאה.

אירוע 8004 אומר לכם שנעשתה חסימה ומה נחסם, אבל בחסימה משתמעת שם הכלל לבדו לא יזהה את הסיבה. צריך להשוות את האירוע ל-policy שבתוקף, ולא רק להסתכל על האירוע.

4.2. אירועים של App Control for Business (WDAC)

exe, DLLים ו-drivers נמצאים ב-log אחר מ-scripts וכדומה

לבקרה על קובצי exe, DLLים ו-drivers בודקים את ה-log הבא של CodeIntegrity. בקרה על MSIים, scripts ו-COM נרשמת ב-log AppLocker - MSI and Script שהוזכר קודם.²

Event Viewer > Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational (בסביבה באנגלית זה הנתיב הזה, ו-CodeIntegrity ו-Operational נשארים באנגלית)

# צפייה בחסימות (3077) וב-audit (3076) של App Control יחד עם פרטי החתימה המתאימים (3089)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

מה שהפקודה הזאת שולפת הוא CodeIntegrity 3076, 3077 ו-3089. כשחוקרים MSIים, scripts או COM, פעלו לפי הטבלה שלמטה ובדקו בנפרד גם את AppLocker - MSI and Script. כל עוד לא ידוע איזה מנגנון מעורב, סדרו את ה-logs תחת AppLocker ואת CodeIntegrity באותו טווח זמן.

להשתמש ב-3089 כדי לבדוק את החתימה שנבדקה בפועל

נוצר אירוע 3089 אחד לכל חתימה על הקובץ. בקובץ לא חתום נפלט אירוע אחד עם מספר חתימות אפס. הוא מותאם ל-3076, ל-3077 ולאחרים לפי correlation Activity ID.²

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

גם עם 8029, PowerShell לא בהכרח נעצר לגמרי

אירוע 8029 מציין ש-script נחסם, אבל התנהגות האכיפה בפועל נתונה בידי ה-script host. PowerShell לא עוצר לגמרי script שה-policy אינו מתיר; הוא מריץ אותו ב-Constrained Language Mode.²

במצב הזה יצירת אובייקטים של .NET מוגבלת מאוד. התוצאה היא התסמין “ה-script התחיל, אבל שורה אחת באמצע נכשלה”. בחקירת script נלווה, אל תשפטו לפי אם הוא עלה. הצד המעשי של החתימה נמצא ב”Execution Policy וחתימת סקריפטים ב-PowerShell”.

שימו לב גם שבמהדורת Windows Server Core אין log של AppLocker - MSI and Script. בחקירת אפליקציה על שרת, גם קיומו של ה-log דורש תשומת לב.²

5. מה יכול הצד שמפיץ — לבנות אפליקציה שקל לכתוב לה כללים

המטרה היא לשלוח מוצר במצב שבו מחלקת ה-IT של הלקוח יכולה לכתוב כללי הרשאה יציבים. החתימה היא האמצעי המרכזי, אבל היא לא אומרת שחתימה לבדה מאפשרת לאפליקציה לרוץ בלי קשר ל-policy של הלקוח. יש שישה דברים לסדר.

ההכנה הזאת עוזרת גם ל-Smart App Control. binary חתום שצבר reputation פחות סביר שייתפס בחסימה האוטומטית במחשב אישי.⁴

5.1. פעם ראשונה שמוציאים certificate לחתימת קוד

לבחור certificate RSA מרשות אישורים מהימנה

כשמפיצים ללקוחות חיצוניים, בוחרים certificate חתימת קוד מבוסס RSA שהונפק על ידי רשות אישורים ציבורית (מסחרית). certificate self-signed או כזה של CA פנימית לא ניתן לאימות במחשב של לקוח שאינו סומך על אותה CA, וגם Smart App Control אינו תומך בו.⁶

בדקו גם את האלגוריתם. בדיקת החתימה של Smart App Control אינה תומכת בחתימות elliptic curve cryptography (ECC). אם תחתמו ב-ECC, הקובץ עלול להיות מטופל כקובץ לא חתום בפועל במחשבים אישיים.⁶

גם ב-App Control, כללים מבוססי חותם תומכים רק ב-RSA (עד 4096 סיביות). אם תנסו להתיר חתימת ECDSA בכלל publisher, אירוע 3089 המתאים ירשום VerificationError = 23. בחירה ב-ECC רק מפני ש”ECC חדש יותר וחזק יותר” משאירה בעיית תאימות מול execution control.⁷

בכללי publisher גם OV וגם EV עובדים

ל-certificates של CA ציבוריים יש OV, שמאמת את קיומה של החברה, ו-EV, שכולל בדיקה מחמירה יותר. publisher rules של AppLocker ו-App Control אפשר לבנות משני סוגי ה-certificates.

ל-App Control יש rule option בשם Required:EV Signers, אבל בתיעוד הרשמי כתוב שהוא לא נתמך כיום. לכן אין סיבה לבחור EV למען ה-execution control שעליו מדובר כאן. הקשר ל-SmartScreen מוסבר בנפרד ב”Windows SmartScreen וחתימת קוד”.⁷

לתקצב גם אחסון מפתח פרטי ופעולות חתימה, לא רק את מחיר ה-certificate

העלות משתנה לפי CA ותקופת התוקף. בתמחור בדקו מעבר ל-certificate עצמו גם את מחיר ה-token או ה-HSM, או את מחיר שירות החתימה בענן של ה-CA.

ל-certificates שמונפקים מ-1 ביוני 2023 ואילך, דרישות CA/Browser Forum קובעות שבין אם זה OV ובין אם EV, המפתח הפרטי חייב להיווצר ולהישמר בחומרה שעומדת ב-FIPS 140-2 Level 2 או שווה ערך (HSM או USB token).⁸

אם אתם חותמים אוטומטית ב-CI/CD, שירות חתימה בענן לרוב קל יותר להגדרה מ-token פיזי. לפני שקונים certificate, כדאי לדון גם באיך יעבוד תהליך העבודה מהבנייה ועד החתימה.

לחתום כל binary ולהוסיף timestamp

מסדרים חתימות Authenticode לא רק על ה-exe אלא גם על ה-DLLים שאתם בונים, על ה-installer (MSI או setup exe) ועל ה-scripts הנלווים. כשקיימים פרטי metadata של חתימה, הלקוח יכול לכתוב כללים ששורדים עדכונים, כמו “להתיר את המוצר הזה מה-publisher הזה, בלי קשר לגרסה”.³

ה-timestamp מוסיפים כדי שהחתימה תישאר תקפה אחרי שה-certificate יפוג. הנה דוגמה מינימלית עם signtool מה-Windows SDK.

:: חתימת הקובץ (hash ב-SHA-256 והוספת timestamp של RFC 3161)
signtool sign /fd sha256 /tr <timestamp server URL> /td sha256 /a MyApp.exe

:: אימות החתימה (בדיקה לפי policy של Authenticode והצגת הפרטים)
signtool verify /pa /v MyApp.exe

משתמשים בכתובת שרת ה-timestamp שה-CA שממנו קניתם מספק. אם אתם משתמשים במפתח על token או HSM, בדקו במדריך של ה-CA גם איזה CSP/KSP לציין. DLLים ו-installers נחתמים באותה פקודה, ולכן כדאי להפוך את החתימה והאימות של הכול לשלב האחרון בבנייה.

5.2. להתייחס לשינויים ב-certificate ובמאפייני הקבצים כאל שינויים בכללים של הלקוח

גם עם חתימה עקבית, גרסה חדשה תיעצר אם מה שהכללים משווים מולו משתנה. מה שצריך לבדוק הוא לא רק ה-subject וה-chain של ה-certificate. שם המוצר, שם הקובץ המקורי והגרסה מגיעים מ-version resource של כל קובץ (פרטי ה-assembly), ולא מה-certificate.

Publisher ב-App Control הוא “certificate ה-PCA (בדרך כלל אחד מתחת ל-root) + ה-CN של ה-leaf certificate”, ו-FilePublisher מוסיף לזה את מאפיין ה-FileName של הקובץ החתום (כברירת מחדל OriginalFileName) ואת גרסת המינימום.⁷

ללקוח שינויים כאלה נראים כמו “אחרי שעדכנו, זה הפסיק לעלות רק בסביבה הזאת”. כשאתם משנים את כתיב שם החברה, את ה-CA או את מאפייני המוצר והקבצים, רשמו ב-release notes הודעה שמציגה זה מול זה את פרטי החתימה הישנים והחדשים (subject, CA מנפיק), ותנו התראה מראש. כך מחלקת ה-IT של הלקוח יכולה להוסיף או לעדכן את כללי ההרשאה.

5.3. לייצב את מיקום ההתקנה ואת זרימת ה-auto-update

מניחים קובצי הרצה תחת Program Files ונמנעים מתכנון שמחלץ קובצי exe או DLL ל-%TEMP% או ל-%APPDATA% בזמן ריצה ומפעיל אותם משם. תכנון שמריץ קוד ממקום שהמשתמש יכול לכתוב בו מתנגש עם סביבות של path rules.

ב-auto-update חותמים גם את חבילת העדכון עצמה, כך שbinary חתום מוחלף ב-binary חתום. לפרטי התכנון הבטוח ראו “האבטחה של auto-update”.

בהפצה דרך Intune או Configuration Manager, אם הלקוח הגדיר את סוכן ההפצה כ-managed installer, אפשר להתיר בפעולה תפעולית binaries שמגיעים בדרך הזאת. הפצה דרך Intune לא מתירה אותם אוטומטית; הגדרה מפורשת של מנהל היא תנאי מוקדם. אספקת MSI שתומך בהתקנה שקטה שמה את האפשרות הזאת בידי הלקוח.

5.4. לשים במדריך ההטמעה את המידע שצריך כדי לבנות כללים

במדריך ההטמעה שאתם מוסרים ללקוח צריכים להופיע ה-subject של החתימה, רשימת ה-binaries שנדרשים להרצה ונתיבי ההתקנה. אלה הבסיסים שעליהם מחלקת ה-IT בונה כללי הרשאה.

למקרה שמשהו נחסם, אפשר לבקש מהם לבדוק לפי שם ה-log ומזהה האירוע מפרק 4. זה מפחית את ההלוך-חזור שמתחיל ונגמר ב”זה לא עולה”, ומשאיר אותם עם אפשרות להשוות מיד את הקובץ ואת פרטי החתימה שלו.

6. נקודות מרכזיות לצד שמטמיע (מחלקת IT)

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

6.1. לבחור את הטכנולוגיה לפי שימוש ולסדר את תנאי ה-audit

ברירת המחדל היא App Control for Business. משתמשים ב-AppLocker לצידו כשנדרשת בקרה per-user במחשב משותף, או כשמערכות הפעלה ישנות מעורבות.³ במחשבים בייעוד קבוע, כמו קיוסקים, צמצום הייעוד קודם עם הגבלת shell מפשט את הכללים. ראו גם “מצב kiosk ו-Assigned Access”.

audit אוסף “מה שהיה נחסם תחת אכיפה” בלי לעצור את העסק. ב-AppLocker חובה ש-AppIDSvc יפעל; אם השירות מופסק, גם אירועי audit לא יופיעו. מגדירים אותו לעלות אוטומטית במחשבי היעד לפני שמתחילים.

הרעיון לאסוף עד שהעסק עבר מחזור מלא לפני המעבר לאכיפה זהה לזה של SMB signing או הגבלות NTLM. כוללים משימות batch חודשיות ושנתיות, ולא מסיימים את הבדיקה בפעולות יומיומיות בלבד.

6.2. AppLocker עובר מ-audit לאכיפה בשלושה שלבים

1. להפעיל מצב audit. ב-Group Policy Management Editor (או secpol.msc באופן מקומי), פותחים Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. לוחצים ימני על AppLocker, פותחים Properties, בוחרים “Configured” בכל אוסף כללים (Executable Rules, Windows Installer Rules, Script Rules, Packaged app Rules) ומגדירים “Audit only”. יוצרים את כללי ברירת המחדל בכל אוסף, ומגדירים את AppIDSvc לעלות אוטומטית.

2. לאסוף אירועים מה-log שמתאים ליעד. לקובצי exe ו-DLL זה 8003 ב-EXE and DLL; ל-scripts ול-MSI זה 8006 ב-MSI and Script. הפקודה בסעיף 4.1 מכסה EXE and DLL בלבד, ולכן היא לא תשלוף את 8006. כדי לראות את שניהם, שולפים את ה-logs בנפרד כך.¹

    # איסוף "מה שהיה נחסם תחת אכיפה" משני ה-logs במצב audit
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   מכיוון ש-Get-WinEvent מחזיר שגיאה עבור log שאין בו אירועים מתאימים, הדוגמה הזאת מוסיפה -ErrorAction SilentlyContinue. אם אין פלט, בדקו גם את מצב השירות, את ה-log ואת טווח הזמן ששלפתם. אם גם packaged apps בהיקף, הוסיפו Packaged app-Deployment ו-Packaged app-Execution באותה צורה, ובדקו עד למשימות batch חודשיות ושנתיות.

3. לסדר את כללי ההרשאה ואז לעבור לאכיפה. עוברים על הקבצים הקריטיים לעסק שהופיעו ב-8003 וב-8006 ומכניסים אותם לכללי ההרשאה. אחר כך משנים באותו חלון Properties ל-“Enforce rules”. אחרי המעבר, עוקבים אחרי חסימות ב-8004 (exe/DLL) וב-8007 (scripts ו-MSI).

6.3. ב-App Control מסירים את אפשרות ה-audit כדי לעבור לאכיפה

מפיצים את ה-policy עם rule option 3 (Enabled:Audit Mode) ב-XML של ה-policy. מגדירים אותו עם App Control Policy Wizard או עם ה-cmdlet Set-RuleOption.⁷

בודקים את ההשפעה על העסק ב-3076 ו-8028, מסדרים את כללי ההרשאה, ואז מסירים את אפשרות ה-audit כדי לעבור למצב אכיפה. Microsoft גם ממליצה לאמת policy חדש תחילה במצב audit.⁷

6.4. לקשור חריגים של קבצים לא חתומים לניהול נכסים

אפליקציות עסקיות ותיקות שנשארות לא חתומות נרשמות כחריגים עם כללי hash ומנוהלות כך. הרשימה הזאת היא גם רשימת הנכסים שעומדים להחלפה. אל תעצרו ביצירת החריג: קשרו אותו לניהול נכסים ובדקו אותו כל שנה.

7. סיכום

ההתמודדות עם execution control מסתכמת בשלושה דברים: להבדיל בין המנגנונים, לקבוע את העובדות מה-logs, ולבנות תוצרי הפצה שכללי ההרשאה נשארים יציבים עבורם.

SmartScreen הוא בעצם אזהרה, אבל תחת policy שאוסר לעבור אותה הוא הופך לחסימה. מתייחסים אליו בנפרד מ-AppLocker, מ-App Control ומ-Smart App Control. מגבלות המהדורה של AppLocker הוקלו, ו-App Control עובד בכל מהדורת client. Smart App Control פועל גם במחשבים אישיים, ולכן “זה Pro” או “אין להם מחלקת IT” לא הופכים אותו ללא רלוונטי.⁵³⁴

כשמשהו לא עולה, משתמשים ב-8004 של AppLocker וב-3077 ו-3089 של App Control כנקודות כניסה, ומצליבים גם את ה-logs של scripts ו-MSI. כשנכשלת רק חלק מהפונקציונליות, בודקים גם את ה-Constrained Language Mode של PowerShell.¹²

הצד שמפיץ מסדר חתימה עקבית של כל binary, timestamps, פרטי publisher ומאפייני קבצים יציבים, מיקומי התקנה סטנדרטיים, auto-update חתום ומדריך הטמעה. המטרה הבסיסית היא אפליקציה שלקוח יכול לכתוב לה כללי הרשאה בקלות, ולשמור עליהם גם אחרי עדכון.

הצד שמטמיע נותן לעסק לרוץ מחזור מלא תחת 8003 ו-8006 של AppLocker ו-3076 ו-8028 של App Control לפני המעבר לאכיפה. כשגם ההפצה וגם התפעול מסודרים, מצטמצמים המקרים של “זה נכשל רק בסביבת הלקוח”.

מאמרים קשורים

• למה ב-Windows מופיע “Windows protected your PC”
• תכנון האבטחה של auto-update — למה HTTPS לבדו אינו מספיק
• איך בוחרים שיטת הפצה לאפליקציית Windows — MSI/MSIX/ClickOnce/xcopy/updater עצמאי
• Execution Policy וחתימת סקריפטים ב-PowerShell — מדריך מעשי ליציאה מ”כיסוי עם Bypass”
• טיפול ב-false positive של Microsoft Defender
• מצב kiosk ו-Assigned Access ב-Windows
• הפתרון המציאותי אחרי סיום התמיכה ב-Windows 10 — טבלת החלטה ל-ESU, LTSC והחלפה

תחומי ייעוץ קשורים

KomuraSoft LLC עוסקת בפיתוח ובשינוי של אפליקציות עסקיות שרצות בסביבת execution control (AppLocker / App Control for Business), בתכנון הפצה ו-auto-update עם חתימת קוד מובנית, ובחקירת מקרים שבהם אפליקציה לא עולה בסביבת לקוח.

• פיתוח אפליקציות Windows
• שינוי ותחזוקה של תוכנה קיימת ל-Windows
• חקירת תקלות וניתוח שורש הבעיה
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

AppLocker לא שמיש במהדורת Pro?

התפיסה הזאת התעדכנה. מ-KB 5024351 ואילך, אכיפה של policy של AppLocker אינה דורשת מהדורה מסוימת ב-Windows 10 גרסה 2004 ומעלה, ובאף מהדורה של Windows 11. המגבלה הישנה — "אכיפה של policy שמופץ ב-Group Policy מוגבלת למהדורות Enterprise ו-Server" — חלה רק עד גרסאות Windows 10 ישנות מגרסה 2004 ועל Windows Server 2019 (וגם שם, הפצה דרך MDM עובדת בכל מהדורה). AppLocker הוא היום אפשרות אמיתית גם בסביבה שנבנתה בעיקר על מחשבי Pro של עסקים קטנים.

כדאי לקנות certificate חתימת קוד מסוג EV?

מנקודת המבט של publisher rules ב-AppLocker וב-App Control for Business, אפשר לבנות כלל על בסיס פרטי החותם גם עם certificate מסוג OV (אימות קיום החברה) וגם עם EV. שימו לב גם שהאמונה "עם EV אזהרת SmartScreen נעלמת כבר מההרצה הראשונה" אינה מעודכנת: קובץ חתום ב-EV צריך להיבחן היום באותה שיטת צבירת reputation כמו קובץ חתום ב-OV (הנקודה הזאת מכוסה במאמר הנפרד "Windows SmartScreen וחתימת קוד"). מה שחשוב יותר מסוג ה-certificate הוא לחתום כל binary עם אותו subject — לא רק את ה-exe אלא גם את ה-DLLים ואת ה-installer — להוסיף timestamp, ולשמור על יציבות פרטי ה-publisher גם בחידוש certificate. publisher rules נכתבים על בסיס פרטי החותם האלה, ואם מצב החתימה משתנה בין גרסאות, הכללים אצל הלקוח נשברים.

נראה שהאפליקציה שלנו נחסמה בסביבה של לקוח, אבל אני לא מוצא כלום ב-log. איפה לחפש?

הסיבה השכיחה היא שה-log שאתם צריכים מפוצל בין שתי משפחות. חסימה של exe או DLL על ידי AppLocker מופיעה כאירוע 8004 (8003 במצב audit) ב-log "AppLocker - EXE and DLL", ואילו scripts ו-MSI מופיעים כ-8007 (8006 במצב audit) ב-log "AppLocker - MSI and Script". חסימה על ידי App Control for Business (WDAC), לעומת זאת, מופיעה כאירוע 3077 (3076 במצב audit) ב-log "CodeIntegrity - Operational", כשפרטי החתימה המתאימים נרשמים ב-3089. מעבר לזה, כש-script, MSI או COM object נתפסים על ידי App Control, הם מופיעים ב-log "AppLocker - MSI and Script" כ-8029, 8036 או 8040. כשאתם חוקרים בלי לדעת איזה מנגנון פועל, סדרו את CodeIntegrity - Operational ואת כל מה שתחת AppLocker לפי זמן והשוו ביניהם.

מה צריך כדי ש-Smart App Control לא יחסום את האפליקציה שלנו?

בפועל — חתימת קוד. כשאפליקציה רצה, Smart App Control בודק אם שירות אבטחה בענן יכול לחזות שהאפליקציה בטוחה ואם יש לאפליקציה חתימה תקפה, והוא חוסם אפליקציות שנקבע שהן זדוניות וגם אפליקציות לא חתומות שאי אפשר לאמת את מהימנותן. גם ההנחיות של Microsoft למפתחים מונות חתימה של האפליקציה ב-certificate תקף. עם זאת, יש לשים לב לאלגוריתם החתימה: בדיקת החתימה של Smart App Control אינה תומכת בחתימות elliptic curve cryptography (ECC), ורק אפליקציות שחתומות ב-certificate מבוסס RSA זכאיות לרוץ. Smart App Control אינו תכונת ניהול ארגונית אלא הגנה למשתמשים פרטיים ב-Windows 11, והוא נדלק או נכבה אוטומטית החל ממצב הערכה, ולכן מהצד שמפיץ ההנחה הבטוחה היא שקובץ הרצה לא חתום עלול לא לרוץ במחשב אישי.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.