Schema-Based Testingのセットアップ ¶

この記事では、WallarmのSchema-Based Testingを有効化して構成する方法を説明します。

有効化¶

Schema-Based Testingはデフォルトで無効です。有効化するには次を実行します。

1. sales@wallarm.comに連絡し、アカウントでSecurity Testingサブスクリプションプランを有効化します。

2. Security Testing → Schema-Based → Test policiesタブに移動し、少なくとも1つのポリシーを作成します。

前提条件 - トークン¶

Schema-Based Testingでは、実行中のDockerコンテナとWallarm Cloudの間でデータ交換を認可するためのトークンが必要です。トークンは次の2通りの方法で作成できます。

• 自動 - 任意のポリシーからDockerコマンドを初めてコピーしようとした際に、Schema-Based Testingが自動でトークンを作成し、docker runコマンドに含めます。他のポリシーは既存のトークンを再利用します。

• 手動 - Wallarm ConsoleでSettings → API Tokensに移動し、New tokenをクリックします。作成時にToken usageをSchema-Based Testing agentに設定します。すべてのポリシーがこのトークンを使用します。

テストポリシーの設定¶

テストポリシーは、OpenAPI仕様(OAS)またはPostmanコレクションを基礎として設定できます。1つのテストポリシーは1種類のテスト(OASベースまたはPostmanベースのいずれか)のみを対象とする点にご注意ください。

• OASは入力検証、インジェクション、設定ミスの検出に重点を置きます。

• Postmanは複雑なビジネスロジックやアクセス制御の脆弱性に重点を置きます。

OASベース¶

OpenAPI仕様(OAS)ベースのテストポリシーでは、次の項目を永続的に定義します。

• アプリケーションのOpenAPI specification

• 実行するテスト

すべてのテスト実行で共通の永続パラメータに加えて、各テストポリシーには、各テスト実行ごとに再定義できるパラメータ（Runtime parameters）を任意で含めることができます。Runtime parametersを再定義できることは、DockerをCI/CDパイプラインに組み込む際に役立ちます。

• アプリケーションのTarget URL

  （各実行時に再定義できますが、初期値の指定が必要です）

• 認証パラメータ

テストポリシーを設定するには:

1. Wallarm Console → Security Testing → Schema-Based → Test policiesに移動します。

2. Add policyをクリックし、OpenAPI仕様ファイルを添付します。

3. 実行するテストタイプを選択します。

4. Target URLを設定します（各テスト実行時に動的に再定義できます）。

5. 任意で、認証のRuntime parametersを追加します。

   

Postmanコレクションベース¶

Postmanベースのセキュリティテストにより、通常のAPIテストと並行してセキュリティスキャンを自動化し、各API実行が脆弱性について十分に検査されるようにできます。

Postmanコレクションの事前チェック¶

Schema-BasedセキュリティテストにPostmanデータを使用する前に、次を確認します。

1. コレクションおよび環境ファイルに次が含まれていることを確認します。

   • APIエンドポイントの機能テスト
   • 対象アプリケーションの場所
   • すべての環境変数の設定
   • 対象アプリケーションに認証するために必要な認証情報

2. （推奨）Postmanコレクションが正常に動作するかを確認します。例えば、次のコマンドを実行します。

   newman run my_collection.json -e my_environment.json
   

   これにより、Postmanコレクションの品質、Target URLの到達性、必要な変数がすべて指定されているかなど、問題の有無を事前に把握できます。

Wallarmでのテストポリシー設定¶

Wallarmでは、Postmanコレクションベースのテストポリシーで次を定義します。

• アプリケーションのPostman collection。

• Postman environment file(s)（すべての設定がメインのコレクションファイルに含まれている場合は任意です）。

  Target URLと認証

  アプリケーションのTarget URLと認証パラメータは、Postmanコレクションまたは環境ファイルで定義します。

• Postmanコレクションに基づくセキュリティテストでは、テストケースの選択は現在サポートされていません。

