תנועת הרשת המוצפנת באמצעות Transport Layer Security (TLS) מהווה את הרוב המכריע של תנועת הרשת. גורמים זדוניים משתמשים לעיתים קרובות בערוצים המוצפנים האלה כדי להסתיר פעילות זדונית, ולכן חשוב לבדוק את התנועה הזו לפני שהיא מגיעה ליעד שלה.
Secure Web Proxy מספק שירות משולב לבדיקת TLS שמאפשר ליירט ולפענח תנועת HTTPS. כך, Secure Web Proxy יכול להחיל מדיניות אבטחה מתקדמת – כמו סינון כתובות URL בנתיב הבקשה המלא ובדיקת כותרות HTTP – כדי להגן על הסביבה שלכם מפני איומים שמוסתרים בתוך מנהרות מוצפנות.
איך זה עובד
בדיקת TLS פועלת על ידי יצירת שני חיבורים מוצפנים נפרדים, כאשר Secure Web Proxy פועל כמתווך מאובטח.
לחיצת יד של לקוח: כשלקוח מנסה להתחבר לאתר חיצוני, כמו
www.example.com, Secure Web Proxy מיירט את הבקשה.יצירת אישור: Secure Web Proxy יוצר אישור זמני ל-
www.example.comבזמן אמת. בהתאם למצב הנפקת האישורים שהוגדר, שרת ה-proxy מבקש אישורי קצה ישירות משירות ה-CA לכל דומיין, או חותם עליהם באופן מקומי באמצעות אישור ביניים של CA שנשמר במטמון ממאגר ה-CA.אימות האמון: הלקוח מקבל את האישור הזמני.
נקודת בדיקה: תעבורת הנתונים מפוענחת בתוך המכונה של Secure Web Proxy. בשלב הזה, כללי מדיניות האבטחה חלים על נתוני ה-HTTP בטקסט פשוט.
לחיצת יד של השרת: לאחר מכן, Secure Web Proxy יוצר חיבור TLS שני לשרת היעד בפועל. התנועה מוצפנת מחדש ונשלחת לכתובת היעד.
תכונות עיקריות
שירות בדיקת ה-TLS של Secure Web Proxy מציע מסגרת גמישה וניתנת להתאמה לניהול תנועה מוצפנת, באמצעות היכולות הבאות:
אמון פרטי משולב: שילוב מובנה עם CA Service מספק מאגר עם זמינות גבוהה, בניהול Google, לרשויות האישורים הפרטיות שלכם.
שורש אמון גמיש: שימוש ברשות אישורי בסיס (CA) מקומית קיימת כדי לחתום על רשויות אישורים משניות שמתארחות בשירות CA. לאחר מכן תוכלו ליצור ולנהל אישור בסיס חדש לגמרי ישירות ב-CA Service.
פענוח ספציפי: משתמשים ב-
SessionMatcherכדי להגדיר במדויק איזו תנועה לפענח. אפשר להפעיל את בדיקת ה-TLS על סמך הפרמטרים הבאים:- שמות דומיינים של אתרים: התאמה לאתרים ספציפיים באמצעות ביטויים רגולריים ורשימות דומיינים.
- קריטריונים של רשת: טירגוט טווחים ספציפיים של כתובות IP או בלוקי CIDR, כמו
10.0.0.0/24, כדי להגדיר את גבולות הרשת. - לוגיקה בוליאנית: שילוב של כמה תנאים, כמו כתובת IP של מקור וכתובת היעד, כדי ליצור כללי אבטחה ספציפיים מאוד.
ארכיטקטורת מדיניות שניתנת להתאמה:
כללי מדיניות ייעודיים: מקצים מדיניות בדיקת TLS ומאגר רשויות אישורים (CA) ייחודיים לכל מדיניות של Secure Web Proxy כדי לבודד אותם באופן מוחלט.
כללי מדיניות משותפים: מפשטים את ניהול המדיניות על ידי שיתוף של הגדרת בדיקת TLS אחת בין כמה כללי מדיניות של שרתי proxy.
נראות מלאה של מזהה משאבים אחיד (URI): בדיקה של כל ה-URI (כולל הדומיין, הנתיב ומחרוזות השאילתה, כמו
www.example.com/downloads/malware.exe) ולא רק של שם הדומיין.בקרת גישה מדויקת: אפשר להשתמש בבדיקת TLS כדי לאכוף כללי מדיניות בנתיבים ספציפיים של אתר. לדוגמה, אפשר לאשר גישה ל-
www.example.com/documentationאבל לחסום אתwww.example.com/uploads.תמיכה ב-CA ביניים: הפחתת עמלות השימוש ב-CA Service על ידי שמירה במטמון מקומי של CA ביניים יחיד לחתימה על אישורי קצה, במקום לשלוח בקשות לכל דומיין ישירות ל-CA Service. מידע נוסף זמין במאמר מצבי הנפקת אישורים.
התפקיד של רשויות האישורים בבדיקת TLS
כדי לבדוק תנועה מוצפנת, Secure Web Proxy פועל כגורם ביניים מהימן. התהליך הזה כולל תיאום בין שרת ה-proxy, שירות ה-CA והמכשיר של הלקוח.
דרישות בנושא אמון הלקוחות
בדיקת TLS מיועדת לסביבות שבהן לארגון יש אמצעי בקרה לאדמינים על מכשירי הלקוח, כמו מחשבים ניידים, שרתים או מכונות וירטואליות (VM) מנוהלים.
אמון בקונטיינר של הסוכן: כשמנתבים תנועה יוצאת באינטרנט מסוכני AI בקונטיינרים, כמו ב-Cloud Run או ב-Google Kubernetes Engine (GKE), צריך לייצא את אישור ה-CA הבסיסי ממאגר ה-CA או מתשתית המפתח הציבורי (PKI) הפרטית, ולהוסיף אותו למאגר האישורים המהימנים של הקונטיינר. לדוגמה, אתם יכולים להגדיר את סביבת זמן הריצה של הקונטיינר או להגדיר את משתנה הסביבה
AGENT_GATEWAY_ROOT_CERTIFICATESאוSSL_CERT_FILE. מידע נוסף על הגדרת ה-CA ברמה הבסיסית זמין במאמר הגדרת בדיקת TLS בקטע "פריסת Secure Web Proxy בתור Agent Gateway".ישות עוגן אמינה פרטית: מכיוון ש-Secure Web Proxy מציג אישורים שחתומים על ידי רשות האישורים הפנימית שלכם ולא על ידי רשות אישורים ציבורית, הלקוחות סומכים על החיבור רק אם רשות האישורים הבסיסית הפרטית שלכם מותקנת מראש.
היקף הניהול: חיבורים מחומרה לא מנוהלת בדרך כלל מפעילים אזהרות של
Insecure connectionכי במכשירים האלה אין את ישות העוגן האמינה הספציפית של הארגון.
טיפול בכשלים ביירוט
גם במכשירים מנוהלים, אי אפשר ליירט חיבורים מסוימים בגלל הצמדת אישורים. הצמדת אישורים מתרחשת כשאפליקציה מקודדת באופן קשיח כך שהיא מקבלת רק מפתח ציבורי ספציפי או שרשרת ספציפית של רשות אישורים ציבורית.
- דוגמאות להצמדת אישורים: שירותים נפוצים שמשתמשים בהצמדה כוללים עדכוני מערכת של Windows ו-macOS, עדכוני Google Chrome ואפליקציות מסוימות לנייד עם אבטחה גבוהה.
- תוצאה של הצמדת אישורים: כש-Secure Web Proxy מציג את האישור החתום שלו, האפליקציה מזהה שהאישור לא תואם לציפיות שמוגדרות בקוד שלה ומנתקת את החיבור.
הפחתת סיכונים ושליטה מדויקת
כדי למנוע שיבושים בשירות של אפליקציות מוצמדות או כדי לשמור על הפרטיות באתרים רגישים, אתם יכולים להשתמש במאפיין SessionMatcher כדי לעקוף את הבדיקה. אפשר להגביל או לדלג על הבדיקה לפי הפרמטרים הבאים:
- מאפייני יעד: שמות דומיין ספציפיים שמוגדרים במלואם (FQDN).
- מאפייני מקור: תגים מאובטחים, חשבונות שירות או כתובות IP.
- לוגיקה מותאמת אישית: שימוש בביטויים בוליאניים כדי להחריג תנועה ספציפית בזמן בדיקת שאר הסביבה.
מצבי הנפקת אישורים
Secure Web Proxy תומך בשני מצבים להקצאת האישורים שמשמשים לפענוח התנועה במהלך תהליך בדיקת ה-TLS. הבחירה תלויה בדרישות שלכם לגבי עלות, ביצועים ורישום ביומן ביקורת.
מידע נוסף זמין במאמר הגדרת חתימה של רשות אישורים מקומית.
חתימה מקומית של CA ביניים
אם מגדירים את certificateIssuanceMode לערך LOCAL_INTERMEDIATE_CA_SIGNING, Secure Web Proxy מבקש אישור CA אחד של מתווך ממאגר רשויות להנפקת אישורים (CA). שרת ה-proxy שומר במטמון את רשות האישורים המתווכת הזו וחותם על אישורי הקצה הנפרדים באופן מקומי לדומיינים הנדרשים.
אלה המאפיינים של מצב הנפקת אישורי חתימה של רשות אישורים מקומית ברמת ביניים:
עלויות נמוכות יותר של שירות CA: הבקשות לשירות CA מוגבלות למחזור הרענון של ה-CA המתווך (בדרך כלל פעם ביום) ולא מתרחשות בכל דומיין, מה שמוביל לעלויות עסקה נמוכות יותר.
יכולת תצפית מופחתת: אישורי קצה ספציפיים ששרת ה-Proxy חותם עליהם באופן מקומי לא מתועדים ביומני הביקורת של שירות ה-CA.
הקצאה ישירה של אישור קצה
אם מגדירים את certificateIssuanceMode לערך DIRECT_LEAF_PROVISIONING, Secure Web Proxy מתקשר ישירות עם מאגר שירות ה-CA לכל דומיין ייחודי כדי לבקש אישור קצה.
התכונות של מצב הנפקת האישורים "הקצאת הרשאות ישירה של עלה" הן:
יכולת תצפית משופרת: כל בקשה ליצירת אישור מתועדת ביומני הביקורת של שירות CA, וכך אתם יכולים לעקוב אחרי כל הפעילויות ליצירת אישורים ולבצע בהן ביקורת.
עלויות גבוהות יותר של שירות CA: מכיוון שהבקשות נשלחות לשירות CA לכל דומיין, התהליך הזה יכול להוביל לעמלות על עסקאות גבוהות יותר בסביבות שיש בהן כמה דומיינים ייחודיים או משימות פרוקסי.
שיטות להגדרת רשות אישורים
כדי להפעיל בדיקת TLS, צריך להגדיר את רשות האישורים (CA) באחת מהשיטות הבאות:
רשות אישורים משנית ב-CA Service: שימוש ברשות אישורים חיצונית קיימת ברמה הבסיסית כדי לחתום על רשות אישורים משנית שמאוחסנת ב- Google Cloud.
רשות אישורים בסיסית חיצונית: שימוש ברשות אישורים בסיסית חיצונית כדי לחתום על אישורים שנוצרים בזמן הריצה באמצעות רשויות אישורים משניות.
רשות אישורי בסיס בניהול Google: יוצרים אישור בסיס חדש ישירות בתוך שירות ה-CA כדי לחתום על רשויות האישורים המשניות.
למידע נוסף על השיטות האלה, קראו את המאמר יצירת מאגר של רשויות אישורים משניות.