הגדר את Credential Guard ב-Windows שלב אחר שלב

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

בשורות הבאות, תראו כיצד להגדיר את Credential Guard באמצעות שיטות שונות (Intune/MDM, Group Policy ו-Registry), את דרישות המערכת, המגבלות שהוא מציג, כיצד לוודא שהוא אכן פעיל וכיצד להשבית אותו בתרחישים הכרחיים, כולל מכונות וירטואליות ומכשירים נעולים ב-UEFI. הכל מוסבר בפירוט, אך בשפה ברורה וידידותית למשתמש, כך שתוכלו ליישם אותו בקלות.

מהו Credential Guard וכיצד הוא מגן על אישורים?

Credential Guard הוא תכונת אבטחה של Windows אשר משתמש באבטחה מבוססת וירטואליזציה (VBS) כדי לבודד אישורים וסודות אחרים הקשורים לאימות. במקום שהכל יאוחסן ישירות בתהליך רשות האבטחה המקומי (lsass.exe), נתונים רגישים מאוחסנים ברכיב מבודד הנקרא LSA מבודד o LSA מבודד.

מערכת LSA מבודדת זו פועלת בסביבה מוגנת , המופרדת ממערכת ההפעלה הראשית על ידי ההיפר-ויזור ( מצב מאובטח וירטואלי או VSM). ניתן לטעון לסביבה זו רק קבוצה קטנה מאוד של קבצים בינאריים, החתומים עם אישורים מהימנים. התקשורת עם שאר המערכת מתבצעת באמצעות RPC, המונע מתוכנות זדוניות הפועלות על המערכת, לא משנה כמה זכויות יש להן, לקרוא ישירות את הסודות המוגנים.

Credential Guard מגן באופן ספציפי על שלושה סוגי אישורים : גיבובי סיסמה של NTLM, אישורי Kerberos Ticket Grant (TGT) ואישורים המאוחסנים על ידי יישומים כאישורי דומיין. זה ממתן התקפות קלאסיות כגון pass-the-hash או pass-the-ticket , שהן נפוצות מאוד בתנועה רוחבית בתוך רשתות ארגוניות.

חשוב להבין ש-Credential Guard אינו מגן על הכל : הוא אינו מכסה, למשל, אישורים המטופלים על ידי תוכנות צד שלישי מחוץ למנגנוני Windows סטנדרטיים, חשבונות מקומיים וחשבונות Microsoft, או מגן מפני התקפות פיזיות או keyloggers. למרות זאת, הוא מפחית מאוד את הסיכון הקשור לאישורי דומיין.

Credential Guard מופעל כברירת מחדל

החל מ- Windows 11 22H2 ו-Windows Server 2025 , אבטחה מבוססת וירטואליזציה (VBS) ו-Credential Guard מופעלים כברירת מחדל במכשירים העומדים בדרישות החומרה, הקושחה והתוכנה שהוגדרו על ידי מיקרוסופט. משמעות הדבר היא שבמחשבים מודרניים רבים, הם מגיעים מוגדרים מראש ופעילים ללא כל התערבות מנהל מערכת.

מצב ההפעלה המוגדר כברירת מחדל הוא "UEFI unlock ", כלומר הוא אינו נעול, מה שמונע השבתה מרחוק. גישה זו מקלה על מנהלי מערכת להשבית את Credential Guard מרחוק באמצעות מדיניות או תצורה אם יישום קריטי אינו תואם או מתעוררות בעיות ביצועים.

כאשר Credential Guard מופעל כברירת מחדל , גם ה-VBS עצמו מופעל אוטומטית. לא נדרשת תצורת VBS נפרדת כדי ש-Credential Guard יפעל, למרות שקיימים פרמטרים נוספים לחיזוק אבטחת הפלטפורמה (לדוגמה, דרישה להגנת DMA בנוסף לאתחול מאובטח ).

יש הבדל חשוב שיש לעשות במערכות משודרגות : אם במכשיר היה Credential Guard מושבת במפורש לפני השדרוג לגירסת Windows שבה הוא מופעל כברירת מחדל, הוא יישאר מושבת לאחר השדרוג. במילים אחרות, ההגדרות המפורשות של מנהל המערכת גוברות על התנהגות ברירת המחדל.

דרישות מערכת, חומרה, קושחה ורישוי

