1. はじめに
Google Cloud ロード バランシングは、世界中の Google の接続拠点（POP）で Google ネットワークのエッジにデプロイされます。TCP プロキシ ロードバランサを送信先とするユーザー トラフィックは、ユーザーに最も近い POP に入った後、Google のグローバル ネットワークでロードバランスされて、十分な容量がある最も近いバックエンドに送られます。
Cloud Armor は、Google の分散型サービス拒否攻撃とウェブ アプリケーション ファイアウォール（WAF）の検出システムです。Cloud Armor は Google Cloud TCP プロキシ ロードバランサと緊密に連携しており、受信トラフィックを照会して不要なリクエストを検出できます。このサービスのレート制限機能を使用すると、リクエスト量に応じてバックエンド リソースへのトラフィックを制限し、望ましくないトラフィックが Virtual Private Cloud（VPC）ネットワークのリソースを消費するのを防ぐことができます。
Google Cloud TCP/SSL プロキシ ロードバランサを使用すると、バックエンド サービス間で TCP/ SSL タイプのトラフィックをプロキシできます。
このラボでは、バックエンド サービスを使用して TCP/SSL ロードバランサを作成し、ロードバランサへのアクセスを特定のユーザー クライアントのセットに限定します。
学習内容
- TCP/SSL プロキシ ロードバランサを作成する方法
- Cloud Armor セキュリティ ポリシーを作成する方法
- Cloud Armor で TCP/SSL プロキシ ロードバランサの IP 拒否リスト ルールを作成する方法
- Cloud Armor で TCP プロキシ ロードバランサのレート制限ルールを作成する方法
- TCP/SSL ロード バランシング バックエンド サービスにセキュリティ ポリシーを追加する方法
必要なもの
- Google Compute Engine に関する基本的な知識（codelab）
- ネットワークと TCP/IP に関する基本的な知識
- Unix / Linux コマンドラインに関する基本的な知識
- Google Cloud のネットワーキングで GCP のネットワーキングの概要を確認しておいてください。
2. 要件
セルフペース型の環境設定
- Cloud コンソールにログインして、新しいプロジェクトを作成するか、既存のプロジェクトを再利用しますGmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
注: console.cloud.google.com という URL を覚えておくと、Cloud コンソールに簡単にアクセスできます。
プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります（上記の名前はすでに使用されているので使用できません）。以降、この Codelab では PROJECT_ID と呼びます。
注: Gmail アカウントを使用している場合は、デフォルトの場所の設定は [組織なし] のままにしてかまいません。Google Workspace アカウントを使用している場合は、組織に適した場所を選択してください。
- 次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。
このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Cloud Shell の起動
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。
始める前に
Cloud Shell で、プロジェクト ID が設定されていることを確認します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
API を有効にする
必要なサービスをすべて有効にする
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. バックエンド サービスを作成する
次のように 2 つのインスタンスを作成します。ゾーン us-central1-b に instance1-b1 を作成します。
gcloud compute instances create vm-1-b1 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b1 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
ゾーン us-central1-b にインスタンス 1-b2 を作成します。
gcloud compute instances create vm-1-b2 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b2 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
インスタンス グループ vm-ig1 を作成する
gcloud compute instance-groups unmanaged create vm-ig1 --zone us-central1-b
インスタンス グループの名前付きポートを作成します。このラボでは、ポート 110 を使用します。
gcloud compute instance-groups set-named-ports vm-ig1 \ --named-ports tcp 110:110 --zone us-central1-b
インスタンス グループにインスタンスを追加する
gcloud compute instance-groups unmanaged add-instances vm-ig1 \ --instances vm-1-b1,vm-1-b2 --zone us-central1-b
4. ロードバランサの構成
次に、ヘルスチェックを作成します。
gcloud compute health-checks create tcp my-tcp-health-check --port 110
バックエンド サービスを作成する
gcloud compute backend-services create my-tcp-lb --global-health-checks --global \ --protocol TCP --health-checks my-tcp-health-check --timeout 5m --port-name tcp110
バックエンド サービスにインスタンス グループを追加する
gcloud compute backend-services add-backend my-tcp-lb --global --instance-group \ vm-ig1 --instance-group-zone us-central1-b --balancing-mode UTILIZATION \ --max-utilization 0.8
ターゲット TCP プロキシの構成
gcloud compute target-tcp-proxies create my-tcp-lb-target-proxy --backend-service \ my-tcp-lb --proxy-header NONE
グローバル静的 IPv4 アドレスを予約する
この IP アドレスを使用して、ロード バランシングされたサービスにアクセスします。
gcloud compute addresses create tcp-lb-static-ipv4 --ip-version=IPV4 --global
LB IP アドレスのグローバル転送ルールを構成します。
gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
--global --target-tcp-proxy my-tcp-lb-target-proxy --address LB_STATIC_IPV4 \ --ports 110
5. TCP プロキシ ロードバランサのファイアウォール ルールの作成
gcloud compute firewall-rules create allow-tcplb-and-health \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --target-tags tcp-lb \ --allow tcp:110
ロードバランサが作成されたら、次のコマンドを使用してテストします。
Curl LB_IP:110
次に、LB へのアクセス拒否の検証用の VM を作成します。
2 つのインスタンスを作成します。それぞれにパブリック IP アドレスを指定し、test-server1 と test-server2 という名前を付けます。
6. Cloud Armor でセキュリティ ポリシーを作成する
このセクションでは、Cloud Armor でバックエンド セキュリティ ポリシーとポリシー内の 2 つのルールを作成します。
最初のルールは、特定の IP を拒否するようにセキュリティ ポリシーを設定して、限定された IP セットが TCP ロードバランサにアクセスすることを拒否します。2 番目のルールはレート制限を実行します。
- Cloud Shell（Cloud Shell の使用方法については、[設定と要件] の「Cloud Shell を起動する」をご覧ください）で、rate-limit-and-deny-tcp という名前のバックエンド サービス セキュリティ ポリシーを次のように作成します。
gcloud compute security-policies create rate-limit-and-deny-tcp \
--description "policy for tcp proxy rate limiting and IP deny"
セキュリティ ポリシーにルールを追加する
次に、Cloud Armor ポリシー「rate-limit-and-deny-tcp」に拒否リスト ルールを追加します。
gcloud compute security-policies rules create 1000 --action deny --security-policy \ rate-limit-and-deny-tcp --description "deny test-server1" --src-ip-ranges \ "enter-test-server-1ip-here"
Cloud Armor セキュリティ ポリシー「rate-limit-and-deny-tcp」にレート制限ルールを追加する
gcloud compute security-policies rules create 3000 \ --security-policy=rate-limit-and-deny-tcp \ --expression="true" --action=rate-based-ban --rate-limit-threshold-count=5 \ --rate-limit-threshold-interval-sec=60 --ban-duration-sec=300 \ --conform-action=allow --exceed-action=deny-404 --enforce-on-key=IP
TCP プロキシ バックエンド サービスにポリシーを接続します。
次のコマンドを実行して、セキュリティ ポリシーが TCP プロキシ バックエンド サービスに接続されていることを確認します。
gcloud compute backend-services update my-tcp-lb --security-policy \ rate-limit-and-deny-tcp
TCP プロキシ ロードバランサでロギングを有効にする
gcloud beta compute backend-services update my-tcp-lb \ --enable-logging --logging-sample-rate=1
7. 拒否リスト ルールを検証する
拒否リスト ルールで指定された IP を持つテストサーバーにログインし、次のコマンドを実行して拒否リスト ルールを検証します。
Curl LB_IP:110
即時リクエストでは LB からレスポンスが返される場合がありますが、curl リクエストが拒否またはドロップされるまで待ってから、Cloud Logging のログを調べて、トリガーされた IP 拒否ルールのログエントリを確認します。
Cloud Logging に移動し、[リソース] でリソースタイプを「tcp_ssl_proxy_rule」として選択し、バックエンド ターゲットを「my-tcp-lb」に設定します。
フィルタリング用に定義されたリソースを使用して、ログエントリの PRIORITY 値 1000 から IP 拒否ルールが有効であり、拒否ルールと拒否された IP から両方が指示されたため、構成されたアクション 「DENY」が有効であることを確認できます。
8. レート制限ルールを検証する
定義されたしきい値（1 分あたり 5 件のリクエスト）を超える多数のリクエストを短時間に送信して、レート制限ルールが有効であることを確認します。
完了したら、Cloud Armor サービスで [ログを表示] をクリックします。Cloud Logging に移動し、ロードバランサでログをフィルタして、受信した Cloud Armor ログを確認できます。
レート制限エントリは、次のスクリーンショットのようになります。ログエントリの 優先度値が 3000 であることから、レート制限ルールが有効であることが確認できます。また、設定されたアクションから、レート制限ルールの指示に従って「レートベースの禁止」アクションが有効であることも確認できます。
9. 環境のクリーンアップ
未使用のインフラストラクチャの運用コストが発生しないように、作成したインフラストラクチャを必ずクリーンアップしてください。
最も簡単な方法は、GCP でプロジェクト全体を削除して、管理対象外のダングル リソースが残らないようにすることです。ただし、次のコマンドを使用して個々のリソースを削除します。
TCP プロキシ ロードバランサ
gcloud compute target-tcp-proxies delete my-tcp-lb
インスタンス グループ
gcloud compute instance-groups unmanaged delete vm-ig1
作成された 2 つのテスト用 VM インスタンス
gcloud compute instances delete Instance_name --zone=instance_zone
バックエンド サービス
gcloud compute backend-services delete BACKEND_SERVICE_NAME
ポリシー内の Cloud Armor ルール
gcloud compute security-policies rules delete 1000 \ --security-policy=rate-limit-and-deny-tcp && gcloud compute security-policies rules delete 3000 \ --security-policy=rate-limit-and-deny-tcp
Cloud Armor セキュリティ ポリシー
gcloud compute security-policies delete rate-limit-and-deny-tcp