מדריך בסיסי VPC Service Controls 2 – פתרון בעיות של הפרה של תעבורת נתונים יוצאת (egress)

1. מבוא

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

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

  • הסבר על העקרונות הבסיסיים של VPC Service Controls
  • עדכון של גבולות גזרה לשירות ובדיקה שלו באמצעות מצב פרימטר לבדיקות
  • הגנה על שני שירותים באמצעות VPC Service Controls
  • פתרון בעיות של הפרת יציאה ב-VPC Service Controls במהלך הצגת רשימה של אובייקט מ-Cloud Storage

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

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

dbec101f41102ca2.png

Resources-setup

  1. מגדירים את המשאבים כמו שמתואר בקטע Resources-setup (הגדרת משאבים) במאמר VPC Service Controls Basic Tutorial I (הדרכה בסיסית בנושא VPC Service Controls, חלק א')
  2. מוודאים שיש לכם את ההרשאות הנדרשות לניהול Cloud Storage.
  3. במדריך הזה נתחיל להשתמש ב-CLI במקום במסוף Cloud. מגדירים את ה-CLI של gcloud באחת מסביבות הפיתוח הבאות:
  • ‫Cloud Shell: כדי להשתמש בטרמינל אונליין שבו כבר מוגדר ה-CLI של gcloud, צריך להפעיל את Cloud Shell.

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

a0ceb29950db4eac.png

  • מעטפת מקומית: כדי להשתמש בסביבת פיתוח מקומית, צריך להתקין ולהפעיל את ה-CLI של gcloud.

עלות

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

המשאבים היחידים שיצרו עלות הם VM Instance ו-Cloud Storage Object. אפשר למצוא את העלות המשוערת של מופע מכונה וירטואלית במחשבון התמחור. העלות המשוערת של Cloud Storage מופיעה במחירון הזה.

3. יצירת קטגוריית אחסון ואובייקט

כמו שציינו קודם, אנחנו הולכים להשתמש מחדש במשאבים שנוצרו בהמדריך הקודם. לכן נמשיך בתהליך ליצירת הקטגוריה של Cloud Storage. במדריך הזה נתחיל להשתמש ב-CLI של gcloud במקום במסוף.

  1. במסוף Google, בוחרים באפשרות ProjectX. בפרויקט הזה, ניצור את קטגוריית האחסון ואת האובייקט.
  2. מוודאים שהגדרתם את Cloud Shell לשימוש ב-ProjectX על ידי הרצת הפקודה הבאה:
gcloud config set project PROJECT_ID
  1. בסביבת הפיתוח, מריצים את הפקודה הבאה:
gcloud storage buckets create gs://BUCKET_NAME --location=us-central1
  1. יוצרים אובייקט אחסון כדי שנוכל לקרוא אותו ממופע של מכונה וירטואלית שנמצא בפרויקט ProjectZ. ניצור קובץ ‎ .txt.
nano hello.txt

מוסיפים לטקסט כל מה שרוצים.

  1. מעלים את האובייקט לקטגוריה.
gcloud storage cp /home/${USER}/hello.txt gs://BUCKET_NAME
  1. כדי לוודא שהאובייקט הועלה לקטגוריה, מציגים את הרשימה.
gcloud storage ls gs://BUCKET_NAME

הקובץ hello.txt צריך להופיע במסוף.

4. הגנה על Cloud Storage API

ב-Codelab הקודם יצרנו גבולות גזרה והגנו על Compute Engine API. ב-codelab הזה נשנה את גבולות הגזרה של מצב פרימטר לבדיקות ונוסיף את Cloud Storage. כך נוכל להבין את ההשפעה של הגנת גבולות גזרה על ידי הצגת הפרות של VPC Service Controls ביומני הביקורת, אבל המשאבים יישארו נגישים עד שנאכוף את גבולות הגזרה.

  1. במסוף Google, בוחרים את הארגון שלכם ו ניגשים אל VPC Service Controls. מוודאים שאתם בהיקף הארגון.
  2. פותחים את Cloud Shell ומעדכנים את גבולות הגזרה לבדיקות SuperProtection שנוצרו במעבדה הקודמת:
gcloud access-context-manager perimeters dry-run update SuperProtection --policy=POLICY --add-restricted-services=storage.googleapis.com
  1. אימות העדכון של Cloud Storage API על ידי תיאור ההיקף
gcloud access-context-manager perimeters dry-run describe SuperProtection --policy=POLICY

בפלט, תראו שממשק Cloud Storage API מופיע מתחת לשירותים המוגבלים.

יחד עם Compute Engine API, אבל עם התווית -vpcAccessibleServices: {}":

2025ddc01a2e9a81.png

5. בדיקה שה-API של Cloud Storage מוגן

במצב פרימטר לבדיקות, מוודאים שהגבולות גזרה 'SuperProtection' מציג את הדחייה על ידי הצגת רשימת האובייקטים ממכונת ה-VM שנוצרה ב-ProjectZ אל ProjectX שמארח את קטגוריית האחסון.

  1. ב-Cloud Console, עוברים אל בורר הפרויקטים ובוחרים את ProjectZ, ואז מנווטים אל Compute Engine > VM Instances.
  2. לוחצים על לחצן ה-SSH כדי להתחבר למופע של מכונה וירטואלית ולגשת לשורת הפקודה שלו.

5ca02149b78c11f9.png

  1. מציגים את הקובץ hello.txt שהעלינו קודם.
gcloud storage ls gs://BUCKET_NAME

מכיוון ש-Cloud Storage API מוגן במצב פרימטר לבדיקות, אמורה להיות לכם אפשרות להציג את רשימת המשאבים, אבל צריכה להופיע הודעת שגיאה ביומני הביקורת של ProjectZ.

  1. עוברים אל Logs Explorer API בפרויקט Z ומחפשים את הודעת השגיאה האחרונה של VPC Service Controls. אפשר להשתמש במסנן הזה כדי לקבל את היומן שאנחנו מחפשים:
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
"(Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:UNIQUE_ID"

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

egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTX_ID"
sourceType: "Network"
targetResource: "projects/PROJECTZ_ID"
}
]
resourceNames: [
0: "projects//buckets/BUCKET_NAME"
]
securityPolicyInfo: {
organizationId: "ORGANIZATION_ID"
servicePerimeterName: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
vpcServiceControlsUniqueId: "UNIQUE_ID"
}
methodName: "google.storage.objects.list"
  1. מאחר שאימתנו שהקריאה ל-Cloud Storage API יוצרת הפרה של VPC Service Controls, נאכוף את גבולות גזרה עם ההגדרה החדשה. פותחים את Cloud Shell ואוכפים את גבולות הגזרה לבדיקות:
