עודכן לאחרונה:
מה זו הרשאת גישה לאפליקציית צד שלישי? זו הרשאה שמשתמש בארגון מעניק לשירות חיצוני לגשת לנתונים שלו בחשבון Google - מיילים ב-Gmail, קבצים ב-Drive, אירועים ביומן או אנשי קשר. ההרשאה ניתנת פעם אחת, במסך אישור בן שתי שניות, ונשארת בתוקף עד שמישהו מבטל אותה ביוזמתו. היא לא פגה מעצמה כשמפסיקים להשתמש בכלי.
רוב הארגונים משקיעים בסיסמאות, באימות דו-שלבי ובהגנה על נקודות הקצה, ומשאירים פתוח בדיוק את הערוץ שעוקף את כולם. אפליקציה שקיבלה הרשאה לקרוא את תיבת הדואר לא צריכה סיסמה, לא נעצרת באימות דו-שלבי ולא מייצרת התראת התחברות. היא ניגשת לתיבה וקוראת אותה, ואף אחד לא מקבל על כך התראה.
ארבעה מצבים חוזרים אצל כמעט כל לקוח שאנחנו בודקים:
מסוף הניהול מציג את התמונה הזו בשני מקומות משלימים, ורוב האדמינים לא הגיעו לאף אחד מהם.
מסוף הניהול, בתפריט: Security > Access and data control > API controls. זהו המסך שקובע מה מותר לכל אפליקציה, והוא זמין בכל חבילות Google Workspace.
מסוף הניהול, בתפריט: Reporting > Audit and investigation > OAuth log events. כאן רואים כל אישור הרשאה, כל ביטול וכל קריאת API בפועל - מי המשתמש, שם האפליקציה, מזהה הלקוח שלה, אילו הרשאות בדיוק אושרו, כתובת ה-IP והשעה. הנתונים נשמרים שישה חודשים אחורה. זה המסך שעונה על השאלה האמיתית: לא מה הגדרנו, אלא מה קרה.
בתוך App access control כל אפליקציה מקבלת אחד מארבעה מצבים:
במקביל אתם מסמנים אילו שירותים הם Restricted - כלומר רק אפליקציה במצב Trusted או Specific Google data תוכל לגעת בהם. Gmail, Drive, Docs ו-Chat מאפשרים גם הגבלה של הרשאות בסיכון גבוה בלבד, כמו שליחת דואר בשם המשתמש, מחיקת קבצים או שינוי הודעות.
זו ההגדרה הכי משפיעה במסך, והיא יושבת תחת Settings במסך ה-API controls. שלוש אפשרויות:
ברירת המחדל פתוחה, וזו בדיוק הסיבה שבארגון ממוצע מצטברות עשרות הרשאות שאיש לא אישר במודע. מאז אוגוסט 2025 יש גם מנגנון ביניים שמופעל כברירת מחדל: משתמש שנחסם מול אפליקציה יכול לשלוח בקשת אישור, והאדמין מאשר או דוחה אותה מתוך מסך ה-API controls. זה מה שהופך את ההידוק מ-החלטה שמייצרת תלונות ל-תהליך עבודה מסודר.
אפליקציות שמותקנות מה-Marketplace נשלטות במסך נפרד: מסוף הניהול, בתפריט Apps > Google Workspace Marketplace apps > Apps list > User Install Settings. תחת Manage access to apps בוחרים אם המשתמשים יכולים להתקין כל אפליקציה, רק אפליקציות מרשימת היתר, או לא להתקין כלל. כשבוחרים רשימת היתר אפשר בנוסף לאפשר התקנה חופשית של אפליקציות פנימיות שפיתחתם בעצמכם.
שימו לב שזה שער נפרד לגמרי מ-App access control. הידוק של אחד מהם בלי השני משאיר חצי דלת פתוחה.
הגדרה זו יושבת באותו מסך: Security > Access and data control > API controls > Manage Domain Wide Delegation. היא מאפשרת לאפליקציה או לחשבון שירות לגשת לנתונים של המשתמשים בלי מסך אישור ובלי הסכמה של אף אחד מהם. Google עצמה מנסחת את זה חד: לאפליקציה יש גישה לנתונים של כל המשתמשים שלכם.
זה מנגנון לגיטימי והכרחי לכלי מיגרציה, לגיבוי ולסנכרון, אבל הוא חייב טיפול נפרד: לעבור על רשימת הלקוחות המורשים, לוודא שההרשאות שהוגדרו לכל אחד הן המצומצמות ביותר שנדרשות בפועל, ולמחוק כל חשבון שירות שאינו בשימוש. אם מופעל אצלכם אישור רב משתתפים, הוספת הרשאה כזו תדרוש אישור של מנהל על נוסף - זו הגדרה שכדאי להשאיר דלוקה.
נכנס לכאן רובד חדש. סוכן AI או זרימת אוטומציה שמחוברת לתיבת הדואר או ל-Drive פועלת בדיוק באותו מנגנון הרשאות, אלא שהיא רצה מעצמה, בתדירות גבוהה יותר, ובלי שמישהו יושב מולה. יומן ה-OAuth כולל שדה ייעודי לפעולות של סוכנים, ומאוגוסט 2026 יש במסוף הניהול לוח ניהול גישה לסוכנים שמאפשר להשעות זרימות או לשלול הרשאה ספציפית מזרימה מסוימת, למשל להוריד ממנה את הגישה ל-Drive בלי לכבות אותה לגמרי.
הרחבנו על סוגי ההרחבות ועל מה בודקים לפני שמחברים אותן במדריך סקילים, פלאגינים ו-MCP.
לא הכול חייב לעבור דרך האדמין. כל בעל חשבון Google יכול להיכנס לעמוד החיבורים לאפליקציות ולשירותים של צד שלישי, לראות בדיוק מי מחובר לחשבון שלו ומה ניתן לו, ולהסיר גישה בלחיצה. זו בדיקה שכדאי להעביר לכל הצוות כמשימה של חמש דקות, במיוחד לפני סקירה ארגונית - היא מנקה לבד חלק גדול מהרעש.
סקירה חד פעמית מייצרת רשימה יפה שמתיישנת תוך רבעון. מה שעובד הוא נוהל קבוע, רבעוני:
עובד שעוזב הוא נקודת בדיקה נוספת ונפרדת, והיא מכוסה במדריך צ׳קליסט הניתוק הבטוח.
אם אתם ניגשים לזה בפעם הראשונה, אל תתחילו מהידוק. תתחילו מתצפית: פתחו את יומן ה-OAuth, הסתכלו על שישה חודשים אחורה וספרו כמה אפליקציות שונות מופיעות שם. המספר הזה, כמעט תמיד, גדול פי כמה ממה שציפיתם - והוא זה שהופך את הנושא מסעיף בצ׳קליסט למשימה עם תאריך.
רוצים את הסביבה הזאת בעסק, עם רישוי דרך מפיץ רשמי, חשבונית שקלית ותמיכה בעברית? זה בדיוק מה שאנחנו עושים ב-Koogler. קראו עוד על Google Workspace לעסקים, או דברו איתנו בשיחת אפיון ראשונית ללא עלות.
במסוף הניהול, בתפריט Reporting ואז Audit and investigation ואז OAuth log events. שם מופיע כל אישור הרשאה וכל קריאת API בפועל, כולל שם האפליקציה, המשתמש, ההרשאות שאושרו והשעה. הנתונים נשמרים שישה חודשים אחורה.
לא. הרשאת OAuth נשארת בתוקף עד שמבטלים אותה - על ידי המשתמש בעמוד החיבורים בחשבון שלו, או על ידי אדמין במסוף הניהול. הפסקת השימוש בכלי אינה מבטלת את ההרשאה.
אלה שני שערים נפרדים. הגדרות ה-Marketplace קובעות מה מותר להתקין, ו-App access control קובע לאילו נתונים מותר לגשת - גם לאפליקציה שהתחברה בלי לעבור דרך ה-Marketplace. צריך להגדיר את שניהם.
זו הרשאה שמאפשרת לאפליקציה או לחשבון שירות לגשת לנתונים של כל המשתמשים בארגון בלי מסך אישור. היא נדרשת לכלי מיגרציה, גיבוי וסנכרון, וצריכה סקירה נפרדת - כל חשבון שירות שאינו בשימוש פעיל יש למחוק.
בקרות הגישה לאפליקציות ויומן ה-OAuth זמינים בכל החבילות. כלי החקירה המתקדם, עם יכולות חיפוש ותחקור רחבות יותר, זמין בחבילות הגבוהות יותר.
אפליקציות צד שלישי מקבלות הרשאה חד פעמית לנתונים בחשבון Google ושומרות אותה עד שמבטלים אותה ידנית. מסוף הניהול מאפשר לראות בדיוק מי מחובר (OAuth log events), לקבוע לכל אפליקציה מצב גישה מדויק, לשלוט בהתקנות מה-Marketplace ולנהל את הרשאות חשבונות השירות. הפעולה המשמעותית ביותר היא נוהל סקירה רבעוני קבוע - לא בדיקה חד פעמית.
