במאמר הזה מפורטות המלצות שיעזרו לכם לשמור על גישה רציפה למשאבים שלGoogle Cloud . המשכיות עסקית נועדה להבטיח שהארגון יוכל לשמור על פעולות חיוניות, גם במהלך שיבושים כמו הפסקות חשמל או אסונות. היעד הזה כולל גישה מתמשכת של העובדים גם כששירותים ותשתיות קריטיים לא זמינים.
המסמך הזה מיועד לאנשי מקצוע בתחום האבטחה או המהימנות שאחראים על ניהול הזהויות והרשאות הגישה (IAM) ועל תחזוקה של גישה מאובטחת אל Google Cloud. במסמך הזה אנחנו מניחים שאתם כבר מכירים את Cloud Identity, את Google Workspace ואת ניהול ה-IAM.
כדי לעזור לכם להתכונן להפסקות שירות ולהבטיח גישה רציפה, במסמך הזה מפורטים השלבים המומלצים הבאים. אתם יכולים ליישם את כל השלבים האלה או רק חלק מהם, אבל אנחנו ממליצים לבצע אותם בסדר הבא:
הגדרת גישה למקרה חירום הפעלת גישה Google Cloud למשאבים במקרה חירום.
מומלץ להגדיר גישת חירום לכלGoogle Cloud הארגונים, בלי קשר לדרישות שלכם להמשכיות עסקית.
מספקים חלופות לאימות למשתמשים קריטיים. אם בארגון שלכם משתמשים בכניסה יחידה (SSO), כל שיבוש שמשפיע על ספק הזהויות (IdP) החיצוני יכול להשפיע על העובדים. יכול להיות שהמשתמשים לא יוכלו לעבור אימות ולהשתמש ב- Google Cloud.
כדי לצמצם את ההשפעה הכוללת של שיבוש ב-IdP על הארגון, צריך לספק חלופה לאימות למשתמשים שנדרשת להם גישה Google Cloud למשאבים קריטיים לעסק.
שימוש ב-IdP לגיבוי כדי לאפשר לכל המשתמשים לגשת למשאבי Google Cloud במהלך שיבוש בשירות של ספק הזהויות, אפשר להגדיר ספק זהויות חלופי.
ספק זהות חלופי יכול לעזור למזער עוד יותר את ההשפעה של שיבוש, אבל יכול להיות שהאפשרות הזו לא תהיה חסכונית לכל הארגונים.
בקטעים הבאים מתוארים השלבים המומלצים והשיטות המומלצות.
הגדרת גישה במקרה חירום
מטרת הגישה למקרה חירום היא לאפשר גישה ל Google Cloud משאבים כמוצא אחרון, ולמנוע מצבים שבהם אתם עלולים לאבד את הגישה לחלוטין.
משתמשים עם גישת חירום מאופיינים במאפיינים הבאים:
- אלה משתמשים שאתם יוצרים בחשבון Cloud Identity או בחשבון Google Workspace.
- יש להם הרשאת סופר-אדמין, שמאפשרת למשתמשים גישה מספקת לפתרון בעיות של הגדרות שגויות שמשפיעות על משאבי Cloud Identity, Google Workspace או Google Cloud.
- הם לא משויכים לעובד ספציפי בארגון. לכן, הם פטורים ממחזור החיים של הצטרפות, מעבר ועזיבה (JML) של חשבונות משתמשים רגילים.
- הם פטורים מ-SSO.
בקטעים הבאים מתוארות שיטות מומלצות לניהול משתמשים עם גישת חירום ולאבטחתם.
יצירת משתמשים עם גישת חירום לכל סביבה
בסביבות Google Cloud שמארחות עומסי עבודה של ייצור, גישת חירום היא קריטית. גם Google Cloud בסביבות שמשמשות למטרות בדיקה או להכנה של אתר להשקה, אובדן גישה עלול לשבש את העבודה.
כדי להבטיח גישה רציפה לכל ה Google Cloud סביבות, צריך ליצור ולתחזק משתמשים עם גישת חירום ב-Cloud Identity או ב- Google Workspace לכל סביבה.
איך מוודאים שיש גישה למקרה חירום
משתמש אחד עם גישת חירום הוא נקודת כשל בודדת. בתרחיש הזה, מפתח אבטחה פגום, סיסמה שאבדה או השעיה של החשבון עלולים לשבש את הגישה לחשבון. כדי לצמצם את הסיכון הזה, אתם יכולים ליצור יותר ממשתמש אחד עם גישת חירום לכל חשבון 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) למשתמשים האלה.
כברירת מחדל, כשמגדירים כניסה יחידה למשתמשים, הם לא נדרשים לבצע אימות דו-שלבי. למרות שהשיטה הזו נוחה, ספק זהויות שנפרץ יוצר סיכון. כל משתמש שלא מופעל אצלו אימות אחרי כניסה יחידה (SSO) יכול להפוך למטרה של מתקפות זיוף פרטי כניסה.
אימות לאחר כניסה יחידה עוזר לצמצם את ההשפעה הפוטנציאלית של פריצה ל-IdP, כי המשתמשים צריכים לבצע אימות דו-שלבי אחרי כל ניסיון כניסה יחידה. אם אתם מקצים למשתמשים עם הרשאות מיוחדות אמצעי אימות לכניסה לחשבון Google, אימות אחרי כניסה יחידה יכול לעזור לשפר את מצב האבטחה של חשבונות המשתמשים האלה בלי להוסיף עומס.
שימוש ביחידה ארגונית נפרדת למשתמשים עם הרשאות מיוחדות
משתמשים עם הרשאות מיוחדות שיכולים לבצע אימות במהלך הפסקות שירות של ספק זהויות חיצוני (IdP) צריכים הגדרה מיוחדת. ההגדרה הזו שונה מההגדרה של משתמשים רגילים ושל משתמשים עם גישה לשעת חירום.
כדי להפריד בין משתמשים עם הרשאות לבין חשבונות משתמשים אחרים, מומלץ להשתמש ביחידה ארגונית ייעודית למשתמשים עם הרשאות. יחידה ארגונית נפרדת מאפשרת להחיל מדיניות מותאמת אישית, כמו אימות אחרי כניסה יחידה (SSO), רק על המשתמשים המורשים האלה.
יחידה ארגונית נפרדת גם עוזרת להשבית באופן סלקטיבי את ה-SSO למשתמשים עם הרשאות מיוחדות במהלך הפסקת שירות של ספק הזהויות. כדי להשבית את ה-SSO ליחידה הארגונית, אפשר לשנות את ההקצאות של פרופיל ה-SSO.
שימוש ב-IdP חלופי
כשמספקים חלופות לאימות למשתמשים קריטיים במהלך הפסקות שירות של ספק זהויות, עוזרים לצמצם את ההשפעה של הפסקת השירות הזו על הארגון. עם זאת, יכול להיות שאסטרטגיית המיתון הזו לא תספיק כדי לשמור על יכולת תפעול מלאה. יכול להיות שהרבה משתמשים עדיין לא יוכלו לגשת לאפליקציות ולשירותים חיוניים.
כדי לצמצם עוד יותר את ההשפעה הפוטנציאלית של הפסקת פעילות של ספק הזהויות, אפשר לבצע מעבר לגיבוי של ספק הזהויות. אפשר להשתמש בתוכנית הגיבוי הבאה:
- במהלך פעולות רגילות, אתם מאפשרים למשתמשים לבצע אימות באמצעות כניסה יחידה (SSO) וספק הזהויות הראשי שלכם.
- במהלך הפסקת חשמל ב-IdP, אתם משנים את הגדרת ה-SSO בחשבון Cloud Identity או Google Workspace כדי לעבור ל-IdP לגיבוי.
ספק ה-IdP של הגיבוי לא חייב להיות אותו ספק. כשיוצרים IdP לגיבוי, צריך להשתמש בהגדרה שתואמת להגדרה של ה-IdP הראשי. כדי לוודא שספק ה-IdP לגיבוי מאפשר לכל המשתמשים שלכם לבצע אימות ולגשת לשירותי Google, ספק ה-IdP לגיבוי צריך להשתמש בעותק עדכני של בסיס המשתמשים של ספק ה-IdP הראשי.
ספק זהויות לגיבוי יכול לעזור לספק גישה מקיפה למקרה חירום. עם זאת, חשוב לשקול את היתרונות האלה מול הסיכונים הנוספים שספק גיבוי של IdP עלול להוסיף. הסיכונים האפשריים האלה כוללים:
- אם ספק הזהויות לגיבוי מספק אבטחה חלשה יותר מספק הזהויות הראשי, יכול להיות שמצב האבטחה הכולל של סביבת Google Cloud העבודה יהיה חלש יותר במהלך יתירות כשל.
- אם יש הבדל בין ספק ה-IdP הראשי לבין ספק ה-IdP לגיבוי באופן הנפקת הצהרות SAML, יכול להיות שספק ה-IdP יחשוף את המשתמשים לסיכון של מתקפות זיוף.
בקטעים הבאים מתוארות שיטות מומלצות לשימוש בספק זהויות לגיבוי לגישה למקרה חירום.
יצירת פרופיל SAML נפרד לספק הגיבוי של הזהויות
ב-Cloud Identity וב-Google Workspace אפשר ליצור כמה פרופילי SAML. כל פרופיל SAML יכול להתייחס לספק זהויות SAML אחר.
כדי לצמצם את כמות העבודה שנדרשת למעבר ל-IdP לגיבוי, צריך להכין מראש פרופיל SAML ל-IdP לגיבוי:
- יוצרים פרופילי SAML נפרדים לספק הזהויות הראשי ולספק הזהויות לגיבוי.
- מגדירים הקצאות של פרופיל SSO כדי להקצות רק את פרופיל ה-SAML של ספק הזהויות הראשי במהלך פעולות רגילות.
- לשנות את ההקצאות של פרופיל ה-SSO כדי להשתמש בפרופיל ה-SAML של ספק הזהויות לגיבוי במהלך הפסקה בשירות של ספק הזהויות. אל תשנו את ההגדרות של פרופיל 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 עם ספק זהויות חיצוני