הקשחת Google Workspace: המדריך המעשי לעסק הקטן

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

קבוצה ראשונה — זהויות: הדלת הראשית של הדומיין

רוב הפריצות ל-Google Workspace לא מתחילות בפרצה מתוחכמת — הן מתחילות בסיסמה. לפי נתוני מערך הסייבר הלאומי ל-2025, פישינג היה וקטור התקיפה המוביל בישראל — 52% מהמתקפות. שלוש ההגדרות הראשונות סוגרות את הדלת הזו.

1. אכפו אימות דו-שלבי (2SV) על כל המשתמשים — לא רק ״אפשרו״

זו ההגדרה עם יחס העלות-תועלת הטוב ביותר שקיים: מחקר של Google (בשיתוף אוניברסיטאות NYU ו-UCSD) מצא שהוספת שלב אימות שני חוסמת 100% מהתקפות הבוטים האוטומטיות ו-99% ממתקפות הפישינג ההמוניות. הנקודה הקריטית היא לא ״האם 2SV קיים״ אלא ״האם הוא נאכף בפועל על כולם״. גוגל מבדילה בין מצב שבו משתמש *יכול* להפעיל אימות דו-שלבי לבין מצב שבו הוא *חייב*. איפה: במסוף הניהול, תחת Security ‏← Authentication ‏← 2-step verification — הפעילו Enforcement, וקבעו תקופת הרשמה (Enrollment period) קצרה לעובדים חדשים. בדקו בדוחות שאין תיבות שירות ישנות או חשבונות שנשכחו וחומקים מהאכיפה.

2. חייבו מפתחות אבטחה או Passkeys לאדמינים — לא כל 2SV נולד שווה

לא כל שיטות האימות הדו-שלבי עמידות באותה מידה. קוד ב-SMS עדיף על כלום, אבל ניתן לעקוף אותו בפישינג ובחטיפת קו סלולרי (SIM swap). השכבה החזקה ביותר היא מפתח אבטחה פיזי (FIDO) או Passkey — שתי שיטות שעמידות לפישינג מעצם התכנון, כי הן קשורות קריפטוגרפית לכתובת האתר האמיתית ולא ייכנסו לפעולה מול אתר מזויף. במחקר של גוגל, מפתחות אבטחה חסמו 100% מכל שלושת סוגי המתקפות, כולל המתקפות הממוקדות. לפחות עבור חשבונות האדמין — המטרה המועדפת על תוקפים — כדאי לחייב את השיטה הזו. איפה: תחת Security ‏← Authentication ‏← 2-step verification אפשר להגדיר ליחידה ארגונית מסוימת אכיפה של Only security key, שכיום מקבלת גם מפתחות פיזיים וגם Passkeys. הנפיקו לכל אדמין שני אמצעים לפחות, כדי לא להינעל בחוץ אם אחד אובד.

3. צמצמו את מספר ה-Super Admins — והפרידו את חשבון הניהול מהחשבון היומיומי

Super Admin ב-Google Workspace שולט בכל הדומיין — פריצה אליו היא פריצה לעסק כולו. שני עקרונות ההקשחה כאן פשוטים ומכריעים. ראשית, מיעוט אדמינים: שמרו על מספר קטן של חשבונות Super Admin (בעסק קטן, שניים עד שלושה — יותר מאחד כדי לא להינעל בחוץ, מעט ככל האפשר כדי לצמצם את שטח התקיפה), והשתמשו בתפקידי ניהול מוגבלים (Admin roles) למשימות ספציפיות במקום להעניק שליטה מלאה. שנית, חשבון ניהול ייעודי: מי שקורא מיילים ומדפדף באינטרנט עם החשבון שמנהל את כל הדומיין חושף את מפתחות הממלכה לכל מייל פישינג. חשבון ה-Super Admin צריך להיות נפרד מהחשבון היומיומי, ולשמש רק למשימות ניהול. איפה: Directory ‏← Users, וניהול התפקידים תחת Account ‏← Admin roles.

4. ודאו שהגישה בסיסמה-בלבד סגורה — עידן ה-Less Secure Apps הסתיים

