シャドウAPI、オーファンAPI、ゾンビAPI
¶
「API Discovery」モジュールは、アップロードした仕様書と実際のトラフィックを比較することで、シャドウAPI、オーファンAPI、ゾンビAPIを自動的に識別します。
不正なAPIタイプ | 概要 |
---|---|
Shadow API | 正式な承認や監視なしに組織内に存在する、ドキュメントに記載されていないAPIです。 |
Orphan API | トラフィックを受信しない、ドキュメントに記載されたAPIです。 |
Zombie API | 誰もが無効化済みと想定している廃止済みのAPIですが、実際にはまだ使用されているAPIです。 |
セットアップ¶
不正なAPIの検出を開始するには、仕様書をアップロードして、不正API検出に使用する仕様書として選択し、検出パラメータを設定する必要があります。
仕様書とAPI自体は時間とともに変化するため、以下の点を考慮してください。
-
初回セットアップ後に比較が開始されます
-
APIの変更を検出した場合、比較が再開始されます
-
新しい設定を保存した場合、比較が再開始されます
-
新たなファイル(名前または完全なURI)を選択した場合、比較が再開始されます
-
URIからアップロードされたファイルに変更があった場合、かつRegularly update the specification(毎時更新)オプションが選択されている場合、比較が再開始されます
-
仕様書メニュー → Restart comparisonを使用して、いつでも比較を再開始できます
また、以前アップロードされた仕様書は、API Specifications → 仕様書詳細ウィンドウ → Download specificationからダウンロードできます。
ステップ1: 仕様書のアップロード¶
-
US CloudまたはEU CloudのAPI Specificationsセクションで、Upload specificationをクリックします。
-
仕様書のアップロードパラメータを設定し、アップロードを開始します。
仕様書のファイルが正常にアップロードされるまで、不正なAPI検出の設定を開始できない点にご注意ください。
ステップ2: 不正なAPI検出パラメータの設定¶
-
Rogue APIs detectionタブをクリックします。
API仕様施行
不正なAPI検出に加えて、仕様書はAPI仕様施行にも使用できます。
-
Use for rogue APIs detectionを選択します。
-
ApplicationsおよびHostsを選択します―選択されたホストに関連するエンドポイントのみが不正なAPIとして検索されます。
無効化¶
不正なAPI検出は、アップロードされた仕様書または複数の仕様書においてUse for rogue APIs detectionオプションが選択されているものに基づいて行われます。これらの仕様書でこのオプションのチェックを外す、または仕様書を削除すると、以下の結果となります。
-
この仕様書に基づく不正なAPI検出が停止されます。
-
以前にこの仕様書に基づいて検出された不正なAPIに関する**すべてのデータが削除されます。
検出された不正なAPIの表示¶
比較が完了すると、各仕様書に対してAPI Specificationsのリストに不正な(shadow、orphan、zombie)APIの数が表示されます。
また、API Discoveryセクションにも不正なAPIが表示されます。Rogue APIsフィルターを使用して、選択された比較に関連するshadow、orphan、および/またはzombie APIのみを表示し、その他のエンドポイントを除外してください。
これらのエンドポイントの詳細、Specification conflictsセクションで、shadow/zombie/orphanが検出された際に使用された仕様書が示されます。
また、Shadow APIはAPI Discovery Dashboardの中で最もリスクの高いエンドポイントとして表示されます。
仕様書のバージョンとゾンビAPI¶
Shadow APIやOrphan APIとは異なり、Zombie APIは異なる仕様書のバージョン間の比較が必要です:
-
setup時にRegularly update the specificationオプションが選択されている場合は、仕様書をホストしているURLに新しいバージョンを配置するだけで、毎時間のスケジュールで、または仕様書メニューからRestart comparisonを選択すると直ちに処理されます。
-
Regularly update the specificationオプションが選択されていない場合:
- URLからアップロードしており、かつ新しい内容がある場合は、Restart comparisonをクリックしてください。
- ローカルマシンからアップロードする場合は、仕様書ダイアログを開き、新しいファイルを選択して変更を保存してください。ファイル名は異なる必要があります。
すべての場合、新しい内容が仕様書の新バージョンとみなされ、バージョンが比較されることでゾンビAPIが表示されます。
複数の仕様書を使用する場合¶
APIの異なる側面を記述するために複数の独立した仕様書を使用する場合、それらをいくつかまたはすべてWallarmにアップロード可能です。
API Discoveryセクションで、Compare to...フィルターを使用して仕様書の比較を選択すると、選択された仕様書に対してのみ、不正なAPIがIssues列内の特別なマークで強調表示されます。
通知の受け取り¶
新たに検出された不正なAPIについて、SIEM, SOAR, log management system or messengerへ即時通知を受け取るには、Wallarm ConsoleのTriggersセクションでRogue API detected条件を持つ1つ以上のトリガーを設定してください。
新たに検出されたshadow、orphan、またはzombie API、あるいはそのすべてについてのメッセージを受け取ることができます。また、監視対象のアプリケーションやホスト、及びそれらの検出に使用された仕様書によって通知を絞り込むことも可能です。
通知の受信方法
-
新たに検出された不正なAPIごとに1つの通知メッセージが発生します。
-
既に通知を受信している不正なAPIについては、比較が何度実施されても再度送信されません。
-
アップロードされた仕様書の設定を更新すると、すべてのorphan APIに関する通知が再送信されます(この仕様はshadowやzombie APIには適用されません)。
トリガー例:Slackでの新たに検出されたshadowエンドポイントに関する通知
この例では、API DiscoveryがSpecification-01
に記載されていない新しいエンドポイント(shadow API)を検出した場合、その通知が設定済みのSlackチャンネルへ送信されます。
トリガーのテスト方法:
-
USまたはEUクラウドのWallarm Console→Integrationsに移動し、integration with Slackを設定します。
-
API Discoveryセクションで、任意のAPI hostによりエンドポイントをフィルターしてから、結果を仕様書としてダウンロードし、
Specification-01
と命名します。 -
API Specificationsセクションで、
Specification-01
を比較のためにアップロードします。 -
Triggersセクションで、上記のようにトリガーを作成します。
-
ローカルの
Specification-01
ファイルから任意のエンドポイントを削除します。 -
API Specificationsセクションで、比較のために
Specification-01
を再アップロードします。 -
エンドポイントがIssues列でshadow APIマークを取得していることを確認します。
-
Slackチャンネルで次のようなメッセージが表示されているか確認します:
[wallarm] 新しいshadowエンドポイントがあなたのAPIで検出されました 通知タイプ: api_comparison_result あなたのAPIで新しいGET example.com/users shadowエンドポイントが検出されました。 クライアント: Client-01 クラウド: US 詳細: application: Application-01 api_host: example.com endpoint_path: /users http_method: GET type_of_endpoint: shadow link: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers specification_name: Specification-01
不正なAPIの種類とリスク¶
Shadow API¶
Shadow APIは、正式な承認や監視なしに組織のインフラ内に存在する、ドキュメントに記載されていないAPIを指します。
Shadow APIは、攻撃者がこれらを悪用して重要なシステムへアクセスし、貴重なデータを盗み、または運用を妨害することにより、ビジネスにリスクをもたらす可能性があります。さらに、APIは重要なデータへのゲートキーパーとして機能することや、さまざまなOWASP API脆弱性がAPIセキュリティを回避するために悪用される可能性がある点も、リスクを増大させます。
アップロードされたAPI仕様書の観点では、Shadow APIは実際のトラフィックに存在する(API Discoveryにより検出される)ものの、仕様書には記載されていないエンドポイントです。
WallarmでShadow APIを検出した場合、不足しているエンドポイントを追加するために仕様書を更新し、API全体を把握した上で、監視やセキュリティ対策を実施することができます。
Orphan API¶
Orphan APIは、トラフィックを受信しない、ドキュメントに記載されたAPIを指します。
Orphan APIの存在は、以下を含む検証プロセスの理由となる可能性があります:
-
Wallarmのトラフィックチェック設定を確認し、トラフィックが実際に受信されていないのか、またはWallarmノードにすべてのトラフィックが通過しない形で展開されているために表示されていないのか(例えば、誤ったトラフィックルーティングや、設定漏れにより別のWeb Gatewayが存在するなど)を確認します。
-
特定のエンドポイントで特定のアプリケーションがトラフィックを受信すべきでないのか、または何らかの設定ミスであるのかを判断します。
-
旧バージョンのアプリケーションで使用され、現行では使用されていない不要なエンドポイントについて、セキュリティチェックの手間を削減するために仕様書から削除すべきかどうかを決定します。
Zombie API¶
Zombie APIは、すべての人が無効化済みと考えている廃止済みのAPIですが、実際にはまだ使用されているAPIを指します。
Zombie APIのリスクは、未文書の(shadow)APIと類似していますが、無効化の理由がしばしば容易に攻撃される不安全な設計である点から、より深刻な場合があります。
アップロードされたAPI仕様書の観点では、Zombie APIは前バージョンの仕様書に記載され、現行バージョンには記載されていないエンドポイント(すなわち、そのエンドポイントを削除する意図があったにもかかわらず)でありながら、実際のトラフィックに存在する(API Discoveryにより検出される)ものです。
WallarmでZombie APIを検出することは、これらのエンドポイントを実際に無効化するために、アプリケーションのAPI設定を再確認する理由となる場合があります。