シャドーAPI：象に変身するアリ
シャドーAPIとは、文書化されておらず、管理も監視も追跡もされていないAPIであり、通常はセキュリティメカニズムが脆弱、あるいは全く存在しないものです。一見すると、まるでアリのように、単純で小さく、全く問題がないように見えるかもしれません。
しかし、このアリはあっという間に象――まさに、部屋の中の象――に変身します。そして、踏みつけられて初めてその重さに気づいたとしたら、それは古代ギリシャの悲劇に匹敵するでしょう。
ギリシャ悲劇の主人公にならない方法を学ぶために読み続けてください。
シャドーAPIとは?
シャドーAPIとは、API管理やセキュリティプログラム、ツールといった組織が確立した制御・防御システムの範囲内で動作しないアクティブなAPIです。そのため、不正APIと呼ばれることもあります。
シャドーAPIという概念は、シャドーITの概念に由来しています。「シャドーIT」が組織内の関連機関（IT部門）の承認や承認を得ずにソフトウェアを積極的に利用することを指すのと同様に、「シャドーAPI」は正式に承認され、既知のAPIの範囲外に存在するAPIを指します。
上記は、シャドーAPIが開発チームのメンバーには知られているものの、部門や階層構造に関わらず、組織内のほとんどのメンバーには見えない状態にあることを示しています。時間が経つにつれて、これは予想以上に複雑な状況を引き起こす可能性があります。
シャドーAPIは、迅速な開発を実現するための一時的な手段であるため、不要になれば廃止されることを前提としています。通常、開発者はテストや公式の既成APIを含まないアプリとの連携など、開発タスクを容易にするための一時的な目的でシャドーAPIを作成します。その意味で、シャドーAPIはAPIセキュリティの問題というより、むしろAPIガバナンスの問題と言えます。
一時的に有用なシャドーAPIが以下の状態になると、真のセキュリティ上の頭痛の種になります：
- 組織外からも発見・アクセス可能である（開発者による内部限定ではない）
- 認証が不十分で、一般的にセキュリティ対策が不十分である
- 過去の忘れ去られたユースケースの残骸として見過ごされるようになる
環境内に存在する第三者のAPIを認識せず、API管理プログラムに含めなかった場合、それらは影のAPIとなる点に留意すべきです。特に、それらが長期間にわたり見過ごされたままの場合、深刻な問題となります。
シャドーAPIとゾンビAPI
シャドーAPIはゾンビAPIと併せて議論されることがよくありますが、それには理由があります。
- どちらも組織の監視外に存在し、非公式のAPIである
- どちらも主に急速な開発環境のプレッシャーが生み出す副産物である
- どちらも実質的に同じセキュリティ上の結果をもたらす
類似点があるとはいえ、シャドーAPIとゾンビAPIを互いに置き換えるべきではありません。両者の違いを理解することは重要です。なぜなら、これらの問題のあるAPIを排除する、あるいは少なくとも発生を減らすためのアプローチがそれぞれ異なるからです。
では、ゾンビAPIとシャドーAPIの違いは何でしょうか?
少なくとも2つの違いにより、これら2種類の非公式APIはセキュリティ上の問題が別々になります。
- シャドーAPIとは異なり、ゾンビAPIは組織、すなわち意思決定者の認識と承認の元で作成されます。
ゾンビAPIとは、正式に廃止・無効化せずに放棄された非推奨APIを指します。例えば、v3が現在のAPIバージョンであり、古いAPIバージョンを正式かつ手順に沿って廃止したことがない場合、v1とv2はゾンビAPIとなります。
これらの2つのバージョンは、当初は組織によって承認され監視されており、不透明な点は何もありませんでした。それぞれが正当な目的を果たす公式APIでした。しかし、新しいAPIバージョンに置き換えられた時点で、それぞれが非公式なものとなったのです。
問題は、v1とv2を廃止しなかったことに端を発します。おそらく、両方のAPIバージョンには欠陥があり、そもそも時代遅れでサポート対象外となっていたのでしょう。その結果、廃止せずに放置したことで、外部からのアクセスや悪用に対して無防備な状態に晒されてしまいました。こうしてゾンビ化したのです。
- シャドーAPIはアクティブに使用されるため問題を引き起こす可能性がありますが、ゾンビAPIはアクティブに使用されなくなったために問題を引き起こす可能性があります。
シャドーAPIの積極的な利用こそがまさに問題です。そもそもこれらのAPIは存在すべきではありません。しかし開発者の視点では有用であるため、設定されたAPIガバナンスプロトコルを回避しながらも積極的に利用されます。これが予期せぬセキュリティリスクを生み出す原因です。
対照的に、ゾンビAPIの問題は存在すること自体ではなく、忘れ去られ放置された状態でありながら存在し続けることにあります。ゾンビAPIがセキュリティリスクとなるのは、もはや有用でも積極的使用されてもいないのに、存在し続けているからです。
重要なのは、シャドーAPIも忘れ去られる可能性がありますが、それがシャドーAPIの本質ではない点です。むしろそれは二重の問題を意味します：シャドーAPIが、情報環境内で監視されず（第一の問題）、ほとんど誰にも知られずに徘徊している状態です（第二の問題）。
シャドーAPIとAPI9:2023不適切なインベントリ管理
適切なAPIインベントリ管理は困難です。最近の調査「2023年APIセキュリティの現状：APIリスクの実態に関するグローバル調査」によると、正確なAPIインベントリの維持は、APIのセキュリティ確保を目指す組織にとって2番目に大きな課題（回答者の37%）であることがわかりました。これは、関連性はあるものの同一ではない現象であるAPIスプロール（48%）に次ぐものです。
シャドーAPIは、ゾンビAPIとともに、OWASP APIセキュリティトップ10、API9:2023 の不適切なインベントリ管理のAPI脆弱性のカテゴリに分類されます。
OWASP Top 10 APIセキュリティリスクは、これまでで最も権威のあるAPIセキュリティプロジェクトです。最も一般的かつ深刻な10のAPIセキュリティ脆弱性を列挙し、解説しています。「不適切なインベントリ管理」（旧称「不適切な資産管理」）は、2019年と2023年のトップ10リストの両方で9位にランクされています。
現在の名称が示すように、このAPI脆弱性カテゴリに含まれるセキュリティ問題の共通項はAPIインベントリです。APIインベントリは、適切に文書化されたAPIとAPIエンドポイントの完全なリストまたはカタログでなければなりません。このカタログが欠落していたり、一貫性がなかったり、不完全であったり、適切に維持・管理されていない場合、深刻なセキュリティリスクを伴います。
しかし、不適切なインベントリ管理がなぜそれほど深刻な問題なのでしょうか?
理由は次のとおりです。
- このAPIの脆弱性は簡単に悪用される可能性があります。
インベントリされていないAPIは目に見えないAPIであり、「目に見えないものを保護することはできない」というよく言われる格言があります。この格言はもううんざりするかもしれませんが、根本的な真実を表現しています。
APIセキュリティ、そしてサイバーセキュリティ全般において、可視性がどれほど重要であるかは、いくら強調してもしすぎることはありません。シャドーAPIエンドポイントの存在すら知らない場合、そのエンドポイントを介したサイバー攻撃をどのようにして防いだり、対応したりできるでしょうか？残念ながら、不可能です。
逆説的ですが、潜在的に脆弱なAPIエンドポイントについて知らないのは、通常、あなただけです。一方、脅威アクターは、Google DorkingやDNS列挙といった単純な手法で、それらのエンドポイントを発見します。
- シャドーAPIなどの考慮されていないAPIは、通常、セキュリティが弱くパッチも適用されていません。
その結果、情報環境の門戸があらゆる種類の悪用に対して開かれたままになり、非公式APIが本物のユーザーまたは企業情報を含むデータベースへのアクセスを保持している場合には機密データが漏洩するおそれがあります。
- 前の点に関連して、インベントリされていないAPIは他の多くの問題を引き起こします。
より正確に言えば、管理されていないAPIがサイバー攻撃の最終的な標的であるとは限りません。
目に見えない性質と、セキュリティメカニズムが緩い、またはまったく存在しないため、十分に保護されている基盤システムへの容易な侵入ポイントとなります。
脅威の主体によって発見されると、それらはラテラルムーヴメント、つまりネットワーク全体に徐々に広がり、システムの奥深くまで侵入して弱点を見つけて悪用し、権限を昇格し、広範囲にわたる（場合によっては修復不可能な）損害を与えることが可能になります。
不適切なインベントリ管理に悩む組織が攻撃者の標的になる頻度がどのくらいなのか疑問に思っているなら、驚くことになるでしょう。
2022年の包括的な調査「API保護レポート：シャドーAPIと自動化された不正利用の急増」によると、観測された167億件の悪質APIトランザクションのうち、 50億件がシャドーAPIを標的としていたことが明らかになりました。これは約31%、つまり悪質APIトランザクション全体のほぼ3分の1に相当し、シャドーAPIは2022年上半期の攻撃ベクトルとして最も多く利用されました。
シャドーAPIの影響
シャドーAPIがこれほどまでに恐ろしいリスクとなるのは、それがもたらす可能性のある結果です。ここで言う「結果」とは、以下のようなものを指します。
- データの露出、漏洩、盗難 — シャドーAPIに関する最大のセキュリティ上の懸念事項
- 膨大なリソース消費などの運用上の問題
- 不安定なシステム
- コンプライアンス違反
これらは関連していると言えます。例えば、ハッカーがシャドーAPIを悪用して個人識別情報（PII）などの機密データをシステムから盗んだ場合、GDPR（一般データ保護規則）違反として罰金が科せられる可能性があります。
シャドーAPIが情報環境に侵入すると何が起こるかを説明するために、実際のセキュリティインシデントを3つ取り上げます。
シャドーAPIを防止および発見する方法
ハッカーは、APIリクエストとレスポンスのパス、ヘッダー、クエリパラメータ、リクエストボディ（基本的にどこにでも）からシャドーAPIエンドポイント情報を見つけることができます。APIトランザクション内でapi.test.target.com、beta.api.com、/api/private、/api/partner、/api/testといったものを探すだけで済みます。
情報に基づいた推測、自動ファジング、ブルートフォースは、脅威の攻撃者がシャドーAPIや、不適切にインベントリされ管理されているその他のAPIを見つけるために使用する追加の手法です。
良いニュースは、あなたも同じことができるということです。どうやって？APIセキュリティテスト、より具体的にはAPI侵入テストを通してです。
手動と自動のAPIペネトレーションテストはどちらも、悪意のある攻撃者と同様のアプローチと手法（一部は上記で述べた通り）を採用しています。違いは、それらが倫理的である点です。その目的は、APIを攻撃して損害を与えることではなく、シャドーAPIを含む脅威攻撃者が発見するのと同じバグ、問題、脆弱性を見つけることで、APIを攻撃し、セキュリティを確保することです。
問題を発見したら、報告と改善ガイドラインを提供します。これは、APIインベントリ管理を改善するための効果的な方法の一つです。
APIセキュリティテスト/ペネトレーションテストに加えて、次の方法を実装して、シャドーAPIによるセキュリティリスクを排除または軽減できます。
- 可能であれば継続的かつ詳細な自動化されたAPIインベントリ
- CI/CDパイプラインの一部として自動化されたAPIドキュメントにより、盲点を排除
- 開発者はシャドーAPIの拡散を防ぐ鍵となるため、セキュリティのベストプラクティスと安全なコーディングに関するトレーニングを実施
- シャドーAPI攻撃の早期検出と抑止のためのAPIゲートウェイ
- 開発中のシャドーAPIを見つけるための静的コード分析
- データフローの盲点を排除するためのデータ分類
- ネットワークトラフィックの監視によるAPI検出
- 非本番環境APIのネットワークアクセス制限
- アウトバウンドプロキシ監視
- ログ分析
- API監査
結論
シャドーAPIとは、情報環境でアクティブであるにもかかわらず、ユーザーからは見えないAPIです。これは、OWASPのAPIセキュリティ脆弱性トップ10の1つである「不適切なインベントリ管理」のカテゴリに該当します。シャドーAPIとゾンビAPIは類似していますが、同一ではありません。
一見大きな脅威には思えないかもしれませんが、シャドーAPIはデータ侵害や機密情報の盗難といった深刻な結果につながる可能性があります。こうした事態を防ぎ、環境内のシャドーAPIを検出し、その発生を最小限に抑えるために、様々な対策を講じることができます。継続的なAPIインベントリ、自動ドキュメント化、APIセキュリティテストなどがその例です。
Equixlyが正確なデータ分類を通じてシャドーAPIの検出とAPIセキュリティ体制の強化をどのように支援できるか、ぜひお問い合わせください。ご連絡をお待ちしております。
※この記事はEquixly社ブログを日本語化したものです。
※この記事の無断複写及び転載を禁じます。
※原文：https://equixly.com/blog/2024/08/05/shadow-api/
Carlo De Micheli
Director of Product Marketing
カルロ氏は、豊富な国際経験を持つ多才なプロフェッショナルです。サイバーセキュリティ、自動車、航空宇宙分野など、イノベーションへの情熱は多岐にわたり、先駆的なプロジェクトに積極的に取り組んでいます。航空宇宙工学の技術的バックグラウンドに加え、プログラミングとセキュリティに関する独学も積極的でした。国際会議の企画・発表や、シェアリングエコノミーやファッション関連のテクノロジー系スタートアップの設立を経て、マーケティングとセールスに携わるようになりました。