מדריך בסיסי VPC Service Controls

1. מבוא

‫VPC Service Controls‏ (VPC-SC) הוא אמצעי בקרה לאבטחה ברמת הארגון ב-Google Cloud, שמאפשר ללקוחות ארגוניים לצמצם את הסיכונים לזליגת נתונים. VPC Service Controls מספק גישה בסגנון אפס-אמון לשירותים מרובי-דיירים, על ידי מתן אפשרות ללקוחות להגביל את הגישה לכתובות IP מורשות, להקשר לקוח ולפרמטרים של מכשירים בזמן התחברות לשירותים מרובי-דיירים מהאינטרנט וממשירות אחרים, כדי לצמצם הפסדים מכוונים ולא מכוונים. אתם יכולים להשתמש ב-VPC Service Controls כדי ליצור גבולות גזרה שמגנים על המשאבים ועל הנתונים של שירותים שאתם מציינים באופן מפורש.

מטרות המדריך הזה:

• הסבר על העקרונות הבסיסיים של VPC Service Controls
• יצירת גבולות גזרה לשירות של VPC
• הגנה על פרויקט באמצעות VPC Service Controls
• פתרון בעיות שקשורות להפרה של תעבורת נתונים נכנסת (ingress) ב-VPC Service Controls

2. הגדרה ודרישות

כדי לבצע את המדריך הזה, אתם צריכים:

• ארגון ב-GCP.
• תיקייה מתחת לארגון.
• ‫2 פרויקטים ב-GCP באותו ארגון, שנמצאים בתיקייה.
• ההרשאות הנדרשות ברמת הארגון.
• חשבון לחיוב לשני הפרויקטים.

הגדרת משאבים

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

(אם אין לכם עדיין חשבון Google Workspace או Cloud Identity, אתם צריכים ליצור חשבון, כי תצטרכו ארגון כדי לבצע את ההדרכה הזו).

2. מוודאים שיש לכם את ההרשאות הנכונות לביצוע הפעולות במדריך הזה ברמת הארגון.

• תפקידי IAM לתיקיות
• הרשאות ותפקידים בפרויקטים
• הרשאות ותפקידים שנדרשים להגדרת VPC Service Controls
• הרשאות ותפקידים שנדרשים לניהול Compute Engine

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

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

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

עלות

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

המשאב היחיד שיפיק עלות הוא VM Instance. אפשר למצוא הערכת עלויות במחשבון התמחור.

3. יצירת היקף

בשיעור ה-Lab הזה נבצע את השלבים הבאים:

1. במסוף Google, בוחרים את הארגון ו ניגשים אל VPC Service Controls. חשוב לוודא שאתם ברמת הארגון.

2. לוחצים על 'ניהול מדיניות' כדי ליצור מדיניות גישה חדשה שמוגדרת לתיקייה Codelab.

3. יוצרים היקף חדש במצב אכיפה. במדריך הזה ניתן לו את השם SuperProtection.

• כשיוצרים את גבולות הגזרה, בוחרים את הפרויקט שרוצים לאכוף עליו את ההיקף בתור ProjectZ.
• בוחרים באפשרות 'רגיל' בתור סוג הגדר הווירטואלית.
• בתיבת הדו-שיח Specify services to restrict, בוחרים את השירות שרוצים להגביל, למשל Compute Engine.

הגדרת ההיקף צריכה להיראות כך:

4. איך מוודאים שההיקף נאכף

1. נכנסים לפרויקט ProjectX ומוודאים שאפשר לגשת ל-API של Compute Engine דרך דף הבית של המכונות הווירטואליות. אפשר לעשות את זה כי פרויקט X לא מוגן על ידי היקף ה-VPC SC שנוצר.
2. נכנסים לפרויקט ProjectZ ומוודאים שיש לכם גישה ל-Compute Engine. אפשר לראות שהבקשה נאסרה על ידי VPC Service Controls כי גבולות גזרה לשירות SuperProtection מגנים על ProjectZ ועל Compute Engine API.

5. פתרון בעיות שקשורות לדחייה

קודם צריך לזהות בדיוק מה הבעיה כדי להבין איך לפתור אותה.

1. היומנים של VPC Service Controls כוללים פרטים על בקשות למשאבים מוגנים ועל הסיבה לדחיית הבקשה על ידי VPC Service Controls. כדי למצוא את המזהה הייחודי של VPC Service Controls ביומני הביקורת של ProjectZ, משתמשים בשאילתה הבאה ב-Logs Explorer:

resource.type="audited_resource"
protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

