API（Application Programming Interface）は、デジタル革命を支える縁の下の力持ちのような存在だ。企業が新たなユーザー体験を生み出すために、多様なソフトウェア・コンポーネントを結びつける役割を果たす。しかし、バックエンドのデータベースへ接続する直接的な経路となるため、APIは攻撃者から格好の標的となっている。ここ数年でAPIの数は爆発的に増加しており、マニュアル化もセキュリティ対策もされていないAPIが多数見受けられる。

最近の調査では、グローバル企業の94%が本番環境のAPIでセキュリティに関する問題に直面しており、そのうち17%がAPIに関連したセキュリティ侵害を経験していた。今こそ、APIの状況を可視化し、管理を強化するときだ。

APIに関する脅威は、どれほど深刻か？

APIはコンポーザブル・エンタープライズを実現する鍵となる。これは、ガートナー社が提唱したコンセプトであり、アプリケーションをパッケージ化されたビジネス機能（PBC）に分割することを推奨している。小さなコンポーネントを多様な方法で組み合わせる考え方は、急速に変化するビジネス環境に対応しながら、素早くかつ柔軟に、新しい機能や体験を生み出すことができる。APIはPBCに欠かせない要素であり、マイクロサービス・アーキテクチャーの普及とともに、近年その利用が急増している。

したがって、現在では、世界のIT部門のリーダーのほぼ全員（97%）が、API戦略の着実な遂行が将来的な売上や成長に不可欠であることに同意している。しかし一方で、膨大な量のAPIと、複数のアーキテクチャーや担当チームにまたがって利用されている点が懸念されている。大企業では、顧客やパートナー企業向けのAPIが数万から数十万に達している可能性がある。中堅企業でさえ、数千ものAPIを利用している可能性があるのだ。

企業にはどのような影響があるか？

APIへの脅威は現実のものとなっている。2023年だけでも、以下のようなことが発生している。

• 米国T-Mobile社は、3,700万件の個人情報とアカウント情報が、APIを経由して悪意のある攻撃者から不正にアクセスされたと発表した。
• Booking.comでOAuthの実装に設定ミスがあり、同サイトで深刻なアカウントの乗っ取り攻撃が可能になっていた。

APIの脅威によって危険に晒されるのは、企業の評判や収益だけではない。重要なプロジェクトを停滞させる恐れもある。APIのセキュリティに関する懸念により、新しいアプリの公開を遅らせた経験がある企業は半数以上（59%）に上った。今やAPIは経営層レベルで議論すべきトピックになったと言えるだろう。

APIに関する3つの主要なリスク

攻撃者がAPIを悪用する手法は多数存在するが、組織にとって重要な脅威を理解したいのであれば、OWASP（Open Web Application Security Project）の情報が参考になるだろう。OWASPは、ソフトウェアのセキュリティ環境や、セキュリティ技術を普及させることを目的として活動する専門団体だ。2023年に発表されたOWASPのAPIセキュリティ上位10項目では、以下の3つの主要なリスクが詳述されている。

• オブジェクトレベル認可の不備（BOLA：Broken Object Level Authorization）：リクエスト元が、APIから呼び出されたオブジェクトへのアクセス権を持っているか検証していない状況を指す。BOLAは、データの盗聴や改ざん、破壊につながる可能性がある。攻撃者にBOLAが起きていると発見されるだけで悪用されるため、注意が必要だ。BOLAの状態であると、ハッキングするためのコードやパスワードの盗用さえも必要ない。
• 認証の不備：認証による防御がない、あるいは、実装に不備があるケースが考えられる。API認証の実装方法を誤解し、「複雑で難解だ」と考える開発者が多いとOWASPは指摘している。認証処理の情報には誰でもアクセスできるため、攻撃者からの標的となり得る。認証を担当するAPIエンドポイントは、ほかとは異なる実装を検討すべきであり、より強化された防御が求められる。そして、起こり得る攻撃手段に対して、適切な対策を施した認証手段を実装する必要がある。
• オブジェクトプロパティレベル認可の不備 (BOPLA：Broken Object Property Level Authorization)：アクセスできないはずのオブジェクトプロパティの値が、攻撃者によって閲覧、編集されてしまう状態のこと。機密性のあるオブジェクトプロパティが不正にアクセスされたり（過剰なデータ露出）、それらの値が変更、追加、削除されたり（マス・アサインメント）した場合、APIエンドポイントは脆弱になる。認可されていないアクセスは、データ流出や損失、改ざんにつながる。

上記の脆弱性は、重複して発生する場合があるので注意が必要だ。BOLAと過剰なデータ露出といった組み合わせによって、API経由の深刻な情報漏えいが発生する場合がある。

APIに関する脅威を軽減する方法

先述のリスク要因を考えると、API戦略を立案する際は、初期段階からセキュリティを組み込んで進めることが重要だ。つまり、APIの実装状況を理解し、エンドポイント認証の管理やセキュアなネットワーク通信、一般的なバグや悪質なボットの脅威への対処に必要なツール、ノウハウの蓄積が重要である。

具体的には、以下の対策から始めると良い。

• APIの可視化と管理を強化するために、APIを中心とした開発モデルを導入し、APIガバナンスを向上させる。ソフトウェア開発ライフサイクルの上流工程でセキュリティ対策を講じ、CI/CDパイプラインで自動化することも可能となる。
• 無断で導入されたシャドーAPIの数を削減するよう、APIディスカバリーツールを利用する。APIを組織内のどこで利用しているのか、脆弱性がないかを把握する際に役立つ。
• クライアントからのリクエストを受信し、適切なバックエンド・サービスへ転送するAPIゲートウェイを設置する。この管理ツールは、APIへのトラフィックの認証や管理、監視、保護に役立つ。
• ゲートウェイのセキュリティを強化するよう、WAF（Webアプリケーションファイアウォール）を導入する。DDoS攻撃やエクスプロイトを含めた悪意のあるトラフィックを遮断することが可能だ。
• API経由のすべてのデータを暗号化（例：TLS）する。中間者攻撃による盗聴を防止できる。
• Webサイトなどでアカウント情報が漏えいしないよう、APIアクセスを管理するためにOAuthを利用する。
• APIを呼び出す頻度を制御するため、帯域制限を導入する。DDoS攻撃や不要なアクセス集中による脅威の軽減につながる。
• すべてのセキュリティ・イベントのログをとり、疑わしいアクティビティを記録するよう監視ツールを利用する。
• 境界内の、いかなるユーザー、アセット、リソースも信用しないという考え方に基づいたゼロトラストのアプローチを検討する。いかなる操作においても、認証や認可の処理を要求する。

デジタルトランスフォーメーションは、これからの企業に継続的な成長をもたらす原動力となる。APIは、新たな開発プロジェクトの中心的な存在だ。徹底的に文書化し、セキュリティ・バイ・デザインの原則に基づいて開発しなければならない。さらに本番環境では、APIを多層防御によって保護すべきだろう。APIのセキュリティリスクを軽減するために、本記事で紹介した対策を試してほしい。