תכנון פריטי מדיניות של גישה מותנית
תכנון הפריסה של גישה מותנית הוא קריטי להשגת אסטרטגיית הגישה של הארגון שלך עבור יישומים ומשאבים.
בעולם חדש למכשירים ניידים, בענן, המשתמשים שלך ניגשים למשאבים של הארגון שלך מכל מקום באמצעות מכשירים ואפליקציות שונים. כתוצאה מכך, ההתמקדות ב מי יכול לגשת למשאב אינה מספיקה עוד. עליך גם לשקול היכן נמצא המשתמש, את המכשיר שנמצא בשימוש, את המשאב שאליו מתבצעת גישה ועוד.
Microsoft Entra Conditional Access (CA) מנתח אותות, כגון משתמש, מכשיר ומיקום, כדי להפוך החלטות לאוטומטיות ולאכוף מדיניות גישה ארגונית עבור משאב. באפשרותך להשתמש בפריטי מדיניות של רשות אישורים (CA) כדי להחיל פקדי גישה כגון אימות רב גורמי (MFA). מדיניות רשות אישורים (CA) מאפשרת לך לבקש ממשתמשים MFA בעת הצורך לצורך אבטחה ולהישאר מחוץ לתוקף של משתמשים כאשר אין צורך.
על אף שהגדרות ברירת המחדל של האבטחה מבטיחות רמת אבטחה בסיסית, הארגון שלך זקוק לגמישות רבה יותר מהצעת ברירות המחדל של האבטחה. באפשרותך להשתמש ב- CA כדי להתאים אישית ברירות מחדל של אבטחה עם צפיפות רבות יותר ולהגדיר פריטי מדיניות חדשים שעומדים בדרישות שלך.
יתרונות
היתרונות של פריסת רשות אישורים (CA) הם:
- הגדל את הפרודוקטיביות - לקט את המשתמשים עם תנאי כניסה בלבד, כגון MFA, כאשר אות אחד או יותר מ אחר מ האחריות עליו. פריטי מדיניות של רשות אישורים (CA) מאפשרים לך לקבוע מתי משתמשים מתבקשים לספק MFA, מתי הגישה חסומה ומתי עליהם להשתמש במכשיר מהימן.
- ניהול סיכון - הפיכת הערכת סיכונים לאוטומטית באמצעות תנאי מדיניות פירושה שהכניסה המסכנה מזוהה ופותנת או נחסמה בבת אחת. גישה מותנית צימוד עם הגנת זהות, אשר מזהה חריגות ואירועים חשודים, מאפשרת לך לייעד כאשר הגישה למשאבים חסומה או משויכת.
- תאימות כתובות ופיקוח - גישה מותנית מאפשרת לך לבצע ביקורת גישה לאפליקציות, להציג תנאי שימוש להסכמה ולהגביל את הגישה בהתבסס על מדיניות תאימות.
- ניהול עלות - מדיניות גישה ל- Microsoft Entra ID מפחיתה את התלות בפתרונות מותאמים אישית או מקומיים עבור רשות אישורים ובעלויות התשתית שלהם.
- אפס אמון - גישה מותנית עוזרת לך לנוע לכיוון סביבת אפס אמון.
הבנת רכיבי מדיניות גישה מותנית
פריטי מדיניות של רשות אישורים (CA) הם משפטי אם-אז: אם מטלה תם, החל פקדי גישה אלה. כאשר מנהל המערכת מגדיר מדיניות של רשות אישורים (CA) , התנאים נקראים הקצאות. פריטי מדיניות של רשות אישורים (CA) מאפשרים לך לאכוף בקרות גישה ביישומים של הארגון שלך בהתבסס על הקצאות מסוימות.
מטלות מגדירות את המשתמשים והקבוצות להשפיע על המדיניות, האפליקציות או הפעולות בענן שעליו תחול המדיניות והתנאים שבהם המדיניות תחול. הגדרות בקרת גישה מעניקות או חוסמיות גישה לאפליקציות ענן שונות, והן יכולות לאפשר חוויות מוגבלות בתוך אפליקציות ענן ספציפיות.
כמה שאלות נפוצות אודות מטלות, פקדי גישה ופקדי הפעלה:
- משתמשים וקבוצות: אילו משתמשים וקבוצות ייכללו במדיניות או לא ייכללו בה? האם מדיניות זו כוללת את כל המשתמשים, קבוצת משתמשים ספציפית, תפקידי מדריך כתובות או משתמשים חיצוניים?
- אפליקציות או פעולות בענן: על אילו אפליקציות תחול המדיניות? אילו פעולות משתמש יהיו כפופות למדיניות זו?
- תנאים: אילו פלטפורמות מכשיר ייכללו במדיניות או לא ייכללו בה? מהן המיקומים המהימנים של הארגון?
- פקדי גישה: האם ברצונך להעניק גישה למשאבים על-ידי יישום דרישות כגון MFA, מכשירים המסומנים כמכשירים תואמים או מכשירים מצורפים היברידיים של Microsoft Entra?
- פקדי הפעלה: האם ברצונך לשלוט בגישה לאפליקציות ענן על-ידי יישום דרישות כגון הרשאות שנאכפו על-ידי היישום או בקרת יישום של גישה מותנית?
הנפקת אסימון גישה
אסימוני גישה מאפשרים ללקוחות לקרוא באופן מאובטח ממשקי API מוגנים של אינטרנט, ומשמשים אותם ממשקי API של אינטרנט כדי לבצע אימות והרשאות. לפי מפרט OAuth, אסימוני גישה הם מחרוזות אטיות ללא תבנית ערכה. ספקי זהויות (IDPs) מסוימים משתמשים במזהי GUID; משתמשים אחרים משתמשים ב- Blob מוצפנים. פלטפורמת הזהויות של Microsoft משתמשת במגוון תבניות אסימון גישה בהתאם לתצורה של ה- API שמקבל את האסימון.
חשוב להבין כיצד מונפקים אסימוני גישה.
הערה
אם לא נדרשת הקצאה, ולא חלה מדיניות של רשות אישורים, אופן הפעולה המהווה ברירת מחדל הוא להנפצת אסימון גישה.
לדוגמה, שקול מדיניות שבה:
אם המשתמש נמצא בקבוצה 1, כפה על MFA לגשת ליישום 1.
אם משתמש שאינו בקבוצה 1 מנסה לגשת ליישום, התנאי "if" הוא התנאי והונפק אסימון. אי-הכללת משתמשים מחוץ לקבוצה 1 דורשת מדיניות נפרדת לחסימת כל המשתמשים האחרים.
פעל בהתאם לשיטות העבודה המומלצות
מסגרת הגישה המותנה מספקת לך גמישות תצורה נהדרת. עם זאת, גמישות רבה גם פירושה שעליך לסקור בקפידה כל מדיניות תצורה לפני שתשחרר אותה כדי להימנע מתוצאות בלתי רצויות.
הגדרת חשבונות גישה לשעת חירום
אם תגדיר מדיניות באופן שגוי, היא תוכל לנעול את הארגונים מחוץ לפורטל Azure. צמצם את נעילת מנהל המערכת בטעות על-ידי יצירת שני חשבונות גישה לשעת חירום או יותר בארגון שלך. תקבל מידע נוסף על חשבונות גישה לשעת חירום בהמשך קורס זה.
הגדרת מצב דוח בלבד
ייתכן שקשה לחזות את מספר המשתמשים ואת שמות המשתמשים המושפעים מיוזמות פריסה נפוצות, כגון:
- חוסם אימות מדור קודם.
- נדרש MFA.
- יישום מדיניות של סיכוני כניסה.
מצב דוח בלבד מאפשר למנהלי מערכת להעריך את מדיניות רשות אישורים (CA) לפני הפיכתם לזמינים בסביבה שלהם.
אל תכלול מדינות שמהן לעולם לא תצפה לכניסה
מזהה Microsoft Entra מאפשר לך ליצור מיקומים בעלי שם. צור מיקום בעל שם הכולל את כל המדינות שמהן לא היית מצפה הכניסה להתרחש. לאחר מכן צור מדיניות עבור כל האפליקציות החוסמת את הכניסה ממיקום בעל שם זה. הקפד לפטור את מנהלי המערכת ממדיניות זו.
פריטי מדיניות נפוצים
בעת תכנון פתרון מדיניות של רשות אישורים (CA) שלך, להעריך אם עליך ליצור פריטי מדיניות כדי להשיג את התוצאות הבאות.
דרוש MFA. מקרי שימוש נפוצים כוללים דרישת MFA על-ידי מנהלי מערכת, לאפליקציות ספציפיות, לכל המשתמשים או ממיקומים ברשת שאינך נותן בהם אמון.
הגב לחשבון שעלול להיות בסכנה. ניתן להפוך שלושה פריטי מדיניות המהווים ברירת מחדל לזמינים: דרוש מכל המשתמשים להירשם ל- MFA, לדרוש שינוי סיסמה עבור משתמשים בעלי סיכון גבוה ולדרוש MFA עבור משתמשים בעלי סיכון כניסה בינוני או גבוה.
דרוש מכשירים מנוהלים. ההפצה של מכשירים נתמכים כדי לגשת למשאבי הענן שלך עוזרת לשפר את הפרודוקטיביות של המשתמשים שלך. סביר להניח שאינך מעוניין שמכשירים בעלי רמת הגנה לא ידועה יוכלו לגשת למשאבים מסוימים בסביבה שלך. עבור משאבים אלה, דרוש שהמשתמשים יוכלו לגשת אליהם רק באמצעות מכשיר מנוהל.
דרוש יישומי לקוח מאושרים. עובדים משתמשים במכשירים הניידים שלהם עבור משימות אישיות ומשימות עבודה. עבור תרחישי BYOD, עליך להחליט אם לנהל את המכשיר כולו או רק את הנתונים שבו. אם אתה מנהל רק נתונים וגישה, באפשרותך לדרוש אפליקציות ענן מאושרות העשויות להגן על הנתונים הארגוניים שלך.
חסום גישה. חסימת גישה עוקפת את כל המטלות האחרות עבור משתמש ויש לה את הכוח לחסום את הכניסה של הארגון כולו לדייר שלך. ניתן להשתמש בה, לדוגמה, כאשר אתה מעביר יישום אל Microsoft Entra ID, אך אינך מוכן עדיין להיכנס אליה. באפשרותך גם לחסום מיקומי רשת מסוימים לגשת לאפליקציות הענן שלך או לחסום אפליקציות באמצעות אימות מדור קודם מלגשת למשאבי הדייר שלך.
חשוב
אם אתה יוצר מדיניות לחסימת גישה עבור כל המשתמשים, הקפד לא לכלול חשבונות גישה לשעת חירום ושקול לא לכלול את כל מנהלי המערכת במדיניות.
בנייה ובדיקה של פריטי מדיניות
בכל שלב בפריסה, ודא שאתה מעריך שהתוצאות הן כצפוי.
כאשר פריטי מדיניות חדשים מוכנים, פרוס אותם בשלבים בסביבת הייצור:
- ספק תקשורת בין שינויים פנימיים למשתמשי קצה.
- התחל עם קבוצה קטנה של משתמשים וודא שהמדיניות מתנהגת כצפוי.
- בעת הרחבת מדיניות כדי לכלול משתמשים נוספים, המשך לא לכלול את כל מנהלי המערכת. אי-הכללת מנהלים מבטיחה של מישהו עדיין תהיה גישה למדיניות אם נדרש שינוי.
- החל מדיניות על כל המשתמשים רק לאחר בדיקה יסודית. ודא שיש לך חשבון מנהל מערכת אחד לפחות שעליו מדיניות אינה חלה.
יצירת משתמשי בדיקה
צור ערכה של משתמשי בדיקה המשקפים את המשתמשים בסביבת הייצור שלך. יצירת משתמשי בדיקה מאפשרת לך לוודא שמדיניות פועלת כצפוי לפני שתחיל על משתמשים אמיתיים ותשבש את הגישה שלהם ליישומים ולהמשאבים.
לארגונים מסוימים יש דיירי בדיקה למטרה זו. עם זאת, ייתכן שקשה ליצור מחדש את כל התנאים והאפליקציות בדייר בדיקה כדי לבדוק באופן מלא את התוצאה של מדיניות.
יצירת תוכנית בדיקה
חשוב שתוכנית הבדיקה תכלול השוואה בין התוצאות הצפויות לבין התוצאות בפועל. תמיד צריך להיות לך ציפיות לפני בדיקת משהו. הטבלה הבאה מתארת דוגמאות של מקרי בדיקה. התאם את התרחישים ואת התוצאות הצפויות בהתבסס על האופן שבו מדיניות רשות אישורים (CA) מוגדרת.
| שם המדיניות | תרחיש | תוצאה צפויה |
|---|---|---|
| דרוש MFA בעת העבודה | משתמש מורשה נכנס לאפליקציה בזמן שאתה נמצא במיקום מהימן / בעבודה | המשתמש אינו מתבקש לספק MFA. המשתמש מורשה לגשת. המשתמש מתחבר ממיקום מהימן. באפשרותך לבחור לדרוש MFA במקרה זה. |
| דרוש MFA בעת העבודה | משתמש מורשה נכנס לאפליקציה כאשר הוא לא נמצא במיקום מהימן / עבודה | המשתמש מתבקש ל- MFA והוא יכול להיכנס בהצלחה |
| דרוש MFA (עבור מנהל מערכת) | מנהל מערכת כללי נכנס לאפליקציה | מנהל המערכת מתבקש לספק MFA |
| כניסה מסיכונים | המשתמש נכנס לאפליקציה באמצעות דפדפן לא שקול | המשתמש מתבקש לספק MFA |
| ניהול מכשירים | משתמש מורשה מנסה להיכנס ממכשיר מורשה | הגישה הוענקה |
| ניהול מכשירים | משתמש מורשה מנסה להיכנס ממכשיר לא מורשה | הגישה נחסמה |
| שינוי סיסמה עבור משתמשים מסיכונים | משתמש מורשה מנסה להיכנס עם אישורים שנחשף לסכנה (כניסה בסיכון גבוה) | המשתמש מתבקש לשנות סיסמה או גישה חסומה בהתבסס על המדיניות שלך |
דרישות רישיון
- מזהה Entra של Microsoft ללא תשלום - ללא גישה מותנית
- מנוי Office 365 ללא תשלום - ללא גישה מותנית
- Microsoft Entra ID Premium 1 (או Microsoft 365 E3 ותואר למעלה) - גישה מותנית פועלת בהתבסס על כללים רגילים
- Microsoft Entra ID Premium 2 - גישה מותנית, ואתה מקבל את היכולת להשתמש באפשרויות כניסה מסיכונים, משתמשים מסיכונים ואפשרויות כניסה מבוססות סיכון (מתוך Identity Protection)