פתרון בעיות של דחיות גישה באמצעות הצעות לתיקון

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

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

הסבר על הצעות לתיקון

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

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

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

לפני שמתחילים

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות בשביל להציג ולהחיל הצעות לתיקון, אתם צריכים לבקש מהאדמין לתת לכם את התפקידים הבאים ב-IAM:

  • אבחון אירוע של דחיית גישה והצגת הצעות לתיקון: Access Context Manager Reader (roles/accesscontextmanager.policyReader) במדיניות הגישה
  • אחזור אסימונים לפתרון בעיות מיומני הביקורת של Cloud:‏ Logs Viewer (roles/logging.viewer) בפרויקטים שמכילים יומני ביקורת של VPC Service Controls
  • החלת הצעות לתיקון ועדכון של גבולות גזרה לשירות: עורך Access Context Manager (roles/accesscontextmanager.editor) במדיניות הגישה

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

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

ההרשאות הנדרשות

כדי לראות את ההצעות לתיקון וליישם אותן, נדרשות ההרשאות הבאות:

  • כדי לאבחן אירוע של דחיית גישה ולראות הצעות לתיקון:
    • accesscontextmanager.accessLevels.list במדיניות הגישה שלכם
    • accesscontextmanager.policies.get במדיניות הגישה
    • accesscontextmanager.servicePerimeters.list במדיניות הגישה שלכם
  • אחזור אסימוני פתרון בעיות מיומני הביקורת של Cloud: logging.logEntries.list בפרויקטים שמכילים יומני ביקורת של VPC Service Controls
  • מיישמים את ההצעות לתיקון ומעדכנים את הגדרות ההיקפים של השירות:
    • accesscontextmanager.accessLevels.create במדיניות הגישה שלכם
    • accesscontextmanager.accessLevels.get במדיניות הגישה שלכם
    • accesscontextmanager.accessLevels.list במדיניות הגישה
    • accesscontextmanager.policies.get במדיניות הגישה
    • accesscontextmanager.servicePerimeters.get במדיניות הגישה שלכם
    • accesscontextmanager.servicePerimeters.update במדיניות הגישה

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

צפייה בהצעות לתיקון ויישום שלהן

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

  1. נכנסים לדף VPC Service Controls במסוף Google Cloud .

    מעבר אל VPC Service Controls

    אם מתבקשים, בוחרים את הארגון.

  2. בדף VPC Service Controls (אמצעי בקרה לשירותי VPC), לוחצים על Violation analyzer (כלי לניתוח הפרות).

  3. בשדה Troubleshooting token (or unique ID) (אסימון לפתרון בעיות או מזהה ייחודי), מזינים את האסימון לפתרון בעיות או את המזהה הייחודי של דחיית הגישה.

  4. לוחצים על Continue.

  5. בדף התוצאות של פתרון הבעיות, בקטע Protected resources accessed, בוחרים את ההיקף שחסם את הגישה.

  6. לוחצים על בדיקת ההמלצה. נפתחת החלונית פרטי התיקון.

  7. בודקים את פעולות התיקון המוצעות:

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

  8. כדי להחיל את השינויים המוצעים, לוחצים על החלת התיקון.

‫VPC Service Controls מקצה באופן אוטומטי את רמת הגישה החדשה (אם בחרתם ליצור אחת) ומעדכן את הגדרת גבולות הגזרה לשירות.

פעולות לתיקון לפי סוג ההפרה

בטבלה הבאה מתוארות הפעולות שמנוע התיקון מציע על סמך סוג ההפרה:

סוג ההפרה הצעה לפעולת תיקון
הפרה של Ingress
  • מאפשרת לבחור רמת גישה קיימת שתואמת להקשר של הבקשה (מומלץ), או להקצות רמת גישה חדשה מבוססת-הקשר שתואמת לרשתות המשנה של כתובות ה-IP של המתקשר, לאזורים הגיאוגרפיים או למדיניות המכשיר.
  • מוסיפה כלל לתעבורת נתונים נכנסת בהיקף הזהות של מבצע הקריאה, רמת הגישה או הרשת של המקור, שירות היעד, בוררי השיטה והמשאב.
הפרה של תעבורת נתונים יוצאת (egress) מוסיף כלל לתעבורת נתונים יוצאת בהיקף של זהות המקור או הפרויקט, שירות היעד, בוררי השיטה והמשאב החיצוני.
שירותים שנגישים ל-VPC הוספת השירות המוגבל לרשימת ההיתרים של השירותים שניתן לגשת אליהם ב-VPC של המערך, או הצעה לעדכן את ההגבלות אם השירות לא נתמך.

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

נניח שאנליסט (analyst@example.com) מנסה לקרוא אובייקט מקטגוריה של Cloud Storage בפרויקט 803311519563 מתחנת עבודה חיצונית (198.51.100.42), אבל הגישה נדחית.

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

פעולה 1: בוחרים רמת גישה קיימת או יוצרים רמת גישה עם היקף

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

  • בחירה של רמת גישה קיימת (מומלץ): בכרטיסייה רמת גישה קיימת, בוחרים רמת גישה קיימת שכבר תואמת להקשר של הבקשה (לדוגמה, corp_trusted_workstations). מומלץ לעשות שימוש חוזר ברמת גישה קיימת כדי להימנע מיצירה של רמות גישה כפולות וכדי לפשט את ניהול המדיניות.
  • יצירה של רמת גישה חדשה: לחלופין, בכרטיסייה רמת גישה חדשה, אפשר לאפשר למנוע ליצור רמת גישה חדשה בהיקף תחנת העבודה של המתקשר:
    • Name (שם): accessPolicies/POLICY_ID/accessLevels/analyst_secure_workstation
    • תת-רשתות של כתובות IP: 198.51.100.0/24
    • אזורים: US
    • מדיניות מכשירים: נדרשת שיטה לפתיחת הנעילה, הצפנת דיסק, סטטוס של מכשיר בבעלות החברה ואישור אדמין.

פעולה 2: הוספה של כלל כניסה בהיקף לגבולות הגזרה

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

  • זהויות: user:analyst@example.com
  • מקורות: רמת הגישה הקיימת שבחרתם (לדוגמה, corp_trusted_workstations) או רמת הגישה החדשה analyst_secure_workstation
  • שירות: storage.googleapis.com
  • Method selectors: google.storage.objects.get
  • מקורות מידע: projects/803311519563

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

מגבלות

  • השמטת נתונים רגישים:
    • אי אפשר להשתמש בכתובות IP פנימיות שהוסרו מהן פרטים מזהים כדי ליצור רמות גישה ספציפיות.
    • אם הזהויות של המתקשרים מצונזרות או לא זמינות ביומני ביקורת, יכול להיות שההצעות ישתמשו בזהויות גנריות כמו ANY_USER_ACCOUNT.
    • אם אין תמיכה בשיטות שירות ברמת פירוט גבוהה, יכול להיות שההצעות יכללו תבנית wildcard ‏ (*).
    • אם אי אפשר לגשת לשמות הרשתות, ההצעות יתבססו על מספרי הפרויקטים.
  • ההצעות לתיקון דורשות פרטים על דחיית הגישה מיומני הביקורת של Cloud. אי אפשר לנתח אירועים שהתרחשו לפני תקופת שמירת היומנים (30 ימים כברירת מחדל).
  • ההצעות לתיקון זמינות רק ברמת הארגון בGoogle Cloud מסוף.
  • מנוע התיקון לא תומך בדפוסי שירות ובחלק מההגדרות של מאגרי זהויות של כוח העבודה של צד שלישי.

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