במשך שנים הייתה ב-Google Workspace דלת אחורית: אפליקציות ומכשירים שהתחברו לחשבון עם שם משתמש וסיסמה בלבד (״Less Secure Apps״), דרך פרוטוקולים ישנים כמו IMAP, POP ו-SMTP. הבעיה: אימות בסיסי כזה לא יודע לעבוד עם 2SV — כלומר תוקף עם סיסמה גנובה יכול להתחבר בלי לפגוש את האימות הנוסף. החדשות הטובות: גוגל סגרה את זה. החל ממרץ 2025 חובה להשתמש ב-OAuth כדי לגשת ל-Gmail, ליומן ולאנשי הקשר מאפליקציות צד שלישי, וגישה בסיסית בסיסמה-בלבד (כולל IMAP, POP, SMTP, CalDAV ו-CardDAV עם סיסמה) הופסקה. עדיין כדאי לוודא במסוף הניהול שהגישה מנוהלת נכון, ולבדוק אילו אפליקציות ישנות התחברו כך בעבר — לרוב תגלו מדפסת-סורקת אחת או סקריפט אוטומציה שצריך להגדיר מחדש מול OAuth.

קבוצה שנייה — הדואר: הזירה של הונאות ה-BEC

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

5. פרסמו רשומות SPF, DKIM ו-DMARC לדומיין שלכם

שלוש רשומות ה-DNS האלה מונעות מאחרים לשלוח מייל בשם הדומיין שלכם — כלומר מגנות על הלקוחות והספקים שלכם מ״חשבונית מכם״ שלא אתם שלחתם. SPF מוגדר בדרך כלל בעת חיבור הדומיין. את DKIM צריך להפעיל ידנית — במסוף הניהול תחת Apps ‏← Google Workspace ‏← Gmail ‏← Authenticate email מפיקים מפתח, מפרסמים רשומת TXT אצל ספק הדומיין, ומפעילים את החתימה. את DMARC מגדירים כרשומת TXT: מתחילים במצב ניטור (p=none) כדי לראות מי שולח בשמכם, ואחרי שמוודאים שכל השולחים הלגיטימיים חתומים — מקשיחים ל-quarantine ואז ל-reject. עסק בלי DMARC אוכף הוא מטרה נוחה להתחזות מול כל אנשי הקשר שלו. גוגל מספקת בתוך המסוף גם דשבורד (DMARC/authentication) שמראה את סטטוס האימות של הדואר היוצא.

6. הפעילו את מלוא הגנות הפישינג והנוזקות של Gmail

ל-Gmail יש שכבת הגנה מובנית חזקה, אבל חלק מההגדרות המתקדמות אינן דלוקות כברירת מחדל. במסוף הניהול, תחת Apps ‏← Google Workspace ‏← Gmail ‏← Spam, phishing, and malware, ודאו שמופעלות כל תיבות הסימון של הגנת ההתחזות והנוזקות — זיהוי דומיינים דומים (lookalike), הגנה מפני התחזות לשמות בארגון, סימון מיילים לא מאומתים, וסריקת קבצים וקישורים. שדרוג משמעותי נוסף הוא Enhanced pre-delivery message scanning — סריקה מוקפדת יותר של תוכן חשוד *לפני* המסירה לתיבה. שימו לב לרישיון: התכונה הזו זמינה ב-Business Standard, ב-Business Plus ובמהדורות Enterprise — אך לא ב-Business Starter. במהדורות Enterprise מתווסף גם Security Sandbox — הרצת קבצים מצורפים בסביבה מבודדת (detonation) כדי לחשוף נוזקות לא מוכרות. איך מזהים את מה שבכל זאת עובר? מדריך זיהוי הפישינג שלנו נכתב בדיוק בשביל זה.

7. הפעילו אזהרות על שולחים חיצוניים

אחת ההגנות הפשוטות והיעילות ביותר נגד BEC והתחזות היא תווית ״חיצוני״: Gmail יכול להוסיף באנר אזהרה בראש כל מייל שמגיע מחוץ לארגון, וכן להזהיר עובד שעומד להשיב לנמען חיצוני. תווית כזו הופכת את הטריק הקלאסי — מייל ״מהמנכ״ל״ שנשלח בפועל מכתובת חיצונית — לגלוי מיד. איפה: ההגדרות נמצאות תחת Apps ‏← Google Workspace ‏← Gmail (בהגדרות המתקדמות/הבטיחות). זו הגדרה זולה, ברורה לעובדים, ובעלת ערך גבוה במיוחד בעסק שמתכתב הרבה עם ספקים.

8. סרקו חוקי העברה וסינון אוטומטיים — אחת לרבעון

