מדריך

קליטת מאות משתמשים חדשים מקובץ CSV שסופק על ידי משאבי אנוש.

→השתמש בתכונת העלאה בכמות גדולה (Bulk Upload) בקונסולת הניהול. כלול את העמודה `Org Unit Path` בקובץ ה-CSV כדי למקם משתמשים ישירות ביחידות הארגוניות (OUs) הנכונות.

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

עובד עוזב. יש לשמר את קבצי ה-Drive שלו ולהעבירם לשליטת המנהל שלו.

→לפני השעיה או מחיקה של המשתמש, השתמש בכלי העברת הנתונים בקונסולת הניהול כדי להעביר בעלות על כל קבצי ה-Drive למנהל.

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

מחלקות וצוותים שונים דורשים הגדרות שירות ומדיניות אבטחה ייחודיות.

→צור מבנה היררכי של יחידות ארגוניות (OU) (לדוגמה, /Sales/East, /Sales/West). החל מדיניות רחבה ביחידת הארגון ההורה והגדרות ספציפיות ביחידות הארגון הצאצאיות.

למה: יחידות ארגוניות (OUs) מספקות הורשת מדיניות היררכית, המאפשרת שליטה מדרגית ומפורטת על הגדרות עבור אוכלוסיות משתמשים שונות.

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

→צור קבוצה דינמית עם שאילתת חברות המבוססת על תכונת המשתמש `department==Engineering`.

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

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

→צור תפקיד מנהל מותאם אישית עם הרשאת "משתמשים > איפוס סיסמה" בלבד. הקצה תפקיד זה לצוות התמיכה וקבע את היקפו כך שיחול רק על יחידת הארגון (OU) היעד.

למה: מיישם את עקרון ההרשאה המינימלית. תפקידים מותאמים אישית עם היקף מוגדר מונעים ממנהלים מואצלים להשפיע על משתמשים או הגדרות מחוץ לתחום אחריותם.

סנכרון מ-Active Directory באמצעות GCDS, אך ל-UPNs של המשתמשים יש דומיין ישן. יש ליצור משתמשים עם הדומיין החדש והנכון.

→ב-GCDS, הגדר כלל טרנספורמציית תכונה עבור תכונת כתובת האימייל כדי להחליף את מחרוזת הדומיין הישנה בחדשה.

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

משתמש נמחק בטעות לפני 15 ימים. המנהל שלו זקוק כעת לקובץ קריטי מ-Drive שלו.

→מתוך קונסולת הניהול, שחזר את המשתמש שנמחק לאחרונה. חלון השחזור הוא 20 יום. לאחר השחזור, העבר את הנתונים, ואז מחק מחדש במידת הצורך.

למה: משתמשים שנמחקו ניתנים לשחזור למשך 20 יום. זו הדרך היחידה לשחזר את הנתונים שלהם אם לא הוגדרה מדיניות Vault hold/retention.

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

→צור קבוצת Google והגדר אותה כ"תיבת דואר נכנס שיתופית" (Collaborative Inbox).

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

אכוף הצהרה משפטית מוגדרת ומיתוג אחיד על כל האימיילים היוצאים ממחלקת המכירות.

→בהגדרות Gmail, הגדר כלל תאימות עם פעולת "הוספת כותרת תחתונה" (Append footer), שהיקפה מוגדר ליחידה הארגונית (OU) של המכירות.

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

אפשר למשתמשים לשתף קבצי Drive חיצונית, אך רק עם דומיינים ספציפיים ומאושרים של שותפים.

→בהגדרות שיתוף של Drive, הוסף דומיינים של שותפים לרשימת "דומיינים מותרים" (Allowlisted domains) והגדר את מדיניות השיתוף ל"דומיינים מותרים בלבד".

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

אפשר לאורחים חיצוניים ב-Google Meet, אך מנע מהם להצטרף לפני הגעת מארח פנימי.

→בהגדרות הבטיחות של Google Meet, ודא שהאפשרות "המארח חייב לאשר אנשים מחוץ לארגון שלך" (דפיקה) מופעלת.

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

הגירה משרת Exchange מקומי ל-Gmail עם אפס השבתה עבור דואר נכנס.

→הגדר "מסירה כפולה" (dual delivery). הגדר נתיב דואר ב-Workspace כדי להעביר דואר לשרת Exchange הישן, ולאחר מכן הפנה רשומות MX ל-Google.

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

מנע ממשתמשים להתקין הרחבות צד שלישי לא מאושרות ב-Docs, Sheets וב-Gmail.

