Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Secure Web Proxy でフロントエンド mTLS を使用する

Secure Web Proxy でフロントエンド相互 TLS（mTLS）を構成して、AI エージェントなどのワークロードのセキュリティを強化できます。Secure Web Proxy は、フロントエンド mTLS を使用して、証明書でクライアント ID を検証します。

この統合により、Secure Web Proxy 認証ポリシーで検証済みのクライアント ID を使用して、下り（外向き）トラフィックのきめ細かいアクセス制御を適用できます。

仕組み

次の手順では、Secure Web Proxy がフロントエンド mTLS を使用して下り（外向き）トラフィックを保護する方法について説明します。

明示的なプロキシ接続: Secure Web Proxy を明示的なプロキシとして使用するようにクライアントを構成できます。クライアントは、インターネットに直接接続するのではなく、Secure Web Proxy フロントエンドに HTTPS CONNECT リクエストを開始します。
相互 TLS handshake: 接続設定中に、Secure Web Proxy とクライアントはプロキシフロントエンドで mTLS handshake を実行します。プロキシは、構成された TrustConfig リソースを使用してクライアントの証明書を検証しますが、クライアントはプロキシのサーバー証明書を検証します。
ID の抽出: handshake が成功すると、Secure Web Proxy は検証済みのクライアント証明書から URI_SAN などの一意の ID 属性を直接抽出します。
ID ベースの認証: Secure Web Proxy は、構成された認証ポリシーに対して下り（外向き）リクエストを評価します。リクエストが承認されているかどうかを判断するために、プロキシは mTLS handshake 中に暗号で検証されたクライアントの ID を使用します。
下り（外向き）トラフィックの保護: 承認されると、一致するルールが外部宛先にある場合、Secure Web Proxy は宛先へのリクエストを満たします。

主な特典

Secure Web Proxy でフロントエンド mTLS を構成すると、次のようなセキュリティと運用上のメリットがあります。

セキュリティの強化: すべての下り（外向き）トラフィックにフロントエンド mTLS 認証を要求することで、ゼロトラストアクセスを実現します。これにより、検証済みの ID を持つワークロードのみがプロキシとの接続を確立して外部サービスにアクセスできるようになります。
ワークロード構成の簡素化: Secure Web Proxy に明示的なプロキシルーティングモードを使用して、リクエストをインターセプトして認証するプロキシの機能を活用します。
きめ細かい制御: 詳細な ID 対応ポリシーを適用して、特定のワークロードがアクセスできる外部サービスを決定します。

ユースケースの例: ワークロードの ID を検証する

銀行などのコンプライアンスが厳しく規制されている業界では、不正なデータアクセスを防ぐために、リクエストのネットワークロケーションを確認するだけでは不十分です。Secure Web Proxy でフロントエンド mTLS を構成することで、組織は暗号で検証された ID モデルに移行できます。これにより、仮想マシン（VM）インスタンスや AI エージェントなど、すべてのワークロードが信頼できる証明書を使用して特定の ID を証明する必要があります。

このアプローチにより、管理者は機密性の高い下り（外向き）パスを保護する ID ベースのガードレールを適用できます。たとえば、銀行は特定の認証済み決済処理ワークロードのみが外部金融ゲートウェイに到達できるようにします。

Secure Web Proxy のフロントエンド mTLS 認証を構成する

このセクションでは、Secure Web Proxy インスタンスのフロントエンド mTLS 認証を構成する手順について説明します。

始める前に

信頼構成を管理するページを確認します。
CLI を Google Cloud インストールします
必要な API を有効にします。
Identity and Access Management 管理者に次のロールの付与をリクエストします。
- Certificate Manager オーナーロール（roles/certificatemanager.owner）
- Compute Network Admin ロール（roles/compute.networkAdmin）
- Compute Security Admin ロール（roles/compute.securityAdmin）
- Networksecurity Admin ロール (roles/networksecurity.admin)
明示的なプロキシルーティングモードでデプロイしたSecure Web Proxy インスタンスが必要です。

ルート証明書と中間証明書を作成する

このセクションでは、OpenSSL を使用してルート認証局（CA）証明書（トラストアンカー）とオプションの中間 CA 証明書を生成する方法について説明します。Secure Web Proxy は、これらの証明書を使用して、フロントエンド mTLS handshake プロセス中にワークロードが提示するクライアント証明書を検証します。この手動プロセスは、テスト環境と開発環境で、Secure Web Proxy がクライアント証明書を検証するために必要なトラストアンカーを提供することを目的としています。

