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が表示されます。
期間内に新規に検出されたパラメータがある、またはUnusedステータスになったパラメータがあるエンドポイントにはChangedが表示されます。エンドポイントの詳細では、そのようなパラメータに対応するラベルが表示されます。
- パラメータは、期間内に検出された場合、Newステータスになります。
- パラメータは、7日間データを一切受け渡さない場合、Unusedステータスになります。
- その後Unusedステータスのパラメータが再びデータを受け渡した場合は、Unusedステータスが解除されます。
期間内にUnusedステータスになったエンドポイントにはUnusedが表示されます。
- エンドポイントは、7日間リクエストされない（応答コード200が返らない）場合、Unusedステータスになります。
- その後Unusedステータスのエンドポイントに再びリクエストがあり（応答コード200が返る）、Unusedステータスが解除されます。

どの期間を選択しても、New、Changed、Unusedのいずれのマークも表示されない場合は、その期間にAPIの変更はありません。

rogueとしてマークされたエンドポイント向けの簡単なヒント：

New、Changed、Unusedラベルにマウスオーバーすると、変更が発生した時期を確認できます。
Changedのエンドポイントの詳細に移動すると、このステータスの理由（NewになったパラメータやUnusedステータスになったパラメータ）を確認できます。ラベルにマウスオーバーすると、パラメータの変更が発生した時期を確認できます。
直近7日間のすべての種類の変更のカウンターはAPI Discovery Dashboardに表示されます。

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

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

Changes in APIフィルターは動作が異なり、選択した期間に変更されたエンドポイントのみを表示し、それ以外はすべて除外します。

例を考えます。今日時点でAPIには10個のエンドポイントがあります（以前は12個ありましたが、そのうち3個は10日前にUnusedとしてマークされました）。この10個のうち1つは昨日追加され、2つはパラメータに変更があり、1つは5日前、もう1つは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の変更についてメッセンジャー、SIEM、またはログ管理システムに即時通知を送るには、Changes in API条件を持つtriggersを構成します。

新規、変更あり、または未使用のエンドポイントに関するメッセージ、あるいはそれらすべての変更に関するメッセージを受け取ることができます。監視したいアプリケーションやホスト、および含まれる機密データの種類で通知を絞り込むこともできます。

Triggerの例: Slackでの新規エンドポイント通知

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

トリガーをテストするには：

USまたはEUクラウドのWallarm Console → Integrationsに移動し、Slackとの連携を構成します。
Triggersセクションで、上記のとおりTriggerを作成します。
example.com/usersエンドポイントに対して、200（OK）の応答が得られるように複数のリクエストを送信します。
API Discoveryセクションで、エンドポイントがNewマーク付きで追加されたことを確認します。

Slackチャンネルに次のようなメッセージが届いていることを確認します：

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

Notification type: api_structure_changed

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

    Client: Client 001
    Cloud: US

    Details:

      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