בקטע הזה נסביר איך להשתמש ב-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. | מנהל מערכת בעל הרשאת עריכה להגדרות מרכז האבטחה | ארגון |
grp-gcp-secrets-admin@example.com |
הצוות שאחראי לניהול, לאחסון ולביקורת של פרטי הכניסה וסודות אחרים שמשמשים את האפליקציות. | Secret Manager Admin | פרויקטים של סודות |
grp-gcp-kms-admin@example.com |
הצוות שאחראי על אכיפת ניהול מפתחות ההצפנה כדי לעמוד בדרישות התאימות. | Cloud KMS Viewer | kms projects |
כשאתם יוצרים עומסי עבודה משלכם על בסיס התשתית, אתם יוצרים קבוצות נוספות ומקצים תפקידי 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 בתוכנית הבסיסית. מומלץ להחיל כל אחד מאמצעי הבקרה האלה לשיפור האבטחה בשלב מוקדם בתהליך בניית התשתית.
| שליטה | תיאור |
|---|---|
| פריסה של אימות דו-שלבי | יכול להיות שחשבונות משתמשים ייפרצו באמצעות פישינג, הנדסה חברתית, ריסוס סיסמאות או איומים שונים אחרים. אימות דו-שלבי עוזר לצמצם את האיומים האלה. מומלץ לאכוף אימות דו-שלבי בכל חשבונות המשתמשים בארגון באמצעות מנגנון עמיד בפני פישינג, כמו מפתחות אבטחה 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. מומלץ להגדיר את הגדרות השיתוף כך שבעלי קבוצות לא יוכלו להוסיף משתמשים מחוץ לארגון. שימו לב שההגבלה הזו לא חלה על חשבון הסופר-אדמין או על אדמינים מורשים אחרים עם הרשאות אדמין בקבוצות. מכיוון שהפדרציה מספק הזהויות שלכם פועלת עם הרשאות אדמין, הגדרות השיתוף של הקבוצה לא חלות על סנכרון הקבוצה הזה. מומלץ לבדוק את אמצעי הבקרה בספק הזהויות ובמנגנון הסנכרון כדי לוודא שחברים שלא שייכים לדומיין לא מתווספים לקבוצות, או להחיל הגבלות על קבוצות. |
המאמרים הבאים
- מידע נוסף על המבנה הארגוני (המאמר הבא בסדרה).