1. はじめに
クラウド セキュア ウェブプロキシ
Cloud SWP は、下り（外向き）ウェブ トラフィック（HTTP/S）の保護を支援する安全なウェブ プロキシを提供するクラウド ファーストのサービスです。プロキシとして Cloud SWP を明示的に使用するようにクライアントを構成します。ウェブ リクエストは次のソースから開始されます。
- 仮想マシン（VM）インスタンス
- コンテナ
- サーバーレス コネクタを使用するサーバーレス環境
- VPC ピアリング間のワークロード
- Cloud VPN または Cloud Interconnect で接続された Google Cloud 外のワークロード
Cloud SWP を使用すると、クラウド ファースト ID とウェブ アプリケーションに基づいた、柔軟かつ詳細なポリシーを実現できます。
利点
Cloud SWP が組織にもたらすメリットの例を次に示します。
Google Cloud への移行
Cloud SWP は、下り（外向き）ウェブ トラフィックの既存のセキュリティ ポリシーと要件を維持しながら、Google Cloud への移行を支援します。別の管理コンソールの使用、または構成ファイルの手動編集を必要とするサードパーティのソリューションを回避できます。
信頼できる外部ウェブサービスにアクセスする
Cloud SWP では、下り（外向き）ウェブ トラフィックに詳細なアクセス ポリシーを適用して、ネットワークを保護できます。ワークロードまたはアプリケーションの ID を作成して識別し、ポリシーを適用します。
信頼できないウェブサービスへのモニタリングされたアクセス
Cloud SWP を使用して、信頼できないウェブサービスへのモニタリング対象アクセスを提供できます。Cloud SWP は、ポリシーに準拠していないトラフィックを識別して Cloud Logging（Logging）に記録します。これにより、インターネット使用状況をモニタリングし、ネットワークに対する脅威を検出し、脅威に対応できます。
Google API のきめ細かいポリシー制御
Cloud SWP を使用すると、Google API のきめ細かいポリシーを提供できます。たとえば、Common Expression Language（CEL）を活用して、バケット/オブジェクト レベルのポリシーを設定できます。
サポートされる機能
Cloud SWP は、次の機能をサポートしています。
明示的プロキシ サービス
プロキシ サーバーを使用するようにクライアントを明示的に構成する必要があります。Cloud SWP プロキシは、クライアントに代わって新しい TCP 接続を作成することで、クライアントをインターネットから分離します。
Cloud SWP Envoy プロキシの自動スケーリング
Envoy プロキシプールのサイズとリージョン内のプールの容量を自動的に調整します。これにより、需要が高い期間に最も低コストで、一貫したパフォーマンスが可能になります。
モジュラー下り（外向き）アクセス ポリシー
Cloud SWP は、次の下り（外向き）ポリシーを明示的にサポートしています。
- セキュアタグ、サービス アカウント、IP アドレスに基づく送信元 ID。
- URL、ホスト名に基づく宛先。
- メソッド、ヘッダー、URL に基づくリクエスト。URL は、リスト、ワイルドカード、パターンを使用して指定できます。
- エンドツーエンドの暗号化: クライアント プロキシ トンネルは TLS を経由する可能性があります。Cloud SWP は、宛先サーバーへのクライアントが開始したエンドツーエンドの TLS 接続用に HTTP/S CONNECT もサポートしています。
Cloud NAT との統合の簡素化
Cloud SWP トラフィックを処理するプロキシのセットが増加すると、Cloud NAT は追加のパブリック IP アドレスを自動的にプロビジョニングします。
既知の下り（外向き）IP を使用したい場合は、手動の静的パブリック IP アドレスも選択できます。
Cloud Audit Logs と Google Cloud のオペレーション スイートの統合
Cloud Audit Logs と Google Cloud のオペレーション スイートは、Cloud SWP 関連リソースの管理アクティビティとアクセス リクエストを記録します。また、このプロキシで処理されるリクエストの指標とトランザクション ログも記録します。
TLS インスペクション
Secure Web Proxy には、TLS トラフィックを傍受し、暗号化されたリクエストを検査し、セキュリティ ポリシーを適用できる TLS 検査サービスが用意されています。
- プライベート CA の可用性とスケーラビリティに優れたリポジトリである Certificate Authority Service（CAS）との緊密な統合。
- 必要に応じて独自のルート オブ トラストを使用できること。既存のルート CA を使用して、CAS が保持する下位 CA に署名することもできます。必要に応じて、CAS 内で新しいルート証明書を生成することもできます。
- Secure Web Proxy のポリシールール内で SessionMatcher と ApplicationMatcher を使用してきめ細かい復号基準。この条件には、URL リスト、正規表現、IP アドレス範囲、類似の式に存在する一致するホストが含まれます。必要に応じて、条件をブール式と組み合わせることができます。
- 各 Secure Web Proxy ポリシーは、独自の TLS 検査ポリシーと CA プールを使用して構成できます。また、複数の Secure Web Proxy ポリシーで 1 つの TLS 検査ポリシーを共有することもできます。
学習内容
- Cloud SWP をデプロイして管理する方法。
必要なもの
- インスタンスのデプロイとネットワーク コンポーネントの構成に関する知識
- VPC ファイアウォールの構成に関する知識
2. テスト環境
この Codelab では、単一の VPC を使用します。この環境のコンピューティング リソースは、次の図に示すように、Cloud SWP を使用して下り（外向き）を行います。
このラボでは、2 つのワークロード VM を使用します。
クライアント A は、すべての HTTP/HTTPS リクエストを Cloud SWP に送信するように構成されます。
クライアント B は、HTTP/HTTPS リクエストを Cloud SWP に明示的に送信するように構成されませんが、代わりにインターネット バウンド トラフィックに Cloud NAT を活用します。
3. 始める前に
この Codelab では、単一のプロジェクトが必要です。
Cloud Shell で、プロジェクト ID が設定されていることを確認します。
export project_id=`gcloud config list --format="value(core.project)"` export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"` export region=us-west1 export zone=us-west1-a export prefix=codelab-swp export member="serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com"
4. API を有効にする
プロダクトを使用するために API を有効にする
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. VPC ネットワーク、サブネット、プロキシ専用サブネットを作成する
VPC ネットワーク
codelab-swp-vpc VPC を作成します。
gcloud compute networks create $prefix-vpc --subnet-mode=custom
サブネット
選択したリージョンにそれぞれのサブネットを作成します。
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
プロキシ専用サブネット
選択したリージョンにプロキシ専用サブネットを作成します。
gcloud compute networks subnets create $prefix-proxy-only-subnet --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$region --network=$prefix-vpc --range=172.16.0.0/23
6. ファイアウォール ルールを作成する
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセス可能にするすべての VM インスタンスに適用されます。
- IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可します。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell から:
gcloud compute firewall-rules create $prefix-allow-iap-proxy \ --direction=INGRESS \ --priority=1000 \ --network=$prefix-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
7. Cloud Router と Cloud NAT を作成する
Cloud NAT 用の Cloud Router を作成します。
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
クライアント B の Cloud NAT ゲートウェイを作成します。
gcloud compute routers nats create $prefix-nat-gw-$region \ --router=$prefix-cr \ --router-region=$region \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
8. ゲートウェイ セキュリティ ポリシーを作成する
ポリシーに関連する情報を含む YAML ファイルを作成します。
cat > /tmp/policy.yaml << EOF
description: Policy to allow .com traffic, then (/index.html), and finally TLS.
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
EOF
gcloud コマンドを実行して、yaml ファイルからポリシーを作成します。
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. ゲートウェイ セキュリティ ポリシー ルールを作成する
ルールを含む YAML ファイルを作成します。これらのルールは Common Expression Language（CEL）で表されます。このラボでは、.com ドメインへのトラフィックを許可し、それ以外のトラフィックをすべてブロックするシンプルなルールを使用します。
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
EOF
これで、ルールをゲートウェイ セキュリティ ポリシーにバインドできます。
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. 証明書を作成して Cloud Certificate Manager にアップロードする
ワークロード トラフィックを終了する証明書を作成します。
openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -subj '/CN=www.codelab-swp.com' -nodes -addext \ "subjectAltName = DNS:www.codelab-swp.com"
証明書を Cloud Certificate Manager にアップロードして、SWP がセキュリティ ゲートウェイ ポリシーで参照できるようにします。
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. SWP ゲートウェイを作成する
SWP Gateway の yaml ファイルを作成して、証明書、ゲートウェイ セキュリティ ポリシー、ネットワーク、サブネットなどの前の情報を参照します。
cat > /tmp/gateway.yaml << EOF
name: projects/${project_id}/locations/${region}/gateways/${prefix}-gateway
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.50]
ports: [443]
certificateUrls: [projects/${project_id}/locations/${region}/certificates/${prefix}-cert]
gatewaySecurityPolicy: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
network: projects/${project_id}/global/networks/${prefix}-vpc
subnetwork: projects/${project_id}/regions/${region}/subnetworks/${prefix}-vpc-subnet
EOF
ゲートウェイを作成します。
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
ゲートウェイが作成されたことを確認します。
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. コンピューティング インスタンスを作成する
Cloud SWP は明示的なプロキシであるため、ワークロード トラフィックのプロキシ IP を明示的に指定する必要があります。コンピューティング インスタンス clientA には環境変数が設定されます。ClientB はそうではありません。
コンピューティング インスタンス ClientA と ClientB を作成します。
gcloud compute instances create clienta \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.10 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update sudo echo http_proxy=https://10.10.10.50:443/ >> /etc/environment sudo echo https_proxy=https://10.10.10.50:443/ >> /etc/environment '
gcloud compute instances create clientb \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.200 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update '
13. セッション マッチングのテスト
最近作成したコンピューティング VM「clienta」に SSH 接続します。この VM には、Cloud SWP を使用するように設定された環境変数があります。
Cloud Shell から:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
ウェブクエリを実行して、機能を確認します。このラボでは自己署名証明書を作成したため、-proxy-insecure が必要です。
curl https://google.com --proxy-insecure
予想される出力:
davidtu@clienta:~$ curl https://google.com --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
ご覧のとおり、リクエストは「成功」しました。ウェブサイトが https://www.google.com にリダイレクトされるため、301 リダイレクトが表示されることが想定されます。
次のコマンドを実行すると、接続の詳細を含む詳細ログが提供されます。
curl https://google.com --proxy-insecure -v
プロキシ接続の詳細、証明書、宛先を示すために、一部の出力をハイライト表示しています。
davidtu@clienta:~$ curl https://google.com --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to google.com:443 > CONNECT google.com:443 HTTP/1.1 > Host: google.com:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < date: Mon, 12 Dec 2022 19:22:04 GMT < * Proxy replied 200 to CONNECT request * CONNECT phase completed! ...
他の .com ドメインを試して、機能を確認することもできます。
次に、.com 以外のドメインをいくつか試して、デフォルトのブロック動作を確認してみましょう。
curl https://wikipedia.org --proxy-insecure
予想される出力:
curl: (56) Received HTTP code 403 from proxy after CONNECT
同様に、詳細出力ロギングを確認し、Cloud SWP がこのトラフィックをブロックしていることを確認します。
curl https://wikipedia.org --proxy-insecure -v
davidtu@clienta:~$ curl https://wikipedia.org --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to wikipedia.org:443 > CONNECT wikipedia.org:443 HTTP/1.1 > Host: wikipedia.org:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 403 Forbidden < content-length: 13 < content-type: text/plain < date: Mon, 12 Dec 2022 19:35:09 GMT < connection: close < * Received HTTP code 403 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0 curl: (56) Received HTTP code 403 from proxy after CONNECT
動作を確認するために、他のドメインも試してみてください。
「clienta」への SSH セッションを終了し、「clientb」への新しい SSH 接続を開始します。
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
いくつかの curl コマンドを実行して動作を確認します。
curl https://google.com
clientb VM は想定どおりに動作するはずです。
davidtu@clientb:~$ curl https://google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
org ドメインに対するテスト:
curl https://wikipedia.org
clientb は Cloud SWP を活用していないため、これは想定どおりに機能します。
davidtu@clientb:~$ curl https://wikipedia.org <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.wikipedia.org/">here</a>.</p> </body></html>
Cloud SWP を介してトラフィックを明示的に送信するテスト:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
このトラフィックは Cloud SWP ポリシーによって拒否されています。
davidtu@clientb:~$ curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure curl: (56) Received HTTP code 403 from proxy after CONNECT
確認したように、Cloud SWP を利用するトラフィックは、構成されたセキュリティ ポリシーに対して適用されています。.com 宛てのトラフィックは許可され、他のすべての宛先は拒否されます。
clientb を終了します。
14. ApplicationMatching のゲートウェイ セキュリティ ポリシー ルールを更新する
アプリケーション レベルの詳細と照合するようにルールを更新しましょう。リクエスト パスを調べて、index.html と一致する場合にのみ許可するルールを作成します。
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
EOF
更新されたルールをゲートウェイ セキュリティ ポリシーにバインドできるようになりました。
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. ApplicationMatcher ルールのテスト
clienta コンピューティング VM に SSH で接続します。この VM には、Cloud SWP を使用するように設定された環境変数があります。
Cloud Shell から:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
ウェブクエリを実行して、機能を確認します。このラボでは自己署名証明書を作成したため、-proxy-insecure が必要です。
curl http://google.com --proxy-insecure
このクエリは、以前に成功したときに失敗します。
Access denied
「index.html」以外のリクエストパスはすべて 403 でブロックされます。引き続きお試しください。
クエリを変更してパス /index.html を含める
curl http://google.com/index.html --proxy-insecure
このリクエストは成功するはずです。
davidtu@clienta:~$ curl http://google.com/index.html --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
ウェブサイトが http://www.google.com/index.html にリダイレクトされるため、301 リダイレクトが表示されることが想定されます。
これは HTTP リクエストです。次に、TLS インスペクション機能を有効にするために SWP を有効にする必要があります。
次に、同じクエリを TLS 経由で実行します。
curl -k https://google.com/index.html --proxy-insecure
予想される出力:
curl: (56) Received HTTP code 403 from proxy after CONNECT
SWP は TLS を検査するように構成されていないため、このリクエストは失敗します。また、applicationMatcher ルールに対してパスを評価することもできません。
clenta を終了します。
16. TLS インスペクションを有効にする
TLS インスペクションがない場合、applicationMatcher は HTTPS トラフィックと照合されません。
「applicationMatcher」では、次の項目でフィルタできます。
- リクエスト ヘッダー マップ
- リクエスト メソッド
- リクエスト ホスト
- リクエストパス
- リクエスト クエリ
- リクエスト スキーム
- 完全なリクエスト URL
- ユーザー エージェントをリクエストする
サービス アカウントを作成する
このサービス アカウントには、SWP TLS インスペクション用の証明書を生成する権限が付与されます。
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
CAS が有効になっていることを確認する
gcloud services enable privateca.googleapis.com
CA プールを作成します
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
ルート CA を作成する
証明書の署名に使用される CA。
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
証明書発行ポリシー ファイルを作成する
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
TLS インスペクションの YAML ファイルを作成する
cat > /tmp/tls-inspection-policy.yaml << EOF caPool: projects/$project_id/locations/$region/caPools/$prefix-ca-pool name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-inspection EOF
TLS インスペクション ポリシーを作成する
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
証明書発行ポリシーを使用するように CA プールを更新する
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
権限の付与
これにより、サービス アカウントは CA プールを使用して証明書を生成できます。
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
TLS インスペクションを含むように Policy yaml を更新
cat > /tmp/policy.yaml << EOF
description: some policy description
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
tlsInspectionPolicy: projects/${project_id}/locations/${region}/tlsInspectionPolicies/${prefix}-tls-inspection
EOF
コマンドを実行して更新したポリシーを適用する
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
TLS インスペクションを含むようにルールを更新する
次に、TLS インスペクションの「enabtlsInspectionEnabled: true」フラグを設定するルールを指定します。
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
tlsInspectionEnabled: true
EOF
コマンドを実行して、更新されたルールを適用します。
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. TLS インスペクションをテストする
clienta コンピューティング VM に SSH で接続します。この VM には、Cloud SWP を使用するように設定された環境変数があります。
Cloud Shell から:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
前のウェブクエリを実行して、SWP が TLS インスペクションを実行してパスを取得しているかどうかを確認します。
curl -k https://google.com/index.html --proxy-insecure
今回は、SWP が ApplicationMatcher を評価できるため、成功するはずです。
予想される出力:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
これで、TLS を検査して applicationMatcher ロジックを評価するように Cloud SWP を設定できました。
clienta を終了します。
18. クリーンアップ手順
Cloud Shell から、SWP ゲートウェイ、セキュリティ ポリシー、証明書、インスタンス、Cloud NAT、Cloud Router を削除します。
gcloud -q network-services gateways delete ${prefix}-swp --location=${region}
gcloud -q network-security gateway-security-policies rules delete rule-com --location=${region} --gateway-security-policy=${prefix}-policy
gcloud -q network-security gateway-security-policies delete ${prefix}-policy --location=${region}
gcloud -q certificate-manager certificates delete ${prefix}-cert --location=${region}
gcloud -q network-security tls-inspection-policies delete $prefix-tls-inspection --location=$region
gcloud -q privateca roots disable $prefix-root-ca --pool=$prefix-ca-pool --location=$region
gcloud -q privateca roots delete $prefix-root-ca --pool=$prefix-ca-pool --location=$region --ignore-active-certificates --skip-grace-period
gcloud -q privateca pools delete $prefix-ca-pool --location=$region
gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region
gcloud -q compute routers delete `gcloud compute routers list --regions=$region --format="value(NAME)" | grep -e swg-autogen -e codelab-swp` --region=$region
サブネット、FW ルール、VPC を削除します。
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks subnets delete $prefix-proxy-only-subnet \
--region=$region
gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute networks delete $prefix-vpc
19. 完了
以上で、この Codelab は完了です。これで、Google Cloud で Cloud Secure Web Proxy の構成とデプロイが完了しました。
学習した内容
- Cloud SWP とそのメリット