API Sessionsのセットアップ ¶

API Sessionsにはセッション識別のための組み込みルールが含まれており、有効化されたWallarmnodeがあるだけで動作し始めます。必要に応じて、本記事で説明する方法でAPI Sessionsを細かく調整できます。

セッションコンテキスト¶

API Sessionsにおけるコンテキストとは、リクエストデータを論理的なセッションにグループ化し、レスポンスデータやメタデータを付与して、セッションアクティビティに関するより深い洞察を提供するための情報です。コンテキストを構成すると、各セッションと関連付けて追跡すべき側面や追加データを指定できます。

追加のリクエスト/レスポンスパラメータを加え、セッションを機微なビジネスフローに関連付け、ユーザーおよびユーザーロールの識別に使用できるパラメータを強調表示することで、セッションコンテキストを設定します。

追加パラメータ¶

API Sessionsでは、セッション内のリクエスト詳細にデフォルトで次が含まれます:

• セッショングルーピングに有効だったリクエストまたはレスポンスのパラメータ―独自のもの、または組み込みセットのもの（API session ID parametersグループで強調表示されます）。

• Mitigation controlsにより追加されたパラメータ（存在する場合）。

• 悪意のあるリクエストの場合―リクエスト内容全体。

セッションの内容（アクターが何をどの順序で実行し、どのようなレスポンスが返ったか）を把握するために必要であれば、リクエストとそれに関連するレスポンスの両方に任意の追加（コンテキスト）パラメータを追加できます。追加するには、Wallarm Console → API Sessions → Session context parametersでこれらのパラメータを追加します。追加後、WallarmはそれらをWallarm Cloudにエクスポートし、セッションリクエストの詳細（API session parametersグループ）に表示します。

いくつかの例を示します。

リクエストのjwt_payloadからユーザー名を取得する場合:

{
  "token_type": "access",
  "exp": 1741774186,
  "iat": 1741773706,
  "jti": "jti_value",
  "user_id": 932,
  "details": {
    "username": "john-doe@company-001.com",
    "rnd": "some_data",
    "contact": {
      "contactId": 438,
      "contactUUID": "contact_UUID_value",
      "firstName": "John",
      "lastName": "Doe",
      "portalSecurityLevel": 3,
      "companyId": 255,
      "companyName": "Company 001",
      "companyUUID": "company_UUID_value"
    }
  }
}

...は次のように表示されます:

リクエストボディからemailパラメータを取得する場合:

レスポンスボディからproduct_idパラメータを取得する場合:

リクエストヘッダーからJWTトークンを取得する場合:

ユーザーとロール¶

セッションのユーザー名およびそのロールの命名に使用すべきセッションパラメータを強調表示できます。そのためには、Wallarm Console → API Sessions → Session context parametersでパラメータを追加し、TypeからUserまたはRoleを選択します。

ユーザーおよびそのロールの識別に使用するパラメータを構成すると、以降、セッションに対してこれらのパラメータが設定されるようになります。ユーザーとロールでセッションをフィルタリングできます。

Mitigation controls¶

Mitigation controlsはセッションコンテキストにさらなるパラメータを追加できます。例えば、BOLA protectionのMitigation controlは、object_idパラメータを列挙対象パラメータとして、またはスコープのフィルターとして使用したい場合があります。このようなパラメータがAPI Sessions → Session context parametersに追加されていない場合は、Mitigation controlの設定内で直接追加できます。API Sessionでは非表示として追加されます。つまり、リクエストに存在する場合はセッション詳細にこれらのパラメータが表示されますが、Session context parametersの設定画面には表示されません。

非表示で追加されたパラメータは20個のパラメータ枠を消費しません。これらのパラメータは、誤って削除されることを防ぐために非表示になっています。削除するとMitigation controlによる保護が停止する可能性があるためです。

セッションのグルーピング¶

Wallarmは、選択されたリクエストおよび/またはレスポンスのヘッダー/パラメータの同一の値に基づいて、アプリケーションのトラフィックに含まれるリクエストをユーザーセッションにグループ化します。設定では、グルーピングキーとしてマークされたパラメータがこれに該当します。グルーピングキーの動作は例をご覧ください。

デフォルトでは、そのようなパラメータの組み込みセットでセッションを識別します（Wallarm Consoleには表示されません）。ロジックとしては、PHPSESSIDやSESSION-IDヘッダーなどの一般的な識別パラメータを試行し、それが機能しない場合は、リクエスト送信元IPとuser-agentの組み合わせ（またはuser-agentが存在しない場合は少なくともIP）に基づいてセッションを形成します。

アプリケーションのロジックに基づく独自の識別パラメータを追加できます。追加するには、Wallarm Console → API Sessions → Session context parametersでリクエストまたはレスポンスのパラメータを追加し、そのパラメータに対してGroup sessions by this keyを選択します。

複数のグルーピングキーを追加できます。指定した順序で試行され、前のキーが機能しなかった場合にのみ次が試されます。ドラッグして順序を変更できます。独自のキーは常に組み込みのキーより先に試されます。

グルーピングキーの動作例

loginというルートがあり、レスポンスのresponse_body → json_doc → hash → tokenパラメータに特定の<TOKEN>を返すとします。以降のリクエストでは、この<TOKEN>がget → tokenまたはpost → json_doc → hash → tokenのどこかで使用されます。

グルーピングキーとして使用する3つのパラメータ（レスポンスボディ、GETおよびPOSTリクエスト用）を構成できます。次の順序で試行されます（前のキーが機能しなかった場合にのみ次が試されます）。

1. response_body → json_doc → hash → token

2. get → token

3. post → json_doc → hash → token

4. （組み込みセット。上記がいずれも機能しない場合に使用されます）

リクエスト:

• curl example.com -d '{in: 'bbb'}'、レスポンス '{token: aaa}' → セッション「A」（グルーピングキー#1が機能）

• curl example.com -d '{in: 'ccc'}' '{token: 'aaa'}'、トークンなしのレスポンス → セッション「A」（グルーピングキー#3が機能）

同じパラメータ値aaaにより、これらのリクエストは1つのセッションにグループ化されます。

データ保護¶

API Sessionsでは、nodeからCloudへのエクスポート対象は、皆さまが選択したパラメータのみに限定されます。それらに機微なデータが含まれる場合は、エクスポート前に必ずハッシュ化してください。ハッシュ化すると実際の値は判読不能に変換されます。つまり、パラメータの存在と特定だが不明な値が、分析のための限定的な情報のみを提供します。

機微なパラメータをハッシュ化するには、Wallarm Console → API Sessions → Session context parametersで追加した後、それらに対してHashing (secret)オプションを選択します。

Wallarmは選択したパラメータをエクスポート前にハッシュ化します。

解析対象トラフィック¶

API Sessionsは、Wallarm nodeが保護するように有効化されているすべてのトラフィックを解析し、セッションに編成します。特定のアプリケーション/ホストに解析を限定したい場合は、Wallarmサポートチームまでご連絡ください。

保存期間¶

API Sessionsセクションには直近1週間のセッションが保存・表示されます。より古いセッションは、最適なパフォーマンスとリソース消費のために削除されます。

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