במאמר הזה מוסבר איך להעביר חשבונות לשימוש אישי לחשבונות משתמשים מנוהלים שמנוהלים על ידי 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), הם מופנים לספק זהויות חיצוני כדי לבצע אימות. אחרי שהם מאומתים, הם יכולים להשתמש בחשבון כמו בכל חשבון מנוהל אחר. עם זאת, מכיוון שאף אחד מהנתונים לא הועבר מהחשבון המקורי לשימוש אישי, זה למעשה חשבון חדש.
אם המשתמש בוחר באפשרות השנייה במסך ההצבעה, הוא מתבקש לשנות את כתובת האימייל של החלק הצרכני בחשבון בעל מאפיינים זהים לחשבון פעיל.
שינוי כתובת האימייל פותר את הבעיה כי הוא מבטיח שלחשבון המנוהל ולחשבון הפרטי יהיו שוב זהויות שונות. התוצאה היא שיהיה להם חשבון פרטי אחד עם כל הנתונים המקוריים, וחשבון מנוהל אחד ללא גישה לנתונים המקוריים.
המשתמש יכול לדחות את שינוי השם של החשבון על ידי לחיצה על אעשה זאת מאוחר יותר. הפעולה הזו תגרום לכך שהחשבון יהיה במצב הוצאה. במצב הזה, המשתמש רואה את אותו מסך בחירות בכל פעם שהוא נכנס לחשבון, ולחשבון מוקצית כתובת אימייל זמנית 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 שהם צריכים כתוצאה מההסכמה להעברה.