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 タイプのトラフィックをプロキシできます。
この Codelab では、バックエンド サービスを使用して TCP/SSL プロキシ ロードバランサを作成し、Cloud Armor を使用して、ロードバランサへのアクセスを特定のユーザー クライアントのセットのみに制限します。
学習内容
- TCP/SSL プロキシ ロードバランサを作成する方法
- Cloud Armor セキュリティ ポリシーの作成方法
- Cloud Armor で TCP/SSL プロキシ ロードバランサの IP 拒否リストルールを作成する方法
- Cloud Armor で TCP プロキシ ロードバランサのレート制限ルールを作成する方法
- TCP/SSL ロード バランシング バックエンド サービスにセキュリティ ポリシーを追加する方法
必要なもの
- Google Compute Engine に関する基本的な知識（コードラボ）
- ネットワークと 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 米ドル分の無料トライアル プログラムをご利用いただけます。
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 を作成します。
パブリック IP アドレスを持つ 2 つのインスタンスを作成し、それぞれ 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 を持つ test-server にログインし、次のコマンドを実行して、拒否リスト ルールを検証します。
Curl LB_IP:110
即時リクエストでは、LB からレスポンスが返されることがありますが、curl リクエストが拒否またはドロップされるまで待ってから、Cloud Logging のログを確認して、IP 拒否ルールのトリガーに関するログエントリを確認します。
Cloud Logging に移動し、[リソース] でリソースタイプとして「tcp_ssl_proxy_rule」を選択し、バックエンド ターゲットを「my-tcp-lb」に設定します。
フィルタリング用に定義されたリソースを使用して、ログエントリの優先度値 1000 と構成されたアクション 「DENY」から、IP 拒否ルールが有効であることを検証できます。これは、拒否ルールと拒否される IP の両方から指示されたためです。
8. レート制限ルールを検証する
定義されたしきい値（1 分あたり 5 件のリクエスト）を超える多数のリクエストを短時間で送信して、レート制限ルールが有効であることを検証します。
完了したら、Cloud Armor サービスでログを表示をクリックします。これにより、Cloud Logging に移動し、ロードバランサでログをフィルタして、Cloud Armor ログの受信状況を確認できます。
レート制限のエントリは、以下のスクリーンショットのようになります。ログエントリの PRIORITY 値が 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