5. השלמת משימות לפני ההעברה

בסביבות המקור והיעד יש משימות שונות שצריך לבצע לפני שאפשר לאשר העברת דומיין ב-Google Workspace.

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

המשימות שצריך לבצע לפני ההעברה

שלב 1: משימות במקור

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

    הערות:

    • כדי להימנע מעלויות, אתם יכולים להשתמש ברישיונות זמניים או ברישיונות לתקופת ניסיון בסביבת המקור. עם זאת, חשוב לשים לב לנקודות הבאות:
      • הרישיונות האלה חוסמים את התהליך של החלפת כל דומיין אחר בדומיין הראשי. לשנות את הדומיין הראשי לפני שמקצים רישיונות זמניים.
      • אם הרישיונות שזמינים בסביבת היעד הם רישיונות מלאים, המשתמשים יקבלו רישיונות מלאים כתוצאה מההעברה.
    • משתמשים בסביבת המקור שלא הוקצו להם רישיונות עדיין מועברים.
  2. לבטל מינויים לרישיונות שלא נתמכים – יכולות להיות לכך השלכות. בסביבות מקור עם Google Voice צריך לשים לב במיוחד לשלב הזה. פרטים נוספים זמינים בקטע רישיונות במקור.
  3. הוספת דומיין פלייסהולדר ל-Google Workspace (אם רלוונטי) – מוסיפים ומאמתים שם דומיין משני חדש בסביבת המקור, שבסופו של דבר יחליף את הדומיין הראשי הקיים. אם יש דומיין משני שלא צריך להעביר, אפשר להשתמש בו במקום זאת. פרטים נוספים זמינים במאמר הוספת דומיין חלופי או דומיין משני של משתמש.
  4. יצירת אדמין זמני והגדרתו כאדמין הראשי של החשבון – יוצרים חשבון משתמש שמשויך לדומיין הזמני. אם אתם משתמשים בחשבון ישן, ודאו שאין דומיינים אחרים להעברה שמקושרים לחשבון ככתובות אימייל חלופיות. מקצים למשתמש הזה את תפקיד הסופר-אדמין והופכים אותו לאדמין הראשי בחשבון. מידע נוסף זמין במאמר איך לשלוח התראות על חיובים וחשבונות לאדמין אחר. מוודאים שהאימות הדו-שלבי של Google מוגדר ונכנסים לפחות פעם אחת כדי לאמת את הגישה באמצעות חשבון האדמין הזמני.
  5. החלפת הדומיין הראשי בדומיין הפלייסהולדר – מבצעים החלפת דומיין, ומקדמים את דומיין הפלייסהולדר לדומיין הראשי החדש.

    לפני שמחליפים את הדומיין:

    כשתהיו מוכנים להחליף, עברו אל שינוי הדומיין הראשי ב-Google Workspace.

    • מבטלים את כל המינויים למכשירים, כולל ציוד ל-Google Meet ו-Chrome Enterprise.
    • יכול להיות שתצטרכו להסיר חלק מהרישיונות שלא נתמכים כדי לבצע את ההעברה. פרטים נוספים זמינים בקטע רישיונות במקור.
    • אם בסביבת המקור יש רישיונות לתקופת ניסיון, ההחלפה תיחסם. חשוב לוודא שההחלפה מתבצעת לפני שמוקצים רישיונות זמניים.
    • יש בעיות מוכרות בשינוי הדומיין הראשי ובשימוש בדומיינים משניים. מידע נוסף על חלופות לשינוי הדומיין הראשי
    • אל תשנו את השם של משתמשי ההעברה או של הקבוצות אחרי ששיניתם את שם הדומיין הראשי. המשתמשים והקבוצות צריכים להישאר בדומיינים להעברה.
    • אם הגדרתם כניסה יחידה (SSO) באמצעות ספק זהויות מצד שלישי ואתם משתמשים במנפיק ספציפי לדומיין, טענת הנכוֹנוּת (assertion) ב-SAML משתנה בהתאם לדומיין הראשי החדש. כדי לוודא שהמשתמשים יוכלו לבצע אימות אחרי החלפת הדומיין הראשי, צריך לבדוק את ההגדרה של ספק הזהויות. למידע נוסף כדאי לעיין במאמר בנושא דרישות טענת נכוֹנוּת (assertion) ב-SSO.
  6. להגדיר כללי שמירה ב-Google Vault – מגדירים כללי שמירה מותאמים אישית ללא הגבלת זמן.

    יוצרים כלל אחד לאפליקציות הבאות:

    • Gmail – בקטע "יחידה ארגונית", בוחרים את היחידה הארגונית ברמה הבסיסית (root).
    • אפליקציית Gemini – בוחרים את היחידה הארגונית ברמה העליונה.
    • קבוצות Google – בוחרים באפשרות "כל הקבוצות".

    יוצרים 2 כללים לאפליקציות הבאות:

    • Chat – בוחרים באפשרות יחידה ארגונית ואז היחידה הארגונית ברמה הבסיסית. לכלל השני, בוחרים באפשרות כל המרחבים המשותפים ב-Chat.
    • Drive – בוחרים באפשרות יחידה ארגונית ואז היחידה הארגונית ברמה הבסיסית (root). בכלל השני, בוחרים באפשרות כל תיקיות האחסון השיתופי.
    • ‫Meet – בוחרים באפשרות יחידה ארגונית ואז היחידה הארגונית ברמה הבסיסית ומפעילים את האפשרות כולל פריטים מתיקיות אחסון שיתופי. בכלל השני, בוחרים באפשרות כל תיקיות האחסון השיתופי.
    • Google Sites – בוחרים באפשרות יחידה ארגונית ואז היחידה הארגונית ברמה הבסיסית ומפעילים את האפשרות כולל פריטים מתיקיות אחסון שיתופי. בכלל השני, בוחרים באפשרות כל תיקיות האחסון השיתופי.

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

  7. עדכון רשומת Sender Policy Framework ‏ (SPF) (אם רלוונטי) – אם בסביבת היעד משתמשים בשער דואר יוצא שונה מזה שבסביבת המקור, צריך לעדכן את רשומת ה-SPF של המקור כך שתכלול את שער הדואר היוצא.

    הערה: אם אתם משתמשים ב-DomainKeys Identified Mail ‏ (DKIM), ההעברה לא אמורה להשפיע על המדיניות שלכם בנושא פרוטוקול מבוסס-דומיין לאימות, דיווח והתאמה של הודעות (DMARC). רשומת ה-SPF תמשיך להתאים אחרי ההעברה, גם אם ה-DKIM לא יתאים באופן זמני. בנוסף, חשוב להשלים את המשימה של DKIM לאחר ההעברה בסביבת היעד.

  8. פתרון מחלוקות בנושא משאבים לתזמון ביומן – אם יש מחלוקות בנושא משאבים לתזמון ביומן, צריך לפתור אותן לפני שממשיכים:
    • מזהי מבנים – מזהה מבנה בסביבת המקור לא יכול להיות זהה למזהה מבנה בסביבת היעד. יש שתי דרכים לעקוף את חסימת ההעברה. אתם יכולים למחוק את הבניין בסביבת המקור. אפשר גם להגדיר את הפרטים של שני המבנים כך שיהיו זהים, כדי למזג את מבנה המקור ומבנה היעד. כדי שהמבנים יהיו זהים, צריך להגדיר את המזהה, השם, כל שדות הכתובת, התיאור והקומה באופן זהה בשני המבנים.
    • שמות של מבנים – אם למשאב מבנה בסביבת המקור יש שם זהה לשם של משאב מבנה בסביבת היעד, צריך לשנות את השם של אחד מהמשאבים כדי לפתור את ההתנגשות. אחרי שתהליך ההעברה מסתיים, אפשר למזג את שני משאבי המבנים.
    • מזהי משאבים – אם בסביבת המקור יש משאב עם מזהה זהה לזה של משאב בסביבת היעד, נוצרת התנגשות שתהליך ההעברה לא יכול לפתור, והמשאב לא יועבר. למחוק את אחד מהמשאבים שמתנגשים וליצור אותו מחדש עם מזהה שלא מתנגש. משאב שנמחק יוסר מהמערכת באופן סופי תוך 30 ימים. אתם יכולים לחכות עד שהמשאב יימחק לגמרי, או שצוות העברת הדומיין יכול לשלוח בקשה למחוק אותו ידנית.
  9. הערכת ההשפעה על הארגון המשויך ב-Google Cloud (אם רלוונטי) – אם משתמשים ב-Google Cloud, צריך להודיע לאדמינים של הסביבה הזו על ההשפעות הפוטנציאליות של העברת הדומיין ב-Google Workspace על Google Cloud. במקרה הצורך, אפשר לפנות לשותף של Google Cloud או לאנשי הקשר ב-Google Cloud כדי לקבל עזרה בהערכת ההשפעות ובשלבי התיקון. צוות Google Workspace Domain Transfer לא מציע עזרה עם Google Cloud במהלך העברת דומיין.
  10. מודיעים למפיץ של Google Workspace (אם רלוונטי) – מודיעים לו על מועד העברת הדומיין המתוכנן ומבקשים ממנו לא לשנות את החשבון (למשל, לעדכן מינויים) במהלך תקופת ההעברה.

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

  12. כדי להעביר מכשירי Chrome שמשויכים אוטומטית לארגון:
    1. בסביבת המקור, מבטלים את האסימון הקיים להקצאה מראש ומבטלים את ניהול ההקצאות בכל המכשירים. מאפסים את המכשירים להגדרות המקוריות.
    2. בסביבת היעד, יוצרים טוקן חדש להקצאה מראש.
    3. מספקים את הטוקן החדש לשותף המורשה להקצאה ידנית. השותף משתמש בטוקן כדי להקצות מראש את המכשירים בסביבת היעד.

    המכשירים משויכים לארגון באופן אוטומטי כשהם מתחברים לאינטרנט. מצב המכשיר משתנה ל"הוקצה".

    מידע נוסף על מכשירים עם שיוך אוטומטי לארגון זמין במאמר בנושא שיוך אוטומטי לארגון.

  13. מחיקת חשבונות אורחים – דומיינים של אורחים וחשבונות אורחים לא מועברים לסביבת היעד. להשבית את ההזמנות לאורחים ולמחוק את כל חשבונות האורחים הקיימים.

    כדי להשבית את האפשרות להזמין משתתפים:

    1. במסוף Admin, נכנסים אל תפריט ואז אבטחה ואז אפשרויות לניהול השימוש בנתונים ואז שיתוף חיצוני.
    2. מבטלים את הסימון בתיבה המשתמשים יוכלו לשלוח הזמנות לאורחים מחוץ לארגון.

    כדי למחוק חשבונות אורחים:

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

    1. במסוף Google Admin, נכנסים לתפריט ואז מכשירים ואז ניידים ונקודות קצה ואז הגדרות ואז אוניברסליות.

      נדרשת הרשאת אדמין לניהול מכשירים ניידים.

    2. לוחצים על כללי ואז ניהול מכשירים ניידים ובוחרים אפשרות:
      • בסיסי (ללא סוכן) – אתם יכולים לאכוף דרישות בסיסיות לגבי קוד הגישה של מסך הנעילה, לפרוס אפליקציות מנוהלות ולמחוק מרחוק רק את חשבון העבודה (לא מידע אישי) אם המכשיר אבד או נגנב.
      • מתקדם (נדרשת אפליקציית Device Policy) – כל התכונות של הניהול הבסיסי, וגם ניהול אפליקציות, איפוס נתונים במכשירים המחוברים לרשת אחרת ואישורי מכשירים.
      • בהתאמה אישית – הגדרת תכונות ניהול לפי פלטפורמת המכשיר.
      • השבתת הניהול של מכשירים ניידים (לא מנוהל) – המשתמשים יכולים להוסיף את חשבון העבודה שלהם ולגשת לנתונים של הארגון (כמו Gmail ו-Drive) בלי מדיניות אבטחה או אמצעי בקרה ניהוליים.
    3. לוחצים על שמירה.

