Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שילוב של Cloud Armor עם מוצרים אחרים של Google

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

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

לכללי מדיניות האבטחה של Cloud Armor ולכללי חומת האש של VPC יש פונקציות שונות:

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

לדוגמה, נניח שאתם רוצים לאפשר תעבורת נתונים רק מטווח ה-CIDR‏ 100.1.1.0/24 ומטווח ה-CIDR‏ 100.1.2.0/24 כדי לגשת למאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או למאזן עומסים קלאסי של אפליקציות. המטרה היא לחסום תעבורה שלא מגיעה ישירות למופעים מאוזני העומסים בעורף. במילים אחרות, רק תנועה חיצונית שעוברת דרך שרת proxy באמצעות מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות עם מדיניות אבטחה משויכת יכולה להגיע למופעים.

שימוש במדיניות האבטחה של Cloud Armor עם חומות אש של תעבורת נכנסת כדי להגביל את הגישה. — שימוש במדיניות אבטחה של Cloud Armor עם חומות אש של תעבורת נכנסת כדי להגביל את הגישה (לחצו כדי להגדיל).

התרשים הקודם מציג את תצורת הפריסה הבאה:

יוצרים שתי קבוצות של מכונות, אחת באזור us-west1 ואחת באזור europe-west1.
פורסים מופעים של אפליקציות לקצה העורפי במכונות הווירטואליות בקבוצות המכונות.
יוצרים מאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות במסלול פרימיום. מגדירים מפת URL ושירות לקצה העורפי יחיד, ששני קבוצות המופעים שיצרתם בשלב הקודם משמשות כבק-אנד שלו. כלל ההעברה של מאזן העומסים חייב להשתמש בכתובת ה-IP החיצונית 120.1.1.1.
מגדירים מדיניות אבטחה של Cloud Armor שמאפשרת תנועה מ-100.1.1.0/24 ומ-100.1.2.0/24 ודוחה את כל התנועה האחרת.
משייכים את המדיניות הזו לשירות לקצה העורפי של מאזן העומסים. הוראות מפורטות זמינות במאמר הגדרת מדיניות אבטחה ב-Cloud Armor. מאזני עומסים חיצוניים מסוג HTTP(S) עם מפות URL מורכבות יותר יכולים להפנות לכמה שירותים לקצה העורפי. אפשר לשייך את מדיניות האבטחה לשירות לקצה העורפי אחד או יותר לפי הצורך.
מגדירים כללי חומת אש שמאפשרים תעבורת נתונים נכנסת כדי לאפשר תעבורת נתונים ממאזן עומסים גלובלי חיצוני של אפליקציות או ממאזן עומסים של אפליקציות בגרסה הקלאסית. מידע נוסף זמין במאמר בנושא כללים של חומת אש.

‫Cloud Armor עם מאזני עומסים חיצוניים של אפליקציות (ALB) ו-IAP

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

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

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

שימוש ברשימות של כתובות IP שנחסמו וברשימות של כתובות IP מורשות עם IAP. — שימוש ברשימות של כתובות IP שנחסמו וברשימות היתרים לכתובות IP עם IAP (לחצו כדי להגדיל).

מידע נוסף על IAP והגדרות שקשורות אליו זמין במאמרים בנושא שרת proxy לאימות זהויות (IAP).

‫Cloud Armor עם פריסות היברידיות

בפריסה היברידית, מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות (ALB) צריכים גישה לאפליקציה או למקור תוכן שפועלים מחוץ ל- Google Cloud, למשל בתשתית של ספק ענן אחר. אפשר להשתמש ב-Cloud Armor כדי להגן על פריסות כאלה.

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

‫Cloud Armor לפריסות היברידיות. — Cloud Armor לפריסות היברידיות (לחצו כדי להגדיל).

כשמצרפים מדיניות אבטחה של Cloud Armor לשירות לקצה העורפי שיש לו NEG באינטרנט כקצה עורפי, Cloud Armor בודק כל בקשה בשכבה 7 שמגיעה למאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או למאזן עומסים קלאסי של אפליקציות (ALB), שמיועד לשירות לקצה העורפי הזה.

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

‫Cloud Armor עם Google Kubernetes Engine‏ (GKE)

בקטעים הבאים מוסבר איך Cloud Armor פועל עם GKE.

GKE Ingress

אחרי שמגדירים כללי מדיניות אבטחה של Cloud Armor, אפשר להשתמש ב-Kubernetes Ingress כדי להפעיל אותם ב-GKE.

אפשר להפנות למדיניות האבטחה באמצעות BackendConfig משאב על ידי הוספת שם מדיניות האבטחה אל BackendConfig. במניפסט BackendConfig הבא מצוינת מדיניות אבטחה בשם example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

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

GKE Gateway

אחרי שמגדירים מדיניות אבטחה של Cloud Armor, אפשר להשתמש ב-Kubernetes Gateway API כדי להפעיל אותה ב-GKE.

