שימוש מאובטח בפלטפורמה לניהול הזהויות והרשאות הגישה

בדף הזה מפורטות שיטות מומלצות לאבטחה שכדאי לזכור כשמשתמשים ב-IAM.

הדף הזה מיועד למשתמשים שמכירים את IAM. אם אתם רק מתחילים להשתמש ב-IAM, ההוראות האלה לא ילמדו אתכם איך להשתמש בו. משתמשים חדשים צריכים להתחיל עם מדריך IAM למתחילים.

הרשאות מינימליות

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

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

❑   חשוב לזכור שכללי מדיניות ההרשאות של משאבים צאצאים יורשים את כללי מדיניות ההרשאות מהמשאבים ההורים. לדוגמה, אם מדיניות ההרשאות של הפרויקט מאפשרת למשתמש לנהל מכונות וירטואליות (VM) של Compute Engine, המשתמש יכול לנהל כל מכונה וירטואלית של Compute Engine באותו פרויקט, בלי קשר למדיניות ההרשאות שתגדירו לכל מכונה וירטואלית.

❑   כדאי להקצות את התפקידים בהיקף הקטן ביותר הנדרש. לדוגמה, אם משתמש מסוים צריך גישה רק כדי לפרסם נושאים ב-Pub/Sub, מקצים לו את התפקיד מפרסם בנושא הזה.

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

❑   קובעים למי יש גישה ליצירה ולניהול של חשבונות שירות בפרויקט.

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

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

חשבונות שירות

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

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

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

מפתחות של חשבונות שירות

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

❑   מבצעים רוטציה של המפתחות של חשבון השירות באמצעות IAM service account API. אפשר לבצע רוטציה של מפתח על ידי יצירת מפתח חדש, החלפת אפליקציות כדי שהן ישתמשו במפתח החדש, השבתה של המפתח הישן ומחיקה של המפתח הישן כאשר בטוחים שכבר אין בו צורך.

❑   הטמעת תהליכים לניהול מפתחות של חשבונות שירות בניהול המשתמש.

❑   חשוב לא להתבלבל בין מפתחות הצפנה לבין מפתחות של חשבונות שירות. מפתחות הצפנה משמשים בדרך כלל להצפנת נתונים, ומפתחות של חשבונות שירות משמשים לגישה מאובטחת ל-API של Google Cloud .

❑   לא להכניס את המפתחות של חשבונות השירות לקוד המקור ולא להשאיר אותם בספריית ההורדות.

ביצוע בקרה

❑   אפשר להשתמש ביומנים מיומני הביקורת של Cloud כדי לבדוק באופן שוטף את השינויים בכללי מדיניות ההרשאה.

❑   ייצוא יומני ביקורת ל-Cloud Storage כדי לאחסן את היומנים לפרקי זמן ארוכים.

❑   ביצוע ביקורת כדי לראות למי יש אפשרות לשנות את מדיניות ההרשאות בפרויקטים.

❑   אפשר לנהל את הגישה ליומנים באמצעות תפקידי Logging.

❑   החלת אותן מדיניות גישה על Google Cloud המשאב שמשמש לניתוב יומנים, כמו על הכלי Logs Explorer.

❑   להשתמש ביומנים מיומני הביקורת של Cloud כדי לבדוק באופן שוטף את הגישה למפתחות של חשבונות שירות.

ניהול המדיניות

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

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