בעזרת Secure Web Proxy אתם יכולים לאבטח את כל תנועת הגולשים היוצאת – HTTP ו-HTTPS – מהרשת הפנימית של הארגון. כשמגדירים את הלקוחות כך שישתמשו ב-Secure Web Proxy כשער, Secure Web Proxy הוא נקודת ביקורת אבטחה חובה לכל אפליקציה או שירות שמנסים לגשת לאתר מחוץ לארגון.
יתרונות
אלה היתרונות העיקריים של Secure Web Proxy:
אין צורך בתחזוקה. אחרי שמגדירים את כללי המדיניות, Secure Web Proxy מנהל את השרתים, התיקונים וההתאמה לעומס (scaling) כדי להתאים את הקיבולת באופן אוטומטי ככל שהתנועה גדלה.
כללים גמישים וניתנים לשימוש חוזר. ב-Secure Web Proxy, מדיניות האבטחה נפרדת מהפרוקסי עצמו. כדי להבטיח ניהול עקבי, האדמינים יוצרים קבוצה של כללי גישה ומחילים אותם על כמה שרתי proxy בחלקים שונים של הארגון.
אבטחה חזקה כברירת מחדל. ל-Secure Web Proxy יש הגדרת ברירת מחדל
deny-allשחוסמת את כל התנועה היוצאת עד שמאשרים אותה באופן מפורש. Google Cloud המערכת מטפלת אוטומטית בכל עדכוני התוכנה והתשתית, וכך מצמצמת את הסיכון המתמשך לפרצות אבטחה.בקרת גישה שמודעת לזהות. הסיבה לכך היא ש-Secure Web Proxy בודק מאיפה מגיעה הבקשה (כתובת ה-IP) ומי שולח את הבקשה (המשתמש או זהות השירות), ולכן הגישה מבוססת על תפקיד המשתמש והצורך שלו, ולא רק על המיקום ברשת. הזהות יכולה להיות חשבון שירות, תג מאובטח או כל זהות שסופקה על ידי אישור לקוח שאומת באמצעות frontend mTLS. באמצעות Secure Web Proxy אפשר ליצור כללים ספציפיים מאוד, כמו "רק חברים בצוות הכספים יכולים לגשת לאתר הבנק הזה".
רישום ביומן וביקורת של תנועה מאוחדת. כל תנועה באתר שעוברת דרך Secure Web Proxy מתועדת ביומן מרכזי ונבדקת ב- Google Cloud. מקור האמון היחיד והברור הזה לכל הגישה החוצה עוזר לכם לעקוב אחרי הפעילות, לחקור אירועי אבטחה ולעמוד בדרישות התאימות.
בדיקה מרכזית. Secure Web Proxy מאחד בקשות אינטרנט יוצאות מעומסי העבודה בענן וממשרדים מחוברים לנקודת בדיקה אחת, כדי לאכוף את המדיניות באופן עקבי.
ניהול פשוט יותר של יציאות. כשפורסים את המכונה של Secure Web Proxy בתור הדילוג הבא, אפשר להאזין לכל היציאות (מ-
1עד65535). הפונקציונליות הזו מייתרת את הצורך למנות יציאות ספציפיות, והיא שימושית בסביבות דינמיות או בשירותים שמשתמשים בכמה יציאות. למידע על המגבלות שקשורות לשימוש בתכונהall_ports, קראו את המאמר מגבלות.מעקב מבוזר. שילוב מובנה עם Cloud Trace ו-OpenTelemetry מאפשר לכם לעקוב אחרי כל מחזור החיים של בקשות יוצאות מעומסי עבודה פנימיים דרך Secure Web Proxy. בעזרת התכונה הזו אפשר לאתר צווארי בקבוק של זמן אחזור ולנתח את מחזורי החיים של הבקשות.
התכונות הנתמכות
Secure Web Proxy תומך בתכונות הבאות:
התאמה אוטומטית לעומס של שרתי proxy מסוג Envoy ב-Secure Web Proxy: ב-Secure Web Proxy אפשר להתאים באופן אוטומטי את הגודל והקיבולת של מאגר שרתי ה-proxy מסוג Envoy באזור מסוים, כדי לשמור על ביצועים עקביים בתקופות של ביקוש גבוה בעלות הנמוכה ביותר. התכונה 'התאמה אוטומטית לעומס' מנהלת אוטומטית את השינויים בקיבולת באזור מסוים. זה אומר שאתם לא צריכים לעקוב באופן ידני אחרי צי שרתי ה-Proxy ולשנות את הגודל שלו, וכך אתם נהנים מביצועים טובים יותר ומשקיעים פחות זמן בתפעול.
מדיניות מודולרית לגישה ליוצא: Secure Web Proxy מנהל את התנועה היוצאת באמצעות הפעולות הבאות:
- מזהה ישויות מקור באמצעות תגים מאובטחים, חשבונות שירות, כתובות IP או זהויות של אישורי לקוח שאומתו באופן קריפטוגרפי באמצעות Mutual TLS (mTLS) של ממשק קצה.
- מסנן את יעדי היעד לפי שמות מארחים או כתובות URL כשמפעילים בדיקת TLS או משתמשים ב-HTTP לא מוצפן.
- הערכה של מאפייני בקשה כמו שיטות, כותרות או כתובות URL אם התנועה היא HTTP לא מוצפנת או אם מופעלת בדיקת TLS.
האופי המודולרי של המדיניות (מקורות, יעדים ובקשות) מאפשר לצוותים שונים ליצור ולנהל רכיבי כללים ספציפיים לשימוש חוזר. אדמין מרכזי יכול להגדיר רשימת כתובות URL, ואז כמה שרתי proxy יכולים להפנות אליה במדיניות הנפרדת שלהם.
הגבלת קצב של יצירת בקשות לשירות: ב-Secure Web Proxy נאכפות מגבלות על תנועת הגולשים היוצאת, כדי למנוע מלקוחות שצורכים הרבה משאבים לנצל את כל קיבולת השירות או ליצור עלויות מוגזמות, כמו אלה שקשורות לאסימונים של מודל שפה גדול (LLM). אפשר לצרף מדיניות להגבלת קצב של שירותים לשערים שהוגדרו עם מדיניות אבטחה של שערים או עם מדיניות הרשאה. אתם יכולים להשתמש במדיניות להגבלת קצב שליחת בקשות כדי לתת עדיפות לתעבורת נתונים או להגביל אותה על סמך מספר הבקשות וזהויות לקוח ספציפיות, כמו חשבונות ראשיים של mTLS או כתובות IP של מקורות.
הצפנה מקצה לקצה: מנהרות של שרת proxy של לקוח יכולות לעבור דרך TLS. Secure Web Proxy תומך גם ב-HTTP וב-HTTPS
CONNECTלחיבורי TLS מקצה לקצה שיזם הלקוח לשרת היעד.השירות מנהל את אמצעי האבטחה החשוב הזה באופן אוטומטי, כך שהתנועה מאובטחת בלי שצריך להגדיר או לנטר ידנית את תקני ההצפנה.
שילוב של יומני ביקורת של Cloud ו-Google Cloud Observability: באמצעות Google Cloud Observability, יומני הביקורת של Cloud מתעדים גם פעולות ניהוליות (שינויים במדיניות) וגם בקשות גישה ומדדים (יומני עסקאות של שרת proxy) של Secure Web Proxy. התצוגה המאוחדת והמובנית הזו מאפשרת ניטור לצורכי אבטחה ודיווח על תאימות.
גישה גלובלית: כשיוצרים מכונה של שרת proxy, אפשר להפעיל גישה גלובלית ל-Secure Web Proxy. התכונה הזו מאפשרת ללקוחות מכל אזור Google Cloud להתחבר לשרת ה-proxy, ולא רק ללקוחות באזור מקומי ספציפי. התכונה הזו משפרת את העמידות של התשתית ותומכת בתרחישי שימוש באזורים שונים, כמו דרישות מותאמות אישית לתנועה יוצאת. מידע נוסף זמין במאמר הגדרת גישה גלובלית ל-Secure Web Proxy.
איך פועל Secure Web Proxy
Secure Web Proxy פועל כנקודת בקרה חובה לאבטחה של כל תנועת הגולשים מהרשת של הארגון לאינטרנט. עומסי עבודה פנימיים חייבים לעמוד בכללי האבטחה של Secure Web Proxy לפני שהם יכולים להגיע לאינטרנט.
שער מרכזי: עומסי העבודה, כמו מכונות וירטואליות (VM) וקונטיינרים, מוגדרים לשלוח את כל בקשות לאחזור מהרשת היוצאות למופע המרכזי של Secure Web Proxy.
אכיפת המדיניות: שרת ה-proxy בודק את הבקשה ומחיל את מדיניות האבטחה כדי לקבוע אם לאשר או לדחות את החיבור.
תעבורת נתונים יוצאת מאובטחת: אם הבקשה מותרת, תעבורת הנתונים מנותבת בצורה מאובטחת לאינטרנט באמצעות התשתית של Google Cloud, בדרך כלל Cloud NAT. שרת ה-proxy משתמש גם ב-Cloud DNS כדי לתרגם כתובות אינטרנט חיצוניות.
מדיניות וכללים
אפשר להגדיר את כללי המדיניות והכללים הבאים במופע של Secure Web Proxy:
מדיניות הרשאות: המדיניות הזו מאפשרת לכם לבצע בדיקות של בקרת גישה שמבוססות על זהות או על יעד, כשמעבדים בקשות יוצאות דרך מופע Secure Web Proxy. אתם יכולים להגדיר כללי מדיניות הרשאה (
AuthzPolicy) כדי לאמת את הזהות של סוכן או של עומס עבודה במקור שניגש לאינטרנט.כללי מדיניות אבטחה של שערים: כללי המדיניות האלה מגדירים את תקן האבטחה הכולל של שער ספציפי. מדיניות אבטחה של שער היא הקונטיינר הראשי של הוראות האבטחה.
כללי אבטחה של שערים: בכל מדיניות אבטחה של שער, אפשר להוסיף כלל אבטחה אחד או יותר של שערים. הכללים האלה הם ההוראות הספציפיות שמאפשרות או דוחות תנועה על סמך קריטריונים שונים.
כללי מדיניות להגבלת קצב של יצירת בקשות לשירות: כללי המדיניות האלה מאפשרים לאכוף מגבלות קצב של יצירת בקשות ספציפיות ללקוח וכלל-שירותיות על תנועת אינטרנט יוצאת. אתם יכולים להגדיר מגבלות קצב של יצירת בקשות לפי מספר הבקשות לדקה, ואז לשייך את המגבלות האלה ללקוחות ספציפיים או לקבוצות של לקוחות.
מצבי פריסה
אפשר לפרוס את מופע Secure Web Proxy באחד מהמצבים הבאים:
מצב ניתוב מפורש של שרת proxy: במצב הזה, צריך להגדיר באופן מפורש את סביבות עומסי העבודה והלקוחות כך שיצביעו ישירות על שרת ה-proxy. לאחר מכן, Secure Web Proxy מבודד את הלקוחות מהאינטרנט. בדרך הזו, Secure Web Proxy פועל כמתווך, יוצר חיבורי TCP חדשים עבור הלקוח ומוודא שכל חיבור עומד בדרישות של מדיניות האבטחה המנוהלת.
מצב קובץ מצורף של שירות Private Service Connect: במצב הזה, אפשר לרכז את פריסות שרתי ה-proxy שלכם באינטרנט בארכיטקטורה מורכבת של כמה רשתות VPC.
מצב הצעד הבא: במצב הזה, אפשר להגדיר את מופע Secure Web Proxy כך שיפעל כצעד הבא לניתוב ברשת. במילים אחרות, אתם יכולים להגדיר את ניתוב הרשת כך שתנועה יוצאת תישלח באופן אוטומטי למכונה של Secure Web Proxy. שיטת הפריסה הזו מפחיתה את התקורה הניהולית של הארגון, כי לא צריך להגדיר ידנית כל עומס עבודה או לקוח במקור כדי להשתמש בשרת ה-proxy.
מגבלות
גרסאות IP: Secure Web Proxy תומך רק ב-IPv4, ולא ב-IPv6.
גרסאות HTTP: Secure Web Proxy תומך בגרסאות HTTP/0.9, 1.0, 1.1 ו-2.0. אין תמיכה ב-HTTP/3.
היקף הפריסה: אפשר לפרוס מופע של Secure Web Proxy רק בפרויקט מארח, ולא בפרויקט שירות.
כלים נוספים של Google Cloud שכדאי לבדוק
אתם יכולים לשלב את Secure Web Proxy עם הכלים הבאים של Google Cloud כדי לשפר את מצב האבטחה הכולל של עומסי העבודה והאפליקציות:
משתמשים ב-Mutual TLS (mTLS) קצה קדמי כדי לאפשר ל-Secure Web Proxy להגדיר זהויות לקוח מאומתות בכללי מדיניות הרשאה ולאכוף בקרת גישה פרטנית לתנועה יוצאת.
אתם יכולים להשתמש בCertificate Manager כדי לנהל את ישויות העוגן האמינות (אישורי הבסיס) ואת רשויות האישורים (CA) המתווכות שנדרשות לאימות אישורי הלקוח בחיבורי mTLS של קצה קדמי ל-Secure Web Proxy.
להטמיע את VPC Service Controls כדי למנוע זליגת נתונים משירותי Google Cloud , כמו Cloud Storage ו-BigQuery.
משתמשים ב-Trace כדי לקבל נתוני מעקב מבוזרים לבקשות יוצאות ולנתח את זמן האחזור של הרשת מקצה לקצה.