סקירה כללית של מדיניות ההרשאות

מדיניות הרשאות מאפשרת לכם לבצע בדיקות של בקרת גישה וגם בדיקות של ניקוי תוכן כשמעבדים בקשות או תגובות באמצעות שירותים שונים שלGoogle Cloud , כמו איזון עומסים של אפליקציות, Agent Gateway ו-Secure Web Proxy.

ב-Agent Gateway וב-Secure Web Proxy, מדיניות ההרשאות מצורפת ישירות למשאב השער של השירותים האלה. במאזן עומסים, מדיניות ההרשאות מצורפת למשאב של כלל ההעברה של מאזן העומסים.

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

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

  • מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)
  • מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
  • מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
  • מאזני עומסים פנימיים של אפליקציות (ALB) שפועלים בכמה אזורים

כללים של מדיניות ההרשאות

מדיניות הרשאות מורכבת מרשימה של כללי HTTP שמתאימים לבקשה הנכנסת.

במדיניות הרשאות עם פעולה מסוג ALLOW או DENY, כלל HTTP ‏(AuthzRule) מגדיר את התנאים שקובעים אם התעבורה יכולה לעבור דרך מאזן העומסים. צריך להזין לפחות כלל HTTP אחד.

במדיניות הרשאה עם פעולת CUSTOM, כלל HTTP ‏ (AuthzRule) מגדיר את התנאים שקובעים אם התנועה מוקצית לספק המותאם אישית לצורך הרשאה. ספק מותאם אישית הוא חובה, אבל כללי HTTP הם אופציונליים.

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

כלל HTTP במדיניות הרשאות מורכב מהשדות הבאים:

  • ‫from: מציין את הזהות של הלקוח שמורשה על ידי הכלל. אפשר לגזור את הזהות מאישור לקוח בחיבור TLS בו-זמני, או שהיא יכולה להיות הזהות הסביבתית שמשויכת למופע של מכונה וירטואלית (VM) של הלקוח, למשל מחשבון שירות או מתג מאובטח.
  • ‫to: מציין את הפעולות שמותרות לפי הכלל, כמו כתובות ה-URL שאפשר לגשת אליהן או שיטות ה-HTTP שמותרות.
  • ‫when: מציין אילוצים נוספים שצריך לעמוד בהם. אפשר להשתמש בביטויים של Common Expression Language ‏(CEL) כדי להגדיר את האילוצים.

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

כשמעריכים בקשה, מדיניות הרשאות מציינת את הפעולה (AuthzAction) שצריך להחיל על הבקשה. במדיניות הרשאות צריך להיות לפחות פעולה אחת, שיכולה להיות אחת מהפעולות הבאות:

  • ‫ALLOW: מאפשרת לבקשה לעבור אל ה-Backend אם הבקשה תואמת לאחד מהכללים שצוינו במדיניות ALLOW. אם קיימות מדיניות ALLOW, אבל אין התאמה, הבקשה נדחית. במילים אחרות, הבקשה נדחית אם אף אחת ממדיניות ההרשאות שהוגדרה עם פעולת ALLOW לא תואמת לבקשה. ב-Cloud Logging, הפעולה הזו נרשמת כ-denied_as_no_allow_policies_matched_request.

    כדי להחיל פעולה מסוג ALLOW, צריך לפחות כלל HTTP אחד.

  • ‫DENY: דחיית הבקשה אם היא תואמת לאחד מהכללים שצוינו במדיניות DENY. אם קיימות מדיניות DENY, אבל אין התאמה, הבקשה תאושר. במילים אחרות, הבקשה מותרת אם אף אחת ממדיניות ההרשאות שהוגדרה עם פעולה DENY לא תואמת לבקשה. ב-Cloud Logging, הפעולה הזו נרשמת כ-allowed_as_no_deny_policies_matched_request.

    כדי להחיל פעולה מסוג DENY, צריך לפחות כלל HTTP אחד.

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

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

