כלי AI לסיכום פגישות שמשתלטים על הארגון, ואיך מחזירים את השליטה

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

Read.AI הוא רק דוגמה. Otter, Fireflies, Fathom ועוד עשרות כלים עובדים באותה דרך. במאמר הזה נסביר איך כלי כזה נכנס לארגון בלי אישור, למה זה מסוכן, ואיך מחזירים את השליטה. זה אחד המקרים הנפוצים שאנחנו פוגשים בפרויקטי אבטחת מידע ב-Microsoft 365.

איך כלי כזה נכנס בלי שאף אחד אישר

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

ההרשמה. עובד נרשם לכלי עם חשבון Microsoft 365 שלו, או לוחץ על קישור בסיכום פגישה שהכלי שלח. ההרשמה יוצרת חשבון בכלי ומחברת אותו לחשבון הארגוני.
ההסכמה. במסך ההתחברות מופיעה בקשת הרשאות: גישה ליומן, לפרופיל ולפעמים לדוא"ל. אם הארגון מאפשר למשתמשים לאשר אפליקציות בעצמם (User Consent), העובד לוחץ "אשר" וזהו. אין מעורבות של IT.
ההצטרפות האוטומטית. הכלי קורא את היומן של העובד ומצטרף לפגישות עם קישור Teams. לפי הגדרות ההצטרפות שנבחרות בהרשמה, הוא יכול להצטרף לכל הפגישות ביומן, גם כאלה שהעובד רק מוזמן אליהן, ולפעמים גם אם העובד עצמו לא נכנס לפגישה.
ההתפשטות. אחרי הפגישה הכלי שולח סיכום לכל המשתתפים, עם הזמנה להירשם. משתתף נוסף שנרשם מצטרף למעגל, וכך הכלי מתפשט מפגישה לפגישה.

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

למה זה מסוכן

כלי סיכום פגישות הוא לא סתם מטרד. הוא מקליט ומתמלל את השיחות הרגישות ביותר בארגון ושומר אותן מחוץ לארגון:

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

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

איך מחזירים את השליטה

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

צעד	איפה	מה זה עושה
מיפוי האפליקציה ומי אישר אותה	Entra ID > Enterprise applications	רואים אילו משתמשים נתנו הסכמה ואילו הרשאות האפליקציה קיבלה
הגבלה לקבוצת משתמשים	באפליקציה: Assignment required = Yes, ושיוך רק לקבוצת המשתמשים המאושרים	רק מי שבקבוצה יכול להתחבר לכלי, ומשתמשים אחרים כבר לא יכולים לאשר אותו בעצמם. ההסכמות הקיימות של המשתמשים המאושרים נשארות
ביטול הרשאות לשאר	ביטול ההסכמות של המשתמשים שלא ברשימה, דרך Microsoft Graph או PowerShell (בפורטל אפשר רק לראות אותן)	הכלי מאבד את הגישה ליומן שלהם, ולא נשלח יותר לפגישות דרך החשבון שלהם. הוא עדיין יכול להגיע דרך משתתף אחר שמחובר לכלי
חסימת האפליקציה ב-Teams	Teams admin center > Manage apps	חוסם את אפליקציית ה-Teams של הכלי למי שלא צריך אותה. זה לא מונע מהבוט להצטרף דרך קישור הפגישה
שליטה בבוטים בפגישות	מדיניות פגישות ב-Teams: Manage external bots and their access to meetings, ו-Anonymous users can join a meeting unverified כבוי	בוטים חיצוניים שזוהו מחכים לאישור בלובי. ההגדרות חלות רק על פגישות שהארגון מארח
הגדרות בכלי עצמו	אצל המשתמשים המאושרים: Auto-Join Preferences רק לפגישות שהם מארחים	הכלי מפסיק להצטרף לפגישות של אחרים

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

איך מונעים את המקרה הבא

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

הגבלת הסכמת משתמשים: ב-Entra ID, תחת User consent settings, בוחרים ב-Allow user consent for apps from verified publishers, for selected permissions, ומסווגים כ-Low impact רק הרשאות בסיסיות. גישה ליומן ולדוא"ל כבר לא תאושר בלחיצה אחת. השינוי חל על הסכמות עתידיות בלבד, אז את הקיימות צריך לבדוק בנפרד.
תהליך אישור מסודר: מפעילים Admin consent workflow. עובד שצריך אפליקציה שולח בקשה עם נימוק, ואדמין מאשר או דוחה. כך העובדים לא נחסמים, אבל ההחלטה עוברת דרך IT.
רשימת כלים מאושרים: מחליטים אילו כלי AI מותרים בארגון, ומפרסמים את הרשימה. אם יש רישוי Microsoft 365 Copilot, סיכומי הפגישות שלו נשארים בגבולות השירות של Microsoft 365 ויורשים את מדיניות האבטחה, התאימות והשמירה של הארגון.
ניטור אפליקציות OAuth: ב-Defender for Cloud Apps, בעזרת App Governance, מקבלים התראה על אפליקציות חדשות עם הרשאות רחבות, ואפשר לבדוק את כל האפליקציות שכבר מחוברות.
סקירה תקופתית: פעם ברבעון עוברים על Enterprise applications ובודקים אילו אפליקציות קיבלו הסכמה, כמה משתמשים מחוברים אליהן, ואילו כבר לא בשימוש.

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

בשורה התחתונה

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

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

קביעת שיחה