שלב 2: משימות ביעד

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

    אם בסביבת היעד משתמשים במהדורה שונה של Google Workspace מזו שבסביבת המקור, צריך לוודא שהרישיונות תואמים על ידי שדרוג הרישיונות בסביבת המקור או בסביבת היעד.

    הערות:

    • ‫Google ממליצה לשדרג את הרישיונות כדי למנוע את הפעלת תהליך מחיקת השירות (SWP).
    • מקצים את כל הרישיונות החסרים כדי שיהיו כמה מינויים בסביבת היעד. אחרי ההעברה, אפשר לשדרג או לשנמך רישיונות של משתמשים ספציפיים. חשוב לזכור שלא כל סוגי הרישיונות תומכים ברישוי דומיין בשיטה חלקית (PDL).
    • חשוב לוודא שיש מספיק רישיונות פנויים בסביבת היעד. חשוב לבדוק אם נוספו עוד משתמשים (לדוגמה, עובדים חדשים) לכל סביבת מקור בין ההתחלה לסיום של תהליך ההעברה. אם יש כמה העברות, צריך גם להביא בחשבון את המספר הכולל של משתמשי המקור בכל ההעברות.
    • משתמשים בסביבת המקור שלא הוקצו להם רישיונות עדיין מועברים. כדאי לעקוב אחרי ההקצאה האוטומטית של הרישיונות בסביבת היעד כדי לוודא שהמשתמשים האלה לא מקבלים רישיונות.
    • בהעברת דומיין אין תוכניות חיוב מיוחדות של Google Workspace שמאפשרות לרכוש רישיונות מיותרים במהלך ההעברה. אם הרישיונות בסביבת המקור הם במסגרת תוכנית חיוב שנתית, הם נשארים פעילים ומחויבים עד לסיום החוזה של התוכנית השנתית. אם יש לכם שאלות נוספות לגבי תוכניות החיוב של Google Workspace, אתם יכולים להתייעץ עם נציג המכירות או עם מנהל החשבון שלכם.

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

    כדי לוודא שלא יהיו שינויים בלתי צפויים ברישיונות במהלך ההעברה, צריך לבצע את הפעולות הבאות:

    • אם הגדרת הרישוי האוטומטי בסביבת היעד היא "מושבת לכולם" או אם יש בסביבת היעד רק סוג רישיון אחד, לא צריך לבצע שינויים.
    • אם הגדרת הרישוי האוטומטי בסביבת היעד היא "מופעל לכולם" (לדוגמה, רישיונות Google Workspace), צריך לוודא שההגדרה "שינוי" מופעלת ביחידות ארגוניות ספציפיות. ביחידה הארגונית ברמה הבסיסית (root) שמועברת, צריך לוודא שהגדרת הרישוי האוטומטי מושבתת, בלי שינויים נוספים ביחידות הבת הארגוניות.

  3. יוצרים את היחידה הארגונית ברמה הבסיסית (root) להעברה, ואם רוצים, יוצרים מחדש את מבנה היחידה הארגונית של סביבת המקור – יוצרים יחידה ארגונית שתשמש כיחידה הארגונית ברמה העליונה לכל המשתמשים שמועברים. אחרי שיוצרים את הקבוצה, יש 2 אפשרויות:

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

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

  4. להגדיר את כללי המדיניות וההגדרות המתאימים בהתאם לדרישות של סביבת המקור וסביבת היעד – כללי המדיניות וההגדרות בסביבת המקור לא מועברים לסביבת היעד. בנוסף, אחרי שתהליך ההעברה מסתיים, רק כללי המדיניות וההגדרות בסביבת היעד חלים על המשתמשים שהועברו ועל הנתונים שלהם.

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

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

    • הפעלת שירותים (הפעלה/השבתה) – מוודאים שהשירותים שבהם אתם משתמשים בסביבת המקור מופעלים בסביבת היעד, ושהיחידה הארגונית הבסיסית להעברה פועלת כמצופה. זה חשוב במיוחד כשמשתמשים ב-Google Vault, כי יכול להיות שהכללים של Vault לא יחולו אם השירות מושבת.
    • Gmail, הגדרות מתקדמות ורשומות MX – בודקים הגדרות כמו ניתוב אימייל, כללי תאימות, הפעלת IMAP והקצאת הרשאות. לפרטים, אפשר לעבור למאמר בנושא הפעלת Gmail עם Google Workspace.
    • ניהול סיסמאות – כדאי לבדוק את כללי המדיניות בנושא סיסמאות כדי לוודא שהם תואמים לנהלים של הארגון. אחרי שהמשתמשים מועברים לסביבת היעד, הם מקבלים את כללי המדיניות לניהול סיסמאות שמוגדרים בסביבת היעד.
    • אימות דו-שלבי – קובע אם המשתמשים יכולים להוסיף לחשבון שלהם הגדרה של אימות דו-שלבי, אם זה מותר או אם זה נאכף. אם משתמשים שמועברים עם אימות דו-שלבי מופעל מועברים לסביבת יעד או ליחידה ארגונית שבהן האימות הדו-שלבי מושבת, האדמינים ביעד לא יוכלו לנהל אותם. במקום זאת, אדמינים יכולים להעביר את המשתמשים האלה ליחידה ארגונית אחרת שבה האימות הדו-שלבי מופעל כדי לבצע שינויים, או להסיר את האימות הדו-שלבי מהחשבונות לפני ההעברה.
    • הרשאות שיתוף – קובעות אם המשתמשים יכולים לשתף את התוכן שלהם מחוץ לארגון. אם סביבת המקור חוסמת שיתוף וסביבת היעד לא, יכול להיות שאפשר יהיה לגשת לתוכן שמועבר מחוץ לארגון. אם בסביבת המקור מוגדר שיתוף פתוח כברירת מחדל ובסביבת היעד לא, יכול להיות שלמשתמשים בארגון לא תהיה גישה לתוכן שמועבר. מידע נוסף על אפשרויות השיתוף ב-Google Drive וביומן Google
    • מניעת אובדן נתונים (DLP) – שימוש בכללי הגנה על נתונים כדי לעקוב אחרי שיתוף של מידע אישי רגיש מחוץ לארגון ולמנוע אותו. אם DLP מונע ממשתמשים לשתף מידע בסביבת המקור, והתוכן מועבר לסביבת יעד שלא מוגדר בה DLP, המשתמשים בסביבת היעד יכולים לשתף מידע מחוץ לארגון. מידע נוסף על DLP וכללי הגנה על נתונים ועל כללי תאימות תוכן ל-Gmail.
    • היסטוריית הצ'אט – קובעת אם היסטוריית הצ'אט תתועד או לא לציטוט, ואם המשתמשים יכולים להגדיר אכיפה בכל הצ'אטים או להגדיר אותה כברירת מחדל. אם בסביבת המקור אפשר להפעיל את היסטוריית הצ'אט, אבל בסביבת היעד היא מושבתת, היסטוריית הצ'אט תאבד. למרות ש-Google Chat מופיע ברשימת השירותים שלא נתמכים בהעברה, הצ'אטים האישיים יועברו.
    • מדינות או אזורים לאחסון נתונים – קובעים באיזה מיקום גיאוגרפי ספציפי יאוחסנו הנתונים שהועברו. משתמשים להעברה שצריכים להישאר במיקום גיאוגרפי מסוים חייבים להגדיר את המדיניות הזו בסביבת היעד, כדי לוודא שהנתונים שלהם לא עוברים באופן בלתי צפוי מהמדינה או האזור הנדרשים. פרטים נוספים מופיעים במאמר בנושא אזורים גיאוגרפיים לאחסון נתונים: בחירת מיקום גיאוגרפי לנתונים.
    • אפליקציות ברמת אבטחה נמוכה (שנקראות גם סיסמאות לאפליקציות) – אם הגישה לאפליקציות ברמת אבטחה נמוכה מופעלת בסביבת המקור ומושבתת בסביבת היעד, החיבור לאפליקציה שמשתמשת באפליקציות ברמת אבטחה נמוכה יסתיים וייסגר. תקופות הזמן הקצוב לתפוגה משתנות בהתאם לאפליקציה, אבל בדרך כלל הן פגות תוך 60 דקות. בקשות גישה עתידיות של האפליקציה הלא מאובטחת ייחסמו. פרטים נוספים זמינים במאמר שליטה על הגישה לאפליקציות ברמת אבטחה נמוכה.
    • היקפי הרשאות OAuth, כניסה יחידה (SSO) ל-SAML, אפליקציות מהימנות ותוספים ל-Chrome – אמצעי הבקרה של OAuth קובעים את רמת הגישה ל-API שניתנת למשתמשים ולאפליקציות של צד שלישי. כניסה יחידה (SSO) ל-SAML, בין אם היא מסופקת על ידי Google Workspace או מוטמעת כאפליקציה בהתאמה אישית, מאפשרת למשתמשים להשתמש בפרטי הכניסה שלהם ב-Google Workspace כדי לגשת לאפליקציות או לשירותים אחרים. אפליקציות מהימנות קובעות אילו אפליקציות המשתמשים יכולים להתקין מ-Google Workspace Marketplace או מחנות האינטרנט של Chrome, ואילו אפליקציות יכולות לעקוף את הגבלות OAuth. מידע נוסף על אופן השליטה באפליקציות של צד שלישי ואפליקציות פנימיות, כניסה יחידה (SSO) באמצעות SAML, אפליקציות של Google Workspace Marketplace ואפליקציות ותוספים ל-Chrome.
    • הענקת גישה ברמת הדומיין – מאפשרת לאפליקציות לגשת לנתוני המשתמשים ב-Google Workspace. כדי לוודא שהלקוחות וההיקפים פועלים כמו שצריך, צריך להגדיר את ההעברה ברמת הדומיין בסביבת היעד לפני ההעברה.

    חשוב: אם לא תגדירו את כללי המדיניות וההגדרות כמו שצריך, יכול להיות ש:

    • חשיפה לא מכוונת של הנתונים מחוץ לארגון (לדוגמה, סביבת היעד כוללת יותר הגדרות פתוחות מסביבת המקור)
    • גישה מוגבלת לנתונים שהיו נגישים בעבר (לדוגמה, בסביבת היעד יש הגדרות מגבילות יותר מאשר בסביבת המקור)
  5. לאשר את ההסכמים שחלים על הנתונים שמועברים – בודקים את התיקון לעיבוד נתונים (DPA), את סעיף החוזה לדוגמה ואת התיקון בנושא שותפים עסקיים לפי HIPAA‏ (BAA) בסביבת היעד. פרטים נוספים זמינים במאמר עמידה בדרישות הפרטיות וניהול רשומות בסביבות Google Workspace ו-Cloud Identity.
  6. הפעלת Vault אם משתמשים בו בסביבת המקור – אם לא משתמשים ב-Vault בסביבת היעד אבל כן משתמשים בו בסביבת המקור, צריך להפעיל את Vault בסביבת היעד.
  7. מודיעים למפיץ של Google Workspace (אם רלוונטי) – מודיעים לו על מועד העברת הדומיין המתוכנן ומבקשים ממנו לא לשנות את החשבון (למשל, לעדכן מינויים) במהלך תקופת ההעברה.

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

