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 またはアプリケーション 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 NAT は、Cloud SWP トラフィックを処理するプロキシのセットが増加すると、追加のパブリック 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 に必要なプロジェクトは 1 つです。
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 ゲートウェイ用の yaml ファイルを作成します。SWP ゲートウェイは、以前の情報（証明書、ゲートウェイ セキュリティ ポリシー、ネットワーク、サブネットなど）を参照します。
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 を明示的に指定する必要があります。Compute インスタンス clientA には環境変数が設定されます。クライアント B はアクセスできません。
Compute インスタンス 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. セッション マッチングのテスト
「clienta」に SSH 接続するCompute VM を作成しました。この 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
クライアント 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>
組織のドメインに対するテスト:
curl https://wikipedia.org
お客様は 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 を宛先とするトラフィックは許可され、他のすべての宛先は拒否されます。
クライアント b を終了します。
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 ルールのテスト
クライアント Compute 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 リクエストであることに注目してください。次に、SWP で TLS インスペクション機能を有効にする必要があります。
次に、同じクエリを 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 インスペクションを含めるためにポリシー 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 インスペクションをテストする
クライアント Compute 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 の設定が完了しました。
クライアントを終了します。
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 とそのメリット