テストポリシーを設定するには:

1. Wallarm Console → Security Testing → Schema-Based → Test policiesに移動します。

2. Add policyをクリックし、SourceをPostman collectionに設定します。

3. Postmanコレクションファイルを添付します。

4. 任意で、Postman環境ファイルを添付します。2つのファイルを添付すると、異なる変数値（例: 異なる認証情報）で2回テストを実行し、結果を比較できます。

   

ビジネスロジックのセキュリティテスト¶

ビジネスロジックのテスト（OWASP API1:2023 オブジェクトレベル認可の不備 (BOLA)およびOWASP API5:2023 機能レベル認可の不備 (BFLA)）では、WallarmのSchema-Basedセキュリティテストは少なくとも2人の異なる認証済みユーザーからのAPIトラフィックを必要とし、できれば権限が異なるユーザー（例: 管理者と一般ユーザー）が望ましいです。この多様性により、より効果的なビジネスロジックのセキュリティテストが可能になり、より徹底的な評価が提供されます。

例1: 2人のユーザーのリクエストを含むPostmanコレクションの使用¶

次を実施します。

1. 認証済みユーザー2人のリクエストを含むPostmanコレクションを作成します。例えば、対象アプリケーションで、User AとUser Bのログインおよびアクティビティのリクエストを同一コレクションに含めます。

   

2. すべてのリクエストが正しく実行されることを確認します。

3. 作成したPostmanコレクションでテストポリシーを作成します。

例2: 複数ユーザー向けにPostman環境を使用する¶

次を実施します。

1. それぞれ異なる認証済みユーザーの認証情報を持つ2つのPostman環境ファイルを作成します。例:

   • env1.jsonはUser A用
   • env2.jsonはUser B用

2. Postmanコレクションと両方の環境ファイルを使用するテストポリシーを作成します。

   この構成では、env1.json（User A）とenv2.json（User B）でそれぞれ1回ずつ、合計2回コレクションが実行されるため、各リクエストは両方のユーザーコンテキストで実行されます。

既存ポリシーの編集¶

作成済みのポリシーは編集できます。ポリシー自体をクリックするとDockerコマンド情報が表示されますが、編集ボタンをクリックすると編集ダイアログにアクセスできます。

Dockerの実行¶

テストポリシーを作成すると、アプリケーションのテストを開始できるdocker runコマンドが提供されます。

1. Wallarm Console → Security Testing → Schema-Based → Test policiesに移動します。

2. 対象のポリシーをクリックします。ポリシーのDockerコマンドが表示されます。

   

3. 必要に応じて、Dockerのログレベルとフォーマットを再定義します。

4. コマンドをコピーして実行するか、CI/CDパイプラインに組み込みます。これにより、ポリシーで選択したセキュリティテストがアプリケーションに対して実行されます。

   OASベースの実行では、Dockerのrunコマンドに対応する-eパラメータを追加することで、各実行時にポリシーのRuntime parametersを再定義できる点に注意してください。例:

   -e TARGET_URL="http://dvapi.st.wallarm.tools" 
   -e AUTH_HEADER="Authorization: Bearer <VALUE>"
   

   Rewrite authentication dataおよび/またはRewrite target URLチェックボックスを選択すると、コマンドに次が追加され、これらのパラメータの再定義を簡単にできます。

   -e AUTH_HEADER="${AUTH_HEADER}" -e TARGET_URL="${TARGET_URL}"
   

5. Test runsタブで実行の統計とテスト実行結果を表示します。

ポリシーの削除¶

テストポリシーを削除できます。削除した場合:

• 過去のテスト実行に関する情報はそのまま保持されます

• 削除したポリシーに基づくDockerのコマンドは実行できません

• ポリシーのDockerコンテナが実行中の場合、そのまま実行が継続されます

• ポリシーのDockerコンテナが停止した後は、再実行できません

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send