ניהול הרשאות אפליקציות Google Workspace: איך לאשר, להגביל ולחסום גישה בעסק

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

ניהול הרשאות אפליקציות Google Workspace מתחיל במיפוי

את האפליקציות המחוברות בודקים ב־Admin console, באזור App access control. פתחו Security > Access and data control > API controls ובחרו Manage App Access; נדרשת הרשאת האדמין Service Settings. בעברית, חפשו את אזור האבטחה ובקרת הגישה לנתונים, והיעזרו בשמות האנגליים לזיהוי המסך. עברו על Configured apps ועל Accessed apps: הגדרה מאושרת ושימוש בפועל אינם אותו דבר. אל תסיקו שאפליקציה אינה קיימת רק משום שלא הופיעה ברשימה אחת.

פתחו כל אפליקציה ותעדו ספק, משתמשים, שירותים ומזהה לקוח OAuth. בדקו את היקפי ההרשאה (Scopes), ורשמו אילו פעולות נדרשות: זיהוי משתמש, קריאה, שינוי או מחיקה. השוו את הבקשה לצורך העסקי וקבעו בעלים עסקיים לחיבור.

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

איזו רמת גישה מתאימה לכל צורך עסקי?

בחרו רמת גישה לפי הנתונים והפעולות שהכלי צריך. לפי תיעוד Google, Trusted מאפשרת כניסה ובקשת גישה לכל נתוני Google; Limited מאפשרת בקשת גישה רק לנתונים שאינם מוגבלים; Specific Google data מאפשרת בקשת גישה להיקפים שתגדירו. הגדרת המדיניות אינה ראיה לכך שהאפליקציה השתמשה בפועל בכל הרשאה.

הגדרה	הגישה שניתן לבקש	מתי לשקול
Trusted	כל נתוני Google	לאחר בדיקת צורך רחב ואישורו
Limited	נתוני Google שאינם מוגבלים	כאשר הגבלת השירותים מתאימה לצורך
Specific Google data	היקפי OAuth שהאדמין מגדיר	כאשר הכלי תומך בהרשאות מצומצמות
חסימה	בדקו את אפשרות החסימה במסוף ואת תוצאותיה בפועל	כאשר כלי נדחה או יצא משימוש

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

צורך עסקי	גישה מצומצמת לבחינה	מי מאשרים	מועד בדיקה מומלץ
זיהוי משתמשים	הרשאות Google Sign-in הדרושות	בעל המערכת ו־IT	בשינוי מנגנון הכניסה
עיבוד מסמכים	הרשאות מצומצמות לפי תיעוד הספק	בעלי המידע ו־IT	בסיום הפיילוט
סנכרון יומן ל־CRM	היקפים המתאימים לפעולות הסנכרון	מנהל המכירות ו־IT	בשינוי הסנכרון
גיבוי ארגוני	הרשאות בהתאם לתכולת הגיבוי	אחראי הגיבוי ו־IT	בבדיקת שחזור ובהחלפת ספק

איך מאשרים כלי לעובדים מסוימים בלי להשבית עבודה?

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

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

1. אשרו צורך ותנאי חזרה

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

2. הגדירו את יחידות הפיילוט

אדמין בעל Service Settings פותח Apps pending review ובוחר Configure access ליד האפליקציה. מסמנים יחידות, לוחצים שוב Configure access, בודקים את התחולה ב־Scope ולוחצים Next. בוחרים Specific Google data והיקפים מאושרים, לרבות Google Sign-in אם נדרשת כניסה, ומשלימים את מסכי האישור. ראיה: מזהה לקוח, יחידות והיקפים שנשמרו. אם אינם תואמים לבקשה, עוצרים ומתקנים.

3. אמתו עבודה והגבלות

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

4. אשרו הרחבה

בעלי התהליך והמידע מאשרים הרחבה לאחר הצלחת הבדיקות. IT מתעדים תחולה ותוצאות לאחר היישום. ראיה: אישור והגדרות שנשמרו. בתקלה בהרחבה חוזרים לתחולה הקודמת בהתאם לתוכנית שאושרה.

