1. はじめに
Google Cloud Load Balancing は、世界中の 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 タイプのトラフィックをプロキシできます。
この Codelab では、バックエンド サービスを使用する TCP/SSL プロキシ ロードバランサを作成し、Cloud Armor を使用して、ロードバランサへのアクセスを特定のユーザー クライアントのセットのみに制限します。
学習内容
- TCP/SSL プロキシ ロードバランサの作成方法
- Cloud Armor セキュリティ ポリシーの作成方法
- Cloud Armor で TCP/SSL プロキシ ロードバランサの IP 拒否リストルールを作成する方法
- Cloud Armor で TCP プロキシ ロードバランサのレート制限ルールを作成する方法
- TCP/SSL ロード バランシング バックエンド サービスにセキュリティ ポリシーを追加する方法
必要なもの
- Google Compute Engine に関する基本的な知識（Codelab）
- ネットワークと TCP/IP に関する基本的な知識
- Unix / Linux コマンドラインに関する基本的な知識
- Networking in the 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 USD 分の無料トライアル プログラムをご利用いただけます。
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 つのインスタンスを作成する。instance1-b1 をゾーン us-central1-b に作成する
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"
インスタンス 1-b2 をゾーン us-central1-b に作成する
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 を作成する
パブリック IP アドレスを持ち、test-server1 と test-server2 という名前の 2 つのインスタンスを作成する必要があります。
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 の test-server にログインして拒否リストルールを検証し、次のコマンドを実行します。
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 のログを受信したときにそのログを確認できます。
レート制限のエントリは、以下のスクリーンショットのようになります。ログエントリの PRIORITY 値 3000 と、構成されたアクションからレート制限ルールの指示のとおりに、"RATE BASED BAN" アクションが有効であることから、レート制限ルールが有効であることを確認できます。
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