アーキテクチャ リスクを緩和する

アプリケーションのクラウドネイティブ インフラストラクチャへの移行や拡張が進むにつれて、それに伴うリスクが生じています。F5のアプリケーション戦略状況レポートによると、組織の88％は、最新のアプリケーションとレガシー アプリケーションの両方を管理し続けています。実際には、多くの企業が何世代ものアーキテクチャにまたがるアプリケーション カタログを持っています。組織は、ハイブリッド クラウドおよびマルチクラウド環境のレガシー アプリケーションと最新のアプリケーションを保護するために、常に多数のセキュリティ管理を導入し調整しています。アプリケーションの安全性はそれらが稼働するインフラストラクチャに依存するため、アプリケーションやAPIから基盤となるクラウドネイティブ インフラストラクチャまで、アーキテクチャ スタック全体にセキュリティを拡張する必要があります。

従来のセキュリティ管理は、動的で高度に分散されたアーキテクチャを保護するように設計されていません。組織には、1つの組織的な攻撃キャンペーンから生じるさまざまなセキュリティ脅威を特定するための可視性と管理性が不足しています。企業は、このギャップの解消をクラウド インフラストラクチャ プロバイダに期待していますが、クラウド プロバイダごとに責任モデル、セキュリティ体制、クラウドネイティブ ツールは異なります。さらに、アプリケーションをクラウドに移行してもリスクが解消されるわけではないため、複雑さが軽減されない可能性もあります。実際のところ、クラウドネイティブ インフラストラクチャには十分な可観測性とセキュリティが備わっていないことが多いため、データ センタと複数のクラウド プロバイダにわたる異種環境のリスク対象が拡大する可能性が高くなります。これは、一貫性のないセキュリティ体制により生じるダウンタイム、機能停止、セキュリティ インシデントにつながりかねない重大な盲点と機会を攻撃者に与えてしまいます。

必然的に、攻撃者が攻撃手段や戦略を革新し続ける限り、脆弱性の悪用も続きます。たとえWeb Application Firewall（WAF）であっても、1つのツールだけで広範囲に及ぶ脅威をすべて軽減することはできません。複雑なソフトウェア サプライ チェーン、オープンソース ソフトウェアの急増、およびCI/CDパイプラインによる自動化により予期せぬリスクが発生する可能性があるため、WebアプリケーションとAPIを効果的に保護するには、早期の検出と修復が重要になります。

たとえば、大きな問題となっているlog4j2の脆弱性はさまざまな方法で悪用される可能性が高いため、修復が困難です。潜在的なリスクが複数のクラウドにまたがるコンポーネントに及ぶ場合はなおさらです。修復までの時間を短縮するには、脆弱性の指標と、デジタル ハウスの玄関ドア（アプリ）、窓（API）、および土台（インフラストラクチャ）の間の統合が必要です。Web App and API Protection（WAAP）を拡張してクラウドネイティブ インフラストラクチャとワークロードを保護すれば、脆弱なコンポーネントや潜在的に悪意のある動作をリアルタイムで検出し、WAFのようなセキュリティ管理に対する重要な洞察を提供することで、脅威を封じ込めることができます。WAFでは、重要なアプリケーション サービスを保護するようポリシーを更新できます。log4j2の脆弱性は、手に負えない複雑さや今後発生する壊滅的な被害をもたらす悪用のリスクをセキュリティ リーダーに知らせる警鐘の役割もありますが、組織が堅牢なインフラストラクチャ保護を含む包括的なセキュリティ戦略を導入するきっかけにもなります。

モダナイズされたアプリケーションを正常に運用および保護するには、アーキテクチャ全体にわたる包括的な可観測性が必要ですが、アプリケーション レベルとインフラストラクチャ レベルの両方で脅威を包括的に把握するために、脱集中化と分散化が進んでいます。