פתרון בעיות שקשורות למדיניות ולגישה

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

Google Cloud אמצעי בקרה לאכיפת מדיניות הגישה

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

תוויות, תגים ותגים של רשת

‫Google Cloud מציע כמה דרכים לתיוג ולקיבוץ משאבים. אתם יכולים להשתמש בתוויות, בתגים ובתגי רשת כדי לאכוף את המדיניות.

תוויות הן צמדי מפתח/ערך שעוזרים לכם לארגן את המשאבים ב- Google Cloud . הרבה Google Cloud שירותים תומכים בתוויות. אפשר גם להשתמש בתוויות כדי לסנן ולקבץ משאבים לתרחישי שימוש אחרים, למשל, כדי לזהות את כל המשאבים שנמצאים בסביבת בדיקה לעומת משאבים שנמצאים בסביבת ייצור. בהקשר של אכיפת מדיניות, תוויות יכולות לציין את המיקום שבו המשאבים צריכים להיות. לדוגמה, מדיניות הגישה שאתם מחילים על משאבים עם התווית test שונה ממדיניות הגישה שאתם מחילים על משאבים עם התווית production resources.

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

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

כללי חומת אש ב-VPC

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

VPC Service Controls

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

מנהל המשאבים

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

ניהול זהויות והרשאות גישה

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

אחת התכונות של IAM היא תנאים ב-IAM. כשמטמיעים תנאים של IAM כחלק מהגדרת המדיניות, אפשר לתת זהויות (חשבונות משתמשים) גישה למשאבים רק אם התנאים שהוגדרו מתקיימים. לדוגמה, אפשר להשתמש בתנאים של IAM כדי להגביל את הגישה למשאבים רק לעובדים ששולחים בקשות מהמשרדים הפיזיים של החברה.

Organization Policy Service

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

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

מכסות

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

  • מכסה לקצב שליחת בקשות, כמו בקשות API ליום. המכסה הזו מתאפסת אחרי פרק זמן מסוים, כמו דקה או יום.
  • מכסת הקצאה, כמו מספר המכונות הווירטואליות או מאזני העומסים שבהם נעשה שימוש בפרויקט. המכסה הזו לא מתאפסת עם הזמן. צריך לשחרר מכסת הקצאה במפורש כשלא רוצים יותר להשתמש במשאב – לדוגמה, על ידי מחיקת אשכול Google Kubernetes Engine ‏ (GKE).

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

Chrome Enterprise Premium

‫Chrome Enterprise Premium משתמש במוצרים שונים של Google Cloud Google כדי לאכוף בקרת גישה מפורטת על סמך זהות המשתמש וההקשר של הבקשה. אפשר להגדיר את Chrome Enterprise Premium כך שהגישה למסוף Google Cloud ולממשקי ה-API Google Cloud תהיה מוגבלת.

הגנה על הגישה ב-Chrome Enterprise Premium פועלת באמצעות השירותים הבאים: Google Cloud

  • שרת proxy לאימות זהויות (IAP): שירות שמאמת את זהות המשתמש ומשתמש בהקשר כדי לקבוע אם צריך לאפשר למשתמש גישה למשאב.
  • ‫IAM: שירות ניהול הזהויות וההרשאות של Google Cloud.
  • ‫Access Context Manager: מנוע כללים שמאפשר בקרת גישה פרטנית.
  • ‫Endpoint Verification: תוסף ל-Google Chrome שאוסף פרטים על מכשיר המשתמש.

שירות המלצות IAM

‫IAM כולל כלים של Policy Intelligence שמספקים לכם קבוצה מקיפה של הנחיות פרואקטיביות שיעזרו לכם להיות יעילים ומאובטחים יותר כשאתם משתמשים ב- Google Cloud. ההמלצות לפעולות מוצגות לכם באמצעות התראות במסוף, ואתם יכולים להחיל אותן ישירות או באמצעות אירוע שנשלח לנושא Pub/Sub.

IAM Recommender הוא חלק מחבילת כלים לבקרת מדיניות, ואפשר להשתמש בו כדי להחיל את העיקרון של הרשאות מינימליות. שירות ההמלצות משווה בין ההרשאות שניתנו ברמת הפרויקט לבין ההרשאות שכל חשבון משתמש השתמש בהן ב-90 הימים האחרונים. אם מקצים לחשבון משתמש תפקיד ברמת הפרויקט, והחשבון לא משתמש בכל ההרשאות של התפקיד, יכול להיות ששירות Recommender ימליץ לבטל את התפקיד. במקרה הצורך, הכלי להמלצות גם ממליץ על תפקידים עם פחות הרשאות כתחליף.

