Microsoft Entra וניהול זהויות

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

לאחרונה השיקה מיקרוסופט פתרון זהויות הוליסטי ומורחב לזהויות שמבוסס על תשתיות וכלים קיימים, מבוסס על כלים חדשים וחשוב מכך מתבסס על קונספט חדש שמביא בשורה חדשה לתחום הזהויות – Microsoft Entra.

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

זהות היא DMZ

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

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

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

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

השאלות שעולות בכל סביבה ובמצבים כאלה הם:

– מהי כמות האובייקטים של זהות אנושית?
– מהי כמות האובייקטים של זהות לא אנושית (אוטומציה, בוטים וכו’)?
– האם זהות מנוהלת במקום אחד ולא מפוזרת על סמך מספר דירטקורי?
– האם ישנם מספר דירטקורים שמנוהלים מתוך מקום אחד?
– האם ישנו תהליך מחזורי של ניהול משתמש ואובייקטים של זהויות?
– מהם כמות הסביבות שיש לכל זהות? היברידי עם ענן אחד או יותר?
– האם משתמש ניגש רק למידע שהוא צריך, או שנוגע במידע רגיש?
– האם ישנו ניהול הרשאות לפי סוג המשתמש? האם אוטומטי או ידני?
– מהן ההרשאות שיש לכל אובייקט? לכל משתמש?
– האם יש מערכת לניהול גישה מועדפת, סטייל PAM או PIM?

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

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

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

KillChain מורכב מחמישה תפקידים שונים: אאוטסיידר, אורח, פנימי, אדמין ומנהל מקומי. בדרך כלל סריקות ותקיפות חיצוניות מוכוונים לתפקידי אאוטסיידר ואורח. היתר הם חלק מסריקות ותקיפות פנימיות מתוך Active Directory מקומי שהוא חלק מסביבה היברידית.

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

ℹ️ חיבור לענן מצריך תחילה בקרה ונראות של זהויות וזאת לפני כלים ובקרות אחרות

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

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

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

ℹ️ חשוב להדגיש כי תשתיות IAM אינם תשתיות אבטחה ואינם יכולות להיות כאלה ולכן כאן מתחיל הפער הגדול או חוב אבטחה

דוגמה נפוצה של פערי אבטחה וחוב אבטחה הוא השילוב של Active Directory מקומי אל תשתית Azure AD, במצב כזה הרכיב שמבצע סנכרון מהווה סיכון אבטחה בגלל שאינו מקבל מיטיגציה ובקרה הולמת. המאמר Breaking the Cloud via Azure AD Connect יורד לרזלוציות וונגע בתרחיש אחד מבין רבים שמאפשר לבצע תנועה רוחבית מהסביבה המקומית אל הענן ולעקוף מנגנוני אבטחה.

בשטח אפשר לומר שרוב הסביבות הן סביבות היברידיות שמחוברות מתוך Active Directory מקומי אל Azure AD ואל AWS ומשם לאינספור אפליקציות. לצד זה ישנו אחוז קטן של סביבות ענניות בלבד וכאלה שמחוברות למספר עננים. בשני המקרים המוזכרים וגם בתרחישים אחרים ישנם בעיות ופערי אבטחה והעובדה שזהויות מבתססות רק בענן אינה מורידה באופן מהותי את כמות הבעיות של זהויות.

ℹ️ בעבר העליתי מאמר של הגנה על זהויות וגישת PIM בתשתית Azure AD. בזמנו מקום טוב להתחיל ממנו והיום אנו צריכים כבר ניהול מרוכז שכולל Permission Management.

מצב קיים וחדש

כידוע סביבת Active Directory מקומית שאליה מחוברות המון מערכות מקומיות מכילה מאות או עשרות אלפי אובייקטים ומכאן סביבה ADDS היא מאוד hackable ומכילה אלפי בעיות ופערי אבטחה שמאפשרות לכל תוקף להשיג אחיזה בתשתית באופן מהיר מאוד. נוסיף על כך את העובדה שהמעבר לענן יצר סיטואציה שאינה מוכרת לרבים ויצרה בעיות, פערים ואיומי אבטחה חדשים, חלקם אינם מוכרים.

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

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

קישור ישיר לדוח IDENTITY SECURITY THREAT LANDSCAPE

עיקרי הנושאים ונקודות מעניינות בדוח שאפשר להיתקל בהן בכל סביבה:

– קצב צמיחת אובייקטים וזהויות דיגיטליות.
– למשתמש ממוצע ישנם מעל 30 זהויות דיגיטליות.
– זהויות מכונה הוא כפול 45 מאשר משתמש.
– תקיפות מוצלחות בעלי נזק מהותי מגיעות מתוך גישה לזהויות.
– כלים אינם מצליחים לזהות נגיעה במשתמשים פריבילגים.
– תהליכי פיתוח רבים מכילים זהויות.
– 68% מהזהויות שאינם משתמשים רגילים יש גישה לנתונים ונכסי מידע רגישים.
– 87% מהארגונים מאחסנים סיקרטים במיקומים רבים של סביבות DevOps.
– 64% ממנהלי האבטחה מודים שארגוניהם אינם מסוגלים לבלום מתקפה על שרשרת האספקה.

ואחת השאלות שעלו הן, האם ישנם כלים ובקרות אבטחה לזהויות? (שוב, לא IAM או רכיב SSO או שאר יכולות אינטגרציה)

כמו שניתן לשים לב אחוז קטן מהארגונים התקינו בקרה או כלי לאבטחת זהויות.

ℹ️ כלים ובקרות לבד לא יכסו חלק ניכר מהבעיות והפערים ולכן היגיינת אבטחה בסיסית היא המפתח להצלחה והקטנת שטח התקיפה

אין ספק שהדוח מביא איתו עובדות מוכרות אך בחלק מהמקרים אפשר להרחיב על כך, למשל:

– בארגונים גדולים מספר הזהויות הדיגיטליות הוא לפחות 45.
– תהליכי פיתוח מכילים כמות רבה של זהויות חשופות ברמת קוד, ריפו וכן הלאה – הדוח של apiiro מציין זאת בצורה מפורטת.
– הדוח של סייברארק אינו מתייחס לאפליקציות והרשאות שניתנות ע”י מורשים או משתמשים.

לנתונים נוספים אודות חשיפה של זהויות אפשר לראות בדוח של חברת apiiro – קישור ישיר Secrets Insights 2022.

ℹ️ המאמץ של ניהול זהויות אינו רק של צוות האבטחה אלא של צוות זהויות (במידה וקיים) וכן של צוות IT המונחה ע”י מהל אבטחה או צוות אבטחה.

גישה תומכת זהויות

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

– איחוד זהויות
– הזדהות אחודה
– סנכרון סיסמאות
– מיכון תהליכים
– הקצאת וביטול הרשאות
– כלי Self-Service
– ניהול ויישום Lifecycle management
– שימוש ב MFA
– למרכז זהויות ומכונות

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

 ℹ️ מומלץ להפריד ברמת כלים, גישה ותהליכים בין ניהול זהויות של סביבות פיתוח לבין שאר הסביבות – אינם מתקיימים ביחד בגלל קונפליקטים

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

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

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

בחיבור אפליקציות אנו עלולים למצוא אפליקציות שמבוססות על תקנים וסטנדרטים מסויימים כמו OAuth ואנו עלולים להבחין באפליקציות שהן מבוססות Bookmark או אפליקציה שמתבססת על סיסמה ללא אינטגרציה מנוהל ונתמכת בין האפליקציה לתשתית Azure AD. נסו למצמם אפשרויות כאלה או להשתמש במנגנון App Proxy בכדי לצמצם בעיות אבטחה.

ℹ️ לתשתית זהויות שאינה תקינה יש השלכות על גישה וכלים כמו כלי CIEM או מימוש API Security – ללא זהויות מנוהלות הטמעה של כלים כאלה היא חסרת ערך, יקרה ואינה נותנת מענה נדרש.

מיהו Entra

אז מהו Microsoft Entra ומה עם Active Directory ואיך CloudKnox נכנס בתמונה? ומהי הבשורה?

הפתרון Microsoft Entra הוא תשתית עם שם חדש שמפגיש את שלושת עמודי התווך העיקריים באסטרטגיית ניהול הזהויות והגישה של identity trust fabric אחד ומשולב. למה השם Entra? מכיוון שזהות צריכה להיות כניסה לעולם של אפשרויות חדשות, לא שער אשר מגביל גישה, או יוצר חיכוך ומעכב חדשנות.

ℹ️ בגישת אבטחה אנו מחפשים חיכוך עם התוקף, הקטנת שטח התקיפה ומזעור פערים ובעיות אבטחה

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

המטרה של Microsoft Entra היא לאמת את כל סוגי הזהויות תוך אבטחה, ניהול ופיקוח על הגישה לכל משאב ובכל רגע נתון.

עמודי התווך

הפילארים המרכזיים של Entra הם: Azure AD, Permissions Management, Verified ID.

Azure AD

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

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

לשירות Azure AD ישנם שלושה גרסאות: Free, Basic, Premium. בכל גרסה אנו מקבלים יכולות שונות כאשר גרסת Free היא הגרסה החינמית שמקבל כל שירות ענן ללא יוצא מן הכלל.