חוק העברה (Forwarding) הוא כלי ההתמדה האהוב על תוקפי BEC: גם אחרי שתחליפו סיסמה, עותק של כל מייל נכנס ימשיך לזרום אליהם, וחוקי סינון נוספים יסתירו התכתבויות (למשל ימחקו הודעות ״מהנהלת חשבונות״) כדי שהקורבן לא יבחין. שתי פעולות מגן כאן. ראשית, ברמת הארגון — הגבילו או חסמו העברה אוטומטית של דואר לכתובות מחוץ לדומיין, במסוף הניהול תחת Apps ‏← Google Workspace ‏← Gmail ‏← Routing / End User Access. שנית, כפעולה תקופתית — סרקו את חוקי ההעברה והסינון הקיימים בתיבות המשתמשים, במיוחד של הנהלה והנהלת חשבונות. חוק שמעביר דואר החוצה או מוחק הודעות לפי מילות מפתח פיננסיות הוא דגל אדום בוהק.

קבוצה שלישית — קבצים, אפליקציות ושליטה

9. הקשיחו את ברירות המחדל של שיתוף ב-Drive

ב-Google Drive, קובץ אחד ששותף ״לכל מי שיש לו את הקישור״ יכול להיות דלף מידע שקט — קובץ שכתובתו זלגה לכל מקום. שתי הגדרות מפתח כאן, שתיהן תחת Apps ‏← Google Workspace ‏← Drive and Docs ‏← Sharing settings. ראשית, שיתוף חיצוני: במקום ״הכול פתוח״, הגבילו שיתוף לדומיינים חיצוניים מאומתים בלבד (allowlist), או כבו שיתוף חיצוני ליחידות ארגוניות שלא זקוקות לו. שנית, ברירת המחדל של שיתוף קישור: קבעו את Link sharing default על Off — כך כל קובץ חדש נגיש רק לבעליו ולמי ששותף אליו במפורש, במקום להיות זמין ״לכל מי שיש לו את הקישור״. ולמידע הרגיש באמת — עבדו ב-Shared Drives (כונני צוות) עם מדיניות ניהול מרוכזת, במקום בבעלות אישית שנעלמת כשעובד עוזב.

10. שלטו בגישת אפליקציות צד שלישי (OAuth) לדאטה שלכם

כאן מסתתרת אחת מנקודות העיוורון הגדולות: משתמש שמאשר לאפליקציית צד שלישי ״לקרוא את המייל שלך״ או ״לגשת ל-Drive״ מעניק לה אסימון גישה שממשיך לעבוד גם אחרי החלפת סיסמה וגם עם 2SV. תוקפים מנצלים זאת במתקפות Consent Phishing — במקום לגנוב סיסמה, הם גורמים לכם לאשר אפליקציה עוינת. הפתרון הוא API Controls / App Access Control: במקום להשאיר את שוק האפליקציות פתוח לגמרי, הגדירו מדיניות שמגבילה אילו אפליקציות רשאיות לגשת לשירותים רגישים (Gmail, Drive), והעבירו את השאר למצב חסום או מוגבל. איפה: במסוף הניהול תחת Security ‏← Access and data control ‏← API controls. באותה הזדמנות עברו על האפליקציות שכבר קיבלו הרשאות (Connected apps) והסירו כל מה שאינו מזוהה או אינו בשימוש.

11. הגדירו נמענים אמיתיים למרכז ההתראות ולכללי הפעילות

ל-Google Workspace יש Alert Center (מרכז התראות) שמתריע על אירועים מחשידים — פעילות כניסה חשודה, מכשיר שנפרץ, קמפיין פישינג שזוהה, שינויי הגדרות רגישים. החדשות הטובות: מרכז ההתראות זמין בכל המהדורות, כולל Business Starter. הבעיה הנפוצה בעסקים קטנים: אף אחד לא פותח אותו, או שההתראות מגיעות לכתובת שעובד שעזב מזמן מנהל. ודאו שהתראות בחומרה גבוהה נשלחות לכתובת מנוטרת שמישהו באמת קורא. במהדורות המתקדמות אפשר גם להגדיר Activity rules — כללים אוטומטיים שמפעילים פעולה בתגובה לאירוע. התראה שאיש לא רואה שקולה להתראה שלא נשלחה.

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

