מדריך בסיסי 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
  • עדכון של גבולות גזרה לשירות ובדיקה שלו באמצעות מצב Dry-run
  • הגנה על שני שירותים באמצעות VPC Service Controls
  • פתרון בעיות של הפרת יציאה ב-VPC Service Controls במהלך הצגת רשימה של אובייקט מ-Cloud Storage

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

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

  • ארגון GCP.
  • תיקייה מתחת לארגון.
  • ‫2 פרויקטים ב-GCP באותו ארגון, שנמצאים בתיקייה.
  • ההרשאות הנדרשות ברמת הארגון.
  • חשבון לחיוב לשני הפרויקטים.
  • VPC Service Controls Basic Tutorial I VPC Service Controls and Access Context Manager setup.

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 שנוצר בשיעור Lab הקודם:
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. מתחברים למופע של המכונה הווירטואלית באמצעות 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 ובוחרים באפשרות Troubleshoot denial (פתרון בעיות של דחייה). פותר הבעיות של 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 לגשת לדלי האחסון מפרויקט Z לפרויקט X. בנוסף, אנחנו רואים שהרשת לא נמצאת באותם גבולות גזרה, ולכן צריך לאפשר תקשורת 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.