סקירה כללית על גישה זמנית עם הרשאות גבוהות

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

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

ב- Google Cloud, יש כמה דרכים לנהל גישה זמנית מורחבת מהסוג הזה.

Privileged Access Manager

אתם יכולים להשתמש ב-Privileged Access Manager ‏ (PAM) כדי לנהל הרשאות זמניות שמוקצות לחשבונות משתמשים נבחרים רק כשצריך, וכדי לצפות ביומני הביקורת לאחר מכן ולגלות למי הייתה גישה למה ומתי.

יכול להיות שתרצו לספק הרשאות זמניות באמצעות Privileged Access Manager במקרים הבאים:

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

  • שליטה בגישה למשאבים רגישים: שליטה הדוקה בגישה למשאבים רגישים, עם דרישה לאישורים ולהצדקות עסקיות. אפשר גם להשתמש ב-Privileged Access Manager כדי לבדוק איך נעשה שימוש בגישה הזו – למשל, מתי התפקידים שהוקצו היו פעילים עבור משתמש, אילו משאבים היו נגישים במהלך הזמן הזה, מה היה הנימוק לגישה ומי אישר אותה.

    לדוגמה, אפשר להשתמש ב-Privileged Access Manager כדי:

    • לתת למפתחים גישה זמנית לסביבות ייצור לצורך פתרון בעיות או פריסות.

    • לתת למהנדסי תמיכה גישה לנתונים רגישים של לקוחות למשימות ספציפיות.

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

  • הטמעה של הרשאות מינימליות ברמת גרנולרית: הקצאת תפקידי אדמין או גישה רחבה לכל המשתמשים עלולה להגדיל את שטח הפנים להתקפה. כדי למנוע את זה, אדמינים יכולים להקצות תפקידים קבועים עם הרשאות מינימליות ולהשתמש ב-Privileged Access Manager כדי לספק גישה זמנית ומוגבלת בזמן עם הרשאות מורחבות למשימות ספציפיות כשצריך. אדמינים יכולים ליצור הרשאות עם תנאים מבוססי-תגים ולאכוף על מבקשי ההרשאות ליצור בקשות למתן הרשאות עם היקף מותאם אישית, ולבטל את ההרשאות אחרי שהמשימה הושלמה. כך מצטמצמים באופן משמעותי הסיכויים לשימוש לרעה, ומתחזק העיקרון של גישה 'בזמן אמת'.

  • הפיכת אישורי גישה עם הרשאות מיוחדות לאוטומטיים: כדי לשפר את היעילות, אתם יכולים להגדיר חשבונות שירות כגורמים מאשרים בצינורות ה-DevOps. בחשבונות האלה אפשר לבצע אוטומציה של אישורים פרוגרמטיים באמצעות אימות כרטיסים ישירות ממערכות ITSM, וכך לבטל בדיקות ידניות איטיות.

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

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

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

מידע נוסף על הגדרת Privileged Access Manager זמין במאמר סקירה כללית על Privileged Access Manager.

מידע נוסף על בקשת הרשאת גישה זמנית זמין במאמר בקשת הרשאת גישה זמנית.

קבוצות Google

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

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

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

אם רוצים לתעד את ההצדקות של המשתמש לגישה למשאבים רגישים, צריך להגדיר תהליכים תפעוליים וכלים משלכם.

לדוגמה, כדי לנהל גישת חירום למשאבי Compute Engine, אפשר ליצור קבוצה, emergency-compute-access@example.com, ולהקצות לה את התפקיד אדמין Compute‏ (roles/compute.admin). אם משתמש צריך הרשאת אדמין לשעת חירום למשאבי מחשוב, אפשר להוסיף אותו לקבוצה emergency-compute-access@example.com. אחרי שהאירוע יסתיים, תוכלו להסיר אותם מהקבוצה.

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

אפשר להשתמש בתנאים של IAM כדי להעניק למשתמשים גישה למשאביGoogle Cloud שתוקפה יפוג. מידע נוסף מופיע במאמר בנושא הגדרת גישה זמנית.

אם רוצים לתעד את ההצדקות של המשתמש לגישה למשאבים רגישים, צריך להגדיר תהליכים תפעוליים וכלים משלכם.

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

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

גישה מורשית בדיוק בזמן

גישת Just-In-Time היא אפליקציה בקוד פתוח שמשתמשת בתנאי IAM כדי להעניק למשתמשים גישה עם הרשאות למשאבים ב- Google Cloudרק בזמן שהם צריכים אותה. האפליקציה הזו מיועדת להפעלה ב-App Engine או ב-Cloud Run.

לאפליקציה הזו יש יתרונות לעומת הוספה ידנית של קישורי תפקידים מותנים:

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

מידע נוסף על גישת Just-In-Time זמין במאמר ניהול גישת Just-In-Time עם הרשאות לפרויקטים.

התחזות לחשבון שירות

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

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

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

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

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

    במאמר שימוש בהתחזות לחשבון שירות מוסבר איך מתחזים לחשבונות שירות.

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

    בשיטה הזו, אתם יכולים להחליט מתי לאפשר למשתמשים להתחזות לחשבון השירות.

    במאמר יצירת פרטי כניסה לטווח קצר לחשבון שירות מוסבר איך ליצור פרטי כניסה לטווח קצר.

מידע נוסף על התחזות לחשבון שירות זמין במאמר התחזות לחשבון שירות.

המאמרים הבאים