本文へ移動します

未来に繋ぐセキュリティ情報発信

シャドー API がもたらす企業セキュリティへの危険性と API セキュリティ対策について

大塚 パトリック

こんにちは。セキュリティ分野におけるお客様の課題解決や、最先端のセキュリティ製品を利用したサービスの企画を担当している大塚です。

さて、デジタルトランスフォーメーション(DX)の加速化に伴い、Web サービスにおける Application Programming Interface(以下、API)の利用が爆発的に増えており、Imperva社の「2024年版 APIセキュリティの現状」レポートによると、2023年には API がネットワークトラフィックの71%以上を占めるほどでした。しかし、企業は必ずしも自社のシステム内で実装されている、または外部システムと連携するために導入されている API すべてを管理できているわけではなく、この管理外の API は「シャドー API」と呼ばれています。
今回は、そのシャドー API がもたらすセキュリティへの危険性とその対策についてご紹介します。

※参考:Imperva社「2024年版 APIセキュリティの現状」

そもそも「API」とは何か、どのようなメリットがあるのか

API は各種システムやサービス(ハードウェア、OS、ミドルウェアおよび Web サービスなど)を利用するアプリケーションソフトウェアを開発・プログラミングするためのインターフェースです。
Web ブラウザを利用するシステムの多くは API で情報をやり取りしますが、例えば、Google Map の Web ページへの埋め込みや、ネット通販で商品を購入する際の決済処理など、生活のさまざまな場面で API が使われています。もっと身近な例としては、家計簿アプリとインターネットバンキングの口座を連携させると、その後わざわざ銀行口座にログインしなくても、家計簿アプリ側で最新の口座情報が確認できるようになります。

API を活用することにより、多種多様なシステムを連携させて利用者のシステムに対する利便性や効率性を上げたり、柔軟なカスタマイズが可能なため開発コストを削減したりすることができる反面、API は Web ブラウザなどで認証作業をした後の機密性の高いデータをやり取りすることがあるので、セキュリティ面での対策が非常に重要になります。

シャドー API の危険性

前章で紹介したように、API はシステム利用者だけでなく、開発者にも高い利便性を提供しますが、その対価として API の実装と利用におけるセキュリティ面に注意を払う必要があります。これは、企業管理外の PC やタブレット端末などを社内に持ち込んで業務で利用する「シャドー IT」と同様に、「シャドー API」も存在するためです。シャドー API とは、公式に文書化されていない、または管理されていない API のことを指します。
これらの API が生じる場面として、例えば企業が Web サービス開発を外部業者に委託した際に、文書化されていない API が組み込まれたシステム一式が成果物として納品される場合や、企業内の開発者が新しいサービスを開発する際に、リリーススケジュールを短縮するために本来の承認プロセスを経ずに API を実装してしまう場合などが挙げられます。その結果、そのサービスに使われている API の来歴(※1)や安全性(※2)が不明確になってしまうことがあります。

このように API を実装してしまうと、どのようなリスクがあるでしょうか。
未承認の API には、考慮漏れや検証を実施していないことによる設定不備、脆弱性などが内在している可能性が考えられます。これらが悪用された場合、API を足がかりにネットワークを侵害される恐れがあり、データ漏えいや不正アクセスが発生するリスクが高まります。このような事象は以下のような問題を誘発する恐れがあり、極めて重大なリスクといえるでしょう。

法的リスク
個人情報保護法や GDPR(一般データ保護規則)などの法律に違反することで、罰金や訴訟のリスクが生じます。
財務的損失
情報漏えいによる罰金、訴訟費用、顧客への賠償金などが発生し、企業の財務状況に悪影響を及ぼします。
ブランドイメージの損失
顧客や取引先の信頼を失うことで、ブランドイメージが損なわれ、長期的には顧客離れを引き起こす恐れがあります。
顧客の流出
個人情報が漏えいした場合、顧客は他の競合企業に移ることが多く、売上の減少につながります。
業務の中断
情報漏えいの調査や対応に時間とリソースを割く必要があり、通常の業務が中断されることがあります。
サイバー攻撃のリスク増加
情報漏えいが発生すると、さらなるサイバー攻撃のターゲットになる危険性が高まります。
内部の信頼関係の損失
従業員の個人情報が漏えいした場合、社内の信頼関係が損なわれ、士気が低下することがあります。

これらのリスクを軽減するためには、適切なセキュリティ対策や定期的な監査が重要です。

※1:API を新規開発したものなのか、オープンソースの API を使ったのかなどのこと
※2:潜在的な脆弱性がないこと、組織のセキュリティ基準を満たしていること

API ディスカバリーと管理体制を建てる必要性

API の活用に潜在するリスクを低減するには、企業内で使われている API の可視化と制御が非常に重要な管理策となります。API を可視化するには、まずはどのような API が存在するかを把握(ディスカバリー)する必要があります。API ディスカバリーとは、企業内で使われている自社開発およびサードパーティ製 API をリストアップしてカタログ化するプロセスのことです。実装されている API の数は組織によって異なりますが、外部システムとの連携をしている企業であれば、最低でも数十の API が使われていることは珍しくありません。

API ディスカバリーを実施することで、API を通してアクセスできるデータや機能である API リソース、サードパーティシステムがリソースにアクセスするための URL である API エンドポイントの自動検出とカテゴリ化を行います。その上で API のリクエスト(要求)とそのレスポンス(応答)において機密情報がやり取りされていないかを検出し、各 API におけるリスクの種別や OWASP(※3)の API Security Top 10(API において重要な10のセキュリティリスク)に関連する攻撃を把握できるようになることが望ましいです。

