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

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

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

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

סקירה כללית

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

תוכנית ההעברה הזו כוללת שלושה שלבים:

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

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

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

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

איסוף נתונים על שימוש מרכזי

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

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

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

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

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

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

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

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

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

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

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

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

דוגמה: כל עומסי העבודה הנוכחיים מוערכים לצורך העברה

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

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

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

דוגמה: לא מתבצעת הערכה של עומסי עבודה (workloads) להעברה

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

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

זיהוי של ניצחונות מהירים

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

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

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

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

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

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

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

תכנון תהליך חריגים

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

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

הודעה לבעלי עומסי העבודה על שינויים צפויים

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. חשוב לוודא שהוקצו לכם התפקידים 'Tag Administrator' (roles/resourcemanager.tagAdmin) ו'אדמין מדיניות ארגונית' (roles/orgpolicy.policyAdmin) ברמת הארגון. במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים מוסבר איך מקצים תפקידים ברמת הארגון.

  2. ברמת הארגון, יוצרים מפתח תג וערך תג שישמשו להגדרה אם משאב צריך להיות פטור ממדיניות הארגון. מומלץ ליצור תג עם המפתח disableServiceAccountKeyCreation והערכים enforced ו-not_enforced.

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

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

    במאמר צירוף תגים למשאבים מוסבר איך לצרף תגים למשאבים.

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

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

    • מגדירים את האילוץ iam.disableServiceAccountKeyCreation כך שלא ייאכף על משאבים עם התג disableServiceAccountKeyCreation: not_enforced. התנאי בכלל הזה צריך להיראות כך: 

      "resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced')"
    • מגדירים את האילוץ iam.disableServiceAccountKeyCreation כך שהוא ייאכף על כל שאר המשאבים.

תיקון של עומסי עבודה קיימים

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

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

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

  • אתם משתמשים במוצרים מסחריים מוכנים (COTS) או באפליקציות של תוכנה כשירות (SaaS) שמבקשות להזיןCloud de Confiance מפתח של חשבון שירות ישירות בממשק המשתמש שלהן.
  • עומס העבודה פועל מחוץ ל- Cloud de Confiance ולא מתבצע אימות שלו באמצעות ספק זהויות שתומך באיחוד שירותי אימות הזהות של עומסי עבודה.

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

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

מחיקת מפתחות מיותרים

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

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

  • מפתחות לעומסי עבודה שעברו לשיטות אימות אחרות.

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

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

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

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

שיפורים שוטפים בניהול חשבונות שירות

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

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