ルールの評価では、ポリシーで設定したルールを使用して、ウェブ リクエストを許可するか拒否するかを決定します。次の属性を考慮して判断します。
- ルールの優先度: 小さい整数が高い優先度を示します。
- SessionMatcher: 次のセッション レベルの属性と照合します。
- ソースマシンの IP アドレス
- ソースマシンのサービス アカウント
- ソースマシンのセキュアタグ
- ターゲット マシンのホスト名
- ApplicationMatcher: 次の HTTP リクエストの
- 属性と照合します。
- URL
- パス
- リクエスト ヘッダー
すべての SessionMatcher
属性と ApplicationMatcher
属性のリストについては、SessionMatcher
と ApplicationMatcher
で使用可能な属性をご覧ください。
ルール評価の仕組み
ルールは以下の順序で評価されます。
- 優先度の高いルールが最初に評価されます。
SessionMatcher
属性とApplicationMatcher
属性に一致する最も優先度の高いルールによって、トラフィックに対して実行されるアクションが決まります。- リクエストがそのルールの
SessionMatcher
属性とApplicationMatcher
属性と一致しない場合は、優先度が最も高い次のルールが評価されます。 - このプロセスは、リクエストに一致するルールが見つかるか、すべてのルールが評価されるまで続きます。一致が見つからない場合、リクエストは拒否されます。
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'
- ルール 2 の優先度を高いレベル(優先度: 5)に増やします。その結果、ルール 1 を評価する前にルール 2 が適用され、
制限事項
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 は新しい証明書を強制的に生成する必要があります。