ルート証明書は証明書チェーンの最上位にありますが、中間証明書はルートへの信頼チェーンのブリッジとして機能します。中間証明書は、ルート証明書によって暗号署名されます。Secure Web Proxy は、クライアント証明書を受信すると、クライアント証明書から構成済みのトラストアンカーまでの信頼チェーンを確立して ID を検証します。

次のコマンドを使用して、ルート証明書と中間証明書を作成します。中間証明書は省略可能ですが、この構成では、クライアント証明書に署名して多層証明書階層を示すために使用します。

OpenSSL 構成ファイルを作成します。

cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name

[empty_distinguished_name]
# Kept empty to allow setting via -subj command-line argument.

[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth
EOF

自己署名 X.509 ルート証明書（root.cert）と秘密鍵（root.key）を作成します。

openssl req -x509 \
    -new -sha256 -newkey rsa:2048 -nodes \
    -days 3650 -subj '/CN=root' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout root.key -out root.cert

中間証明書の証明書署名リクエスト（int.req）を作成します。

openssl req -new \
    -sha256 -newkey rsa:2048 -nodes \
    -subj '/CN=int' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout int.key -out int.req

証明書署名リクエスト（CSR）に署名して、X.509 中間証明書（int.cert）を作成します。

openssl x509 -req \
    -CAkey root.key -CA root.cert \
    -set_serial 1 \
    -days 3650 \
    -extfile example.cnf \
    -extensions ca_exts \
    -in int.req -out int.cert

テスト用のクライアント証明書を作成する

テストクライアントワークロードのリーフ証明書と秘密鍵を作成します。Secure Web Proxy インスタンスとの mTLS handshake プロセス中に、クライアントはこのリーフ証明書を提供して ID を証明します。

次の例では、OpenSSL を使用してクライアント鍵と CSR を生成し、ルート証明書と中間証明書を作成するセクションで作成した中間 CA 鍵で CSR に署名します。

次の OpenSSL コマンドを実行して、という名前の RSA 秘密鍵を生成します。client.key
```
openssl genpkey -algorithm RSA -out client.key
```

サブジェクト代替名（SAN）の DNS 名を指定する client.cnf という名前の構成ファイルを作成します。これにより、証明書が最新のセキュリティ要件と互換性があることが保証されます。

cat > client.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = my-client.example.com

[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = my-client.example.com

EOF

必要に応じて、テスト用に CN 値と DNS.1 値を変更できます。

作成した秘密鍵と構成ファイルを使用して OpenSSL リクエストコマンドを実行し、client.req ファイルを生成します。
```
openssl req -new -key client.key -out client.req -config client.cnf
```
OpenSSL x509 コマンドを使用して、中間証明書（int.cert）と鍵（int.key）を使用してリクエストに署名します。365 日などの有効期間を設定し、構成ファイルの拡張機能が生成された client.cert ファイルに適用されていることを確認します。
```
openssl x509 -req -in client.req -CA int.cert -CAkey int.key \
  -set_serial 02 -days 365 -out client.cert \
  -extfile client.cnf -extensions v3_req
```
このプロセスにより、client.cert ファイルが作成されます。DNS SAN で使用される値（my-client.example.com など）をクライアント ID として記録します。この値を使用して、Secure Web Proxy 認証ポリシーを作成するときにワークロードを識別できます。

証明書をフォーマットする

ルート証明書と中間証明書を、trust_config.yaml ファイルで使用する環境変数にフォーマットします。

  export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
  export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

信頼構成リソースを作成する

信頼構成は、Certificate Manager の公開鍵基盤（PKI）を表します。信頼構成は、フロントエンド mTLS handshake 中に提示されたクライアント証明書を検証するときに信頼する認証局（CA）証明書を Secure Web Proxy インスタンスに示します。

このサンプル信頼構成リソースには、トラストアンカー（ルート CA）と中間 CA を含む単一のトラストストアを含むトラストストアが含まれています。前の証明書をフォーマットするセクションで作成した環境変数の証明書の内容を使用します。

trust_config.yaml ファイルを作成します。

cat << EOF > trust_config.yaml
trustStores:
  TRUST_CONFIG_NAME:
    trustAnchors:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----
    intermediateCAs:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----

EOF

TRUST_CONFIG_NAME は、信頼構成リソースの名前に置き換えます。

trust config.yaml ファイルを gcloud certificate-manager trust-configs import コマンドを使用してインポートします。
```
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME\
  --source=trust_config.yaml \
  --location=LOCATION
```
次のように置き換えます。
- TRUST_CONFIG_NAME: 信頼構成リソースの名前
- LOCATION: 信頼構成リソースが保存されているリージョン

`ServerTlsPolicy` リソースを作成する

ServerTlsPolicy リソース（クライアント認証リソースとも呼ばれます）は、Secure Web Proxy がクライアント証明書を検証する方法を定義します。これにより、証明書の検証に使用するサーバーサイド TLS モードと信頼構成リソースを指定できます。

clientValidationMode 属性は、クライアントが無効な証明書を提供した場合、または証明書をまったく提供しない場合に、接続を処理する方法を決定します。詳細については、フロントエンド mTLS クライアント検証モードをご覧ください。

clientValidationMode 属性の値は次のとおりです。

REJECT_INVALID: Secure Web Proxy は、信頼構成の CA によって署名された有効な証明書を提示するクライアントからの接続のみを許可します。証明書が無効または欠落している接続は拒否されます。
ALLOW_INVALID_OR_MISSING_CLIENT_CERT: クライアント証明書が無効な場合、信頼構成に対して検証できない場合、または完全に欠落している場合でも、Secure Web Proxy は接続リクエストを許可します。

注: このモードを選択すると、Secure Web Proxy インスタンスは SPIFFE_IDとその他の証明書属性を、有効な証明書が提供された場合に抽出します。ただし、証明書が無効または欠落している場合、これらの特定の ID 属性は使用できません。証明書の有無またはそのフィンガープリントに基づいて認証ポリシーを作成できます。

ServerTlsPolicy リソースを作成する手順は次のとおりです。

server_tls_policy.yaml ファイルを作成します。clientValidationMode に次のいずれかのオプションを選択します。
- オプション 1: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
- オプション 2: REJECT_INVALID
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: REJECT_INVALID
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
次のように置き換えます。
- SERVER_TLS_POLICY_NAME: ServerTlsPolicy リソースの名前
- PROJECT_ID: プロジェクトの ID。 Google Cloud
- TRUST_CONFIG_NAME: 信頼構成リソースの名前
- LOCATION: Secure Web Proxy インスタンスが構成されているリージョン
ServerTlsPolicy リソースを gcloud network-security server-tls-policies import コマンドを使用してインポートします。
```
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME\
  --source=server_tls_policy.yaml \
  --location=LOCATION
```
次のように置き換えます。
- SERVER_TLS_POLICY_NAME: ServerTlsPolicy リソースの名前
- LOCATION: Secure Web Proxy インスタンスが構成されているリージョン
省略可: すべての ServerTlsPolicies リソースを一覧表示するには、 gcloud network-security server-tls-policies list コマンドを使用します。
```
gcloud network-security server-tls-policies list \
  --location=LOCATION
```
LOCATION は、Secure Web Proxy インスタンスが構成されているリージョンに置き換えます。

`ServerTlsPolicy` リソースを Secure Web Proxy インスタンスに関連付ける

Secure Web Proxy インスタンスの gateway.yaml ファイルに ServerTlsPolicy リソースを追加します。
```
echo "serverTlsPolicy:
//networksecurity.googleapis.com/projects/PROJECT_ID/locations/
LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME"
>> gateway.yaml
```
次のように置き換えます。
- PROJECT_ID: プロジェクトの ID。 Google Cloud
- LOCATION: Secure Web Proxy インスタンスが構成されているリージョン
gcloud network-services gateways import コマンドを使用して、 gateway.yaml ファイルから Secure Web Proxy インスタンスの構成をインポートします。
```
gcloud network-services gateways import GATEWAY_NAME\
    --source=gateway.yaml \
    --location=LOCATION
```
次のように置き換えます。
- GATEWAY_NAME: Secure Web Proxy インスタンスの名前
- LOCATION: Secure Web Proxy インスタンスが構成されているリージョン

認証ポリシーを構成する

詳細については、Secure Web Proxy の認証ポリシーを設定するをご覧ください。

ロギング

詳細については、フロントエンド mTLS のエラー処理とロギングをご覧ください。

制限事項

Secure Web Proxy は、明示的なプロキシルーティングモードでのみフロントエンド mTLS の構成をサポートしています。
フロントエンド mTLS ベースのセキュリティルールを作成するには、Secure Web Proxy の認証ポリシーを使用します。ゲートウェイセキュリティポリシールールはサポートされていません。

詳細については、フロントエンド mTLS の制限事項をご覧ください。

次のステップ

Secure Web Proxy を Private Service Connect サービスとしてデプロイする