כדי ש-Credential Guard יספק הגנה יעילה , המכשיר חייב לעמוד בדרישות מינימום של חומרה, קושחה ותוכנה. מכשירים העולים על מינימום אלה ויש להם תכונות נוספות, כגון IOMMU או TPM 2.0, יכולים ליהנות מרמות אבטחה גבוהות יותר מפני התקפות DMA ואיומים מתקדמים.

דרישות חומרה וקושחה

דרישות החומרה העיקריות עבור Credential Guard כוללות מעבד 64 סיביות עם הרחבות וירטואליזציה ( Intel VT-x או AMD-V) ותמיכה בתרגום כתובות ברמה השנייה (SLAT, המכונה גם טבלאות עמודים מורחבות). ללא יכולות וירטואליזציה אלו, VBS ומצב בטוח וירטואלי לא יוכלו לבודד כראוי את הזיכרון.

ברמת הקושחה, חובה להשתמש בגרסה 2.3.1 ומעלה של UEFI עם תמיכה באתחול מאובטח ותהליך עדכון קושחה מאובטח. בנוסף, מומלץ להשתמש בתכונות כגון בקשת מעבר זיכרון (MOR) המוטמעת בצורה מאובטחת, הגנה על תצורת אתחול ויכולת לעדכן קושחה דרך Windows Update.

מומלץ מאוד להשתמש ביחידת ניהול זיכרון קלט/פלט (IOMMU) , כגון Intel VT-d או AMD-Vi, מכיוון שהיא מאפשרת הגנה מפני DMA בשילוב עם VBS. הגנה זו מונעת מהתקנים זדוניים המחוברים לאפיק לגשת ישירות לזיכרון ולחלץ סודות.

מודול הפלטפורמה המהימנה (TPM) הוא רכיב מפתח נוסף , רצוי TPM 2.0 , אם כי גם TPM 1.2 נתמך. ה-TPM מספק עוגן אבטחה חומרתי כדי להגן על מפתח המאסטר של VSM ולהבטיח שניתן לגשת לנתונים המוגנים על ידי Credential Guard רק בסביבה מהימנה.

הגנות VSM ותפקיד ה-TPM

סודות המוגנים על ידי Credential Guard מבודדים בזיכרון באמצעות Virtual Secure Mode (VSM). בחומרה עדכנית עם TPM 2.0, נתונים קבועים בסביבת VSM מוצפנים באמצעות מפתח ראשי של VSM המוגן על ידי ה-TPM עצמו ומנגנוני האתחול המאובטח של המכשיר.

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

דרישות ורישיונות של גרסת Windows

Credential Guard אינו זמין בכל הגרסאות של Windows . במערכות לקוח, הוא נתמך ב- Windows Enterprise וב-Windows Education, אך לא ב-Windows Pro או Windows Pro Education/SE. משמעות הדבר היא שמחשב שבו פועל Windows Pro יצטרך לעבור שדרוג ל-Enterprise כדי להשתמש בתכונה זו.

זכויות שימוש ב-Credential Guard מוענקות באמצעות רישיונות כגון Windows Enterprise E3 ו-E5 או רישיונות חינוכיים A3 ו-A5. בסביבות ארגוניות, זכויות אלו מושגות בדרך כלל באמצעות הסכמי רישוי בכמות גדולה, בעוד שיצרני ציוד מקורי (OEM) מספקים בדרך כלל את Windows Pro והלקוח משדרג לאחר מכן ל-Enterprise.

Credential Guard במכונות וירטואליות Hyper-V

Credential Guard יכול גם להגן על סודות בתוך מכונות וירטואליות הפועלות על Hyper-V, בדומה לאופן שבו הוא מגן על מכונות פיזיות. הדרישות העיקריות הן שלמארח Hyper-V יהיה IOMMU ושהמכונות הווירטואליות הן מדור 2.

חשוב להבין את גבולות ההגנה בתרחישים אלה : Credential Guard מגן מפני התקפות שמקורן במכונה הווירטואלית עצמה, אך לא מפני איומים מצד מחשב מארח עם הרשאות מוגברות. אם המארח נפגע, הוא עדיין יכול לגשת למכונות האורח.

דרישות יישום ותאימות

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

יישומים הדורשים הצפנת DES עבור Kerberos , הקצאת Kerberos בלתי מוגבלת, חילוץ TGT או תמיכה ב-NTLMv1 יושבתו מכיוון שאפשרויות אלו מושבתות כאשר Credential Guard פעיל. זהו אמצעי אבטחה קפדני, אך הכרחי למניעת פגיעויות חמורות.

