איך לבקר אפליקציות OAuth של צד שלישי בגוגל וורקספייס

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

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

מהי בעצם הרשאת OAuth

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

שתי תכונות הופכות את ההענקות האלה לראויות לביקורת:

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

איפה מוצאים את המלאי

יש שתי נקודות תצפית.

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

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

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

איך שופטים סיכון

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

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

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

ביקורת שאפשר לחזור עליה, צעד אחר צעד

1. מנו. משכו את הרשימה המלאה של אפליקציות מחוברות והרשאותיהן מקונסולת הניהול (או דרך הממשק התוכנתי).
2. סווגו הרשאות. סמנו את המסוכנות — דרייב מלא, שליחה/קריאה בג׳ימייל, ספרייה, וכל הרשאת ניהול.
3. הצליבו שימוש. זהו אפליקציות ללא פעילות עדכנית ואפליקציות שמעט מאוד משתמשים מחזיקים.
4. בדקו את המפרסם. רשמו מפרסמים לא מאומתים או לא מוכרים.
5. החליטו. לכל אפליקציה: להשאיר, להגביל או לשלול. תעדו את הסיבה — יומן ההחלטות הוא מה שהופך את הביקורת הבאה למהירה יותר.
6. שללו בבטחה. הסירו גישה לאפליקציות שהחלטתם לסלק, ותקשרו עם קומץ המשתמשים שהסתמכו על כלי שאתם מסירים.
7. הציבו מעקות. עברו מניקוי למניעה: הגבילו התקנות מהמרקטפלייס לאפליקציות באישור מנהל, וחסמו או הגדירו רשימת היתר להרשאות בסיכון גבוה, כדי שהשלל פשוט לא יצמח מחדש.

שוללים בלי לשבור דברים

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

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

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

הופכים את זה לרציף

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

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

ההרשאות שצריכות לעצור אתכם לרגע

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

• `drive` (דרייב מלא) — קריאה, יצירה, שינוי ומחיקה של *כל* קובצי הדרייב של המשתמש. זו הרשאת הנתונים הרחבה ביותר שאפליקציה יכולה להחזיק, והיא נפוצה הרבה יותר משהיא צריכה להיות; אפליקציות רבות מבקשות אותה כשהרשאה צרה יותר ברמת הקובץ הייתה מספיקה.
• `gmail.send` / `gmail.modify` / `mail.google.com` — היכולת לשלוח דואר בשם המשתמש, או לקרוא ולשנות את תיבת הדואר. אפליקציה עם גישה לתיבה יכולה גם להוציא התכתבויות וגם להתחזות למשתמש מול אחרים.
• **admin.directory.*** — קריאה או ניהול של ספריית המשתמשים והקבוצות שלכם. אפליקציה שמחזיקה בזה מגיעה אל הארגון כולו, לא רק אל משתמש אחד.
• `spreadsheets` / `documents` — גישת תוכן לגיליונות ולמסמכים, שמחזיקים לעיתים קרובות בדיוק את הנתונים הרגישים (כספים, תוכניות, סיסמאות שהודבקו ״זמנית״) שאתם הכי רוצים להגן עליהם.

הרשאות צרות, לקריאה בלבד — userinfo.email, calendar.readonly, drive.file (גישה רק לקבצים שהאפליקציה עצמה יצרה) — הן אלה שכדאי לעודד. כשאתם מעריכים כלי חדש, העדיפו את הגרסה שמבקשת הכי מעט.

מביקורת למדיניות

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

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

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

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

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