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

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

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

  • השירות המוגן וה-method של ה-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 כמו sink ביומן בעלי הרשאת כתיבה, צריך להוסיף את חשבון השירות של 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

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

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