מדריך בסיסי 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.
• תיקייה בארגון.
• שני פרויקטים של 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. אפשר למצוא עלות משוערת במחשבון התמחור.

3. יצירת גבולות גזרה

במעבדה הזו נבצע את השלבים הבאים:

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

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

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

• כשיוצרים את גבולות הגזרה, צריך לבחור את הפרויקט לאכיפה כ-ProjectZ.
• בוחרים את סוג ההיקף כ'רגיל'.
• בתיבת הדו-שיח ציון שירותים להגבלה, בוחרים את השירות שרוצים להגביל כ-Compute Engine.

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

4. יש לוודא שגבולות הגזרה נאכפים

1. נכנסים ל-ProjectX ומוודאים שיש לכם גישה ל-Compute Engine API בדף הבית של מכונות וירטואליות. תוכלו לעשות זאת כי projectX לא מוגן על ידי ההיקף של 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 Controls שקיבלנו בזמן שאימות הגבולות נאכף.

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, דרישת המכשיר או זהות המשתמש לא תואמים לכללי תעבורת הנתונים הנכנסת (ingress) או לרמות הגישה שהוקצו לגבולות הגזרה. אם כתובת ה-IP של המתקשר חסרה או מופיעה ככתובת IP פנימית, יכול להיות שההפרה נובעת משירות Google Cloud שלא משולב עם VPC Service Controls. בדף הזה מפורט מידע נוסף על בעיות נפוצות ב-VPC Service Controls.

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

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

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

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

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

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

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

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

1. נכנסים אל Compute Engine ולוחצים על Create Instance

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

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

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

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

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

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

2. כדי למחוק את ההיקף:

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

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

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

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

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

8. מעולה!

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

מידע נוסף

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

רישיון

היצירה הזו בשימוש ברישיון Creative Commons Attribution 2.0 גנרי.