במאמר הזה מפורטות המלצות שיעזרו לכם לשמור על גישה רציפה למשאבים של 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, אתם יכולים להגדיר בחשבון שלכם ב-Cloud Identity או ב-Google Workspace חלופה לאימות עבור משתמשים קריטיים. אפשר להשתמש בתוכנית הגיבוי הבאה:
- במהלך פעולות רגילות, אתם מאפשרים למשתמשים לבצע אימות באמצעות כניסה יחידה (SSO).
- במהלך הפסקת פעולה של ספק הזהויות, אתם יכולים להשבית באופן סלקטיבי את ה-SSO למשתמשים הקריטיים האלה ולאפשר להם לבצע אימות באמצעות פרטי הכניסה לחשבון Google שהקציתם מראש.
בקטעים הבאים מתוארות השיטות המומלצות כשמאפשרים למשתמשים קריטיים לבצע אימות במהלך הפסקות בשירות של ספק זהויות חיצוני.
התמקדות במשתמשים עם הרשאות
כדי שמשתמשים קריטיים יוכלו לעבור אימות במהלך הפסקת פעולה של IdP, צריכים להיות להם פרטי כניסה תקפים לחשבון Google, כמו:
- סיסמה עם מפתח אבטחה לאימות דו-שלבי.
- מפתח גישה.
כשמקצים פרטי כניסה לחשבון Google למשתמשים שבדרך כלל משתמשים ב-SSO, יכול להיות שתגדילו את העומס התפעולי ואת החיכוך עם המשתמשים בדרכים הבאות:
- יכול להיות שלא תוכלו לסנכרן את סיסמאות המשתמשים באופן אוטומטי, בהתאם ל-IdP שלכם. לכן, יכול להיות שתצטרכו לבקש מהמשתמשים להגדיר סיסמה באופן ידני.
- יכול להיות שתצטרכו לבקש מהמשתמשים לרשום מפתח גישה או להירשם לאימות דו-שלבי. בדרך כלל לא צריך לבצע את השלב הזה למשתמשי SSO.
כדי לאזן בין היתרונות של גישה רציפה לשירותי Google לבין העומס הנוסף, מומלץ להתמקד במשתמשים בעלי הרשאות ובמשתמשים שחיוניים לעסק. המשתמשים האלה צפויים להפיק תועלת משמעותית מגישה רציפה, והם עשויים להיות רק חלק קטן מבסיס המשתמשים הכולל שלכם.
כדאי לנצל את ההזדמנות כדי להפעיל אימות אחרי כניסה יחידה
כשמקצים אימות חלופי למשתמשים עם הרשאות מיוחדות, יכול להיות שיווצר עומס נוסף. כדי לעזור לקזז את התקורה הזו, אתם יכולים גם להפעיל אימות אחרי כניסה יחידה (SSO) למשתמשים האלה.
כברירת מחדל, כשמגדירים כניסה יחידה למשתמשים, הם לא נדרשים לבצע אימות דו-שלבי. למרות שהשיטה הזו נוחה, אם ספק הזהויות נפגע, כל משתמש שלא הפעיל אימות אחרי כניסה יחידה יכול להפוך למטרה של מתקפות זיוף פרטי כניסה.
אימות לאחר כניסה יחידה עוזר לצמצם את ההשפעה הפוטנציאלית של פריצה ל-IdP, כי המשתמשים צריכים לבצע אימות דו-שלבי אחרי כל ניסיון כניסה יחידה. אם אתם מקצים פרטי כניסה של כניסה לחשבון Google למשתמשים עם הרשאות, אימות אחרי כניסה יחידה יכול לעזור לשפר את רמת האבטחה של חשבונות המשתמשים האלה בלי להוסיף עומס.
שימוש ביחידה ארגונית נפרדת למשתמשים עם הרשאות מיוחדות
משתמשים עם הרשאות מיוחדות שיכולים לבצע אימות במהלך הפסקות בשירות של ספק זהויות חיצוני (IdP) צריכים הגדרה מיוחדת. ההגדרה הזו שונה מההגדרה של משתמשים רגילים ושל משתמשים עם גישה לשעת חירום.
כדי להפריד בין משתמשים עם הרשאות לבין חשבונות משתמשים אחרים, כדאי להשתמש ביחידה ארגונית ייעודית למשתמשים עם הרשאות. יחידה ארגונית נפרדת מאפשרת להחיל מדיניות מותאמת אישית, כמו אימות אחרי כניסה יחידה (SSO), רק על המשתמשים המורשים האלה.
יחידה ארגונית נפרדת גם עוזרת להשבית באופן סלקטיבי את ה-SSO למשתמשים עם הרשאות מיוחדות במהלך הפסקת שירות של IdP. כדי להשבית את ה-SSO ליחידה הארגונית, אפשר לשנות את ההקצאות של פרופיל ה-SSO.
שימוש ב-IdP חלופי
כשמספקים חלופות לאימות למשתמשים קריטיים במהלך הפסקות זמניות בשירות של ספק הזהויות, עוזרים לצמצם את ההשפעה של ההפסקות האלה על הארגון. עם זאת, יכול להיות שאסטרטגיית ההפחתה הזו לא תספיק כדי לשמור על יכולת תפעול מלאה. יכול להיות שהרבה משתמשים עדיין לא יוכלו לגשת לאפליקציות ולשירותים חיוניים.
כדי לצמצם עוד יותר את ההשפעה הפוטנציאלית של הפסקת פעולה של ספק הזהויות, אפשר לבצע מעבר לגיבוי של ספק הזהויות. אפשר להשתמש בתוכנית הגיבוי הבאה:
- במהלך פעולות רגילות, אתם מאפשרים למשתמשים לבצע אימות באמצעות כניסה יחידה וספק הזהויות הראשי שלכם.
- במהלך הפסקת חשמל ב-IdP, אתם משנים את הגדרת ה-SSO בחשבון Cloud Identity או Google Workspace כדי לעבור ל-IdP לגיבוי.
ספק ה-IdP של הגיבוי לא חייב להיות אותו ספק. כשיוצרים IdP לגיבוי, צריך להשתמש בהגדרה שתואמת להגדרה של ה-IdP הראשי. כדי להבטיח שספק הזהויות לגיבוי יאפשר לכל המשתמשים שלכם לבצע אימות ולגשת לשירותי Google, ספק הזהויות לגיבוי צריך להשתמש בעותק עדכני של בסיס המשתמשים של ספק הזהויות הראשי.
ספק זהויות לגיבוי יכול לעזור לספק גישה מקיפה למקרה חירום. עם זאת, חשוב לשקול את היתרונות האלה מול הסיכונים הנוספים שספק זהויות לגיבוי עלול להוסיף. הסיכונים האפשריים האלה כוללים:
- אם ספק ה-IdP לגיבוי מספק אבטחה חלשה יותר מספק ה-IdP הראשי, יכול להיות שרמת האבטחה הכוללת של סביבת Google Cloud הארגון תהיה חלשה יותר במהלך מעבר לגיבוי.
- אם יש הבדל בין ספק הזהויות הראשי לבין ספק הזהויות לגיבוי באופן שבו הם מנפיקים הצהרות SAML, ספק הזהויות עלול להעמיד את המשתמשים בסיכון למתקפות זיוף.
בקטעים הבאים מתוארות שיטות מומלצות לשימוש בספק זהויות לגיבוי לגישה למקרה חירום.
יצירת פרופיל 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 המשני, הוא צריך לטפל בכל בקשות האימות שבדרך כלל מטופלות על ידי ה-IdP הראשי.
כשפורסים ומגדירים את הגודל של ספק זהויות לגיבוי, חשוב לזכור שמספר הבקשות הצפויות תלוי בגורמים הבאים:
- מספר המשתמשים בחשבון Cloud Identity או בחשבון Google Workspace.
- Google Cloud משך הסשן שהוגדר.
לדוגמה, אם משך הסשן הוא בין 8 ל-24 שעות, יכול להיות שיהיה זינוק בבקשות האימות בשעות הבוקר, כשהעובדים מתחילים את יום העבודה.
בדיקה תקופתית של תהליך המעבר לגיבוי
כדי לוודא שתהליך המעבר לגיבוי בעת כשל של ה-SSO פועל בצורה מהימנה, צריך לאמת את התהליך באופן תקופתי. כשבודקים את תהליך המעבר לגיבוי, מבצעים את הפעולות הבאות:
- משנים באופן ידני את הקצאת פרופיל ה-SSO של יחידה ארגונית אחת או יותר או של קבוצה אחת או יותר כדי להשתמש ב-IdP לגיבוי.
- מוודאים שכניסת ה-SSO עם ספק הזהויות לגיבוי פועלת כצפוי.
- מוודאים שאישורי החתימה מעודכנים.
המאמרים הבאים
- מומלץ לעיין בשיטות המומלצות לשמירה על אבטחה בחשבונות של אדמינים.
- מידע נוסף על שיטות מומלצות לאיחוד Google Cloud עם ספק זהויות חיצוני
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Johannes Passing | Cloud Solutions Architect
תורם נוסף: Ido Flatow | Cloud Solutions Architect