ルールの評価順序

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

  • ルールの優先度: 整数の値が小さいほど優先度が高いことを示します。
  • 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 トンネルを確立できます。これは、クライアントが任意の TCP トラフィックを送信する場合や、HTTPS の場合と同様に、プロキシを介して宛先とのエンドツーエンドの TLS 接続を確立する場合に行われます。

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

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

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

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

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

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

    • TLS インスペクション フラグが有効になっている。
    • トラフィックが SessionMatcher 属性と一致する。

TLS インスペクション ルールの構成に関する推奨事項

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

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 宛てのトラフィックを含むすべてのトラフィックが検査され、優先度の高いルール 1 の request.url() と一致する TLS が検出されます。

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

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

    • 推奨: ルール 1 のスコープを狭めて、github.com ドメインに限定して TLS インスペクションを許可します。スコープを狭めるには、ターゲットを絞った 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）（旧称: Encrypted SNI）を必要としている場合、TLS インスペクションは機能しません。

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

  • クライアントは、非公開ルート証明書を信頼するように構成する必要があります。

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