התנועה המוצפנת באמצעות 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. לאחר מכן תוכלו ליצור ולנהל אישור בסיס חדש לגמרי ישירות בשירות CA.
פענוח ספציפי: משתמשים ב-
SessionMatcherכדי להגדיר בדיוק איזה תעבורה לפענח. אפשר להפעיל את הבדיקה של TLS על סמך הפרמטרים הבאים:- שמות דומיינים של אתרים: התאמה לאתרים ספציפיים באמצעות ביטויים רגולריים ורשימות של דומיינים.
- קריטריונים לרשת: טירגוט של טווחי כתובות IP ספציפיים או בלוקים של Classless Inter-Domain Routing (CIDR), כמו
10.0.0.0/24, כדי להגדיר גבולות לרשת. - לוגיקה בוליאנית: אפשר לשלב כמה תנאים – כמו כתובת IP של מקור וכתובת היעד – כדי ליצור כללי אבטחה ספציפיים מאוד.
ארכיטקטורת מדיניות שניתנת להתאמה:
מדיניות ייעודית: הקצאת מדיניות ייחודית לבדיקת TLS ומאגר רשויות אישורים לכל מדיניות של Secure Web Proxy לצורך בידוד קפדני.
כללי מדיניות משותפים: מאפשרים לנהל את המדיניות בצורה פשוטה יותר על ידי שיתוף של הגדרת בדיקה אחת של TLS בין כמה כללי מדיניות של שרת proxy.
חשיפה מלאה של מזהה משאב אחיד (URI): בדיקה של ה-URI כולו (כולל הדומיין, הנתיב ומחרוזות השאילתה, כמו
www.example.com/downloads/malware.exe) ולא רק של שם הדומיין.בקרת גישה מדויקת: אפשר להשתמש בבדיקת TLS כדי לאכוף מדיניות עבור נתיבים ספציפיים באתר. לדוגמה, אפשר לאפשר גישה ל-
www.example.com/documentationולחסום את הגישה ל-www.example.com/uploads.תמיכה ב-CA ביניים: אפשר להפחית את עמלות השימוש בשירות CA על ידי שמירת מטמון מקומי של CA ביניים יחיד לחתימה על אישורי עלים, במקום להנפיק בקשות לכל דומיין ישירות לשירות CA. מידע נוסף זמין במאמר בנושא מצבי הנפקת אישורים.
תפקיד רשויות האישורים בבדיקת TLS
כדי לבדוק תנועה מוצפנת, Secure Web Proxy פועל כמתווך מהימן. התהליך הזה כולל תיאום בין ה-proxy, שירות ה-CA ומכשיר הלקוח.
דרישות בנושא אמון הלקוחות
בדיקת TLS מיועדת לסביבות שבהן לארגון יש שליטה אדמיניסטרטיבית במכשירי הלקוח, כמו מחשבים ניידים מנוהלים, שרתים או מכונות וירטואליות (VM).
- עוגן אמון פרטי: מכיוון ש-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. הפרוקסי שומר במטמון את רשות האישורים המנפיקה הזו וחותם על אישורי העלה הנפרדים באופן מקומי עבור הדומיינים הנדרשים.
התכונות של מצב הנפקת אישורי חתימה של CA מקומיים ברמת הביניים הן:
עלויות נמוכות יותר של CA Service: הבקשות ל-CA Service מוגבלות למחזור הרענון של רשות האישורים הביניים (בדרך כלל פעם ביום) ולא מתרחשות עבור כל דומיין, ולכן עלויות העסקאות נמוכות יותר.
צמצום יכולת הצפייה: אישורים פרטניים של עלים שהפרוקסי חותם באופן מקומי לא נרשמים ביומני הביקורת של CA Service.
הקצאת אישורי קצה ישירה
אם מגדירים את certificateIssuanceMode ל-DIRECT_LEAF_PROVISIONING, Secure Web Proxy מתקשר ישירות עם מאגר שירותי ה-CA לכל דומיין ייחודי כדי לבקש אישור עלים.
התכונות של מצב הנפקת האישורים הישיר של עלה הם כדלקמן:
יכולת מעקב משופרת: כל בקשה ליצירת אישור מתועדת ביומני הביקורת של שירות רשות האישורים, כך שאתם יכולים לעקוב אחרי כל הפעילויות שקשורות ליצירת אישורים ולבדוק אותן.
עלויות גבוהות יותר של CA Service: מכיוון שבכל דומיין נשלחות בקשות ל-CA Service, התהליך הזה עלול להוביל לעלויות גבוהות יותר של עמלות עסקה בסביבות שיש בהן כמה דומיינים ייחודיים או משימות פרוקסי.
שיטות להגדרת רשות אישורים
כדי להפעיל בדיקת TLS, צריך להגדיר את רשות האישורים (CA) באמצעות אחת מהשיטות הבאות:
רשות אישורים (CA) משנית בשירות CA: שימוש ברשות אישורים (CA) חיצונית קיימת ברמה הבסיסית כדי לחתום על רשות אישורים (CA) משנית שמאוחסנת ב- Google Cloud.
רשות אישורים (CA) חיצונית בסיסית: משתמשים ברשות אישורים חיצונית בסיסית כדי לחתום על אישורים שנוצרים בזמן הריצה באמצעות רשויות אישורים משניות.
רשות אישורים (CA) בסיסית בניהול Google: יצירת אישור בסיסי חדש ישירות ב-CA Service כדי לחתום על רשויות אישורים משניות.
למידע נוסף על השיטות האלה, קראו את המאמר בנושא יצירת מאגר של רשויות אישורים משניות.