סדר ההערכה של הכללים

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

• העדיפות של כלל: מספרים שלמים נמוכים יותר מציינים עדיפויות גבוהות יותר.
• ‫SessionMatcher: התאמה למאפיינים הבאים ברמת הסשן:
  • כתובת ה-IP של מכונת המקור
  • חשבון השירות של מכונת המקור
  • תג מאובטח של מכונת המקור
  • שם המארח של מכונת היעד
• ‫ApplicationMatcher: התאמה למאפיינים הבאים של בקשת HTTP:
  • כתובת URL
  • נתיב
  • כותרות של בקשות

רשימה של כל המאפיינים SessionMatcher ו-ApplicationMatcher זמינה במאמר מאפיינים זמינים ב-SessionMatcher וב-ApplicationMatcher.

איך מתבצעת הערכת הכללים

הערכת הכללים מתבצעת לפי הסדר הבא:

1. כללים עם עדיפות גבוהה נבדקים קודם.
2. הכלל בעדיפות הכי גבוהה שתואם למאפיינים SessionMatcher ו-ApplicationMatcher קובע את הפעולה שתתבצע על התנועה.
3. אם הבקשה לא תואמת למאפיינים SessionMatcher ו-ApplicationMatcher של הכלל הזה, המערכת תבדוק את הכלל הבא עם העדיפות הגבוהה ביותר.
4. התהליך הזה נמשך עד שנמצא כלל שתואם לבקשה, או עד שכל הכללים נבדקו. אם לא נמצאת התאמה, הבקשה נדחית.

לפני שמגדירים בדיקת TLS

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

• לקוח יכול לשלוח בקשת HTTP לשרת הפרוקסי. לאחר מכן המערכת מעריכה את הבקשה באמצעות כל הנתונים הזמינים, כולל שם המארח, זהות המקור, כותרות ה-HTTP והנתיב.

  אם הבקשה מורשית, תנועת ה-HTTP נשלחת ליעד. עם זאת, אם הבקשה נדחית, תנועת ה-HTTP לא מורשית לעבור.

• לקוח יכול לשלוח לשרת ה-proxy בקשת HTTP CONNECT כדי ליצור מנהרת TCP ליעד. הפעולה הזו מתבצעת כשהלקוח רוצה לשלוח תנועת TCP שרירותית או ליצור חיבור TLS מקצה לקצה עם היעד דרך ה-proxy, כמו ב-HTTPS.

• אם לכלל יש מאפיין SessionMatcher תואם והוא לא מכיל מאפיין ApplicationMatcher, והערכת הכלל מאפשרת את התעבורה, אז נוצר מנהור ליעד והתעבורה מועברת דרך פרוקסי TCP. ההגדרה הזו חלה על תנועת נתונים ב-HTTPS וב-TCP.

• אם כללים בעדיפות גבוהה יותר לא מצליחים לקבוע את הפעולה שצריך לבצע לגבי בקשה, הערכת הכלל נמשכת. אם ההערכה ממשיכה לכלל עם מאפיין ApplicationMatcher, התנועה המועברת במנהור מתפרשת כ-HTTP או כ-HTTPS.

  אם נתוני הבסיס הם לא HTTP או HTTPS, החיבור ייכשל.

  אם נתוני הבסיס הם HTTP, הבקשות מוערכות, כולל שם המארח, זהות המקור, כותרות HTTP והנתיב. על סמך תוצאת ההערכה, התנועה מאושרת או נדחית.

• בתעבורת HTTPS, כלל נבדק רק אם מופעל בו הדגל של בדיקת TLS. אחרת, המערכת מדלגת על הכלל הזה.

• בתעבורת HTTPS, כלל נבדק רק אם מתקיימים התנאים הבאים:

  • הדגל של בדיקת TLS מופעל.
  • התנועה תואמת למאפייני SessionMatcher.

המלצות להגדרת כללים לבדיקת TLS

• אם רוצים לאפשר תעבורת TCP, הכלל שמאפשר תעבורת TCP צריך להיות בעדיפות גבוהה יותר מהכללים שמאפשרים תעבורת HTTP.
• כדי למזער את הסיכוי שכללים עם מאפיין ApplicationMatcher יפרשו תהליכים לא קשורים כ-HTTP, צריך להגדיר את הכללים כך שיחולו על היקף מצומצם באמצעות המאפיין SessionMatcher.
• כללים שמאפשרים תעבורת TLS (כולל HTTPS) אבל לא מבצעים בדיקת TLS יכולים להתפרש ככללי פרוקסי TCP.
• כדי להימנע מבדיקת TLS מיותרת של תעבורת נתונים, כללי בדיקת TLS צריכים להיות בעדיפות נמוכה יותר מכללי בדיקה שאינם TLS. לחלופין, כדי לזהות במהירות תנועה שלא תואמת, צריך להגדיר את כללי הבדיקה של TLS כך שיהיו מוגבלים באמצעות המאפיין SessionMatcher.