אם אתם מחילים המלצה באופן אוטומטי, יכול להיות שבלי כוונה תגרמו לכך שתימנע גישה של משתמש או חשבון שירות למשאב. אם מחליטים להשתמש בפעולות אוטומטיות, מומלץ להיעזר בשיטות המומלצות של שירות ההמלצות (Recommender) של IAM כדי להחליט מה רמת האוטומציה שנוחה לכם.

מרחבי שמות ו-RBAC ב-Kubernetes

‫Kubernetes מופעל כשירות מנוהל ב-Google Kubernetes Engine‏ (GKE). Google Cloud ‫GKE יכול לאכוף מדיניות שמתאימה לכל מקום שבו אשכול GKE פועל. כללי המדיניות שמשפיעים על הגישה למשאבים הם שילוב של אמצעי בקרה מובנים של Kubernetes ושל אמצעי בקרה ספציפיים. Google Cloud

בנוסף לחומות אש של VPC ול-VPC Service Controls,‏ GKE משתמש במרחבי שמות, בבקרת גישה מבוססת-תפקידים (RBAC) ובזהויות של עומסי עבודה כדי לנהל מדיניות שמשפיעה על הגישה למשאבים.

מרחבי שמות

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

RBAC

ב-RBAC נכללות התכונות הבאות:

  • שליטה פרטנית באופי הגישה של המשתמשים למשאבי ה-API שפועלים באשכול.
    • מאפשרת ליצור מדיניות מפורטת שמגדירה אילו פעולות ומשאבים המשתמשים וחשבונות השירות יכולים לגשת אליהם.
    • יכולים לשלוט בגישה לחשבונות Google, Google Cloudלחשבונות שירות ולחשבונות שירות של Kubernetes.
  • מאפשר ליצור הרשאות RBAC שחלות על כל האשכול או על מרחבי שמות ספציפיים באשכול.
    • הרשאות ברמת האשכול שימושיות להגבלת הגישה למשאבי API ספציפיים למשתמשים מסוימים. מקורות המידע של ה-API כוללים מדיניות אבטחה וסודות.
    • הרשאות ספציפיות למרחב שמות שימושיות אם, לדוגמה, יש לכם כמה קבוצות של משתמשים שפועלות במרחבי שמות משלהן. השימוש ב-RBAC יכול לעזור לכם לוודא שלמשתמשים תהיה גישה רק למשאבי אשכול במרחב השמות שלהם.
  • תפקיד שאפשר להשתמש בו רק כדי להעניק גישה למשאבים במרחב שמות יחיד.
  • תפקיד שמכיל כללים שמייצגים קבוצה של הרשאות. ההרשאות הן מצטברות בלבד, ואין כללי דחייה.

מערכות IAM ו-Kubernetes RBAC משולבות כך שמשתמשים מקבלים הרשאה לבצע פעולות אם יש להם הרשאות מספיקות לפי אחת מהמערכות.

באיור 1 מוצג אופן השימוש ב-IAM עם RBAC ובמרחבי שמות להטמעה של מדיניות.

ניהול זהויות והרשאות גישה (IAM) ו-RBAC ב-Google Kubernetes Engine פועלים יחד כדי לשלוט בגישה לאשכול GKE (לחיצה להגדלה).

באיור 1 מוצגות ההטמעות הבאות של המדיניות:

  1. ברמת הפרויקט, IAM מגדיר תפקידים לאדמינים של אשכולות כדי לנהל אשכולות ולאפשר למפתחי קונטיינרים לגשת לממשקי API באשכולות.
  2. ברמת האשכול, RBAC מגדיר הרשאות באשכולות ספציפיים.
  3. ברמת מרחב השמות, RBAC מגדיר הרשאות במרחבי שמות.

Workload Identity

בנוסף ל-RBAC ול-IAM, צריך להבין גם את ההשפעה של זהויות עומסי עבודה. באמצעות Workload Identity אפשר להגדיר חשבון שירות של Kubernetes כך שיפעל כחשבון שירות של Google. כל אפליקציה שפועלת כחשבון שירות של Kubernetes מבצעת אימות אוטומטי כחשבון שירות של Google כשניגשים ל-APIs של Google Cloud. האימות הזה מאפשר להקצות זהות והרשאות פרטניות לאפליקציות באשכול.

איחוד זהויות של עומסי עבודה ל-GKE מסתמך על הרשאות IAM כדי לקבוע לאילו ממשקי API האפליקציה שלכם ב-GKE יכולה לגשת.Google Cloud לדוגמה, אם ההרשאות ב-IAM משתנות, יכול להיות שאפליקציית GKE לא תוכל לכתוב ל-Cloud Storage.

כלים לפתרון בעיות

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

יומנים

כשמתרחשת בעיה, בדרך כלל המקום הראשון שבו כדאי להתחיל לפתור אותה הוא עיון ביומנים. Google Cloud היומנים שמספקים תובנות לגבי בעיות שקשורות לגישה הם Cloud Audit Logs, ניהול כללי חומת אש ו-VPC Flow Logs.

