שיטות מומלצות להפעלת VPC Service Controls

במאמר הזה מתואר התהליך המומלץ להגדרת הגנה באמצעות VPC Service Controls בארגון Google Cloud .

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

לכל עומס עבודה או אפליקציה שמצטרפים ל-VPC Service Controls, צריך לחזור על תהליך ההפעלה.

תיאום התקשורת

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

  • Google Cloud דפוסי גישה לממשקי API
  • זיהוי הפרות של גבולות גזרה לשירות
  • מתן גישה לגבולות גזרה

בדומה לחומות אש רגילות ברשת, המטרה היא לזהות ולאפשר את התנועה שנדרשת לתפקוד יעיל של עומסי עבודה עסקיים לגיטימיים.

דפוסי גישה למסמכים ותרחישי שימוש

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

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

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

  • אדמינים של הענן מנהלים פרויקטים שכלולים בהיקף.
  • שירותי אוטומציה כמו Terraform, ‏ Jenkins ו-Microsoft Azure DevOps שנמצאים מחוץ לגבולות, מנהלים את פריסת המשאבים בתוך הגבולות.
  • שירותים לניהול הגדרות כמו Ansible, ‏ Chef או Puppet שנמצאים מחוץ לגבולות הגזרה, מנהלים את הפריסה וההגדרה של תוכנה במשאבים שנמצאים בתוך גבולות הגזרה.
  • שירותים של ניטור לצורכי אבטחה ואכיפה כמו Forseti או SIEM שנמצאים מחוץ לגבולות הגזרה צורכים נתונים או אוכפים את מדיניות האבטחה על משאב שנמצא בתוך גבולות הגזרה.

לכל תרחיש לדוגמה, צריך לתעד את הפרטים הבאים:

  • דפוס הגישה
  • הגורמים שיכולים להפעיל את תרחיש השימוש
  • התנאים שמפעילים את תרחיש השימוש
  • האם תרחיש השימוש הוא דפוס גישה תקין שצריך לאפשר אותו
  • הנחות שקשורות לתרחיש לדוגמה

דוגמה לדפוס גישה ולמעקב אחר תרחישי שימוש מופיעה בתבנית להצטרפות ל-VPC Service Controls – תרחישי שימוש (PDF).

עריכת ראיונות

עורכים ראיונות עם הצוותים שאחראים על עומסי העבודה כדי לדון בדפוסי הגישה ובתרחישי השימוש שנאספו מתבניות התקשורת הקודמות. הנה כמה דוגמאות לשאלות שאפשר לשאול במהלך הראיונות האלה:

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

  • האם תוכל לבצע באופן מקיף את כל תרחישי השימוש? הפעולה הזו מאפשרת להפעיל את כל התרחישים האפשריים של גבולות גזרה, כדי שתוכלו לנתח באופן מלא ולוודא שהאפליקציה תפעל בצורה תקינה אחרי שתאכפו את גבולות הגזרה.

  • כמה זמן נמשכת ההרצה של תרחיש השימוש?

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

הכנת הרצת בדיקה

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

