במאמר הזה מתוארות הטמעות של רמות גישה ומומלצות דרכים להתחיל באכיפה של גבולות גזרה לשירות על סמך רשימות היתרים.
כשמבצעים הרצה יבשה של עומסי עבודה, מזוהה רשימה של כתובות IP וזהויות שצריך להוסיף לרשימת ההיתרים. יכול להיות שתגלו שחלק מעומסי העבודה צריכים רשימת היתרים שמבוססת על מכשירים. כדי להעניק גישה מבוקרת למשאבים מוגנים של Google Cloud , אתם יכולים להשתמש ברמות גישה של VPC Service Controls. אלה כמה דרכים מעשיות להטמיע רמות גישה: לפי כתובת IP, זהות או מכשיר.
מידע נוסף זמין במאמר בנושא בקרת גישה מבוססת-הקשר עם כללי כניסה.
הענקת גישה על סמך כתובת IP של המקור
אפשר להשתמש רק בטווחי CIDR של כתובות IP ציבוריות ברמות הגישה של רשימות היתרים מבוססות-IP. מכיוון שהשיטה הזו מאפשרת גישה לכל ממשקי ה-API המוגנים מטווח כתובות ה-IP הזה, הסביבה שמאחורי כתובות ה-IP האלה צריכה להיות מהימנה ומבוקרת. תרחיש שימוש טיפוסי ברשימת ההיתרים הזו הוא לאפשר גישה היקפית מרשתות מקומיות. בתרשים הבא אפשר לראות איך רשימת היתרים מבוססת-IP חוסמת גישה להיקף ומאפשרת גישה להיקף:
בתרשים שלמעלה, יש ניסיון של זהות תקפה לגשת לגבולות גזרה. ניסיונות הגישה נדחים כשהם מגיעים מכתובות IP באינטרנט. עם זאת, הגישה מותרת אם היא מגיעה מכתובות ה-IP הציבוריות של החברה.
וריאציה של התרחיש הזה היא כשמאפשרים גישה לגבולות גזרה ממשאבים פרטיים שנפרסו בפרויקט או בארגון אחר. בתרחיש השימוש הזה, נדרש שער Cloud NAT בפרויקט המקור.
ל-Cloud NAT יש שילוב עם גישה פרטית ל-Google, שמפעיל באופן אוטומטי גישה פרטית ל-Google ברשת המשנה של המשאב, ושומר על התנועה ל-Google APIs ולשירותים של Google כפנימית, במקום לנתב אותה לאינטרנט באמצעות כתובת ה-IP החיצונית של שער Cloud NAT.
כשתעבורת הנתונים מנותבת בתוך הרשת הפנימית של Google, השדה RequestMetadata.caller_ip של האובייקט AuditLog מצונזר ל-gce-internal-ip. כדי לאפשר גישה לגבולות גזרה במקרה הזה, צריך להגדיר כלל כניסה כדי לאפשר גישה על סמך מאפיינים אחרים, כמו הפרויקט או חשבון השירות, במקום להגדיר רמת גישה על סמך כתובת ה-IP של המקור החיצוני.
מתן גישה על סמך זהות המתקשר
כדי להטמיע רשימת היתרים שמבוססת על זהויות, מוסיפים לרשימת ההיתרים חשבונות שירות וסופר-אדמינים בארגון. ההיקף פתוח לזהויות האלה מכל כתובת IP, לכן צריך לוודא שהזהויות מוגנות היטב. צריך גם לוודא שלא נוצרים מפתחות לחשבונות שירות שהוספתם לרשימת ההיתרים. בדרך כלל לא מוסיפים זהויות משתמשים לרשימת ההיתרים (אי אפשר להוסיף קבוצות לרשימת ההיתרים) בגבול גזרה.
אפשר לגשת למשאבים בתוך גבולות הגזרה באמצעות מכונות וירטואליות בתוך גבולות הגזרה, מרשתות מקומיות מהימנות או ממכשירים מהימנים. מומלץ להשתמש ב-Cloud Workstations כדי לגשת למשאבים בתוך גבולות, כי VPC Service Controls לא תומך ב-Cloud Shell.
קביעת הזכאות לגישה על סמך מאפייני המכשיר של המתקשר
אמון במכשיר, שנקרא גם נקודת קצה מהימנה, מתבסס על כך שמשתמש ארגוני תקף מחובר לדפדפן Chrome או למכשיר Chromebook. האמון חל על סשן הכניסה למערכת ההפעלה. לדוגמה, משתמש Windows שמחובר ומריץ סשן של Chrome (לא צריך לפתוח את הדפדפן) יכול להפעיל בהצלחה פקודות ה-CLI של gcloud בממשקי API של היקף מאובטח. עם זאת, סשן אחר של משתמש Windows באותה מכונה לא יכול לקרוא לפקודות בממשקי ה-API של ההיקף המוגן.
התנאים הבאים לגבי מכשירים שימושיים כדי לקבוע את רמת האמון במכשיר:
Chrome OS מאומת הוא תנאי מאובטח מאוד שאומת באמצעות הצפנה, שמציין שמשתמש ארגוני תקף מחובר ל-Chromebook שהופעל בצורה מאובטחת. זהו תנאי מהימנות מומלץ ברמה 1.
נדרש אישור של אדמין כדי לאפשר גישה למכשיר מאפשרת לאדמינים של Cloud Identity לאשר כל מכשיר לפני שניתנת לו גישה. כברירת מחדל, מכשירים מאושרים אוטומטית אם משתמש ארגוני תקף מחובר אליהם. עם זאת, מומלץ להשבית את האפשרות לאישור אוטומטי.
ההגדרה Require corp owned device מסתמכת על סוכן Chrome שמחלץ את המספר הסידורי ממערכת ההפעלה, שמגיע בדרך כלל מה-BIOS. המספר הזה צריך להיות זהה למספרים סידוריים קיימים שהזנתם ב-Cloud Identity.
מכיוון שהמספר הסידורי לא מהימן במכשירים שאינם ChromeOS, משתמש עם הרשאות אדמין גבוהות יכול לזייף את המספר הסידורי. מומלץ להשתמש בתנאי הזה רק כבדיקה ברמה 2.
דוגמה לגיליון מעקב למתן גישה מבוקרת על סמך התנאים שמופיעים ברשימה הקודמת זמינה בתבנית להוספה לרשימת ההיתרים של VPC Service Controls (PDF).
הפעלת האכיפה
אחרי שמעצבים את רשימת ההיתרים ומעדכנים את רמות הגישה, מומלץ להריץ מחדש את עומסי העבודה כדי לוודא שאין הפרות. אם עומסי העבודה פועלים ללא הפרות, אפשר להפעיל את האכיפה של VPC Service Controls בלי להשפיע על האפליקציות.
כשמתכננים את האכיפה, חשוב לכלול את הפרטים הבאים:
- בוחרים תאריך לאכיפה ומודיעים על התאריך הזה לכל הצוותים הרלוונטיים.
- חשוב לוודא שצוותי התגובה לאירועי אבטחה וצוותי פעולות האבטחה מודעים לפריסה. בנוסף, חשוב לוודא שאנשים עם הרשאות מתאימות בודקים את היומנים ומאשרים רשימות נוספות של כתובות שאפשר לשלוח אליהן אימייל, אם צריך.
- מוודאים שצוות התגובה למצבים יוכל לפתוח בקשת תמיכה אם יעלו שאלות או בעיות. Google Cloud
- ליצור או לשנות את גבולות הגזרה ואת רמות הגישה באמצעות כלי אוטומציה כמו Terraform. אנחנו לא ממליצים לבצע את המשימות האלה באופן ידני.
כשמתחילים לאכוף את המדיניות, כדאי להתחיל בהעברת פרויקטים שמשויכים לעומס עבודה יחיד מגבולות גזרה לבדיקות לגבולות גזרה של הסביבה הפעילה. חשוב להקצות זמן להרצת האפליקציה בצורה תקינה בזמן שבודקים את יומני ההפרות. חוזרים על התהליך עבור כל עומסי העבודה שנותרו, אחד בכל פעם.
כדי להציג הפרות חסומות, מגדירים אובייקט נצבר מסוג sink לרישום ביומן ששולח יומני ביקורת מכל הפרויקטים בגבולות גזרה ל-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') is null #exclude logs from a dry-run perimeter
המאמרים הבאים
- איך מאפשרים גישה למשאבים מוגנים מחוץ לגבולות גזרה
- איך מציגים רשימה של גבולות גזרה לשירות, מעדכנים אותם ומוחקים אותם