② Part 1：クラウドフレア / NET：サイバーセキュリティ銘柄のテクノロジー上の競争優位性（強み）分析と今後の将来性（後編）

※「Part 1：クラウドフレア / NET：サイバーセキュリティ銘柄のテクノロジー上の競争優位性（強み）分析と今後の将来性（前編）」の続き

※専門用語の解説に関しては、前編をご覧ください。

ガートナー社はWAAP市場のマーケットガイドを提供しているが、彼らはAPIセキュリティを単に拡張WAF機能でカバーできる側面ではなく、独自のカテゴリとして認識している。

実際、ここ数年、APIセキュリティやより広範なAPI管理分野に取り組む新興企業が数多く誕生している。

例えば、Traceable、Salt、最近アカマイ・テクノロジーズ（AKAM）に買収されたNoname、Cequence Security等は、ここ数年で多額の資金を調達したAPIセキュリティの新興企業である。

これらの新興企業の多くは、Saltのように純粋なアウトオブバンド・セットアップを採用しており、導入が容易で既存のネットワーク・フローに影響を与えないという特徴がある。

そして、これらの企業は、脆弱なAPIを発見し、インベントリを作成し、特定し、悪意のある行動を特定するためにAPIの使用パターンを監視し、分析することができるので、APIセキュリティ全体に大きく貢献している。

しかし、例えばStripeの決済処理APIのようなAPIに脆弱性が含まれている場合、最終的にそれは、サードパーティであるStripeのAPIを使用して開発するウェブアプリケーション開発チームの管理下にはなく、Stripeの責任となる。

つまり、Saltのようなものの助けを借りて、開発チームは脆弱なAPIの影響を緩和し、ウェブアプリケーション環境をより良く保護することはできるが、自分たちだけで問題を完全に解決することはできない。

このため、このようなアウトオブバンドのAPIセキュリティプレーヤーはAPI全体の可視性にとって非常に重要であるが、クラウドフレア（NET）が提供するインライン・プロキシ等のAPIゲートウェイがAPIセキュリティの最大の付加価値コンポーネントであると我々は考えている。

なぜなら、サードパーティのAPIの脆弱性に関係なく、ゲートウェイはウェブアプリケーションに対して承認されたAPI関連のトラフィックのみをインバウンドさせるポリシーを実施するようにセットアップすることができるからである。

同様に、ゲートウェイは承認されたアウトバウンド、つまりウェブアプリケーションからAPIへのアクティビティのみを実行することができる。

これは現在、クラウドフレアがAPIセキュリティの領域で、ウェブアプリとAPI間のゲートウェイを提供し、また、Stripe APIがクラウドフレアによって保護されている場合、Stripeのような公開APIへのボリュームのあるDoS攻撃に対するボット防御も提供している。

しかし、さらなるAPIセキュリティ機能のために、クラウドフレアのAPI Gatewayの顧客は、発見、ベストプラクティス設定、脆弱性評価などのためにサードパーティベンダーを統合する必要がある。

従って、クラウドフレアはおそらく最大の付加価値を持つAPIセキュリティ・コンポーネントであるプロキシ・ベースのゲートウェイを持っているため、WAFからWAAPへと市場が拡大する中で、同社はその強さを維持するのに非常に有利な立場にあると我々は感じている。

クラウドフレアは1日平均約5,000万件のHTTP/Sリクエストを処理しており、そのうち58%がAPI関連である。

この膨大なAPIトラフィックによって、同社は機械学習技術を効果的に適用し、APIをターゲットとした悪意のある行動パターンを特定することができるようになっている。

そして、この能力は、シグネチャベースの検出を無意味なものにする新しいAPIのダイナミズムと急増によって、非常に必要とされている。

確かに、API関連のセキュリティに対する要求は、同社の第1幕の成長を拡大させた。

そして、APIは他のDevSecOpsワークフローと密接な関係にあるため、さらなる進化が見込まれている。

開発者は、アプリケーションを安全に構築、テスト、実行するために、パロアルトネットワークス（PANW）のPrisma Cloudや、shift-left（シフト・レフト）、CSPM（Cloud Security Posture Management：クラウドセキュリティ態勢管理）、CWPP（Cloud Workload Protection Platform：クラウドワークロード保護プラットフォーム）を構成する個々のベンダーのツールチェーンのようなCNAPP（Cloud-Native Application Protection Platform：クラウドネイティブ アプリケーション保護プラットフォーム）を使用しており、APIはこのプロセスの一部である。