דוגמאות להגדרות של כללי בדיקה של TLS

כדאי לעיין בשני הכללים בדוגמאות הבאות.

דוגמה 1

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

• Rule 1

  description: do not allow POST requests
  priority: 10
  basicProfile: DENY
  sessionMatcher: true
  tlsInspectionEnabled: true
  applicationMatcher: request.method == 'POST'
  

• Rule 2

  description: allow TCP proxying from tag 12345 to example.com
  priority: 20
  basicProfile: ALLOW
  sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'
  

בדוגמה הזו, Secure Web Proxy מפרש את שני הכללים באופן הבא:

• האפשרות לאפשר תנועת TCP אבל לא לאפשר סוג ספציפי של בקשת HTTP מוציאה את עצמה, כי תנועת ה-TCP יכולה להכיל בקשת POST.
• התנועה בכלל 2 אף פעם לא מורשית. הגישה נדחית כי התנועה מתג 12345 אל example.com נחסמת ומפורשת כ-HTTP כדי להעריך את ה-method של ה-HTTP.

• כדי שהכלל השני ייכנס לתוקף, אפשר להשתמש באחד מהפתרונות הבאים:

  • מומלץ: להגדיל את העדיפות של כלל 2 לרמה גבוהה יותר (עדיפות: 5).

  • מגדירים את כלל ההיקף 1 כדי למנוע חפיפה בין התנועה המותרת לבין SessionMatcherהמאפיין שלה:

    sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')

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

דוגמה 2

נבחן את שני הכללים הבאים:

• Rule 1

  description: allow to specific GitHub repository (TLS inspect to match specific path)
  priority: 10
  basicProfile: ALLOW
  sessionMatcher: true
  tlsInspectionEnabled: true
  applicationMatcher: request.url().startsWith('github.com/grpc/grpc')
  

• Rule 2

  description: allow TCP proxying from tag 12345 to example.com
  priority: 20
  basicProfile: ALLOW
  sessionMatcher: host() == 'bankofamerica.com'
  

בדוגמה הזו, Secure Web Proxy מפרש את שני הכללים באופן הבא:

• כל התנועה, כולל התנועה שמיועדת ל-bankofamerica.com, נבדקת כדי לוודא שהיא תואמת ל-TLS של request.url() של כלל 1 בעדיפות גבוהה.

• כדי להימנע מבדיקת TLS בכלל 2, אפשר להשתמש באחד מהפתרונות הבאים:

  • העלאת העדיפות של כלל 2 לרמה גבוהה יותר (עדיפות: 5). כתוצאה מכך, כלל 2 מוחל לפני הערכת כלל 1, והתנועה מ-bankofamerica.com מותרת ללא בדיקת TLS.

  • מומלץ: לצמצם את היקף הכלל 1 כדי לאפשר בדיקת TLS באופן ספציפי לדומיין github.com. כדי לצמצם את ההיקף, מוסיפים מאפיין sessionMatcher לטירגוט:

    sessionMatcher: host() == 'github.com'

מגבלות

חשוב לקחת בחשבון את המגבלות האלה לפני שמגדירים בדיקת TLS:

• השרתים מאומתים רק באמצעות אישורי בסיס ציבוריים. קבוצת רשויות האישורים (CA) הבסיסיות מבוססת על Mozilla Root Program. ההתנהגות של אימות האישורים עשויה להשתנות, והיא תואמת לאופן שבו דפדפני אינטרנט מאמתים אישורים.

  בגלל שאי אפשר לבצע אימות בקצה העורפי בשלב הזה, אי אפשר ליירט תעבורה לשרתים עם אישורים פרטיים או עם אישורים בחתימה עצמית.

• ‫Secure Web Proxy לא מריץ בדיקות של רשימת האישורים שבוטלו (CRL).

• כדי שבדיקת TLS תפעל, הלקוחות צריכים לשלוח כרגע את Server Name Indication ‏ (SNI). ‫SNI הוא תוסף אופציונלי למפרט TLS, אבל רוב הלקוחות מפעילים אותו כברירת מחדל.

• בדיקת TLS לא פועלת אם הלקוח דורש הצפנה של Client Hello‏ (ECH) (שנקראה בעבר הצפנה של SNI).

  ECH הוא טיוטת תקן IETF שמאפשרת ללקוחות להצפין את תחילת לחיצת היד ב-TLS באמצעות מפתח שרת שהוגדר מראש. מכיוון שבדיקת TLS פועלת כשרת proxy מיירט, אין לה גישה למפתח השרת שנוצר מראש. כתוצאה מכך, ECH לא פועל.

• צריך להגדיר את הלקוחות כך שיאמתו את אישור הבסיס הפרטי שלכם.

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