EOLマルチテナントノードのアップグレード¶
本手順では、サポート終了（EOL）のマルチテナントノード（バージョン3.6以下）を最新の6.xへアップグレードする手順を説明します。
要件¶
-
テクニカルテナントアカウント配下でGlobal administratorロールが付与されたユーザーによる以降のコマンド実行
-
US Wallarm Cloudで作業する場合は
https://us1.api.wallarm.com、EU Wallarm Cloudで作業する場合はhttps://api.wallarm.comへのアクセス。ファイアウォールでアクセスがブロックされていないことを確認します -
以下のIPアドレスへのアクセス（攻撃検出ルールとAPI仕様の更新ダウンロード、ならびにallowlisted、denylisted、graylistedの国・地域・データセンターに対する正確なIPの取得のため）
ステップ1: Wallarmサポートチームに連絡¶
マルチテナントノードのアップグレード中にカスタムルールセットのビルド機能の最新バージョンを利用できるようにするため、Wallarmサポートチームに支援を依頼します。
アップグレードのブロック
カスタムルールセットのビルド機能のバージョンが正しくない場合、アップグレード処理がブロックされる可能性があります。
サポートチームは、マルチテナントノードのアップグレードや必要な再設定に関するすべての質問にも対応します。
ステップ2: 標準的なアップグレード手順に従う¶
標準手順は以下のとおりです:
マルチテナントノードの作成
Wallarmノードを作成する際は、Multi-tenant nodeオプションを選択してください:
ステップ3: マルチテナンシーを再設定¶
トラフィックをテナントおよびそのアプリケーションに関連付ける設定を書き換えます。以下に例を示します。この例では:
-
テナントはパートナーのクライアントを表します。パートナーには2人のクライアントがいます。
-
tenant1.comおよびtenant1-1.com宛てのトラフィックはクライアント1に関連付ける必要があります。 -
tenant2.com宛てのトラフィックはクライアント2に関連付ける必要があります。 -
クライアント1には3つのアプリケーションもあります:
tenant1.com/logintenant1.com/userstenant1-1.com
これら3つのパス宛てのトラフィックは対応するアプリケーションに関連付け、それ以外はクライアント1の汎用トラフィックと見なす必要があります。
以前のバージョンの設定を確認¶
3.6では、次のように設定できます:
server {
server_name tenant1.com;
wallarm_application 20;
...
location /login {
wallarm_application 21;
...
}
location /users {
wallarm_application 22;
...
}
server {
server_name tenant1-1.com;
wallarm_application 23;
...
}
server {
server_name tenant2.com;
wallarm_application 24;
...
}
...
}
上記設定に関する注意事項:
-
tenant1.comおよびtenant1-1.com宛てのトラフィックは、/v2/partner/111/partner_clientへのAPIリクエスト経由でこのクライアントに紐づけられた20および23の値によってクライアント1に関連付けられています。 -
他のアプリケーションをテナントに関連付けるには、同様のAPIリクエストを送信する必要がありました。
-
テナントとアプリケーションは別個のエンティティであるため、異なるディレクティブで設定するのが理にかなっています。また、追加のAPIリクエストを避けられると便利です。設定自体でテナントとアプリケーションの関係を定義できるのが理想です。これらは現行の設定にはありませんが、後述する新しい6.xのアプローチで可能になります。
6.xのアプローチを確認¶
バージョン6.xでは、ノード設定におけるテナントの指定はUUIDで行います。
設定を書き換えるには、次を実施します:
-
テナントのUUIDを取得します。
-
テナントを含めてアプリケーションをNGINX設定ファイルで指定します。
テナントのUUIDを取得¶
テナント一覧を取得するには、Wallarm APIに認証付きリクエストを送信します。認証方法は、テナント作成に使用する方法と同じです。
-
後で紐づくUUIDを特定するために、
clientid（複数可）を取得します:Wallarm ConsoleのユーザーインターフェイスのID列から
clientid（複数可）をコピーします:
-
/v2/partner_clientルートにGETリクエストを送信します:独自クライアントから送信するリクエストの例
ここで、
PARTNER_IDはテナント作成手順のステップ2で取得したIDです。レスポンス例:
-
レスポンスから
clientid（複数可）をコピーします。
-
-
各テナントのUUIDを取得するには、
v1/objects/clientルートにPOSTリクエストを送信します:独自クライアントから送信するリクエストの例
レスポンス例:
-
レスポンスから
uuid（複数可）をコピーします。
NGINX設定ファイルにテナントを含め、アプリケーションを設定¶
NGINX設定ファイルで次を実施します:
-
取得したテナントUUIDを
wallarm_partner_client_uuidディレクティブに指定します。 -
保護対象のアプリケーションIDを
wallarm_applicationディレクティブに設定します。ノード3.6以下で使用していたNGINX設定にアプリケーション設定が含まれている場合は、テナントUUIDのみを指定し、アプリケーション設定は変更せずに維持します。
例:
server {
server_name tenant1.com;
wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
...
location /login {
wallarm_application 21;
...
}
location /users {
wallarm_application 22;
...
}
server {
server_name tenant1-1.com;
wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
wallarm_application 23;
...
}
server {
server_name tenant2.com;
wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222;
...
}
...
}
上記の設定では:
-
テナントとアプリケーションは異なるディレクティブで設定されています。
-
テナントとアプリケーションの関係は、NGINX設定ファイル内の該当ブロックにある
wallarm_applicationディレクティブで定義されています。
ステップ4: Wallarmマルチテナントノードの動作をテスト¶
-
Send the request with test Path Traversal attack to a protected resource address:
If traffic is configured to be proxied to
example.com, include the-H "Host: example.com"header in the request. -
Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.
-
Optionally, test other aspects of the node functioning.