פרטי כניסה לחשבון שירות

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

חשבונות שירות מבצעים אימות על ידי ביצוע אחת מהפעולות הבאות:

פרטי כניסה לחשבון שירות לטווח קצר

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

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

במקרים רבים פרטי הכניסה האלה מתקבלים אוטומטית – אתם לא צריכים ליצור או לנהל אותם בעצמכם. הנה כמה דוגמאות:

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

ה-Service Account Credentials API יכול ליצור פרטי כניסה מהסוגים הבאים:

  • אסימוני גישה מסוג OAuth 2.0
  • אסימונים מזהים של OpenID Connect‏ (OIDC)
  • אסימוני JWT (‏JSON Web Tokens) בחתימה עצמית
  • ‫blobs בינאריים בחתימה עצמית

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

פירוש של יומני ביקורת

יומני הביקורת של Cloud מיועדים לענות על השאלות 'מי עשה מה, איפה ומתי?' ביחס למשאבי Google Cloud .

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

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

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

לדוגמאות של רשומות ביומן הביקורת שבהן מופיעה התחזות לחשבון שירות, ראו התחזות לחשבון שירות כדי לגשת אל Google Cloud.

התחזות עצמית

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

ה-Service Account Credentials API אוסר על הסוגים הבאים של התחזות עצמית:

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

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

FAILED_PRECONDITION: You can't create a token for the same service account that
you used to authenticate the request.

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

מפתחות של חשבונות שירות

כל חשבון שירות משויך לזוג מפתחות RSA ציבורי/פרטי. ה-Service Account Credentials API משתמש בזוג המפתחות הפנימי הזה כדי ליצור פרטי כניסה לטווח קצר לחשבון שירות, וכדי לחתום על blobs ועל אסימוני JWT ‏(JSON Web Tokens). זוג המפתחות הזה נקרא Google-owned and managed key .

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

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

Google-owned and managed key זוגות

זוגות שלGoogle-owned and managed key משמשים את Service Account Credentials API ואת שירותי Google Cloud כמו App Engine ו-Compute Engine, כדי ליצור פרטי כניסה לטווח קצר לחשבונות שירות.

Google-owned and managed keys שנעשה בהם שימוש פעיל לחתימה, ועוברים רוטציה באופן קבוע בהתאם לשיטות המומלצות לאבטחה. תהליך הרוטציה הוא הסתברותי – מידת השימוש במפתח החדש תעלה ותרד בהדרגה במשך חיי המפתח.

המפתח הפרטי בזוג מפתחות תמיד נשמר בנאמנות, ולעולם לא ניתן לגשת אליו ישירות. Google-owned and managed key

המפתח הציבורי בזוג מפתחות בניהול Google נגיש לציבור, כך שכל אחד יכול לאמת חתימות שנוצרו באמצעות המפתח הפרטי. Google-owned and managed key אתם יכולים לגשת למפתח הציבורי בכמה פורמטים שונים:

  • אישור X.509: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • מפתח JWK‏ (JSON Web Key): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • פורמט גולמי: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

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

זוגות של מפתחות בניהול המשתמש

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

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

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

יש כמה דרכים שונות ליצור זוג מפתחות בניהול משתמש לחשבון שירות:

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

  • ‫constraints/iam.disableServiceAccountKeyCreation: מונע מחשבונות ראשיים ליצור מפתחות לחשבון שירות בניהול משתמש.
  • ‫constraints/iam.disableServiceAccountKeyUpload: מונע מחשבונות ראשיים להעלות מפתח ציבורי לחשבון שירות.

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

מועדי תפוגה של מפתחות בניהול המשתמש

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

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

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

לא מומלץ להשתמש במועדי תפוגה בתרחישים הבאים:

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

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

כדי להגדיר מועד תפוגה, מבצעים את הפעולות הבאות:

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

מועדי התפוגה נמדדים בשעות. מומלץ להשתמש במועדי תפוגה קצרים כמו: 8 שעות, 24 שעות (יום אחד), או 168 שעות (7 ימים). מועדי תפוגה קצרים מבטיחים שלצוות שלכם יהיה תהליך עדכון מפתחות שנבחן היטב. מתחילים עם מועד התפוגה הקצר ביותר שעונה על הצרכים שלכם, ומגדילים אותו רק אם זה הכרחי.