יומני ביקורת של Cloud

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

  • יומני Admin Activity מכילים רשומות ביומן עבור קריאות ל-API או פעולות ניהול אחרות שמשנות את ההגדרות או את המטא-נתונים של משאבים. יומני Admin Activity תמיד מופעלים. למידע על התמחור והמכסות של יומני Admin Activity, אפשר לעיין בסקירה הכללית על יומני הביקורת של Cloud.
  • יומני גישה לנתונים מתעדים קריאות ל-API שיוצרות, משנות וקוראות פרטים שהמשתמשים סיפקו (UPD). יומני הביקורת Data Access מושבתים כברירת מחדל, למעט ב-BigQuery. יומני הגישה לנתונים יכולים לגדול מאוד, ועלולים להיות כרוכים בעלויות. מידע על מכסות השימוש ביומני גישה לנתונים זמין במאמר מכסות ומגבלות. מידע על העלויות האפשריות מופיע במאמר בנושא תמחור.
  • יומני System Event מכילים רשומות ביומן לגבי מקרים שבהם Compute Engine מבצע אירוע מערכת. לדוגמה, כל מיגרציה פעילה מתועדת כאירוע מערכת. מידע על תמחור ומכסות של יומני System Event מופיע במאמר סקירה כללית על יומני הביקורת של Cloud.

ב-Cloud Logging, השדה protoPayload מכיל אובייקט מסוג AuditLog שבו מאוחסנים נתוני יומני הביקורת. דוגמה לרשומה ביומן הביקורת מופיעה במאמר דוגמה לרשומה ביומן הביקורת.

כדי לצפות ביומני הביקורת Admin Activity, צריך להיות לכם תפקיד Logs Viewer ‏ (roles/logging.viewer) או תפקיד Viewer בסיסי (roles/viewer). מומלץ לבחור את התפקיד עם ההרשאות המינימליות שנדרשות להשלמת המשימה.

הרשומות ביומן הביקורת נשמרות למשך פרק זמן ספציפי. כדי לשמור את הרשומות ביומן לפרק זמן ארוך יותר, אפשר לייצא אותן ל-Cloud Storage, ל-BigQuery או ל-Pub/Sub. כדי לייצא רשומות ביומן מכל הפרויקטים, התיקיות והחשבונות לחיוב בארגון, אפשר להשתמש בייצוא מצטבר. ייצוא מצטבר מאפשר לכם לבדוק יומנים מכל הארגון במקום אחד.

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

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

ניהול כללי חומת אש

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

מפעילים את הרישום ביומן של כללי חומת האש בנפרד לכל כלל של חומת האש שרוצים לרשום ביומן את החיבורים שלו. אפשר להשתמש באפשרות 'רישום ביומן של כללי חומת אש' לכל כלל של חומת אש, ללא קשר לפעולה (אישור או דחייה) או לכיוון (תעבורת נתונים נכנסת או יוצאת) של הכלל. ניהול כללי חומת אש יכול ליצור כמות גדולה של נתונים. יש חיוב על ניהול כללי חומת אש, לכן חשוב לתכנן בקפידה אילו חיבורים רוצים לרשום ביומן.

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

תובנות לגבי חומת האש

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

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

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

VPC Flow Logs

VPC Flow Logs מתעד מדגם של זרימות נתונים ברשת שנשלחות ממכונות וירטואליות ומתקבלות בהן. VPC Flow Logs כולל נתונים על תנועת גולשים שמשפיעה על מכונה וירטואלית. כל התעבורה היוצאת (egress) מתועדת ביומן, גם אם כלל חומת אש שחוסם תעבורה יוצאת חוסם את התעבורה. תעבורת נתונים נכנסת (ingress) נרשמת ביומן אם כלל חומת אש שמאפשר תעבורת נתונים נכנסת מתיר את התעבורה. תנועת נכנסת לא נרשמת ביומן אם כלל חומת אש של דחיית תנועה נכנסת חוסם את התנועה.

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

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

שליחת התראות

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

התראות בזמן אמת

מאגר משאבי ענן (CAI) שומר היסטוריה של חמישה שבועות של מטא-נתונים של נכסים. Google Cloudנכס הוא משאב נתמך Google Cloud . המשאבים הנתמכים כוללים IAM, ‏ Compute Engine עם תכונות רשת משויכות כמו כללי חומת אש ומרחבי שמות של GKE, וכן תפקידים וקשרי תפקידים באשכולות. כל המשאבים שלמעלה משפיעים על הגישה למשאבי Google Cloud .

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

יומני ביקורת של Cloud ופונקציות Cloud Run