חשוב:

  • שדרוג לאחור של רישיונות עלול לגרום לאובדן של שירותים ופונקציונליות ב-Google Workspace. לפני שמבצעים שינויים, חשוב לבדוק היטב את ההבדלים בין המהדורות של Google Workspace ואת ההשפעה של שדרוג או שדרוג לאחור. מידע נוסף על המהדורות של Google Workspace
  • שדרוג לאחור של רישיונות עלול להפעיל את SWP, מה שיכול לעכב את ההעברה עד 90 יום.

שלב 3: משימות ושיקולים נוספים

  • ניהול שינויים – הצוות של Google Workspace Domain Transfer ותהליך העברת הדומיין לא מספקים למשתמשים באופן אוטומטי מידע על ביצוע ההעברה במהלך התהליך. מומלץ מאוד שנציגים של סביבת המקור וסביבת היעד יידעו את המשתמשים מראש על תהליך ההעברה ועל ההשפעות האפשריות שלו.

    כל פעולות האדמין בסביבת המקור ובסביבת היעד נחסמות במהלך ההעברה, כולל הגישה ל-API ולמסוף Google Admin. מומלץ מאוד שנציגים של סביבת המקור וסביבת היעד יודיעו לכל הסופר-אדמינים והאדמינים עם ההרשאות בדומיין לפני ההעברה וגם אחרי שהיא מסתיימת.

  • תלויות חיצוניות – אם אתם משתמשים ב-Google Cloud Directory Sync ‏ (GCDS), ב-GAM (כלי של צד שלישי בשורת הפקודה שמאפשר לאדמינים ב-Google Workspace לנהל את הגדרות הדומיין והמשתמשים) או בספק של כניסה יחידה (SSO) של צד שלישי, חשוב לנתח את ההשפעה של ההעברה. כדאי גם לבדוק איך קיום משותף של סביבות המקור והיעד בסביבה אחת משפיע על המערכת ועל תזמון ההעברה.

