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

1. מבוא

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

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

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

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

למדריך הזה נדרשות הדרישות המקדימות הבאות:

dbec101f41102ca2.png

הגדרת משאבים

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

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

a0ceb29950db4eac.png

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

עלות

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

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

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

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

  1. במסוף Google, בוחרים באפשרות ProjectX. בפרויקט הזה תיצרו את קטגוריית האחסון ואת האובייקט.
  2. ודאו שהגדרתם את המעטפת של הענן לשימוש ב-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. הגנה על ממשק ה-API של Cloud Storage

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

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

בפלט יופיע ש-Cloud Storage API מופיע מתחת לשירותים המוגבלים

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

2025ddc01a2e9a81.png

5. מוודאים ש-Cloud Storage API מוגן

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

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

5ca02149b78c11f9.png

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

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

  1. נכנסים אל Logs Explorer API ב-ProjectZ ומחפשים את הודעת השגיאה האחרונה של 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. וידאנו שהקריאה ל-API ל-Cloud Storage יוצרת הפרה של 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

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

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"

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

  1. מפעילים את Cloud Shell ויוצרים קובץ yaml עם כלל תעבורת הנתונים היוצאת (egress) באמצעות כלי לעריכת טקסט.
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. לעדכן את מדיניות תעבורת הנתונים הנכנסת (ingress) שמגינה על ProjectZ.
gcloud access-context-manager perimeters update SuperProtection --set-egress-policies=egresstorage.yaml --policy=POLICY

עכשיו נוכל לנסות שוב לגשת לקטגוריה מהמכונה הווירטואלית.

  1. במסוף Cloud, עוברים אל בורר הפרויקטים, בוחרים באפשרות ProjectZ ועוברים ל-Compute Engine > מכונות וירטואליות.
  2. לוחצים על לחצן ה-SSH כדי להתחבר למכונה הווירטואלית ולגשת לשורת הפקודה שלה.
  3. אחרי שנכנסים ל-VM CLI, מנסים להציג את רשימת האובייקטים בקטגוריית האחסון.
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 ולוחצים על Delete.

da0abf0894fe03cd.png

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

8. מעולה!

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

מידע נוסף

רישיון

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