また、API ディスカバリーに基づいて、企業は検出された API の危険性を識別し、その管理体制を設ける必要があります。単純にどのような API が使われているかを理解するだけではなく、その API のリスク種別が企業にとってどのようなリスクをもたらすか、どのような対策を取るべきかを具体的に検討する必要があります。例えば、社内製の API であれば、開発者に潜在的な脆弱性を解決するための対策を取らせることが重要です。一方、サードパーティ製で文書化されていない API であれば、その開発者へのヒアリングを行い改善を求めるといった対応が考えられます。
そして何よりも継続的に API の利用状況を監視し、その後も新しく実装された API に類似する問題が発生しないか把握することが非常に重要です。

※3:API や Web システムにおける攻撃手法を定義し、対策を提示するオープンソース団体

従来の対策だけでは API 攻撃が防ぎきれない?

以前から存在する API ゲートウェイ製品は、一般的に API リクエストを受信し、通信制限(スロットリング)やセキュリティポリシーを適用することで企業内のサーバー群にリクエストを渡し、そのレスポンスを外部要求者に返すプロキシに相当する製品です。これらの製品では、企業内で実装されている API に対する可視化や制御が十分に行えない場合が多く、API 通信の詳細な分析やインベントリ化も実施しないため、API におけるセキュリティ欠陥に対応できず、対策としては不十分と考えられます。

企業は自社の Web サービスに対する絶え間ない Web 攻撃を遮断してセキュリティ対策を立てるためにクラウド WAF 製品を利用することも一般的ですが、その Web サーバーと外部 API を利用するサービス、社内アプリケーションとの連携をはかる API の不備に伴うデータ漏えいや不正アクセスから守るには、WAF だけでは不十分な場合もあります。

基本的な WAF だけでは、悪意ある API コールと正当な API トラフィックを区別する能力がない製品が世の中に多く、アプリケーションに潜在する脆弱性への対応としては不十分です。また、API ゲートウェイは主にトラフィックの管理や認証、認可を担いますが、API が直面するさまざまなセキュリティ脅威への対策が不足します。API に対しては多様な方法で攻撃が行われるため、API を全面的に保護するには、WAF、高度なボット対策、API セキュリティ対策の組み合わせが最適な解決策です。

また、攻撃者は以下のように自動化された攻撃手法を利用して API に対する攻撃を仕掛けることがあるので、整備された API 対策が必要になります。

(1)ボットを利用して API エンドポイントを見つけるとデータ入力の検出閾値(特定時間内に掛けられる API コールの数)を試みて、偵察行為で攻撃対象領域をマッピングします。これにより、攻撃者は大まかに API の実装領域や Web サービスの構成を把握することができます。

(2)API の実装領域やサービス構成が把握できたら、攻撃者は攻撃フェーズに入ります。一般的なボットによる API 攻撃は、窃取したユーザー名とパスワードリストを試みるリスト型攻撃(クレデンシャル・スタッフィング)や総当たり攻撃とも呼ばれるブルートフォース攻撃、競合の e コマースサイトなどに掲載される価格情報などをかき集めるスクレイピング攻撃、データベースなどから情報を引き出すためのインジェクション攻撃があります。

(3)ボットによる API 攻撃では、真の目的である情報入手や改ざん行為などを実施するために、大量のアラートを発生させて IT 管理の注意を引くための「煙幕」を張り、その間にセキュリティ防御を逃れて攻撃を実施することも多くなっています。

これらを防ぐために、API ディスカバリーとセキュリティ対策に特化したソリューションが必要となってきます。

API セキュリティ対策に必要な機能性

API セキュリティに必要な機能類は、PDCA サイクルに類似する以下4つの要素があげられます。これらは、API 開発チームを持つ企業であれば DevOps(開発運用)のライフサイクルに取り入れることができるうえ、そのような組織がない企業でも API の安全性を確保するために必要となる重要な要素です。

(1)発見
有効、レガシー(公式だが使われなくなった API)およびシャドー API のイベントリ(検出 API のリストアップ)機能
(2)検知
既知、未知を問わず API におけるデータ漏えいや不正アクセス試行を象徴する不審な動き、または開発者・管理者による設定ミスの検出機能
(3)緩和
リアルタイムの攻撃緩和と API に含まれるコード修正の機能
(4)検証
実装前に API の完全性(余分なデータへのアクセスを許可していないかなど)をテストし、検証を可能とする機能

API セキュリティを含むおすすめのクラウド WAF ソリューション「Imperva App Protect」

当社では、Gartner 社に9年連続 WAF のリーダーとして位置づけられている Imperva 社の Imperva App Protect にてオプション提供される API Security 機能の活用をおすすめしています。Imperva API Security では、前述した4つの機能を提供するほか、App Protect で保護する Web サービスとシームレスに連携し、同一ダッシュボード上で管理しレポートを確認することができます。

また、前述した OWASP の API Security Top 10にも準拠し、管理画面内での API イベントリ、各 API に機密データが含まれるか否か、API に存在するリスク種別(認証の失敗・一括割り当て・過剰なデータ露出など)とそれぞれの API のリスクが OWASP API Security Top 10 のどのリスクに該当するかを可視化し、直ちにセキュリティ対策をとることができます。

当社では、この Imperva App Protect をご提供していますので、WAF 導入をご検討の際は、ぜひお気軽にご相談ください。

セキュリティソリューションに関する資料請求・お問い合わせ

本サービスに関する資料請求やお見積り、ご不明点など、お気軽にご相談ください。

セキュリティソリューションに関する資料請求・お問い合わせ

開催中のセミナー

最新トレンドや業務に役立つ知識が得られる SBテクノロジーのセミナー 参加無料 オンデマンド配信あり

ホワイトペーパー

SBT セキュリティサーベイ 2023

ピックアップ

セミナー情報
クラウドエンジニアブログ
NOZ
メールマガジン登録