שמירת נתונים ללא הגבלת זמן ב-Google Vault בסביבת היעד

העברת דומיין ב-Google Workspace& מגדירה כללי שמירה מותאמים אישית ללא הגבלת זמן בסביבת היעד. אדמינים של סביבת היעד לא צריכים לעשות שום דבר.

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

  • יומן Google – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: היחידה הארגונית ברמה הבסיסית (root) של ההעברה).
  • ‫Google Chat – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: צ'אטים ישירים עם משתמשים להעברה ביחידה הארגונית ברמה הבסיסית (root) להעברה, אבל לא מרחבים).
  • ‫Google Drive – כלל שמירה מותאם אישית ללא הגבלת זמן, לא כולל תיקיות אחסון שיתופי (היקף: יחידה ארגונית ברמה הבסיסית (root) של ההעברה).
  • אפליקציית Gemini – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: יחידה ארגונית ברמה הבסיסית).
  • ‫Gmail – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: היחידה הארגונית בראש ההיררכיה של ההעברה).
  • קבוצות Google – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: יחידה ארגונית ברמה הבסיסית). שומר את הנתונים של כל הקבוצות בסביבת היעד, כולל אלה שלא נכללות בתהליך ההעברה.
  • ‫Google Meet – נדרשים 2 כללי שמירה מותאמים אישית ללא הגבלת זמן:
    1. לא כולל תיקיות אחסון שיתופי (היקף: היחידה הארגונית הבסיסית להעברה).
    2. כולל כל תיקיות האחסון השיתופי (היקף: היחידה הארגונית שבראש ההיררכיה).

      שומר את הנתונים של כל האחסונים השיתופיים בסביבת היעד, כולל אלה שלא נכללים בתהליך ההעברה.

  • ‫Google Sites – נדרשים 2 כללי שמירה מותאמים אישית ללא הגבלת זמן.
    1. לא כולל תיקיות אחסון שיתופי (היקף: היחידה הארגונית הבסיסית להעברה).
    2. כולל כל תיקיות האחסון השיתופי (היקף: היחידה הארגונית שבראש ההיררכיה).

      שומר את הנתונים של כל האחסונים השיתופיים בסביבת היעד, כולל אלה שלא נכללים בתהליך ההעברה.

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

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