אדמינים יכולים להשתמש בהענקת גישה ברמת הדומיין כדי לאפשר לאפליקציות פנימיות ולאפליקציות של צד שלישי לגשת לנתונים של המשתמשים ב-Google Workspace, בלי צורך בהסכמה של משתמשי הקצה. כדי לעשות את זה, יוצרים חשבון שירות במסוף Google Cloud ומקצים לו הרשאה ברמת הדומיין במסוף Google Admin. אתם יכולים גם לתת לחשבון השירות היקפי הרשאות מוגבלים ל-API במסוף Admin. פרטים נוספים על הענקת גישה ברמת הדומיין זמינים במאמר בנושא שליטה בהרשאות הגישה ל-API באמצעות הענקת גישה ברמת הדומיין.
ניהול ואבטחה של חשבונות שירות
בממשק לניהול זהויות והרשאות גישה (IAM) יש הנחיות לשימוש בחשבונות שירות כדי להגביל את הגישה ולהגן מפני איומים של הסלמת הרשאות (privilege escalation) ואי-התכחשות (non-repudiation). שיטות מומלצות לשימוש בחשבונות שירות
כל ההמלצות במדריך רלוונטיות להגנה על חשבונות שירות שמשתמשים בהענקת גישה ברמת הדומיין, אבל הנה כמה שיטות מומלצות שכדאי להדגיש:
 |
שימוש בגישה ישירה לחשבון שירות או בהסכמה של OAuth אם אתם יכולים לבצע את המשימה ישירות באמצעות חשבון שירות או באמצעות הסכמה של OAuth, רצוי להימנע משימוש בהענקת הרשאות גישה ברמת הדומיין. אם אתם לא יכולים להימנע משימוש בהענקת הרשאות גישה ברמת הדומיין, אפשר להגביל את קבוצת היקפי ההרשאות של OAuth שאפשר להשתמש בהם בחשבון השירות. היקפי ההרשאות של OAuth לא מגבילים את המשתמשים שחשבון השירות יכול להתחזות אליהם, אבל הם מגבילים את הסוגים של נתוני המשתמשים שלחשבון השירות יש גישה אליהם. |
|
הגבלת היצירה וההעלאה של מפתחות לחשבונות שירות להשתמש בכללי מדיניות של הארגון כדי להגביל את היצירה וההעלאה של מפתחות לחשבונות שירות עם הענקת גישה ברמת הדומיין. כך אפשר להגביל את ההתחזות לחשבון שירות באמצעות מפתחות של חשבונות שירות. |
|
השבתה של הענקת תפקידים אוטומטית לחשבונות שירות שמוגדרים כברירת מחדל חשבונות שירות שנוצרים כברירת מחדל מקבלים את התפקיד "עריכה", שמאפשר לחשבון לקרוא ולשנות את כל המשאבים בפרויקט ב-Google Cloud. אתם יכולים להשבית את מתן התפקידים האוטומטי בחשבונות שירות שמוגדרים כברירת מחדל, כדי לוודא שהם לא יקבלו באופן אוטומטי את התפקיד "עריכה" ומשתמשים זדוניים לא יוכלו לנצל אותם בקלות. לא משתמשים במתן תפקידים אוטומטי בחשבונות שירות שהוגדרו כברירת מחדל |
|
הגבלת התנועה הרוחבית תנועה רוחבית קורית כשלחשבון שירות בפרויקט אחד יש הרשאה להתחזות לחשבון שירות בפרויקט אחר. זה עלול לגרום לגישה לא מכוונת למשאבים. השתמשו בתובנות לגבי תנועה רוחבית כדי לזהות ולהגביל תנועה רוחבית באמצעות התחזות. |
|
הגבלת הגישה לחשבונות שירות עם הענקת גישה ברמת הדומיין אם לחשבון השירות יש יותר הרשאות מלמשתמש, אל תאפשרו לו לשנות את כללי מדיניות ההרשאות של חשבון השירות. להשתמש בתפקידי IAM כדי להגביל את הגישה לחשבונות שירות עם הרשאות גישה ברמת הדומיין. נמנעים מלאפשר למשתמשים לשנות את כללי מדיניות ההרשאות של חשבונות שירות שיש להם יותר הרשאות |
הגנה על חשבונות שירות מפני סיכונים פנימיים
השתמשו בהענקת גישה ברמת הדומיין רק אם יש לכם הצדקה עסקית קריטית שמחייבת אפליקציה לעקוף את ההסכמה מהמשתמש כדי לגשת לנתונים ב-Google Workspace. נסו חלופות כמו OAuth עם הסכמת משתמש או שימוש באפליקציות מ-Marketplace. מידע נוסף זמין במאמר Google Workspace Marketplace.
כדי להגן על חשבונות שירות עם הרשאות להענקת גישה ברמת הדומיין מפני סיכונים פנימיים, מומלץ לפעול לפי השיטות הבאות:
|
לתת גישה רק להרשאות חיוניות חשוב לוודא שלחשבונות שירות עם הענקת גישה ברמת הדומיין יש רק את ההרשאות החיוניות שנדרשות כדי לבצע את הפונקציות המיועדות שלהם. אל תתנו גישה להיקפי הרשאות לא חיוניים של OAuth. |
|
אירוח של חשבונות שירות בפרויקטים ייעודיים ב-Google Cloud חשוב לוודא שחשבונות שירות עם הענקת גישה ברמת הדומיין מתארחים בפרויקטים ייעודיים ב-Google Cloud. אל תשתמשו בפרויקטים האלה לצרכים עסקיים אחרים. |
|
להימנע משימוש במפתחות של חשבונות שירות לא צריך להשתמש במפתחות של חשבונות שירות כדי להעניק גישה ברמת הדומיין. במקום זאת, צריך להשתמש ב-API של signJwt. להימנע משימוש במפתחות של חשבונות שירות להענקת גישה ברמת הדומיין |
|
הגבלת הגישה לפרויקטים שיש להם גישה ברמת הדומיין צמצמו את מספר האנשים שיש להם גישת עריכה לפרויקטים בענן ב-Google Cloud שמוגדרת בהם הענקת גישה ברמת הדומיין. אתם יכולים להשתמש ב-Cloud Asset Inventory API כדי להבין למי יש גישה לחשבונות שירות. לדוגמה, אפשר להשתמש ב-Cloud Shell כדי להריץ את הפקודה:
חפשו הרשאות או תפקידים כמו |