בקטע הזה מפורטות פעולות שצריך לקחת בחשבון כשפורסים ומפעילים עומסי עבודה נוספים בסביבת Google Cloud הענן. הקטע הזה לא כולל את כל הפעולות בסביבת הענן, אבל הוא כולל החלטות שקשורות להמלצות הארכיטקטוניות ולמשאבים שנפרסו באמצעות התוכנית.
עדכון משאבי הבסיס
למרות שהתבנית מספקת נקודת התחלה מוכוונת לצרכים של סביבת הבסיס, יכול להיות שהדרישות שלכם לגבי הבסיס יגדלו עם הזמן. אחרי הפריסה הראשונית, יכול להיות שתצטרכו לשנות את הגדרות התצורה או ליצור שירותים משותפים חדשים שישמשו את כל עומסי העבודה.
כדי לשנות משאבי בסיס, מומלץ לבצע את כל השינויים דרך צינור עיבוד הנתונים של הבסיס. במאמר אסטרטגיית הסתעפות מוסבר על תהליך כתיבת הקוד, מיזוגו והפעלת צינורות עיבוד הנתונים לפריסה.
החלטה על מאפיינים לפרויקטים חדשים של עומסי עבודה
כשיוצרים פרויקטים חדשים באמצעות מודול project factory של צינור האוטומציה, צריך להגדיר מאפיינים שונים. התהליך שלכם לעיצוב וליצירה של פרויקטים עבור עומסי עבודה חדשים צריך לכלול החלטות לגבי הנושאים הבאים:
- אילו ממשקי Google Cloud API צריך להפעיל
- באיזה VPC משותף להשתמש, או אם ליצור רשת VPC חדשה
- אילו תפקידי IAM צריך ליצור עבור
project-service-accountהראשוני שנוצר על ידי צינור הנתונים - אילו תוויות פרויקט להחיל
- התיקייה שבה הפרויקט נפרס
- באיזה חשבון לחיוב להשתמש
- האם להוסיף את הפרויקט להיקף של VPC Service Controls
- האם להגדיר תקציב וסף התראה לחיוב בפרויקט
רשימה מלאה של המאפיינים שניתנים להגדרה בכל פרויקט זמינה במשתני הקלט של מפעל הפרויקטים בצינור האוטומציה.
ניהול הרשאות בקנה מידה רחב
כשפורסים פרויקטים של עומסי עבודה על בסיס הפרויקט המרכזי, צריך לחשוב איך להעניק גישה למפתחים ולצרכנים המיועדים של הפרויקטים האלה. מומלץ להוסיף משתמשים לקבוצה שמנוהלת על ידי ספק הזהויות הקיים, לסנכרן את הקבוצות עם Cloud Identity ואז להחיל תפקידי IAM על הקבוצות. חשוב לזכור תמיד את העיקרון של הרשאות מינימליות.
מומלץ גם להשתמש בכלי ההמלצות של IAM כדי לזהות מדיניות הרשאות שמעניקה תפקידים עם הרשאות עודפות. כדאי לתכנן תהליך לבדיקה תקופתית של ההמלצות או ליישום אוטומטי של ההמלצות בצינורות הפריסה.
שינויים בקואורדינטות בין צוות הרשת לצוות האפליקציה
טופולוגיות הרשת שפריסת התוכנית מתבססת עליהן מניחות שיש לכם צוות שאחראי על ניהול משאבי הרשת, וצוותים נפרדים שאחראים על פריסת משאבי תשתית של עומסי עבודה. כשצוותי עומסי העבודה פורסים תשתית, הם צריכים ליצור כללי חומת אש כדי לאפשר את נתיבי הגישה המיועדים בין רכיבים של עומס העבודה שלהם, אבל אין להם הרשאה לשנות את מדיניות חומת האש בין רשתות עצמה.
תכננו איך הצוותים יעבדו יחד כדי לתאם את השינויים במשאבי הרשת המרכזיים שנדרשים לפריסת האפליקציות. לדוגמה, אפשר לתכנן תהליך שבו צוות של עומסי עבודה מבקש תגים לאפליקציות שלו. לאחר מכן, צוות הרשת יוצר את התגים ומוסיף כללים למדיניות חומת אש בין רשתות שמאפשרים תנועה בין משאבים עם התגים, ומקצה לצוות של עומסי העבודה תפקידי IAM לשימוש בתגים.
אופטימיזציה של הסביבה באמצעות חבילת Active Assist
בנוסף לשירות ההמלצות בנושא IAM, Google Cloud מספקת את חבילת השירותים Active Assist כדי לתת המלצות לגבי אופטימיזציה של הסביבה שלכם. לדוגמה, תובנות לגבי חומת האש או שירות המלצות לגבי פרויקטים שאינם בשימוש מספקים המלצות פרקטיות שיכולות לעזור לכם לשפר את מצב האבטחה.
כדאי לתכנן תהליך לבדיקה תקופתית של ההמלצות או ליישום אוטומטי של ההמלצות בצינורות הפריסה. מחליטים אילו המלצות ינוהלו על ידי צוות מרכזי ואילו יהיו באחריות הבעלים של עומסי העבודה, ומקצים תפקידי IAM כדי לגשת להמלצות בהתאם.
איך מעניקים חריגות ממדיניות הארגון
תוכנית הבסיס אוכפת קבוצה של מגבלות של מדיניות הארגון, שמומלצות לרוב הלקוחות ברוב התרחישים, אבל יכול להיות שיש לכם תרחישי שימוש לגיטימיים שמחייבים חריגים מוגבלים למדיניות הארגון שאתם אוכפים באופן נרחב.
לדוגמה, התוכנית מחייבת את האילוץ iam.disableServiceAccountKeyCreation. האילוץ הזה הוא אמצעי בקרה חשוב לאבטחה, כי מפתח של חשבון שירות שדלף עלול לגרום להשפעה שלילית משמעותית, וברוב התרחישים מומלץ להשתמש בחלופות מאובטחות יותר למפתחות של חשבונות שירות לצורך אימות. עם זאת, יכולים להיות תרחישי שימוש שבהם אפשר לבצע אימות רק באמצעות מפתח של חשבון שירות, כמו שרת מקומי שנדרשת לו גישה לשירותיGoogle Cloud ושאי אפשר להשתמש בו באיחוד שירותי אימות הזהות של עומסי עבודה. בתרחיש כזה, יכול להיות שתחליטו לאפשר חריגה מהמדיניות, כל עוד נאכפים אמצעי בקרה נוספים מפצים, כמו שיטות מומלצות לניהול מפתחות של חשבונות שירות.
לכן, כדאי לתכנן תהליך שבו עומסי עבודה יכולים לבקש חריג ממדיניות, ולוודא שלמקבלי ההחלטות שאחראים על אישור חריגים יש את הידע הטכני כדי לאמת את תרחיש השימוש ולהתייעץ לגבי הצורך באמצעי בקרה נוספים. כשמעניקים חריג לעומס עבודה, צריך לשנות את האילוץ של מדיניות הארגון בצורה הכי מצומצמת שאפשר. אפשר גם להוסיף מגבלות למדיניות הארגון בתנאים. כדי לעשות את זה, מגדירים תג שמעניק חריגה או אכיפה למדיניות, ואז מחילים את התג על פרויקטים ותיקיות.
הגנה על המשאבים באמצעות VPC Service Controls
התוכנית עוזרת להכין את הסביבה ל-VPC Service Controls על ידי אכיפת הגדרות של דרישות מוקדמות, כמו כתובת ה-VIP המוגבלת. עם זאת, התוכנית פורסת את VPC Service Controls בהתחלה רק במצב הרצה יבשה, כי המעבר למצב אכיפה עלול להיות תהליך משבש שדורש תכנון ייחודי לארגון שלכם.
גבולות גזרה מונעים גישה לשירותים מוגבלים מתעבורת נתונים שמקורה מחוץ לגבולות הגזרה, כולל המסוף, תחנות עבודה של מפתחים ופייפליין בסיסי שמשמש לפריסת משאבים. אם אתם משתמשים ב-VPC Service Controls, עליכם לתכנן חריגים לגבולות הגזרה שיאפשרו את נתיבי הגישה שאתם רוצים. Google Cloud
הגדרת אזור ב-VPC Service Controls נועדה לשליטה בזליגת נתונים בין Google Cloud הארגון שלכם לבין מקורות חיצוניים. גבולות הגזרה לא נועדו להחליף או לשכפל את מדיניות ההרשאות לשליטה בבקרת גישה מפורטת לפרויקטים או למשאבים ספציפיים. כשמתכננים ומעצבים גבולות גזרה, מומלץ להשתמש בגבולות גזרה משותפים ומאוחדים כדי לצמצם את התקורה של הניהול.
אם אתם צריכים לתכנן כמה גבולות גזרה כדי לשלוט באופן מדויק בתנועת הנתונים של השירותים בתוך Google Cloud הארגון, מומלץ להגדיר בבירור את האיומים שמטופלים על ידי מבנה מורכב יותר של גבולות גזרה, ואת נתיבי הגישה בין גבולות הגזרה שנדרשים לפעולות המיועדות.
כדי להטמיע את VPC Service Controls, צריך לבדוק את הדברים הבאים:
- אילו תרחישים לדוגמה דורשים VPC Service Controls.
- האם Google Cloud השירותים הנדרשים תומכים ב-VPC Service Controls.
- איך מגדירים גישת Breakglass כדי לשנות את ההיקף במקרה של שיבוש בצינורות האוטומציה.
- איך משתמשים בשיטות המומלצות להפעלת VPC Service Controls כדי לתכנן ולהטמיע את גבולות הגזרה.
אחרי שמשנים את גבולות הגזרה ממצב הרצת בדיקה למצב אכיפה, מומלץ לתכנן תהליך להוספה עקבית של פרויקטים חדשים לגבולות הגזרה הנכונים, ותהליך לתכנון חריגים כשמפתחים נתקלים בתרחיש שימוש חדש שנדחה על ידי הגדרת גבולות הגזרה הנוכחית.
בדיקת שינויים בכל הארגון בארגון נפרד
מומלץ אף פעם לא לפרוס שינויים בסביבת ייצור בלי לבדוק אותם. במשאבי עומס עבודה, הגישה הזו מתאפשרת באמצעות סביבות נפרדות לפיתוח, לסביבה ללא ייצור ולייצור. עם זאת, לחלק מהמשאבים בארגון אין סביבות נפרדות שיאפשרו בדיקה.
אם אתם רוצים לבצע שינויים ברמת הארגון, או שינויים אחרים שיכולים להשפיע על סביבות ייצור, כמו ההגדרה בין ספק הזהויות לבין Cloud Identity, כדאי ליצור ארגון נפרד למטרות בדיקה.
שליטה בגישה מרחוק למכונות וירטואליות
אנחנו ממליצים לפרוס תשתית בלתי משתנה באמצעות צינורות העברת הנתונים של השכבה הבסיסית, התשתית והאפליקציה, ולכן אנחנו ממליצים גם להעניק למפתחים גישה ישירה למכונה וירטואלית באמצעות SSH או RDP רק לתרחישי שימוש מוגבלים או חריגים.
בתרחישים שבהם נדרשת גישה מרחוק, מומלץ לנהל את גישת המשתמשים באמצעות OS Login, אם אפשר. בגישה הזו נעשה שימוש בשירותים מנוהלים כדי לאכוף בקרת גישה, ניהול מחזור החיים של החשבון, אימות דו-שלבי ורישום ביומן ביקורת. Google Cloud לחלופין, אם אתם חייבים לאפשר גישה באמצעות מפתחות SSH במטא-נתונים או פרטי כניסה ל-RDP, באחריותכם לנהל את מחזור החיים של פרטי הכניסה ולאחסן אותם בצורה מאובטחת מחוץ ל- Google Cloud.
בכל תרחיש, משתמש עם גישת SSH או RDP למכונה וירטואלית עלול להוות סיכון להרחבת הרשאות, ולכן חשוב לתכנן את מודל הגישה בהתאם. המשתמש יכול להריץ קוד במכונה הווירטואלית עם ההרשאות של חשבון השירות המשויך, או לשלוח שאילתה לשרת המטא-נתונים כדי לראות את אסימון הגישה שמשמש לאימות בקשות API. הגישה הזו עלולה להוביל להרחבת הרשאות אם לא התכוונתם שהמשתמש יפעל עם ההרשאות של חשבון השירות.
איך מצמצמים חריגה מהתקציב באמצעות תכנון התראות לגבי תקציב
התוכנית מיישמת שיטות מומלצות שמוצגות ב-Google Cloud Well-Architected Framework: הוזלת העלויות לניהול עלויות, כולל:
שימוש בחשבון יחיד לחיוב בכל הפרויקטים ב-Enterprise Foundation.
מקצים לכל פרויקט תווית מטא-נתונים של
billingcodeשמשמשת להקצאת עלויות בין מרכזי עלות.הגדרת תקציבים ורמות סף להתראות.
באחריותכם לתכנן תקציבים ולהגדיר התראות על חיוב. התוכנית יוצרת התראות לגבי התקציב לפרויקטים של עומסי עבודה כשההוצאות החזויות צפויות להגיע ל-120% מהתקציב. הגישה הזו מאפשרת לצוות מרכזי לזהות אירועים של הוצאות גבוהות מדי ולצמצם אותם. עלייה משמעותית ובלתי צפויה בהוצאות ללא סיבה ברורה יכולה להצביע על אירוע אבטחה, ולכן כדאי לבדוק את העלייה הזו מנקודת מבט של בקרת עלויות וגם של אבטחה.
בהתאם לתרחיש השימוש, יכול להיות שתגדירו תקציב שמבוסס על העלות של תיקיית סביבה שלמה, או של כל הפרויקטים שקשורים למרכז עלויות מסוים, במקום להגדיר תקציבים פרטניים לכל פרויקט. מומלץ גם להעביר את ההרשאה להגדרת התקציב וההתראות לבעלי עומסי העבודה, שיכולים להגדיר סף התראה מפורט יותר לצורך מעקב יומיומי.
המלצות לאופטימיזציה של העלויות זמינות במאמר אופטימיזציה של העלויות באמצעות FinOps Hub.
הקצאת עלויות בין מרכזי עלות פנימיים
במסוף אפשר לראות את דוחות החיוב כדי להציג ולחזות את העלויות בכמה מימדים. בנוסף לדוחות המוכנים מראש, מומלץ לייצא את נתוני החיוב למערך נתונים ב-BigQuery בפרויקט prj-c-billing-export. רשומות החיוב המיוצאות מאפשרות להקצות עלויות למאפיינים מותאמים אישית, כמו מרכזי עלויות פנימיים, על סמך מטא נתונים של תוויות פרויקט כמו billingcode.
שאילתת ה-SQL הבאה היא שאילתה לדוגמה להבנת העלויות של כל הפרויקטים שמקובצים לפי billingcode תווית הפרויקט.
#standardSQL
SELECT
(SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
service.description AS description,
SUM(cost) AS charges,
SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC
הוראות להגדרת הייצוא מופיעות במאמר בנושא ייצוא נתוני החיוב ב-Cloud ל-BigQuery.
אם אתם צריכים הנהלת חשבונות פנימית או החזר כספי בעקבות ביטול עסקה בין מרכזי עלויות, אתם אחראים לשלב את הנתונים שמתקבלים מהשאילתה הזו בתהליכים הפנימיים שלכם.
הוספת ממצאים מאמצעי בקרה לזיהוי איומים למערכת SIEM קיימת
אף על פי שהמשאבים הבסיסיים עוזרים לכם להגדיר יעדים מצטברים ליומני ביקורת ולממצאי אבטחה, באחריותכם להחליט איך להשתמש באותות האלה.
אם יש לכם דרישה לצבירת יומנים בכל סביבות הענן והסביבות המקומיות בכלי SIEM קיים, אתם צריכים להחליט איך להטמיע יומנים מprj-c-logging הפרויקט וממצאי Security Command Center בכלים ובתהליכים הקיימים. אתם יכולים ליצור ייצוא יחיד לכל היומנים והממצאים אם צוות אחד אחראי על מעקב אחר האבטחה בכל הסביבה, או ליצור כמה ייצואים שמסוננים לפי קבוצת היומנים והממצאים שנדרשים לכמה צוותים עם אחריות שונה.
לחלופין, אם נפח היומנים והעלות גבוהים מדי, אפשר להימנע משכפול על ידי שמירת Google Cloud היומנים והממצאים רק ב-Google Cloud. במקרה כזה, חשוב לוודא שלצוותים הקיימים יש את הגישה וההכשרה הנכונות לעבודה עם היומנים והממצאים ישירות ב-Google Cloud.
- במקרה של יומני ביקורת, כדאי לעצב תצוגות יומנים כדי להעניק גישה לקבוצת משנה של יומנים בדלי יומנים מרכזי לצוותים ספציפיים, במקום לשכפל יומנים לכמה דליים, מה שמגדיל את עלות האחסון של היומנים.
- לממצאים בנושא אבטחה, צריך להעניק תפקידים ברמת התיקייה וברמת הפרויקט ל-Security Command Center כדי לאפשר לצוותים לצפות בממצאים בנושא אבטחה ולנהל אותם רק בפרויקטים שהם אחראים להם, ישירות במסוף.
פיתוח מתמשך של ספריית אמצעי הבקרה
התוכנית מתחילה עם קו בסיס של אמצעי בקרה לזיהוי איומים ולמניעתם. מומלץ לעיין באמצעי הבקרה האלה ולהוסיף עוד אמצעי בקרה בהתאם לדרישות שלכם. בטבלה הבאה מפורטים המנגנונים לאכיפת מדיניות ניהול, ומוסבר איך להרחיב אותם כדי לעמוד בדרישות נוספות:
| אמצעי בקרה על מדיניות שנאכפים על ידי התוכנית | הנחיות להרחבת אמצעי הבקרה האלה |
|---|---|
ב-Security Command Center מתבצע זיהוי של נקודות חולשה ואיומים ממקורות אבטחה שונים. | הגדרת מודולים מותאמים אישית ל-Security Health Analytics ומודולים מותאמים אישית ל-Event Threat Detection. |
השירות של מדיניות הארגון אוכף קבוצה מומלצת של אילוצים של מדיניות הארגון בשירותיGoogle Cloud . |
אפשר לאכוף אילוצים נוספים מתוך רשימת האילוצים הזמינים או ליצור אילוצים בהתאמה אישית. |
מדיניות Open Policy Agent (OPA) מאמתת קוד בצינור הנתונים של הפלטפורמה כדי לוודא שההגדרות מקובלות לפני הפריסה. | מפתחים אילוצים נוספים על סמך ההנחיות בכתובת GoogleCloudPlatform/policy-library. |
התראות על מדדים מבוססי-יומנים ומדדי ביצועים מגדירות מדדים מבוססי-יומנים כדי לשלוח התראות על שינויים במדיניות IAM ובהגדרות של חלק מהמשאבים הרגישים. | עיצוב מדדים נוספים מבוססי-יומן ומדיניות התראות לאירועים ביומן שלא צפויים להתרחש בסביבה שלכם. |
פתרון מותאם אישית לניתוח אוטומטי של יומנים שבודק בקביעות את היומנים כדי לאתר פעילות חשודה ויוצר ממצאים ב-Security Command Center. |
כותבים שאילתות נוספות כדי ליצור ממצאים לאירועי אבטחה שרוצים לעקוב אחריהם, באמצעות ניתוח יומני אבטחה כהפניה. |
פתרון מותאם אישית לתגובה לשינויים בנכסים יוצר ממצאים ב-Security Command Center ויכול להפוך פעולות תיקון לאוטומטיות. | יוצרים פידים נוספים של מאגר משאבי ענן כדי לעקוב אחרי שינויים בסוגי נכסים מסוימים, וכותבים פונקציות נוספות של Cloud Run עם לוגיקה מותאמת אישית כדי להגיב להפרות מדיניות. |
יכול להיות שאמצעי הבקרה האלה ישתנו בהתאם לדרישות ולרמת הבשלות שלכם ב-Google Cloud .
ניהול מפתחות הצפנה באמצעות Cloud Key Management Service
Google Cloud מספק הצפנה במנוחה כברירת מחדל לכל תוכן הלקוחות, אבל מספק גם את Cloud Key Management Service (Cloud KMS) כדי לתת לכם שליטה נוספת על מפתחות ההצפנה של הנתונים באחסון. מומלץ לבדוק אם ההצפנה שמוגדרת כברירת מחדל מספיקה, או אם יש לכם דרישת תאימות שאתם צריכים להשתמש ב-Cloud KMS כדי לנהל את המפתחות בעצמכם. מידע נוסף זמין במאמר איך מחליטים איך לעמוד בדרישות התאימות להצפנה במנוחה.
תוכנית ה-Blueprint מספקת prj-c-kms פרויקט בתיקייה המשותפת וprj-{env}-kms פרויקט בכל תיקיית סביבה לניהול מרכזי של מפתחות הצפנה. הגישה הזו מאפשרת לצוות מרכזי לבצע ביקורת ולנהל מפתחות הצפנה שמשמשים משאבים בפרויקטים של עומסי עבודה, כדי לעמוד בדרישות רגולטוריות ובדרישות תאימות.
בהתאם למודל התפעולי שלכם, יכול להיות שתעדיפו מופע פרויקט מרכזי יחיד של Cloud KMS שנמצא בשליטה של צוות אחד, או שתעדיפו לנהל את מפתחות ההצפנה בנפרד בכל סביבה, או שתעדיפו כמה מופעים מבוזרים כדי שאפשר יהיה להעביר את האחריות על מפתחות ההצפנה לצוותים המתאימים. אפשר לשנות את דוגמת הקוד של Terraform לפי הצורך כדי להתאים אותה למודל התפעולי שלכם.
אפשר גם לאכוף מדיניות ארגון בנושא מפתחות הצפנה בניהול הלקוח (CMEK) כדי לוודא שסוגים מסוימים של משאבים תמיד ידרשו מפתח CMEK, ושאפשר להשתמש רק במפתחות CMEK מרשימת היתרים של פרויקטים מהימנים.
אחסון פרטי כניסה של אפליקציות וביקורת שלהם באמצעות Secret Manager
מומלץ אף פעם לא לשמור סודות רגישים (כמו מפתחות API, סיסמאות ואישורים פרטיים) במאגרי קוד מקור. במקום זאת, צריך להוסיף את הסוד ל-Secret Manager ולהקצות למשתמש או לחשבון השירות שצריכים לגשת לסוד את תפקיד ה-IAM Secret Manager Secret Accessor. מומלץ להקצות את תפקיד ה-IAM לסוד ספציפי, ולא לכל הסודות בפרויקט.
כשזה אפשרי, כדאי ליצור סודות ייצור באופן אוטומטי בצינורות CI/CD ולשמור אותם כך שמשתמשים אנושיים לא יוכלו לגשת אליהם, אלא במקרים של breakglass. במקרה כזה, חשוב לוודא שלא נותנים תפקידי IAM לצפייה בסודות האלה למשתמשים או לקבוצות.
תוכנית ה-Blueprint מספקת פרויקט prj-c-secrets אחד בתיקייה המשותפת ופרויקט prj-{env}-secrets אחד בכל תיקיית סביבה לניהול סודות באופן מרכזי. הגישה הזו מאפשרת לצוות מרכזי לבצע ביקורת ולנהל סודות שמשמשים אפליקציות כדי לעמוד בדרישות רגולטוריות ובדרישות תאימות.
בהתאם למודל התפעולי שלכם, יכול להיות שתעדיפו מופע מרכזי יחיד של Secret Manager בשליטה של צוות אחד, או שתעדיפו לנהל סודות בנפרד בכל סביבה, או שתעדיפו כמה מופעים מבוזרים של Secret Manager כדי שכל צוות של עומס עבודה יוכל לנהל את הסודות שלו. משנים את דוגמת הקוד של Terraform לפי הצורך כדי שתתאים למודל התפעולי שלכם.
תכנון גישת Breakglass לחשבונות עם הרשאות גבוהות
למרות שאנחנו ממליצים לנהל שינויים במשאבי הבסיס באמצעות IaC עם ניהול גרסאות שנפרס על ידי פייפליין הבסיס, יכול להיות שיהיו לכם תרחישים חריגים או מצבי חירום שידרשו גישה בעלת הרשאות מיוחדות כדי לשנות את הסביבה שלכם ישירות. אנחנו ממליצים לתכנן חשבונות breakglass (שנקראים לפעמים חשבונות firecall או חשבונות חירום) עם גישה בעלת הרשאות מיוחדות לסביבה שלכם למקרה חירום או אם תהליכי הפעולות האוטומטיות נכשלים.
בטבלה הבאה מתוארות כמה דוגמאות למטרות של חשבונות breakglass.
| מטרת השימוש ב-breakglass | תיאור |
|---|---|
משתמש-על | גישת חירום לתפקיד סופר-אדמין שמשמש עם Cloud Identity, למשל כדי לתקן בעיות שקשורות לאיחוד שירותי אימות הזהות או לאימות רב-גורמי (MFA). |
אדמין ארגוני |
גישת חירום לתפקיד אדמין ארגוני, שמאפשר לתת גישה לכל תפקיד אחר ב-IAM בארגון. |
אדמין של צינור עיבוד נתונים של Foundation | גישת חירום לשינוי המשאבים בפרויקט CICD ב-Google Cloud ובמאגר Git חיצוני, למקרה שהאוטומציה של צינור הנתונים הבסיסי נכשלת. |
Operations או SRE |
צוות תפעול או צוות SRE צריך הרשאות גישה מיוחדות כדי להגיב להפסקות שירות או לאירועים. זה יכול לכלול משימות כמו הפעלה מחדש של מכונות וירטואליות או שחזור נתונים. |
המנגנון שלכם למתן גישת חירום תלוי בכלים ובנהלים הקיימים, אבל הנה כמה דוגמאות למנגנונים כאלה:
- כדי להוסיף משתמש זמנית לקבוצה שמוגדרים בה מראש תפקידי IAM עם הרשאות גבוהות, או כדי להשתמש בפרטי הכניסה של חשבון עם הרשאות גבוהות, אפשר להשתמש בכלים הקיימים לניהול הרשאות גישה.
- הקצאת חשבונות מראש שמיועדים לשימוש אדמינסטרטיבי בלבד. לדוגמה, למפתחת דנה יכול להיות חשבון עם כתובת dana@example.com לשימוש יומיומי וחשבון עם כתובת admin-dana@example.com לגישה במקרה חירום.
- אפשר להשתמש באפליקציה כמו גישה עם הרשאות בדיוק בזמן, שמאפשרת למפתח להעניק לעצמו הרשאות גבוהות יותר.
לא משנה באיזה מנגנון תשתמשו, כדאי לחשוב איך תענו על השאלות הבאות:
- איך מתכננים את ההיקף והגרנולריות של גישת החירום? לדוגמה, אפשר לתכנן מנגנון שונה לגישת חירום ליחידות עסקיות שונות כדי לוודא שהן לא יכולות לשבש אחת את השנייה.
- איך המנגנון שלכם מונע שימוש לרעה? האם נדרשים אישורים? לדוגמה, יכול להיות שחילקתם את הפעולות כך שאדם אחד מחזיק באמצעי הזיהוי ואדם אחר מחזיק בטוקן של אימות רב-שלבי.
- איך מבצעים ביקורת על גישת breakglass ושולחים התראות לגביה? לדוגמה, אפשר להגדיר מודול מותאם אישית של Event Threat Detection כדי ליצור ממצא אבטחה כשנעשה שימוש בחשבון breakglass מוגדר מראש.
- איך מסירים את הגישה במקרה חירום וממשיכים בפעילות הרגילה אחרי שהאירוע מסתיים?
למשימות נפוצות של הרחבת הרשאות ולביטול שינויים, מומלץ לתכנן תהליכי עבודה אוטומטיים שבהם משתמש יכול לבצע את הפעולה בלי להרחיב את ההרשאות של זהות המשתמש שלו. הגישה הזו יכולה לעזור לצמצם טעויות אנוש ולשפר את האבטחה.
למערכות שדורשות התערבות קבועה, יכול להיות שהפתרון הכי טוב הוא אוטומציה של התיקון. Google ממליצה ללקוחות לאמץ גישה של אפס מגע בייצור כדי לבצע את כל השינויים בייצור באמצעות אוטומציה, פרוקסי בטוחים או breakglass שעבר ביקורת. Google מספקת את ספרי ה-SRE ללקוחות שרוצים לאמץ את גישת ה-SRE של Google.
המאמרים הבאים
- מומלץ לקרוא את המאמר פריסת התוכנית (המסמך הבא בסדרה).