במסמך הזה מופיעה סקירה כללית של שירות Access Context Manager והפונקציות שלו. Cloud de Confiance by S3NS אדמינים ארגוניים יכולים להשתמש ב-Access Context Manager כדי להגדיר בקרת גישה פרטנית שמבוססת על מאפיינים לפרויקטים ולמשאבים ב- Cloud de Confiance. אדמינים מגדירים קודם מדיניות גישה, שהיא מאגר ברמת הארגון של רמות גישה ושל אזורים של שירותים.
רמות הגישה מתארות את הדרישות שצריך לעמוד בהן כדי שהבקשות יאושרו. דוגמאות:
- סוג המכשיר ומערכת ההפעלה
- כתובת IP
- זהות המשתמש
גבולות שירות מגדירים ארגזי חול של משאבים. למשאבים בתוך הגבולות יש אפשרות להחליף נתונים באופן חופשי, אבל הם לא יכולים לייצא נתונים מחוץ לגבולות. האחריות לאכיפת המדיניות לא מוטלת על Access Context Manager. במקום זאת, Access Context Manager נועד להגדיר כללים או הקשרים ספציפיים. המדיניות מוגדרת ונאכפת בנקודות שונות, כמו VPC Service Controls. מידע נוסף על השירותים האלה זמין במדריכים למשתמש של כל אחד מהם.
אתם יכולים להגדיר ולאכוף מדיניות של Access Context Manager ברכיבים הבאים של פתרון Chrome Enterprise Premium:
יתרונות
חברות רבות מסתמכות על מודל אבטחה היקפי כמו חומת אש כדי לאבטח משאבים פנימיים. מודל אבטחה היקפי מוגן מאוד עם נקודת כניסה ויציאה אחת. כל מה שנמצא מחוץ להיקף נחשב למסוכן. כל מה שנמצא בתוך התיקייה נחשב מהימן.
חומות אש ומודל האבטחה ההיקפי פועלים היטב אם יש גבול מוגדר היטב סביב משתמשים ושירותים ספציפיים. עם זאת, אם העובדים ניידים, מגוון המכשירים גדל כי המשתמשים מביאים את המכשירים שלהם (BYOD) ומשתמשים בשירותים מבוססי-ענן. התרחיש הזה מוביל לווקטורים נוספים של תקיפה שלא נלקחים בחשבון במודל ההיקפי. לכן, גבולות הגזרה כבר לא מוגבלים למיקום הפיזי של הארגון, ואי אפשר להניח שמה שנמצא בתוכו בטוח.
אתם יכולים להשתמש ב-Access Context Manager כדי לצמצם את גודל הרשת עם הרשאות היתר ולעבור למודל שבו לנקודות קצה אין סמכות סביבתית שמבוססת על הרשת. במקום זאת, אתם יכולים להעניק גישה על סמך ההקשר של הבקשה, כמו סוג המכשיר, זהות המשתמש ועוד, ועדיין לבדוק אם יש גישה לרשת הארגונית כשצריך.
מדיניות גישה
מדיניות גישה היא מאגר לכל המשאבים של Access Context Manager, כמו רמות גישה ואזורים של Service Control.
אתם יכולים ליצור מדיניות גישה בהקשר של ארגון ולהשתמש במדיניות הגישה ברמת הארגון בכל מקום בארגון. כדי להעביר את ניהול מדיניות הגישה, אפשר ליצור מדיניות גישה בהיקף מוגבל ולהגדיר את היקף המדיניות ברמת התיקייה או הפרויקט. האדמין עם הרשאות ניהול שהוקצתה לו מדיניות עם היקף מוגבל יכול לנהל רק את מדיניות הגישה עם ההיקף המוגבל, ולא את מדיניות הגישה ברמת הארגון.
מדיניות גישה עוברת ניהול גרסאות באמצעות etag.
אתם יכולים להשתמש ב-etag כדי לטרגט שינויים במדיניות הגישה, כמו שינויים ברמות הגישה או בגרסה ספציפית של המדיניות. אם כמה מקורות משנים את מדיניות הגישה, שימוש בשדה etag עבור כלי שורת הפקודה gcloud וקריאות ל-API עוזר למנוע החלפות לא מכוונות וקונפליקטים.
מידע נוסף על יצירת מדיניות גישה
רמות גישה
רמות הגישה משמשות כדי לאפשר גישה למשאבים על סמך מידע הקשרי על הבקשה. בעזרת רמות גישה, אפשר להתחיל לארגן רמות של אמון. לדוגמה, אפשר ליצור רמת גישה בשם High_Level שתאפשר בקשות מקבוצה קטנה של אנשים עם הרשאות גבוהות. אפשר גם לזהות קבוצה כללית יותר שרוצים לתת לה הרשאה, כמו טווח כתובות IP שרוצים לאפשר שליחת בקשות ממנו. במקרה כזה, אפשר ליצור רמת גישה בשם Medium_Level כדי לאשר את הבקשות האלה.
אחרי שמגדירים רמות גישה, שירותי האכיפה יכולים להשתמש בהן כדי לקבוע אם לאשר בקשה. לדוגמה, יכול להיות שתציינו שבעוד שמשאבים רבים זמינים ל-Medium_Trust, משאבים רגישים יותר מסוימים דורשים את הרמה High_Trust. הבדיקות האלה מתבצעות בנוסף למדיניות IAM רגילה.
אפשר להתאים אישית את רמות הגישה. רמות הגישה High_Trust ו-Medium_Trust הן דוגמאות לכך. אפשר לציין כמה רמות גישה במסגרת מדיניות גישה.
!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED // levels.regions_check
inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED // levels.ip_check
!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED
levels.regions_check || levels.ip_check -> GRANTED
כתובת IP
אפשר להעניק רמת גישה על סמך כתובת ה-IP של הבקשה המקורית. טווח כתובות ה-IP שמותרות מצוין בצורה של בלוק Classless Inter-Domain Routing (CIDR), שמאפשר שליטה מדויקת בכתובות ה-IP המותרות.
רמת גישה אחת יכולה להכיל כמה טווחי כתובות IP.
במאמר יצירת רמת גישה לגישה לרשת ארגונית מוסבר איך ליצור רמת גישה שמאפשרת גישה רק לטווח מסוים של כתובות IP, כמו אלה שנמצאות ברשת ארגונית אחת.
טווח כתובות ה-IP הבא נחשב לטווח פרטי על ידי Access Context Manager:
10.0.0.0/8(RFC 1918)172.16.0.0/12(RFC 1918)192.168.0.0/16(RFC 1918)-
100.64.0.0/10(RFC 6598 Shared Address Space) -
fc00::/7(IPv6 Unique Local Addresses RFC 4193)
זהות המשתמש
במקרים מסוימים, יכול להיות שתרצו להעניק רמת גישה לישויות ספציפיות. בתרחישים האלה, הזהות של המתקשר קובעת אם התנאי מתקיים. התרחיש הזה משמש לעיתים קרובות יחד עם חשבונות שירות ועם VPC Service Controls.
אפשר ליצור ולנהל רמות גישה שמבוססות על זהות בלבד באמצעות כלי שורת הפקודה gcloud, אבל לא באמצעות מסוף Cloud de Confiance .
כדי להתחיל ליצור רמת גישה בסיסית, אפשר לעיין במאמר בנושא יצירת רמת גישה ל-Access Context Manager.
שילוב של תנאים
רמת גישה אחת יכולה להכיל כמה תנאים. אפשר להעריך את התנאים באמצעות האופרטורים AND או OR. אפשר לציין את המצב כשיוצרים או מעדכנים רמת גישה.
האפשרות AND היא מחמירה יותר ומוגדרת כברירת מחדל. האפשרות הזו מעניקה את רמת הגישה רק אם כל התנאים מתקיימים. לדוגמה, יכול להיות שתדרשו שהבקשה תגיע מתוך הרשת הארגונית וגם ממכשיר שפועלת בו הגרסה העדכנית של מערכת ההפעלה.
OR היא אפשרות פחות מגבילה. כדי שהאפשרות הזו תפעל, רק אחד מתוך הרבה תנאים צריך להיות נכון. לפעמים זה שימושי כשמטפלים בזהויות של משתמשים – למשל, כדי להחריג ישויות ספציפיות (כמו חשבונות שירות) מהדרישות הרגילות.
תנאי קינון
אפשר להגדיר תנאים מקוננים, כך שתנאי אחד יהיה תלוי בתנאי אחר. לדוגמה, אם יש לכם שתי רמות גישה של מהימנות 'בינונית' ו'גבוהה', אתם יכולים להגדיר את הדרישות ל'גבוהה' כך שידרשו 'בינונית', בנוסף לתנאים אחרים.
הטמנת תנאים יכולה להקל על ניהול רמות הגישה. לדוגמה, נניח שרמת הגישה הכי מתירנית שלך מכילה גרסה מינימלית של מערכת ההפעלה, ואתה מגדיר את הרמות המגבילות יותר כך שיהיו תלויות בה. אם בעתיד תעדכנו את הגרסה המינימלית, תצטרכו לעדכן רק תנאי אחד, ולא כל רמת גישה במדיניות.