איך מנהלים בקשות, התקנות והאצלה ברמת הדומיין?

בדקו בנפרד בקשות עובדים, התקנות Marketplace והאצלה ברמת הדומיין. הגדירו ערוץ בקשות הכולל מטרה, ספק, נתונים, משתמשים ובעלים עסקיים. IT בודקים במסוף את אפשרויות המדיניות לאפליקציות שלא הוגדרו ואת מנגנון הבקשות הזמין; בעלי המידע מאשרים את השימוש בנתונים.

ב־Apps pending review הגדירו גישה ליחידות הנדרשות ובדקו את התחולה לפני האישור. לפי תיעוד תהליך הבקשות, השינויים בתהליך עשויים להימשך עד 24 שעות, ובדרך כלל חלים מהר יותר. אל תרחיבו הרשאות רק בגלל בדיקה מיידית שנכשלה.

לפי מדריך התקנת Marketplace, התקנה ארגונית דורשת Super administrator; הגישה למסך Apps > Google Workspace Marketplace apps > Apps list דורשת הרשאת Google Workspace Marketplace. בדקו דרישות גישה לנתונים לפני Admin install ותעדו את היחידות והקבוצות שנבחרו.

Domain-wide delegation מאפשרת גישה לנתוני משתמשים ללא הסכמתם האישית, במסגרת ההיקפים שאושרו. לפי תיעוד ההאצלה, הניהול נעשה ב־API controls > Manage Domain Wide Delegation בידי Super administrator. כאשר Multi-party approval מופעל, אישור האצלה דורש אישור של Super administrator נוסף. מפו מזהי לקוח, היקפים ובעלים; אל תניחו שפיילוט ביחידה מגביל האצלה ברמת הדומיין.

איך מבטלים גישה ומוודאים שהשינוי הושלם?

1. אשרו את היקף הביטול

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

2. יישמו את הביטול

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

3. אמתו את התוצאה

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

4. הסדירו עותקי מידע ובעלות

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

ב־Reporting > Audit and investigation > OAuth log events חפשו אירועי הרשאה ושימוש באמצעות המסננים הזמינים. נדרשת הרשאת Audit & Investigation, כמפורט בתיעוד היומנים; יכולות החיפוש והחקירה תלויות במהדורה ובהרשאות. שלבו את סקירת החיבורים בתהליך קליטה וסיום העסקה לצורך העברת בעלות וביטול חיבורים מיותרים.

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

תקלה	מה לבדוק לפני הרחבת הרשאות
גישה נכשלת לאחר אישור	מזהה לקוח, יחידה, היקפים והמדיניות החלה בפועל.
כניסה באמצעות Google נכשלת	היקפי Google Sign-in והמדיניות לאפליקציות שלא הוגדרו.
האפליקציה אינה ברשימה	חפשו לפי מזהה. לפי <a href="https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data">תיעוד Google</a>, פרטים מופיעים בדרך כלל 24–48 שעות לאחר ההרשאה; זהו זמן הופעת פרטים.
שינוי בבקשה טרם חל	בדקו תחולה והגדרה שנשמרה. לפי <a href="https://knowledge.workspace.google.com/admin/apps/review-and-manage-third-party-app-access-requests">תיעוד הבקשות</a>, השינויים בתהליך עשויים להימשך עד 24 שעות, לרוב פחות.

שאלות נפוצות

איך מאפשרים כניסה בלי לאשר גישה למיילים ולקבצים?

בחנו הרשאות Google Sign-in בלבד, ודרשו מהספק אישור שהכלי יכול לפעול בלעדי הרשאות הנתונים הנוספות. אמתו זאת בפיילוט.

האם הופעה ב־Marketplace מספיקה לאישור?

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

איך מטפלים במידע שהועבר לספק?

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

מי מאשרים אפליקציות חדשות?

בעלי התהליך והמידע מאשרים צורך ושימוש בנתונים; IT בודקים ומיישמים. קבעו מחליפים ומועד לסקירה חוזרת.

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