‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

כדי להגן על השירותים והאפליקציות שלכם מפני התקפות מניעת שירות (DoS) ומתקפות באינטרנט, אתם יכולים לשלב את Google Cloud Armor עם מוצרים אחרים של Google Cloud. במאמר הזה מוסבר איך Cloud Armor פועל עם כללי חומת אש של VPC, עם שרת proxy לאימות זהות (IAP), עם Google Kubernetes Engine ‏(GKE), עם Cloud CDN ועם ממשק קצה גלובלי (GFE).

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

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

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

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

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

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

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

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

‫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 עם IAP. — שימוש ברשימות של כתובות IP שנחסמו וברשימות היתרים לכתובות IP עם IAP (לחצו כדי להגדיל).

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

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

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

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

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

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

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

‫Cloud Armor עם 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: מדיניות אבטחה בקצה הרשת ומדיניות אבטחה לקצה העורפי.

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

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

כללי מדיניות אבטחה של בק-אנד

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

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

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

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

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

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

אתם יכולים להשתמש בכללי מדיניות האבטחה של Cloud Armor עם קצה עורפי של קבוצת נקודות קצה ברשת ללא שרת (serverless NEG) שמפנה לשירות של Cloud Run, של App Engine או של פונקציות Cloud Run.

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

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

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

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

‫Cloud Armor עם Cloud Service Mesh

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

Cloud Armor והגבלת קצב של יצירת בקשות בשירות

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

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

‫Cloud Armor וממשק קצה גלובלי (GFE)

‫Global Front End משלב את Cloud Armor,‏ מאזני עומסים גלובליים חיצוניים של אפליקציות, Service Extensions ו- Cloud CDN לפתרון אחד שיעזור לכם לספק, להרחיב ולאבטח את האפליקציות שפונות לאינטרנט. ברמת התמחור Global Front End Enterprise, התמחור של המוצרים האלה מאוחד בתוכנית תמחור אחת.

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