סקירה כללית של בדיקת TLS

‫Cloud Next Generation Firewall מציע שירות של יירוט והצפנה של Transport Layer Security‏ (TLS) שיכול לבדוק תעבורה מוצפנת ולא מוצפנת כדי לזהות מתקפות ושיבושים ברשת. חיבורי TLS נבדקים בחיבורים נכנסים ויוצאים, כולל תנועה אל האינטרנט וממנו ותנועה בתוך Google Cloud.

‫Cloud NGFW מבצע פענוח של תעבורת ה-TLS כדי לאפשר לנקודת הקצה של חומת האש לבצע בדיקה של Layer 7, כמו שירות סינון כתובות URL ושירות גילוי חדירות ומניעתן ברשת. אחרי הבדיקה, Cloud NGFW מצפין מחדש את התנועה לפני שהוא שולח אותה ליעד שלה.

‫Cloud NGFW משתמש ב-Certificate Authority Service‏ (CAS) בניהול Google כדי ליצור אישורי ביניים לטווח קצר. ‫Cloud NGFW משתמש באישורים הביניים האלה כדי ליצור את האישורים שנדרשים לפענוח התנועה שיירטה. אתם מגדירים מאגרי רשויות אישורים (CA), ואם רוצים, גם הגדרות אמון, כדי לאחסן ולתחזק רשימה של אישורי CA מהימנים.

בדף הזה מופיעה סקירה מפורטת של יכולות הבדיקה של TLS ב-Cloud NGFW.

מפרטים

  • ‫Cloud NGFW תומך בפרוטוקול TLS בגרסאות 1.0,‏ 1.1,‏ 1.2 ו-1.3.

  • ‫Cloud NGFW תומך בסטים הבאים של אלגוריתמים להצפנה (cipher suite) של TLS:

    ערך IANA שם סט האלגוריתמים להצפנה
    0xCCA9 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    0xCCA8 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    0xC02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    0xC02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    0xC02C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    0xC030 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    0xC009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    0xC013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    0xC00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    0xC014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    0x009C TLS_RSA_WITH_AES_128_GCM_SHA256
    0x009D TLS_RSA_WITH_AES_256_GCM_SHA384
    0x002F TLS_RSA_WITH_AES_128_CBC_SHA
    0x0035 TLS_RSA_WITH_AES_256_CBC_SHA
    0x000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

  • ‫Cloud NGFW משתמש במדיניות בדיקת TLS כדי להגדיר בדיקת TLS בנקודת קצה של חומת אש.

    אתם מגדירים מאגרי CA ואופציונלית, הגדרות אמון כדי ליצור אישורי TLS מהימנים עבור לקוחות TLS. לחלופין, אפשר גם להגדיר הגדרות אמון כדי לאחסן ולתחזק אישורי CA מהימנים. אתם כוללים את פרטי ההגדרה של מאגרי CA והגדרות מהימנות במדיניות בדיקת TLS. לאחר מכן המדיניות מצורפת לנקודת הקצה של חומת האש ולרשת הענן הווירטואלי הפרטי (VPC) שהיא היעד, ומשמשת לפענוח התנועה שרוצים לבדוק.

    מידע נוסף על הגדרת בדיקת TLS ב-Cloud NGFW זמין במאמר בנושא הגדרת בדיקת TLS.

  • מדיניות בדיקת TLS ומאגר רשויות אישורים הם משאבים אזוריים. לכן, צריך ליצור מאגר CA ומדיניות בדיקת TLS לכל אזור שבו מפעילים בדיקת TLS.

  • אם אתם רוצים להשתמש בהגדרות אמון במדיניות הבדיקה של TLS, ודאו שהגדרות האמון ומדיניות הבדיקה של TLS נמצאות באותו אזור.

התפקיד של רשות האישורים בבדיקת TLS