כדי להכין את סביבת ההרצה היבשה:

  1. מזהים את כל הפרויקטים שעומדים בדרישות להכללה בגבולות גזרה, ומשלימים את התהליך של תרחיש שימוש וראיון עבור הפרויקטים האלה.
  2. יוצרים היקף יבש ומוסיפים את כל הפרויקטים.
  3. בגבול הגזרה לשירות של VPC Service Controls, בקטע שירותים מוגבלים > שירותים להגנה, מוסיפים את כל השירותים הנתמכים.

  4. יוצרים sink לרישום ביומן מצטבר ששולח את כל היומנים ל-BigQuery, או יוצרים sink לרישום ביומן לכל פרויקט ששולח את היומנים של הרצת הבדיקה למערך נתונים משותף ב-BigQuery. כדי לשלוח שאילתות לגבי הודעות היומן האלה ולזהות הפרות של VPC Service Controls, אפשר להשתמש בשאילתת SQL.

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

    logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"

  5. כדי להבטיח רמת אבטחה מקסימלית, צריך לחסום את הגישה לשירותים שלא נתמכים. מגדירים את גבולות הגזרה כך שרק שירותים מוגבלים יפעלו בתוך גבולות הגזרה. כדי לעשות את זה, מגדירים את רשימת השירותים הנגישים ל-RESTRICTED-SERVICES.

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

  7. מוודאים של אף אחד מה-VPC בפרויקטים אין נתיב יציאה לאינטרנט או ל-VIP הפרטי.

  8. מוודאים שכל רשתות ה-VPC מכוונות את ה-DNS של *.googleapis.com אל restricted.googleapis.com.

    בפרטי האזור, שם ה-DNS ‏ *.googleapis.com מוגבל ל-restricted.googleapis.com בשדה הנתונים

הפעלת תרחישים לדוגמה

בזמן שנקבע מראש, צוות האפליקציה יריץ את עומס העבודה בפרויקט בפרימטר של ההרצה היבשה. חשוב לוודא שיש כיסוי מלא של כל הקוד שעשוי לקרוא לממשקי Google API. בסיום ההרצה היבשה, צוות הבדיקה שייעדתם יכול לבצע ניתוח של יומן ההפרות.

ניתוח ההפרות

יומני הפרות של הרצה יבשה מכילים את רוב המידע שדרוש כדי לקבוע אם הפרה של אפליקציה מחייבת פעולה כלשהי, כמו הוספת זהויות או כתובות IP לרשימת ההיתרים של ההיקף. נתוני ההפרות מאוחסנים בטבלה cloudaudit_googleapis_com_policy ב-BigQuery. אלה הרכיבים העיקריים שצריך לנתח כדי להבין את ההפרה:

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

הדוגמה הבאה היא שאילתת BigQuery שמחזירה את כל פרטי ההפרה:

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
where JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') = "true" #ensure these are dry-run logs

שאילתה לגבי הפרות רלוונטיות

השיטות הבאות יכולות לעזור לכם לזהות את ההפרות הרלוונטיות:

  • מוסיפים מסנן חותמת זמן לחלון הזמן שבו כל אפליקציה ייחודית ביצעה את תרחיש השימוש שלה:

    WHERE receiveTimestamp >'2020-07-23 19:53:48.241317 UTC'

  • מוסיפים מסנן למוסכמת השמות של זהויות של עומסי עבודה או של פרויקטים:

    WHERE where resource.labels.project_id like '%APPLICATION_NAME%'

בדיקת יומני ההפרות

כשבודקים את יומני ההפרות, צריך לוודא שהתנאים הבאים מתקיימים:

  • האם הזהות (כתובת האימייל) אמורה להפעיל את ממשקי ה-API המוגנים?
  • האם צריך לאפשר למתקשר להפעיל את ה-API מחוץ לגבולות?

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

יכול להיות שלחלק מהרשומות יש כתובת IP של private. המשמעות היא שהשיחה הגיעה מרשת Google, דרך השירותים של Google או דרך VPC בפרויקט שנמצא מחוץ לגבולות גזרה. בשירותי Google כמו log sink writers, צריך להוסיף את חשבון השירות של Google לרשימת ההיתרים.

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

אם סוג ההפרה הוא SERVICE_NOT_ALLOWED_FROM_VPC, יכול להיות שעומס העבודה משתמש בשירות שנתמך על ידי VPC Service Controls, אבל לא נוסף לרשימת ממשקי ה-API המוגנים. לדוגמה, אם IAM גרם להפרה כזו, האדמין צריך להוסיף את IAM לרשימת השירותים הנגישים באמצעות הפעלת הפקודה הבאה ב-Google Cloud CLI:

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

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

המאמרים הבאים