מה מכינים לפני שמשנים מדיניות
מפו חשבונות עובדים, מנהלים, ספקים ותהליכים שנשענים על התחברות של אדם. רשמו מי מנהל את הסביבה ואילו משתמשים כבר רשומים לאימות. משתמש פרטי ב-Gmail אינו חשבון Workspace מנוהל; המדריך מיועד למנהל מורשה של סביבת העסק.
לפני אכיפה, הכינו גישת ניהול חלופית מוגנת ונוהל שחזור שאינו תלוי רק בטלפון של אדם אחד. לא מבטלים הגנה קיימת כדי להתחיל מחדש. בדקו את המדיניות הנוכחית, את ההחרגות ואת דרישות Google לחשבונות מנהלים.
איך מפעילים את התהליך ב-Admin console
לפי תיעוד Google, הגדרות האימות נמצאות תחת Security > Authentication > 2-step verification. שינוי הגדרות ההטמעה דורש הרשאת super administrator. בחרו את היחידה או הקבוצה הרלוונטית, אפשרו רישום לפי המדיניות הרצויה והנחו את המשתמשים להשלים אותו.
עקבו אחר מצב הרישום והאכיפה בדוחות האבטחה, ובדקו את המדיניות האפקטיבית על חשבון לדוגמה. לפני מעבר לאכיפה, אשרו שהעובדים יכולים להתחבר בשיטה המותרת. שמות אפשרויות ומגבלות עשויים להשתנות, ולכן משווים לתיעוד הרשמי לפני החלת השינוי.
איך בודקים מוכנות לאכיפה
השתמשו בטבלה כשער קבלה, ולא רק כרשימת הגדרות. לכל קבוצה צריך להיות אחראי שיודע מי נבדק ומה עדיין חסר. חשבון שעליו חל חריג זמני צריך תאריך בחינה מחדש; חריג ללא מעקב עלול להפוך למסלול הכניסה הקבוע.
| בדיקה | תוצאה רצויה | אם הבדיקה נכשלת |
|---|---|---|
| כניסה רגילה | המשתמש נכנס בשיטה שהעסק אישר | בודקים התאמת שיטה ומכשיר |
| אובדן אמצעי אימות | קיים מסלול שחזור מורשה ונגיש | מסדירים שחזור לפני הרחבה |
| חשבון מנהל | קיימת יכולת ניהול חלופית מוגנת | לא משנים את כל המנהלים יחד |
| יישום עסקי | החיבור עובד בלי עקיפה לא מתועדת | בודקים תמיכה ושיטת התחברות |
| מדיניות בפועל | ההגדרה הרצויה חלה על קבוצת היעד | בודקים ירושה, קבוצות וחריגים |
איך נמנעים מנעילת עובדים ומנהלים
מעבר של משתמש ליחידה עם אכיפה, או שינוי הדרישה למפתח אבטחה שאין לו, עלולים לחסום כניסה. Google מציינת שדוחות רישום עשויים להתעדכן באיחור; בעת הצורך בודקים גם את הגדרות האבטחה של המשתמש. אל תסיקו ממסך דוח יחיד שהמשתמש מוכן.
קודי גיבוי, אם הם מותרים ומתאימים למדיניות, נשמרים במקום מוגן ולא בהתכתבות צוותית. במצב נעילה משתמשים במסלול השחזור של הספק. אכיפה שמגיעה מ-Google לחשבונות מנהלים אינה בהכרח ניתנת לביטול באמצעות חריג ארגוני.
איך Passkeys משתלבים ומה נבדק בסיום
רישום Passkey אינו מפעיל אוטומטית 2SV. Google מבחינה בין שימוש במפתח גישה לכניסה ללא סיסמה לבין רישום ואכיפה של אימות דו-שלבי. גם הפעלת האפשרות לדלג על סיסמה אינה מוחקת את הסיסמה הקיימת.
בסיום בדקו כניסה, שחזור, מדיניות אפקטיבית ויישומים חשובים, ותעדו מה נבדק בפועל. אל תבקשו מהעובדים לשלוח סיסמה או קוד אימות לצורך אישור ההטמעה. התיעוד צריך לכלול את תוצאת הבדיקה, לא את הסוד ששימש לביצועה.
תרחיש ניסיון: עובד חדש, מנהל וספק חיצוני
זו דוגמה להמחשה, לא תוצאת הטמעה אצל לקוח. בחרו שלושה חשבונות שמייצגים עבודה שונה: עובד שמשתמש בדפדפן ובטלפון, מנהל מורשה וספק בעל גישה מוגבלת. לכל אחד רשמו אמצעי כניסה, מסלול שחזור, מדיניות יעד ויישום עסקי שיש לבדוק. השתמשו בחשבונות ניסיון מתאימים ובאישור האחראי, בלי להנמיך הגנות על חשבון פעיל כדי לייצר ניסוי.
בדקו כניסה חדשה בסביבה מתואמת, פעולה עסקית ושחזור לפי נוהל הספק. עבור יישומים המשתמשים ב-SSO או בחיבורים שאינם כניסה רגילה, מפו את מסלול האימות שלהם בנפרד. אם נוצר צורך בעקיפה, תעדו אותה והחליטו על טיפול במקום להניח שהיא חלק תקין מההטמעה.
בסיום הפיילוט חלקו את המשתמשים למוכנים, חסרי אמצעי מתאים וזקוקים לבדיקה נוספת. הרחבה תלויה בתוצאה ולא רק בתאריך ביומן. העבירו לעובדים הוראות שמבהירות היכן נרשמים ולמי פונים במקרה תקלה; תמיכה אינה צריכה לבקש קוד חד-פעמי כדי לוודא שהמשתמש הצליח.
