ルールの評価順序

ルールの評価では、ポリシーで設定したルールを使用して、ウェブ リクエストを許可するか拒否するかを決定します。次の属性を考慮して判断します。

  • ルールの優先度: 小さい整数が高い優先度を示します。
  • SessionMatcher: 次のセッション レベルの属性と照合します。
    • ソースマシンの IP アドレス
    • ソースマシンのサービス アカウント
    • ソースマシンのセキュアタグ
    • ターゲット マシンのホスト名
  • ApplicationMatcher: 次の HTTP リクエストの
      属性と照合します。
    • URL
    • パス
    • リクエスト ヘッダー

すべての SessionMatcher 属性と ApplicationMatcher 属性のリストについては、SessionMatcher と ApplicationMatcher で使用可能な属性をご覧ください。

ルール評価の仕組み

ルールは以下の順序で評価されます。

  1. 優先度の高いルールが最初に評価されます。
  2. SessionMatcher 属性と ApplicationMatcher 属性に一致する最も優先度の高いルールによって、トラフィックに対して実行されるアクションが決まります。
  3. リクエストがそのルールの SessionMatcher 属性と ApplicationMatcher 属性と一致しない場合は、優先度が最も高い次のルールが評価されます。
  4. このプロセスは、リクエストに一致するルールが見つかるか、すべてのルールが評価されるまで続きます。一致が見つからない場合、リクエストは拒否されます。

TLS 検査を構成する前

TLS 検査を構成する前に、次のルール評価シナリオを理解する必要があります。

  • クライアントはプロキシ サーバーに HTTP リクエストを送信できます。その後、ホスト名、ソース ID、HTTP ヘッダー、パスなど、使用可能なすべてのデータを使用してリクエストが評価されます。

    リクエストが許可されている場合、HTTP トラフィックは宛先に送信されます。ただし、リクエストが拒否された場合、HTTP トラフィックは通過できません。

  • クライアントは HTTP CONNECT リクエストをプロキシに送信して、宛先への TCP トンネルを確立できます。これは、クライアントが HTTPS と同様に、プロキシ経由で任意の TCP トラフィックを送信するか、プロキシ経由で宛先とのエンドツーエンドの TLS 接続を確立しようとするときに行われます。

  • ルールの SessionMatcher 属性が一致し、ApplicationMatcher 属性が含まれていない場合、ルールの評価によりトラフィックが許可されます。宛先へのトンネルが確立され、トラフィックが TCP プロキシされる。これは HTTPS と TCP のトラフィックに適用されます。

  • 優先度の高いルールで、リクエストに対して実行されるアクションを決定できない場合、ルールの評価が続行されます。評価が ApplicationMatcher 属性を含むルールに進むと、トンネリングされたトラフィックが HTTP または HTTPS として解釈されます。

    基になるデータが HTTP または HTTPS でない場合、接続は失敗します。

    基になるデータが HTTP の場合は、ホスト名、ソース ID、HTTP ヘッダー、パスなど、リクエストが評価されます。評価結果に基づいて、トラフィックは許可または拒否されます。

  • HTTPS トラフィックの場合、TLS 検査フラグが有効になっている場合にのみルールが評価されます。それ以外の場合は、そのルールはスキップされます。

  • HTTPS トラフィックの場合、次の条件が満たされる場合にのみ、ルールが検査されます。

    • TLS 検査フラグが有効になっています。
    • トラフィックは SessionMatcher 属性と一致します。

TLS 検査ルールの構成に関する推奨事項

  • TCP トラフィックを許可するルールには、HTTP トラフィックを許可するルールよりも高い優先度の TCP トラフィックを許可する必要があります。
  • ApplicationMatcher 属性を含むルールは、SessionMatcher 属性を使用して厳密にスコープを限定し、無関係なフローの HTTP としての解釈を最小限に抑える必要があります。
  • TLS（HTTPS を含む）トラフィックを許可するが TLS 検査を実行しないルールは、TCP プロキシ ルールとして解釈できます。
  • トラフィックの不要な TLS 検査を回避するため、TLS 検査ルールは TLS 以外の検査ルールよりも優先度を低くする必要があります。または、一致しないトラフィックに対してフェイル ファストを行うには、TLS 検査ルールのスコープを SessionMatcher 属性で厳密に設定する必要があります。

TLS 検査ルールの構成例

以下の例で、2 つのルールについて考えてみます。

例 1

この例では、その他の優先度の低いルールが存在することを前提としています。次の 2 つのルールを検討します。

  • ルール 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 は次のように 2 つのルールを解釈します。

  • TCP トラフィックを許可するが、特定の種類の HTTP リクエストを禁止すると、相互に排他的です。これは、TCP トラフィックには POST リクエストが含まれる可能性があるためです。
  • ルール 2 のトラフィックは許可されません。タグ 12345 から example.com へのトラフィックは、インターセプトされて HTTP として解釈され、HTTP メソッドを評価するため拒否されます。

  • ルール 2 を有効にするには、次のいずれかのソリューションを使用します。

    • 推奨: ルール 2 の優先度を高くします（優先度: 5）。

    • 許可されたトラフィックを SessionMatcher 属性と重複しないようにルール 1 を設定します。

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

      このソリューションでは、重複するルールを多く維持することが難しいため、おすすめしません。

例 2

次の 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 は次のように 2 つのルールを解釈します。

  • bankofamerica.com 宛てのトラフィックを含むすべてのトラフィックで、TLS が検査され、優先度の高いルール 1 の request.url() と照合されます。

  • ルール 2 で TLS インスペクションを回避するには、次のいずれかの方法を使用します。

    • ルール 2 の優先度を高いレベル（優先度: 5）に増やします。その結果、ルール 1 を評価する前にルール 2 が適用され、bankofamerica.com からのトラフィックは TLS 検査なしで許可されます。

    • 推奨: github.com ドメイン専用の TLS 検査を許可するには、ルール 1 の範囲を絞り込みます。スコープを絞り込むには、対象の sessionMatcher 属性を追加します。

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

制限事項

TLS 検査を構成する前に、次の制限事項を考慮する必要があります。

  • サーバーは公開ルート証明書でのみ検証されます。ルート認証局（CA）のセットは、Mozilla Root Program に基づいています。証明書の検証動作は変更される場合があり、ウェブブラウザによる証明書の検証方法に対応しています。

    現時点では、バックエンドの検証はできないため、非公開証明書または自己署名証明書を使用したサーバーへのトラフィックはインターセプトできません。

  • Secure Web Proxy では、証明書失効リスト（CRL）のチェックは実行されません。

  • TLS 検査が機能するためには、クライアントは現在、Server Name Indication（SNI）を送信する必要があります。SNI は TLS 仕様の拡張オプションですが、ほとんどのクライアントではデフォルトで有効になっています。

  • クライアントに Encrypted Client Hello（ECH）（旧称 暗号化された SNI）が必要な場合、TLS 検査は機能しません。

    ECH は IETF のドラフト標準であり、確立済みのサーバーキーを使用してクライアントが TLS handshake の開始を暗号化できます。TLS 検査はインターセプト プロキシとして機能するため、事前に確立されたサーバーキーにはアクセスできません。そのため、ECH は機能しません。

  • クライアントは、プライベート ルート証明書を信頼するように構成されている必要があります。

  • プライベート CA プールから CA を削除すると、その CA によって署名されたキャッシュ済み証明書が最大 28 時間提供されます。キャッシュ内の証明書の使用を防ぐには、新しい CA プールを指すように TLS 検査ポリシーを更新します。その結果、Secure Web Proxy は新しい証明書を強制的に生成する必要があります。