התנועה המוצפנת באמצעות 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 מתקשר עם Certificate Authority Service הפרטית. הפרוקסי יוצר אישור זמני עבור
www.example.comבזמן אמת, שנחתם על ידי רשות האישורים המשנית הפרטית של הארגון.אימות מהימן: הלקוח מקבל את האישור הזמני.
נקודת הבדיקה: תעבורת הנתונים מפוענחת בתוך מופע 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.
התפקיד של רשויות אישורים בבדיקת TLS
כדי לבדוק תנועה מוצפנת, Secure Web Proxy פועל כמתווך מהימן. התהליך הזה כולל תיאום בין ה-proxy, שירות ה-CA ומכשיר הלקוח.
דרישות בנושא אמון הלקוחות
בדיקת TLS מיועדת לסביבות שבהן לארגון יש שליטה אדמיניסטרטיבית במכשירי הלקוח, כמו מחשבים ניידים מנוהלים, שרתים או מכונות וירטואליות (VM).
- עוגן אמון פרטי: מכיוון ש-Secure Web Proxy מציג אישורים שחתומים על ידי רשות אישורים פנימית ולא על ידי רשות אישורים ציבורית, הלקוחות יסמכו על החיבור רק אם רשות האישורים הבסיסית הפרטית שלכם מותקנת מראש.
- היקף אדמיניסטרטיבי: חיבורים מציוד לא מנוהל בדרך כלל מפעילים אזהרות
Insecure connectionכי למכשירים האלה אין עוגן אמון ספציפי של הארגון.
טיפול בכשלים ביירוט
גם במכשירים מנוהלים, לא ניתן ליירט חיבורים מסוימים בגלל הצמדת אישורים. הצמדת אישורים מתרחשת כשמגדירים באפליקציה קידוד קשיח כך שהיא תקבל רק מפתח ציבורי ספציפי או שרשרת ספציפית של רשות אישורים ציבורית.
- דוגמאות לקיבוע אישורים: שירותים נפוצים שמשתמשים בקיבוע כוללים עדכוני מערכת של Windows ו-macOS, עדכונים של Google Chrome ואפליקציות מסוימות לנייד עם רמת אבטחה גבוהה.
- התוצאה של הצמדת אישורים: כש-Secure Web Proxy מציג את האישור החתום שלו, האפליקציה מזהה שהאישור לא תואם לציפיות המקודדות שלה ומנתקת את החיבור.
צמצום הפגיעה ושליטה מדויקת
כדי למנוע שיבושים בשירותים של אפליקציות מוצמדות או כדי לשמור על הפרטיות באתרים רגישים, אפשר להשתמש במאפיין SessionMatcher כדי לעקוף את הבדיקה. אפשר להגביל את הבדיקה או לדלג עליה על סמך הפרמטרים הבאים:
- מאפייני יעד: שמות דומיין ספציפיים שמוגדרים במלואם (FQDN).
- מאפייני מקור: תגים מאובטחים, חשבונות שירות או כתובות IP.
- לוגיקה מותאמת אישית: שימוש בביטויים בוליאניים כדי להחריג תנועה ספציפית תוך בדיקת שאר הסביבה.
שיטות להגדרת רשות אישורים
כדי להפעיל בדיקת TLS, צריך להגדיר את רשות האישורים (CA) באמצעות אחת מהשיטות הבאות:
רשות אישורים (CA) משנית בשירות CA: שימוש ברשות אישורים (CA) חיצונית קיימת ברמה הבסיסית כדי לחתום על רשות אישורים (CA) משנית שמאוחסנת ב- Google Cloud.
רשות אישורים (CA) חיצונית בסיסית: משתמשים ברשות אישורים חיצונית בסיסית כדי לחתום על אישורים שנוצרים בזמן הריצה באמצעות רשויות אישורים משניות.
רשות אישורים (CA) בסיסית בניהול Google: יצירת אישור בסיסי חדש ישירות ב-CA Service כדי לחתום על רשויות אישורים משניות.
למידע נוסף על השיטות האלה, קראו את המאמר בנושא יצירת מאגר של רשויות אישורים משניות.