סדר ההערכה של מדיניות ההרשאות

מדיניות ההרשאות תומכת במדיניות CUSTOM, DENY ו-ALLOW לבקרת גישה. אם כמה כללי מדיניות הרשאה משויכים למשאב אחד, המערכת בודקת קודם את כלל המדיניות CUSTOM, אחר כך את כלל המדיניות DENY ולבסוף את כלל המדיניות ALLOW. ההערכה נקבעת לפי הכללים הבאים:

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

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

  3. אם לא קיימות מדיניות ALLOW, הבקשה מאושרת.

  4. אם אחת ממדיניות ALLOW תואמת לבקשה, מאשרים את הבקשה.

  5. אם קיימות מדיניות ALLOW, אבל אין התאמה, הבקשה נדחית. במילים אחרות, הבקשה נדחית כברירת מחדל אם אף אחת מההגדרות של AuthzPolicies עם הפעולה ALLOW לא תואמת לבקשה.

במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), במאזני עומסים פנימיים אזוריים של אפליקציות, ב-Agent Gateway וב-Secure Web Proxy –Google Cloud שירותים שתומכים בפרופילים של מדיניות – סדר ההערכה של מדיניות ההרשאה הוא כדלקמן:

  1. אם יש מדיניות מותאמת אישית של הרשאת בקשה (REQUEST_AUTHZ) שתואמת לבקשה, המדיניות REQUEST_AUTHZ מוערכת באמצעות ספק הרשאות מותאם אישית. אם ספק הזהויות המותאם אישית דוחה את הבקשה, היא נדחית. המדיניות DENY, ALLOW ו-CONTENT_AUTHZ לא מוערכת, גם אם אחת מהן מוגדרת.

  2. אם יש DENY מדיניות שתואמת לבקשה, הבקשה נדחית. המערכת לא תבדוק את כללי המדיניות ALLOW ו-CONTENT_AUTHZ, גם אם הם מוגדרים.

  3. אם לא קיימות מדיניות ALLOW, הבקשה עוברת להערכה של הרשאת גישה לתוכן (CONTENT_AUTHZ).

  4. אם אחת ממדיניות ALLOW תואמת לבקשה, הבקשה עוברת לCONTENT_AUTHZ הערכה.

  5. אם קיימות מדיניות ALLOW, אבל אין התאמה, הבקשה נדחית. המערכת לא מעריכה את כללי המדיניות CONTENT_AUTHZ.

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

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

פרופילי מדיניות במדיניות הרשאות נתמכים בשירותים הבאים של Google Cloud Google Cloud:

  • מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
  • מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
  • Agent Gateway
  • Secure Web Proxy

פרופיל מדיניות (PolicyProfile) במדיניות הרשאות הוא אחד מהסוגים הבאים:

  • בקשת פרופיל הרשאה (REQUEST_AUTHZ): מסתמכת על מידע בכותרות של בקשות HTTP כדי לאשר או לדחות תנועה.
  • פרופיל הרשאת תוכן (CONTENT_AUTHZ): מספק אבטחה וסינון מבוססי-תוכן כדי לחסום מתקפות של החדרת הנחיות, למנוע דליפות של נתונים רגישים ולסנן תוכן מזיק.

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

בקשת פרופיל הרשאה

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

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

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

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

פרופיל הרשאת תוכן

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

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

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

הקצאת החלטות בנוגע להרשאות

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

  • שירות שמנוהל על ידי Google
    • הגנה מוגברת על המודל
    • שרת proxy לאימות זהויות (IAP)
  • שירות שמנוהל על ידי המשתמש
    • שירות לקצה העורפי Google Cloud
    • שירות שאפשר לגשת אליו באמצעות שם דומיין שמוגדר במלואו (FQDN) שתומך בפרוטוקול ext_proc או ext_authz של Envoy

