בניגוד לחשבונות משתמשים, לחשבונות שירות אין סיסמאות. במקום זאת, חשבונות שירות משתמשים בזוג מפתחות RSA לאימות. אם ידוע המפתח הפרטי של זוג מפתחות של חשבונות שירות, אפשר להשתמש בו כדי ליצור אסימון למוכ"ז של JWT ולהשתמש באסימון למוכ"ז כדי לבקש אסימון גישה. אסימון הגישה שנוצר משקף את הזהות של חשבון השירות, ואפשר להשתמש בו כדי לקיים אינטראקציה עם ממשקיGoogle Cloud API מטעם חשבון השירות.
מכיוון שהמפתח הפרטי מאפשר לבצע אימות בתור חשבון השירות, גישה למפתח הפרטי דומה להכרת הסיסמה של המשתמש. המפתח הפרטי נקרא מפתח של חשבון שירות. זוגות המפתחות המשמשים את חשבונות השירות מתחלקים לשתי קטגוריות: בניהול Google ובניהול משתמשים.
מפתחות של חשבונות שירות יכולים להפוך לסיכון אבטחה אם לא מנהלים אותם בקפידה. כאשר הדבר אפשרי, כדאי לבחור חלופה מאובטחת יותר לצורך אימות. האיומים העיקריים הקשורים למפתחות של חשבונות שירות הם:
- דליפת פרטי כניסה: מפתחות של חשבונות שירות עלולים להגיע בטעות למקומות שבהם הם לא אמורים להיות מאוחסנים. גורם זדוני יכול להשתמש במפתח חשבון שירות שדלף כדי לבצע אימות ולקבל דריסת רגל בסביבה שלכם.
- הסלמת הרשאות (privilege escalation): אם גורם זדוני מקבל גישה למפתח של חשבון שירות שלא מאובטח כראוי, ייתכן שהוא יוכל להשתמש במפתח כדי לקבל הרשאות שלא אמורות להיות לו.
- חשיפת מידע: מפתחות של חשבונות שירות עלולים לחשוף בטעות מטא-נתונים סודיים.
- מניעת הכחשה: אימות באמצעות מפתח של חשבון שירות ומתן אפשרות לחשבון השירות לבצע פעולות מטעמו יכול לאפשר לגורם זדוני להסתיר את הזהות ואת הפעולות שלו.
- הגדרות זדוניות של פרטי כניסה: גורם זדוני יכול לספק הגדרה זדונית של פרטי כניסה כדי לעקוף את אמצעי ההגנה שלכם.
הדרך הטובה ביותר להפחית את האיומים האלו היא להימנע ממפתחות של חשבונות שירות בניהול משתמשים, ולהשתמש בשיטות אחרות לאימות חשבונות שירות כשהדבר אפשרי. אפשר גם להשתמש בתנאים של IAM וב-VPC Service Controls כדי להגביל את המשאבים שאפשר לגשת אליהם דרך חשבון שירות שנפרץ.
במצבים שבהם אי אפשר להשתמש בחלופות מאובטחות יותר למפתחות של חשבונות שירות, מדריך זה מפרט שיטות מומלצות לניהול, לשימוש ולאבטחה של מפתחות של חשבונות שירות.
הגנה מפני דליפת פרטי כניסה
כמו שם משתמש וסיסמה, מפתחות של חשבונות שירות הם סוג של פרטי כניסה. אם משתמש יכול לגשת למפתח תקף של חשבון שירות, הוא יכול להשתמש בו כדי לאמת ולגשת למשאבים שחשבון השירות הרלוונטי קיבל גישה אליהם.
לגורמים זדוניים, מפתחות של חשבונות שירות יכולים להיות בעלי ערך רב יותר מסיסמה שדלפה. ניסיון כניסה באמצעות סיסמה שדלפה לא צפוי להצליח אם חשבון המשתמש הוגדר לשימוש באימות דו-שלבי ובאימות זהות. לעומת זאת, אימות באמצעות שימוש במפתח של חשבון שירות שדלף עשוי להצליח, כי חשבונות שירות לא נדרשים לאימותים נוספים בכניסה.
גורמים זדוניים עשויים לחפש מפתחות של חשבונות שירות במגוון מקומות, כולל:
- מאגרים של קוד מקור של פרויקטים בקוד פתוח
- קטגוריות של Cloud Storage
- קובצי נתונים ציבוריים של שירותים שנפרצו
בנוסף למיקומים ציבוריים, גורמים זדוניים עשויים לחפש מפתחות של חשבונות שירות במיקומים פרטיים שנפרצו. לדוגמה:
- תיבות דואר נכנס באימייל
- התקני רשת לשיתוף קבצים
- אחסון לגיבוי
- ספריות זמניות של מערכות קבצים
שיטה אפקטיבית להפחתת הסיכון לדליפת מפתחות של חשבונות שירות היא לצמצם את מספר המפתחות הקיימים, ולא ליצור תמריץ ליצירת מפתחות חדשים. בקטעים הבאים מתואר איך להגביל את מספר המפתחות של חשבונות השירות, ואילו אמצעים אחרים יכולים לעזור בצמצום הסיכון לדליפה של חשבונות שירות.
שיטות מומלצות:
מתן חלופות ליצירת מפתחות של חשבונות שירות.שימוש באילוצים של מדיניות הארגון כדי להגביל את הפרויקטים שיכולים ליצור מפתחות לחשבונות שירות.
לא להשאיר מפתחות של חשבונות שירות במיקומים זמניים.
לא להעביר מפתחות של חשבונות שירות בין משתמשים.
לא לשלוח מפתחות של חשבונות שירות למאגרים של קוד מקור.
לא להטמיע מפתחות של חשבונות שירות בקבצים הבינאריים של תוכנות.
שימוש בתובנות ובמדדים כדי לזהות מפתחות של חשבונות שירות שלא נמצאים בשימוש.
ביצוע רוטציה למפתחות של חשבונות שירות כדי לצמצם את סיכון האבטחה שנוצר בגלל מפתחות שדלפו.
שימוש במועדי תפוגה כדי לאפשר לתוקף המפתחות לפוג באופן אוטומטי
שימוש באילוצים של מדיניות הארגון כדי להשבית באופן אוטומטי מפתחות שנחשפו.
מתן חלופות ליצירת מפתחות של חשבונות שירות
חשוב לוודא שהמשתמשים בארגון מודעים לחלופות ושאפשר להצדיק את הסיכון הנוסף ואת תקורת הניהול הנוספת הכרוכים בשימוש במפתח של חשבון שירות:
- הדרכת מפתחים לגבי חלופות מאובטחות יותר למפתחות של חשבונות שירות.
- יצירת תהליך שעוזר למפתחים להחליט מהי שיטת האימות המתאימה לתרחיש לדוגמה, לפני יצירת מפתח חדש של חשבון שירות.
- שימוש באילוצים של מדיניות הארגון כדי למנוע יצירת מפתחות חדשים של חשבונות שירות, ולאפשר חריגים רק לפרויקטים שהוכיחו שהם לא יכולים להשתמש בחלופה מאובטחת יותר.
שימוש באילוצים של מדיניות הארגון כדי להגביל את הפרויקטים שיכולים ליצור מפתחות של חשבונות שירות
בגלל החלופות המאובטחות יותר למפתחות של חשבונות שירות, עדיף לראות את השימוש במפתחות של חשבונות שירות כאפשרות חריגה במקום כנורמה.
כדי למנוע שימוש מיותר במפתחות של חשבונות שירות, אפשר להשתמש באילוצים של מדיניות הארגון:
ברמה הבסיסית (root) שלהיררכיית המשאבים של הארגון, מחילים את האילוצים השבתה של יצירת מפתח של חשבון שירות והשבתה של העלאת מפתח של חשבון שירות כדי להגדיר ברירת מחדל שבה מפתחות של חשבונות שירות אסורים.
במקרה הצורך, אפשר לבטל את אחד האילוצים של פרויקטים נבחרים כדי להפעיל מחדש יצירה או העלאה של מפתחות של חשבונות שירות.
כדי לשנות אילוצים של מדיניות הארגון צריך את ההרשאה orgpolicy.policy.set. מכיוון שהתפקידים 'בעלים' (roles/owner) ו'עריכה' (roles/editor) לא כוללים את ההרשאה הזו, האילוצים יכולים להיות אפקטיביים בסביבות שאינן ייצור, שבהן ייתכן שלחשבונות משתמש מסוימים יש גישת בעלים או עריכה לפרויקטים.
לא להשאיר מפתחות של חשבונות שירות במיקומים זמניים
כשיוצרים מפתח של חשבון שירות באמצעות מסוף Google Cloud , רוב הדפדפנים מורידים את המפתח החדש באופן מיידי ושומרים אותו בתיקיית הורדות במחשב. צריך להעביר את המפתח באופן מיידי למיקום שבו אתם רוצים לאחסן אותו. ודאו שאתם לא משאירים בטעות עותק בתיקיית ההורדות או בסל המיחזור של המחשב.
אפשר להשתמש ב-CLI של Google Cloud כדי להפחית את הסיכון להשארת עותקי מפתחות של חשבונות שירות במיקומים זמניים בטעות: הפקודה gcloud iam service-accounts keys create מאפשרת לכתוב את קובץ המפתח של חשבון השירות ישירות למיקום שבו צריכים אותו. כמו כן, ברוב מערכות ההפעלה ה-CLI של gcloud מתאים באופן אוטומטי את ההרשאות לקובץ, כדי שרק אתם תוכלו לגשת אליו.
לא להעביר מפתחות של חשבונות שירות בין משתמשים
כשפורסים אפליקציה שמחייבת מפתח לחשבון שירות, יכול להיות שלא תהיה לכם הרשאה ליצור מפתח של חשבון שירות בעצמכם. במקום זאת, ייתכן שתצטרכו לבקש ממישהו אחר ליצור בשבילכם מפתח של חשבון שירות.
בתרחישים שבהם הרבה משתמשים מעורבים ביצירה ובפריסה של מפתח של חשבון שירות, יש סיכון מוגבר שעותקים של המפתח יישארו בתיבות דואר, בהיסטוריית צ'אטים או במיקומים אחרים. כשצריך לבצע החלפה בין משתמשים, יכול להיות מאובטח יותר להעלות מפתח של חשבון שירות:
- מומלץ שהמשתמש שפורס את האפליקציה, ייצור אישור בחתימה עצמית שמשתמש בזוג מפתחות RSA של 2048 ביט במכונת היעד. כדי ליצור את האישור אפשר להשתמש ב-
openssl, ב-certutil, ב-New-SelfSignedCertificateאו בכלים אחרים של מערכת הפעלה. - מעבירים את קובץ האישור למשתמש שיש לו הרשאה להעלות אותו, תוך שמירה על המפתח הפרטי במכונת היעד. כשמעבירים את האישור, חשוב לוודא שלא ניתן להחליף אותו או לשנות אותו, אבל אין צורך לשמור על הסודיות שלו.
- המשתמש בעל ההרשאות שנדרשות לניהול המפתחות של חשבונות השירות צריך להעלות את האישור כדי לשייך אותו לחשבון שירות.
תהליך זה מונע את הצורך להעביר את המפתח הפרטי ובמקום זאת רק מחליף מידע ציבורי בין משתמשים.
לא לשלוח מפתחות של חשבונות שירות למאגרים של קוד מקור
מפתחות של חשבונות שירות הם פרטי כניסה, וצריך להגן עליהם מפני גישה לא מורשית. אם שולחים מפתח של חשבון שירות למאגר של קוד מקור, גובר הסיכון שהמפתח יהיה נגיש למשתמשים לא מורשים ולגורמים זדוניים:
- גורמים זדוניים עלולים לסרוק את קוד המקור של מאגרי מקור ציבוריים כדי לאתר מפתחות שדלפו.
- בעתיד ייתכן שתרצו להפוך מאגר מקור פרטי למאגר ציבורי, בלי לבדוק קודם אם יש בו מפתחות.
- חברי צוות אחרים עלולים לאחסן עותקים של קוד המקור בתחנות העבודה שלהם.
כשעובדים על קוד שמשתמש במפתח של חשבון שירות, צריך לאחסן תמיד את המפתח של חשבון השירות בנפרד מקוד המקור, כדי לצמצם את הסיכון לשליחה בטעות של המפתח למאגר המקור. במקרים רבים אפשר לצמצם עוד יותר את הסיכון אם תעשו שימוש בפרטי הכניסה האישיים במקום במפתחות של חשבונות השירות במהלך הפיתוח.
בנוסף, אפשר להגדיר את המערכת לבקרת המקורות כך שהיא תזהה שליחה בטעות של מפתחות של חשבונות שירות:
- אם משתמשים ב-Cloud Source Repositories, צריך להפעיל גילוי מפתחות כדי לחסום פעולות דחיפת הודעות של
gitשמכילות מפתחות פרטיים, וכדי ליידע את המשתמשים. - אם משתמשים ב-GitHub, צריך להפעיל סריקה סודית של המאגרים.
- אפשר להשתמש בזיהוי אנומליות של Security Command Center כדי להציג מידע על פרטי כניסה שדלפו.
- אם מערכת ניהול בקרת המקורות לא תומכת בסריקה אוטומטית, אפשר להשתמש בכלי קוד פתוח כמו truffHog. כך תוכלו לסרוק את קוד המקור ולחפש סודות באמצעות הוק (hook) לפני שמירה, הוספת שלב לצינור עיבוד הנתונים של אינטגרציה רציפה (CI) או באמצעות שניהם.
לא להטמיע מפתחות של חשבונות שירות בקבצים הבינאריים של התוכנות
מפתחות של חשבונות שירות הן מחרוזות שתואמות לדפוס מסוים, וניתן לזהות אותן גם אם הן מוטמעות בקבצים או בקבצים בינאריים אחרים. אם לגורם זדוני יש גישה לקובץ הבינארי, הוא יכול לחלץ מפתחות של חשבונות שירות שמוטמעים בקובץ הבינארי.
קבצים בינאריים של אפליקציות בצד השרת עשויים להתארח במאגרים של ארטיפקטים, או להיות מועתקים לתחנות עבודה של מפתחים למטרות ניפוי באגים. הפרדה בין מפתחות של חשבונות שירות לקבצים הבינאריים של התוכנות תעזור להבטיח שמשתמש עם גישה לקובץ הבינארי לא יקבל גישה כלל לפרטי הכניסה של חשבונות השירות.
- באפליקציות בצד הלקוח כמו כלים, תוכנות למחשב או אפליקציות לנייד, אנחנו ממליצים לא להשתמש בחשבונות שירות. במקום זאת, כדאי לאפשר למשתמשים לבצע אימות באמצעות פרטי הכניסה שלהם. לדוגמה, אפשר להשתמש בתהליך ההסכמה של OAuth.
- באפליקציות בצד השרת, אנחנו ממליצים לא להטמיע מפתחות של חשבונות שירות בקובץ הבינארי. במקום זאת, כדאי לשמור את המפתחות בנפרד מהקובץ הבינארי של האפליקציה.
שימוש במדדים כדי לזהות מפתחות של חשבונות שירות שלא נמצאים בשימוש
כדי לצמצם את מספר המפתחות התקפים של חשבונות השירות הקיימים, עדיף להשבית מפתחות ברגע שאין יותר צורך בהם, ולאחר מכן למחוק את המפתחות כאשר בטוחים שכבר אין צורך בהם.
אם לא בטוחים שמפתח עדיין נמצא בשימוש, אפשר לבדוק את השימוש בו באמצעות תובנות ומדדי אימות של חשבונות שירות:
- תובנות של חשבונות שירות מאפשרות לזהות חשבונות שירות שלא נעשה בהם שימוש ב-90 הימים האחרונים.
- בעזרת מעקב אחר המדד אירועי אימות מפתחות אפשר לראות מתי נעשה שימוש לאחרונה במפתח של חשבון שירות ובאיזו תדירות נעשה בו שימוש לאימות של חשבון שירות.
מכיוון שחשבונות שירות שייכים ל Google Cloud פרויקט, צריך לעקוב בנפרד אחרי התובנות והמדדים של כל פרויקט.
ביצוע רוטציה למפתחות של חשבונות שירות כדי לצמצם את סיכון האבטחה שנוצר בגלל מפתחות שדלפו
אפשר למזער את הסיכוי להדלפה בטעות של מפתח של חשבון שירות, אבל זה יכול להיות קשה לשלול את הסיכון לחלוטין.
רוטציית מפתחות היא התהליך של החלפת המפתחות הקיימים במפתחות חדשים, וביטול התוקף של המפתחות שהוחלפו. אנו ממליצים לבצע באופן קבוע רוטציה לכל המפתחות שאתם מנהלים, כולל המפתחות של חשבונות השירות.
החלפת מפתחות של חשבונות שירות יכולה לעזור בצמצום הסיכון של דליפת או גניבת מפתחות. אם מתרחשת דליפת מפתח, ייתכן שיחלפו ימים או שבועות עד שגורמים זדוניים יגלו את המפתח. אם תבצעו באופן קבוע רוטציה למפתחות של חשבונות השירות, יש סיכוי גבוה יותר שהמפתחות שדלפו כבר לא יהיו בתוקף עד שגורם זדוני יקבל אותם.
תהליך קבוע עבור רוטציית מפתחות של חשבונות שירות גם עוזר לפעול במהירות, אם קיים חשד שמפתח של חשבון שירות נחשף.
אם יצרתם בעצמכם את זוג המפתחות הציבוריים/הפרטיים, אחסנתם את המפתח הפרטי במודול אבטחת חומרה (HSM) והעליתם את המפתח הציבורי ל- Google Cloud, יכול להיות שלא תצטרכו לבצע רוטציה של המפתח בלוח זמנים קבוע. במקום זאת, אפשר לבצע רוטציה למפתח אם חושדים שהוא נפרץ.
שימוש במועדי תפוגה כדי לאפשר לתוקף המפתחות לפוג באופן אוטומטי
כברירת מחדל, למפתחות של חשבונות שירות שאתם יוצרים ומורידים מ-IAM אין מועד תפוגה והם נשארים בתוקף עד שמוחקים אותם. הגדרת מועד תפוגה למפתחות של חשבונות שירות יכולה לצמצם את סיכוני האבטחה על-ידי קיצור משך החיים של פרטי כניסה קבועים. עם זאת, יש סיכונים אחרים שקשורים להגדרת מועדי תפוגה. לדוגמה, הגדרת מועד תפוגה יכולה לגרום לכשל בעומסי העבודה כשתוקף המפתחות פג.
מומלץ להשתמש במועדי תפוגה כשצריך גישה זמנית למערכת שמחייבת מפתח של חשבון שירות. לדוגמה, כדאי להגדיר מועדי תפוגה כשמבצעים את הפעולות הבאות:
- מפתחים קוד בסביבה שאינה סביבת ייצור, לאפליקציה שאפשר לאמת רק באמצעות מפתחות של חשבונות שירות
- משתמשים בכלי של צד שלישי שיכול לבצע אימות רק באמצעות מפתחות של חשבונות שירות
לא מומלץ להשתמש במועדי תפוגה בתרחישים הבאים:
- עומסי עבודה בסביבת ייצור. בסביבת ייצור, מפתח של חשבון שירות שפג תוקפו עלול לגרום בטעות להפסקה זמנית בשירות. במקום זאת, כדאי להשתמש במפתחות שהתוקף שלהם לא יפוג ולנהל את מחזור החיים שלהם באמצעות רוטציית מפתחות.
- עומסי עבודה שאינם בסביבת ייצור וצריכים גישה קבועה, כמו צינור עיבוד נתונים של אינטגרציה רציפה (CI).
- מערכות של רוטציית מפתחות שמונעות שימוש במפתח אחרי פרק זמן מסוים. מידע נוסף על אסטרטגיות מומלצות לרוטציית מפתחות מופיע במאמר רוטציית מפתחות של חשבונות שירות.
כדי להגביל את התוקף של מפתחות של חשבונות השירות, אפשר להגדיר מועד תפוגה למפתחות חדשים שנוצרים בפרויקט, בתיקייה או בארגון. מועד התפוגה לא חל על מפתחות קיימים.
אפשר גם להעלות מפתח של חשבון שירות ולציין תאריך לפקיעת התוקף בקובץ האישור של X.509. אחרי חלוף מועד התפוגה, לא יהיה אפשר להשתמש במפתח לאימות. עם זאת, הוא יישאר משויך לחשבון השירות עד שתמחקו אותו.
שימוש באילוצים של מדיניות הארגון כדי להשבית באופן אוטומטי מפתחות שנחשפו
גם אם תפעלו לפי כל השיטות המומלצות לשימוש במפתחות של חשבונות שירות, יכול להיות שהמפתחות של חשבונות השירות ידלפו.
כדי לנהל פרטי כניסה שנחשפו, צריך לוודא שהאילוץ תגובה לחשיפה של מפתח לחשבון שירות מוגדר לערך DISABLE_KEY. אם מגדירים את האילוץ לערך הזה, Google Cloud
המערכת תשבית באופן אוטומטי כל מפתח שנחשף.
אם מפתח מושבת כי הוא נחשף, השדות הבאים מתווספים למטא-נתונים של המפתח:
-
"disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": מציין שהמפתח הושבת כי הוא נחשף. -
"extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": מציין שהמפתח נחשף בעבר לציבור. הערך הזה נשמר גם אם מפעילים מחדש את המפתח. -
"extended_status_message": "LINK_TO_EXPOSURE": אם זמינים, מטא-הנתונים מכילים קישור למקום שבו המפתח זוהה, שבו אפשר להשתמש לתיקון שגיאות.
אפשר להפעיל מחדש את המקשים האלה אם צריך לצמצם את ההשפעה של הפסקה זמנית בשירות. עם זאת, מומלץ להשבית אותם שוב בהקדם האפשרי, כי מפתחות שחשופים לציבור מהווים סיכון אבטחה, גם אם החשיפה הראשונית הוסרה.
כדי לקרוא על שיטות מומלצות אחרות לניהול פרטי כניסה שנחשפו, אפשר לעיין במאמר בנושא מה עושים אם פרטי הכניסה נחשפו? Google Cloud
הגנה מפני הסלמת הרשאות (privilege escalation)
השימוש במפתחות של חשבונות שירות יכול לחשוף אתכם למתקפות של הסלמת הרשאות (privilege escalation), אם המפתחות מאובטחים פחות מאשר המשאבים שאליהם המפתחות מעניקים גישה.
לדוגמה, נניח שגורם זדוני כבר השיג דריסת רגל בסביבה שלכם ועכשיו הוא מנסה לגשת למשאבים מסוימים של Google Cloud . יכול להיות שהוא עדיין לא מחזיק בהרשאות האלו, אבל יכול להיות שההרשאות שלו מספיקות כדי לגשת למפתח של חשבון שירות שמאוחסן ב-VM, בהתקן רשת לשיתוף קבצים או במיקום אחר פחות מאובטח. אימות באמצעות המפתח של חשבון השירות יכול לאפשר לגורם הזדוני לעטות את הזהות של חשבון השירות. חשבון השירות עלול להעניק לגורם הזדוני גישה למשאבים שלא הייתה לו גישה אליהם קודם לכן, ובכך להסלים את ההרשאות של הגורם הזדוני.
מכיוון שמפתח של חשבון שירות מעניק באופן עקיף גישה למשאבים של Google Cloud, צריך להתייחס למפתח עצמו כבעל ערך וראוי להגנה כמו המשאבים עצמם.
הקטעים הבאים מתארים שיטות מומלצות להגנה על מפתחות של חשבונות שירות וצמצום הסיכון לגישה בלתי מורשית והסלמת ההרשאות כתוצאה מכך.
שיטות מומלצות:
הימנעות מאחסון מפתחות במערכת קבצים.שימוש במודול אבטחה לחומרה (HSM) או במודול פלטפורמה מהימנה (TPM) לאחסון מפתחות.
שימוש במאגר מפתחות מבוסס תוכנה
לא לאחסן מפתחות ב-Secret Manager או במאגרים סודיים אחרים מבוססי ענן.
לא להשתמש בתפקיד 'עריכה' בפרויקטים שמאפשרים יצירה של מפתחות של חשבונות שירות או העלאה שלהם.
להימנע משימוש במפתחות של חשבונות שירות להענקת גישה ברמת הדומיין.
הימנעות מאחסון מפתחות במערכת קבצים
מפתחות של חשבונות שירות שנוצרים באמצעות מסוף Google Cloud או ה-CLI של gcloud הם קובצי JSON. אפשר להעתיק קבצים אלו למערכת הקבצים של המכונה שבה הם נחוצים. עם זאת, שמירת מפתחות של חשבונות שירות כקבצים במערכת קבצים עלולה לחשוף אתכם למספר סיכונים, כולל:
- במערכות קבצים מסוימות, כמו NTFS, שימוש בהורשת הרשאות הוא ברירת המחדל. ללא השבתה של אפשרות זו, הוספת הרשאה לתיקיית הורה עלולה לגרום לכך שבטעות קובץ של מפתח יהיה נגיש וגלוי למשתמשים לא מורשים.
- בסביבה וירטואלית, גורמים זדוניים עלולים לפגוע באבטחה של מערכת הקבצים באמצעות גישה לדיסק הווירטואלי שבבסיס שלה.
- לרוב, שינויים לגישה ולהרשאות במערכת הקבצים לא מתועדים ביומני ביקורת. אם הרשאות הקבצים ישתנו בטעות והמפתח יהיה גלוי למשתמשים לא מורשים, יכול להיות שיהיה קשה לגלות את הזמן שבו בוצעו השינויים ואת הגורם שביצע אותן.
- קל להעתיק את הקבצים וכתוצאה מכך הם עלולים לזלוג אם גורם זדוני יקבל גישה אליהם.
הימנעו ככל האפשר משמירת מפתחות של חשבונות שירות במערכת קבצים. אם לא ניתן להימנע משמירת מפתחות בדיסק, חשוב לוודא שאתם מגבילים את הגישה לקובץ המפתחות, מגדירים ביקורת על גישה לקובץ ומצפינים את הדיסק שבבסיס שלו.
שימוש במודול אבטחה לחומרה (HSM) או במודול פלטפורמה מהימנה (TPM) לאחסון מפתחות
כשיוצרים מפתח של חשבון שירות באמצעות מסוף Google Cloud או ה-CLI של gcloud, מערכת Google Cloud יוצרת את המפתח הפרטי ואז חושפת אותו בפניכם. סיכוני אבטחה רבים שקשורים למפתחות של חשבונות שירות נובעים מהעובדה שהמפתח הפרטי מופיע באופן זמני או קבוע בטקסט לא מוצפן, כך שקשה להגן עליו.
לכן במקום לאפשר ל- Google Cloud ליצור זוג מפתחות, אפשר להשתמש במודול האבטחה לחומרה (HSM) או במודול פלטפורמה מהימנה (TPM) כדי ליצור מפתחות ולנהל אותם:
- משתמשים ב-HSM או ב-TPM כדי ליצור זוג מפתחות RSA.
- משתמשים בזוג המפתחות כדי ליצור אישור עם חתימה עצמית.
- מעלים את האישור כמפתח של חשבון שירות.
- מאפשרים לאפליקציה להשתמש ב-API החתימה של HSM או של TPM כדי לחתום על ה-JWT לאימות חשבון השירות.
HSM או TPM מאפשרים לכם להשתמש במפתח פרטי בלי לחשוף את המפתח כטקסט לא מוצפן. השימוש ב-HSM או ב-TPM לניהול המפתחות של חשבונות השירות עוזר לאכוף את בקרת הגישה תוך צמצום הסיכון להעתקה של המפתחות למערכות אחרות.
בחלק מהפלטפורמות יש הפשטות שמאפשרות לנצל לרעה את ה-TPM בלי ליצור איתו אינטראקציה ישירה. לדוגמה, Windows מאפשרת לנהל מפתחות שמוגנים באמצעות TPM על ידי שימוש ב-CryptoNG API בשילוב עם ה-Microsoft Platform Crypto Provider.
מפתחות של חשבונות שירות בניהול TPM הם ייחודיים למכונה פיזית או וירטואלית. עדיין תוכלו לאפשר למספר מכונות לשתף חשבון שירות על-ידי שיוך המפתח של כל מכונה עם חשבון שירות משותף.
שימוש במאגר מפתחות מבוסס תוכנה
במצבים שבהם אי אפשר להשתמש במאגר מפתחות מבוסס חומרה, אפשר להשתמש במאגר מפתחות מבוסס תוכנה כדי לנהל את המפתחות של חשבונות השירות. בדומה לאפשרויות שמבוססות על חומרה, מאגר מפתחות מבוסס תוכנה מאפשר למשתמשים או לאפליקציות להשתמש במפתחות של חשבונות שירות בלי לחשוף את המפתח הפרטי. פתרונות של מאגרים מבוססי תוכנה יכולים לעזור לכם לשלוט בגישה למפתחות באופן פרטני, ולהבטיח שכל גישה למפתח תתועד.
האבטחה של מאגר מפתחות מבוסס תוכנה תלויה בדרך כלל באופן שבו מפתח המאסטר שלו מוגן. לפני שמשתמשים במאגר מפתחות מבוסס תוכנה, חשוב לבדוק את הדברים הבאים:
- האופן שבו מפתח המאסטר מאובטח במנוחה,
- האופן שבו פועל תהליך השליפה והגורם שיכול ליזום אותו,
- האופן שבו מפתחות מוגנים מפני חילוץ מהזיכרון,
- האופן שבו מאגר המפתחות מוגן מפני פגיעה אם לגורם זדוני יש גישה למעטפת או גישת hypervisor למערכת הבסיסית.
לא לאחסן מפתחות ב-Secret Manager או במאגרים סודיים אחרים מבוססי ענן
לא מומלץ להשתמש ב-Secret Manager של Google Cloudכדי לאחסן מפתחות של חשבונות שירות ולבצע רוטציה עבורם. הסיבה לכך היא שכדי לגשת לסודות של Secret Manager, האפליקציה זקוקה לזהות ש-Google Cloud יכולה לזהות. אם לאפליקציה כבר יש זהות ש- Google Cloud יכולה לזהות, אז האפליקציה יכולה להשתמש בזהות הזו כדי לאמת את Google Cloud במקום להשתמש במפתח של חשבון שירות.אותו עיקרון חל על שירותי ניהול סודות אחרים מבוססי-ענן, כמו Azure KeyVault ו-AWS Secret Manager. אם לאפליקציה כבר יש זהות שספקי הענן האלה יכולים לזהות, האפליקציה תוכל להשתמש בזהות הזו כדי לבצע אימות ל- Google Cloud במקום להשתמש במפתח של חשבון שירות.
לא להשתמש בתפקיד 'עריכה' בפרויקטים שמאפשרים יצירה של מפתחות של חשבונות שירות או העלאה שלהם
הבדל משמעותי בין התפקידים הבסיסיים 'עריכה' (roles/editor) ו'בעלים' (roles/owner) הוא שהתפקיד 'עריכה' לא מאפשר לשנות כללי מדיניות של IAM או תפקידים.
לכן בתפקיד 'עריכה' אי אפשר להרחיב בקלות את הגישה, או להעניק למשתמשים אחרים גישה למשאבי הפרויקט.
אם בפרויקט יש חשבונות שירות, יש אפשרות שהמגבלות של התפקיד 'עריכה' ייפגעו. מכיוון שתפקידי 'עריכה' מעניקים הרשאה ליצור מפתחות של חשבונות שירות או להעלות אותם, גורם זדוני יכול ליצור מפתחות חדשים לחשבונות השירות הקיימים ולהשתמש במפתחות האלו להסלמת ההרשאות שלו, או כדי להעביר את המפתחות למשתמשים אחרים על-מנת לקבל גישה למשאבי הפרויקט.
לכן במקום להשתמש בתפקיד 'עריכה' או בכל תפקיד בסיסי אחר, עדיף להשתמש בתפקידים שמוגדרים מראש בצורה צרה יותר, או ליצור תפקידים בהתאמה אישית שמעניקים רק את ההרשאות הנדרשות.
אם צריך להשתמש בתפקיד 'עריכה', אנחנו ממליצים להשבית את ההעלאה של מפתחות של חשבונות השירות ואת יצירת המפתחות באמצעות אילוצים של מדיניות הארגון. כך תוכלו לוודא שאי אפשר לעשות שימוש לרעה בתפקיד 'עריכה' להסלמת הרשאות (privilege escalation).
להימנע משימוש במפתחות של חשבונות שירות להענקת גישה ברמת הדומיין
הענקת גישה ברמת הדומיין מאפשרת להתחזות למשתמש כדי שיהיה אפשר לגשת לנתונים של משתמש ללא הרשאה ידנית מצידו. בדרך כלל, דוגמאות שמתארות את השימוש בהענקת גישה ברמת הדומיין מרמזות על שימוש במפתחות של חשבונות שירות, אבל למעשה לא נדרש להשתמש בהם כדי להעניק גישה ברמת הדומיין.
כשמשתמשים בהענקת גישה ברמת הדומיין, מומלץ להימנע ממפתחות של חשבונות שירות ולהשתמש במקום זאת ב-signJwt API:
- קודם מאמתים את חשבון השירות באמצעות חשבון שירות מצורף, איחוד שירותי אימות הזהות של עומסי עבודה ל-GKE או איחוד שירותי אימות הזהות של עומסי עבודה.
- יוצרים JWT ומשתמשים בהצהרה
subכדי לציין את כתובת האימייל של המשתמש שבשבילו מבקשים הענקת גישה. - משתמשים ב-API של
signJwtכדי לחתום על ה-JWT. - מעבירים את ה-JWT החתום למשאב של אסימון OAuth2 כדי לקבל אסימון גישה.
גישה זו מונעת את הצורך לנהל מפתח של חשבון שירות, ומובילה להגדרה שקל יותר לאבטח.
הגנה מפני איומים של חשיפת מידע
הימנעות מחשיפת מידע סודי באישורי X.509 שהועלו
IAM מאפשר להוריד אישור X.509 מנקודת קצה (endpoint) https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL לכל מפתח של חשבון שירות.
נקודת הקצה (endpoint) הזו גלויה לכולם ולא מחייבת אימות.
למפתחות בניהול Google ולמפתחות בניהול משתמשים שיצרתם באמצעות מסוף Google Cloud או ה-CLI של gcloud, אישורי X.509 נוצרים באופן אוטומטי ומכילים רק מטא-נתונים בסיסיים, כמו כתובת האימייל ומועד התפוגה. Google-owned and managed keys Google Cloud
למפתחות של חשבונות שירות שהועלו, אישור X.509 שהעניקה נקודת הקצה הציבורית הוא אותו אישור שהעליתם. אם האישור שהעליתם הכיל מאפיינים אופציונליים (כמו פרטי כתובת או מיקום שמוטמעים בשם הנפוץ), גם מידע זה יהיה נגיש וגלוי לכולם. גורם זדוני עלול להשתמש במידע הזה כדי לקבל מידע נוסף על הסביבה שלכם.
כדי למנוע חשיפת מידע סודי, אל תוסיפו מאפיינים אופציונליים לאישורי X.509 שהועלו, והשתמשו ב-Subject כללי.
הגנה מפני איומי מניעת הכחשה
אם הבחנתם בפעילות חשודה שמשפיעה על המשאבים שלכם ב- Google Cloud, ואתם רוצים לנתח את המקור שלה, אתם צריכים נתונים שיאפשרו לשחזר את שרשרת האירועים שהובילו לפעילות החשודה. המקור העיקרי של הנתונים לביצוע ניתוח כזה הוא לרוב יומני ביקורת.
לפעמים קשה יותר לנתח יומני ביקורת כשמעורבים חשבונות שירות. אם חשבון שירות יבצע פעולה כלשהי, הרשומה ביומן תכיל את כתובת האימייל שלו, אבל צריך גם לגלות את המשתמש או היישום שהשתמשו בחשבון השירות באותו זמן.
בקטעים הבאים מופיעות שיטות מומלצות לשימוש במפתחות של חשבונות שירות כך שיעזרו לכם לעקוב אחר השימוש בהם.
שימוש בחשבון שירות ייעודי לכל אפליקציה
כל הרשומות ביומן הביקורת מכילות שדה principalEmail שמזהה את חשבון המשתמש שביצע את הפעילות. אם תשתפו מפתח של חשבון שירות במספר אפליקציות, יכול להיות שיהיה קשה לזהות איזו אפליקציה ביצעה פעילות, כי לרשומות ביומן הביקורת יש ערך זהה בשדה principalEmail.
לכן במקום לשתף מפתח בין מספר אפליקציות, צריך ליצור חשבון שירות ייעודי לכל אפליקציה. כך אפשר לזהות את האפליקציה שמשויכת לחשבון השירות באמצעות השדה principalEmail, וזה יכול לעזור בשחזור שרשרת האירועים שהובילה לפעילות חשודה.
שימוש במפתח ייעודי לכל מכונה שמריצה אפליקציה
אם מריצים מספר עותקים של אותה אפליקציה במספר מכונות, השדה principalEmail עשוי לאפשר זיהוי של האפליקציה, אבל לא את המכונה שממנה בוצעה פעילות מסוימת.
כדי לצמצם את המקורות הפוטנציאליים של הפעילות החשודה, צריך ליצור מפתחות נפרדים לכל עותק של האפליקציה. כך אפשר להשתמש בשדה serviceAccountKeyName ששירותים רבים מוסיפים לרשומות ביומן הביקורת כדי לזהות מאיזו מכונה הגיעה פעילות.
הגנה מפני הגדרות זדוניות של פרטי כניסה
חלק מהגדרות פרטי הכניסה מכילות כתובות URL ונתיבי קבצים, שאם לא יאומתו כראוי על ידי עומס העבודה, עלולים לגרום לעומס העבודה להשתמש בנקודות קצה זדוניות.
אימות מפתחות שהתקבלו ממקור חיצוני לפני שמשתמשים בהם לאימות ל-Google APIs
כשמקבלים מפתח של חשבון שירות ממקור חיצוני, צריך לאמת את המפתח לפני שמשתמשים בו. אם לא תאמתו את המפתח, גורם זדוני יוכל להשתמש בו כדי לגרום לעומס העבודה שלכם לגשת לנקודות קצה זדוניות.
אם המערכת שלכם מצפה רק למפתחות של חשבונות שירות, צריך לוודא שהערך של השדה type הוא service_account.
מידע נוסף זמין במאמר דרישות אבטחה כשמשתמשים בהגדרות של פרטי כניסה ממקור חיצוני.
המאמרים הבאים
- מידע נוסף על שיטות מומלצות לעבודה עם חשבונות שירות.
- מומלץ לקרוא את המאמר שיטות מומלצות לשימוש בחשבונות שירות בצינורות עיבוד נתונים לפריסה.