כדי להגן על השירותים והאפליקציות שלכם מפני התקפות מניעת שירות (DoS) והתקפות באינטרנט, אתם יכולים לשלב את Google Cloud Armor עם מוצרים אחרים של Google Cloud Google. במאמר הזה מוסבר איך Cloud Armor פועל עם כללי חומת אש של VPC, Identity-Aware Proxy (IAP), Google Kubernetes Engine (GKE), Cloud CDN ו-Global Front End.
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) או למאזן עומסים קלאסי של אפליקציות. המטרה היא לחסום את התעבורה כך שלא תגיע ישירות לשרתים העורפיים (backend instance) שמוגדרים במאזן העומסים. במילים אחרות, רק תנועה חיצונית שמועברת דרך שרת proxy באמצעות מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות עם מדיניות אבטחה משויכת יכולה להגיע למופעים.
התרשים הקודם מציג את תצורת הפריסה הבאה:
- יוצרים שתי קבוצות של מכונות, אחת באזור
us-west1ואחת באזורeurope-west1. - פורסים מופעים של אפליקציות לקצה העורפי במכונות ה-VM בקבוצות המכונות.
- יוצרים מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות (ALB) במסלול Premium. מגדירים מפת 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 במאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או במאזן עומסים קלאסי של אפליקציות, צריך להשתמש בשירותי הקצה העורפי של מאזן העומסים. באופן דומה, מדיניות האבטחה של 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 לא בודק את הבקשה.
מידע נוסף על IAP והגדרות שקשורות אליו זמין במאמר בנושא שרת proxy לאימות זהויות (IAP).
Cloud Armor עם פריסות היברידיות
בפריסה היברידית, מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות (ALB) צריכים גישה לאפליקציה או למקור תוכן שפועלים מחוץ ל- Google Cloud, למשל בתשתית של ספק ענן אחר. אתם יכולים להשתמש ב-Cloud Armor כדי להגן על פריסות כאלה.
בתרשים הבא, למאזן העומסים יש שני שירותים לקצה העורפי. אחד מהם משתמש בקבוצת מכונות כבק-אנד. לשירות העורפי השני יש NEG לאינטרנט כחלק העורפי שלו, וה-NEG לאינטרנט משויך לאפליקציה שפועלת במרכז נתונים של ספק צד שלישי.
כשמצרפים מדיניות אבטחה של Cloud Armor לשירות הקצה העורפי שיש לו NEG באינטרנט כקצה עורפי, Cloud Armor בודק כל בקשה בשכבה 7 שמגיעה למאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או למאזן עומסים קלאסי של אפליקציות (ALB) שמיועד לשירות הקצה העורפי הזה.
ההגנה של Cloud Armor על פריסות היברידיות כפופה לאותן מגבלות שחלות על קבוצות נקודות קצה ברשת האינטרנט.
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: מדיניות אבטחה של קצה ומדיניות אבטחה של קצה עורפי.
מדיניות אבטחה של Edge
אתם יכולים להשתמש במדיניות אבטחה של קצה הרשת בשירותי קצה עורפי ובקטגוריות קצה עורפי של Cloud Storage שמופעל בהם Cloud CDN, מאחורי מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאחורי מאזן עומסים קלאסי של אפליקציות (ALB). אפשר להשתמש במדיניות אבטחה של קצה הרשת כדי לסנן בקשות לפני שהתוכן מוגש מהמטמון.
מדיניות אבטחה של קצה עורפי
כשמחילים מדיניות אבטחה של Cloud Armor על שירותים לקצה העורפי עם Cloud CDN מופעל, המדיניות חלה רק על בקשות שמנותבות לשירות לקצה העורפי. הבקשות האלה כוללות בקשות לתוכן דינמי ופספוסים במטמון – כלומר, בקשות שלא נכללות במטמון של Cloud CDN או שעוקפות אותו.
כשמדיניות אבטחה של קצה ומדיניות אבטחה של קצה עורפי מצורפות לאותו שירות קצה עורפי, מדיניות האבטחה של הקצה העורפי נאכפת רק על בקשות של אי מציאה במטמון שעברו את מדיניות האבטחה של הקצה
בתרשים הבא מוצג באופן בלעדי איך מדיניות אבטחה של קצה עורפי פועלת עם מקורות של 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 שמוגדרת כברירת מחדל ומוקצית Google Cloud באופן אוטומטי לשירותי Cloud Run או לפונקציות Cloud Run (דור שני). כדי להגן על אפליקציות App Engine, אפשר להשתמש באמצעי בקרה לגישה.
אם אתם משתמשים באמצעי בקרה על תעבורת נכנסת כדי להחיל את אמצעי בקרת הגישה על כל התעבורה הנכנסת, אתם יכולים להשתמש בהגדרת התעבורה הנכנסת internal-and-gclb כשאתם מגדירים פונקציות של Cloud Run או Cloud Run.
הגדרת הכניסה internal-and-gclb מאפשרת רק תעבורה פנימית ותעבורה שנשלחת לכתובת IP חיצונית שנחשפת על ידי מאזן העומסים החיצוני הגלובלי של האפליקציות או מאזן העומסים הקלאסי של האפליקציות. תנועה שנשלחת לכתובות ה-URL האלה שמוגדרות כברירת מחדל מחוץ לרשת הפרטית שלכם נחסמת.
ההגדרה הזו עוזרת למנוע מהמשתמשים לעקוף אמצעי בקרה על הגישה (כמו מדיניות אבטחה של Cloud Armor) שהוגדרו באמצעות מאזן עומסים גלובלי חיצוני של אפליקציות או מאזן עומסים קלאסי של אפליקציות.
מידע נוסף על NEGs ללא שרתים זמין במאמרים סקירה כללית של קבוצות של נקודות קצה ברשת ללא שרתים והגדרת קבוצות של נקודות קצה ברשת ללא שרתים.
Cloud Armor עם Cloud Service Mesh
אתם יכולים להגדיר מדיניות אבטחה פנימית של שירותים עבור רשת Service mesh כדי לאכוף הגבלת קצב גלובלית בצד השרת לכל לקוח. כך תוכלו לחלוק בצורה הוגנת את הקיבולת הזמינה של השירות ולצמצם את הסיכון של לקוחות זדוניים או לקוחות שמתנהגים בצורה לא תקינה שגורמים לעומס יתר על השירותים. מצרפים מדיניות אבטחה למדיניות של נקודת קצה ב-Cloud Service Mesh כדי לאכוף הגבלת קצב יצירת הבקשות בתעבורה נכנסת בצד השרת. עם זאת, אי אפשר להגדיר מדיניות אבטחה של Cloud Armor אם משתמשים בניתוב תנועת TCP. מידע נוסף על שימוש ב-Cloud Armor עם Cloud Service Mesh זמין במאמר הגדרת הגבלת קצב של יצירת בקשות באמצעות 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 .
המאמרים הבאים
- הגדרת מדיניות אבטחה, כללים וביטויים
- מידע על התכונות במסלולים של Google Cloud Armor Enterprise
- פתרון בעיות