בטבלה הבאה מפורטים השירותים השונים שאפשר להעביר אליהם החלטות הרשאה באמצעות Service Extensions.

מדיניות הרשאות הערכה ישירה הועבר ל-Service Extensions (תוסף הרשאה)
שירותים מנוהלים של Google שירותים בניהול המשתמשים
הגנה מוגברת על המודל שרת proxy לאימות זהויות (IAP) Google Cloud שירות לקצה העורפי שירות שמבוסס על FQDN
פרופיל REQUEST_AUTHZ
פרופיל CONTENT_AUTHZ

Service Extensions

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

באמצעות רכיבי Callout של Service Extensions, אתם מנחים את מאזן העומסים להעביר תעבורת נתונים מתוך נתיב עיבוד הנתונים של איזון העומסים באמצעות קריאות gRPC, לשירות Callout, שיכול להיות בניהול המשתמש או בניהול Google. בטבלה הקודמת מוגדרים שירותי ההדגשה השונים. שירותי ה-callout האלה מריצים את תוסף ההרשאה ויכולים להחיל מדיניות או פונקציות שונות לפני שהתנועה מוחזרת למאזן העומסים לעיבוד נוסף. בתרשים הבא מוצג התהליך.

מדיניות הרשאות יכולה להעביר את ההחלטות בנוגע להרשאות ל-Service Extensions, במיוחד לתוספי הרשאות.
מדיניות הרשאות שמקצה החלטת הרשאה באמצעות תוסף הרשאות (לחצו כדי להגדיל).

כדי להעביר את ההחלטות לגבי הרשאות לתוסף הרשאות, צריך ליצור תוסף הרשאות (AuthzExtension) שפועל בשירות callout. לאחר מכן, אפשר ליצור מדיניות הרשאות עם פעולת CUSTOM ולהפנות אותה לתוסף ההרשאות שיצרתם. אפשר להשתמש בתוסף ההרשאות כדי לבצע הרשאה ברמת הבקשה (REQUEST_AUTHZ) וניקוי תוכן (CONTENT_AUTHZ).

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

הרחבות של הרשאות בנתיב עיבוד הנתונים

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

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

  • כשמדיניות הרשאה עם פרופיל מדיניות CONTENT_AUTHZ מצביעה על תוסף הרשאה (AuthzExtension), תוסף ההרשאה נקרא תוסף הרשאה לתוכן.

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

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

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

הגנה מוגברת על המודל

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

כדי לעשות את זה, אפשר ליצור תוסף הרשאה (AuthzExtension) שפועל בשירות הגנה מוגברת על המודל. לאחר מכן, תוכלו ליצור מדיניות הרשאה עם פעולת CUSTOM ופרופיל CUSTOM שמפנה לתוסף ההרשאה שיצרתם.CONTENT_AUTHZ

מידע נוסף על העברת סמכויות הרשאה ל-Model Armor

שרת proxy לאימות זהויות (IAP)

אפשר להעביר את ההחלטות בנוגע להרשאות לשרת proxy לאימות זהויות (IAP). IAP מאמת את זהות המשתמש ואת ההקשר של הבקשה כדי לקבוע אם צריך לאפשר למשתמש לגשת לאפליקציה או למשאב.

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

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

מידע נוסף על שימוש ב-IAP כשירות הרשאות זמין במאמר העברת החלטת ההרשאה לשרת proxy לאימות זהויות (IAP).

מדיניות הרשאות שמבוססת על חשבונות משתמשים

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

  • שמות חלופיים של נושאים (SAN) של URI של אישור לקוח (CLIENT_CERT_URI_SAN)
  • שמות DNS של אישורי לקוח ב-SAN (CLIENT_CERT_DNS_NAME_SAN)
  • השם הנפוץ של אישור הלקוח (CLIENT_CERT_COMMON_NAME)