gcloud access-context-manager perimeters dry-run enforce SuperProtection --policy=POLICY --async
  1. מתחברים למופע של ה-VM באמצעות SSH ומציגים שוב את רשימת דלי האחסון כדי לוודא שגבולות הגזרה לבדיקות נאכפים בצורה נכונה.
gcloud storage ls gs://BUCKET_NAME

במקום רשימה של אובייקטים של Storage, נקבל הפרה של VPC Service Control ב-CLI של מכונת ה-VM:

ERROR: (gcloud.storage.ls) User [PROJECT_NUMBER-compute@developer.gserviceaccount.com] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:"UNIQUE_ID"

הצלחנו למנוע זליגת מידע באמצעות VPC Service Controls כדי למנוע קריאת נתונים ממשאב מחוץ לגבולות הגזרה או העתקת נתונים למשאב כזה.

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

נפתור את הבעיה שגרמה לדחייה שקיבלנו מ-CLI של מופע VM. בואו נבדוק את יומני הביקורת ונחפש את המזהה הייחודי של VPC Service Controls.

  1. עוברים לרשימת הפרויקטים ובוחרים את ProjectZ.
  2. כדי למצוא את המזהה הייחודי של VPC Service Controls ביומני הביקורת, משתמשים בשאילתה הבאה ב-Logs Explorer:
resource.type="audited_resource"
protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

יוצגו כל יומני הביקורת של VPC Service Controls. אנחנו נחפש את יומן השגיאות האחרון. מכיוון שהקריאה ל-API בוצעה מהמכונה הווירטואלית, חשבון המשתמש הראשי צריך להיות חשבון השירות של Compute Engine‏ PROJECT_NUMBER-compute@developer.gserviceaccount.com"

מכיוון שכבר יש לנו את המזהה הייחודי של VPC Service Controls, אנחנו יכולים להשתמש בו כדי לקבל את היומן הרצוי ישירות באמצעות המסנן הזה:

protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_ID"
  1. לוחצים על הכותרת VPC Service Controls ובוחרים באפשרות 'פתרון בעיות שקשורות לדחייה'. כך ייפתח פותר הבעיות של VPC Service Controls.

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

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

