מדיניות הרשאות (AuthzPolicy) שמוחלת על כלל ההעברה של איזון עומסים של אפליקציות מגדירה כללים שמציינים את המקור של התנועה הנכנסת ואת הפעולות שמותרות או אסורות למקור הזה.
בנוסף, מדיניות ההרשאות מפרטת את התנאים שבהם כלל חל ומציינת פעולה שמאפשרת, דוחה או מעריכה עוד יותר את התנועה.
כללי מדיניות של הרשאה מאפשרים לכם להגדיר בדיקות של בקרת גישה לתנועה נכנסת למאזני עומסים של אפליקציות. בקשות שעוברות את הבדיקות האלה מנותבות לשירותים לקצה העורפי. בקשות שנכשלות בבדיקות האלה מסתיימות בתשובה לא מורשית.
אפשר להגדיר מדיניות הרשאה בכללי ההעברה של כל מאזני העומסים של האפליקציות עם סכמת איזון עומסים של EXTERNAL_MANAGED או INTERNAL_MANAGED.
מאזני העומסים הבאים של אפליקציות תומכים במדיניות הרשאות:
- מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)
- מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
- מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
- מאזני עומסים פנימיים של אפליקציות (ALB) שפועלים בכמה אזורים
במאזני עומסים של אפליקציות, הפעלת מדיניות ההרשאות מתבצעת אחרי הערכה של תוספי מסלולים, מדיניות אבטחת רשת (שמוערכת על ידי Google Cloud Armor), מדיניות שיתוף משאבים בין מקורות (CORS) ומדיניות שרת proxy לאימות זהויות (IAP), אבל לפני ביצוע פעולות לניהול תנועה.
מידע נוסף על המקרים שבהם מופעלות מדיניות הרשאות בנתיב עיבוד הבקשות זמין במאמר נקודות הרחבה בנתיב הנתונים של איזון העומסים.
אם רוצים להשתמש במדיניות הרשאות לשירותים שנפרסו באמצעות Cloud Service Mesh, אפשר לעיין במאמר הגדרת אבטחת שירות באמצעות Envoy.
כללים של מדיניות ההרשאות
מדיניות הרשאה מורכבת מרשימה של כללי 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, מדיניות ההרשאות תמיד מעבירה את החלטת ההרשאה לספק הרשאות בהתאמה אישית. למידע נוסף, אפשר לעיין בדוגמה הבאה שבה לא מוגדרים כללי HTTP ומדיניות ההרשאות מעבירה את החלטת ההרשאה ל-IAP:
סדר ההערכה של מדיניות ההרשאות
מדיניות ההרשאות תומכת במדיניות CUSTOM, DENY ו-ALLOW לבקרת גישה. אם כמה כללי מדיניות הרשאות משויכים למשאב אחד, המערכת בודקת קודם את כלל המדיניות CUSTOM, אחר כך את כלל המדיניות DENY ולבסוף את כלל המדיניות ALLOW. ההערכה מתבצעת לפי הכללים הבאים:
אם יש מדיניות
CUSTOMשתואמת לבקשה, המדיניותCUSTOMמוערכת באמצעות ספקי ההרשאות המותאמים אישית, והבקשה נדחית אם הספק דוחה אותה. המערכת לא מעריכה את המדיניותDENYאוALLOW, גם אם הן מוגדרות.אם יש מדיניות
DENYשתואמת לבקשה, הבקשה נדחית. המערכת לא מעריכה מדיניות מסוגALLOW, גם אם היא מוגדרת.אם לא קיימות מדיניות
ALLOW, הבקשה מאושרת.אם אחת ממדיניות
ALLOWתואמת לבקשה, מאשרים את הבקשה.אם קיימות מדיניות
ALLOW, אבל אין התאמה, הבקשה נדחית. במילים אחרות, הבקשה נדחית כברירת מחדל אם אף אחת מההגדרות שלAuthzPoliciesעם פעולתALLOWלא תואמת לבקשה.
שימוש במדיניות הרשאות כדי להעביר החלטות בנושא הרשאות
להחלטות מורכבות לגבי הרשאות שלא ניתן לבטא באמצעות מדיניות ההרשאות, אפשר להעביר את ההחלטה לגבי ההרשאות לספקי הרשאות בהתאמה אישית, כמו Identity-Aware Proxy (IAP), או ליצור תוסף הרשאות משלכם באמצעות Service Extensions. האפשרות הזו שימושית כשרוצים להשתמש במנוע ההרשאות המקומי או בספקי זהויות של צד שלישי דרך IAP.
IAP: הגדרת IAP כדי לשלוט בגישה לאפליקציות שמאחורי כללי העברה של מאזן עומסים של אפליקציות. IAP מאמת את זהות המשתמש וההקשר כדי לקבוע את הגישה. הוא יכול גם לאמת אסימונים של חשבונות שירות בניהול זהויות והרשאות גישה (IAM) ולהעריך מדיניות IAM, כדי להגן על הגישה לדליים בעורף שחשופים ממאזן העומסים של האפליקציה. מידע נוסף זמין במאמר העברת הרשאות ל-IAP ול-IAM.
יכול להיות שתבחרו להעביר את האימות ל-IAP ול-IAM בתרחישים הבאים:
- שימוש ב-IAM לניהול הרשאות.
- הטמעה של בקרת גישה מבוססת-הקשר.
- משתמשים באימות מבוסס-דפדפן לאפליקציות אינטרנט שנדרש בהן אימות אינטראקטיבי.
Service Extensions: העברת סמכויות להחלטות הרשאה למנוע הרשאה מותאם אישית שפועל במכונות וירטואליות של Google Cloud או בשרתים מקומיים. כך אפשר להגדיר מדיניות הרשאות מורכבת שלא נכללת במדיניות המובנית. מידע נוסף מופיע במאמר בנושא הגדרת תוסף הרשאות.
מדיניות הרשאות שמבוססת על חשבונות משתמשים
כדי לזהות את מקור התנועה ברמת פירוט גבוהה, אפשר להגדיר מדיניות הרשאה על סמך זהויות שנגזרות מהאישור של הלקוח. כדי להשתמש בשיטה הזו צריך להפעיל 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.
דוגמה למדיניות הרשאות שמבוססת על חשבונות משתמשים מופיעה במאמר מדיניות הרשאות לדחיית בקשות.
מדיניות הרשאות שמבוססת על חשבונות שירות או על תגים
אתם יכולים להשתמש במאפיינים כמו חשבונות שירות או תגים כדי לזהות את מקור התעבורה עבור מאזני עומסים פנימיים של אפליקציות.
במאזני עומסים פנימיים של אפליקציות, אפשר להחיל מדיניות הרשאות על סמך חשבונות שירות או תגים שמצורפים ל Google Cloud משאבים. אפשר לאפשר, לדחות או להעביר לשירות חיצוני כל תנועה שמקורה במשאבים האלה Google Cloud שמקושרים לחשבון שירות או לתג ספציפיים.
בטבלה הבאה מפורטים משאבי המקור שתומכים בשימוש בחשבונות שירות ובתגים.
| מקור | תמיכה בחשבון שירות | תמיכה ב-Google Tag |
|---|---|---|
| VM | ||
| צומת GKE | ||
| קונטיינר GKE | 1 | 1 |
| Direct VPC for Cloud Run | 1 | |
| מחבר חיבור לרשת (VPC) מאפליקציית serverless | 2 | 2 |
| Cloud VPN | 1 | 1 |
| Cloud Interconnect באתרים מקומיים | 1 | 1 |
| מאזן עומסים של אפליקציות (ALB) | 3 | 3 |
| מאזן עומסי רשת | 3 | 3 |
1 לא אפשרי על ידי Google Cloud.
2 כתובת ה-IP של המקור היא ייחודית ואפשר להשתמש בה במקום זאת.
3 אין תמיכה בחשבונות שירות ובתגים כשמאזני עומסים של אפליקציות ומאזני עומסים של רשתות משמשים כמקורות תעבורה בארכיטקטורה מדורגת.
בטבלה הבאה מפורטות ארכיטקטורות שונות של ענן וירטואלי פרטי (VPC) שתומכות בשימוש בחשבונות שירות ובתגים.
| VPC | ארכיטקטורת VPC | תמיכה |
|---|---|---|
| בתוך VPC | בין פרויקטים (VPC משותף) | |
| בתוך VPC | בין אזורים | |
| Cross VPC | קישור בין רשתות שכנות (peer VPC) | |
| Cross VPC | התחברות לשירות פרטי | |
| Cross VPC | Cross Network Connectivity Center spokes |
מידע נוסף על הגדרת מדיניות הרשאות שמבוססת על חשבונות שירות ועל תגים שמצורפים למשאב של מכונה וירטואלית זמין במאמר מדיניות הרשאות שמבוססת על חשבונות שירות או על תגים. Google Cloud
מכסות
מידע על מכסות של מדיניות הרשאות זמין במאמר מכסות ומגבלות של מדיניות הרשאות.
תמחור
למידע על מחירים אפשר לעיין במאמר תמחור.