אם לא מציינים בורר ראשי לזיהוי, CLIENT_CERT_URI_SAN משמש כבורר הראשי שמוגדר כברירת מחדל. כלומר, כשמתקבלות החלטות לגבי הרשאות, המערכת בודקת את שדות ה-SAN של ה-URI של אישור הלקוח.

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

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

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

ההשפעה של מגבלות הגודל של מאפיינים

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

דחייה יכולה להתרחש בתנאים הבאים:

  • המדיניות מאמתת את CLIENT_CERT_URI_SAN, וערכי ה-SAN של ה-URI של האישור חורגים ממגבלת הגודל.
  • המדיניות מאומתת מול CLIENT_CERT_DNS_NAME_SAN, ושמות ה-SAN של אישור ה-DNS חורגים ממגבלת הגודל.
  • המדיניות מאמתת את CLIENT_CERT_COMMON_NAME, והנושא של האישור (שכולל את השם הנפוץ) חורג ממגבלת הגודל.

אם מאפיין של אישור חורג ממגבלת הגודל שלו, אבל לא מאומת באופן מפורש על ידי בורר העיקרון של המדיניות, הבקשה עדיין מוערכת בהתאם לכללי העיקרון שהוגדרו. לדוגמה, אם המדיניות מוגדרת לאמת רק את CLIENT_CERT_DNS_NAME_SAN, בקשה מלקוח עם ערכי SAN URI גדולים מדי לא תידחה בגלל זה. המדיניות ממשיכה להעריך את הבקשה על סמך ה-SAN של שם ה-DNS.

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

מדיניות הרשאות שמבוססת על חשבונות שירות או על תגים מאובטחים

מדיניות הרשאות שמבוססת על חשבונות שירות או על תגים מאובטחים נתמכת במאזני העומסים הבאים:

  • מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
  • מאזני עומסים פנימיים של אפליקציות (ALB) שפועלים בכמה אזורים

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

  • למנוע ממכונה וירטואלית ב-Compute Engine עם חשבון שירות ספציפי (my-sa-123@PROJECT_ID.iam.gserviceaccount.com) להגיע לנתיב /api/payments.

  • לאפשר למכונות וירטואליות של Compute Engine עם תג מאובטח (environment: prod צמד מפתח/ערך) להגיע לנתיב /api/payments.

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

בטבלה הבאה מפורטים Google Cloud השירותים השונים שתומכים בשימוש בחשבונות שירות ובטגים מאובטחים.

שירותGoogle Cloud תמיכה בחשבון שירות תמיכה בתגים מאובטחים
מכונה וירטואלית (VM) ב-Compute Engine
צומת של Google Kubernetes Engine‏ (GKE)
מאגר Google Kubernetes Engine‏ (GKE) 1 1
Direct VPC for Cloud Run 1
מחבר חיבור לרשת (VPC) מאפליקציית serverless 2 2
‫Cloud VPN 1 1
Cloud Interconnect on premises 1 1
‫Application Load Balancer 3 3
מאזן עומסים ברשת 3 3

‫1 לא נתמך על ידי Google Cloud.

‫2 כתובת ה-IP של המקור היא ייחודית ואפשר להשתמש בה במקום זאת.

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

בטבלה הבאה מפורטות ארכיטקטורות שונות של ענן וירטואלי פרטי (VPC) שתומכות בשימוש בחשבונות שירות ובתגים.

VPC ארכיטקטורת VPC תמיכה
בתוך VPC בין פרויקטים (VPC משותף)
בתוך VPC בין אזורים
Cross VPC קישור בין רשתות שכנות (VPC שכנה)
Cross VPC התחברות בין רשתות Private Service Connect
Cross VPC Cross Network Connectivity Center spokes

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

מכסות

מידע על מכסות של מדיניות הרשאות זמין במאמר מכסות ומגבלות של מדיניות הרשאות.

תמחור

למידע על תמחור, אפשר לעיין במאמר בנושא תמחור רשת: איזון עומסים ב-Cloud.

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