תכונות אחרות, כגון אימות מרומז , האצלת אישורים, MS-CHAPv2 או CredSSP, חושפות אישורים לסיכונים נוספים גם כאשר Credential Guard פעיל. יישומים שמתעקשים להשתמש בתכונות אלה עשויים להמשיך לתפקד, אך הם משאירים אישורים פגיעים יותר, ולכן מומלץ גם לבדוק אותם.

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

כיצד להפעיל את Credential Guard בצורה נכונה

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

ישנן שלוש שיטות עיקריות להגדרת תכונה זו : באמצעות Microsoft Intune/MDM, מדיניות קבוצתית ורישום Windows. הבחירה תלויה בסביבה, בכלי הניהול הזמינים וברמת האוטומציה הרצויה.

הפעלת Credential Guard באמצעות Microsoft Intune / MDM

בסביבות המנוהלות באמצעות Intune או פתרונות MDM אחרים , ניתן להפעיל את Credential Guard על ידי יצירת מדיניות תצורת מכשירים שתחילה מפעילה אבטחה מבוססת וירטואליזציה ולאחר מכן מגדירה את ההתנהגות הספציפית של Credential Guard.

באמצעות DeviceGuard CSP, ניתן ליצור מדיניות מותאמת אישית עם פרמטרי OMA-URI המרכזיים הבאים:

• הפעלת VBS: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurityסוג נתונים int, ערך 1 כדי לאפשר אבטחה מבוססת וירטואליזציה.
• הגדרת Credential Guard: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags, הקלד int, ערך 1 כדי להפעיל עם נעילת UEFI או 2 כדי להפעיל ללא חסימה.

לאחר יצירת המדיניות, היא מוקצית לקבוצת המכשירים או המשתמשים שיש להגן עליהם. לאחר החלת המדיניות, יש להפעיל מחדש את המכשיר כדי ש-Credential Guard ייכנס לתוקף.

הגדרת Credential Guard באמצעות מדיניות קבוצתית (GPO)

בדומיינים של Active Directory, השיטה הנוחה ביותר היא בדרך כלל אובייקט מדיניות קבוצתית (GPO) . ניתן להשתמש בעורך המדיניות הקבוצתית המקומי עבור מחשב בודד או ליצור אובייקט מדיניות קבוצתית המקושר לדומיינים או יחידות ארגוניות כדי לכסות מכשירים רבים.

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

בעת הפעלת מדיניות זו, עליך לבחור את האפשרות Credential Guard מהרשימה הנפתחת "הגדרות Credential Guard":

• מופעל עם נעילת UEFIמונע השבתה מרחוק של Credential Guard; ניתן לשנות זאת רק באמצעות גישה פיזית לקושחה/BIOS.
• מופעל ללא חסימהמאפשר לך להשבית את Credential Guard מאוחר יותר באמצעות GPO או הגדרה מרחוק.

ניתן לסנן אובייקטי מדיניות קבוצתית (GPO) באמצעות קבוצות אבטחה או מסנני WMI , מה שמאפשר להחיל הגנה זו רק על סוגים מסוימים של מחשבים או פרופילי משתמשים. לאחר החלת המדיניות, נדרשת גם הפעלה מחדש של המערכת כדי שהשינויים ייכנסו לתוקף.

הגדרת Credential Guard באמצעות הרישום של Windows

כאשר נדרשת בקרה מפורטת יותר או סקריפט מותאם אישית , ניתן להפעיל את Credential Guard ישירות דרך הרישום. שיטה זו משמשת בדרך כלל בתרחישים מתקדמים או אוטומציות שבהם אובייקטי מדיניות קבוצתית (GPO) או ניהול דרישות מרובות (MDM) אינם זמינים.

כדי להפעיל אבטחה מבוססת וירטואליזציה (VBS) , יש להגדיר את המפתחות הבאים:

• נתיב מפתח: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  שם: EnableVirtualizationBasedSecurity, הקלד REG_DWORD, ערך 1.
• נתיב מפתח: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  שם: RequirePlatformSecurityFeatures, הקלד REG_DWORD, ערך 1 להתנעה בטוחה או 3 לאתחול מאובטח עם הגנת DMA.

המפתח הבא משמש לתצורה ספציפית של Credential Guard :

• נתיב מפתח: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  שם: LsaCfgFlags, הקלד REG_DWORDערכים אפשריים:
  0 כדי להשבית את Credential Guard,
  1 כדי להפעיל אותו עם נעילת UEFI,
  2 כדי להפעיל אותו בלי לחסום.

