סקירה כללית על חשבונות שירות

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

מהם חשבונות שירות?

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

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

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

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

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

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

הסוגים של חשבונות שירות

ב- Google Cloudיש כמה סוגים שונים של חשבונות שירות:

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

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

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

למידע נוסף על הסוגים השונים של חשבונות שירות, ראו הסוגים של חשבונות שירות.

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

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

  • קבלת פרטי כניסה לטווח קצר. במקרים רבים, כמו במקרה של חשבונות שירות מצורפים ופקודות שמשתמשות בדגל --impersonate-service-account ב-CLI של gcloud, פרטי הכניסה האלה נוצרים באופן אוטומטי – לא צריך ליצור או לנהל אותם בעצמכם.
  • שימוש במפתח של חשבון שירות כדי לחתום על אסימון אינטרנט מסוג JSON ‏(JWT) ולהחליף אותו באסימון גישה. מפתחות של חשבונות שירות מהווים סיכון אבטחה אם לא מנהלים אותם בצורה נכונה, לכן כשאפשר, מומלץ לבחור שיטה מאובטחת יותר למפתחות של חשבונות שירות.

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

התחזות לחשבון שירות

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

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

מידע נוסף על התחזות לחשבון שירות זמין במאמר התחזות לחשבון שירות.

חשבונות שירות ודומיינים ב-Google Workspace

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

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

הרשאות של חשבון שירות

חשבונות שירות הם חשבונות משתמשים. המשמעות היא שאתם יכולים לתת לחשבונות שירות גישה ל Google Cloud משאבים. לדוגמה, אפשר לתת לחשבון שירות את התפקיד 'אדמין Compute'‏ (roles/compute.admin) בפרויקט. לאחר מכן, חשבון השירות יוכל לנהל את המשאבים ב-Compute Engine באותו הפרויקט.

אבל חשבונות שירות הם גם משאבים. המשמעות היא שאתם יכולים לתת לחשבונות משתמשים אחרים הרשאה לגשת לחשבון השירות. לדוגמה, אפשר להעניק למשתמש את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) בחשבון שירות כדי לאפשר לו לצרף את חשבון השירות הזה למשאבים. לחלופין, אפשר להקצות למשתמש את התפקיד 'אדמין של חשבון שירות' (roles/iam.serviceAccountAdmin) כדי לאפשר לו לבצע פעולות כמו צפייה בחשבון השירות, עריכה, השבתה ומחיקה שלו.

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

חשבונות שירות כחשבונות משתמשים

מאחר שחשבונות שירות הם חשבונות משתמשים, אפשר לנהל את הגישה לחשבונות שירות בדיוק כמו שמנהלים את הגישה לכל חשבון משתמש אחר. לדוגמה, אם אתם רוצים לאפשר לחשבון השירות של האפליקציה לגשת לאובייקטים בקטגוריה של Cloud Storage, אתם יכולים לתת לחשבון השירות את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer) בקטגוריה. לחלופין, אם רוצים לוודא שחשבון השירות של אפליקציה לא יכול לשנות את מדיניות ה-IAM של פרויקט, אפשר להשתמש במדיניות דחייה כדי למנוע מחשבון השירות להשתמש בהרשאה resourcemanager.projects.setIamPolicy בפרויקט הזה. מידע נוסף על ניהול הגישה לחשבונות משתמשים זמין במאמר גישה ב-Google Cloud.

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

סוג חשבון המשתמש מזהה של חשבון משתמש
חשבון שירות פרטי

serviceAccount:SA_EMAIL_ADDRESS

דוגמה: serviceAccount:my-service-account@my-project.iam.gserviceaccount.com
כל חשבונות השירות בפרויקט

principalSet://cloudresourcemanager.googleapis.com/projects/PROJECT_NUMBER/type/ServiceAccount

דוגמה: principalSet://cloudresourcemanager.googleapis.com/projects/123456789012/type/ServiceAccount
כל חשבונות השירות בכל הפרויקטים בתיקייה

principalSet://cloudresourcemanager.googleapis.com/folders/FOLDER_NUMBER/type/ServiceAccount

דוגמה: principalSet://cloudresourcemanager.googleapis.com/folders/123456789012/type/ServiceAccount
כל חשבונות השירות בכל הפרויקטים בארגון

principalSet://cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_NUMBER/type/ServiceAccount

דוגמה: principalSet://cloudresourcemanager.googleapis.com/organizations/123456789012/type/ServiceAccount

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

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

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

.

חשבונות שירות כמשאבים

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

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

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

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

מחזור החיים של חשבון שירות

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

איפה יוצרים חשבונות שירות

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

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

  • יצירת חשבונות שירות ומשאבים באותו הפרויקט.

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

  • ריכוז חשבונות שירות בפרויקטים נפרדים.

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

    כשחשבון שירות נמצא בפרויקט אחד והוא ניגש למשאב בפרויקט אחר, בדרך כלל צריך להפעיל את ה-API של המשאב הזה בשני הפרויקטים. לדוגמה, אם יש לכם חשבון שירות בפרויקט my-service-accounts ומכונה של Cloud SQL בפרויקטmy-application, תצטרכו להפעיל את Cloud SQL API גם ב-my-service-accounts וגם ב-my-application.

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

כדי ללמוד איך יוצרים חשבון שירות, ראו יצירת חשבונות שירות.

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

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

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

לפני שאוכפים את האילוץ הזה, קחו בחשבון את המגבלות הבאות:

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

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

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

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

מעקב אחרי חשבונות שירות

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

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

שימוש בחשבונות שירות עם Compute Engine

המכונות ב-Compute Engine צריכות לפעול כחשבונות שירות כדי שתהיה להן גישה למשאבים אחרים ב- Google Cloud . כדי לאבטח את המכונות ב-Compute Engine:

  • אפשר ליצור מכונות עם חשבונות שירות שונים באותו פרויקט. כדי לשנות את חשבון השירות של מכונה אחרי שיוצרים אותו, משתמשים בשיטה instances.setServiceAccount.

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

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

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

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

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

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

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

לקוחות Security Command Center Premium יכולים להשתמש ב-Event Threat Detection כדי לקבל התראה כשחשבון שירות רדום גורם להתחלה של פעולה. חשבונות שירות רדומים הם חשבונות שירות שלא היו פעילים במשך יותר מ-180 ימים. אחרי שמשתמשים בחשבון שירות, הוא כבר לא רדום.

מחיקה של חשבונות שירות

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

אפשר למחוק את חשבון השירות אחרי שמוודאים שהוא לא נחוץ.

יצירה מחדש של חשבונות שירות שנמחקו

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

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

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

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

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

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

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

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

נסו בעצמכם

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

מתחילים לעבוד בלי לשלם