במאמר הזה מוסבר איך להעביר חשבונות לשימוש אישי לחשבונות משתמשים מנוהלים שמנוהלים על ידי Cloud Identity או Google Workspace.
אם הארגון שלכם לא השתמש ב-Cloud Identity או ב-Google Workspace בעבר, יכול להיות שחלק מהעובדים משתמשים בחשבונות פרטיים כדי לגשת לשירותי Google. חלק מהחשבונות האלה לצרכנים עשויים להשתמש בכתובת אימייל ארגונית כמו alice@example.com ככתובת האימייל הראשית שלהם.
חשבונות לצרכן נמצאים בבעלות ובניהול של האנשים שיצרו אותם. לכן, לארגון שלכם אין שליטה על ההגדרות, האבטחה ומחזור החיים של החשבונות האלה.
לפני שמתחילים
כדי להעביר חשבונות לשימוש אישי אל Cloud Identity או אל Google Workspace, צריך לעמוד בדרישות המוקדמות הבאות:
- זיהית תוכנית מתאימה להעברת נתונים והשלמת את כל הדרישות המוקדמות לאיחוד חשבונות המשתמשים הקיימים.
- יצרתם חשבון Cloud Identity או Google Workspace והכנתם את היחידה הארגונית (OU) שמוגדרת כברירת מחדל כדי להעניק גישה מתאימה לחשבונות משתמשים שהועברו.
כל חשבון פרטי שאתם מתכננים להעביר צריך לעמוד בקריטריונים הבאים:
- אי אפשר להשתמש בחשבון Gmail.
- היא צריכה להשתמש בכתובת אימייל ראשית שתואמת לדומיין הראשי או לדומיין משני בחשבון Cloud Identity או Google Workspace. בהקשר של העברת חשבון פרטי, המערכת מתעלמת מכתובות אימייל חלופיות ומדומיינים של כתובות אימייל חלופיות.
- הבעלים של החשבון צריך להיות מסוגל לקבל אימייל לכתובת האימייל הראשית של החשבון.
המרת חשבון פרטי לחשבון מנוהל פירושה שהמשתמש שרשם את החשבון הפרטי מעביר את השליטה בחשבון ובנתונים שמשויכים אליו לארגון שלכם. יכול להיות שהארגון שלכם דורש מהעובדים לחתום על מדיניות שימוש מקובל באימייל ולפעול לפיה, ושבמדיניות הזו נאסר על שימוש בכתובות אימייל ארגוניות למטרות פרטיות. במקרה כזה, אפשר להניח בבטחה שהחשבון הפרטי שימש רק למטרות עסקיות. עם זאת, אם לארגון שלכם אין מדיניות כזו או שהמדיניות מאפשרת שימוש אישי מסוים, יכול להיות שהחשבון לצרכן ישויך לשילוב של נתונים ארגוניים ואישיים. בגלל אי הוודאות הזו, אי אפשר לכפות את ההעברה של חשבון פרטי לחשבון מנוהל. לכן, ההעברה תמיד דורשת את הסכמת המשתמש.
עיבוד
העברת חשבונות לצרכן לחשבונות מנוהלים היא תהליך רב-שלבי שצריך לתכנן בקפידה. בקטעים הבאים מפורט תהליך ההגדרה.
סקירה כללית על התהליך
מטרת ההעברה היא להפוך חשבון פרטי לחשבון משתמש מנוהל, תוך שמירה על הזהות של החשבון כפי שהיא משתקפת בכתובת האימייל שלו, ועל כל הנתונים שמשויכים לחשבון.
במהלך העברה כזו, חשבון יכול להיות באחד מארבעה מצבים, כפי שמוצג בתרשים של מכונת המצבים הבא.
כשמוסיפים דומיין ומאמתים אותו ב-Cloud Identity או ב-Google Workspace, כל חשבון פרטי שמשתמש בכתובת אימייל עם הדומיין הזה הופך לחשבון לא מנוהל. למשתמש אין השפעה; הוא יכול להיכנס לחשבון ולגשת לנתונים שלו כרגיל.
הוספת דומיין ב-Google Workspace או ב-Cloud Identity משפיעה רק על משתמשים שכתובת האימייל שלהם תואמת לדומיין הזה בדיוק. לדוגמה, אם מוסיפים את example.com, החשבון johndoe@example.com מזוהה כחשבון לא מנוהל, אבל johndoe@corp.example.com לא מזוהה ככזה אלא אם מוסיפים גם את corp.example.com לחשבון Cloud Identity או Google Workspace.
אם יש חשבונות לא מנוהלים, אתם מקבלים על כך הודעה כאדמינים ב-Cloud Identity או ב-Google Workspace. אחרי זה, אפשר לבקש מהמשתמש להעביר את החשבון שלו לחשבון מנוהל.
בתרשים שלמעלה, אם המשתמש johndoe מסכים להעברה, החשבון הלא מנוהל מומר לחשבון מנוהל. הזהות נשארת זהה, אבל מעכשיו Cloud Identity או Google Workspace שולטים בחשבון, כולל בכל הנתונים שלו.
אם המשתמש johndoe לא מסכים להעברת נתונים, אבל אתם יוצרים חשבון ב-Cloud Identity או ב-Google Workspace באמצעות אותה כתובת אימייל, התוצאה היא חשבון בעל מאפיינים זהים לחשבון פעיל. חשבון מתנגש הוא למעשה שני חשבונות – אחד לצרכן ואחד מנוהל – שמשויכים לאותה זהות, כמו בתרשים הבא.
משתמש שנכנס באמצעות חשבון שמתנגש עם חשבון אחר רואה מסך שבו הוא מתבקש לבחור בין החשבון המנוהל לבין החשבון הפרטי כדי להמשיך בתהליך הכניסה.
כדי להימנע ממצב שבו יש לכם חשבונות סותרים, כדאי להבין את מצבי החשבון בפירוט.
פירוט התהליך
בתרשים הבא של מכונת מצבים מוצגים מצבי החשבון בפירוט רב יותר. התיבות המלבניות בצד שמאל מציינות פעולות שאדמין ב-Cloud Identity או ב-Google Workspace יכול לבצע, והתיבות המלבניות בצד ימין מציינות פעולות שרק הבעלים של חשבון פרטי יכול לבצע.
איך מוצאים חשבונות משתמשים לא מנוהלים
כשנרשמים ל-Cloud Identity או ל-Google Workspace, צריך לספק שם דומיין, ואז מתבקשים לאמת את הבעלות עליו. אחרי שתשלימו את תהליך ההרשמה, תוכלו להוסיף דומיינים משניים ולאמת אותם.
כשמאמתים דומיין, מתחיל באופן אוטומטי חיפוש של חשבונות לצרכן שמשתמשים בדומיין הזה בכתובת האימייל שלהם. תוך כ-12 שעות, החשבונות האלה יופיעו כחשבונות משתמשים לא מנוהלים בכלי ההעברה למשתמשים שאינם מנוהלים.
בחיפוש אחר חשבונות לצרכן נלקחים בחשבון הדומיין הראשי שרשום ב-Cloud Identity או ב-Google Workspace, וגם כל דומיין משני שאומת. החיפוש מנסה להתאים בין הדומיינים האלה לכתובת האימייל הראשית של חשבונות לשימוש אישי. לעומת זאת, דומיינים של כינויים שרשומים ב-Cloud Identity או ב-Google Workspace, וגם כתובות אימייל חלופיות של חשבונות לצרכן לא נחשבים.
המשתמשים בחשבונות הצרכניים המושפעים לא יודעים שאימתתם דומיין או שזיהיתם את החשבון שלהם כחשבון לא מנוהל. הם יכולים להמשיך להשתמש בחשבונות שלהם כרגיל.
התחלת ההעברה
בנוסף להצגת כל החשבונות הלא מנוהלים, כלי ההעברה למשתמשים שאינם מנוהלים מאפשר לכם לשלוח בקשה להעברת חשבון כדי להתחיל בהעברה. בתחילה, החשבון מופיע עם הערך עדיין לא נשלחה הזמנה, שמציין שלא נשלחה בקשה להעברה.
אם בוחרים משתמש ושולחים בקשה להעברת חשבון, המשתמש מקבל אימייל דומה לזה שמופיע בהמשך. בינתיים, החשבון מופיע ברשימה עם התווית הוזמן.
אישור או התעלמות מהעברה
אחרי קבלת בקשת ההעברה, המשתמשים המושפעים יכולים פשוט להתעלם ממנה ולהמשיך להשתמש בחשבון כרגיל. במקרה כזה, אפשר לשלוח בקשה נוספת ולחזור על התהליך.
עד שהמשתמש יאשר את בקשת ההעברה, הפונקציונליות של החשבון הלא מנוהל לא תיפגע – המשתמשים יוכלו להיכנס לחשבון ולגשת לנתונים שלהם. עם זאת, כל עוד משתמש מתעלם מבקשת העברה, תהליך העברת נתוני החשבון אל Google Workspace או אל Cloud Identity נתקע. כדי למנוע את המצב הזה, חשוב להסביר לעובדים על תוכנית ההעברה לפני ששולחים את בקשות ההעברה הראשונות. חשוב גם לוודא שהעובדים מודעים באופן מלא לסיבות ולתוצאות של אישור בקשת העברה או התעלמות ממנה.
במקום להתעלם מהבקשה, המשתמש יכול גם לשנות את כתובת האימייל של החשבון. אם המשתמש משנה את כתובת האימייל הראשית לשימוש בדומיין שלא אומת על ידי אף חשבון Cloud Identity או חשבון Google Workspace, החשבון הופך שוב לחשבון לצרכן. יכול להיות שעדיין תהיה רשימה זמנית של המשתמש בכלי ההעברה כחשבון לא מנוהל, אבל לא תוכלו יותר להתחיל העברת חשבון עבור חשבון ששמו השתנה.
יצירת חשבון בעל מאפיינים זהים לחשבון פעיל
אם בשלב כלשהו תיצרו חשבון משתמש ב-Cloud Identity או ב-Google Workspace עם אותה כתובת אימייל של חשבון משתמש לא מנוהל, מסוף Admin יציג אזהרה לגבי חשבון בעל מאפיינים זהים לחשבון פעיל:
אם מתעלמים מהאזהרה הזו ויוצרים בכל זאת חשבון משתמש, החשבון החדש הזה, יחד עם החשבון הלא מנוהל, הופך לחשבון בעל מאפיינים זהים לחשבון פעיל. יצירת חשבון מתנגש שימושית אם רוצים להסיר חשבון פרטי לא רצוי, אבל עדיף להימנע ממנה אם המטרה היא להעביר חשבון פרטי אל Cloud Identity או אל Google Workspace.
יצירת חשבון בעל מאפיינים זהים לחשבון פעיל יכולה לקרות בטעות. אחרי שנרשמים ל-Cloud Identity או ל-Google Workspace, יכול להיות שתחליטו להגדיר כניסה יחידה (SSO) באמצעות ספק זהויות (IdP) חיצוני, כמו Microsoft Entra ID (לשעבר Azure Active Directory) או Active Directory. אם הגדרתם ספק זהויות חיצוני, יכול להיות שהוא ייצור אוטומטית חשבונות ב-Cloud Identity או ב-Google Workspace לכל המשתמשים שהפעלתם עבורם כניסה יחידה, וכך ייצרו חשבונות שמתנגשים זה בזה.
שימוש בחשבון עם מאפיינים זהים לחשבון פעיל
בכל פעם שהמשתמש נכנס לחשבון באמצעות חשבון מתנגש, מוצג לו מסך עם אפשרויות בחירה כמו זה שבהמשך.
אם הם בוחרים באפשרות הראשונה, תהליך הכניסה ממשיך באמצעות החלק המנוהל של החשבון המתנגש. הם מתבקשים להזין את הסיסמה שהגדרתם לחשבון המנוהל, או שאם הגדרתם כניסה יחידה (SSO), הם מופנים לספק זהויות חיצוני (IdP) כדי לבצע אימות. אחרי שהם מאומתים, הם יכולים להשתמש בחשבון כמו בכל חשבון מנוהל אחר – אבל מכיוון שאף אחד מהנתונים לא הועבר מחשבון פרטי המקורי, זה למעשה חשבון חדש.
אם המשתמש בוחר באפשרות השנייה במסך ההצבעה, הוא מתבקש לשנות את כתובת האימייל של החלק הצרכני בחשבון שנוצר בו קונפליקט.
שינוי כתובת האימייל פותר את הבעיה כי הוא מבטיח שלחשבון המנוהל ולחשבון פרטי יהיו שוב זהויות שונות. התוצאה היא שלמשתמש יש חשבון פרטי אחד עם כל הנתונים המקוריים שלו, וחשבון מנוהל אחד שאין לו גישה לנתונים המקוריים.
המשתמש יכול לדחות את שינוי השם של החשבון על ידי לחיצה על אעשה זאת מאוחר יותר. הפעולה הזו תעביר את החשבון למצב הוצא מהמערכת. במצב הזה, המשתמש רואה את אותו מסך בחירות בכל פעם שהוא נכנס לחשבון, ומוקצית לחשבון כתובת אימייל זמנית gtempaccount.com עד שמשנים את השם.
דרך נוספת לפתור את הבעיה היא למחוק את החשבון המנוהל ב-Cloud Identity או ב-Google Workspace, או אם המשתמש משתמש בכניסה יחידה, ב-IdP החיצוני. כתוצאה מכך, מסך ההצבעה לא יוצג בפעם הבאה שהמשתמש ייכנס לחשבון, אבל הוא עדיין יצטרך לשנות את כתובת האימייל של החשבון.
אם המשתמש משנה את כתובת האימייל לכתובת אימייל פרטית, החשבון נשאר חשבון פרטי. אם המשתמש יחליט לשנות את כתובת האימייל בחזרה לכתובת האימייל העסקית המקורית, החשבון יהפוך שוב לחשבון לא מנוהל.
השלמת העברה
אם המשתמש מאשר את ההעברה, החשבון מופיע ב-Cloud Identity או ב-Google Workspace. החשבון נחשב עכשיו לחשבון מנוהל, וכל הנתונים שמשויכים לחשבון הפרטי המקורי מועברים לחשבון המנוהל.
אם לא הוגדר ב-Cloud Identity או ב-Google Workspace שימוש ב-IdP חיצוני לכניסה יחידה, המשתמש יכול להיכנס באמצעות הסיסמה המקורית שלו ולהמשיך להשתמש בחשבון כרגיל.
אם אתם משתמשים בכניסה יחידה, המשתמש לא יוכל יותר להיכנס באמצעות הסיסמה הקיימת שלו. במקום זאת, הם מועברים לדף הכניסה של ספק הזהויות החיצוני שלכם כשהם מנסים להיכנס. כדי שהפעולה הזו תצליח, ספק הזהויות החיצוני צריך לזהות את המשתמש ולאפשר כניסה יחידה. אחרת, החשבון יינעל.
שיטות מומלצות
אם אתם מתכוונים להעביר חשבונות פרטיים קיימים ל-Cloud Identity או ל-Google Workspace, כדאי לתכנן ולתאם מראש את שלבי ההעברה. תכנון טוב ימנע שיבושים אצל המשתמשים ויצמצם את הסיכון ליצירת חשבונות מתנגשים בטעות.
כדאי לפעול לפי השיטות המומלצות הבאות כשמתכננים העברה של חשבון פרטי:
- אם משתמשים בספק זהויות חיצוני, צריך להגדיר הקצאת חשבונות משתמשים וכניסה יחידה (SSO) באופן שלא יפריע להעברת חשבונות פרטיים.
לעדכן את המשתמשים שהושפעו לפני ההעברה. העברת חשבונות לשימוש אישי לחשבונות מנוהלים מחייבת את הסכמת המשתמשים, ועשויה להשפיע עליהם באופן אישי אם הם השתמשו בחשבונות למטרות פרטיות. לכן, חשוב מאוד שתעדכנו את המשתמשים המושפעים לגבי תוכניות ההעברה שלכם.
לפני שמתחילים בהעברה, חשוב להעביר למשתמשים את המידע הבא:
- הסבר על ההצדקה והחשיבות של העברת החשבון.
- ההשפעה על מידע אישי שמשויך לחשבונות קיימים.
- מסגרת הזמן שבה המשתמשים יכולים לצפות לקבל בקשת העברה.
- חלון הזמן שבו אתם מצפים שהמשתמשים יאשרו את ההעברה.
- שינויים שצפויים בתהליך הכניסה לחשבון אחרי המיגרציה (רלוונטי רק כשמשתמשים באיחוד זהויות).
- הוראות להעברת בעלות על קובצי Google Docs פרטיים לחשבון אישי.
אם תודיעו על ההעברה באימייל, חלק מהמשתמשים עלולים לחשוב שמדובר בניסיון פישינג. כדי למנוע את זה, כדאי להודיע על המעבר גם באמצעי תקשורת אחרים.
דוגמה להודעה באימייל מופיעה במאמר בנושא הודעה מראש על העברת חשבונות משתמשים.
התחלת העברות בקבוצות. מתחילים עם קבוצה קטנה של כ-10 משתמשים, ומגדילים את גודל הקבוצה בהדרגה.
חשוב להקצות מספיק זמן למשתמשים המושפעים כדי שיוכלו להגיב לבקשות ההעברה. חשוב לזכור שיכול להיות שעובדים מסוימים נמצאים בחופשה או בחופשת לידה, ולכן לא יוכלו להגיב במהירות.
חשוב לוודא שהמשתמשים לא יאבדו את הגישה לנתונים או לשירותי Google שהם צריכים כתוצאה מהסכמה להעברה.