שיטות מומלצות לשימוש בחשבונות שירות

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

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

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

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

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

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

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

במדריך הזה מוצגות שיטות מומלצות לניהול, לשימוש ולאבטחה של חשבונות שירות.

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

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

כשנכנסים לשירותי Google Cloud באמצעות ה-CLI של Google Cloud, ספריות הלקוח של Cloud, כלים שתומכים ב-Application Default Credentials‏ (ADC) כמו Terraform או בקשות REST, תוכלו להיעזר בדיאגרמה שכאן כדי לבחור שיטת אימות:

עץ החלטות שנועד לעזור בבחירת שיטת אימות בהתאם לתרחיש לדוגמה

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

  1. אתם מפעילים קוד בסביבת פיתוח למשתמש יחיד, כמו תחנת עבודה משלכם, Cloud Shell או ממשק של מחשב וירטואלי?
    1. אם כן, ממשיכים לשאלה 4.
    2. אם לא, ממשיכים לשאלה 2.
  2. אתם מפעילים את הקוד ב-Google Cloud?
    1. אם כן, ממשיכים לשאלה 3.
    2. אם לא, ממשיכים לשאלה 5.
  3. אתם מפעילים קונטיינרים ב-Google Kubernetes Engine או ב-Anthos?
    1. אם כן, משתמשים ב-Workload Identity כדי לחבר חשבונות שירות לקבוצות Pod ב-Kubernetes.
    2. אם לא, מחברים חשבון שירות למשאב.
  4. בתרחיש לדוגמה שלכם יש צורך בחשבון שירות?

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

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

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

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

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

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

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

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

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

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

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

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

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

באופן ספציפי, שירותים מסוימים של Google Cloud, כולל App Engine ו-Compute Engine, יוצרים חשבון שירות כברירת מחדל שיש לו תפקיד עריכה (roles/editor) בפרויקט כברירת מחדל. כשיוצרים משאב כמו מכונה וירטואלית (VM) ב-Compute Engine בלי לציין חשבון שירות, המשאב יכול להשתמש באופן אוטומטי בחשבון השירות שמוגדר כברירת מחדל. חשבון השירות שמוגדר כברירת מחדל מקל על התחלת העבודה, אבל מאוד מסוכן לשתף חשבון שירות מתקדם כזה עם כמה אפליקציות.

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

פעולה בהתאם למוסכמה לגבי מתן שמות ותיעוד

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

  • מוסיפים לכתובת האימייל של חשבון השירות קידומת שמתארת את אופן השימוש בחשבון. לדוגמה:
    • vm- לחשבונות שירות שמחוברים למכונה וירטואלית.
    • wi- לחשבונות שירות שבשימוש של Workload Identity.
    • wif- לחשבונות שירות שבשימוש של איחוד שירותי אימות הזהות של עומסי עבודה.
    • onprem- לחשבונות שירות שבשימוש של אפליקציות בארגון.
  • מטמיעים את שם האפליקציה בכתובת האימייל של חשבון השירות, לדוגמה: vm-travelexpenses@ אם המכונה הווירטואלית מפעילה אפליקציה למעקב אחרי הוצאות נסיעה.
  • משתמשים בשדה התיאור כדי להוסיף איש קשר, קישורים למסמכים רלוונטיים או הערות אחרות.

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

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

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

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

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

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

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

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

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

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

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

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

בחלק משירותי Google Cloud, נוצרים חשבונות שירות שמוגדרים כברירת מחדל כשמפעילים את ה-API בפעם הראשונה בפרויקט ב-Google Cloud. כברירת מחדל, חשבונות השירות האלה מקבלים את התפקיד 'עריכה' (roles/editor) בפרויקט שלכם ב-Google Cloud. התפקיד הזה מאפשר להם לקרוא ולשנות את כל המשאבים בפרויקט ב-Google Cloud. התפקיד הזה ניתן לנוחיותכם, אבל הוא לא הכרחי כדי שהשירותים יפעלו: כדי לגשת למשאבים בפרויקט שלכם ב-Google Cloud, שירותי Google Cloud משתמשים בסוכני שירות ולא בחשבונות השירות שמוגדרים כברירת מחדל.

כדי שחשבונות שירות שמוגדרים כברירת מחדל לא יקבלו את התפקיד 'עריכה' באופן אוטומטי, צריך להפעיל בארגון את האילוץ השבתה של הענקת IAM לחשבונות שירות שמוגדרים כברירת מחדל באופן אוטומטי (constraints/iam.automaticIamGrantsForDefaultServiceAccounts). כדי להחיל את האילוץ על פרויקטים ב-Google Cloud, צריך להגדיר אותו בתיקייה או בצומת של הארגון. החלת האילוץ לא מסירה את התפקיד עריכה מחשבונות שירות שהוגדרו כברירת מחדל.

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

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

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

היקפי הגישה רחבים. לדוגמה, באמצעות ההיקף https://www.googleapis.com/auth/devstorage.read_only תוכלו להגביל את הגישה ב-Cloud Storage לפעולות לקריאה בלבד, אבל אי אפשר להגביל את הגישה לקטגוריות ספציפיות. מהסיבה הזו היקפי הגישה לא נחשבים לתחליף מתאים למדיניות הרשאות מפורטת.

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

לא משתמשים בקבוצות כדי לתת לחשבונות שירות הרשאות גישה למשאבים.

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

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

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

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

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

נמנעים משימוש במתן הרשאות גישה ברמת הדומיין

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

הענקת הרשאות גישה ברמת הדומיין לא מונעת מחשבון שירות להתחזות למשתמש מסוים, אלא מאפשרת לו להתחזות לכל משתמש בחשבון Cloud Identity או Google Workspace, כולל סופר-אדמינים. לכן שימוש בהענקת הרשאות גישה ברמת הדומיין הופך את חשבונות השירות ליעד אטרקטיבי להתקפות מסוג הסלמת הרשאות (privilege escalation).

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

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

יכול להיות שיש צורך בגישה לנתוני משתמש רגישים או אישיים באפליקציה מסוימת. הנתונים האלה יכולים להיות תיבת הדואר או היומן של המשתמש, מסמכים ששמורים ב-Google Drive או מערך נתונים ב-BigQuery שמכיל מידע אישי רגיש.

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

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

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

אם תאפשרו לאפליקציה להשתמש בפרטי כניסה של משתמש קצה, תוכלו להפנות את הבדיקות של ההרשאות ל-Google Cloud APIs. דרך הפעולה הזאת את הסיכון לחשוף בטעות נתונים שלמשתמשים לא אמורה להיות גישה אליהם בגלל שגיאה בתכנות (בלבול הרשאות, באנגלית: confused deputy problem).

משתמשים ב-IAM credentials API בשביל העלאת רמת הרשאה באופן זמני

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

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

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

כדי לעזור לוודא שלחלקים השונים באפליקציה יש גישה רק למשאבים שנחוצים להם, תוכלו להשתמש ב-IAM Credentials API לצורך העלאת רמת הרשאה זמניות:

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

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

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

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

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

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

משתמשים בהמלצות לתפקידים כדי לזהות הרשאות שלא נמצאות בשימוש

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

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

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

משתמשים בתובנות לגבי תנועה רוחבית כדי להגביל תנועה רוחבית

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

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

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

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

הגנה מפני איומים של הסלמת הרשאות (privilege escalation)

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

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

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

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

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

    לדוגמה, אם למשתמש יש גישת SSH למכונה וירטואלית ב-Compute Engine, הוא יכול להתחזות באופן עקיף לחשבון השירות שמחובר למכונה הווירטואלית ולגשת לכל המשאבים ב-Google Cloud שחשבון השירות יכול לגשת אליהם.

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

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

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

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

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

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

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccountKeys.create
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

התפקידים שכוללים חלק מההרשאות האלה הם (בין היתר):

  • בעלים (roles/owner)
  • עריכה (roles/editor)
  • משתמש בחשבון שירות (roles/iam.serviceAccountUser)
  • יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator)
  • אדמין של מפתח לחשבון שירות (roles/iam.serviceAccountKeyAdmin)
  • אדמין בחשבון שירות (roles/iam.serviceAccountAdmin)
  • משתמש ב-Workload Identity (roles/iam.workloadIdentityUser)
  • עריכה ב-Deployment Manager (roles/deploymentmanager.editor)
  • עריכה ב-Cloud Build (roles/cloudbuild.builds.editor)

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

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

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

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

