סקירה כללית על Privileged Access Manager

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

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

  • קבוצה של חשבונות משתמשים שיכולים לבקש גישה להרשאה.

  • אם נדרשת הצדקה להענקת הגישה.

  • קבוצה של תפקידים להקצאה זמנית. אפשר להגדיר תנאי IAM לתפקידים.

  • משך הזמן המקסימלי של בקשת הגישה.

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

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

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

תרחישים לדוגמה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יכולות ומגבלות

בקטעים הבאים מתוארות היכולות והמגבלות השונות של Privileged Access Manager.

משאבים נתמכים

ב-Privileged Access Manager אפשר ליצור הרשאות ולבקש מענקים לפרויקטים, לתיקיות ולארגונים.

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

תפקידים נתמכים

ב-Privileged Access Manager אפשר להשתמש בתפקידים מוגדרים מראש, בתפקידים בהתאמה אישית ובתפקידים בסיסיים של אדמין, כתיבה וקריאה. ב-Privileged Access Manager אי אפשר להשתמש בתפקידים בסיסיים מדור קודם (בעלים, עריכה וצפייה).

זהויות נתמכות

Privileged Access Manager תומך בכל סוגי הזהויות, כולל Cloud Identity, איחוד שירותי אימות הזהות של כוח עבודה, איחוד זהויות של עומסי עבודה וזהויות של נציגים.

רישום ביומן ביקורת

אירועים של Privileged Access Manager, כמו יצירת הרשאות, בקשה או בדיקה של הרשאות, מתועדים ביומני הביקורת של Cloud. רשימה מלאה של האירועים ש-Privileged Access Manager יוצר להם יומנים מופיעה במסמכי התיעוד של רישום ביומן הביקורת של Privileged Access Manager. במאמר ביקורת על אירועי הרשאות והקצאות ב-Privileged Access Manager מוסבר איך לצפות ביומנים האלה.

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

אדמינים ב-Privileged Access Manager יכולים להגדיר אישורים בכמה רמות ומכמה גורמים. האפשרות הזו שימושית בתרחישים לדוגמה שכוללים:

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

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

התאמה אישית של היקף הגישה

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

אישורים של חשבונות שירות וזהויות של סוכנים

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

תמיכה בירושה

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

התאמה אישית של ההעדפות לגבי התראות

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

תזמון הענקת גישה

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

ביטול הגישה

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

שימור מענקים

הרשאות נמחקות באופן אוטומטי מ-Privileged Access Manager‏ 30 ימים אחרי שהן נדחות, מבוטלות, נמשכות, פגות או מסתיימות. יומני ההרשאות נשמרים ביומני הביקורת של Cloud למשך תקופת השמירה של היומנים בקטגוריה _Required. במאמר ביקורת על אירועי הרשאות והקצאות ב-Privileged Access Manager מוסבר איך לצפות ביומנים האלה.

שינויים במדיניות של Privileged Access Manager ו-IAM

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

אם קישורי התפקידים האלה ישתנו על ידי משהו אחר מלבד Privileged Access Manager, יכול להיות ש-Privileged Access Manager לא יפעל כצפוי.

כדי למנוע את הבעיה הזו, מומלץ לבצע את הפעולות הבאות:

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

התראות

בקטעים הבאים מוסבר איך Privileged Access Manager יכול לשלוח לכם התראות על אירועים שונים שמתרחשים ב-Privileged Access Manager.

התראות באימייל

Privileged Access Manager שולח התראות באימייל לבעלי העניין הרלוונטיים לגבי שינויים בהרשאות ובאישורים. אלה קבוצות הנמענים:

  • מי יכול לבקש הרשאה:

    • כתובות אימייל של משתמשים וקבוצות ב-Cloud Identity שצוינו כמבקשים בהרשאה.
    • כתובות אימייל שהוגדרו ידנית בהרשאה: כשמשתמשים במסוףGoogle Cloud , כתובות האימייל האלה מופיעות בשדה נמעני אימייל של מבקשים בקטע הוספת מבקשים. כשמשתמשים ב-CLI של gcloud או ב-API בארכיטקטורת REST, כתובות האימייל האלה מופיעות בשדה requesterEmailRecipients.

  • הענקת הרשאות לאישורים:

    • כתובות אימייל של משתמשים וקבוצות ב-Cloud Identity שצוינו כמאשרים ברמת האישור.
    • כתובות אימייל שהוגדרו ידנית בהרשאה: כשמשתמשים במסוףGoogle Cloud , כתובות האימייל האלה מופיעות בשדה Approval email recipients בקטע Add approvers. כשמשתמשים ב-CLI של gcloud או ב-API בארכיטקטורת REST, כתובות האימייל האלה מופיעות בשדה approverEmailRecipients של שלבי תהליך האישור.

  • האדמין של ההרשאה:

    • כתובות אימייל שהוגדרו ידנית בהרשאה: כשמשתמשים במסוףGoogle Cloud , כתובות האימייל האלה מופיעות בשדה Admin email recipients בקטע Entitlement details. כשמשתמשים ב-CLI של gcloud או ב-API בארכיטקטורת REST, כתובות האימייל האלה מופיעות בשדה adminEmailRecipients.

  • מבקש המענק:

    • כתובת האימייל של מבקש ההרשאה, אם הוא משתמש ב-Cloud Identity.
    • כתובות אימייל נוספות שהוסיף מבקש ההרשאה בזמן שליחת הבקשה: כשמשתמשים במסוף Google Cloud , כתובות האימייל האלה מופיעות בשדה כתובות אימייל נוספות. כשמשתמשים ב-CLI של gcloud או ב-API בארכיטקטורת REST, כתובות האימייל האלה מופיעות בשדה additionalEmailRecipients.

הכלי Privileged Access Manager שולח אימיילים לכתובות האלה באירועים הבאים:

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

התראות Pub/Sub

כדי לקבל התראות על שינויים בהרשאות דרך Pub/Sub, מומלץ לנתב את יומני הביקורת של Cloud ל-Pub/Sub באמצעות כיור של Cloud Logging. מידע נוסף על אירועי הביקורת הזמינים מופיע במאמר רישום ביומן ביקורת של Privileged Access Manager.

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