このページでは、Secure Web Proxy ポリシーの送信元属性と宛先属性について説明します。また、このページでは、Transmission Control Protocol（TCP）ルールベースのプロキシと、アプリケーションの TCP プロキシルールを構成する方法についても説明します。
Secure Web Proxy ポリシーは、次の 2 つのパラメータに基づいています。
- トラフィック ソース: Secure Web Proxy は、サービス アカウント、セキュアタグ、IP アドレスなどの属性を使用してトラフィック ソースを識別します。
- 許可される宛先: Secure Web Proxy は、宛先ドメイン、URL の完全パス（TLS インスペクションが有効になっている場合）、URL リスト、または宛先ポートを使用して、許可される宛先を決定します。
デフォルトでは、Secure Web Proxy は、Secure Web Proxy インスタンスのポリシーに特定のルールを含めない限り、プロキシ経由のすべての外向きウェブ トラフィック（HTTP または HTTPS）を拒否するように設定されています。
ポリシーのソース属性
次の属性を使用して、Secure Web Proxy インスタンスでトラフィックの送信元を識別できるようにします。
- サービス アカウント: サービス アカウントを使用して、トラフィック ソースを識別し、Secure Web Proxy ポリシーを構成します。
- 安全なタグ: Resource Manager タグを使用して、 Google Cloud リソースへのアクセスを制御します。
- IP アドレス: Secure Web Proxy がアウトバウンド トラフィックに使用するエンタープライズ IP アドレス（または静的 Google Cloud IP アドレス）を割り当てます。
サポートされている ID
ソース ID ベースのセキュリティ ポリシー（サービス アカウントとセキュアタグ）を使用して、複数の Google Cloud サービスのウェブ トラフィックを保護できます。次の表に、送信元 ID ベースのセキュリティ ポリシーを使用する場合にさまざまな Google Cloud サービスがサポートされるかどうかを示します。
| Google Cloud サービス | サービス アカウントのサポート | セキュアタグのサポート |
|---|---|---|
| VM | ||
| GKE ノード | ||
| 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） | |
| VPC 間 | Private Service Connect 間 | |
| VPC 間 | Network Connectivity Center スポーク間 |
ポリシーの宛先属性
Secure Web Proxy を使用すると、宛先ドメインと URL の完全パス（TLS インスペクションが有効になっている場合）に基づいて、アプリケーションのポリシーを構成できます。
次の属性を使用して、Secure Web Proxy インスタンスで許可されるトラフィックの宛先を決定できるようにします。
- 宛先ポート: Secure Web Proxy インスタンスがトラフィックを送信するアップストリーム ポート。詳細については、
SessionMatcherとApplicationMatcherで使用可能な属性をご覧ください。 - URL リスト: URL リストを使用して、ユーザーがアクセスできる URL を定義します。詳細については、URL リストをご覧ください。
HTTP ベースの宛先トラフィックの場合は、アプリケーションの host() 宛先属性を使用できます。
HTTPS ベースの宛先トラフィックの場合、アプリケーションにさまざまな request.* 宛先関連属性（request.method など）を使用できます。
HTTP トラフィックと HTTPS トラフィックに使用できる宛先属性の詳細については、属性をご覧ください。
TCP プロキシルール
Secure Web Proxy インスタンスを使用すると、ウェブ プロトコルに関連付けられていないトラフィックを含む、Transmission Control Protocol（TCP）トラフィックのプロキシルールを構成できます。たとえば、80（HTTP）または 443（HTTPS）以外のポートからトラフィックを送信するウェブサイトやアプリケーションのトラフィックを許可またはブロックできます。
ワークロード（アプリケーションやサービスなど）で Secure Web Proxy をネクストホップとして使用する場合は、TCP プロキシルールを適用するとメリットがあります。これは、ルートベースのリダイレクト プロセスを使用すると、HTTP(S) 以外のトラフィックとウェブ トラフィック以外のトラフィックが Secure Web Proxy インスタンスに転送されるためです。これにより、悪意のあるトラフィックがアプリケーションに到達するのをブロックし、ネットワークにアクセスできるアプリケーションやウェブサイトを制御できます。
アプリケーションの TCP プロキシルールを構成する
TCP プロキシルールを実装し、アプリケーションのトラフィックを許可またはブロックするルールを作成するには、宛先ポートを指定する必要があります。必要に応じて、次の SessionMatcher 属性を含めて、許可ルールまたはブロックルールの条件を絞り込むことができます。
| 属性 | 属性タイプ | 説明 |
|---|---|---|
source.ip |
文字列 | リクエストを送信したクライアントの IP アドレス。 |
source.port |
文字列 | リクエストを送信したクライアント ポート。 |
destination.port |
文字列 | Secure Web Proxy インスタンスがトラフィックを送信するアップストリーム ポート。 |
source.matchTag(SECURE_TAG) |
ブール値 | ソースが 引数は、セキュアタグの永続 ID です（ |
source.matchServiceAccount(SERVICE_ACCOUNT) |
ブール値 | ソースが SERVICE_ACCOUNT（source.matchServiceAccount('x@my-project.iam.gserviceaccount.com') など）に関連付けられている場合は、True。 |
inIpRange(IP_ADDRESS, |
ブール値 | IP_ADDRESS が IP_RANGE に含まれている場合（inIpRange(source.ip, '1.2.3.0/24') など）は True。IPv6 アドレスのサブネット マスクは /64 以下にする必要があります。 |
制限事項
Secure Web Proxy では、User Datagram Protocol（UDP）アプリケーションの TCP プロキシルールを構成することはできません。その結果、Secure Web Proxy は UDP ベースのアプリケーションのトラフィックをブロックします。
ホスト マッチング ルール
Secure Web Proxy インスタンスの下り（外向き）ルールを構成する場合は、アウトバウンド リクエストの宛先ホストに応じてルールを定義してください。また、Secure Web Proxy インスタンスのデプロイモードに基づいてホスト マッチングがどのように機能するかも考慮する必要があります。
明示的プロキシモード
暗号化されていない HTTP リクエストの場合は、
SessionMatcherのhost() == "myownpersonaldomain.com"ルールを使用できます。Secure Web Proxy は、HTTP リクエストのCONNECTヘッダーのhostフィールドに対してこのルールを検証します。TLS インスペクションを有効にして、
Application Matcherに基づいてルールを設定する場合は、TRUEに評価されるSessionMatcherルールを設定する必要があります。たとえば、SessionMatcherでhost() == "myownpersonaldomain.com"ルールを使用し、ApplicationMatcherでrequest.host() == "myownpersonaldomain.com"ルールを追加できます。Secure Web Proxy は、まず HTTP リクエストの
CONNECTヘッダーのhostフィールドに対してSessionMatcherを検証します。SessionMatcherルールが有効な場合にのみ、Secure Web Proxy はApplicationMatcherルールを検査します。
ネクストホップ モード
暗号化されていない HTTP リクエストの場合は、
SessionMatcherのhost() == "myownpersonaldomain.com"ルールを使用できます。Secure Web Proxy は、標準の HTTP リクエスト ヘッダーのhostフィールドに対してこのルールを検証します。ただし、リクエストが TLS で暗号化されている場合、Secure Web Proxy はアウトバウンド リクエストの Server Name Indication（SNI）ヘッダーに対して同じルールを検証します。
TLS インスペクションを有効にして、
ApplicationMatcherに基づいてルールを設定する場合は、TRUEに評価されるSessionMatcherルールを設定する必要があります。たとえば、SessionMatcherでhost() == "myownpersonaldomain.com"ルールを使用し、ApplicationMatcherでrequest.host() == "myownpersonaldomain.com"ルールを追加できます。Secure Web Proxy は、まず送信リクエストの SNI ヘッダーに対して
SessionMatcherを検証します。また、SessionMatcherルールが有効な場合にのみ、Secure Web Proxy はApplicationMatcherルールを検査します。