לאחר התאמת מפתחות אלה ברישום , עליך להפעיל מחדש את המחשב כדי ש-VBS ו-Credential Guard יאותחלו כראוי ויתחילו להגן על האישורים.

בדוק אם Credential Guard מופעל

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

אימות עם מידע מערכת (msinfo32)

הדרך הקלה ביותר עבור מנהלי מערכת רבים היא להשתמש בכלי "מידע מערכת" של Windows:

1. בחר התחל והקלד msinfo32.exeלאחר מכן פתח את היישום "מידע מערכת".
2. בחלונית השמאלית, עבור אל סקירה כללית של המערכת.
3. בחלונית הימנית, חפשו את הסעיף שירותי אבטחה מבוססי וירטואליזציה בפעולה ותבדוק ש-"Credential Guard" מופיע בין השירותים המפורטים.

אם Credential Guard מופיע כשירות פעיל בסעיף זה, פירוש הדבר שהוא מופעל ופעיל כראוי במחשב.

אימות באמצעות PowerShell

בסביבות מנוהלות, מאוד פרקטי להשתמש ב-PowerShell כדי לבדוק את הסטטוס של Credential Guard בכמות גדולה. מקונסולת PowerShell מוגבהת, ניתן להריץ:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

פקודה זו מחזירה קבוצה של ערכים מספריים המציינים אילו שירותי אבטחה מבוססי וירטואליזציה פעילים. במקרה הספציפי של Credential Guard, הם מתפרשים באופן הבא:

• 0: Credential Guard מושבת (לא פועל).
• 1: Credential Guard מופעל (פועל).

בנוסף לשאלה הכללית הזומיקרוסופט מציעה את הסקריפט DG_Readiness_Tool (לדוגמה, DG_Readiness_Tool_v2.0.ps1), המאפשר לך לבדוק אם המערכת מסוגלת להפעיל את Credential Guard, להפעיל אותו, להשבית אותו ולאמת את מצבו באמצעות אפשרויות כגון -Capable, -Enable, -Disable y -Ready.

שימוש במציג האירועים

שיטת אימות נוספת המכוונת יותר לביקורת זה כדי להשתמש במציג האירועים. מאת eventvwr.exe ניתן לגשת ל"יומני Windows" → "מערכת" ו סנן את האירועים שמקורו הוא "WinInit".

בין אירועים אלה נמנים ערכים הקשורים לאתחול של שירותי אבטחה מבוססי וירטואליזציה, כולל אלה המציינים האם Credential Guard אותחל בהצלחה במהלך תהליך האתחול.

השבתת Credential Guard וניהול נעילת UEFI

למרות שבדרך כלל עדיף להשאיר את Credential Guard מופעל , ישנם תרחישים שבהם ייתכן שיהיה צורך להשבית אותו: אי תאימות של יישומים, בדיקות מעבדה, שינויים בארכיטקטורת האבטחה וכו'. ההליך להשבתתו יהיה תלוי באופן ההפעלה שלו ובשאלה האם נעשה שימוש בנעילת UEFI.

באופן כללי, השבתת Credential Guard כרוכה בביטול ההגדרות שהוחלו דרך Intune/MDM, Group Policy או הרישום, ולאחר מכן הפעלה מחדש של המחשב. עם זאת, כאשר הוא מופעל עם נעילת UEFI, ישנם שלבים נוספים מכיוון שחלק מההגדרות מאוחסנות במשתני קושחה של EFI.

השבתת Credential Guard עם נעילת UEFI

אם Credential Guard הופעל עם נעילת UEFIלא מספיק לשנות את ה-GPO או את הרישום. עליך גם להסיר את משתני ה-EFI המשויכים לתצורת ה-LSA המבודדת באמצעות bcdedit ותהליך סטארט-אפ קטן ומיוחד.

משורת פקודה עם הרשאות מלאות , בצע רצף של פקודות כדי:

1. התקן יחידת EFI זמנית עם mountvol ולהעתיק SecConfig.efi לנתיב האתחול של מיקרוסופט.
2. צור ערך מטען מערכת עם bcdedit /create מצביע על כך SecConfig.efi.
3. הגדר את רצף אתחול של מנהל האתחול כך שהוא יאתחל פעם אחת עם אותו טוען מיוחד.
4. הוסף את אפשרות הטעינה DISABLE-LSA-ISO כדי להשבית את תצורת ה-LSA המבודדת המאוחסנת ב-UEFI.
5. הסר שוב את יחידת ה-EFI הזמנית.

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

