תמיכה בתיקיות בגבולות גזרה לשירות

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

במאמר הזה מוסבר איך תמיכה בתיקיות פועלת בהיקפים, ומוצגים בו הנושאים הבאים:

  • מושגים מרכזיים, התנהגויות ויתרונות של שימוש בתיקיות בהיקפים.

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

  • איך מחפשים את ההיקפים שהוגדרו לפרויקטים ולתיקיות.

  • שיטות מומלצות ומגבלות ידועות לשימוש בתכונה הזו.

מידע על חברות בתיקייה בהיקפים

Google Cloud תיקייה יכולה להכיל מספר פרויקטים, תיקיות אחרות או שילוב של השניים. אפשר להוסיף פרויקטים בודדים בתוך תיקייה לגבולות גזרה לשירות, אבל מומלץ להוסיף את התיקייה הראשית במקום. כשמציינים תיקייה כמשאב מוגן כשיוצרים מתחם אבטחה,‏ VPC Service Controls כולל את כל המשאבים בתיקייה הזו, כמו פרויקטים ותיקיות מקוננות.

כשמוסיפים פרויקטים לתיקייה שהגדרתם ב-perimeter, מערכת VPC Service Controls מוסיפה את הפרויקטים האלה אוטומטית לאותו perimeter. אין צורך לעדכן את הגדרת ההיקף כדי לכלול את הפרויקטים האלה. באופן דומה, כשמסירים פרויקטים מהתיקייה, מערכת VPC Service Controls מסירה את הפרויקטים האלה מהגבול באופן אוטומטי.

תיקיות בתוך תיקיות וירושה

VPC Service Controls מגביל את כל המשאבים בתיקייה שהגדרתם ב-perimeter, כמו תיקיות מקוננות והמשאבים שלהן. כשמוסיפים תיקייה להיקף, VPC Service Controls מגביל אוטומטית את כל הפרויקטים בתיקייה הזו ובתיקיות המשנה שלה.

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

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

מערכת VPC Service Controls מעריכה את העדיפות באופן עצמאי עבור מצב אכיפה ומצב הרצה יבשה:

  • עדיפות של מצב אכיפה: ההיקף האפקטיבי של האכיפה נקבע לפי המשאב הנמוך ביותר בהיררכיה (הפרויקט עצמו או תיקיית האב הקרובה ביותר שלו) שהוקצה לו באופן מפורש היקף אכיפה.
  • עדיפות של מצב הרצה יבשה: ההיקף האפקטיבי של ההרצה היבשה נקבע לפי המשאב הנמוך ביותר בהיררכיה שהוקצה באופן מפורש להיקף של הרצה יבשה או שהועבר בירושה באופן מרומז ממשאב נאכף שהוקצה באופן מפורש.

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

דוגמאות לקדימות

  • דוגמה 1 (שינוי מברירת המחדל של פרויקט בגבולות גזרה במצב אכיפה): אם מגדירים תיקיית אב (folders/1) בגבולות גזרה במצב אכיפה (sp1) ומגדירים באופן מפורש פרויקט בתוך התיקייה הזו (projects/1) בגבולות גזרה אחרים במצב אכיפה (sp2), הפרויקט projects/1 מוגן על ידי sp2. הקצאה ישירה לפרויקט מקבלת עדיפות על פני הרשאות שעוברות בירושה מתיקייה. כל שאר הפרויקטים ב-folders/1 (למשל projects/2) ממשיכים להיות מוגנים על ידי sp1 באמצעות ירושת הרשאות בתיקייה.

  • דוגמה 2 (העברת הרשאות בתיקייה במצב פרימטר לבדיקות): כשמגדירים תיקייה (folders/1) בגבולות גזרה לשירות במצב פרימטר לבדיקות, כל הפרויקטים בתיקייה הזו (projects/1 ו-projects/2) מקבלים בירושה את הגדרת גבולות הגזרה לבדיקות (sp1), אלא אם היא מושבתת באופן מפורש. התנהגות ההורשה במצב פרימטר לבדיקות זהה להתנהגות ההורשה במצב אכיפה, אלא אם משאב מקונן מוגדר במפורש עם פרימטר אחר לבדיקות.

  • דוגמה 3 (הערכה עצמאית של היקפי אבטחה שנאכפים והיקפי אבטחה במצב הרצת בדיקה): מערכת VPC Service Controls מעריכה את השיוכים של היקפי אבטחה שנאכפים והיקפי אבטחה במצב הרצת בדיקה באופן עצמאי. אם מגדירים תיקיית אב (folders/1) בגבול גזרה נאכף (sp1) ומקצים באופן מפורש פרויקט בתוך התיקייה הזו (projects/1) לגבול גזרה של הרצה יבשה (sp2), הפרויקט projects/1 נשאר מוגן על ידי sp1 במצב נאכף, ובמקביל נבדק במצב הרצה יבשה על ידי sp2. הקצאת פרויקט לגבולות גזרה לבדיקות לא מבטלת את גבולות הגזרה במצב אכיפה של תיקיית האב ולא משביתה אותו.

  • דוגמה 4 (היררכיית תיקיות מרובת רמות ועדיפות של תיקיות משנה): בהיררכיית תיקיות מרובת רמות, VPC Service Controls מעריך את העדיפות בכל רמה בהיררכיה. אם תיקיית אב (folders/2) מוגדרת בהיקף אכיפה (sp1), כל הפרויקטים שכלולים בה (projects/1 ו-projects/2) יורשים את האכיפה של sp1. כשמקצים גבולות גזרה לבדיקות ברמות שונות – למשל, הקצאת folders/2 של ישות אם לגבול גזרה לבדיקות sp2 ופרויקט projects/2 (בתיקיית משנה folders/1) לגבול גזרה לבדיקות sp1 – כל פרויקט מקבל בירושה את הגדרת ההרצה היבשה מהישות אם הקרובה ביותר שלו. כתוצאה מכך, המערכת מעריכה את projects/1 בהרצת הבדיקה sp2, אבל את projects/2 בהרצת הבדיקה sp1.

