アーキテクチャリスクの軽減

組織がapplicationsをクラウドネイティブ インフラストラクチャに移行して拡張すると、リスクが発生します。 F5 のapplication戦略の現状レポートによると、組織の 88% が最新のアプリケーションとレガシーapplicationsを混在させて管理し続けています。 現実には、多くの企業が何世代にもわたるアーキテクチャにまたがるapplicationカタログを保有しています。 ハイブリッドおよびマルチクラウド環境全体でこれらのレガシー アプリと最新アプリを保護するために、組織は多数のセキュリティ制御を継続的に導入および調整しています。 applicationsは、それが実行されるインフラストラクチャのセキュリティと同程度にしか確保されないため、セキュリティは、アプリや API から基盤となるクラウドネイティブ インフラストラクチャに至るまで、アーキテクチャ スタック全体に拡張する必要があります。

従来のセキュリティ制御は、動的かつ高度に分散されたアーキテクチャを保護するようには設計されていません。 組織には、単一の協調攻撃キャンペーンから発生する可能性のあるさまざまなセキュリティ脅威を識別するための可視性と制御力が欠けています。 企業はギャップを埋めるためにクラウド インフラストラクチャ プロバイダーに期待していますが、クラウド プロバイダーごとに責任モデル、セキュリティ体制、クラウド ネイティブ ツールが異なります。 さらに、アプリをクラウドに移行してもリスクは解消されず、複雑さも軽減されない可能性があります。 実際には、クラウドネイティブ インフラストラクチャには十分な監視性とセキュリティが欠けていることが多いため、データ センターと複数のクラウド プロバイダーにまたがる異種環境のリスク サーフェスは拡大する可能性が高く、セキュリティ体制の一貫性の欠如により、ダウンタイム、停止、セキュリティ インシデントにつながる可能性のある重大な盲点と攻撃者にとっての機会が生まれます。

悪意のある人物が攻撃の手段や戦略を革新するにつれ、脆弱性の悪用は必然的に続くでしょう。 脅威の範囲が広範囲にわたる場合、Webapplicationファイアウォール (WAF) であっても、単一のツールで完全に軽減することはできません。 複雑なソフトウェア サプライ チェーン、オープンソース ソフトウェアの急増、CI/CD パイプラインによる自動化により、予期しないリスクが生じるため、Web アプリと API を効果的に保護するには、早期検出と修復が重要になります。

たとえば、悪名高いlog4j2 の脆弱性はさまざまな方法で悪用される可能性があり、特に潜在的な露出が複数のクラウドにまたがるコンポーネントに及ぶ場合は、修復が困難になります。 修復のスピードを向上させるには、脆弱性の指標と、デジタルハウスの玄関 (アプリ)、ウィンドウ (API)、基盤 (インフラストラクチャ) 間の統合が必要です。 クラウドネイティブのインフラストラクチャとワークロードを保護するために Web アプリと API の保護 (WAAP) を拡張すると、脆弱なコンポーネントと潜在的に悪意のある動作をリアルタイムで検出して脅威を封じ込めるのに役立ちます。これにより、WAF などのセキュリティ制御に重要な分析情報が提供され、ポリシーを更新して重要なapplicationサービスを保護できます。 log4j2 の脆弱性は、セキュリティ リーダーにとって、耐え難い複雑さと今後起こりうる壊滅的な攻撃のリスクについて警告するものであると同時に、組織がセキュリティ体制を見直し、堅牢なインフラストラクチャ保護を含む包括的なセキュリティ戦略を採用する機会でもあります。

アプリケーションの最新化に伴ってapplicationsの運用とセキュリティ保護を成功させるには、分散化と分散化が進むアーキテクチャ全体にわたる包括的な観測性が必要であり、applicationレベルとインフラストラクチャ レベルの両方で脅威を包括的に把握する必要があります。