שיטות מומלצות לשימוש באיחוד שירותי אימות הזהות של עומסי עבודה

איחוד שירותי אימות הזהות של עומסי עבודה מאפשר לאפליקציות שפועלות מחוץ ל- Cloud de Confiance by S3NSלהתחזות לחשבון שירות באמצעות פרטי כניסה מספק זהויות חיצוני.

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

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

• זיוף: יכול להיות שגורם זדוני ינסה לזייף זהות של משתמש אחר כדי לקבל גישה לא מורשית למשאבים ב- Cloud de Confiance .
• הסלמת הרשאות (privilege escalation):גורם זדוני יכול לנצל לרעה את איחוד שירותי אימות הזהות של עומסי עבודה כדי לקבל גישה למשאבים שלא הייתה לו אפשרות לקבל אליהם גישה בדרך אחרת.
• מניעת הכחשה: יכול להיות שגורם זדוני ישתמש בפרטי כניסה חיצוניים שמקשים על מעקב אחריו, וכך יסתיר את הזהות ואת הפעולות שלו.
• הגדרות זדוניות של פרטי כניסה: גורם זדוני יכול לספק הגדרה זדונית של פרטי כניסה כדי לעקוף את אמצעי ההגנה שלכם.

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

מתי כדאי להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה

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

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

• ב-AWS, אפליקציות שפרוסות ב-EC2 יכולות להשתמש בפרופילים של מכונות כדי למלא תפקיד ולקבל פרטי כניסה זמניים.
• ב-Azure, אפליקציות יכולות להשתמש בזהויות מנוהלות כדי לקבל אסימוני גישה.
• בפעולות של GitHub, תהליכי עבודה יכולים לקבל אסימונים מזהים שמשקפים את הזהות של משימת הפריסה.

אם פרטי הכניסה ברקע הם אסימוני OpenID Connect‏ (OIDC), טענות נכוֹנוּת (assertions) של SAML או פרטי כניסה ב-AWS, אפשר להגדיר את איחוד שירותי אימות הזהות של עומסי עבודה כדי לאפשר לאפליקציות להמיר את פרטי הכניסה האלה באסימוני גישה לטווח קצר של Google. אם פרטי הכניסה ברקע יהיו בפורמט שונה, יכול להיות שתוכלו להמיר אותם באסימון OIDC או בטענת נכונות (assertion) של SAML, ולאחר מכן להשתמש בהם בשביל איחוד שירותי אימות הזהויות של עומסי עבודה.

כדאי להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה בכל פעם שאפליקציה צריכה לגשת ל-Cloud de Confiance ויש לה גישה לפרטי הכניסה ברקע.

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

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

לדוגמה, אם האפליקציה תפעל בסביבת Active Directory, יכול להיות שתהיה לה גישה לפרטי הכניסה של Kerberos. אם יש בסביבה שלך ספק זהויות כמו Active Directory Federation Services‏(AD FS), שתומך באימות משולב של Windows, אפשר להשתמש בפרטי הכניסה האלה של Kerberos כדי לבצע את האימות לספק הזהויות ולקבל אסימון גישה ל-OAuth שמשתמש בפורמט JWT. באמצעות אסימון הגישה הזה ואיחוד שירותי אימות הזהות של עומסי עבודה, אפשר לאפשר לאפליקציה להמיר אסימון שני כדי לקבל פרטי כניסה לטווח קצר של Google.

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

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

אפליקציות שמשתלבות עם ספק זהויות של OpenID או SAML משתמשות בדרך כלל בסוד לקוח (או בצורה אחרת של סוד) כדי לבצע אימות לספק הזהויות. בדרך כלל הסוד הזה מאוחסן כחלק מהתצורה של האפליקציה. כדי לאפשר לאפליקציה כזו גישה Cloud de Confiance, צריך לבחור באחת מהאפשרויות הבאות:

1. ליצור מפתח לחשבון שירות ולאחסן אותו לצד הסוד האחר.
2. להשתמש באסימונים שהנפיק ספק הזהויות הנוכחי ולהמיר אותם בפרטי הכניסה ל-Google באמצעות איחוד שירותי אימות הזהות של עומסי עבודה.

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

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

נקודות קצה אזוריות של Security Token Service לא נתמכות ב- Cloud de Confiance by S3NS.

משתמשים ב-https://sts.s3nsapis.fr בכתובת ה-URL כדי לגשת אל Security Token Service.

הגנה מפני איומי זיופים

