כשמשתמשים ב-VPC Service Controls, יכול להיות קשה לקבוע את ההשפעה על הסביבה כשיוצרים או משנים גבולות גזרה לשירות. בעזרת מצב הרצה יבשה, תוכלו להבין טוב יותר את ההשפעה של הפעלת VPC Service Controls ושל שינויים ב-perimeters בסביבות קיימות.
במצב פרימטר לבדיקות, בקשות שמפירות את מדיניות ההיקף לא נדחות, אלא רק נרשמות ביומן. אתם יכולים להשתמש במצב פרימטר לבדיקות כדי לבדוק את הגדרת גבולות הגזרה ולעקוב אחר השימוש בשירותים בלי למנוע גישה למשאבים. תרחישים נפוצים לדוגמה:
לזהות את ההשפעה של שינויים בהיקפי שירות קיימים.
תצוגה מקדימה של ההשפעה של גבולות שירות חדשים.
מעקב אחרי בקשות לשירותים מוגנים שמקורן מחוץ לגבולות גזרה לשירות. לדוגמה, כדי לראות מאיפה מגיעות בקשות לשירות מסוים, או כדי לזהות שימוש לא צפוי בשירות בארגון שלכם.
בסביבות הפיתוח, ליצור ארכיטקטורת גבולות גזרה אנלוגית לסביבת הייצור. כך תוכלו לזהות ולצמצם בעיות שייגרמו על ידי גבולות השירות לפני שתדחפו שינויים לסביבת הייצור.
אפשר להשתמש בגבולות גזרה לשירות רק במצב פרימטר לבדיקות. אפשר גם להגדיר היקפי שירות שמשתמשים בשילוב של מצב אכיפה ומצב הרצה יבשה.
היתרונות של מצב פרימטר לבדיקות
באמצעות מצב פרימטר לבדיקות, אפשר ליצור גבולות גזרה לשירות חדשים או לשנות כמה גבולות גזרה קיימים בלי להשפיע על סביבה קיימת. בקשות שמפרות את ההגדרות החדשות של ההיקף לא נחסמות. תוכלו גם להבין את ההשפעה של גבולות הגזרה בסביבה שבה לא כל השירותים שבשימוש משולבים עם VPC Service Controls.
אפשר לנתח את היומנים של VPC Service Controls כדי לזהות דחיות, לשנות את ההגדרה כדי לתקן בעיות פוטנציאליות, ואז לאכוף את מצב האבטחה החדש.
אם לא הצלחתם לפתור בעיות בהגדרת ההיקף, אתם יכולים להשאיר את הגדרת ההרצה היבשה של ההיקף ולעקוב אחרי היומנים כדי לזהות דחיות לא צפויות שעשויות להצביע על ניסיון להוצאת נתונים. עם זאת, בקשות להיקף לא נדחות.
מושגים שקשורים למצב פרימטר לבדיקות
מצב פרימטר לבדיקות פועל כמעבר הערכה שני של הגדרת הגבולות. כברירת מחדל, ההגדרה של מצב האכיפה לכל גבולות הגזרה לשירות עוברת בירושה להגדרה של מצב פרימטר לבדיקות, שבה אפשר לשנות או למחוק את ההגדרה בלי להשפיע על הפעולה של גבול גזרה לשירות.
מצב פרימטר לבדיקות מקבל בירושה את הגדרת מצב האכיפה, ולכן בכל שלב שתי ההגדרות צריכות להיות תקפות. בפרט, פרויקט יכול להיות רק בגבולות גזרה אחד בהגדרה שנאכפת וגבולות גזרה אחד בהגדרה של הרצת בדיקה. כתוצאה מכך, שינויים שמתפרסים על פני כמה גבולות גזרה, כמו העברת פרויקט בין גבולות גזרה, צריכים להתבצע בסדר הנכון.
במצב פרימטר לבדיקות, בקשה נרשמת ביומן רק אם היא עומדת בשני הקריטריונים הבאים:
הבקשה לא נדחתה כבר על ידי ההרצה היבשה או ההגדרה האכיפה של ההיקף.
הבקשה מפרה את הגדרת ההרצה היבשה של גבולות הגזרה.
לדוגמה, אם הגדרות זהות של הרצת בדיקה ומצב אכיפה מגבילות קטגוריה של Cloud Storage, מצב האכיפה חוסם כל בקשה לקטגוריה של Cloud Storage ומתעד אותה ביומן. במצב פרימטר לבדיקות, המערכת מתעדת רק את ההבדלים בהפרות בהשוואה למצב האכיפה.
ביומני הביקורת של בדיקת מדיניות במצב פרימטר לבדיקות, הערך של השדה metadata.dryRun ביומן הביקורת מוגדר כ-True. מידע נוסף מופיע במאמר בנושא תוכן של רשומות ביומן הביקורת.
אפשר גם ליצור היקפים עם הגדרות של הרצה יבשה בלבד. כך תוכלו לדמות את ההשפעה של גבולות גזרה במצב אכיפה חדשים בסביבה שלכם.
כדי להעריך את הגדרת ההרצה היבשה של גבולות גזרה לשירות, מגדירים את השדה useExplicitDryRunSpec בהגדרת גבולות הגזרה לשירות לערך True.
מידע נוסף זמין במאמר accessPolicies.servicePerimeters.
סמנטיקה של מדיניות
בקטע הבא מתואר הקשר בין מדיניות שנאכפת לבין מדיניות במצב פרימטר לבדיקות, ומהו סדר הפעולות שבו מתבצעת האכיפה.
אילוץ ייחודי של חברות בקבוצה
אפשר לכלול פרויקט Cloud de Confiance by S3NS רק בהגדרה אחת של אכיפה ובהגדרה אחת של הרצה יבשה. עם זאת, ההגדרות של האכיפה ושל הרצת בדיקה לא צריכות להיות לאותו היקף. כך תוכלו לבדוק את ההשפעה של העברת פרויקט ממתחם אחד למתחם אחר בלי לפגוע באבטחה שמוחלת כרגע על הפרויקט.
דוגמה
פרויקט corp-storage מוגן כרגע על ידי התצורה האכיפה של גבולות גזרה PA. אתם רוצים לבדוק את ההשפעה של העברת corp-storage לגבולות גזרה PB.
ההגדרה של הרצת בדיקה של PA עדיין לא שונתה. מכיוון שההגדרה של ההרצה היבשה לא השתנתה, היא יורשת את corp-storage מההגדרה שנאכפת.
כדי לבדוק את ההשפעה, קודם מסירים את corp-storage מההגדרה של הרצת סימולציה עבור PA ומוסיפים את הפרויקט להגדרה של הרצת סימולציה עבור PB.
קודם צריך להסיר את corp-storage מההגדרה של ההרצה היבשה של PA, כי פרויקטים יכולים להיות רק בהגדרה אחת של הרצה יבשה בכל פעם.
אם אתם בטוחים שהעברה של corp-storage מ-PA ל-PB לא תשפיע לרעה על רמת האבטחה שלכם, אתם יכולים לאכוף את השינויים.
יש שתי דרכים לאכוף את השינויים בהיקפים PA ו-PB:
אפשר להסיר באופן ידני את
corp-storageמההגדרה שנאכפת עבור PA ולהוסיף את הפרויקט להגדרה שנאכפת עבור PB. מכיוון ש-corp-storageיכול להיות רק בהגדרה אחת שנאכפת בכל פעם, צריך לבצע את השלבים בסדר הזה.-or-
אפשר להשתמש בכלי שורת הפקודה
gcloudאו ב-Access Context Manager API כדי לאכוף את כל ההגדרות של הרצת בדיקה. הפעולה הזו חלה על כל ההגדרות של הרצות בדיקה ששונו לגבי גבולות הגזרה שלכם, ולכן כדאי לתאם את הפעולה עם כל מי ששינה בארגון שלכם הגדרות של הרצות בדיקה לגבי גבולות הגזרה. מכיוון שההגדרה של הרצת בדיקה ל-PA כבר לא כוללת אתcorp-storage, לא נדרשים שלבים נוספים.
ההגדרה שנאכפת של גבולות גזרה מופעלת קודם
רק בקשות שאושרו על ידי ההגדרה האכיפה של גבולות גזרה, אבל נדחו על ידי הגדרת הרצת בדיקה, נרשמות ביומן כהפרות של מדיניות הרצת בדיקה. בקשות שנדחות על ידי ההגדרה שנאכפת, אבל היו מתקבלות על ידי ההגדרה של ההרצה היבשה, לא נרשמות ביומן.
אין מצב פרימטר לבדיקות שמתאים לרמות גישה
אפשר ליצור הגדרת הרצה יבשה להיקף, אבל לרמות גישה אין הגדרת הרצה יבשה. בפועל, אם רוצים לבדוק איך שינוי ברמת הגישה ישפיע על ההגדרה של הרצת ניסיון, צריך:
יוצרים רמת גישה שמשקפת את השינויים שרוצים לבצע ברמת גישה קיימת.
מחילים את רמת הגישה החדשה על הגדרת הרצת הבדיקה של גבולות הגזרה.
למצב פרימטר לבדיקות אין השפעה שלילית על האבטחה
שינויים בהגדרת הרצת בדיקה של גבולות גזרה, כמו הוספת פרויקטים חדשים או רמות גישה לגבולות גזרה, או שינוי השירותים שמוגנים או נגישים לרשתות בתוך גבולות הגזרה, לא משפיעים על האכיפה בפועל של גבולות הגזרה.
לדוגמה, נניח שיש לכם פרויקט ששייך לגבולות גזרה לשירות PA. אם הפרויקט נוסף להגדרת הרצת בדיקה של גבולות גזרה אחרים, האבטחה בפועל שחלה על הפרויקט לא משתנה. הפרויקט ממשיך להיות מוגן על ידי ההגדרה שנאכפת של PA היקפי, כצפוי.
סטטוסים של פעולות והגדרות של הרצה יבשה
באמצעות התכונה 'הרצה יבשה' תוכלו:
יצירת גבולות גזרה עם הגדרת הרצת בדיקה בלבד
עדכון של הגדרת בדיקה של גבולות גזרה קיימים
העברת פרויקט חדש להיקף קיים
העברת פרויקט מגבולות גזרה אחד לאחר
מחיקת הגדרת בדיקה של service perimeter
בהתאם לפעולה שבוצעה במצב פרימטר לבדיקות, יכול להיות שסטטוס ההגדרה של ההיקף יהיה אחד מהסטטוסים הבאים:
הועבר מגבולות גזרה במצב אכיפה: מצב ברירת המחדל של גבולות גזרה במצב אכיפה. במצב הזה, כל שינוי בהגדרות האכיפה של ההיקף חל גם על הגדרות ההרצה היבשה.
שונה: בוצעה צפייה בהגדרה של הרצת בדיקה של גבולות גזרה או שינוי שלה, ואז היא נשמרה. במצב הזה, שינויים בתצורה האכיפה של גבולות גזרה לא חלים על תצורת הרצת בדיקה.
חדש: לגבולות הגזרה יש רק הגדרה של הרצת בדיקה. גם אם יבוצעו שינויים בהגדרות של ההרצה היבשה, הסטטוס יישאר חדש עד שיהיו להגדרות של הגבול הזה הגדרות מחייבות.
Deleted (נמחק): הגדרת הרצת הבדיקה של הפרימטר נמחקה. הסטטוס הזה יישאר עד שתיצרו הגדרה חדשה של הרצת בדיקה לגבולות הגזרה או עד שתבטלו את הפעולה. במצב הזה, שינויים בתצורה האכיפה של גבולות גזרה לא חלים על תצורת הרצת בדיקה.
מגבלות של מצב פרימטר לבדיקות
מצב פרימטר לבדיקות רלוונטי רק לגבולות גזרה. הוא לא עוזר להבין את ההשפעה של הגבלת הגישה ל-API ל Cloud de Confiance by S3NS VIP מוגבל או פרטי. מומלץ לוודא שכל השירותים שרוצים להשתמש בהם זמינים ב-VIP המוגבל לפני שמגדירים את הדומיין restricted.googleapis.com.
אם אתם לא בטוחים אם ממשקי ה-API שבהם אתם משתמשים בסביבה קיימת נתמכים על ידי ה-VIP המוגבל, מומלץ להשתמש ב-VIP הפרטי. עדיין אפשר לאכוף אבטחה היקפית בשירותים נתמכים. עם זאת, אם משתמשים ב-VIP הפרטי, לישויות ברשת תהיה גישה לשירותים לא מאובטחים (שירותים שלא נתמכים על ידי VPC Service Controls), כמו הגרסאות לצרכנים של Gmail ו-Drive. מכיוון שכתובת ה-IP הווירטואלית הפרטית מאפשרת גישה לשירותים שלא נתמכים על ידי VPC Service Controls, יכול להיות שקוד שנפרץ, תוכנות זדוניות או משתמש זדוני ברשת שלכם יוכלו להעביר נתונים באמצעות השירותים הלא מאובטחים האלה.
מה השלב הבא?
בודקים את הפקודות של כלי שורת הפקודה
gcloudלמצב פרימטר לבדיקות