במאמר הזה מפורטות המלצות שיעזרו לכם לשמור על גישה רציפה למשאבים ב- Google Cloud . המשכיות עסקית נועדה להבטיח שהארגון יוכל לשמור על פעולות חיוניות, גם במהלך שיבושים כמו הפסקות חשמל או אסונות. המטרה הזו כוללת גישה רציפה של העובדים גם כששירותים ותשתיות קריטיים לא זמינים.
המסמך הזה מיועד לאנשי מקצוע בתחום האבטחה או המהימנות שאחראים על ניהול הזהויות והרשאות הגישה (IAM) ועל תחזוקה של גישה מאובטחת אל Google Cloud. במסמך הזה אנחנו מניחים שאתם כבר מכירים את Cloud Identity, את Google Workspace ואת ניהול הזהויות והרשאות הגישה (IAM).
כדי לעזור לכם להתכונן להפסקות שירות ולהבטיח גישה רציפה, במסמך הזה מפורטים השלבים המומלצים שתוכלו ליישם. אתם יכולים לבצע את כל השלבים האלה או רק חלק מהם, אבל אנחנו ממליצים לבצע אותם בסדר הבא.
הגדרת גישת חירום: הפעלת גישה כמוצא אחרון למשאביGoogle Cloud .
מומלץ להגדיר גישת חירום לכלGoogle Cloud הארגונים, בלי קשר לדרישות שלכם להמשכיות עסקית.
מספקים חלופות לאימות למשתמשים קריטיים: אם בארגון שלכם משתמשים בכניסה יחידה (SSO), כל שיבוש שמשפיע על ספק הזהויות (IdP) החיצוני יכול להשפיע על היכולת של העובדים לבצע אימות ולהשתמש ב-Google Cloud.
כדי לצמצם את ההשפעה הכוללת של שיבוש ב-IdP על הארגון, צריך לספק חלופה לאימות למשתמשים שנדרשת להם גישה למשאבים קריטיים לעסק. Google Cloud
שימוש בספק זהויות לגיבוי: כדי לאפשר לכל המשתמשים לגשת למשאבים של Google Cloud ספק הזהויות במהלך שיבוש בשירות, אפשר להגדיר ספק זהויות לגיבוי.
ספק זהויות חלופי יכול לעזור למזער עוד יותר את ההשפעה של שיבוש, אבל האפשרות הזו לא תמיד משתלמת לכל ארגון.
בקטעים הבאים מפורטים השלבים המומלצים והשיטות המומלצות.
הגדרת גישה במקרה חירום
מטרת הגישה למקרה חירום היא לאפשר גישה למשאבים כמוצא אחרון, ולמנוע מצבים שבהם אתם עלולים לאבד את הגישה לחלוטין.Google Cloud
המאפיינים של משתמשים עם גישת חירום:
- אלה משתמשים שאתם יוצרים בחשבון Cloud Identity או בחשבון Google Workspace.
- יש להם הרשאת סופר-אדמין, שמאפשרת למשתמשים גישה מספקת לפתרון בעיות בהגדרות שמשפיעות על Cloud Identity, על Google Workspace או על משאביGoogle Cloud .
- הם לא משויכים לעובד ספציפי בארגון, והם לא כפופים למחזור החיים של חשבונות משתמש רגילים, שנקרא Joiner, Mover, and Leaver (JML).
- הם פטורים מ-SSO.
בקטעים הבאים מתוארות השיטות המומלצות לניהול משתמשים עם גישת חירום ולהגנה עליהם.
יצירת משתמשים עם גישת חירום לכל סביבה
בסביבות Google Cloud שמארחות עומסי עבודה של ייצור, גישת חירום היא קריטית. גם בסביבות שמשמשות למטרות בדיקה או להכנת אתר להשקה, אובדן גישה עלול לשבש את העבודה. Google Cloud
כדי להבטיח גישה רציפה לכל הסביבות, צריך ליצור ולתחזק משתמשים עם גישת חירום ב-Cloud Identity או ב-Google Workspace לכל סביבה. Google Cloud
בדיקה אם יש גישה חלופית למקרה חירום
משתמש יחיד עם גישת חירום הוא נקודת כשל בודדת. בתרחיש הזה, מפתח אבטחה פגום, סיסמה שאבדה או השעיה של החשבון עלולים לשבש את הגישה לחשבון. כדי לצמצם את הסיכון הזה, אתם יכולים ליצור יותר ממשתמש אחד עם גישת חירום לכל חשבון Cloud Identity או Google Workspace.
למשתמשים עם גישת חירום יש הרשאות גבוהות מאוד, לכן לא מומלץ ליצור יותר מדי משתמשים כאלה. לרוב הארגונים, אנחנו ממליצים להגדיר לפחות שני משתמשים עם גישת חירום ולכל היותר חמישה משתמשים כאלה לכל חשבון Cloud Identity או Google Workspace.
שימוש ביחידה ארגונית נפרדת למשתמשים עם גישת חירום
משתמשים עם גישת חירום דורשים הגדרה מיוחדת, והם לא כפופים למחזור החיים של JML שאולי אתם פועלים לפיו לגבי חשבונות משתמשים אחרים.
כדי להפריד בין משתמשים עם גישת חירום לבין חשבונות משתמשים רגילים, כדאי להשתמש ביחידה ארגונית ייעודית למשתמשים עם גישת חירום. יחידה ארגונית נפרדת מאפשרת להחיל הגדרות מותאמות אישית רק על משתמשים במצבי חירום.
שימוש במפתחות אבטחה מסוג FIDO לאימות דו-שלבי
שימוש במפתחות אבטחה מסוג Fast IDentity Online (FIDO) לאימות דו-שלבי.
משתמשי גישת חירום הם משתמשים עם הרשאות גבוהות מאוד בחשבון Cloud Identity או Google Workspace שלכם, ולכן אתם צריכים להגן עליהם באמצעות אימות דו-שלבי.
בין שיטות האימות הדו-שלבי שנתמכות ב-Cloud Identity וב-Google Workspace, מומלץ להשתמש במפתחות אבטחה של FIDO. השיטה הזו מספקת הגנה מפני פישינג ואבטחה חזקה. כדי לוודא שכל המשתמשים עם גישת חירום משתמשים במפתחות אבטחה מסוג FIDO לאימות דו-שלבי, צריך לבצע את הפעולות הבאות:
- ביחידה הארגונית שמכילה את המשתמשים עם גישת חירום, מגדירים אימות דו-שלבי כך שמפתחות אבטחה יהיו שיטת האימות היחידה.
- מפעילים אימות דו-שלבי לכל המשתמשים עם גישת חירום.
- לכל משתמש עם גישת חירום, צריך לרשום שני מפתחות אבטחה או יותר שתואמים ל-FIDO.
כשרושמים כמה מפתחות לכל משתמש, מצמצמים את הסיכון לאובדן גישה בגלל מפתח אבטחה מקולקל. בנוסף, אתם מגדילים את הסיכוי שהמשתמש יוכל לגשת לפחות לאחד מהמפתחות במקרה חירום.
מותר להשתמש באותה קבוצה של מפתחות אבטחה לכמה משתמשים עם גישת חירום. עם זאת, מומלץ להשתמש במפתחות אבטחה שונים לכל משתמש עם גישת חירום.
שימוש באמצעי בקרה פיזיים לאבטחה כדי להגן על פרטי הכניסה ומפתחות האבטחה
כשמאחסנים את פרטי הכניסה ומפתחות האבטחה של משתמשים עם גישת חירום, צריך לאזן בין הגנה חזקה לבין זמינות בזמן חירום:
- למנוע מאנשים לא מורשים לגשת לפרטי הכניסה של משתמשי גישת חירום. משתמשים עם גישת חירום צריכים להשתמש בפרטי הכניסה האלה רק במקרה חירום.
- חשוב לוודא שלצוות מורשה תהיה גישה לפרטי הכניסה עם עיכוב מינימלי במקרה חירום.
אנחנו ממליצים לא להסתמך על מנהל סיסמאות מבוסס תוכנה. במקום זאת, מומלץ להסתמך על אמצעי אבטחה פיזיים כדי להגן על פרטי הכניסה ומפתחות האבטחה של משתמשים עם גישת חירום.
כשבוחרים אילו אמצעי בקרה פיזיים להחיל, כדאי לקחת בחשבון את הנקודות הבאות:
- שיפור הזמינות:
- אחסון עותקים של סיסמאות בכמה מיקומים פיזיים, למשל בכמה כספות מאובטחות במשרדים שונים.
- מומלץ לרשום כמה מפתחות אבטחה לכל משתמש עם גישת חירום, ולאחסן מפתח אחד בכל מיקום משרדי רלוונטי.
- שיפור האבטחה: אחסון הסיסמה ומפתחות האבטחה במיקומים שונים.
הימנעות מאוטומציה של החלפת סיסמאות
יכול להיות שייראה לכם מועיל להפוך את הרוטציה של הסיסמאות לאוטומטית עבור משתמשים עם גישת חירום. עם זאת, האוטומציה הזו עלולה להגדיל את הסיכון לפגיעה באבטחה. למשתמשים עם גישת חירום יש הרשאות סופר-אדמין. כדי להחליף את הסיסמה של משתמש עם הרשאת סופר-אדמין, גם לכלי אוטומציה או לתסריטים צריכות להיות הרשאות סופר-אדמין. הדרישה הזו יכולה להפוך את הכלים למטרות אטרקטיביות לתוקפים.
כדי לא לפגוע ברמת האבטחה הכוללת, אל תשתמשו בפעולות אוטומטיות כדי להחליף את הסיסמאות.
שימוש בסיסמאות חזקות
כדי להגן על משתמשים עם גישת חירום, חשוב לוודא שהם משתמשים בסיסמה ארוכה וחזקה. כדי לאכוף רמת מורכבות מינימלית של סיסמאות, משתמשים ביחידה ארגונית ייעודית כמו שמתואר למעלה, ומטמיעים דרישות לסיסמאות.
אלא אם אתם מבצעים רוטציה של הסיסמאות באופן ידני, אתם צריכים להשבית את תפוגת הסיסמאות לכל המשתמשים עם גישת חירום.
איך מוציאים משתמש עם גישת חירום ממדיניות הגישה
במהלך מצב חירום, מדיניות של בקרת גישה מבוססת-הקשר עלולה לגרום למצב שבו אפילו משתמש עם גישת חירום לא יכול לגשת למשאבים מסוימים. כדי לצמצם את הסיכון הזה, צריך להחריג לפחות משתמש אחד עם גישת חירום מכל רמות הגישה במדיניות הגישה.
הפטורים האלה עוזרים לוודא שלפחות לאחד מהמשתמשים עם גישת חירום יש גישה רציפה למשאבים. במקרה חירום או אם מדיניות בקרת הגישה מבוססת-הקשר לא מוגדרת בצורה נכונה, משתמשים עם גישת חירום יכולים לשמור על הגישה שלהם.
הגדרת התראות על אירועים של משתמשים עם גישת חירום
פעילות משתמש עם גישת חירום שלא קשורה לאירוע חירום, כנראה מצביעה על התנהגות חשודה. כדי לקבל התראה על אירועים שקשורים לפעילות של משתמשים עם גישת חירום, צריך ליצור כלל דיווח במסוף Google Admin. כשיוצרים כלל דיווח, אפשר להגדיר תנאים כמו:
- מקור נתונים: אירועים ביומן משתמשים.
מאפיינים בכרטיסייה הכלי להגדרת תנאים: משתמשים במאפיינים ובאופרטורים כדי ליצור מסנן ליחידה הארגונית שמכילה את המשתמשים עם גישת חירום ואת האירועים.
לדוגמה, אפשר להגדיר מאפיינים ואופרטורים כדי ליצור מסנן שדומה למשפטי התנאי הבאים:
Actor organizational unit Is /Privileged AND (Event Is Successful login OR Event Is Failed login OR Event Is Account password change)סף: כל שעה, אם הספירה > 0
פעולה: שליחת התראות באימייל
נמעני אימייל: בוחרים קבוצה שמכילה את החברים הרלוונטיים בצוות האבטחה
מתן חלופות לאימות למשתמשים קריטיים
אם הארגון שלכם משתמש ב-SSO כדי לאפשר לעובדים לבצע אימות לשירותי Google, הזמינות של ה-IdP מצד שלישי הופכת לקריטית. כל שיבוש ב-IdP עלול למנוע מהעובדים גישה לכלים ולמשאבים חיוניים.
גישת חירום עוזרת להבטיח גישת אדמין רציפה, אבל היא לא נותנת מענה לצרכים של העובדים במהלך הפסקה זמנית בשירות של ספק הזהויות.
כדי לצמצם את ההשפעה הפוטנציאלית של שיבוש ב-IdP, אתם יכולים להגדיר בחשבון Cloud Identity או Google Workspace שלכם חלופה לאימות עבור משתמשים קריטיים. אפשר להשתמש בתוכנית הגיבוי הבאה:
- במהלך פעולות רגילות, אתם מאפשרים למשתמשים לבצע אימות באמצעות כניסה יחידה (SSO).
- במהלך הפסקה זמנית בשירות של IdP, אתם יכולים להשבית באופן סלקטיבי את ה-SSO למשתמשים הקריטיים האלה ולאפשר להם לבצע אימות באמצעות פרטי הכניסה לחשבון Google שסיפקתם מראש.
בקטעים הבאים מתוארות השיטות המומלצות כשמאפשרים למשתמשים קריטיים לבצע אימות במהלך הפסקות זמניות בשירות של IdP חיצוני.
התמקדות במשתמשים עם הרשאות
כדי שמשתמשים קריטיים יוכלו לעבור אימות במהלך הפסקה זמנית בשירות של IdP, צריכים להיות להם פרטי כניסה תקפים לחשבון Google, כמו:
- סיסמה עם מפתח אבטחה לאימות דו-שלבי.
- מפתח גישה.
כשמקצים פרטי כניסה לחשבון Google למשתמשים שבדרך כלל משתמשים ב-SSO, יכול להיות שתגדילו את העומס התפעולי ואת החיכוך עם המשתמשים בדרכים הבאות:
- יכול להיות שלא תוכלו לסנכרן את סיסמאות המשתמשים באופן אוטומטי, בהתאם ל-IdP שלכם. לכן, יכול להיות שתצטרכו לבקש מהמשתמשים להגדיר סיסמה באופן ידני.
- יכול להיות שתצטרכו לבקש מהמשתמשים לרשום מפתח גישה או להירשם לאימות דו-שלבי. בדרך כלל לא צריך לבצע את השלב הזה למשתמשי SSO.
כדי לאזן בין היתרונות של גישה רציפה לשירותי Google לבין התקורה הנוספת, מומלץ להתמקד במשתמשים בעלי הרשאות ובמשתמשים שחיוניים לעסק. המשתמשים האלה צפויים להפיק תועלת משמעותית מגישה רציפה, והם עשויים להיות רק חלק קטן מבסיס המשתמשים הכולל שלכם.
כדאי לנצל את ההזדמנות כדי להפעיל אימות אחרי כניסה יחידה
כשמקצים אימות חלופי למשתמשים עם הרשאות מיוחדות, יכול להיות שיווצר עומס נוסף. כדי לקזז את התקורה הזו, אתם יכולים גם להפעיל אימות אחרי SSO למשתמשים האלה.
כברירת מחדל, כשמגדירים כניסה יחידה למשתמשים, הם לא נדרשים לבצע אימות דו-שלבי. למרות שהשיטה הזו נוחה, אם ה-IdP נפגע, כל משתמש שלא הפעיל אימות אחרי SSO יכול להפוך למטרה של מתקפות זיוף פרטי כניסה.
אימות לאחר SSO עוזר לצמצם את ההשפעה האפשרית של פריצה ל-IdP, כי המשתמשים צריכים לבצע אימות דו-שלבי אחרי כל ניסיון SSO. אם אתם מקצים פרטי כניסה ל-Google למשתמשים עם הרשאות מיוחדות, אימות אחרי כניסה באמצעות SSO יכול לעזור לשפר את רמת האבטחה של חשבונות המשתמשים האלה בלי להוסיף עומס.
שימוש ביחידה ארגונית נפרדת למשתמשים עם הרשאות מיוחדות
משתמשים עם הרשאות מיוחדות שיכולים לבצע אימות במהלך הפסקות זמניות בשירות של ספק זהויות חיצוני, צריכים הגדרה מיוחדת. ההגדרה הזו שונה מההגדרה של משתמשים רגילים ושל משתמשים עם גישת חירום.
כדי להפריד בין משתמשים עם הרשאות לבין חשבונות משתמשים אחרים, כדאי להשתמש ביחידה ארגונית ייעודית למשתמשים עם הרשאות. יחידה ארגונית נפרדת מאפשרת להחיל מדיניות מותאמת אישית, כמו אימות אחרי כניסה יחידה (SSO), רק על המשתמשים המורשים האלה.
יחידה ארגונית נפרדת גם עוזרת להשבית באופן סלקטיבי את SSO למשתמשים עם הרשאות מיוחדות במהלך הפסקה זמנית בשירות של IdP. כדי להשבית את ה-SSO ליחידה הארגונית, אפשר לשנות את ההקצאות של פרופיל ה-SSO.
שימוש ב-IdP חלופי
כשמספקים חלופות לאימות למשתמשים קריטיים במהלך הפסקות זמניות בשירות של IdP, עוזרים לצמצם את ההשפעה של הפסקת השירות הזו על הארגון. עם זאת, יכול להיות שאסטרטגיית ההפחתה הזו לא תספיק כדי לשמור על יכולת תפעול מלאה. יכול להיות שהרבה משתמשים עדיין לא יוכלו לגשת לאפליקציות ולשירותים חיוניים.
כדי לצמצם עוד יותר את ההשפעה הפוטנציאלית של הפסקה זמנית בשירות של IdP, אפשר לבצע מעבר לגיבוי של IdP. אפשר להשתמש בתוכנית הגיבוי הבאה:
- במהלך פעולות רגילות, אתם מאפשרים למשתמשים לבצע אימות באמצעות כניסה יחידה (SSO) וספק הזהויות הראשי שלכם.
- במהלך הפסקת פעילות של ספק הזהויות, אתם משנים את הגדרת ה-SSO בחשבון Cloud Identity או Google Workspace כדי לעבור לספק הזהויות לגיבוי.
ספק ה-IdP של הגיבוי לא חייב להיות אותו ספק. כשיוצרים ספק זהויות לגיבוי, צריך להשתמש בהגדרה שתואמת להגדרה של ספק הזהויות הראשי. כדי לוודא ש-IdP הגיבוי מאפשר לכל המשתמשים לבצע אימות ולגשת לשירותי Google, IdP הגיבוי צריך להשתמש בעותק עדכני של בסיס המשתמשים של IdP הראשי.
ספק זהויות לגיבוי יכול לעזור לספק גישה מקיפה למקרה חירום. עם זאת, חשוב לשקול את היתרונות האלה מול הסיכונים הנוספים שספק זהות לגיבוי עלול להוסיף. הסיכונים האפשריים האלה כוללים:
- אם לאמצעי הזיהוי המשני יש אבטחה חלשה יותר מאמצעי הזיהוי הראשי, יכול להיות שרמת האבטחה הכוללת של סביבת Google Cloud העבודה שלכם תהיה חלשה יותר במהלך מעבר לגיבוי.
- אם יש הבדל בין ספק הזהויות הראשי לבין ספק הזהויות לגיבוי בדרך שבה הם מנפיקים הצהרות SAML, יכול להיות שספק הזהויות יסכן את המשתמשים בהתקפות זיוף.
בקטעים הבאים מתוארות שיטות מומלצות לשימוש ב-IdP גיבוי לגישה למקרה חירום.
יצירת פרופיל SAML נפרד לספק הזהויות לגיבוי
ב-Cloud Identity וב-Google Workspace אפשר ליצור כמה פרופילי SAML. כל פרופיל SAML יכול להתייחס ל-SAML IdP אחר.
כדי לצמצם את כמות העבודה שנדרשת למעבר ל-IdP לגיבוי, צריך להכין מראש פרופיל SAML עבור ה-IdP לגיבוי:
- יוצרים פרופילי SAML נפרדים לספק הזהויות הראשי ולספק הזהויות לגיבוי.
- מגדירים הקצאות של פרופילי SSO כדי להקצות רק את פרופיל ה-SAML של ספק הזהויות הראשי במהלך פעולות רגילות.
- לשנות את ההקצאות של פרופיל ה-SSO כדי להשתמש בפרופיל ה-SAML של ה-IdP לגיבוי במהלך הפסקה זמנית בשירות של IdP. אל תשנו את ההגדרות של פרופיל ה-SAML הספציפי.
שימוש בספק זהויות מקומי קיים
אין צורך להקצות ספק זהויות נוסף שישמש כגיבוי. במקום זאת, בודקים אם אפשר להשתמש ב-IdP קיים מקומי למטרה הזו. לדוגמה, יכול להיות שהארגון שלכם משתמש ב-Active Directory כמקור המוסמך לזהויות, וגם משתמש ב-Active Directory Federation Services (AD FS) ל-SSO. בתרחיש הזה, יכול להיות שאפשר להשתמש ב-AD FS כספק הגיבוי של הזהויות.
הגישה הזו של שימוש חוזר יכולה לעזור לכם להגביל את העלויות ואת הוצאות התקורה של התחזוקה.
הכנת ספק ה-IdP לגיבוי לטיפול בעומס הנדרש
כשמעבירים את האימות ל-IdP הגיבוי, הוא צריך לטפל בכל בקשות האימות שבדרך כלל מטופלות על ידי ה-IdP הראשי.
כשפורסים ספק זהויות לגיבוי וקובעים את הגודל שלו, חשוב לזכור שמספר הבקשות הצפויות תלוי בגורמים הבאים:
- מספר המשתמשים בחשבון Cloud Identity או בחשבון Google Workspace.
- Google Cloud משך הסשן שהוגדר.
לדוגמה, אם משך הסשן הוא בין 8 ל-24 שעות, יכול להיות שיהיה זינוק בבקשות האימות בשעות הבוקר, כשהעובדים מתחילים את יום העבודה.
בדיקה תקופתית של תהליך המעבר לגיבוי (failover)
כדי לוודא שתהליך יתירות הכשל של ה-SSO פועל בצורה מהימנה, צריך לאמת את התהליך באופן תקופתי. כשבודקים את תהליך המעבר לגיבוי, מבצעים את הפעולות הבאות:
- לשנות באופן ידני את הקצאת פרופיל ה-SSO של יחידה ארגונית אחת או יותר או של קבוצה אחת או יותר כדי להשתמש ב-IdP לגיבוי.
- מוודאים שכניסת ה-SSO עם ספק ה-IdP לגיבוי פועלת כצפוי.
- מוודאים שאישורי החתימה מעודכנים.
המאמרים הבאים
- מומלץ לעיין בשיטות המומלצות לשמירה על אבטחה בחשבונות של אדמינים.
- מידע נוסף על שיטות מומלצות לאיחוד Google Cloud עם ספק זהויות חיצוני
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Johannes Passing | Cloud Solutions Architect
תורם נוסף: Ido Flatow | Cloud Solutions Architect