כדי להשלים את השימוש בהתראות בזמן אמת, אפשר לעקוב אחרי Cloud Logging ולהגדיר התראות על קריאות לפעולות רגישות. לדוגמה, אפשר ליצור יעד ב-Cloud Logging שמסנן קריאות אל SetIamPolicy ברמת הארגון. ה-sink שולח יומנים לנושא Pub/Sub שאפשר להשתמש בו כדי להפעיל פונקציית Cloud Run.

בדיקות קישוריות

כדי לבדוק אם בעיית הגישה קשורה לרשת או להרשאות, אפשר להשתמש בכלי בדיקות קישוריות של Network Intelligence Center. בדיקות הקישוריות הן כלי סטטי לניתוח הגדרות ולאבחון, שמאפשר לבדוק את הקישוריות בין נקודת קצה של מקור לבין נקודת קצה של יעד. הכלי 'בדיקות קישוריות' עוזר לכם לזהות את שורש הבעיה בבעיות גישה שקשורות לרשת ואסוציאטיביות לGoogle Cloud הגדרת הרשת שלכם.

הכלי 'בדיקות קישוריות' מבצע בדיקות שכוללות את רשת ה-VPC, קישור בין רשתות שכנות (peering) של VPC ומנהרות VPN לרשת המקומית. לדוגמה, בדיקות הקישוריות עשויות לזהות שכלל חומת אש חוסם את הקישוריות. מידע נוסף מופיע במאמר תרחישים נפוצים לדוגמה.

פותר הבעיות שקשורות למדיניות

הרבה משימות ב- Google Cloud דורשות תפקיד ב-IAM והרשאות שמשויכות אליו. מומלץ לבדוק אילו הרשאות כלולות בתפקיד, ולבדוק כל הרשאה שנדרשת להשלמת משימה. לדוגמה, כדי להשתמש בתמונות של Compute Engine כדי ליצור מכונה, משתמש צריך את התפקיד compute.imageUser, שכולל תשע הרשאות. לכן, למשתמש צריך להיות שילוב של תפקידים והרשאות שכולל את כל תשע ההרשאות.

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

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

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

  • חשבון ראשי (משתמש יחיד, חשבון שירות או קבוצות)
  • הרשאה (שימו לב שאלה הרשאות הבסיס, ולא תפקידי ה-IAM)
  • משאב

שירות המלצות IAM

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

העברת פנייה לטיפול ברמה גבוהה יותר בשירות Customer Care

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

אם לא הצלחתם לפתור בעיה באמצעות הכלים שמתוארים במסמך הזה, תהליך תמיכה מוגדר היטב יעזור לצוות שירות הלקוחות לפתור את הבעיות שלכם. מומלץ להשתמש בגישה שיטתית לפתרון בעיות, כמו שמתואר בפרק פתרון בעיות יעיל בספר Site Reliability Engineering (SRE) של Google.

מומלץ שתהליך התמיכה הפנימי יכלול את הפעולות הבאות:

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

אם אתם צריכים להעביר את הבעיה לטיפול של Customer Care, תצטרכו לספק את הפרטים הבאים כדי ש-Customer Care יוכל לפתור את בעיות הגישה:

  • הזהות (כתובת האימייל של המשתמש או חשבון השירות) שמבקשת גישה.
    • האם הבעיה משפיעה על כל הזהויות או רק על חלקן.
    • אם רק חלק מהזהויות מושפעות, צריך לספק דוגמה של זהות שפועלת ודוגמה של זהות שלא פועלת.
  • אם הזהות נוצרה מחדש לאחרונה.
  • המשאב שהמשתמש מנסה לגשת אליו (כולל מזהה הפרויקט).
  • הבקשה או השיטה שמתבצעת אליה קריאה.
    • צריך לספק עותק של הבקשה והתשובה.
  • ההרשאות שניתנו לישות לצורך הגישה הזו.
    • צריך לספק עותק של מדיניות IAM.
  • המקור (המיקום) שממנו הזהות מנסה לגשת למשאבים. לדוגמה, אם הם מנסים לגשת מGoogle Cloud משאב (כמו מכונה של Compute Engine), מGoogle Cloud המסוף, מ-Google Cloud CLI, מ-Cloud Shell או ממקור חיצוני כמו מקור מקומי או אינטרנט.
    • אם המקור הוא מפרויקט אחר, צריך לציין את מזהה פרויקט המקור.
  • השעה (חותמת הזמן) שבה השגיאה התרחשה לראשונה, והאם היא עדיין מתרחשת.
  • הזמן האחרון הידוע שבו הזהות ניגשה למשאב בהצלחה (כולל חותמות זמן).
  • כל השינויים שבוצעו לפני שהבעיה התחילה (כולל חותמות זמן).
  • כל השגיאות שמתועדות ב-Cloud Logging. לפני שמשתפים עם שירות לקוחות, חשוב לצנזר נתונים רגישים כמו טוקני גישה, פרטי כניסה ומספרי כרטיסי אשראי.

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

לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.