APIの変更追跡 ¶

もしAPIに変更が発生した場合、API DiscoveryはビルトインのAPIインベントリを更新し、変更箇所を強調表示し、いつ何が変更されたのかの情報を提供します。また、すべてもしくは一部の変更に対する通知を設定することができます。

企業では複数のチームや異なるプログラミング言語、さまざまな言語フレームワークが存在する場合があります。したがって、APIへの変更は異なるソースからいつでも発生する可能性があり、管理が困難となります。セキュリティ担当者にとって、変更をできるだけ早く検出し、分析することが重要です。見逃すと、以下のようなリスクが生じる可能性があります:

開発チームが別のAPIを持つサードパーティライブラリを使用し始め、セキュリティ専門家に通知しない場合があります。この結果、企業は監視されず脆弱性検査されないエンドポイントを持つことになり、潜在的な攻撃経路となる可能性があります。
個人識別情報（PII）がエンドポイントに転送され始める場合があります。計画外のPII転送は、規制当局の要求事項への準拠違反および信用リスクにつながる可能性があります。
ビジネスロジック上重要なエンドポイント（例：/login、/order/{order_id}/payment/）が呼び出されなくなる場合があります。
転送すべきでないその他のパラメータ（例：is_admin―エンドポイントにアクセスして管理者権限で操作を試みる際のもの）が転送され始める場合があります。

APIの変更点の強調表示¶

API Discoveryセクションを開くたびに、Changes sinceフィルターはLast week状態となり、直近1週間以内の変更が強調表示されます。表示期間を変更するには、Changes sinceフィルターで日付を再設定してください。

エンドポイント一覧では、次のマークでAPIの変更が強調表示されます:

New ― 期間内に一覧に追加されたエンドポイント
Changed ― 期間内に新たに発見されたパラメータまたはUnusedステータスが付与されたパラメータを持つエンドポイント
- 期間内に発見されたパラメータはNewステータスとなります。
- 7日間データが送信されないパラメータはUnusedステータスとなります。
- その後、Unusedステータスのパラメータが再びデータを送信すると、Unusedステータスは解除されます。
Unused ― 期間内にUnusedステータスが付与されたエンドポイント
- 7日間（200のレスポンスコード）リクエストされなかったエンドポイントはUnusedステータスとなります。
- その後、Unusedステータスのエンドポイントが再びリクエストされる（200のレスポンスコードを受け取る）と、Unusedステータスは解除されます。

どの期間を選択しても、New、Changed、Unusedのマークが一切表示されない場合、その期間中にAPIの変更がなかったことを意味します。

エンドポイントに表示されるクイックヒント:

New、ChangedまたはUnusedラベルにマウスオーバーして、変更が発生した日時を確認してください。
Changedエンドポイントの詳細に移動して、このステータスの理由を確認してください。新規のパラメータおよびUnusedステータスになったパラメータについては、ラベルにマウスオーバーすると、パラメータ変更の日時が表示されます。
直近7日間のすべての変更のカウントはAPI Discovery Dashboardに表示されます。

APIの変更のフィルタリング¶

API Discoveryセクションでは、Changes sinceフィルターを使用することで、選択した期間内に変更があったエンドポイントのみを強調表示しますが、変更のないエンドポイントはフィルタリングされません。

Changes in APIフィルターは挙動が異なり、選択した期間内に変更があったエンドポイントのみを表示し、その他のエンドポイントはすべてフィルタリングします。

例を考えます: 例えば、今日あなたのAPIには10個のエンドポイントが存在します（以前は12個ありましたが、10日前に3個がUnusedとしてマークされました）。この10個のうち1個は昨日追加され、2個はそれぞれ5日前と10日前にパラメータの変更が発生しているとします:

今日、API Discoveryセクションを開くたびに、Changes sinceフィルターはLast week状態となり、ページには10個のエンドポイントが表示され、Changes列には、そのうち1個にNewマーク、1個にChangedマークが表示されます。
Changes sinceをLast 2 weeksに切り替えると、13個のエンドポイントが表示され、Changes列には、1個にNewマーク、2個にChangedマーク、3個にUnusedマークが表示されます。
Changes in APIをUnused endpointsに設定すると、3個のエンドポイントが表示され、すべてにUnusedマークが付きます。
Changes in APIをNew endpoints + Unused endpointsに変更すると、4個のエンドポイントが表示され、うち3個にUnusedマーク、1個にNewマークが付きます。
Changes sinceを再びLast weekに切り替えると、1個のエンドポイントが表示され、Newマークが付きます。

通知の受信方法¶

APIの変更に関する即時通知をメールまたはメッセンジャーで受け取るには、Changes in API条件を設定したtriggersを構成してください。

新しい、変更された、またはUnusedになったエンドポイントについて、あるいはこれらすべての変更についてのメッセージを受け取ることができます。また、監視したいアプリケーションやホスト、表示されるセンシティブデータの種類によって通知を絞り込むことも可能です。

トリガー例: Slackにおける新規エンドポイント通知

この例では、API Discoveryモジュールによってexample.com APIホストの新規エンドポイントが検出された場合、その通知があなたが設定したSlackチャンネルに送信されます。

トリガーのテスト方法:

Wallarm Console → Integrationsに移動し、USまたはEUクラウドでSlackとの連携を設定してください。
Triggersセクションで、上記のようにトリガーを作成してください。
example.com/usersエンドポイントに対して複数のリクエストを送信し、200（OK）レスポンスを受け取ってください。
API Discoveryセクションで、エンドポイントがNewマーク付きで追加されたことを確認してください。

Slackチャンネル内のメッセージを以下のように確認してください:

[wallarm] API内で新しいエンドポイントが検出されました

通知タイプ: api_structure_changed

API内で新規のGET example.com/usersエンドポイントが検出されました。

    Client: Client 001
    Cloud: US

    詳細:

      application: Application 1802
      domain: example.com
      endpoint_path: /users
      http_method: GET
      change_type: added
      link: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers