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

במדריך הזה מתוארות שיטות מומלצות לניהול, לשימוש ולאבטחה של חשבונות שירות מפני איומי אבטחה. Cloud de Confiance by S3NS

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

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

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

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

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

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

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

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

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

1. אתם מפעילים קוד בסביבת פיתוח למשתמש יחיד, כמו תחנת עבודה משלכם, Cloud Shell או ממשק של מחשב וירטואלי?
   1. אם כן, ממשיכים לשאלה 4.
   2. אם לא, ממשיכים לשאלה 2.
2. האם אתם מריצים קוד ב- Cloud de Confiance by S3NS?
   1. אם כן, ממשיכים לשאלה 3.
   2. אם לא, ממשיכים לשאלה 5.
3. אתם מריצים קונטיינרים ב-Google Kubernetes Engine?
   1. אם כן, משתמשים ב- Workload Identity Federation for GKE כדי לחבר חשבונות שירות לקבוצות Pod ב-Kubernetes.
   2. אם לא, מחברים חשבון שירות למשאב.

4. בתרחיש לדוגמה שלכם יש צורך בחשבון שירות?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש ב-Service Account Credentials API להעלאת רמת הרשאה באופן זמני

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

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

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

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

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

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

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

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

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

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

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

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

  לדוגמה, אם למשתמש יש גישת SSH למכונה וירטואלית ב-Compute Engine, הוא יכול להריץ קוד במכונה כדי לגשת לכל משאב שחשבון השירות שמחובר למכונה יכול לגשת אליו.

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

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

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

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

הענקת הרשאה למשתמש להתחזות לחשבון שירות בעל יותר הרשאות יכולה להיות שיטה לאפשר למשתמש להעלות את רמת ההרשאות שלו באופן זמני, באופן דומה לשימוש בכלי 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אסור להעניק גישה לחשבונות שירות ברמת הפרויקט או ברמת התיקייה Cloud de Confiance

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

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

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

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

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

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

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

• את קוד האפליקציה שלכם
• את הקוד שמשתמשי הקצה שלחו, אם האפליקציה שלכם מתירה הערכה של סקריפטים בצד השרת
• את קוד שנקרא ממאגר מקור מרוחק, אם משאב המחשוב הוא חלק ממערכת 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, יכול להיות שהמשתמשים שלא הייתה להם אפשרות לקבל הרשאה להתחזות לחשבון השירות במקרה אחר מורשים להתחבר. מידע נוסף זמין במאמר בנושא שיטות מומלצות להפעלת Active Directory ב-Cloud de Confiance.

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

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

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

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

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

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

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

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

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

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

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

הגנה מפני איומי מניעת הכחשה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• רישום ביומן של בקשות API שבוצעו בכל הרצה של צינור עיבוד נתונים של CI/CD.
• תיעוד של המזהה ביומנים של מערכת ה-CI/CD בכל פעם שה-API מחזיר מזהה פעילות.

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

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

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

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

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

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

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

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