そのため、CNAPPとAPIセキュリティ・ベンダー、あるいはより広範なWAAPベンダーの間で、重複や統合が進むことは明らかである。

そして、CNAPPとAPIセキュリティベンダーの間には、より強力な統合が必要である。

なぜなら、前者はAPIに対する可視性や制御が限られており、後者はアプリケーションのワークロードのランタイム実行に対する可視性がゼロだからである。

また、APIベースの脅威に取り組む上で、どちらも重要である。

なぜなら、APIトラフィックの分析だけでは検出できない悪意のある活動の様々なケースがあり、より大きなコンテキストを得るためには、CWPPが提供するようなランタイムからの補足的な洞察が必要だからである。

これは逆もまた真なりで、CWPPベンダーはAPIトラフィックのパターン分析を取り入れることで、保護機能を向上させることができる。

しかし、このような統合の初期開発はいくつか行われている。

シフト・レフト型のサービスを提供するCNAPPの中には、サードパーティのWAAPベンダーをCI/CDパイプラインに統合して、開発者がアプリケーションの機能に組み込む前にAPIのセキュリティをチェックできるようにしているところもある。

さらに、これらの統合により、開発者はアプリケーションライフサイクルの早い段階で、分散クラウドベースのWAAPサービスをセットアップできるようになる。

数社のCNAPPとWAAPベンダーは、アプリケーションをホストするコンテナ上にWAAPエージェントを簡単に実装し、実行時にAPI関連の洞察と保護を提供することも可能にしている。

しかし、一部の開発を除いて、一般的にCNAPPとWAAPのベンダーは互いに直接情報を共有していない。

通常、両方のソースからの遠隔測定は、SecOpsの専門家が分析し、相関関係を見つけるために、ロギングプラットフォームに送信される。

そして、これは、脅威への対応に遅延時間を追加するか、脅威が全く検出されない危険性がある。

クラウドフレアに話を戻すと、こうしたWAAPの開発は同社の強みとはまったく一致していない。

CNAPPベンダーのWAAPをハイパースケーラのクラウドに統合することは、クラウドフレアの強みでも戦略的利益でもないだろう。

なぜなら、特に、同社は自社のグローバルPoPネットワーク内に、コンピュート＋ストレージの代替エコシステムを構築しようとしているからである。

さらに、将来のCNAPPとWAAPの統合の主要部分には、コンテナにインストール可能な軽量エージェントや、コンテナ化されたアプリケーションに隣接して配置されるサイドカーエージェントが含まれるようである。

そして、そのどちらもが、同社の能力の範囲内ではないと言える。

対照的に、クラウドフレアのインフラ内のクラウドフレアWorkers上でアプリケーションを構築し実行する開発者にとっては、クラウドフレアのWAAPとAPIセキュリティが適している。

しかし、クラウドフレアのインフラはアマゾン（AMZN）のAWSやマイクロソフト（MSFT）のAzureからまだ何年も遅れており、特にDevSecOpsや最新のソフトウェア開発に必要なCI/CDパイプラインが完全に欠けていることを考えると、このCNAPPとWAAPの統合が進化し続ければ、クラウドフレアのWAAPの地位は疎外されるような気がする。

この複雑な状況を要約すると、WAFが進化してWAAPに拡大するにつれて、クラウドフレアは有利な立場にあるように見えるが、WAAPがCNAPPとともに進化するにつれて劣位に立たされる。

後者の進化に対して、理想を言えば、クラウドフレアは開発者がより安全なアプリケーションを構築し実行できるように、エンドツーエンドのAPIセキュリティ・ライフサイクルにおけるノウハウと能力を深めたいところだが、これはAWSとAzureを知るために多くの時間を費やす必要があることを意味する。

そして、クラウドフレアがCSPと競合する代替サービスを構築することは、良いROI（投資利益率)）の観点からも良い投資とは言えないだろう。

つまり、現在と中期的な近い将来においては、クラウドフレアのWAAPの見込みは良さそうであるが、長期的には、コンピュートとストレージのIaaS（Infrastructure as a Service）全体の開発をどうにかスピードアップし、APIセキュリティを自社のインフラで繁栄させない限り、限界になる可能性があると見ている。