אפשר להוסיף את השם של מדיניות האבטחה שלכם למשאב מדיניות GCPBackendPolicy כדי להפנות אליה. במניפסט של משאב המדיניות GCPBackendPolicy הבא מצוינת מדיניות אבטחה של קצה עורפי בשם example-security-policy:

שירות

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

שירות אשכול מרובה

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

מידע נוסף על הגדרת כללי מדיניות אבטחה של עורף השרת ב-Cloud Armor זמין במאמר הגדרת כללי מדיניות אבטחה של עורף השרת ב-Cloud Armor כדי לאבטח את שירותי עורף השרת.

‫Cloud Armor עם Cloud CDN

כדי להגן על שרתי מקור של CDN, אפשר להשתמש ב-Cloud Armor עם Cloud CDN. ‫Cloud Armor מגן על שרת המקור של ה-CDN מפני מתקפות על אפליקציות, מצמצם את עשרת סיכוני האבטחה המובילים של OWASP ומחיל מדיניות סינון בשכבה 7. יש שני סוגים של כללי אבטחה שמשפיעים על האופן שבו Cloud Armor פועל עם Cloud CDN: כללי אבטחה של קצה וכללי אבטחה של קצה עורפי.

מדיניות אבטחה של Edge

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

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

כשמחילים מדיניות אבטחה של קצה עורפי ב-Cloud Armor על שירותים לקצה העורפי עם Cloud CDN מופעל, המדיניות חלה רק על בקשות שמנותבות לשירות לקצה העורפי. הבקשות האלה כוללות בקשות לתוכן דינמי ופספוסים במטמון – כלומר, בקשות שלא נמצאות במטמון של Cloud CDN או שעוקפות אותו.

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

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

שימוש בכללי מדיניות אבטחה של קצה עורפי של Cloud Armor עם Cloud CDN. — שימוש במדיניות אבטחה של קצה עורפי ב-Cloud Armor עם Cloud CDN (לחצו כדי להגדיל).

מידע נוסף על Cloud CDN זמין במסמכי התיעוד של Cloud CDN.

‫Cloud Armor עם Cloud Run,‏ App Engine או פונקציות Cloud Run

אפשר להשתמש במדיניות אבטחה של Cloud Armor עם קצה עורפי של NEG מסוג Serverless שמפנה לשירות Cloud Run,‏ App Engine או Cloud Run Functions.

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

משתמשים שיש להם את כתובת ה-URL שמוגדרת כברירת מחדל לאפליקציה בלי שרת יכולים לעקוף את איזון העומסים ולעבור ישירות לכתובת ה-URL של השירות. הפעולה הזו עוקפת את כללי האבטחה של Cloud Armor. כדי לפתור את הבעיה הזו, צריך להשבית את כתובת ה-URL שמוגדרת כברירת מחדל ומוקצית באופן אוטומטי לשירותי Cloud Run או לפונקציות Cloud Run (דור שני). Google Cloud כדי להגן על אפליקציות App Engine, אפשר להשתמש באמצעי בקרה לכניסה.

אם אתם משתמשים באמצעי בקרה על תעבורת נכנסת כדי להחיל את אמצעי בקרת הגישה על כל התעבורה הנכנסת, אתם יכולים להשתמש בהגדרת התעבורה הנכנסת internal-and-gclb כשאתם מגדירים פונקציות של Cloud Run או Cloud Run. הגדרת הכניסה internal-and-gclb מאפשרת רק תעבורה פנימית ותעבורה שנשלחת לכתובת IP חיצונית שנחשפת על ידי מאזן העומסים החיצוני הגלובלי של האפליקציות או מאזן העומסים הקלאסי של האפליקציות. תנועה שנשלחת לכתובות ה-URL האלה שמוגדרות כברירת מחדל מחוץ לרשת הפרטית נחסמת. כך המשתמשים לא יכולים לעקוף אמצעי בקרת גישה (כמו מדיניות אבטחה של Cloud Armor) שהוגדרו באמצעות מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות (ALB).

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

‫Cloud Armor עם Cloud Service Mesh

אתם יכולים להגדיר מדיניות אבטחה פנימית של שירותים עבור רשת Service mesh כדי לאכוף הגבלת קצב של יצירת בקשות גלובלית בצד השרת לכל לקוח. כך תוכלו לחלוק בצורה הוגנת את הקיבולת הזמינה של השירות ולצמצם את הסיכון של לקוחות זדוניים או לקוחות שמתנהגים בצורה לא תקינה וגורמים לעומס יתר על השירותים. מצרפים מדיניות אבטחה למדיניות של נקודת קצה ב-Cloud Service Mesh כדי לאכוף הגבלת קצב יצירת הבקשות בתעבורה נכנסת בצד השרת. עם זאת, אי אפשר להגדיר מדיניות אבטחה של Google Cloud Armor אם משתמשים בניתוב תנועת TCP. מידע נוסף על שימוש ב-Cloud Armor עם Cloud Service Mesh זמין במאמר הגדרת הגבלת קצב של יצירת בקשות באמצעות Cloud Armor.