בקטע הזה נסביר איך להשתמש ב-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, או לכל המשתמשים באינטרנט. כדי שלחשבון משתמש תהיה אפשרות ליצור אינטראקציה עם Google Cloud שירותים, צריך להקצות לו תפקידים ב ניהול זהויות והרשאות גישה (IAM).
כדי לנהל תפקידי 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 |
כשאתם בונים עומסי עבודה משלכם על בסיס התשתית, אתם יוצרים קבוצות נוספות ומקצים תפקידי 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. מומלץ להגדיר את הגדרות השיתוף כך שבעלי קבוצות לא יוכלו להוסיף משתמשים מחוץ לארגון. ההגבלה הזו לא חלה על חשבון הסופר-אדמין או על אדמינים מורשים אחרים עם הרשאות אדמין בקבוצות. מכיוון שהפדרציה מספק הזהויות שלכם פועלת עם הרשאות אדמין, הגדרות השיתוף של הקבוצה לא חלות על סנכרון הקבוצה הזה. מומלץ לבדוק את אמצעי הבקרה בספק הזהויות ובמנגנון הסנכרון כדי לוודא שמשתמשים שלא שייכים לדומיין לא נוספים לקבוצות, או להחיל הגבלות על קבוצות. |
המאמרים הבאים
- מידע נוסף על מבנה הארגון (המאמר הבא בסדרה).