Google Cloud מנפיקה כמה סוגים של אסימונים, ששונים זה מזה במטרה שלהם ובצדדים שאיתם הם מוחלפים.
בטבלה הבאה מופיע סקירה כללית של קטגוריות האסימונים העיקריות, שבתוכן יש סוגים שונים של אסימונים.
| קטגוריית הטוקן | נתיב התקשורת | מטרה |
|---|---|---|
| אסימוני גישה | שרת הרשאות ⭢ לקוח ⭢ Google API | מאפשר ללקוחות לקרוא ל- Google Cloud API. |
| אסימונים שמעניקים אסימונים | שרת הרשאות ⭤ לקוח | מאפשר ללקוחות לקבל טוקנים חדשים או שונים, אולי במועד מאוחר יותר. |
| אסימוני זהות | שרת הרשאות ⭢ לקוח | השיטה מאפשרת ללקוחות לזהות את המשתמש שאיתו הם מקיימים אינטראקציה. |
אסימוני גישה ואסימוני זהות הם אסימונים למוכ"ז. אסימוני למוכ"ז הם סוג כללי של אסימון שמעניק גישה לגורם שמחזיק באסימון.
השימוש באסימונים למוכ"ז לאימות מסתמך על האבטחה של פרוטוקול מוצפן כמו HTTPS. אם גורם זדוני מיירט אסימון למוכ"ז, הוא יוכל להשתמש בו כדי לקבל גישה.
אם אסימונים למוכ"ז לא מספקים אבטחה מספקת בתרחיש השימוש הפרטני שלכם, אתם יכולים להקטין את הסיכון לגניבת אסימונים באמצעות בקרת גישה מבוססת-הקשר, הגבלת משך החיים של אסימוני הגישה או שימוש בפתרון מסוג mutual Transport Layer Security (mTLS), כמו Chrome Enterprise Premium.
אסימוני גישה
אסימוני גישה מאפשרים ללקוחות לבצע קריאות מאומתות לממשקי API של Google Cloud .Google Cloud תומך בכמה סוגים שונים של אסימוני גישה, שיש להם את המאפיינים המשותפים הבאים:
הם מאמתים חשבון ראשי, שיכול להיות משתמש או עומס עבודה.
הם מונפקים ללקוח מסוים.
הם קיימים לזמן קצר בלבד, והתוקף שלהם פג אחרי כמה שעות לכל היותר.
הם מוגבלים להיקפי הרשאות, לנקודות קצה או למשאבים מסוימים של OAuth. כלומר, בדרך כלל טוקן גישה לא מעניק גישה לכל המשאבים של המשתמש, אלא רק לקבוצת משנה מסוימת שלהם.
אסימוני הגישה יכולים להיות שונים בדרכים הבאות:
Issuer: הגורם שמנפיק את האסימון.
Principal: סוג החשבון שהאסימון יכול לאמת.
הגבלות: ההגבלות שאפשר להטיל על הטוקן.
בטבלה הבאה מפורטים סוגי האסימונים השונים לגישה:
| סוג הטוקן | מנפיק | חשבונות משתמשים | הגבלות |
|---|---|---|---|
| אסימון גישה של משתמש | שרת ההרשאות של Google |
|
היקף הרשאות OAuth |
| טוקן גישה לחשבון שירות |
|
חשבון שירות | היקף הרשאות OAuth |
| אסימון של הענקת גישה ברמת הדומיין | שרת ההרשאות של Google | משתמש (חשבון מנוהל) | היקף הרשאות OAuth |
| אסימון JWT (JSON Web Token) של חשבון שירות | לקוח | חשבון שירות | היקף הרשאות OAuth או API |
| טוקן גישה מאוחד | Google Cloud שרת הרשאות IAM |
|
היקף הרשאות OAuth |
| אסימון של גבול הגישה לפרטי כניסה | Google Cloud שרת הרשאות IAM |
|
אובייקטים ספציפיים ב-Cloud Storage |
| טוקן של גבול גישה לפרטי כניסה שהונפק על ידי הלקוח | לקוח | חשבון שירות | אובייקטים ספציפיים ב-Cloud Storage |
לסוגים השונים של טוקנים לגישה יש גם מאפייני אבטחה שונים:
- פורמט: חלק מאסימוני הגישה הם אטומים, כלומר הם בפורמט קנייני ואי אפשר לבדוק אותם. אסימונים אחרים מקודדים כאסימון אינטרנט מסוג JSON, שאפשר לפענח אותו באמצעות הלקוח.
- יכולת בדיקה: אפשר לבדוק חלק מהאסימונים האטומים באמצעותGoogle Cloud API, אבל אי אפשר לבדוק אחרים.
כל משך החיים: יש הבדלים בין הטוקנים מבחינת כל משך החיים שלהם והמידה שבה אפשר לשנות אותם.
אפשרות ביטול: אפשר לבטל חלק מהטוקנים. אסימונים אחרים נשארים בתוקף עד לתאריך התפוגה.
בטבלה הבאה מסוכמים ההבדלים בין סוגי טוקני הגישה.
| סוג הטוקן | פורמט | ניתן לבדיקה | כל התאריכים | ניתן לביטול |
|---|---|---|---|---|
| טוקן גישה של משתמש | אטום | כן | שעה אחת | כן |
| טוקן גישה לחשבון שירות | אטום | כן | 5 דקות עד 12 שעות | לא |
| טוקן של הענקת גישה ברמת הדומיין | אטום | כן | שעה אחת | לא |
| אסימון JWT (JSON Web Token) של חשבון שירות | JWT | לא רלוונטי | 5 דקות עד שעה | לא |
| טוקן גישה מאוחד | אטום | לא | אסימוני גישה מאוחדים | לא |
| טוקן של גבול גישה לפרטי כניסה | אטום | לא | מידע נוסף על אסימונים של גבולות גישה לפרטי כניסה | לא |
| טוקן של גבול גישה לפרטי כניסה שהונפק על ידי הלקוח | אטום | לא | לא רלוונטי | לא |
טוקנים של גישת משתמשים
אסימוני גישה של משתמשים מאמתים את המשתמש ומאשרים ללקוח לפעול בשם המשתמש:
הגורם המאומת הוא חשבון משתמש מנוהל או חשבון לשימוש פרטי. הלקוח יכול להיות אפליקציית אינטרנט או אפליקציית נייטיב.
טוקנים של גישת משתמשים הם אטומים. למטרות אבחון, אפשר לבדוק את טוקן הגישה באמצעות הפקודה הבאה, ולהחליף את ACCESS_TOKEN בטוקן גישה תקין:
curl "https://oauth2.googleapis.com/tokeninfo?access_token=ACCESS_TOKEN"
הפלט של הפקודה אמור להיראות כך:
{
"azp": "0000000000.apps.googleusercontent.com",
"aud": "0000000000.apps.googleusercontent.com",
"sub": "00000000000000000000",
"scope": "openid https://www.googleapis.com/auth/userinfo.email",
"exp": "1744687132",
"expires_in": "3568",
"email": "user@example.com",
"email_verified": "true"
}
הפלט כולל את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
aud |
קהל |
לקוח ה-OAuth שאליו משויך הטוקן הזה, שמזוהה באמצעות מזהה הלקוח ב-OAuth. לקוחות OAuth יכולים לקבל טוקנים של גישה ללקוחות OAuth אחרים ששייכים לאותו פרויקט. יכול להיות שהקהל יהיה שונה מהצד המורשה. |
azp |
צד מורשה | לקוח ה-OAuth שביקש את הטוקן, שמזוהה באמצעות מזהה הלקוח ב-OAuth. |
email |
כתובת אימייל ראשית |
כתובת האימייל הראשית של המשתמש.
השדה הזה מוצג רק אם האסימון כולל את ההיקף
|
exp |
תאריך תפוגה | תאריך התפוגה של האסימון, בפורמט של זמן יוניקס. |
scope |
היקפי ההרשאות של OAuth | קבוצת ממשקי ה-API שהלקוח מורשה לגשת אליהם בשם המשתמש, שמזוהה על ידי היקף הרשאות OAuth. |
sub |
נושא |
הגורם המאומת, שמזוהה באמצעות המזהה הייחודי שלו. המזהה הזה מקביל למזהה שמוצג ב- Directory API. |
התוקף של אסימוני גישה של משתמשים פג אוטומטית אחרי שעה, אבל אפשר לבטל אותם לפני כן אם צריך.
כברירת מחדל, אסימוני הגישה של המשתמשים הם אסימונים למוכ"ז, כלומר הם לא קשורים לערוץ תקשורת, לרשת או לפרטי כניסה נוספים. אפשר גם להטמיע קישור טוקנים על ידי פריסת גישה מבוססת-אישורים, כך שאפשר להשתמש בטוקנים של גישת משתמש רק בשילוב עם אישור לקוח mTLS תקין.
אסימוני גישה לחשבון שירות
אסימוני גישה לחשבון שירות מאמתים חשבון שירות. האסימונים הם אטומים
ואפשר לבדוק אותם באמצעות https://oauth2.googleapis.com/tokeninfo API.
עבור אסימון גישה של חשבון שירות, ה-API מחזיר פלט שדומה לדוגמה הבאה:
{
"azp": "000000000000000000000",
"aud": "000000000000000000000",
"scope": "https://www.googleapis.com/auth/userinfo.email",
"exp": "1744687132",
"expires_in": "3568",
"email": "service-account@example.iam.gserviceaccount.com",
"email_verified": "true",
"access_type": "online"
}
אסימון של חשבון שירות כולל את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
aud |
קהל | חשבון השירות שאליו משויך האסימון, ששווה ל-authorized party. |
azp |
צד מורשה | חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו. |
email |
כתובת אימייל ראשית |
כתובת האימייל של חשבון השירות.
השדה הזה מוצג רק אם האסימון כולל את ההיקף
|
exp |
תאריך תפוגה | תאריך התפוגה של האסימון, בפורמט של זמן יוניקס. |
אי אפשר לבטל אסימוני גישה לחשבונות שירות, והם תקפים עד שהתוקף שלהם פג.
כברירת מחדל, התוקף של אסימוני גישה לחשבון שירות פג אחרי שעה אחת. באמצעות השיטה
serviceAccounts.generateAccessToken
אפשר לבקש טוקנים עם משך חיים שונה. משך חיים ארוך יותר של אסימונים עלול להגדיל את הסיכון, ולכן צריך להגדיר את האילוץ iam.allowServiceAccountCredentialLifetimeExtension כדי לאפשר ללקוחות לבקש אסימוני גישה לחשבון שירות עם משך חיים ארוך משעה אחת.
אסימונים של הענקת גישה ברמת הדומיין
טוקנים של הענקת גישה ברמת הדומיין מאמתים משתמש ומאשרים לחשבון שירות לפעול בשם המשתמש. האסימונים אטומים, ואפשר לבדוק אותם באמצעות https://oauth2.googleapis.com/tokeninfo API.
אם מדובר באסימון להענקת גישה ברמת הדומיין, ה-API מחזיר פלט שדומה לדוגמה הבאה:
{
"azp": "000000000000000000000",
"aud": "000000000000000000000",
"scope": "https://www.googleapis.com/auth/admin.directory.user.readonly https://www.googleapis.com/auth/userinfo.email",
"exp": "1744688957",
"expires_in": "3540",
"email": "user@example.com",
"email_verified": "true",
"access_type": "offline"
}
אסימון להענקת גישה ברמת הדומיין כולל את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
aud |
קהל | חשבון השירות שאליו משויך האסימון, ששווה לצד המורשה. |
azp |
צד מורשה | חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו. |
email |
כתובת אימייל ראשית |
כתובת האימייל הראשית של המשתמש שמתחזים אליו. השדה הזה מוצג רק אם האסימון כולל את ההיקף
|
exp |
תאריך תפוגה | תאריך התפוגה של האסימון, בפורמט של זמן יוניקס. |
scope |
היקפי ההרשאות של OAuth | קבוצת ממשקי ה-API שהלקוח יכול לגשת אליהם בשם המשתמש המתחזה, שמזוהה על ידי היקף ההרשאות של OAuth. |
התוקף של אסימוני הרשאה ברמת הדומיין פג אוטומטית אחרי שעה, ואי אפשר לבטל אותם.
אסימוני JWT (JSON Web Tokens) של חשבון שירות
אסימוני JWT (JSON Web Tokens) של חשבון שירות מאמתים חשבון שירות. לעומת זאת, אסימוני גישה של חשבון שירות מונפקים על ידי שרת הרשאות, אבל אסימוני JWT של חשבון שירות יכולים להיות מונפקים על ידי הלקוח עצמו.
לפעמים הם נקראים אסימוני JWT בחתימה עצמית. הם יכולים להיות שימושיים כשצריך לבצע אימות לממשקי Google APIs מסוימים בלי לקבל אסימון גישה משרת ההרשאות – למשל, כשיוצרים ספריות לקוח משלכם.
כדי להנפיק JWT של חשבון שירות, הלקוחות צריכים לבצע את השלבים הבאים:
מכינים מטען ייעודי (payload) של חתימת אינטרנט מסוג JSON שכולל את כתובת האימייל של חשבון השירות, היקף הרשאה של OAuth או נקודת קצה ל-API ומועד תפוגה.
חתימה על מטען הייעודי (payload) באמצעות מפתח של חשבון השירות הרלוונטי. לקוחות יכולים לחתום על מטען הייעודי (payload) במצב אופליין באמצעות מפתח של חשבון שירות בניהול המשתמש, או במצב אונליין באמצעות השיטה
signJwtומפתח של חשבון שירות בניהול Google. למידע נוסף, תוכלו לקרוא את המאמר יצירת JSON Web Token בחתימה עצמית
דוגמה ל-JWT של חשבון שירות אחרי פענוח, כש-SIGNATURE מוחלף בחתימה של האסימון:
{
"alg": "RS256",
"kid": "290b7bf588eee0c35d02bf1164f4336229373300",
"typ": "JWT"
}.{
"iss": "service-account@example.iam.gserviceaccount.com",
"sub": "service-account@example.iam.gserviceaccount.com",
"scope": "https://www.googleapis.com/auth/cloud-platform",
"exp": 1744851267,
"iat": 1744850967
}.SIGNATURE
במקום לציין היקף OAuth במפתח scope, אפשר לציין נקודת קצה ל-API במפתח aud באסימון JWT של חשבון שירות:
{
"alg": "RS256",
"kid": "290b7bf588eee0c35d02bf1164f4336229373300",
"typ": "JWT"
}.{
"iss": "service-account@example.iam.gserviceaccount.com",
"sub": "service-account@example.iam.gserviceaccount.com",
"aud": "https://cloudresourcemanager.googleapis.com/",
"exp": 1744854799,
"iat": 1744851199
}.SIGNATURE
JWT של חשבון שירות כולל את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
aud |
קהל |
נקודות קצה של API שהלקוח יכול לגשת אליהן. ההגדרה הזו תקפה רק אם לא צוין scope.
|
exp |
תאריך תפוגה | תאריך התפוגה של האסימון, בפורמט של זמן יוניקס. |
iat |
זמן הבעיה | הזמן שבו הונפק האסימון, בפורמט של חותמת זמן של מערכת Unix. |
iss |
מנפיק | הגורם שהנפיק את האסימון, שהוא חשבון השירות עצמו. |
scope |
היקפי ההרשאות של OAuth |
קבוצת ממשקי ה-API שהלקוח מורשה לגשת אליהם, שמזוהים על ידי
היקף הרשאות OAuth. ההגדרה הזו תקפה רק אם לא צוינה מדיניות aud.
|
sub |
נושא | חשבון המשתמש המאומת, שהוא חשבון השירות עצמו. |
אסימוני JWT של חשבונות שירות יכולים להיות תקפים למשך שעה אחת לכל היותר, ואי אפשר לבטל אותם.
אסימוני גישה מאוחדים
אסימוני גישה מאוחדים מאמתים את הזהות של משתמש במאגר זהויות של כוח עבודה או של משתמש במאגר זהויות של עומסי עבודה.
איחוד שירותי אימות הזהות של כוח עבודה מאפשר ללקוחות להמיר אסימון חיצוני לאסימון גישה מאוחד שמאמת את המשתמש הראשי במאגר כוח העבודה. הגורם הראשי במאגר הזהויות של כוח העבודה מזוהה באמצעות מזהה גורם ראשי שדומה לדוגמה הבאה:
principal://iam.googleapis.com/locations/global/workforcePools/POOL/subject/raha@altostrat.com.
איחוד שירותי אימות הזהות של עומסי עבודה מאפשר ללקוחות להמיר אסימון חיצוני לאסימון גישה מאוחד שמאמת את העיקרון של מאגר עומסי עבודה. הגורם הראשי במאגר הזהויות של עומסי העבודה מזוהה על ידי מזהה גורם ראשי שדומה לזה:
principal://iam.googleapis.com/projects/PROJECT/locations/global/workloadIdentityPools/POOL/subject/SUBJECT_ATTRIBUTE_VALUE
אסימוני גישה מאוחדים הם אטומים ואי אפשר לבדוק אותם. אי אפשר לבטל את האסימונים והם תקפים עד לתפוגה. תוקף האסימונים מכל סוג מוגדר באופן הבא:
איחוד שירותי אימות הזהות של כוח העבודה מגדיר את תוקף האסימון לערך הקטן מבין שני הערכים הבאים:
הזמן שנותר עד שתוקף הסשן של איחוד שירותי אימות הזהות של כוח העבודה יפוג
שעה אחת
תוקף הסשן של איחוד שירותי אימות הזהות של כוח העבודה נקבע על סמך זמן הכניסה ומשך הסשן שהוגדר למאגר של איחוד שירותי אימות הזהות של כוח העבודה.
איחוד שירותי אימות הזהות של עומסי עבודה מגדיר את תפוגת האסימון כך שתהיה זהה לתפוגה של האסימון החיצוני.
אסימונים של גבולות גישה לפרטי כניסה
אסימונים של גבולות גישה לפרטי הכניסה מאמתים משתמש או חשבון שירות וכוללים גבולות גישה. גבול הגישה מגביל את האסימון כך שאפשר להשתמש בו רק כדי לגשת לקבוצת משנה מוגדרת של משאבי Cloud Storage.
אסימונים של גבולות הגישה לפרטי כניסה נקראים לפעמים אסימונים עם היקף מצומצם כי הם נגזרים מאסימון קלט, אבל הגישה שלהם למשאבים מוגבלת יותר.
תוקף הטוקנים של גבולות הגישה לפרטי הכניסה נגזר מתוקף טוקן הקלט, שיכול להיות טוקן גישה של משתמש או טוקן גישה של חשבון שירות.אסימונים של גבולות גישה לפרטי כניסה הם אטומים, ואי אפשר לבדוק אותם או לבטל אותם.
טוקנים של גבולות גישה לפרטי כניסה שהונפקו על ידי לקוח
אסימונים של גבולות גישה לפרטי כניסה שהונפקו על ידי לקוח דומים לאסימונים של גבולות גישה לפרטי כניסה, אבל הם מותאמים לתרחישים שבהם לקוחות צריכים לקבל אסימונים של גבולות גישה לפרטי כניסה עם גבולות גישה שונים בתדירות גבוהה.
לקוחות יכולים ליצור באופן מקומי אסימונים של גבול גישה לפרטי כניסה שהונפקו על ידי הלקוח באמצעות ספריות הלקוח ב-Cloud ואסימון ביניים של גבול גישה, שהם צריכים לרענן מעת לעת.
אסימונים של גבולות גישה לפרטי כניסה שהונפקו על ידי לקוח הם אטומים, ואי אפשר לבדוק אותם או לבטל אותם.
טוקנים שמעניקים טוקנים
אסימונים שמעניקים אסימונים מאפשרים ללקוחות לקבל אסימונים חדשים או שונים, אולי בשלב מאוחר יותר. Google Cloud תומך בכמה סוגים שונים של אסימונים שמעניקים אסימונים, ולכולם יש את המאפיינים המשותפים הבאים:
הם מייצגים אימות קודם.
הם מאמתים חשבון משתמש, שיכול להיות זהות ב-Google (משתמש או עומס עבודה) או זהות חיצונית.
אפשר לממש אותם כדי לקבל טוקן גישה.
אי אפשר להשתמש בהם כדי לבצע קריאות ל-Google API, ולכן הם שונים מטוקנים לגישה.
האסימונים שמעניקים אסימונים יכולים להיות שונים בדרכים הבאות:
Issuer: הגורם שמנפיק את האסימון.
Principal: סוג הזהות של חשבון המשתמש שאסימון יכול לאמת.
הגבלות: ההגבלות שאפשר להטיל על הטוקן.
בטבלה הבאה מפורטים הסוגים השונים של אסימונים שמעניקים גישה לאסימונים.
| סוג הטוקן | מנפיק | סוג טוקן הגישה שנפדה | חשבונות משתמשים | הגבלות |
|---|---|---|---|---|
| טוקן רענון | שרת ההרשאות של Google | טוקן גישה של משתמש |
|
היקף הרשאות OAuth |
| קוד הרשאה | שרת ההרשאות של Google | טוקן גישה של משתמש |
|
היקף הרשאות OAuth |
| טוקן רענון מאוחד | Google Cloud שרת הרשאות IAM | טוקן גישה מאוחד | פרינציפל במאגר זהויות של כוח עבודה | היקף הרשאות OAuth |
| קוד הרשאה מאוחד | Google Cloud שרת הרשאות IAM | טוקן גישה מאוחד | פרינציפל במאגר זהויות של כוח עבודה | היקף הרשאות OAuth |
| טענת JWT (אסימון אינטרנט מסוג JSON) של חשבון שירות | לקוח |
|
|
היקף הרשאות OAuth |
| אסימון רשת חיצוני מבוסס JSON | ספק זהויות חיצוני | טוקן גישה מאוחד | גורם חיצוני | ללא |
| טענת נכוֹנוּת (assertion) או תגובה חיצונית של SAML | ספק זהויות חיצוני | טוקן גישה מאוחד | גורם חיצוני | ללא |
אסימון של Amazon Web Services (AWS) GetCallerIdentity
|
ספק זהויות חיצוני | טוקן גישה מאוחד | גורם חיצוני | ללא |
לסוגים השונים של אסימונים שמעניקים אסימונים יש גם מאפייני אבטחה שונים:
פורמט: חלק מהטוקנים אטומים. הלקוח יכול לפענח אסימונים אחרים.
משך חיים: לכל טוקן יש משך חיים שונה, ומידת האפשרות לשנות אותו שונה.
שימוש רב: אפשר להשתמש בחלק מהאסימונים שמעניקים אסימונים רק פעם אחת. באסימונים אחרים אפשר להשתמש כמה פעמים.
אפשרות ביטול: אפשר לבטל חלק מהטוקנים. אסימונים אחרים נשארים בתוקף עד לתאריך התפוגה.
בטבלה הבאה מסוכמים ההבדלים בין המאפיינים האלה עבור טוקנים שמעניקים גישה:
| סוג הטוקן | פורמט | כל התאריכים | ניתן לביטול | רב-שימושי |
|---|---|---|---|---|
| טוקן רענון | אטום | משתנה, ראו אסימוני רענון | כן | כן |
| קוד הרשאה | אטום | 10 דקות | לא | לא |
| טוקן רענון מאוחד | אטום | משתנה, ראו אסימוני רענון מאוחדים | לא | כן |
| קוד הרשאה מאוחד | אטום | 10 דקות | לא | לא |
| טענת זהות של אסימון JWT (JSON Web Token) של חשבון שירות | JWT | 5 דקות עד שעה | לא | כן |
| אסימון חיצוני או אסימון חיצוני מסוג JSON Web Token | JWT | תלוי בספק הזהויות | תלוי בספק הזהויות | כן |
| טענת נכונות או תגובה חיצונית של SAML | SAML | תלוי בספק הזהויות | תלוי בספק הזהויות | כן |
טוקן של Amazon Web Services (AWS) GetCallerIdentity |
בלוב טקסט | תלוי בספק הזהויות | תלוי בספק הזהויות | כן |
אסימוני רענון
אסימוני רענון הם אסימונים אטומים שמאפשרים ללקוחות לקבל אסימוני מזהה ואסימוני גישה עבור משתמש, אם המשתמש אישר בעבר ללקוח לפעול בשמו.
טוקנים לרענון קשורים ללקוח ספציפי ואפשר להשתמש בהם רק בשילוב עם פרטי לקוח תקינים, למשל מזהה לקוח וסוד לקוח.
אם ההרשאה של הלקוח כוללת Google Cloud היקפי OAuth אחד או יותר, משך החיים של טוקן הרענון כפוף לשליטה בGoogle Cloud אורך הסשן. אחרת, טוקנים לרענון נשארים בתוקף עד שהמשתמש מבטל את ההרשאה שלו או עד שמתרחשים אירועים אחרים של ביטול טוקנים.
קודי הרשאה
קודי הרשאה הם אסימונים אטומים לטווח קצר. הקודים מיועדים לשימוש רק במהלך אימות המשתמש כגורם מתווך בין הלקוח לבין שרת ההרשאות של Google.
בדומה לאסימוני רענון, קודי הרשאה משויכים ללקוח ואפשר להשתמש בהם רק בשילוב עם פרטי לקוח תקינים. בניגוד לאסימוני רענון, אפשר להשתמש בקודי הרשאה רק פעם אחת.
טוקנים מאוחדים לרענון
אסימוני רענון מאוחדים הם אסימונים אטומים שמאפשרים ללקוחות לקבל אסימוני גישה עבור משתמש ראשי במאגר זהויות של כוח עבודה, אם המשתמש אישר בעבר ללקוח לפעול בשמו.
בדומה לאסימוני רענון, אסימוני רענון מאוחדים קשורים ללקוח ספציפי ואפשר להשתמש בהם רק בשילוב עם פרטי כניסה תקפים של לקוח, למשל מזהה לקוח וסוד לקוח.
בניגוד לאסימוני רענון, אי אפשר לבטל אסימוני רענון מאוחדים. משך החיים של אסימון רענון מאוחד מקושר לסשן של אימות הזהות של כוח העבודה ששימש לקבלת האסימון, והוא נשאר בתוקף עד שהסשן יפוג.
קודי הרשאה מאוחדים
בדומה לקודי הרשאה, קודי הרשאה מאוחדים הם אסימונים אטומים לטווח קצר. הקודים מיועדים לשימוש רק במהלך אימות המשתמש כגורם מתווך בין הלקוח לבין שרת ההרשאות של Google Cloud IAM.
קודי הרשאה משויכים ללקוח, אפשר להשתמש בהם רק בשילוב עם פרטי כניסה תקינים של לקוח, ואפשר להשתמש בהם רק פעם אחת.
טענות (assertions) של אסימוני JWT (JSON Web Tokens) של חשבון שירות
הצהרות של אסימוני JWT (JSON Web Tokens) בחשבון שירות מאשרות את הזהות של חשבון שירות. עומסי עבודה יכולים להשתמש בהצהרות JWT של חשבון שירות כדי לקבל אסימוני גישה לחשבון שירות או אסימונים של הענקת הרשאות גישה ברמת הדומיין. הצהרת ה-JWT של חשבון השירות חתומה על ידי מפתח של חשבון שירות.
טענת נכוֹנוּת (assertion) של JWT של חשבון שירות לאחר פענוח נראית בערך כך, כש-SIGNATURE מוחלף בחתימה של האסימון:
{
"alg": "RS256",
"kid": "290b7bf588eee0c35d02bf1164f4336229373300",
"typ": "JWT"
}.{
"iss": "service-account@example.iam.gserviceaccount.com",
"scope": "https://www.googleapis.com/auth/devstorage.read_only",
"aud": "https://oauth2.googleapis.com/token",
"exp": 1744851267,
"iat": 1744850967
}.SIGNATURE
הצהרות JWT של חשבון שירות דומות מבחינה מבנית לאסימוני JWT של חשבון שירות: את שני סוגי האסימונים יכול להנפיק הלקוח עצמו, והם חתומים באמצעות מפתח של חשבון שירות. עם זאת, שני סוגי האסימונים משתמשים במטענים שונים, כפי שמתואר בטבלה הבאה.
| שדה | JWT של חשבון שירות | הצהרת JWT של חשבון שירות |
|---|---|---|
aud |
Google Cloud API, מושמט אם מצוין scope |
חייב להיות https://oauth2.googleapis.com/token |
exp |
תאריך תפוגה | תאריך תפוגה |
iat |
זמן הבעיה | זמן הבעיה |
iss |
כתובת האימייל של חשבון השירות | כתובת האימייל של חשבון השירות |
scope |
היקפי הרשאות OAuth, מושמטים אם מצוין |
היקפי ההרשאות של OAuth |
sub |
כתובת האימייל של חשבון השירות | כתובת האימייל של חשבון משתמש להענקת גישה ברמת הדומיין. אם לא מוגדרת כתובת, הערך הוא ריק. |
אפשר להשתמש בטענות JWT של חשבון שירות למשך שעה אחת לכל היותר, ואי אפשר לבטל אותן.
אסימוני JWT חיצוניים
אסימוני JWT (JSON Web Tokens) חיצוניים מונפקים על ידי ספק זהויות חיצוני, כמו Microsoft Entra ID, Okta, Kubernetes או GitHub. יכול להיות שהמבנה והתוכן שלהם יהיו שונים.
הגדרת איחוד זהויות של כוח עבודה או איחוד זהויות של עומסי עבודה מאפשרת ליצור יחסי אמון בין Google Cloud לבין ספק זהויות חיצוני. עומסי עבודה יכולים להשתמש ב-JWT חיצוניים כאסימונים שמעניקים גישה כדי לקבל אסימוני גישה מאוחדים.
כשמשתמשים באיחוד שירותי אימות הזהות של כוח עבודה, אסימון הגישה המאוחד שמתקבל מאמת את חשבון המשתמש במאגר הזהויות של כוח העבודה.
כשמשתמשים באיחוד שירותי אימות הזהויות של עומסי עבודה, אסימון הגישה המאוחד שמתקבל מאמת את חשבון המשתמש של מאגר הזהויות של עומס העבודה.
בשני המקרים, מזהה חשבון המשתמש נגזר מאחת או יותר מהטענות של ה-JWT החיצוני.
כדי להיות תואמים לאיחוד שירותי אימות הזהות של כוח העבודה או לאיחוד שירותי אימות הזהות של עומסי עבודה, אסימוני JWT חיצוניים צריכים לעמוד בדרישות ספציפיות.
טענות נכוֹנוּת (assertions) או תגובות SAML חיצוניות
טענות נכוֹנוּת (assertions) חיצוניות של Security Assertion Markup Language (SAML) הן טענות נכוֹנוּת (assertions) של SAML 2.0 שמונפקות על ידי ספק זהויות חיצוני כמו Microsoft Entra ID, Okta או Active Directory Federation Services. אפשר גם לצרף את טענות הנכוֹנוּת החיצוניות של SAML לתגובת SAML 2.0 או להצפין אותן.
בדומה לאסימוני JSON Web חיצוניים, אתם יכולים להגדיר את איחוד שירותי אימות הזהות של כוח העבודה או את איחוד שירותי אימות הזהות של עומסי עבודה כך שעומסי עבודה יוכלו להשתמש בתגובות או בטענות נכוֹנוּת (assertions) חיצוניות של SAML כאסימונים שמעניקים גישה כדי לקבל אסימוני גישה מאוחדים.
כדי להיות תואמים לאיחוד שירותי אימות הזהות של כוח העבודה או לאיחוד שירותי אימות הזהות של עומסי עבודה, טענות נכונות (assertions) חיצוניות של SAML צריכות לעמוד בדרישות ספציפיות.
טוקן של Amazon Web Services (AWS) GetCallerIdentity
אסימוני AWS GetCallerIdentity חיצוניים הם אובייקטים של טקסט שמכילים בקשה חתומה ל-GetCallerIdentity API של AWS.
בדומה לאסימוני אינטרנט חיצוניים של JSONולטענות נכוֹנוּת (assertions) של SAML, אפשר להגדיר את איחוד שירותי אימות הזהות של כוח עבודה או את איחוד שירותי אימות הזהות של עומסי עבודה כך שעומסי עבודה יוכלו להשתמש בבלובים האלה של טקסט כאסימון להענקת אסימון כדי לקבל אסימוני גישה מאוחדים.
אסימוני זהות
אסימוני זהות (ID) מאפשרים ללקוחות לזהות את המשתמשים שאיתם הם מקיימים אינטראקציה. Google Cloud תומך בכמה סוגים שונים של אסימוני זהות, ולכולם יש את המאפיינים המשותפים הבאים:
הם מעוצבים כ-JSON Web Tokens (JWT) כדי שהלקוח יוכל לפענח, לאמת ולפרש אותם.
הם מאמתים חשבון ראשי, שיכול להיות משתמש או עומס עבודה.
הם מונפקים ללקוח מסוים.
הם תקפים לזמן קצר בלבד, והתוקף שלהם פג אחרי שעה לכל היותר.
אי אפשר לבטל אותם.
אי אפשר להשתמש בהם כדי לבצע קריאות ל-Google API, ולכן הם שונים מאסימוני גישה.
אי אפשר להשתמש בהם כדי לקבל אסימוני גישה, ולכן הם שונים מאסימונים שמאפשרים הענקת הרשאות.
אפשר להשתמש בהם כדי לאמת קריאות בין מיקרו-שירותים, או כדי לאמת באופן פרוגרמטי בשרת proxy לאימות זהויות (IAP).
אסימוני זהות יכולים להיות שונים מהסיבות הבאות:
קהל: הצד שאמור לפענח את האסימון ולהשתמש בו.
Issuer: הגורם שמנפיק את האסימון.
כל משך החיים: לכל טוקן יש תוקף שונה, ומידת האפשרות לשנות אותו שונה.
Principal: סוג הזהות של חשבון המשתמש שאסימון יכול לאמת.
בטבלה הבאה מפורטים הסוגים השונים של אסימוני זהות.
| סוג הטוקן | מנפיק | קהל | חשבון משתמש | כל התאריכים |
|---|---|---|---|---|
| אסימון מזהה משתמש | שרת ההרשאות של Google | לקוח OAuth/OIDC |
|
שעה אחת |
| אסימון מזהה של חשבון שירות | Google Cloud שרת הרשאות IAM | חופשיים לבחור כל קהל | חשבון שירות | שעה אחת |
| טענת נכוֹנוּת (assertion) של שרת proxy לאימות זהויות (IAP) | IAP |
|
|
10 דקות |
| SAML assertion | שרת ההרשאות של Google | אפליקציית SAML | משתמש (חשבון מנוהל) | 10 דקות |
אסימונים של מזהי משתמשים
אסימונים מזהים של משתמשים הם אסימוני JWT (JSON Web Tokens) שמאמתים משתמש. לקוחות יכולים לקבל אסימון מזהה של משתמש על ידי הפעלת תהליך אימות OIDC.
אסימוני User ID חתומים באמצעות Google JSON Web Key Set (JWKS). קובץ ה-JWKS של Google הוא משאב גלובלי, ואותם מפתחות חתימה משמשים לסוגים שונים של משתמשים, כולל:
חשבונות מנוהלים
חשבונות משתמשים פרטיים
חשבונות שירות
אסימון מזהה משתמש מפוענח נראה בערך כך, כש-SIGNATURE מוחלף בחתימה של האסימון:
{
"alg": "RS256",
"kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
"typ": "JWT"
}.{
"iss": "https://accounts.google.com",
"azp": "1234567890-123456789abcdef.apps.googleusercontent.com",
"aud": "1234567890-123456789abcdef.apps.googleusercontent.com",
"sub": "12345678901234567890",
"at_hash": "y0LZEe-ervzRNSxn4R-t9w",
"name": "Example user",
"picture": "https://lh3.googleusercontent.com/a/...",
"given_name": "Example",
"family_name": "User",
"hd": "example.com",
"iat": 1745361695,
"exp": 1745365295
}.SIGNATURE
אסימון מזהה כולל את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
aud |
קהל |
לקוח ה-OAuth שאליו משויך הטוקן הזה, שמזוהה באמצעות מזהה הלקוח ב-OAuth. לקוחות OAuth יכולים לקבל טוקנים של גישה ללקוחות OAuth אחרים ששייכים לאותו פרויקט. במקרה כזה, יכול להיות שהקהל יהיה שונה מהגורם המורשה. |
azp |
צד מורשה | לקוח ה-OAuth שביצע את תהליך האימות של OIDC, מזוהה על ידי מזהה לקוח ה-OAuth שלו. |
exp |
תאריך תפוגה | תאריך התפוגה של האסימון, בפורמט של זמן יוניקס. |
hd |
דומיין מתארח |
הדומיין הראשי של חשבון Cloud Identity או Google Workspace של המשתמש.
התביעה הזו מופיעה רק אם המשתמש הוא חשבון מנוהל והלקוח ציין את הפרמטר
|
iss |
מנפיק |
הישות שהנפיקה את האסימון. הערך תמיד יהיה https://accounts.google.com.
|
sub |
נושא |
הגורם המאומת, שמזוהה באמצעות המזהה הייחודי שלו. המזהה הזה מקביל למזהה שמוצג ב- Directory API. |
הקבוצה המדויקת של ההצהרות שכלולות בטוקן מזהה תלויה בפרמטר scope בבקשת האימות.
כדי לזהות אם משתמש הוא חשבון מנוהל, או כדי לזהות את חשבון Cloud Identity או Google Workspace שאליו משתמש משתייך, הלקוחות צריכים לבדוק את הטענה hd.
אסימונים מזהים של משתמשים תקפים למשך שעה אחת, ואי אפשר לבטל אותם.
טוקנים של מזהי חשבונות שירות
אסימונים מזהים של חשבון שירות הם אסימוני JWT (JSON Web Tokens) שמאמתים חשבון שירות.
בשונה מאסימוני JWT של חשבון שירות ומהצהרות JWT של חשבון שירות, אסימוני מזהה של חשבון שירות לא נחתמים על ידי מפתח של חשבון שירות. במקום זאת, אסימונים מזהים של חשבונות שירות נחתמים על ידי Google JSON Web Key Set (JWKS).
אסימון מזהה של חשבון שירות אחרי פענוח נראה בערך כך, כש-SIGNATURE מוחלף בחתימה של האסימון:
{
"alg": "RS256",
"kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
"typ": "JWT"
}.{
"aud": "example-audience",
"azp": "112010400000000710080",
"email": "service-account@example.iam.gserviceaccount.com",
"email_verified": true,
"exp": 1745365618,
"iat": 1745362018,
"iss": "https://accounts.google.com",
"sub": "112010400000000710080"
}.SIGNATURE
אסימון מזהה של חשבון שירות כולל את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
aud |
קהל | מזהה של הצד שאליו האסימון הזה מיועד. הערך יכול להיבחר באופן חופשי על ידי מי שמבקש את הטוקן. |
azp |
צד מורשה | חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו. |
exp |
תאריך תפוגה | תאריך התפוגה של האסימון, בפורמט של זמן יוניקס. |
iss |
מנפיק |
הנפקן של האסימון, תמיד מוגדר כ-https://accounts.google.com.
|
sub |
נושא | חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו. |
הקבוצה המדויקת של ההצהרות שכלולות באסימון מזהה תלויה באופן שבו מתבצעת הבקשה לאסימון המזהה. לדוגמה, אסימוני מזהה שמבוקשים על ידי שרת המטא-נתונים של Compute Engine יכולים לכלול אופציונלית טענות נוספות שמאשרות את הזהות של ה-VM. אסימוני מזהה שנשלחת לגביהם בקשה באמצעות IAM Credentials API יכולים להכיל את מזהה הארגון של הפרויקט של חשבון השירות.
בניגוד לאסימוני מזהה של משתמשים, אסימוני מזהה של חשבונות שירות לא תומכים בטענהhd.
אסימונים מזהים של חשבונות שירות תקפים לשעה אחת, ואי אפשר לבטל אותם.
טענות של שרת proxy לאימות זהויות (IAP)
טענות הנכוֹנוּת (assertions) של שרת proxy לאימות זהויות (IAP) הן אסימוני JSON Web Token (JWT) שמועברים על ידי IAP לאפליקציות אינטרנט שמוגנות על ידי IAP בכותרת בקשת ה-HTTP x-goog-iap-jwt-assertion. טענות של IAP מאמתות משתמש ומשמשות גם כהוכחה לכך שבקשה אושרה על ידי IAP.
חשבונות מנוהלים
חשבונות פרטיים
חשבונות שירות
גורמים ראשיים במאגר זהויות של כוח עבודה
טענת נכוֹנוּת (assertion) של IAP מפוענחת נראית בערך כך, כאשר SIGNATURE מוחלף בחתימה של האסימון:
json {:.readonly}
{
"alg": "ES256",
"typ": "JWT",
"kid": "4BCyVw"
}.{
"aud": "/projects/0000000000/global/backendServices/000000000000",
"azp": "/projects/0000000000/global/backendServices/000000000000",
"email": "user@example.com",
"exp": 1745362883,
"google": {
"access_levels": [
"accessPolicies/0000000000/accessLevels/Australia"
]
},
"hd": "example.com",
"iat": 1745362283,
"identity_source": "GOOGLE",
"iss": "https://cloud.google.com/iap",
"sub": "accounts.google.com:112010400000000710080"
}.SIGNATURE
אם מגדירים את IAP לשימוש באיחוד שירותי אימות הזהות של כוח עבודה במקום בזהויות של Google, טענות IAP נראות קצת שונה:
{
"alg": "ES256",
"typ": "JWT",
"kid": "4BCyVw"
}.{
"aud": "/projects/0000000000/global/backendServices/000000000000",
"azp": "/projects/0000000000/global/backendServices/000000000000",
"email": "user@example.com",
"exp": 1745374290,
"google": {
"access_levels": [
"accessPolicies/0000000000/accessLevels/Australia"
]
},
"iat": 1745373690,
"identity_source": "WORKFORCE_IDENTITY",
"iss": "https://cloud.google.com/iap",
"sub": "sts.google.com:AAFTZ...Q",
"workforce_identity": {
"iam_principal": "principal://iam.googleapis.com/locations/global/workforcePools/example/subject/user-0000000000",
"workforce_pool_name": "locations/global/workforcePools/example"
}
}.SIGNATURE
הצהרת IAP כוללת את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
aud |
קהל | שירות הקצה העורפי, אפליקציית App Engine או שירות Cloud Run שאליהם מיועדת טענת ה-IAP. |
iss |
מנפיק |
המנפיק של הטוקן, תמיד מוגדר כ-https://cloud.google.com/iap
|
sub |
נושא |
הגורם המאומת, שמזוהה באמצעות המזהה הייחודי שלו. אם שרת IAP מוגדר לשימוש בזהויות של Google, המזהה הזה שווה למזהה שמוצג ב- Directory API. |
לפרטים נוספים על טענות הנכוֹנוּת של IAP, ראו אימות מטען ה-JWT.
הצהרות על רכישות מתוך האפליקציה תקפות למשך 10 דקות, ואי אפשר לבטל אותן.
טענות נכוֹנוּת (assertions) של SAML
טענות נכונות (assertions) של Security Assertion Markup Language (SAML) מאמתות חשבון משתמש מנוהל ומאשרות לו גישה לאפליקציית SAML בהתאמה אישית. טענות נכונות של SAML מונפקות ונחתמות על ידי Cloud Identity, ואפשר להשתמש בהן רק כדי לאמת חשבונות משתמשים מנוהלים.
בניגוד לאסימוני זיהוי (ID) שנחתמים באמצעות מפתח גלובלי, טענות הנכונות (assertions) של SAML נחתמות באמצעות מפתח שספציפי לחשבון Cloud Identity או לחשבון Google Workspace.
טענת נכוֹנוּת (assertion) של תגובת SAML מפוענחת נראית כך:
<saml2:Assertion
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="..."
IssueInstant="2025-04-23T22:47:20.881Z"
Version="2.0">
<saml2:Issuer>
https://accounts.google.com/o/saml2?idpid=C0123456789
</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
user@example.com
</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData
NotOnOrAfter="2025-04-23T22:52:20.881Z"
Recipient="https://app.example.com/"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions
NotBefore="2025-04-23T22:42:20.881Z"
NotOnOrAfter="2025-04-23T22:52:20.881Z">
<saml2:AudienceRestriction>
<saml2:Audience>example-app</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement
AuthnInstant="2025-04-23T22:46:44.000Z"
SessionIndex="...">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
טענת נכוֹנוּת (assertion) של SAML כוללת את השדות הבאים:
| שדה | שם | תיאור |
|---|---|---|
Audience |
קהל | מזהה ישות ב-SAML של אפליקציית SAML. |
Issuer |
מנפיק | הנפקן של האסימון, ספציפי לחשבון Cloud Identity או לחשבון Google Workspace. |
NameID |
נושא | החשבון המאומת. הפורמט של המזהה תלוי בהגדרות של אפליקציית SAML. |
הקבוצה המדויקת של מאפיינים שנכללים בטענת הנכוֹנוּת (assertion) של SAML תלויה בהגדרות של אפליקציית SAML.
הצהרות SAML תקפות למשך 10 דקות, ואי אפשר לבטל אותן.