חיפוש של היקפים יעילים שהוגדרו

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

ה-API מחזיר את הנתונים הבאים:

  • ‫servicePerimeter: השם המלא של ההיקף האפקטיבי שנאכף.
  • ‫servicePerimeterDryRun: השם המלא של גבולות הגזרה האפקטיביים לבדיקות.
  • ‫restrictedResource: המשאב הספציפי (פרויקט או תיקייה) שאליו מצורף ישירות היקף האכיפה.
  • ‫restrictedResourceDryRun: המשאב הספציפי שאליו מצורף ישירות גבולות הגזרה לבדיקות.

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

החרגה של פרויקטים מההיקפים

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

מידע על עדכון גבולות גזרה מופיע במאמר עדכון גבולות גזרה לשירות.

כללי מדיניות בהיקף מוגבל

גבולות גזרה לשירותים בתוך מדיניות מוגבלת מגבילים רק את המשאבים שקיימים בהיקף המדיניות הזו. כדי שתיקייה תיכלל כחברה בהיקף מוגבל, מדיניות הגישה צריכה להיות מוגבלת לתיקייה הזו או לתיקיית אב שלה (כמו תיקיית הורה או הארגון).

שיטות מומלצות

ריכזנו כאן כמה שיטות מומלצות לניהול של גבולות לפי תיקיות.

העברה בטוחה של פרויקטים להיקפי תיקיות

כשעוברים מחברות מפורשת בפרויקט לחברות שמבוססת על תיקיות, כדאי לפעול לפי השלבים הבאים כדי למנוע שיבושים לא מכוונים באכיפת ההיקף:

  1. מוסיפים את תיקיית היעד הראשית לגבולות הגזרה לשירות.
  2. מעבירים את הפרויקטים לתיקיית ההורה בהיררכיית המשאבים.
  3. ממתינים לפחות 48 שעות: משאירים את הרשומות של הפרויקט המפורש בהגדרת ההיקף למשך 48 שעות לפחות. תקופת ההמתנה הזו מאפשרת להשלים את ההפצה של ההיררכיה של המשאבים בכל המערכות.
  4. מסירים את ההגדרות המפורשות של הפרויקט מההיקף. הפרויקטים ממשיכים להיות מוגנים באמצעות הרשאות שמועברות מהתיקייה.

העברות בהיררכיה

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

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

מגבלות

  • אין תמיכה בחברות שמבוססת על תיקיות בגשרים של היקף האבטחה. גשרים של היקפי אבטחה מקבלים רק משאבים של פרויקטים.

  • שירות VPC Service Controls לא תומך במשאבי API ברמת התיקייה.

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

  • חברות בתיקייה לא נתמכת בממשקי API שאינםGoogle Cloud ובגבולות שהוגדרו באמצעות allowed_service_patterns. כדי לאפשר גישה לדפוסי השירות האלה, צריך להוסיף את הפרויקטים או את רשתות ה-VPC המקוריות להיקף באופן מפורש, ולא באמצעות ירושה דרך תיקייה.

המאמרים הבאים