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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כמה דוגמאות של התחזות לחשבון שירות:

  • המשתמש מפעיל פקודת CLI של gcloud עם הדגל --impersonate-service-account. הדגל הזה גורם ל-CLI של gcloud ליצור פרטי כניסה לטווח קצר עבור חשבון השירות, ולאחר מכן להריץ את הפקודה עם פרטי הכניסה האלה.

    במצב כזה, המשתמש מתחזה לחשבון השירות.

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

    במצב כזה, המשתמש מתחזה לחשבון השירות.

הדוגמאות הבאות הן לא התחזות לחשבון שירות:

  • משתמש מצרף משאב לחשבון שירות.

    המשתמש לא מאמת את החשבון בתור חשבון השירות כשהוא מצורף למשאב, ולכן הוא לא מתחזה לחשבון השירות.

  • קוד שרץ על משאב מבצע קריאות ל-API מורשה באמצעות חשבון השירות המצורף של משאב.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המאמר יצירת חשבונות שירות מסביר איך יוצרים חשבון שירות.

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

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

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

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

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

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

השם המוצג של חשבון השירות הוא דרך טובה להציג מידע עליו, כמו מטרת החשבון או איש הקשר שלו. בחשבונות שירות חדשים אפשר לקבוע את השם המוצג כשיוצרים את חשבון השירות. בחשבונות שירות קיימים, השתמשו בשיטה 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$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

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