→בהגדרות Marketplace, הגדר רשימת יישומים מורשים (allowlist) וקבע את המדיניות כך שתגביל משתמשים ליישומים ברשימה המורשית בלבד.

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

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

→ב-Google Vault, צור כלל שמירה מותאם אישית עבור Gmail עם משך של 7 שנים. אל תגדיר תאריך תפוגה.

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

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

→ב-Google Vault, צור "עניין" (Matter), זהה את המשתמשים כנאמנים, והחל עליהם "החזקה משפטית" (Legal Hold).

למה: החזקה משפטית (Legal Hold) עוקפת את כל מדיניות השמירה והמחיקה. הנתונים נשמרים עד לשחרור מפורש של ההחזקה, ומבטיחים עמידה בהתחייבויות שימור משפטיות.

מנע ממשתמשים לשתף בטעות מסמכים המכילים מספרי כרטיסי אשראי או PII עם גורמים חיצוניים.

→צור כלל למניעת אובדן נתונים (DLP) ב`אבטחה > הגנת נתונים`. השתמש במאתרים מוגדרים מראש (לדוגמה, מספר כרטיס אשראי) והגדר את תנאי ההפעלה עבור שיתוף חיצוני. הפעולה צריכה להיות "חסימת שיתוף חיצוני".

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

כדי לציית ל-GDPR, ודא שכל הנתונים הראשיים של עובדים אירופאים מאוחסנים במנוחה (at-rest) בתוך מרכזי נתונים אירופאיים.

→מקם משתמשים אירופאים ביחידת ארגון (OU) ייעודית. ב`חשבון > אזורי נתונים`, החל מדיניות אזור נתונים עבור "אירופה" על אותה יחידת ארגון.

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

משתמש מחק לצמיתות קובץ Drive קריטי לפני 10 ימים. הוא כבר לא נמצא באשפה שלו.

→אם כלל שמירה או החזקה של Vault כיסה את המשתמש, חפש את הקובץ ב-Vault וייצא אותו לצורך שחזור.

למה: Vault משמש כרשת ביטחון. נתונים המכוסים על ידי שמירה/החזקות נשמרים גם לאחר שנמחקו "לצמיתות" על ידי המשתמש.

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

→השעה את חשבון המשתמש והקצה רישיון "משתמש בארכיון" (AU). הנתונים נשארים ב-Vault וכפופים להחזקה.

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

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

→הגדר גישה מודעת הקשר (Context-Aware Access). צור רמות גישה עבור "מכשיר תואם" (מניהול נקודות קצה) ו"טווח IP ארגוני". החל מדיניות הדורשת אחת מרמות אלה לגישה.

למה: זהו הליבה של מודל אפס אמון (zero-trust) עבור Workspace, המעבר מפירמטר רשתי לאכיפת מדיניות גישה המבוססת על הקשר המכשיר והמשתמש, ללא קשר למיקום.

חשבון משתמש חשוד שנפרץ. ייתכן שלתוקף יש הפעלות פעילות או גישת אפליקציות.

→מיידית: 1) אפס את סיסמת המשתמש. 2) בטל את כל אסימוני OAuth של צד שלישי. 3) צא מכל ההפעלות ברשת.

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

מנע ממשתמשים להעניק גישה לנתונים ארגוניים ליישומי OAuth של צד שלישי מסוכנים או לא מאושרים.

→ב`אבטחה > בקרות API`, הגדר "בקרת גישת יישומים" כדי לחסום יישומים לא מוגדרים כברירת מחדל, ולאחר מכן הוסף יישומים ספציפיים ומאושרים לרשימת ה"אמינים".

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

יישם כניסה יחידה (SSO) עם IdP של צד שלישי, אך ודא גישת מנהל אם ה-IdP מושבת.

→הגדר SAML SSO עבור הארגון כולו. צור קבוצה או OU נפרדת עבור מנהלי על (Super Admins) והגדר מסיכת רשת או הגדרת קבוצה כדי להחריג אותם מדרישת ה-SSO.

למה: מספק הליך "שבירת זכוכית" (break-glass) קריטי, המאפשר למנהלים להיכנס עם אישורי Google במהלך השבתת IdP כדי לנהל את הסביבה.

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

→הגדר כראוי רשומות DNS מסוג SPF, DKIM ו-DMARC עבור הדומיין שלך. הגדר את מדיניות DMARC ל-`p=reject` לאכיפה מלאה.

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

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

→עקוב באופן קבוע אחר מרכז ההתראות (Alert Center). הגדר כללי התראה לשליחת התראות אימייל עבור אירועים בעדיפות גבוהה לצוות האבטחה.

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

