EOL多テナントノードのアップグレード¶
この手順では、バージョン3.6以下のEOL多テナントノードをバージョン5.0までアップグレードする手順について説明します。
Requirements¶
-
以降のコマンドは、technical tenant accountに追加されたGlobal administratorロールを持つユーザーによって実行される必要があります
-
US Wallarm Cloudを利用する場合は
https://us1.api.wallarm.com、EU Wallarm Cloudをご利用の場合はhttps://api.wallarm.comにアクセスできることが必要です。ファイアウォールでアクセスがブロックされていないことをご確認ください -
攻撃検知ルールおよびAPI仕様のアップデートのダウンロード、並びにホワイトリスト、ブラックリスト、またはグレイリストに登録された国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへのアクセスが必要です
Step 1: Wallarmサポートチームに連絡¶
多テナントノードのアップグレード中に最新バージョンのcustom ruleset building機能を入手するために、Wallarm support teamの支援を依頼してください
アップグレードのブロック
間違ったバージョンのcustom ruleset building機能を使用すると、アップグレードプロセスがブロックされる可能性があります
サポートチームは、多テナントノードのアップグレードおよび必要な再構成に関するあらゆる質問にお答えします
Step 2: 標準アップグレード手順に従う¶
以下は標準の手順です：
多テナントノードの作成
Wallarmノードの作成時に、必ずMulti-tenant nodeオプションを選択してください：
Step 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宛のトラフィックは、20と23の値を介してクライアント1に関連付けられており、API requestを通じてこのクライアントにリンクされています。 -
同様に、他のアプリケーションをテナントにリンクするためにAPIリクエストが送信されているはずです。
-
テナントとアプリケーションは別個のエンティティであるため、異なるディレクティブで設定するのが合理的です。また、追加のAPIリクエストを避けるため、構成自体でテナントとアプリケーション間の関係を定義するのが望ましいです。これらは現在の構成では欠落していますが、以下で説明する新しい5.xのアプローチにより利用可能になります。
5.xのアプローチを確認する¶
バージョン5.xでは、ノード構成においてテナントを定義する方法としてUUIDを使用します。
構成を変更するには、以下の手順を実行してください：
-
テナントのUUIDを取得します。
-
NGINX構成ファイルにテナントを含め、それぞれのアプリケーションを設定します。
テナントのUUIDを取得する¶
テナントの一覧を取得するには、Wallarm APIへ認証済みのリクエストを送信します。認証方法はtenant creationに使用されたものと同じです。
-
後で関連するUUIDを特定するために、
clientidを取得します：Wallarm ConsoleのユーザーインターフェイスのID列から
clientidをコピーしてください：
-
ルート
/v2/partner_clientへGETリクエストを送信します：自前のクライアントから送信したリクエストの例
ここで
PARTNER_IDは、tenant作成手順のStep 2で取得したものです。レスポンス例：
-
レスポンスから
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ディレクティブを通じて定義されています。
Step 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.