השבתת Credential Guard במכונות וירטואליות

במקרה של מכונות וירטואליות המחוברות למארח Hyper-V , ניתן לגרום למכונה הווירטואלית לא להשתמש ב-VBS וב-Credential Guard גם אם מערכת ההפעלה האורחת מוכנה לעשות זאת.

מהמארח, באמצעות PowerShell, ניתן להפעיל את הפקודה הבאה כדי לא לכלול מכונה וירטואלית מאבטחה מבוססת וירטואליזציה:

Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true

על ידי הפעלת אפשרות אי הכללה זו , המכונה הווירטואלית תפעל ללא הגנות VBS, ובהרחבה, ללא Credential Guard, שיכול להיות שימושי בסביבות בדיקה או בעת הפעלת מערכות מדור קודם בתוך מכונות וירטואליות.

שילוב Credential Guard ב-AWS Nitro ובתרחישים אחרים

Credential Guard זמין גם בסביבות ענן כמו Amazon EC2, תוך ניצול הארכיטקטורה המאובטחת של מערכת AWS Nitro. בהקשר זה, VBS ו-Credential Guard מסתמכים על Nitro כדי למנוע חילוץ של פרטי כניסה ל-Windows מזיכרון מערכת ההפעלה האורחת.

כדי להשתמש ב-Credential Guard על מופע של Windows ב-EC2כדי להפעיל מופע תואם, עליך לבחור סוג מופע נתמך ו-Windows AMI מוגדר מראש הכולל תמיכה ב-TPM וירטואלי ו-VBS. ניתן לעשות זאת מקונסולת Amazon EC2 או מ-AWS CLI באמצעות run-instances או באמצעות PowerShell New-EC2Instanceציון, למשל, תמונה של הסגנון TPM-Windows_Server-2022-English-Full-Base.

בתרחישים מסוימים יהיה צורך להשבית את שלמות הזיכרון (HVCI) לפני הפעלת Credential Guard, על ידי התאמת מדיניות קבוצתית הקשורה ל"הגנה מבוססת וירטואליזציה של שלמות קוד". לאחר ביצוע התאמות אלו וההפעלה מחדש של המופע, ניתן להפעיל ולאמת את Credential Guard, כמו בכל מחשב Windows אחר, עם msinfo32.exe.

מגבלות הגנה והיבטים ש-Credential Guard אינו מכסה

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

כמה דוגמאות לדברים שהוא לא מגן עליהם הן :

• תוכנת צד שלישי שמנהל אישורים מחוץ למנגנוני Windows סטנדרטיים.
• חשבונות מקומיים וחשבונות מיקרוסופט שתצורתם נקבעה במחשב עצמו.
• מסד נתונים של Active Directory בבקרי תחום של Windows Server.
• ערוצי כניסה של אישורים כגון שרתי שער של שולחן עבודה מרוחק.
• מקליטי לחיצות מקשים והתקפות פיזיות ישירות על הקבוצה.

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

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

Device Guard, VBS וקשר עם Credential Guard

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

Credential Guard מתמקד בהגנה על אישורים (NTLM, Kerberos, Credential Manager) על ידי בידודם בתוך LSA המוגן. הוא בלתי תלוי ב-Device Guard, אם כי שניהם חולקים את השימוש ב-hypervisor ובתכונות חומרה כגון TPM, Secure Boot ו-IOMMU.

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

שתי התכונות הן חלק ממאגר ההגנה של Windows Enterprise מפני איומים מתקדמים. Device Guard מסתמך על VBS ודורש מנהלי התקנים להיות תואמי HVCI, בעוד ש-Credential Guard משתמש ב-VBS כדי לבודד סודות אימות. יחד, הן מציעות שילוב רב עוצמה: קוד אמין יותר ואישורים מוגנים טוב יותר.

הגדרה נכונה של Credential Guard מגינה על אחד ההיבטים הרגישים ביותר של כל סביבת Windows: אישורי משתמש ומחשב. הבנת הדרישות שלו, ידיעת אופן הפעלתו באמצעות Intune, GPO או הרישום, הכרת מגבלותיו וקיום נהלים ברורים לאימות מצבו והשבתתו במקרים חריגים מאפשרים לכם לנצל את מלוא היתרונות של טכנולוגיה זו מבלי להיתקל בהפתעות בתהליך הייצור.