統合アプリと API セキュリティ戦略の事例

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

• 認証/承認制御が弱い
• 誤った設定
• ビジネス ロジックの悪用 (クレデンシャル スタッフィング、アカウント乗っ取り)
• サーバー側リクエストフォージェリ (SSRF)

これらのリスクに加えて、可用性を標的とした攻撃も依然として相当数発生しています。 つまり、アプリと API の両方に共通する DDoS 攻撃です。これらは通常、TCP と HTTP への同じ依存関係を共有しており、どちらもアクセスと可用性を妨害するように設計されたさまざまな攻撃の対象となります。 

アプリ、API、およびそれらをサポートするインフラストラクチャのセキュリティ保護の課題に対処する 1 つの方法は、複数のソリューションを導入することです。 ボットと詐欺の防御、DDoS 保護、アプリのセキュリティ、API のセキュリティ。 これは確かにセキュリティ上の課題に対処しますが、運用上の課題をもたらし、ポリシー変更管理やアプリと API の両方に影響を与える脅威への対応など、多くのセキュリティ関連のタスクをより複雑にします。 複雑さはセキュリティの敵であるだけでなく、スピードの敵でもあります。

当社の年次調査によると、新たな脅威に反応できるスピードは、Security as a Service の導入を推進する最大の要因となっています。 新たな脅威を軽減するためにパッチ、更新、または新しいポリシーの導入を必要とするソリューションごとに、時間がかかり、構成ミスや間違いの可能性が高まります。 したがって、脅威を軽減するための時間は複雑さが増すにつれて長くなります。特に、組織が複数の環境 (ハイブリッド IT) で運用されており、環境ごとのセキュリティ ソリューションを活用している場合はその傾向が強まります。 私は、それが線形増加なのか指数関数的増加なのかを判断するための計算は行いません。なぜなら、正直に言って、差し迫った脅威に対応する時間を増やすものは何であれ、良いことではないからです。

そのため、ソリューションを組み合わせて、脅威に対抗するように設計された機能の運用管理とセキュリティ管理を共有しながら、特定のセキュリティ ポリシーでアプリや API 固有のプロトコルやペイロードに対応できるようにする方が、より良いアプローチになります。

これにより、統合されたアプリケーションと API のセキュリティ戦略が実現し、共通機能が共有され、アプリや API に近づくにつれて粒度と特異性が高まります。ボットは結局のところボットであり、データの品質、配信コスト、アプリや API のリスク プロファイルへの影響は共通の懸念事項です。 DDoS は DDoS です。 同じ問題に対処するために 2 倍のサービスを運用することは、あらゆる測定基準において非効率的です。

統合されたアプリケーションと API のセキュリティ戦略は、運用面、財務面、アーキテクチャ面でも優れた意味を持ちます。