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

‫Cloud Next Generation Firewall ‏ (Cloud NGFW) מציע שירות של יירוט ופענוח של 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 שם סט אלגוריתמים להצפנה (cipher suite)
    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 לכל אזור שבו מפעילים את בדיקת ה-TLS.

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת TLS באמצעות מאזני עומסים פנימיים

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

מאחר שמאזן העומסים מפענח את התנועה לפני הבדיקה בשכבת האפליקציה, קורה הדבר הבא:

  • השיוך של נקודת הקצה של חומת האש מתעלם מהדגל --tls-inspection-policy שציינתם לטירגוט תנועה למאזן העומסים.
  • כללי מדיניות חומת האש מתעלמים מכל דגל --tls-inspect כשמגדירים את --target-type ל-INTERNAL_MANAGED_LB.

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

מגבלות

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