Skip to main content

​
מה האינטגרציה הזו מספקת

Google Workspace יכול לספק נתוני פעילות מנורמלים של מחזור חיי משתמשים, כניסה למערכת, MFA, פעולות ניהול והגנה על נתונים. הדוגמאות שנבדקו כוללות:
  • account.compromised — חשבון שסומן כחשבון שנפרץ
  • data.sensitive.downloaded — הורדת נתונים רגישים
  • auth.login.unusual — כניסה למערכת מהקשרים חריגים
ראו כיצד נתוני אינטגרציה הופכים לאותות.

​
מה Living Security דורשת

הפעילו את ממשקי ה-API של Admin SDK ואשרו רק את ההיקפים שהחיבור קורא:
  • https://www.googleapis.com/auth/admin.reports.audit.readonly
  • https://www.googleapis.com/auth/admin.directory.user.readonly
  • https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly

​
הגדרה

1

יצירת חשבון שירות ב-Google Cloud

צרו חשבון שירות ייעודי, הפעילו האצלת סמכויות ברמת הדומיין (domain-wide delegation) והורידו את מפתח ה-JSON שלו. שמרו את המפתח במקום מאובטח.
2

אישור האצלת סמכויות ברמת הדומיין

ב-Google Admin Console, פתחו את Security → Access and data control → API controls → Manage Domain Wide Delegation. הוסיפו את מזהה הלקוח המספרי של חשבון השירות ואת שלושת ההיקפים לקריאה בלבד שצוינו לעיל.
3

בחירת המנהל המורשה

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

​
אימות ופתרון בעיות

ודאו שהחיבור יכול לקרוא משתמש אחד בספרייה ואת פעילות הכניסה האחרונה למערכת. Google מציינת כי הענקות חדשות של האצלת סמכויות ברמת הדומיין עשויות לקחת זמן עד שהן מופצות.
ודאו שהאצלת הסמכויות ברמת הדומיין משתמשת במזהה הלקוח המספרי של חשבון השירות ולא בכתובת הדוא”ל שלו, ושכל שלושת ההיקפים תואמים במדויק.
הוסיפו את admin.directory.rolemanagement.readonly לרשומת ההאצלה וודאו שהמנהל המורשה יכול להציג הקצאות תפקידים.
ודאו ש-Admin Reports API מופעל ושהמנהל המורשה יכול לגשת לדוחות ביקורת עבור דייר ה-Workspace.
לפרטים בצד הספק, ראו המדריך של Google להאצלת סמכויות ברמת הדומיין.