איך לאכוף אימות רב-שלבי בכל ארגון הגוגל וורקספייס שלכם

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

למה ״זמין״ אינו ״נאכף״

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

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

בחרו את גורמי האימות בכוונה

לא כל גורמי האימות שווים. מהחזק לחלש:

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

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

הטמעה מדורגת שמונעת נעילות

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

1. תקשרו קודם. ספרו לארגון מה משתנה, למה ועד מתי. ספקו הוראות הרשמה. אכיפה בהפתעה מייצרת קריאות תמיכה וטינה.
2. פתחו חלון הרשמה. הפעילו אימות דו-שלבי כזמין וקבעו מועד אחרון. עקבו אחרי התקדמות ההרשמה כדי לראות מי טרם נרשם.
3. דחפו את המתמהמהים. ככל שהמועד מתקרב, הזכירו לחשבונות שלא נרשמו. כאן נרשם רוב הזנב הארוך.
4. אכפו עם תקופת חסד למשתמשים חדשים. הפעילו אכיפה, אבל הגדירו תקופת חסד לחשבונות חדשים כדי שקליטת עובדים לא תיחסם בכניסה הראשונה.
5. חלקו אמצעי גיבוי. ודאו שלמשתמשים יש קודי גיבוי או גורם שני רשום, כך שטלפון אבוד יהיה אי-נוחות קטנה ולא נעילה.
6. טפלו בחריגים בצמצום. חשבונות שירות או חשבונות משותפים מסוימים באמת מתקשים באימות דו-שלבי אינטראקטיבי. העבירו אותם למודל אימות מתאים יותר (מפתחות חשבון שירות, טיפול ייעודי) במקום לחצוב פטורים רחבים במדיניות המשתמשים.

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

מלכודות נפוצות

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

ודאו את האכיפה — אל תניחו אותה

להפעיל את המדיניות ולוודא שהיא *באמת מוחלת על כל חשבון* הם שני דברים שונים. חשבונות שנוצרו לפני המדיניות, חשבונות ביחידה ארגונית פטורה או כאלה שנתפסו בתקופת חסד יכולים ליפול בשקט מחוץ לאכיפה. חלק מעמדת אבטחת גוגל וורקספייס בריאה — ובקרה שמבקרי SOC 2 בוחנים ספציפית תחת CC6.1 — הוא לבדוק שאכיפת האימות הרב-שלבי מחזיקה בכל הארגון, לא רק שהמתג דולק.

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

מטפלים במקרים הקשים

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

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

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

אחרי ההטמעה: שמרו על האכיפה

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

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

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