משתמש איבד את הטלפון שלו ואין לו קודי גיבוי, מה שנועל אותו מחוץ לחשבון המוגן ב-2SV שלו.

→כמנהל, בחר את המשתמש וצור עבורו קודי אימות גיבוי לשימוש חד-פעמי כדי שיקבל גישה מחדש.

למה: זהו ההליך הסטנדרטי והמאובטח לשחזור משתמש מבלי צורך להשבית באופן זמני את 2SV, דבר שיחליש את האבטחה.

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

→אכוף מדיניות אימות דו-שלבי (2-Step Verification) הדורשת שימוש במפתחות אבטחה (FIDO) בלבד.

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

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

→באמצעות קונסולת הניהול תחת "מכשירים", אתר את המכשיר ושלח מיד פקודת "מחיקת מכשיר" (Wipe device) מרחוק.

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

אכוף סט סטנדרטי של הגדרות אבטחה והרחבות חובה בכל דפדפני Chrome הארגוניים (Windows, Mac).

→רשום דפדפנים ל-Chrome Browser Cloud Management (CBCM). החל מדיניות על יחידת הארגון (OU) של המשתמש/דפדפן כדי לאלץ התקנת הרחבות, לחסום אחרות ולהגדיר הגדרות.

למה: CBCM מספק ניהול מרכזי, מבוסס ענן, של דפדפני Chrome בכל פלטפורמה, ומבטיח מדיניות ועמדת אבטחה עקביות.

אפשר לעובדים להשתמש במכשירי Android אישיים לעבודה (BYOD) תוך שמירה על נתוני הארגון נפרדים ומאובטחים.

→יישם ניהול נייד מתקדם (Advanced Mobile Management) ואכוף יצירת פרופיל עבודה של Android במכשירים בבעלות עובדים.

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

מדיניות גישה מודעת הקשר (Context-Aware Access) חייבת לוודא שמכשיר נמצא בבעלות החברה ומוצפן לפני מתן גישה.

→פרוס את הרחבת/סוכן Google Endpoint Verification לכל המכשירים המנוהלים. הגדר את רמת הגישה של CAA לדרוש סטטוס מכשיר "תואם" או "בבעלות החברה".

למה: Endpoint Verification הוא הסוכן שאוסף ומדווח על מצב המכשיר למנוע ה-CAA, ומאפשר בקרת גישה מבוססת אמון מכשירים.

משתמשים מדווחים כי אימיילים לשותף ספציפי מוחזרים או מתעכבים באופן חמור.

→השתמש בכלי "חיפוש יומן אימייל" (Email Log Search) בקונסולת הניהול. חפש הודעה לדוגמה כדי לראות את נתיב המסירה המלא, חותמות זמן, וכל שגיאות דחייה משרת הנמען.

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

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

→הבעיה ככל הנראה נמצאת אצל ספק הזהויות (IdP) של צד שלישי. בדוק את מצב שירות ה-IdP ואת תוקף תעודת ה-SAML בהגדרת ה-SSO.

למה: כשלים נרחבים ופתאומיים בכניסה בסביבת SSO כמעט תמיד מצביעים על ה-IdP החיצוני, ולא על חשבונות משתמשים בודדים.

משתמש מדווח שקודי 6 הספרות מאפליקציית Google Authenticator שלו נדחים באופן עקבי.

→הורה למשתמש לבדוק ולסנכרן את השעון במכשיר הנייד שלו. לאפליקציית Authenticator יש תכונת תיקון זמן.

למה: קודי TOTP (Time-based OTP) תלויים מאוד בזמן מסונכרן. סטיית שעון היא הגורם השכיח ביותר לדחיית קודים.

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

→בדוק את הרשת המקומית במשרד המושפע. בדוק רוויית רוחב פס, השהיה/גמגום גבוהים, וודא שכללי חומת האש אינם מגבילים או חוסמים תעבורת Google Meet.

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

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

→בדוק את הגדרות ה-Gmail האישיות של המשתמש עבור מסננים כלשהם או כללי חסימת שולחים שעשויים להפנות או למחוק את האימיילים הנכנסים.

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

משתמש יכול להתחיל הקלטה ב-Meet, אך היא נכשלת בשמירה לאחר סיום הפגישה.

→בדוק את מכסת האחסון של Google Drive של המשתמש. הקלטות נכשלות אם למשתמש אין מספיק מקום.

למה: הקלטות Meet נשמרות ל"האחסון שלי" (My Drive) של המארגן בתיקיית "הקלטות Meet". מכסת Drive מלאה היא הסיבה הנפוצה ביותר לכשלי שמירה.