בכללי מדיניות ההרשאות של חשבון השירות מתועדים המשתמשים שמורשים להשתמש בו או להתחזות אליו. משתמשים שיש להם את ההרשאה iam.serviceAccounts.setIamPolicy יכולים לשנות או להרחיב את כללי המדיניות באותו חשבון שירות. התפקידים שכוללים את ההרשאה הזו הם (בין היתר):

  • בעלים (roles/owner)
  • אדמין לענייני אבטחה (roles/iam.securityAdmin)
  • אדמין בחשבון שירות (roles/iam.serviceAccountAdmin)

תפקידים שכוללים את ההרשאה iam.serviceAccounts.setIamPolicy מעניקים למשתמש שליטה מלאה על חשבון שירות:

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

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

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

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

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

בשביל ליצור או להעלות מפתח לחשבון שירות, נדרשת ההרשאה iam.serviceAccountKeys.create שכלולה בתפקידים אדמין של מפתח לחשבון שירות (roles/iam.serviceAccountKeyAdmin) ועריכה (roles/editor).

לפני שמקצים למשתמש תפקיד שכולל את ההרשאה iam.serviceAccountKeys.create, חשוב לברר לאילו משאבים, בתוך הפרויקט הנוכחי ב-Google Cloud ומחוץ לו, המשתמש יכול לקבל גישה באמצעות התחזות לחשבון השירות. אל תאפשרו למשתמש ליצור מפתחות לחשבונות שירות שיש לו יותר הרשאות מלאותו משתמש.

אם בפרויקט שלכם ב-Google Cloud אין בכלל צורך במפתחות לחשבונות שירות, כדאי להחיל על הפרויקט ב-Google Cloud או על התיקייה המצורפת את אילוצי מדיניות הארגון השבתת יצירה של מפתח לחשבון שירות והשבתת העלאה של מפתח לחשבון שירות. האילוצים האלה מונעים מכל המשתמשים את האפשרות ליצור ולהעלות מפתחות לחשבונות שירות, כולל משתמשים שיש לם את ההרשאה iam.serviceAccountKeys.create בחשבון השירות.

לא מעניקים גישה לחשבונות שירות ברמת הפרויקט ב-Google Cloud או ברמת התיקייה

חשבונות שירות הם משאבים, והם חלק מהיררכיית המשאבים. לכן אתם יכולים לנהל את הגישה לחשבונות שירות בכל אחת מהרמות האלה:

  • חשבון השירות האישי
  • הפרויקט המצורף ב-Google Cloud
  • תיקייה בישות האב של הפרויקט ב-Google Cloud
  • הצומת של הארגון

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

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

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

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

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

  • את קוד האפליקציה שלכם
  • את הקוד שמשתמשי הקצה שלחו, אם האפליקציה שלכם מתירה הערכה של סקריפטים בצד השרת
  • את קוד שנקרא ממאגר מקור מרוחק, אם משאב המחשוב הוא חלק ממערכת CI/CD
  • את הסקריפטים להפעלה ולכיבוי שמוצגים באמצעות קטגוריה של Cloud Storage
  • את כללי מדיניות האורחים שמופצת באמצעות VM Manager

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

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

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

  • באמצעות Compute Engine תוכלו להשתמש ב-SSH או ב-RDP כדי להתחבר למכונה וירטואלית.
  • באמצעות Google Kubernetes Engine תוכלו להשתמש ב-kubectl exec כדי להריץ פקודה או להפעיל מעטפת בקונטיינר ב-Kubernetes.

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

במכונות ב-Linux, תוכלו לאכוף גישת SSH מוגבלת יותר מהגישה לחשבון שהירות המחובר באמצעות OS Login: כדי לקשר למכונה וירטואלית שמופעל בה OS Login, לא מספיק שהמשתמש מורשה להשתמש ב-OS Login, חייבת גם להיות לו ההרשאה iam.serviceAccounts.actAs בחשבון השירות המחובר.

אותה רמה של בקרת גישה לא חלה על מכונות וירטואליות שמשתמשות במפתחות שמבוססים על מטא-נתונים או על מכונות ב-Windows: כדי לפרסם מפתח SSH למטא-נתונים או לבקש פרטי כניסה ל-Windows נדרשות גישה למטא-נתונים של מכונה וירטואלית וההרשאה iam.serviceAccounts.actAs בחשבון השירות המחובר. עם זאת, אחרי שמפתח ה-SSH פורסם או שפרטי הכניסה ל-Windows הושגו, ההתחברות הבאה לא מחויבת לבדיקות נוספות של הרשאות IAM.

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

במיוחד במכונות וירטואליות שלא משתמשות ב-OS Login, מומלץ להעניק גישת מעטפת באמצעות שרת proxy לאימות זהויות (IAP). כדאי להקצות את התפקיד 'משתמש מנהרה באבטחת IAP' למשתמשים שאמורה להיות להם הרשאה להתחזות לחשבון השירות המחובר למכונה הווירטואלית.

מגבילים את הגישה של שרת המטא-נתונים למשתמשים ולתהליכים נבחרים

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

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

ב-Linux, תוכלו להשתמש באפשרויות --uid-owner ו---gid-owner כדי להגדיר כלל iptables שחל רק על קבוצות או משתמשים ספציפיים. ב-Windows, הפקודה Set-NetFirewallSecurityFilter מאפשרת להתאים אישית כלל חומת אש כדי שיחול על קבוצות או על משתמשים נבחרים.

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

נמנעים מחשיפת מידע סודי בכתובות אימייל של חשבונות שירות

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

בדרך כלל, צפייה מדיניות ההרשאות לא נחשבת פעולה שמצריכה הרשאות. הרבה תפקידים כוללים את ההרשאה הנדרשת *.getIamPolicy, כולל התפקיד הבסיסי 'צפייה'.

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

לדוגמה, כללי מדיניות ההרשאות יכולים לכלול קישור לחשבון שירות שכתובת האימייל שלו היא jenkins@deployment-project-123.gserviceaccount.com. כתובת האימייל חושפת לגורמים זדוניים גם שקיים פרויקט ב-Google Cloud שהמזהה שלו הוא deployment-project-123 וגם שהפרויקט ב-Google Cloud מריץ שרת Jenkins. בחירת שם כללי יותר, כמו deployer@deployment-project-123.gserviceaccount.com, מונעת חשיפה של מידע על סוג התוכנה שפועלת במזהה deployment-project-123.

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

הגנה מפני איומים של אי-התכחשות

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

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

הקטע הזה כולל שיטות מומלצות שיכולות לעזור לשמר נתיב ביקורת לאיומי אי-התכחשות.

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

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

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

מפעילים יומני גישה לנתונים של ממשקי API ב-IAM

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

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

  • Identity and Access Management (IAM) API בכל הפרויקטים ב-Google Cloud שיש בהם חשבונות שירות
  • Security Token Service API בכל הפרויקטים ב-Google Cloud שכוללים מאגרי זהויות של כוח עבודה

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

מוודאים שאפשר להתאים פרטים בהיסטוריית ה-CI/CD ליומני הביקורת של Cloud

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

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

כדי ליצור נתיב ביקורת עקבי במערכת CI/CD וב-Google Cloud, אתם צריכים לוודא שיש התאמה בין הרשומות ביומני הביקורת של Cloud לאירועים בהיסטוריה של מערכת ה-CI/CD. אם ביומני הביקורת של Cloud מופיע אירוע לא צפוי, תוכלו להשתמש בהתאמה הזאת כדי לקבוע אם מערכת ה-CI/CD באמת ביצעה את השינוי, למה הוא בוצע ומי אישר אותו.

יש כמה שיטות לבסס התאמה בין רשומות ביומני ביקורת ב-Cloud לאירועים בהיסטוריה של מערכת ה-CI/CD, ביניהן:

  • רישום ביומן של בקשות API שבוצעו בכל הרצה של צינור עיבוד נתונים של CI/CD.
  • תיעוד של המזהה ביומנים של מערכת ה-CI/CD בכל פעם שה-API מחזיר מזהה פעילות.
  • הוספה של כותרת ה-HTTPX-Goog-Request-Reason לבקשות API והעברת המזהה של הפעלת צינור עיבוד הנתונים של CI/CD. המערכת של Terraform יכולה להוסיף את הכותרת הזאת באופן אוטומטי אם מציינים את סיבת הבקשה.

    לחלופין, תוכלו להטמיע את המידע בכותרת User-Agent כדי שהוא יתועד ביומני הביקורת של Cloud.

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

יוצרים רשומות מותאמות אישית ביומן למשתמשים ספציפיים באפליקציה

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

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

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