סימולטור המדיניות למדיניות דחייה מאפשר לכם לראות איך שינוי במדיניות דחייה של IAM עשוי להשפיע על הגישה של חשבון משתמש לפני שאתם מבצעים את השינוי. אתם יכולים להשתמש בסימולטור של המדיניות כדי לוודא שהשינויים לא יגרמו לאובדן הרשאות הגישה שנחוצות לחשבון המשתמש.
התכונה הזו מעריכה רק מדיניות דחייה. כדי ללמוד איך לדמות סוגי מדיניות אחרים, אפשר לעיין במאמרים הבאים:
- סימולטור מדיניות למדיניות ארגונית
- סימולטור מדיניות למדיניות הרשאה
- כלי לסימולציה של מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)
איך פועל סימולטור המדיניות לכללי מדיניות הדחייה
סימולטור המדיניות למדיניות דחייה עוזר לכם לקבוע אם שינוי במדיניות דחייה יחסום גישה שחשבונות המשתמשים שלכם משתמשים בה.
כשמריצים הדמיה למדיניות דחייה, כלי סימולטור המדיניות מבצע את הפעולות הבאות:
מאחזר יומני גישה לארגון שנוצרו במהלך תקופת ההפעלה מחדש. תקופת ההפעלה מחדש היא 90 ימים.
אם הארגון קיים פחות מ-90 ימים, כלי סימולטור המדיניות מאחזר את כל יומני הגישה מאז שהארגון נוצר.
קובעת אילו יומני גישה רלוונטיים לסימולציה. יומני גישה רלוונטיים הם כל יומני הגישה שמייצגים את הניסיון האחרון של חשבון משתמש להשתמש בהרשאה כדי לגשת למשאב.
לכל יומן גישה רלוונטי, המערכת קובעת אם מדיניות הדחייה הנוכחית, יחד עם השינויים המוצעים, תאפשר את הניסיון לגשת. התהליך הזה נקרא הפעלה מחדש של ניסיונות הגישה.
לכל יומן גישה, המערכת משווה את מצב הגישה מההפעלה החוזרת למצב הגישה ביומני הגישה. לאחר מכן, כלי סימולטור המדיניות מדווח על ניסיונות גישה היסטוריים שלא נחסמו ביומן הגישה, אבל נחסמו בהפעלה החוזרת. ההבדלים האלה נקראים שינויים בגישה, והם מראים אילו ניסיונות גישה היו נחסמים אם מדיניות הדחייה המדומה הייתה בתוקף בזמן הניסיון.
תקופת ההפעלה מחדש
תקופת ההפעלה מחדש היא הזמן שבו כלי סימולציית המדיניות מקבל גישה ליומני אירועים כדי להריץ סימולציה. יומני גישה שמתרחשים לפני היום הראשון של תקופת ההפעלה החוזרת או אחרי היום האחרון של תקופת ההפעלה החוזרת לא נכללים בסימולציה. תקופת ההפעלה מחדש היא 90 ימים. אם משאב הארגון קיים פחות מהזמן הזה, כלי סימולטור המדיניות מאחזר את כל ניסיונות הגישה מאז שהארגון נוצר. חלון הזמנים לצפייה חוזרת הוא גם עקביות הדרגתית. כלומר, כשמריצים סימולציה, יכול להיות שחלק מהנתונים יהיו עדכניים יותר מנתונים אחרים. עם זאת, בסופו של דבר, כל הנתונים יהיו עדכניים באותה מידה. עם מודל עקביות הדרגתי, תקופת ההפעלה מחדש מסתיימת בדרך כלל תוך כמה ימים, אבל יכולה להסתיים עד 15 ימים מוקדם יותר. תוצאות הסימולציה מראות את חלון ההפעלה המדויק. יומני גישה שנוצרו אחרי התקופה הזו לא נכללים.
תוצאות של סימולטור המדיניות
בסימולטור של המדיניות מדווחים על ההשפעה של שינוי מוצע במדיניות דחייה כרשימה של שינויים בגישה. במדיניות דחייה, סוג השינוי היחיד בגישה שמדווח עליו בסימולטור המדיניות הוא שינוי הגישה Access revoked (הגישה בוטלה).
דוחות סימולטור המדיניות מציינים שהגישה בוטלה אם התנאים הבאים מתקיימים:
- הניסיון האחרון של הגורם המורשה לגשת למשאב הצליח
- השינויים המוצעים או מדיניות דחייה אחרת חוסמים את הגישה של חשבון המשתמש למשאב
בנוסף, סימולטור המדיניות מדווח על המידע הבא לגבי כל שינוי בגישה:
- חשבון המשתמש, המשאב וההרשאה שקשורים לניסיון הגישה.
- מספר הימים במהלך תקופת ההפעלה מחדש שבהם הגורם הראשי ניסה להשתמש בהרשאה כדי לגשת למשאב. הסכום הכולל הזה כולל רק את הניסיונות לגשת לחשבון שהתוצאה שלהם זהה לתוצאה של הניסיון האחרון לגשת לחשבון.
- התאריך של ניסיון הגישה האחרון.
שגיאות
השגיאות הבאות עלולות לגרום לסימולציה להיכשל:
- חריגה ממספר הסימולציות המקסימלי שמתבצעות בו-זמנית: למשתמש יש כבר 50 סימולציות שמתבצעות בו-זמנית, שזה המספר המקסימלי של סימולציות שמתבצעות בו-זמנית שלמשתמש יכולות להיות. כדי לפתור את הבעיה, צריך לחכות עד שאחת מהסימולציות שמתבצעות תסתיים, ואז לנסות להריץ שוב את הסימולציה.
- זמן קצוב לתפוגה: ההרצה של ההדמיה נמשכה יותר מדי זמן והיא הופסקה בגלל זמן קצוב לתפוגה. כל סימולציה שנמשכת יותר מ-24 שעות מסתיימת אוטומטית. כדי לפתור את הבעיה, מומלץ להפעיל שוב את הסימולציה או להקטין את הגודל שלה.
- מבנה הסימולציה לא תקין: מדיניות הדחייה המוצעת לא תקינה או שהיא מכילה כללי דחייה שלא נתמכים. דוגמה למדיניות לא תקינה היא מדיניות שמכילה ביטוי תנאי לא תקין. דוגמה לכלל דחייה שלא נתמך היא כלל שמשתמש במזהים של ישויות (principal) של זהויות כוח עבודה. כדי לפתור את הבעיה, צריך לתקן את המדיניות ולנסות שוב.
- ההרשאה נדחתה: אין לכם הרשאה להפעיל סימולציה. כדי לפתור את הבעיה, צריך לוודא שהוקצו לכם התפקידים הנדרשים ולנסות שוב.
סוגי החשבונות הנתמכים
סימולטור המדיניות לכללי מדיניות הדחייה בודק רק את יומני הגישה לסוגי החשבונות הבאים:
- חשבונות Google Workspace
- חשבונות שירות
- קבוצות של חשבונות משתמשים של חשבונות שירות לפרויקטים, לתיקיות ולארגונים
- סוכני שירות
- ישות מורשית של סוכן שירות לפרויקטים, לתיקיות ולארגונים
כשמדמים מדיניות של דחיית גישה, הכלי Policy Simulator לא בודק יומני גישה של אף סוג אחר של חשבון משתמש, כולל כאלה שמבוססים על זהויות מאוחדות במאגר זהויות של עומסי עבודה. כתוצאה מכך, סימולטור המדיניות לא מדווח אם השינויים המוצעים במדיניות או בהרשאות שלכם משפיעים על הגישה של חשבונות המשתמש האלה.
הדמיה של גבולות גישה לפרטי כניסה
אתם יכולים להשתמש בגבולות גישה לפרטי כניסה כדי לצמצם (להגביל) את הרשאות ה-IAM שניתנות לפרטי כניסה עם תוקף קצר, כדי לגשת למשאבים של Cloud Storage. כדי לצמצם את היקף ההרשאות, משתמש או חשבון שירות (ברוקר האסימונים) מגדירים את ההרשאות הזמינות בקבוצת משאבים באסימון גישה עם היקף מצומצם, ואז מספקים את אסימון הגישה למשתמש או לחשבון שירות אחר (צרכן האסימונים).
לברוקר האסימון צריך להיות תפקיד שכולל את ההרשאות שניתנות לצרכן האסימון עם אסימון גישה עם היקף מצומצם. דחיית התפקיד הזה ב-token broker גם מסירה את הגישה מצרכן הטוקן. עם זאת, סימולטור המדיניות לא בודק איך שינויים בהרשאות של ברוקר האסימונים משפיעים על הגישה של צרכן האסימונים.
לדוגמה, נניח שלמשתמש מסוים הוקצה התפקיד Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) במשאב באמצעות אסימון גישה עם היקף מצומצם שנוצר באמצעות Credential Access Boundary.
אם תדמו שלילת הגישה לתפקיד קריאה בקטגוריה באחסון מדור קודם עבור המשתמש הזה, סימולטור המדיניות לא ידווח על אובדן גישה.
אם תדמו סירוב להעניק את התפקיד Storage Legacy Bucket Reader ב-Token Broker, הכלי Policy Simulator לא ידווח על אובדן גישה למשתמש. באופן דומה, אם לא נעשה שימוש בגישה של ברוקר האסימונים תוך 90 ימים, הגישה שלו לא נכללת בסימולציה.
מידע נוסף זמין במאמר גבולות גישה של פרטי כניסה ל-Cloud Storage.