アプリケーションとAPIの統合的なセキュリティ戦略の事例

とはいえ、アプリケーションとAPIの両方に共通するセキュリティ リスクもあり、セキュリティ ソリューションを実装する際は考慮する必要があります。例えば、最近更新された2023年版API Security Top 10では、アプリケーションと共通する一連のリスクが明確に示されています。

• 脆弱な認証/認可制御
• 設定ミス
• ビジネス ロジックの悪用（クレデンシャル スタッフィング、アカウント乗っ取り）
• Server-Side Request Forgery（SSRF）

これらのリスクに加え、今もなお、可用性を標的とする攻撃は相当な数に上ります。それが、アプリケーションとAPIの両方に共通するDDoS攻撃です。通常、アプリケーションとAPIはTCPとHTTPに対して同じ依存関係を共有しているため、どちらもアクセスと可用性を妨害することを目的としたさまざまな攻撃の対象となります。

アプリケーション、API、そしてそれらを支えるインフラストラクチャを保護するという課題に対処する1つのアプローチが、ボットや不正行為の防御、DDoS対策、アプリケーション セキュリティ、APIセキュリティといった、複数のソリューションを展開することです。確かにこのアプローチでセキュリティ上の課題には対処できますが、運用上の課題を生み、ポリシーの変更管理やアプリケーションとAPIの両方に影響する脅威への対応など、セキュリティ関連の多くのタスクがより複雑になります。複雑さはセキュリティの敵であるだけでなく、スピードの敵でもあります。

当社の年次調査によると、新たな脅威に迅速に対応できることが、SaaS（Security as a Service）を導入する最大の理由として挙げられています。新たな脅威を軽減するために、ソリューションごとにパッチやアップデートを適用したり、新しいポリシーを導入したりするのでは時間がかかり、設定ミスや間違いが発生する可能性も高くなります。複雑であるほど、脅威を軽減するのに時間がかかることになり、特に組織が複数の環境（ハイブリッドIT）を運用していて、環境ごとにセキュリティ ソリューションを利用しているとなればなおさらです。この時間が直線的に増加するのか、指数関数的に増加するのかを計算するつもりはありません。差し迫った脅威への対応にかかる時間が長くなることは、正直なところ、良いことではありません。

つまり、より優れたアプローチは、ソリューションを組み合わせることであり、脅威と戦うために設計された機能の運用とセキュリティ管理を共有しながら、アプリケーションとAPIに固有のプロトコルやペイロードに対処するための特定のセキュリティ ポリシーを可能にすることです。

これにより、アプリケーションとAPIのセキュリティ戦略が統合され、共通の機能が共有されて、アプリケーションやAPIにより近いところで粒度をより細かくし、特殊性を高めることができます。結局のところ、ボットはボットであり、ボットがアプリケーションとAPIのデータの品質、配信コスト、リスク プロファイルに与える影響は共通の問題です。DDoSはDDoSです。同じ問題に対処するために倍の数のサービスを運用することは、あらゆる指標から見て、非効率的です。

アプリケーションとAPIの統合的なセキュリティ戦略は、運用、財務、アーキテクチャのどの面から見ても理にかなっています。