Gmail או Drive שנשארים פתוחים בדפדפן על מחשב משותף, עמדת קבלה או לפטופ ביתי — הם גישה חופשית לחשבון בלי סיסמה ובלי 2SV. תחת Security ‏← Google session control אפשר לקבוע לכמה זמן נשמר סשן פעיל לפני שנדרשת התחברות מחדש (Session length) — קיצור מברירת המחדל מקטין את חלון הסיכון במחשב זר. במקביל, במסוף הניהול תחת Devices, הפעילו ניהול מכשירים בסיסי: אכיפת נעילת מסך וקוד גישה בטלפונים שניגשים לדואר הארגוני, וחשוב מכול — מחיקה מרחוק (remote wipe) של החשבון הארגוני ממכשיר שאבד או נגנב, או של עובד שעזב. שימו לב: ניהול מכשירים מתקדם (עם מחיקה מרחוק מלאה, אכיפת קוד חזק ודוחות) מתחיל במהדורת Business Plus.

רגע, מה בכלל כלול ברישיון שלי?

חלק ניכר מהצ׳קליסט זמין בכל מהדורה עסקית, בלי לשלם שקל נוסף — אכיפת 2SV, מפתחות אבטחה, צמצום אדמינים, SPF/DKIM/DMARC, הגנות הפישינג הבסיסיות של Gmail, בקרת שיתוף ב-Drive, API Controls, בקרת סשן ומרכז ההתראות. ההבדל מתחיל ביכולות המתקדמות. כך זה מתחלק בין המהדורות העסקיות הנפוצות:

המשמעות: עסק על Business Starter או Standard יכול וצריך ליישם את רוב הרשימה עוד היום. Google Vault — הכלי לשימור מידע לצרכים משפטיים ורגולטוריים (retention) ולחילוץ מידע (eDiscovery) — מתחיל ב-Business Plus; במהדורות הנמוכות אפשר להוסיף אותו כרישיון נפרד בתשלום. שדרוג ל-Plus מצדיק את עצמו בדרך כלל כשיש מידע רגיש בתיבות ובקבצים, או כשצריך יכולת שחזור ומחיקה מרחוק של מכשירים. את השכבות החזקות ביותר — Security Sandbox, גישה מותנית-הקשר (Context-Aware Access) ודשבורד אבטחה מרכזי — גוגל שומרת למהדורות Enterprise.

צ׳קליסט הסקירה הרבעונית — 20 דקות, ארבע פעמים בשנה

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

1. אדמינים: ודאו שרשימת ה-Super Admins עדיין מונה 2–3 חשבונות ייעודיים בלבד — ושכולם עדיין עובדים אצלכם ומאובטחים במפתח אבטחה.
2. רישום 2SV: בדקו בדוחות שאין משתמשים חדשים (או ותיקים) שחומקים מהאכיפה.
3. חוקי העברה וסינון: סרקו חוקי תיבה חדשים שנוצרו ברבעון — במיוחד בתיבות של הנהלה והנהלת חשבונות.
4. שיתוף Drive: עברו על קבצים ותיקיות ששותפו חיצונית, והסירו שיתופים שכבר לא נדרשים.
5. אפליקציות OAuth: עברו על ה-Connected apps, אשרו רק את מה שמוכר, והסירו אפליקציות שאינן בשימוש.
6. התראות: ודאו שהתראות מרכז ההתראות מגיעות לכתובת מנוטרת, ושמישהו באמת פותח אותן.
7. עובדים שעזבו: ודאו שחשבונות של עוזבים הושהו, הסשנים נותקו, ההרשאות בוטלו — ובמידת הצורך בוצעה מחיקה מרחוק מהמכשיר.

עסק שמריץ את הסבב הזה ארבע פעמים בשנה נמצא, מניסיוננו, במצב טוב יותר מרוב השוק — בעלות של פחות משעתיים בשנה. ולסיום, תזכורת חשובה: Google Workspace שומר על זמינות השירות, אבל מחיקה — זדונית או אנושית — היא עדיין הבעיה שלכם. Vault נועד לשימור לצרכים משפטיים, לא לגיבוי מלא. השלימו את התמונה עם אסטרטגיית גיבוי 3-2-1 גם לנתוני הענן.

*האמור במאמר זה הוא מידע כללי בלבד ואינו מהווה ייעוץ מקצועי מחייב. שמות תפריטים, מסלולי ניהול והרכבי רישיונות של Google Workspace משתנים מעת לעת — בדקו מול התיעוד הרשמי של גוגל לפני ביצוע שינויים, והתאימו כל הגדרה לתהליכי העבודה של הארגון.*