‫Cloud NGFW מיירט תנועת TLS על ידי יצירת אישורים באופן דינמי עבור לקוחות. האישורים האלה נחתמים על ידי רשויות אישורים ברמת ביניים (intermediate) שמוגדרות בנקודת הקצה של חומת האש. רשויות האישורים הביניים האלה חתומות על ידי מאגרי רשויות אישורים בתוך שירות CA. ‫Cloud NGFW יוצר רשויות אישורים (CA) חדשות לביניים כל 24 שעות.

בכל פעם שלקוח יוצר חיבור TLS, ‏ Cloud NGFW מיירט את החיבור ויוצר אישור לשם השרת המבוקש כדי להחזיר אותו ללקוח. בנוסף, Cloud NGFW יכול לאמת אישורים של קצה עורפי שחתומים באופן פרטי באמצעות הגדרת אמון. אפשר להוסיף אישורים מהימנים להגדרת אמון ב-Certificate Manager.

מוסיפים הגדרות אמון והגדרות של מאגר רשויות אישורים למדיניות בדיקת TLS. לאחר מכן, המדיניות הזו מתווספת לשיוך של נקודת קצה לחומת אש ומשמשת לפענוח התנועה שירטה.

רשויות האישורים שמאוחסנות ב-CA Service מגובות על ידי מודול אבטחה לחומרה (HSM) ויוצרות יומני ביקורת בכל שימוש.

רשויות אישורים ברמת ביניים (intermediate) לטווח קצר שנוצרות על ידי Cloud NGFW מאוחסנות רק בזיכרון. כל אישור שרת שנחתם על ידי רשות אישורים ברמת ביניים לא יוצר יומן ביקורת משירות ה-CA. בנוסף, מכיוון שאישורי השרת לא נוצרים ישירות על ידי שירות ה-CA, כל מדיניות הנפקה או אילוצי שם שהוגדרו במאגר ה-CA לא חלים על אישורי השרת שנוצרו על ידי Cloud NGFW. ‫Cloud NGFW לא אוכף את המגבלות האלה כשיוצרים אישורים לשרת באמצעות רשויות אישורים ברמת ביניים.

דגל --tls-inspect של כלל מדיניות חומת אש

כדי להפעיל את הפענוח של התנועה שתואמת לכללים של מדיניות חומת האש שהוגדרה, משתמשים בדגל --tls-inspect. כשמגדירים את הדגל --tls-inspect בכלל של מדיניות חומת האש, Cloud NGFW יוצר אישור שרת חדש לתעבורת TLS תואמת. רשויות אישורים (CA) ביניים ב-Cloud NGFW חותמות על האישור הזה. רשויות אישורים ביניים אלה נחתמות בתורן על ידי מאגרי רשויות אישורים בתוך CA Service. האישור הזה מוצג ללקוח, ונוצר חיבור TLS. האישור שנוצר נשמר במטמון לזמן קצר כדי לאפשר חיבורים עתידיים לאותו מארח.

בדיקת TLS בחיבור HTTP

‫Cloud NGFW תומך ביירוט ובפענוח של TLS בתעבורת HTTPS יוצאת של לקוח באמצעות HTTP Connect.

לדוגמה, נניח שלקוח שולח בקשת HTTP Connect כדי ליצור מנהרה מאובטחת בין הלקוח לשרת באמצעות שרת proxy אינטרנט ביניים, כמו Secure Web Proxy. אחרי יצירת המנהרה, Cloud NGFW מיירט ומפענח כל תעבורת נתונים יוצאת באינטרנט עם TLS שעוברת דרך המנהרה, ומבצע בדיקה של Layer 7 כמו זיהוי ומניעה של חדירות.

מגבלות

  • ‫Cloud Next Generation Firewall Enterprise לא תומך בתנועה של HTTP/2,‏ QUIC,‏ HTTP/3 או פרוטוקול PROXY עם בדיקת TLS. עם זאת, בדיקת TLS נתמכת בתעבורת TCP שלא מבוססת על HTTPS.

  • ‫Cloud NGFW Enterprise תומך רק בפענוח TLS. הוא לא תומך בפענוח של תנועת נתונים שנעשה בה שימוש בפרוטוקולי הצפנה אחרים, כמו SSH.

המאמרים הבאים