אם אתם מציעים מוצר או מפעילים שירות שמאפשר ללקוחות לנתח נתונים או משאבים ולנהל אותם, ייתכן שהלקוחות ירצו לגשת לנתונים או למשאבים אחרים בסביבת Google Cloud . דוגמאות למוצרים ושירותים כאלה:
- מוצרים לניתוח נתונים: יכול להיות שהלקוחות שלכם ירצו להשתמש במוצרים כאלה כדי לנתח את הנתונים שלהם ב-BigQuery.
- מוצרים ושירותים של CI/CD: יכול להיות שהלקוחות שלכם ישתמשו בשירותים כאלה כדי לפרוס תשתית ואפליקציות בפרויקטים שלהם ב- Google Cloud .
- אוטומציה רובוטית של תהליכים (RPA): יכול להיות שהלקוחות שלכם ישתמשו ב-RPA בתהליכי עבודה כמו יצירת פרויקטים, ניהול הרשאות גישה או אוטומציה של משימות אדמיניסטרטיביות ב- Google Cloud.
כדי לבצע אימות של מוצרים בארגון או מוצרי תוכנה כשירות (SaaS) ב- Google Cloud, הלקוחות נהגו להסתמך באופן שגרתי על מפתחות של חשבונות שירות, אבל המפתחות האלה יכולים להיות מאתגרים לניהול ואחסון בצורה מאובטחת.
כספקים של מוצר בארגון או של מוצר SaaS, תוכלו לעזור ללקוחות להגן על המשאבים שלהם ב- Google Cloud ולאפשר גישה אליהם באמצעות איחוד שירותי אימות הזהות של עומסי עבודה. Google Cloud דוגמאות לשירותים שכבר מאפשרים ללקוחות להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה: Terraform Cloud, GitHub ו-GitLab.
במאמר הזה נסביר איך להרחיב את המוצר כדי שיתמוך באיחוד שירותי אימות הזהות של עומסי עבודה, ונתאר את השיטות המומלצות שאתם יכולים לבצע. המאמר הזה מתבסס על ההנחה שאתם מכירים את איחוד שירותי אימות הזהויות של עומסי עבודה ואת OpenID Connect.
ארכיטקטורה
המטרה של איחוד שירותי אימות הזהות של עומסי עבודה היא להסיר את הצורך במפתח של חשבון שירות. לשם כך, הוא מאפשר ללקוחות לאחד בין המוצר או השירות שלכם לבין סביבתGoogle Cloud שלהם. כך הלקוחות יוכלו לגשת למשאבים שלהם ב-Google Cloud באמצעות זהות שהוצהרה על ידי המוצר או השירות שלכם.
כדי לאפשר ללקוחות להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה, המוצר או השירות שלכם צריכים להטמיע קבוצת משנה של OpenID Connect. בפרט, אתם צריכים לאפשר לעומסי עבודה לקבל אסימון מזהה שעומד בקריטריונים הבאים:
- האסימון מזהה את עומס העבודה במוצר או בפלטפורמה שלכם.
- האסימון מזהה את המכונה, הדייר (tenant) או ההתקנה של המוצר או הפלטפורמה.
- האסימון מכיל חתימה קריפטוגרפית שאיחוד שירותי אימות הזהות של עומסי עבודה יכול להשתמש בה כדי לאמת את האותנטיות של האסימון.
דרישות
כדי לתמוך באיחוד שירותי אימות הזהות של עומסי עבודה, אתם צריכים לוודא שהמוצר או השירות שלכם עומדים בדרישות הבאות:
לעומסי עבודה יש גישה לאסימון מזהה תקף.
בכל שלב במחזור החיים של עומס עבודה, צריכה להיות לו גישה לאסימון מזהה שמצהיר על הזהות שלו ועומד בדרישות שהוגדרו על ידי OpenID Connect 1.0.
לאסימונים מזהים יש אורך חיים מוגבל, ולכן אתם צריכים לוודא שחיי האסימון המזהה נמשכים אחרי חיי עומס העבודה שלו, או שעומסי העבודה יכולים לקבל אסימונים מזהים חדשים מדי פעם.
האסימונים המזהים יודעים לזהות באופן ייחודי את עומס העבודה.
האסימון המזהה צריך להכיל לפחות הצהרה אחת שמזהה באופן ייחודי את עומס העבודה. מזהה עומס העבודה צריך להיות בלתי ניתן לשינוי.
למוצרים או לשירותים שתומכים בדיירים מרובים, האסימון צריך גם לכלול לפחות הצהרה אחת שמזהה באופן ייחודי את הדייר (tenant). גם מזהה הדייר צריך להיות בלתי ניתן לשינוי.
האסימונים המזהים חתומים, אבל הם לא מוצפנים.
המטא-נתונים של ספק OpenID נגישים לציבור ואפשר לאתר אותם דרך האסימונים המזהים.
אתם צריכים לספק מסמך הגדרות של ספק OpenID בנקודת קצה (endpoint) נגישה לציבור, שאפשר לאתר באמצעות פרוטוקול האיתור של מנפיק ה-OpenID. לדוגמה, אם האסימונים המזהים מכילים הצהרת
issעם הערךhttps://service.example.com/v1/, אתם צריכים לספק מסמך הגדרות של ספק OpenID ב-https://service.example.com/v1/.well-known/openid-configuration, ונקודת הקצה צריכה להיות נגישה לציבור באינטרנט מכל כתובת IP.מפתחות החתימה הם נגישים לציבור ואפשר לאתר אותם במטא-נתונים של ספק ה-OpenID.
אתם צריכים לספק מסמך JSON Web Key Set (JWKS) בנקודת קצה נגישה לציבור, שאפשר לאתר בשדה
jwks_uriבמטא-נתונים של ספק ה-OpenID.
שיטות מומלצות
כשמרחיבים את המוצר או השירות כדי שיתמכו באיחוד שירותי אימות הזהויות של עומסי עבודה, כדאי ליישם את השיטות המומלצות הבאות.
שיטות מומלצות:
הבחנה בין אסימוני זהות לאסימוני גישה.חשיפה של אסימונים מזהים באופן שתואם לספריות הלקוח.
שימוש בכתובות URL של מנפיק ספציפי לדייר.
מתן הרשאה למשתמשים לציין את הקהל של האסימון המזהה.
שימוש במזהים שלא ניתנים לשינוי ולשימוש חוזר בהצהרות של אסימון מזהה.
הוספת מידע על ההקשר באסימונים מזהים.
הגבלת משך החיים של אסימון מזהה ל-30 עד 60 דקות.
הבחנה בין אסימוני זהות לאסימוני גישה
בהקשר של איחוד שירותי אימות הזהות של עומסי עבודה, המטרה של אסימון מזהה היא להצהיר על הזהות של עומס העבודה: האסימון צריך להכיל מספיק מידע כדי שאיחוד שירותי אימות הזהות של עומסי עבודה יוכל לזהות את עומס העבודה ולהבחין בינו לעומסי עבודה אחרים.
בניגוד לאסימונים מזהים, השימוש באסימוני גישה בדרך כלל נועד למטרה אחרת: הם משמשים לקבלת החלטות לגבי גישה, ועשויים להכיל מידע על ההרשאות שיש לעומס העבודה או על ממשקי ה-API שאליהם עומס העבודה מורשה לגשת.
אם המוצר או השירות שלכם משתמשים עכשיו באסימוני גישה למטרות כמו מתן הרשאה לעומסי עבודה לשלוח קריאה ל-API של המוצר, יכול להיות שאסימוני הגישה האלה לא מתאימים לאיחוד שירותי אימות הזהות של עומסי עבודה. במקום להשתמש באסימוני גישה כאסימונים מזהים, כדאי להכיר סוג שני של אסימונים שעונה להגדרה של אסימון מזהה, ולאפשר לעומסי עבודה להשתמש באסימון המזהה לאיחוד שירותי אימות הזהות של עומסי עבודה.
חשיפה של אסימונים מזהים באופן שתואם לספריות הלקוח
ספריות הלקוח של Google Cloud יכולות לקבל באופן אוטומטי אסימונים מזהים ממספר מקורות, כולל מהמקורות הבאים:
- נקודת קצה (endpoint) בפרוטוקול HTTP (פרטי כניסה שהתקבלו מכתובת URL)
- קובץ מקומי (פרטי כניסה שהתקבלו מקובץ)
כדי לקבל אסימונים מזהים ממקורות אחרים, ייתכן שהלקוחות שלכם יצטרכו לשנות את הקוד שלהם או לפרוס ספריות או כלים נוספים. אם תחשפו את האסימונים המזהים באופן שתואם לספריות הלקוח, תוכלו למנוע את המורכבות הנוספת הזו ולהקל על הלקוחות להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה.
שימוש בכתובות URL של מנפיק ספציפי לדייר
ההצהרות המוטמעות באסימון מזהה של עומס עבודה עשויות להיות ייחודיות במכונה מסוימת של המוצר או השירות שלכם, אבל ייתכן שהן לא יהיו ייחודיות בין מכונות שונות של המוצר או השירות. לדוגמה, נניח ששני לקוחות שלכם משתמשים במוצר או בשירות שלכם כדי לפרוס עומס עבודה, ובטעות מוקצה לעומסי העבודה האלה אותו שם ואותו מזהה.
כדי לפצות על חוסר הייחודיות, איחוד שירותי אימות הזהות של עומסי עבודה מבצע אימות כתובת ה-URL של המנפיק (iss) של האסימונים המזהים, ומאפשר אסימונים ממנפיק אחד בלבד לכל מאגר זהויות של עומסי עבודה.
אם המוצר או השירות שלכם תומכים בדיירים מרובים, ייתכן שכמה מהלקוחות חולקים את אותה מכונה של המוצר או השירות, והאסימונים המזהים של עומסי העבודה שלהם עשויים להשתמש באותה כתובת URL של מנפיק. שימוש באותה כתובת URL של מנפיק למספר דיירים עלול לחשוף את הלקוחות שלכם למתקפות זיוף: לדוגמה, גורם זדוני עלול ליצור עומס עבודה בדייר שלו, להקצות לו את אותו מזהה או את אותו שם של עומס עבודה בדייר של הקורבן, ולהשתמש באסימון המזהה של עומס העבודה כדי לזייף את זהות עומס העבודה של הקורבן.
כדי להגן על הלקוחות מפני מתקפות זיוף, אתם צריכים להימנע משימוש באותן כתובות URL של מנפיק למספר דיירים, ולהטמיע מזהה דייר ייחודי בכתובת ה-URL של המנפיק, לדוגמה https://saas.example.com/tenant-123/.
מתן הרשאה למשתמשים לציין את הקהל של האסימון המזהה
יכול להיות שחלק מעומסי העבודה של הלקוחות צריכים לגשת גם ל- Google Cloudוגם לשירותים אחרים של צד שלישי. כשלקוחות מחליטים לאחד את המוצר או השירות שלכם עם כמה גורמים מסתמכים, הם עלולים למצוא את עצמם במצב שבו אסימון מזהה של עומס עבודה משמש בטעות או בזדון לגורם המסתמך הלא נכון: לדוגמה, גורם זדוני עלול לגרום לעומס עבודה לחשוף אסימון מזהה שהיה מיועד לשירות של צד שלישי, ואז להשתמש באסימון המזהה הזה לאיחוד שירותי אימות הזהות של עומסי עבודה.
כדי למנוע מצב שבו הלקוחות שלכם יהיו קורבנות של מתקפות הסגן המבולבל , כדאי להימנע משימוש בקהל סטטי (הצהרת aud) באסימונים מזהים. במקום זאת,
כדאי לאפשר לעומסי העבודה לציין קהל כשהם מקבלים אסימון מזהה.
אפשר גם להחזיק רשימה של קהלים מורשים שעומסי העבודה יכולים לבקש.
כברירת מחדל, איחוד שירותי אימות הזהויות של עומסי עבודה מוגדר כך שהקהל של אסימון מזהה אמור להתאים לכתובת ה-URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID.
חשוב לוודא שעומסי העבודה יכולים להשתמש בכתובת URL כקהל של אסימונים מזהים, ושאורך כתובת ה-URL של הקהל הוא פחות מ-180 תווים.
שימוש במזהים שלא ניתנים לשינוי ולשימוש חוזר בהצהרות של אסימון מזהה
כשלקוחות רוצים להעניק לאחד מעומסי העבודה שלהם גישה למשאבי Google Cloud, הם צריכים ליצור קישור IAM שמפנה לזהות של עומס העבודה לפי נושא, קבוצה או מאפיין מותאם אישית. הנושא, הקבוצה והמאפיינים המותאמים אישית של הזהות של עומס העבודה נגזרים מההצהרות באסימון המזהה של עומס העבודה.
אם לקוח יוצר קישור IAM שמפנה להצהרה שניתנת לשינוי, עומס העבודה שלו עלול לאבד את הגישה בטעות כאשר ערך ההצהרה משתנה. לדוגמה, לקוח יכול ליצור קישור IAM שמפנה לשם של עומס העבודה. אם בהמשך הלקוח ישנה את שם עומס העבודה, ייתכן שקישור ה-IAM לא יעבוד יותר.
בתרחיש גרוע יותר, גורמים זדוניים עלולים לנסות לקבל גישה בלתי מורשית למשאבים אחרים על ידי שינוי מכוון של שמות עומסי העבודה או של סביבת עומס העבודה, כדי לזייף את הזהות של עומס עבודה אחר.
כדי לעזור ללקוחות למנוע בעיות כאלה של זיוף, אתם צריכים לוודא שהאסימונים המזהים מכילים מזהים שלא ניתנים לשינוי ושלא ניתנים לשימוש חוזר.
הוספת מידע על ההקשר באסימונים מזהים
במקום להעניק לעומסי עבודה גישה לא מותנית למשאבים, ייתכן שהלקוחות ירצו להגביל את הגישה כדי שעומס עבודה יוכל לקבל פרטי כניסה של Google רק כשהוא עומד בקריטריונים נוספים. Google Cloud
כדי לאפשר ללקוחות להגדיר הגבלות כאלה, אתם צריכים להוסיף באסימון המזהה הצהרות שמכילות מידע על ההקשר. דוגמאות למידע על הקשר:
- מידע על המשתמש שהוא הבעלים של עומס העבודה או שהתחיל את עומס העבודה
- הסיבה והדרך שבה עומס העבודה התחיל
- הבקשה שעומס העבודה מטפל בה כרגע
הלקוחות יכולים להשתמש בהצהרות האלה כדי להגדיר תנאים של מאפיינים, או במזהי החשבון הראשי.
הגבלת משך החיים של אסימון מזהה ל-60 דקות
לאסימונים מזהים יש משך חיים מוגבל, שנקבע על ידי ההצהרה exp. כאשר עומס העבודה משתמש באסימון מזהה כדי להחליף אסימונים, איחוד שירותי אימות הזהות של עומסי עבודה מאמת את ההצהרה exp של האסימון המזהה, ומנפיק אסימון STS שנשאר בתוקף לכל משך החיים של אסימון הקלט, אבל לא יותר משעה.
שימוש באסימונים מזהים בעלי תוקף של יותר משעה לא משפיע על איחוד שירותי אימות הזהות של עומסי עבודה, אבל עלול להגביר את הסיכונים במקרה של דליפת אסימון מזהה בטעות. שימוש במשך חיים קצר משמעותית משעה יכול לצמצם את הסיכונים האלה, אבל עשוי לגרום להחלפות תכופות של אסימונים ולפגיעה בביצועים.
המאמרים הבאים
- מידע נוסף על איחוד זהויות של עומסי עבודה
- שיטות מומלצות לשימוש באיחוד שירותי אימות הזהות של עומסי עבודה