דוגמאות לבקרת גישה מבוססת-הקשר במצב בסיסי

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

דוגמאות לרמות גישה שפותחו במצב מתקדם (באמצעות כלי העריכה של CEL) זמינות במאמר דוגמאות לבקרת גישה מבוססת-הקשר במצב מתקדם.

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

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

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

שם רמת הגישה	contractor_access
קבלן יקבל גישה אם הוא	מתאימים למאפיינים
מאפיין תנאי 1	רשת משנה של כתובות IP (גלויה לכולם) 74.125.192.0/18
הקצאת רמת גישה	יחידות ארגוניות לקבלנים כל האפליקציות שקבלנים משתמשים בהן

חסימת גישה מכתובות IP ידועות של האקרים

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

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

שם רמת הגישה	block_highrisk
משתמש יקבל גישה אם הוא:	לא מתאימים למאפיינים
מאפיין תנאי 1	רשת משנה של כתובות IP (גלויה לכולם) 74.125.195.105
הקצאת רמת גישה	היחידה הארגונית ברמה העליונה כל האפליקציות

אישור גישה מרשת פרטית ספציפית ב-Google Cloud

חברות רבות מעבירות את תעבורת המשתמשים ל-Google דרך ענן וירטואלי פרטי (VPC). רשת VPC היא רשת מאובטחת ומבודדת בסביבת Google Cloud.

חשוב לדעת שבתעבורת נתונים שמנותבת דרך ה-VPC שלכם יכול להיות שימוש בכתובות IP פרטיות. הדבר עלול לגרום לבעיות במדיניות בנושא כתובות IP ציבוריות או אזורים.

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

שם רמת הגישה	vpc_access
משתמש יקבל גישה אם הוא...	מתאימים למאפיינים
מאפייני תנאי 1	רשת משנה של כתובות IP (פרטית) רשת משנה פרטית של כתובות IP: //compute.googleapis.com/projects/project- name-test/global/networks/network-name רשת משנה של VPC: ‏ 74.125.192.0/18
הקצאת רמת גישה	יחידות ארגוניות לכל המשתמשים כל האפליקציות שקבלנים משתמשים בהן

דברים חשובים שכדאי לזכור:

• תנועה ישירה בלבד: רמת הגישה הזו פועלת רק לגבי תנועה שמגיעה ישירות לשרתי Google מ-VPC שנכלל ברשימת ההיתרים. אם התנועה עוברת קודם דרך רשת או מנהרה אחרת, הגישה לא תינתן. ‫Google מזהה רק את ה-VPC האחרון ששולח את התנועה לשרתים שלה.
• הרשאות אדמין: כדי להציג רשתות VPC ולהגדיר את רמת הגישה הזו, האדמינים צריכים לקבל את התפקיד המתאים בניהול זהויות והרשאות גישה (IAM) (לדוגמה, compute.networks.list,‏ compute.subnetworks.list וכו').
• רשתות VPC חיצוניות: רשת ה-VPC שאתם מוסיפים לרשימת ההיתרים יכולה להיות מחוץ לדומיין הנוכחי שלכם ב-Google Cloud. אדמין צריך לקבל הרשאת צפייה כדי להוסיף את ה-VPC החיצוני.

אישור או דחייה של גישה ממיקומים ספציפיים

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

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

בדוגמה הזו, קבוצת המכירות יכולה לגשת למשאבים של החברה רק מארה"ב (המשרד הראשי), מאוסטרליה ומאירלנד.

שם רמת הגישה	sales_access
צוות המכירות יקבל גישה אם	מתאימים למאפיינים
מאפיין תנאי 1	אזור גיאוגרפי ארה"ב, אוסטרליה, הודו
הקצאת רמת גישה	קבוצה של אנשי מכירות כל האפליקציות שאנשי המכירות משתמשים בהן

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

שימוש ברמות גישה מקוננות במקום בחירה של כמה רמות גישה במהלך הקצאה

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

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

בדוגמה הזו, USWest,‏ USEast ו-USCentral נמצאים ב-3 רמות גישה נפרדות. נניח שאתם רוצים שהמשתמשים יוכלו לגשת לאפליקציות אם הם עומדים בתנאים של רמות הגישה USWest או USEast או USCentral.אתם יכולים ליצור רמת גישה מוטמעת אחת (שנקראת USRegions) באמצעות האופרטור OR. כשמגיע הזמן להקצות את רמות הגישה, מקצים את רמת הגישה USRegions לאפליקציה עבור היחידה הארגונית או הקבוצה.

שם רמת הגישה	USRegions
משתמש יקבל גישה אם הוא:	מתאימים למאפיינים
מאפיין תנאי 1 (רק רמת גישה אחת לכל תנאי)	רמת גישה USWest
שילוב של תנאי 1 ותנאי 2 באמצעות	או
משתמש יקבל גישה אם הוא:	מתאימים למאפיינים
מאפיין תנאי 2	רמת גישה USEast
שילוב של תנאי 2 ותנאי 3 באמצעות	או
משתמש יקבל גישה אם הוא:	מתאימים למאפיינים
מאפיין תנאי 3	רמת גישה USCentral

נדרש מכשיר בבעלות החברה במחשב אבל לא בנייד

חברה עשויה לדרוש מכשיר שולחני בבעלות החברה, אבל לא מכשיר נייד בבעלות החברה.

קודם יוצרים רמת גישה למחשבים:

שם רמת הגישה	aldesktop_access
משתמשים יקבלו גישה אם הם	מתאימים למאפיינים
מאפיין תנאי 1	מדיניות המכשיר נדרש מכשיר בבעלות החברה הצפנת המכשיר = לא נתמכת מערכת ההפעלה של המכשיר ‫macOS = 0.0.0 ‫Windows =0.0.0 Linux OS = 0.0.0 ‫ChromeOS = 0.0.0

לאחר מכן, יוצרים רמת גישה למכשירים ניידים:

שם רמת הגישה	almobile_access
משתמשים יקבלו גישה אם הם	מתאימים למאפיינים
מאפיין תנאי 1	מערכת ההפעלה של המכשיר ‫iOS = 0.0.0 ‫Android = 0.0.0

דרישה לאבטחת מכשיר בסיסית

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

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

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

מידע קשור

• סקירה כללית בנושא בקרת גישה מבוססת-הקשר
• הגדרת תוכנה ויצירת רמות גישה מבוססות-הקשר
• הקצאת רמות גישה מבוססות-הקשר לאפליקציות
• התאמה אישית של בקרת גישה מבוססת-הקשר באמצעות קבוצות
• דוגמאות לשימוש בבקרת גישה מבוססת-הקשר במצב מתקדם
• יומן ביקורת של בקרת גישה מבוססת-הקשר