שירות Azure AD מכיל אפשרויות IAM מוכרות ובסיסיות של איחוד זהויות, הזדהות אחודה, סנכרון סיסמאות, הקצאת וביטול הרשאות, כלי Self-Service למשתמי קצה, תמיכה בפרוטוקולים, תקנים וסטנרטים מוכרים, יכולות אבטחה ועוד. לצד זה ישנם יכולות אבטחה שיכולות לנהל ולהגביל גישה, להתנות חיבור מבוסס פרמטרים, לזהות משתמשים בסיכון ועוד שלל אפשרויות אבטחלה לזהויות. אחד השיפורים שנעשו בשנים האחרונות בתשתית Azure AD הוא האקוסיסטם של תמיכה וחיבור עננים אחרים, מערכות ואפליקציות אחרות מכל סוג וכל מצב, וכן גם כאלה שהם לגאסי ישנות ולאפשר עליהם MFA.

אינספור מאמרים בעברית על Azure AD (ניהול, אבטחה, אינטגרציה ועוד)

Permissions Management

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

Permissions Management מאפשר ניהול הרשאות מותאם, קצב צמחיהנ אוטומטי לפי הזהויות בסביבה ומנטר הרשאות שנמצאות בשימוש מופרז וכאלה שאינן בשימוש מופרז. במצב כזה מאפשר לארגונים להתייחס לניהול ההרשאות כחלק מרכזי במודל אבטלה של גיסת אפס אמון (Zero Trust) וכן מאפשר ליישם גישה עם הרשאות בתשתיות השונות ובמצבים של:

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

מיקרוסופט היא ספקית הענן הגדולה הראשונה שמציעה פתרון Cloud Identity Entitlement Management (CIEM) אשר תוכנן במיוחד עבור ארגונים הפועלים בסביבה מרובת עננים, והוא מספק נראות של ההרשאות עבור כל הזהויות (משתמש ועומס עבודה), הפעולות והמשאבים. Permissions Management יהיה חלק עצמאי ותוכל להתשתלב עם Microsoft Defender for Cloud במטרה להירחיב את ההגנה של Defender for Cloud עם יכולות CIEM.

Verified ID

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

בהתבסס על תקני DID, Entra Verified ID מאפשרת זהות ניידת בבעלות עצמית וכן במקרי שימוש עבור זהות מבוזרת, בין היתר: ביצוע בדיקות רקע, ניהול רישומים וביצוע אימות של אובייקטים בתצורה של B2B או B2C.

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

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

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

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

אחד המרכיבים של Verified ID הם DID. מזהים מבוזרים הם מזהים שנוצרו על ידי משתמשים, בבעלות עצמית וייחודיות גלובלית, המושרשים במערכות מבוזרות. במצב כזה יש להם מאפיינים ייחודיים, כמו אבטחה רבה יותר לבלתי משתנה, התנגדות למגבלות והתחמקות ועוד. תכונות אלו הן קריטיות עבור כל מערכת מזהה שנועדה לספק בעלות עצמית ושליטה על המשתמש. האישורים הניתנים לאימות של Entra משתמשים באישורים מבוזרים כדי לחתום בצורה קריפטוגרפית כהוכחה לכך שצד מסתמך (מאמת) מעיד על מידע המוכיח שהם הבעלים של אישור בר אימות. הבנה בסיסית של DIDs מומלצת לכל מי שיוצר פתרון אישורים שניתן לאימות המבוסס על ההצעה של Microsoft.

לסיכום

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

מיקרוסופט הציבה את Azure AD במרכז המודל של Zero Trust והוא מספק למשתמשים, מכשירים וזהויות וכן וורקלודים זהות אחת וחזקה, יחד עם מדיניות מתקדמת שמבוסס ת על סיכונים להענקה או מניעת גישה למשאבים קריטיים בהתבסס על תנאים וחוקים.

בנוסף לבקרת אימות והרשאות מודרניות עבור זהויות ואפליקציות תשתית Azure AD יכולה לספק פתרון מלא לניהול מחזור חיים של זהות על ידי שימוש בתכונות LCM של מחזור החיים ומינוף הפונקציונליות הקיימת של Cloud Sync ובין רכיבי Azure AD אחרים. במידה ומתכננים Entra אז להפעיל CIEM משולב יכול לגלות, לתקן ולנטר ברציפות סיכון הרשאה עבור כל זהות או משאב, וזה בהחלט יכול להיות חלק חשוב מאסטרטגיית Governance, או מצבים של מיזוגים ורכישות, שלעתים קרובות מציגים מערכות אקולוגיות דיגיטליות חדשות עם סיכונים חדשים.

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

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