בניגוד לספריית משתמשים כמו Cloud Identity, מאגר זהויות של כוח עבודה לא מכיל זהויות או חשבונות משתמשים. במקום זאת, מאגר זהויות של כוח עבודה מייצג תצוגה (View) שמראה זהויות מספקי זהויות חיצוניים, כדי שתוכלו להשתמש בהן כחשבונות משתמשים ב-IAM.

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

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

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

איחוד שירותי אימות הזהות של עומסי עבודה לא מתחזק ספרייה של חשבונות משתמשים, אלא מיישם זהויות מבוססות הצהרות. כתוצאה מכך, כשספק זהויות (IdP) מנפיק שני אסימונים וההצהרות שלהם ממופות לאותו ערך google.subject, המערכת מניחה שהאסימונים האלה מזהים את אותו משתמש. כדי לגלות איזה IdP הנפיק אסימון, איחוד זהויות של עומסי עבודה בודק ומאמת את כתובת ה-URL של המנפיק של האסימון.

ספקים מסוימים, כמו GitHub ו-Terraform Cloud, משתמשים בכתובת URL אחת של מנפיק בכל הדיירים שלהם. בספקי הזהויות האלה, כתובת ה-URL של הגורם המנפיק מזהה את כל GitHub או Terraform Cloud, ולא ארגון ספציפי ב-GitHub או ב-Terraform Cloud.

כשמשתמשים בספקי הזהויות האלה, לא מספיק לאפשר לאיחוד זהויות של עומסי עבודה לבדוק את כתובת ה-URL של המוסד המנפיק של אסימון כדי לוודא שהוא מגיע ממקור מהימן ושאפשר לסמוך על הטענות שלו. מומלץ להגדיר תנאי למאפיין של איחוד שירותי אימות הזהות של עומסי עבודה כדי לבדוק שהאסימון הגיע מדייר מהימן, או במקרה של GitHub או Terraform Cloud, מארגון מהימן.

מידע נוסף על הגדרת תנאי מאפיין

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

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

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

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

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

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

אפשר למנוע יצירת ספקים חדשים של מאגר זהויות של עומסי עבודה באמצעות אילוץ של המדיניות הארגונית: constraints/iam.workloadIdentityPoolProviders עם כלל שמוגדר לדחיית הכול.

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

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

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

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

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

נמנעים מאיחוד כפול עם אותו ספק זהויות

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

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

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

מגנים על נקודת הקצה במטא-נתונים של OIDC של ספק הזהויות

לאחר איחוד עם ספק OpenID Connect, איחוד שירותי אימות הזהות של עומסי עבודה מוריד מדי פעם את המטא-נתונים של OIDC מספק הזהויות. איחוד שירותי אימות הזהות של עומסי עבודה מאמת אסימונים באמצעות מטא-נתונים של ה-IdP ובאמצעות JSON Web Key Set‏(JWKS).

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

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

כדי להגן מפני החלפת JWKS, צריך לוודא שה-IdP שלך פרוס באופן שמגן עליו מפני התקפות MITM.

משתמשים בכתובת ה-URL של ספק מאגר הזהויות של כוח העבודה בתור הקהל

לאחר איחוד עם ספק OpenID Connect, איחוד שירותי אימות הזהות של עומסי עבודה מאמת שקהל האסימונים (מקודד בהצהרה aud) תואם להגדרת הקהל המורשה של הספק. באופן דומה, לאחר איחוד עם ספק SAML, איחוד שירותי אימות הזהות של עומסי עבודה בודק שטענת הנכוֹנוּת (assertion) של SAML מציינת הגבלת קהל שתואמת לקהל הצפוי.

כברירת מחדל, איחוד שירותי אימות הזהות של עומסי עבודה מצפה שהקהל יתאים לכתובת ה-URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID שמזהה באופן ייחודי את ספק מאגר הזהויות של עומס העבודה. דרישה לאסימונים ולטענות נכונות (assertions) כדי להשתמש בכתובת ה-URL הזו בתור קהל היעד מפחיתה את הסיכון להתקפת הסגן המבולבל (confused deputy). במתקפה כזאת, גורם זדוני מציג אסימון או טענת נכונות (assertion) של SAML לאיחוד שירותי אימות הזהות של עומסי עבודה, שלא היה מיועד לשימוש שלו אלא לשימוש של ממשק API אחר.

דרישה שהאסימון או שטענת הנכונות (assertion) יכילו את כתובת ה-URL של ספק מאגר הזהויות ביעד של כוח העבודה תבטיח שהלקוחות יוכלו להשתמש רק באסימונים <x0A>ובטענות נכונות שהונפקו במיוחד לאיחוד שירותי אימות הזהות של עומסי עבודה.

