規則評估順序

規則評估會根據您在政策中設定的規則，判斷是否應允許或拒絕網路要求。系統會根據下列屬性做出決策：

• 規則的優先順序：整數值越小，優先順序就越高。
• SessionMatcher：與下列工作階段層級屬性相符：
  • 來源機器的 IP 位址
  • 來源機器的服務帳戶
  • 來源機器的安全標記
  • 目標機器的主機名稱
• ApplicationMatcher：比對下列 HTTP 要求屬性：
  • 網址
  • 路徑
  • 要求標頭

如需所有 SessionMatcher 和 ApplicationMatcher 屬性的清單，請參閱「SessionMatcher 和 ApplicationMatcher 中可用的屬性」。

規則評估的運作方式

系統會按照下列順序評估規則：

1. 系統會先評估優先順序較高的規則。
2. 優先順序最高且符合 SessionMatcher 和 ApplicationMatcher 屬性的規則，會決定要對流量採取的動作。
3. 如果要求不符合該規則的 SessionMatcher 和 ApplicationMatcher 屬性，系統會評估優先順序最高的下一個規則。
4. 這個程序會持續執行，直到找到符合要求的規則，或已評估所有規則為止。如果找不到相符項目，系統會拒絕要求。

設定 TLS 檢查功能之前

您必須先瞭解下列規則評估情境，再設定 TLS 檢查功能：

• 用戶端可以將 HTTP 要求傳送至 Proxy 伺服器。系統會使用所有可用資料 (包括主機名稱、來源身分、HTTP 標頭和路徑) 評估要求。

  如果要求獲准，HTTP 流量就會傳送至目的地。不過，如果要求遭到拒絕，則不允許 HTTP 流量通過。

• 用戶端可以向 Proxy 傳送 HTTP CONNECT 要求，藉此建立前往目的地的 TCP 通道。當用戶端想要傳送任意 TCP 流量，或透過 Proxy 與目的地建立端對端 TLS 連線時，就會執行這項操作，就像 HTTPS 一樣。

• 如果規則含有相符的 SessionMatcher 屬性，且不含 ApplicationMatcher 屬性，且規則評估結果為允許流量，則會建立通往目的地的通道，並為流量提供 TCP 代理程式。這項規定適用於 HTTPS 和 TCP 流量。

• 如果優先順序較高的規則無法判斷應對要求採取哪項動作，則會繼續進行規則評估。如果評估作業繼續執行至具有 ApplicationMatcher 屬性的規則，則會將建立通道的流量解讀為 HTTP 或 HTTPS。

  如果基礎資料不是 HTTP 或 HTTPS，連線就會失敗。

  如果底層資料為 HTTP，系統會評估要求，包括主機名稱、來源識別資訊、HTTP 標頭和路徑。系統會根據評估結果允許或拒絕流量。

• 針對 HTTPS 流量，只有在啟用 TLS 檢查標記時，系統才會評估規則；否則，系統會略過該規則。

• 針對 HTTPS 流量，只有在符合下列條件時才會檢查規則：

  • 已啟用 TLS 檢查標記。
  • 流量符合 SessionMatcher 屬性。

設定 TLS 檢查規則的建議

• 如果您想允許 TCP 流量，則允許 TCP 流量的規則優先順序必須高於允許 HTTP 流量的規則。
• 使用 SessionMatcher 屬性，可將含有 ApplicationMatcher 屬性的規則納入嚴格範圍，盡量避免將不相關的流量解讀為 HTTP。
• 允許 TLS (包括 HTTPS) 流量但不執行 TLS 檢查的規則，可解讀為 TCP Proxy 規則。
• 為避免對流量進行不必要的 TLS 檢查，TLS 檢查規則的優先順序應低於非 TLS 檢查規則。或者，如要針對不相符的流量快速失敗，請使用 SessionMatcher 屬性，將 TLS 檢查規則的範圍嚴格限制。

TLS 檢查規則設定範例

請參考以下兩個範例中的規則。

範例 1

在本例中，我們假設有其他優先順序較低的規則。請考慮下列兩個規則：

• 規則 1

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

• 規則 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，以便評估 HTTP 方法。

• 如要讓規則 2 生效，您可以使用下列任一解決方案：

  • 建議做法：將規則 2 的優先順序調高至更高層級 (優先順序：5)。

  • 範圍規則 1，避免允許的流量與其 SessionMatcher 屬性重疊：

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

    我們不建議採用這個解決方案，因為這會導致許多重疊的規則難以維護。

範例 2

請考慮下列兩個規則：

• 規則 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')
  

• 規則 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 檢查，以便與高優先順序規則 1 的 request.url() 相符。

• 如要避免在規則 2 中進行 TLS 檢查，您可以使用下列任一解決方案：

  • 將規則 2 的優先順序提高至更高層級 (優先順序：5)。因此，系統會在評估規則 1 之前套用規則 2，並允許來自 bankofamerica.com 的流量，而無須進行 TLS 檢查。

  • 建議做法：縮小規則 1 的範圍，只允許針對 github.com 網域進行 TLS 檢查。如要縮小範圍，請新增指定的 sessionMatcher 屬性：

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

限制

設定 TLS 檢查功能前，請務必考量下列限制：

• 伺服器只能使用公開根憑證進行驗證。根憑證授權單位 (CA) 組合是根據 Mozilla 根計畫建立。憑證驗證的行為可能會有所變動，並與網路瀏覽器驗證憑證的方式相對應。

  由於目前無法進行後端驗證，因此無法攔截使用私人或自行簽署憑證的伺服器流量。

• Secure Web Proxy 不會執行憑證撤銷清單 (CRL) 檢查。

• 如要讓 TLS 檢查功能正常運作，用戶端目前必須傳送伺服器名稱指示 (SNI)。SNI 是 TLS 規格擴充功能，可視情況使用，但大多數用戶端會預設啟用。

• 如果用戶端需要加密的 ClientHello (ECH) (舊稱加密的 SNI)，TLS 檢查功能就無法運作。

  ECH 是 IETF 標準草案，可讓用戶端使用預先建立的伺服器金鑰，加密 TLS 握手程序的開頭。由於 TLS 檢查會充當攔截 Proxy，因此無法存取先前建立的伺服器金鑰。因此 ECH 無法運作。

• 您必須將用戶端設為信任私人根憑證。

• 如果您從私人 CA 集區中移除 CA，系統最多會在 28 小時內提供該 CA 簽署的快取憑證。如要避免使用快取的憑證，您可以更新 TLS 檢查政策，將其指向新的 CA 集區。因此，Secure Web Proxy 會被迫產生新的憑證。