Secure Web Proxy のポリシーとルールは、下り（外向き）ウェブ トラフィックのセキュリティ戦略の基盤となります。これらは、ソース ID（サービス アカウントやセキュアタグなど）と宛先属性（URL リストなど）に基づいてリクエストを許可または 拒否することで、ウェブ トラフィックを正確に制御します。これらのセキュリティ ポリシーとルールを使用して、承認されたトラフィックのみがネットワークから送信されるようにすることができます。
このページでは、ポリシーを定義し、ウェブ以外の TCP 接続を含むトラフィックを制御する特定のルールを構造化し、ソース ID と宛先属性に基づいてきめ細かいセキュリティを適用する方法について説明します。
ポリシーの概要
Secure Web Proxy ポリシーは、すべての下り（外向き）ウェブ トラフィックのアクセス制御を定義するコア セキュリティ アイテムです。Secure Web Proxy ポリシーの主な機能は次のとおりです。
ポリシー制御: ポリシーには、プロキシがウェブ リクエストを許可するか拒否するかを判断するために使用する一連の命令 （Secure Web Proxy ルール）が保存されます。
デフォルトで安全: Secure Web Proxy ポリシーは、
deny-allデフォルトです。つまり、許可する特定のルールを作成するまで、プロキシはすべてのリクエスト（HTTP/S）をブロックし、ゼロトラスト アーキテクチャを最初から適用します。ポリシー ロジック: すべてのポリシーは、トラフィック ソースの特定と許可された宛先の確認という 2 つのコアチェックに基づいて構築されています。
Secure Web Proxy ポリシーは、次の 3 つのパラメータに基づいています。
トラフィック ソース: Secure Web Proxy は、トラフィック ソースを識別するために、 サービス アカウント、 セキュアタグ、 IP アドレスなどの さまざまな属性を使用します。
許可される宛先: 許可される宛先を決定するために、Secure Web Proxy は、宛先ドメイン、URL パス（TLS インスペクションが有効になっている場合）、URL リスト、または宛先ポートを使用します。
リクエストの詳細: Secure Web Proxy は、プロトコル、HTTP メソッド、リクエスト ヘッダーなど、ウェブ リクエスト自体の特定の 属性を分析することもできます。この分析を行うには、暗号化されたトラフィックに対して TLS インスペクションを有効にする 必要があります。
ソース属性
きめ細かいセキュリティを適用するため、Secure Web Proxy ポリシーは、次の Cloud Identity とネットワークの位置情報データを使用してトラフィックのソースを識別します。
- サービス アカウント: アプリケーションまたはワークロードに割り当てられる一意の ID。これにより、アプリケーションの特定の機能に基づいてポリシーを作成できます。たとえば、「バックアップ サービス アカウントのみが Cloud Storage にアクセスできる」などです。
- セキュアタグ: リソース（仮想マシン（VM）インスタンスなど）に適用できるラベル。
Google Cloud タグを使用すると、機能または環境ごとにワークロードをグループ化できます。たとえば、
「
Productionというラベルが付いたすべてのリソースが承認済み ドメインにアクセスできるようにする」などです。 - IP アドレス: 送信元のマシンの特定のネットワーク アドレス。Secure Web Proxy がアウトバウンド トラフィックに使用する エンタープライズ IP アドレス（または静的 Google Cloud IP アドレス） を割り当てることができます。
ソース属性でサポートされている ID
Secure Web Proxy は、サービス アカウントやセキュアタグなどのソース ID に基づくポリシーを使用して、ウェブ トラフィックを制御します。ソース ID ベースのポリシーを使用すると、IP アドレスだけでなく、トラフィックを送信しているユーザーまたはものに基づいてルールを適用できます。
次の表に、これらの ソース ID ベースのポリシーをサポートするさまざまな Google Cloud サービスを示します。
| Google Cloud サービス | サービス アカウントのサポート | セキュアタグのサポート |
|---|---|---|
| Compute Engine 仮想マシン（VM） | ||
| Google Kubernetes Engine（GKE）ノード | ||
| Google Kubernetes Engine（GKE）コンテナ | 1 | 1 |
| Cloud Run のダイレクト VPC | 1 | |
| サーバーレス VPC アクセス コネクタ | 2 | 2 |
| Cloud VPN | 1 | 1 |
| オンプレミスの Cloud Interconnect | 1 | 1 |
| アプリケーション ロードバランサ | ||
| ネットワーク ロードバランサ |
2 送信元 IP アドレスは一意であり、代わりに使用できます。
次の表に、ソース ID ベースのセキュリティ ポリシーを使用する場合に、さまざまな Virtual Private Cloud（VPC）アーキテクチャがサポートされているかどうかを示します。
| VPC | VPC アーキテクチャ | サポート |
|---|---|---|
| VPC 内 | プロジェクト間（共有 VPC） | |
| VPC 間 | ピアリング間リンク（ピア VPC） | |
| VPC 間 | Private Service Connect 間 | |
| VPC 間 | Network Connectivity Center スポーク間 |
宛先属性
Secure Web Proxy ポリシーは、ターゲット ウェブサイトまたはサービスの次の属性を分析して、宛先が承認されているかどうかを判断します。
宛先ドメイン: ウェブサイトのアドレス（
example.comなど）。URL リスト: 承認済みまたはブロックされた URL の事前定義リスト。ポリシーの 管理を効率化できます。
宛先ポート: Secure Web Proxy インスタンスがトラフィックを送信するネットワーク ポート。たとえば、HTTPS の場合は
443です。URL パス: ウェブサイトの正確なパス。特定のウェブページでコンテンツ全体を表示するには、TLS インスペクションを有効にする必要があります。
HTTP と HTTPS の両方の宛先トラフィックで、host 宛先属性と、アプリケーションの request.method などのさまざまな request.* 宛先関連属性を使用できます。
HTTP および HTTPS トラフィックに使用できる宛先属性の詳細については、 属性をご覧ください。
ルールの概要
Secure Web Proxy ルールは、Secure Web Proxy ポリシー内の個々の命令であり、実際のマッチングを実行して、最終的なアクション（許可または拒否）を定義します。Secure Web Proxy インスタンスは、優先度に基づいてルールを評価します。数値が小さいほど先にチェックされます。プロキシは、リクエストに一致する最初のルールで停止して処理を行います。
ルールでは、次の 2 つの専用マッチング エンジンを使用してトラフィックを検査します。
セッション マッチャー: ネットワーク接続の設定時に、ネットワーク接続に関する基本情報を確認します。セッション マッチャーには次の項目が含まれます。
- ソース ID（サービス アカウントまたはセキュアタグ）
- 宛先ホスト名（ドメイン名）
- 宛先ポート
アプリケーション マッチャー: 実際のウェブ リクエストのコンテンツを検査します。通常、きめ細かい制御を確保するために使用され、暗号化されたトラフィックをチェックするには TLS インスペクションが必要です。アプリケーション マッチャーには次の項目が含まれます。
- URL パスの完全パス
- リクエスト メソッド（例: すべての
DELETEアクションをブロックする） - 特定の HTTP ヘッダー
ホスト マッチング ルール
Secure Web Proxy は、ホスト名マッチングを使用して宛先ドメインを確認します。これは、次の表に示すように、プロキシのデプロイ方法によって若干異なります。詳細については、 ホスト マッチング ルールを構成するをご覧ください。
| デプロイモード | ホストの確認プロセス |
|---|---|
| 明示的なプロキシモード | 暗号化されていないトラフィックの場合、プロキシは HTTP 接続ヘッダーに対してホスト名を確認します。TLS インスペクションに [Application Matcher 属性](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) を使用する場合、プロキシはホスト名を 2 つのステップで確認します。まず接続レベルで確認し、次に アプリケーション レベルで確認します。 |
| ネクストホップ モード | 暗号化されたトラフィックの場合、プロキシは宛先 ホスト名をアウトバウンド リクエストの Server Name Indication（SNI）フィールドと照合します。これは、安全な接続でも確認できます。 |
TCP プロキシ ルール
伝送制御プロトコル（TCP）プロキシ ルールを使用すると、標準のウェブ トラフィック（HTTP のポート 80 や HTTPS のポート 443 など）以外のトラフィックを制御できます。TCP
プロキシ ルールを構成することで、他の TCP
ポートのトラフィックを承認またはブロックできます。これにより、悪意のあるトラフィックをブロックし、TCP を使用するウェブ以外のアプリケーションをきめ細かく制御できます。
ワークロード（アプリケーションやサービスなど）が Secure Web Proxy をネクストホップとして使用している場合は、 TCP プロキシルールを適用すると便利です。これは、ルートベースのリダイレクト プロセスを使用すると、HTTP(S) 以外のトラフィックとウェブ以外のトラフィックが Secure Web Proxy インスタンスに転送されるためです。これにより、悪意のあるトラフィックがアプリケーションに到達するのを防ぎ、ネットワークにアクセスできるアプリケーションやウェブサイトを制御できます。
詳細については、 TCP プロキシ ルールを構成するをご覧ください。