משתמשים במאפיינים לא משתנים במיפויי מאפיינים

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

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

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

משתמשים במאפיינים שלא ניתנים לשימוש חוזר במיפויי מאפיינים

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

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

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

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

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

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

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

כדי לשנות את מיפויי המאפיינים צריך את ההרשאה iam.googleapis.com/workloadIdentityPoolProviders.update. התפקידים שיש להם את ההרשאה הזו כוללים:

• בעלים (roles/owner)
• אדמין של מאגר זהויות של כוח עבודה ב-IAM (roles/iam.workloadIdentityPoolAdmin)

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

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

לא מסתמכים על מאפיינים לא יציבים או לא מהימנים

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

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

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

אימות של תצורות פרטי כניסה ממקור חיצוני לפני השימוש בהן לאימות ל-Google APIs

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

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

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

הגנה מפני איומי מניעת הכחשה

בכל פעם שמבחינים בפעילות חשודה שמשפיעה על אחד המשאבים ב-Cloud de Confiance, יומני הביקורת של Cloud הם מקור מידע חשוב כדי לברר מתי הפעילות התרחשה ואילו משתמשים היו מעורבים.

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

בקטע הזה מתוארות שיטות מומלצות שיכולות לעזור לשמר נתיב ביקורת לאיומי מניעת הכחשה.

מפעילים יומני גישה לנתונים של ממשקי API ב-IAM

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

שירותים מסוימים לא כוללים פרטי התחזות ביומני הביקורת של Cloud. כדי לשמור על נתיב ביקורת לאיומי מניעת הכחשה, צריך גם לתעד את כל אירועי ההתחזות. לשם כך, צריך להפעיל את יומני הגישה לנתונים של Security Token Service API ושל Identity and Access Management API. כדאי להפעיל את היומנים האלה לכל הפרויקטים ב-Cloud שמכילים מאגרי זהויות של כוח עבודה או חשבונות שירות שמשמשים לאיחוד שירותי אימות הזהויות של עומסי עבודה.

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

משתמשים במיפוי ייחודי של נושא

מיפוי המאפיינים של ספק מאגר הזהויות של כוח עבודה ב-google.subject קובע אתהנושא העיקרי שבו משתמשים בקטע serviceAccountDelegationInfo ברשומות של יומני הביקורת ב-Cloud.

אם מזהים פעילות חשודה וצריך לברר איזו זהות חיצונית מעורבת, צריך לחפש זהות חיצונית לפי הערך המתאים שלה ב-google.subject.

באופן דומה, כשזהות חיצונית נחשפה וצריך לבדוק אם הזהות הזו שימשה לגישה למשאבים של Cloud de Confiance , חייבים למצוא רשומות של יומני ביקורת ב-Cloud שמתאימות לזהות החיצונית.

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

• זהות חיצונית ממופה לערך אחד בלבד של google.subject.
• ערך של google.subject ממופה לזהות חיצונית אחת בלבד.
• אפשר לחפש זהות חיצונית לפי הערך שלה ב-google.subject.

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

הגנה מפני איומים של הסלמת הרשאות (privilege escalation)

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

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

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

בקטעים הבאים מתוארות שיטות מומלצות שיכולות לעזור בהגנה מפני איומי הסלמת הרשאות (privilege escalation).

משתמשים בחשבונות שירות שנמצאים באותו הפרויקט של המשאבים שצריך גישה אליהם

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

1. מקבלים פרטי כניסה מספק הזהויות המהימן.
2. המרת פרטי הכניסה באסימון מהממשק Security Token Service.
3. שימוש באסימון מהממשק Service Token Service כדי להתחזות לחשבון שירות ולקבל אסימון גישה לטווח קצר של Google.

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

משתמשים בחשבון שירות ייעודי לכל אפליקציה

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

נמנעים מהענקת גישה לכל החברים במאגר

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

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

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

אם תקצו את התפקיד roles/iam.workloadIdentityUser רק לזהויות חיצוניות ספציפיות, תוכלו לוודא שאתם מגדילים בבטחה את מאגר הזהויות של כוח עבודה, בלי להעניק בטעות גישה לא נחוצה להתחזות של זהויות חיצוניות.

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

• למידע נוסף על שיטות מומלצות לשימוש בחשבונות שירות.
• לקריאה נוספת על שיטות מומלצות לניהול מפתחות לחשבונות שירות.