בקטע הזה נסביר איך להשתמש ב-Cloud Identity כדי לנהל את הזהויות שבהן העובדים משתמשים כדי לגשת לשירותי Google Cloud.
ספק זהויות חיצוני כמקור האמת
מומלץ לאחד את חשבון Cloud Identity עם ספק הזהויות הקיים. הפדרציה עוזרת להבטיח שתהליכי ניהול החשבונות הקיימים שלכם יחולו על Google Cloud ועל שירותים אחרים של Google.
אם אין לכם ספק זהויות קיים, אתם יכולים ליצור חשבונות משתמשים ישירות ב-Cloud Identity.
בתרשים הבא מוצגת סקירה כללית של איחוד שירותי אימות הזהות וכניסה יחידה (SSO). הוא משתמש ב-Microsoft Active Directory, שנמצא בסביבה המקומית, כספק הזהויות לדוגמה.
בתרשים הזה מתוארות השיטות המומלצות הבאות:
- זהויות המשתמשים מנוהלות בדומיין Active Directory שנמצא בסביבה המקומית ומאוחד עם Cloud Identity. Active Directory משתמש ב-Google Cloud Directory Sync כדי להקצות זהויות ל-Cloud Identity.
- משתמשים שמנסים להיכנס לשירותי Google מופנים לספק הזהויות החיצוני כדי לבצע כניסה יחידה (SSO) באמצעות SAML, והם משתמשים בפרטי הכניסה הקיימים שלהם כדי לבצע אימות. אין סיסמאות שמסונכרנות עם Cloud Identity.
בטבלה הבאה מופיעים קישורים להנחיות להגדרה של ספקי זהויות.
| ספק הזהויות | הדרכה |
|---|---|
| Active Directory | |
| Microsoft Entra ID (לשעבר Azure AD) | |
| ספקי זהויות חיצוניים אחרים (לדוגמה, Ping או Okta) |
מומלץ מאוד לאכוף אימות רב-שלבי אצל ספק הזהויות באמצעות מנגנון עמיד בפני פישינג, כמו מפתח אבטחה Titan.
ההגדרות המומלצות ל-Cloud Identity לא מוגדרות אוטומטית באמצעות קוד Terraform בתוכנית הזו. במאמר בנושא אמצעי בקרה אדמיניסטרטיביים ב-Cloud Identity מפורטות הגדרות האבטחה המומלצות שצריך להגדיר בנוסף לפריסת קוד Terraform.
קבוצות לבקרת גישה
חשבון משתמש הוא זהות שאפשר להעניק לה גישה למשאב. חשבונות משתמשים כוללים חשבונות Google למשתמשים, קבוצות Google, חשבונות Google Workspace, דומיינים ב-Cloud Identity וחשבונות שירות. יש גם שירותים שמאפשרים להעניק גישה לכל המשתמשים שמבצעים אימות באמצעות חשבון Google, או לכל המשתמשים באינטרנט. כדי שישות מורשית תוכל ליצור אינטראקציה עם שירותים, עליך להקצות לה תפקידים בניהול זהויות והרשאות גישה (IAM). Google Cloud
כדי לנהל תפקידי IAM בהיקף גדול, מומלץ להקצות משתמשים לקבוצות על סמך תפקידיהם ודרישות הגישה שלהם, ואז להעניק תפקידי IAM לקבוצות האלה. כדאי להוסיף משתמשים לקבוצות באמצעות התהליכים בספק הזהויות הקיים שלכם ליצירת קבוצות ולחברות בהן.
אנחנו לא ממליצים להקצות תפקידי IAM למשתמשים ספציפיים, כי הקצאות כאלה יכולות להגדיל את המורכבות של ניהול תפקידים וביקורת שלהם.
תוכנית האב מגדירה קבוצות ותפקידים עם גישה לצפייה בלבד במשאבי הבסיס. מומלץ לפרוס את כל המשאבים בתוכנית הבסיסית באמצעות צינור הנתונים של הבסיס, ולא להקצות תפקידים למשתמשים או לקבוצות כדי לשנות משאבי בסיס מחוץ לצינור הנתונים.
בטבלה הבאה מוצגות הקבוצות שמוגדרות על ידי התוכנית ליצירת תשתית לצפייה במשאבי הבסיס.
| שם | תיאור | תפקידים | היקף |
|---|---|---|---|
grp-gcp-org-admin@example.com | אדמינים עם הרשאות גבוהות במיוחד שיכולים להקצות תפקידי IAM ברמת הארגון. הם יכולים לגשת לכל תפקיד אחר. לא מומלץ להשתמש בהרשאה הזו באופן יומיומי. | אדמין ארגוני | ארגון |
grp-gcp-billing-admin@example.com |
אדמינים עם הרשאות גבוהות שיכולים לשנות את החשבון לחיוב ב-Cloud. לא מומלץ להשתמש בהרשאה הזו על בסיס יומי. | אדמין של חשבון לחיוב | ארגון |
grp-gcp-billing-viewer@example.com | הצוות שאחראי לצפייה בהוצאות ולניתוח שלהן בכל הפרויקטים. | צפייה בחשבון לחיוב | ארגון |
| BigQuery User | פרויקט חיוב | ||
grp-gcp-audit-viewer@example.com |
הצוות שאחראי לביקורת של יומנים שקשורים לאבטחה. | פרויקט רישום ביומן | |
grp-gcp-security-reviewer@example.com |
הצוות שאחראי על בדיקת האבטחה בענן. | בודק אבטחה | ארגון |
grp-gcp-network-viewer@example.com |
הצוות שאחראי על הצגה ותחזוקה של הגדרות הרשת. | צפייה ברשת Compute | ארגון |
grp-gcp-scc-admin@example.com |
הצוות שאחראי על הגדרת Security Command Center. | Security Center Admin Editor | ארגון |
grp-gcp-secrets-admin@example.com |
הצוות שאחראי לניהול, לאחסון ולביקורת של פרטי הכניסה וסודות אחרים שמשמשים את האפליקציות. | Secret Manager Admin | פרויקטים של סודות |
grp-gcp-kms-admin@example.com |
הצוות שאחראי לאכיפת ניהול מפתחות ההצפנה כדי לעמוד בדרישות התאימות. | Cloud KMS Viewer | kms projects |
כשמפתחים עומסי עבודה משלכם על בסיס התשתית, יוצרים קבוצות נוספות ומקצים תפקידי IAM שמבוססים על דרישות הגישה לכל עומס עבודה.
מומלץ מאוד להימנע משימוש בתפקידים בסיסיים (כמו בעלים, עריכה או צפייה) ולהשתמש במקום זאת בתפקידים מוגדרים מראש. ההרשאות בתפקידים הבסיסיים הן רחבות מדי, ויש בהם סיכון אבטחה פוטנציאלי. התפקידים 'בעלים' ו'עריכה' עלולים להוביל להסלמת הרשאות (privilege escalation) ולתנועה רוחבית, והתפקיד 'צפייה' כולל גישה לקריאת כל הנתונים. במאמר שימוש מאובטח ב-IAM מפורטות שיטות מומלצות לשימוש בתפקידי IAM.
חשבונות סופר-אדמין
משתמשי Cloud Identity עם חשבון סופר-אדמין עוקפים את הגדרות ה-SSO של הארגון ומבצעים אימות ישירות ב-Cloud Identity. החריגה הזו היא מכוונת, כדי שסופר-אדמין עדיין יוכל לגשת למסוף Cloud Identity במקרה של הגדרה שגויה או הפסקה זמנית בשירות של SSO. עם זאת, המשמעות היא שצריך להוסיף אמצעי הגנה לחשבונות סופר-אדמין.
כדי להגן על חשבונות הסופר-אדמינים, מומלץ תמיד לאכוף אימות דו-שלבי באמצעות מפתחות אבטחה ב-Cloud Identity. מידע נוסף זמין במאמר שיטות מומלצות לשמירה על אבטחה בחשבונות של אדמינים.
בעיות בחשבונות משתמשים לצרכן
אם לא השתמשתם ב-Cloud Identity או ב-Google Workspace לפני שהצטרפתם ל- Google Cloud, יכול להיות שהעובדים בארגון שלכם כבר משתמשים בחשבונות לצרכן שמשויכים לזהויות האימייל העסקיות שלהם כדי לגשת לשירותים אחרים של Google, כמו Google Marketing Platform או YouTube. חשבונות לצרכן הם חשבונות שנמצאים בבעלות ובניהול מלאים של האנשים שיצרו אותם. החשבונות האלה לא נמצאים בשליטת הארגון שלכם, ויכול להיות שהם כוללים נתונים אישיים ונתונים ארגוניים. לכן אתם צריכים להחליט איך לאחד את החשבונות האלה עם חשבונות ארגוניים אחרים.
מומלץ לאחד את חשבונות המשתמשים הקיימים לשימוש אישי כחלק מתהליך ההצטרפות ל- Google Cloud. אם אתם לא משתמשים ב-Google Workspace בכל חשבונות המשתמשים, מומלץ לחסום את הגישה לחשבונות פרטיים.
אמצעי בקרה אדמיניסטרטיביים ל-Cloud Identity
ב-Cloud Identity יש אמצעי בקרה ניהוליים שונים שלא מופעלים אוטומטית על ידי קוד Terraform בתוכנית ה-blueprint. מומלץ להחיל כל אחד מהאמצעים האלה לאבטחה בשלב מוקדם בתהליך בניית הבסיס.
| שליטה | תיאור |
|---|---|
| פריסה של אימות דו-שלבי | יכול להיות שחשבונות משתמשים ייפרצו באמצעות פישינג, הנדסה חברתית, ריסוס סיסמאות או איומים שונים אחרים. אימות דו-שלבי עוזר לצמצם את האיומים האלה. מומלץ לאכוף אימות דו-שלבי בכל חשבונות המשתמשים בארגון באמצעות מנגנון עמיד בפני פישינג, כמו מפתחות אבטחה Titan או מפתחות אחרים שמבוססים על תקני FIDO U2F (CTAP1) העמידים בפני פישינג. |
| הגדרת אורך הסשן לשירותיGoogle Cloud | טוקנים של OAuth שקיימים באופן קבוע בתחנות עבודה של מפתחים עלולים להוות סיכון אבטחה אם הם נחשפים. מומלץ להגדיר מדיניות אימות מחדש שתדרוש אימות כל 16 שעות באמצעות מפתח אבטחה. |
| הגדרת אורך הסשן לשירותי Google | (לקוחות Google Workspace בלבד)
אם יש לכם סשנים קבועים באינטרנט בשירותים אחרים של Google, יכול להיות שזה יוביל לסיכון אבטחה. מומלץ לאכוף משך גלישה מקסימלי באינטרנט ולהתאים אותו לאמצעי הבקרה של משך הגלישה אצל ספק ה-SSO. |
| שיתוף נתונים מ-Cloud Identity עם שירותי Google Cloud | יומני ביקורת של פעילות אדמין מ-Google Workspace או מ-Cloud Identity בדרך כלל מנוהלים ומוצגים במסוף Admin, בנפרד מהיומנים בסביבת Google Cloud . היומנים האלה מכילים מידע שרלוונטי לסביבת Google Cloud העבודה שלכם, כמו אירועים של התחברות משתמשים. מומלץ לשתף את יומני הביקורת של Cloud Identity עם סביבתGoogle Cloud כדי לנהל באופן מרכזי את היומנים מכל המקורות. |
| הגדרת אימות אחרי כניסה יחידה (SSO) | התוכנית מניחה שהגדרתם כניסה יחידה (SSO) עם ספק הזהויות החיצוני שלכם. מומלץ להפעיל שכבת בקרה נוספת על סמך ניתוח הסיכון של הכניסה לחשבון Google. אחרי שמחילים את ההגדרה הזו, יכול להיות שיוצגו למשתמשים אתגרי אימות זהות נוספים לכניסה לחשבון שמבוססים על רמת הסיכון, אם Google תסווג את הכניסה של המשתמש כחשודה. |
| פתרון בעיות בחשבונות משתמשים לצרכן | משתמשים עם כתובת אימייל תקינה בדומיין שלכם אבל בלי חשבון Google יכולים להירשם לחשבונות פרטיים לא מנוהלים. יכול להיות שהחשבונות האלה מכילים נתונים ארגוניים, אבל הם לא נשלטים על ידי תהליכי ניהול מחזור החיים של החשבון. מומלץ לנקוט פעולות כדי לוודא שכל חשבונות המשתמשים הם חשבונות מנוהלים. |
| השבתה של שחזור החשבון בחשבונות סופר-אדמין | אפשרות השחזור העצמי של חשבון סופר-אדמין מושבתת כברירת מחדל לכל הלקוחות החדשים (יכול להיות שההגדרה הזו מופעלת אצל לקוחות קיימים). השבתת ההגדרה הזו עוזרת לצמצם את הסיכון שטלפון שנפרץ, אימייל שנפרץ או מתקפת הנדסה חברתית יאפשרו לתוקף לקבל הרשאות סופר-אדמין בסביבה שלכם. כדאי לתכנן תהליך פנימי שבו סופר-אדמין יכול לפנות לסופר-אדמין אחר בארגון אם הוא איבד את הגישה לחשבון שלו, ולוודא שכל הסופר-אדמינים מכירים את התהליך של שחזור בעזרת תמיכה. |
| אכיפה ומעקב אחרי עמידה בדרישות לגבי סיסמאות של המשתמשים | ברוב המקרים, הסיסמאות של המשתמשים מנוהלות דרך ספק הזהויות החיצוני, אבל חשבונות סופר-אדמין עוקפים את הכניסה היחידה (SSO) וחייבים להשתמש בסיסמה כדי להיכנס ל-Cloud Identity. משביתים את האפשרות לשימוש חוזר בסיסמאות ועוקבים אחרי חוזק הסיסמאות של כל המשתמשים שמשתמשים בסיסמה כדי להיכנס ל-Cloud Identity, במיוחד חשבונות סופר-אדמין. |
| הגדרת מדיניות לשימוש בקבוצות בכל הארגון | כברירת מחדל, אפשר להוסיף חשבונות של משתמשים חיצוניים לקבוצות ב-Cloud Identity. מומלץ להגדיר את הגדרות השיתוף כך שבעלי הקבוצות לא יוכלו להוסיף חברים חיצוניים. ההגבלה הזו לא חלה על חשבון הסופר-אדמין או על אדמינים מורשים אחרים עם הרשאות אדמין בקבוצות. מכיוון שהאיחוד מספק הזהויות שלכם פועל עם הרשאות אדמין, הגדרות השיתוף של הקבוצה לא חלות על הסנכרון הזה של הקבוצה. מומלץ לבדוק את אמצעי הבקרה בספק הזהויות ובמנגנון הסנכרון כדי לוודא שמשתמשים שלא שייכים לדומיין לא יתווספו לקבוצות, או להחיל הגבלות על קבוצות. |
המאמרים הבאים
- מידע נוסף על המבנה הארגוני (המאמר הבא בסדרה).