יוצגו כל יומני הביקורת של VPC Service Controls. אנחנו נחפש את יומן השגיאות האחרון.

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

2. לוחצים על הכותרת VPC Service Controls ובוחרים באפשרות 'פתרון בעיות שקשורות לסירוב'. כך ייפתח פותר הבעיות של VPC Service Controls.

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

במסגרת התרגיל הזה, נחפש את הדברים הבאים:

"principalEmail": "user@domain"
"callerIp": "PUBLIC_IP_ADDRESS"
"serviceName": "compute.googleapis.com"
"servicePerimeterName":
"accessPolicies/[POLICY_NUMBER]/servicePerimeters/SuperProtection
"ingressViolations": [
        {
"targetResource": "projects/[PROJECT_NUMBER]",
"servicePerimeter": "accessPolicies/[POLICY_NUMBER]/servicePerimeters/SuperProtection"
        }
      ],
"violationReason": "NO_MATCHING_ACCESS_LEVEL",
"resourceNames": "[PROJECT_ID]"

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

יש לנו שתי אפשרויות לפתרון הדחייה הזו ב-ProjectZ.

• יצירת רמת גישה כדי לאפשר גישה לפרויקט בתוך ההיקף על ידי הענקת גישה לכתובת ה-IP של המערכת שלי.
• יצירת כלל לתעבורת נתונים נכנסת כדי לאפשר ללקוח API מחוץ לגבולות הגזרה לשירות לגשת למשאבים בתוך גבולות הגזרה לשירות.

במדריך הזה נפתור בעיות על ידי יצירת רמת גישה.

1. עוברים אל Access Context Manager בהיקף של תיקייה (Codelab) ויוצרים רמת גישה חדשה.
2. תשתמשו ב'מצב בסיסי', ואנחנו נאפשר גישה כשהרשת המשנית של כתובת ה-IP והמיקום הגיאוגרפי יעמדו בדרישות.

במעבדה הבאה, השתמשנו בכתובת ה-IP הציבורית של המערכת ובמיקום שלה. צריך לשנות את הערכים האלה בהתאם. אפשר לבדוק את כתובת ה-IP של המערכת בכתובת whatismyip.com

3. עוברים אל VPC Service Controls בהיקף הארגון. בוחרים את מדיניות הגישה ל-Codelab הזה ועורכים את ההיקף שיצרנו קודם.
4. מוסיפים את רמת הגישה שנוצרה בהיקף התיקייה ושומרים.

6. תוצאות הבדיקה.

מוודאים שיש לנו גישה ל-Compute Engine ואפשרות ליצור מכונת VM. אחרי שיצרנו את רמת הגישה, ננסה לגשת ל-Compute Engine בפרויקט ProjectZ וליצור מכונה וירטואלית.

1. עוברים אל Compute Engine ולוחצים על יצירת מכונה.

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

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

7. הסרת המשאבים

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

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

1. כדי למחוק את מכונת ה-VM, מסמנים את תיבת הסימון בצד ימין של שם מכונת ה-VM ולוחצים על מחיקה.

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

• במסוף Google Cloud, לוחצים על Security (אבטחה) ואז על VPC Service Controls (אמצעי בקרה לשירותי VPC) בהיקף הארגון.
• בדף VPC Service Controls (אמצעי בקרה של שירותי VPC), בשורת הטבלה שמתאימה להיקף שרוצים למחוק, לוחצים על סמל המחיקה.

3. כדי למחוק את רמת הגישה, מבצעים את השלבים הבאים:

• במסוף Google Cloud, פותחים את הדף Access Context Manager בהיקף התיקייה.
• ברשת, בשורה של רמת הגישה שרוצים למחוק, לוחצים על סמל המחיקה ואז על מחיקה.

4. כדי לכבות את הפרויקטים, מבצעים את השלבים הבאים:

• במסוף Google Cloud, עוברים לדף IAM & Admin Settings של הפרויקט שרוצים למחוק.
• בדף ההגדרות של IAM ואדמין, לוחצים על כיבוי.
• מזינים את מזהה הפרויקט ולוחצים על Shutdown anyway (השבתה בכל זאת).

8. מעולה!

ב-codelab הזה יצרתם גבול גזרה של VPC Service Controls, אכפתם אותו ופתרתם בו בעיות.

מידע נוסף

• מידע נוסף זמין במסמכי VPC Service Controls.
• מידע נוסף זמין במסמכים בנושא Access Context Manager.
• מידע נוסף על פותר הבעיות בנושא VPC-SC

רישיון

העבודה הזו בשימוש במסגרת רישיון Creative Commons שמותנה בייחוס כללי מגרסה 2.0.