סקירה כללית על Access Context Manager

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

רמות הגישה מתארות את הדרישות שצריך לעמוד בהן כדי שהבקשות יאושרו. לדוגמה:

  • סוג המכשיר ומערכת ההפעלה
  • כתובת IP
  • זהות המשתמש

גבולות גזרה לשירות מגדירים ארגזי חול של משאבים. משאבים בתוך ההיקף יכולים להחליף נתונים באופן חופשי, אבל לא יכולים לייצא נתונים מחוץ להיקף. ‫Access Context Manager לא אחראי לאכיפת המדיניות. במקום זאת, Access Context Manager נועד להגדיר כללים או הקשרים ספציפיים. המדיניות מוגדרת ונאכפת בנקודות שונות, כמו VPC Service Controls. מידע נוסף על השירותים האלה זמין במדריכים למשתמשים של כל אחד מהם.

אתם יכולים להגדיר ולאכוף כללי מדיניות של Access Context Manager ברכיבי הפתרונות הבאים של Chrome Enterprise Premium:

יתרונות

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

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

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

‫Access Context Manager הוא חלק בלתי נפרד מהמאמץ של Google בתחום BeyondCorp. למידע נוסף, ראו BeyondCorp.

כללי מדיניות גישה

מדיניות גישה היא מאגר לכל המשאבים של Access Context Manager, כמו רמות גישה וגבולות גזרה לשירות.

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

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

במאמר יצירת מדיניות גישה מוסבר איך יוצרים מדיניות גישה.

רמות גישה

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

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

אפשר להתאים אישית את רמות הגישה. רמות הגישה High_Trust ו-Medium_Trust הן דוגמאות. אפשר לציין כמה רמות גישה כחלק ממדיניות גישה.

ב-Access Context Manager יש שתי דרכים להגדיר רמות גישה:

  • רמת גישה בסיסית מורכבת מאוסף של תנאים שמשמשים לבדיקת בקשות. אפשר להגדיר תנאים כקבוצת מאפיינים שרוצים לבדוק, כמו סוג המכשיר, כתובת ה-IP או זהות המשתמש. המאפיינים משולבים כפעולת AND (כולם חייבים להיות נכונים) או כפעולת NAND (לפחות אחד חייב להיות שקרי) כדי לקבוע אם התנאי מתקיים.

  • רמות גישה בהתאמה אישית נוצרות באמצעות קבוצת משנה של Common Expression Language. בנוסף להקשר של הבקשה שמשמש לרמות גישה בסיסיות, אתם יכולים להשתמש גם ברמות גישה בהתאמה אישית כדי לאשר בקשות על סמך נתונים משירותי צד שלישי. מידע נוסף זמין במאמר רמות גישה בהתאמה אישית. 

!(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)
  • fc00::/7 (כתובות מקומיות ייחודיות של IPv6, ‏RFC 4193)

סוג המכשיר

ב-Access Context Manager משתמשים באימות נקודת קצה (Endpoint Verification) כדי לאסוף מידע על מכשירי המשתמשים, כמו מערכת ההפעלה, סוג המכשיר או הגרסה. אתם יכולים להעניק רמת גישה על סמך הנתונים האלה. לדוגמה, אתם יכולים להעניק רמת גישה עם יותר הרשאות למכשירים שפועלת בהם הגרסה העדכנית של מערכת ההפעלה הראשית שפרוסה בחברה.

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

זהות המשתמש

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

אפשר ליצור ולנהל רמות גישה שמבוססות על זהות בלבד באמצעות כלי שורת הפקודה gcloud, אבל לא באמצעות מסוף Google Cloud .

כדי להתחיל ליצור רמת גישה בסיסית, קראו את המאמר יצירת רמת גישה ל-Access Context Manager.

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

שילוב של תנאים

רמת גישה אחת יכולה להכיל כמה תנאים. אפשר להעריך את התנאים באמצעות האופרטור AND או OR. אפשר לציין את המצב כשיוצרים או מעדכנים רמת גישה.

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

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

תנאים מקוננים

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

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

כשמגדירים רמות גישה בתצוגת עץ, חשוב לזכור את המגבלות הבאות:

  • אין תלויות מעגליות: אסור להשתמש בתלויות מעגליות. רמות גישה לא יכולות להפנות זו לזו בלולאה, באופן ישיר (לדוגמה, Level_A דורשת את Level_B ו-Level_B דורשת את Level_A, או שרמת גישה מפנה לעצמה) או באופן טרנזיטיבי (לדוגמה, Level_A דורשת את Level_B, Level_B דורשת את Level_C ו-Level_C דורשת את Level_A). אם תנסו ליצור או לעדכן רמת גישה שיוצרת תלות מעגלית, הקריאה תיכשל ותופיע השגיאה INVALID_ARGUMENT.

  • מספר מקסימלי של יחסי תלות לכל תנאי: ברמת גישה בסיסית, הרשימה requiredAccessLevels של תנאי אחד יכולה להפנות לעד 15 רמות גישה אחרות.

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

מידע נוסף