authenticationInfo: {
principalEmail: "PROJECT_ID-compute@developer.gserviceaccount.com"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTZ_ID"
sourceType: "Network"
targetResource: "projects/PROJECTX_ID"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"

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

  1. מפעילים את Cloud Shell ויוצרים קובץ ‎ .yaml עם כלל היציאה באמצעות כלי לעריכת טקסט.
nano egresstorage.yaml 

- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: \"*\"
    resources:
    - projects/PROJECTX_ID
 egressFrom:
    identities:
    - serviceAccount:PROJECT_ID-compute@developer.gserviceaccount.com
  1. מעדכנים את מדיניות הכניסה שמגנה על ProjectZ.
gcloud access-context-manager perimeters update SuperProtection --set-egress-policies=egresstorage.yaml --policy=POLICY

עכשיו אפשר לנסות שוב לגשת לדלי ממופע ה-VM.

  1. ב-Cloud Console, עוברים אל בורר הפרויקטים ובוחרים את ProjectZ, ואז מנווטים אל Compute Engine > VM Instances.
  2. לוחצים על לחצן ה-SSH כדי להתחבר למופע של מכונה וירטואלית ולגשת לשורת הפקודה שלו.
  3. אחרי שנכנסים ל-CLI של ה-VM, מנסים ליצור רשימה של האובייקטים בקטגוריית האחסון.
gcloud storage ls gs://BUCKET_NAME/

תוצג הודעת השגיאה הבאה:

ERROR: (gcloud.storage.ls) User [PROJECT_ID-compute@developer.gserviceaccount.com] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): PROJECT_ID-compute@developer.gserviceaccount.com does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist).
  1. אנחנו צריכים להעניק הרשאת קריאת אובייקטים לחשבון השירות של Compute Engine כדי שנוכל לראות את רשימת האובייקטים בקטגוריית האחסון.
gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=serviceAccount:PROJECT_ID-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer
  1. בואו ננסה שוב להציג את הקובץ hello.txt מ-CLI של המכונה הווירטואלית .
gcloud storage ls gs://BUCKET_NAME/
.
.
gs://BUCKET_NAME/hello.txt

עכשיו אפשר לראות את רשימת האובייקטים בלי הפרה של הרשאת VPC Service Controls, אבל מה לגבי הורדה של הקובץ? בוא ננסה.

gcloud storage cp gs://BUCKET_NAME/hello.txt /home/${USER}

ונקבל את הפלט הבא

Copying gs://BUCKET_NAME/hello.txt to file:///home/${USER}
 Completed files 1/1 | 54.0B/54.0B

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

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

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

da0abf0894fe03cd.png

  1. כדי למחוק את גבולות הגזרה, מבצעים את השלבים הבאים:
  • במסוף Google Cloud, לוחצים על Security (אבטחה) ואז על VPC Service Controls (אמצעי בקרה לשירותי VPC) בהיקף הארגון.
  • בדף VPC Service Controls (אמצעי בקרה של שירותי VPC), בשורת הטבלה שמתאימה להיקף שרוצים למחוק, לוחצים על סמל המחיקה.
  1. כדי למחוק את רמת הגישה, מבצעים את השלבים הבאים:
  • במסוף Google Cloud, פותחים את הדף Access Context Manager בהיקף התיקייה.
  • ברשת, בשורה של רמת הגישה שרוצים למחוק, לוחצים על סמל המחיקה ואז על מחיקה.
  1. כדי למחוק את אובייקט האחסון ואת הקטגוריה, מבצעים את השלבים הבאים:
  • במסוף Google Cloud, פותחים את הדף Cloud Storage buckets .
  • מסמנים את התיבה ליד הקטגוריה שיצרתם.
  • לוחצים על מחיקה.
  • בחלון שנפתח, מאשרים שרוצים למחוק את הקטגוריה.
  • לוחצים על מחיקה.
  1. כדי להשבית את הפרויקט, מבצעים את השלבים הבאים:
  • במסוף Google Cloud, עוברים לדף IAM & Admin Settings של הפרויקט שרוצים למחוק.
  • בדף ההגדרות של IAM ואדמין, לוחצים על כיבוי.
  • מזינים את מזהה הפרויקט ולוחצים על Shutdown anyway (השבתה בכל זאת).

8. מעולה!

ב-codelab הזה עדכנתם מתחם היקפי של VPC Service Controls במצב Dry-run, הפעלתם אותו ופתרתם בו בעיות.

מידע נוסף

רישיון

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