SSE: 誰も教えてくれないこと(でも私は教えます)
パート2/3: セキュリティ以上のものを実現するにはSSEが必要
こんにちは、戻ってきました!第2ラウンドでは、このリアルトークシリーズの最初のブログ「パート1:要件のすべてが特定されていない」で取り上げ始めたトピックをさらに掘り下げていきます。第2回はデータパスについてです。早速見ていきましょう。
顧客の声に耳を傾けることは大きな利益をもたらす
シマンテックとCarbon Blackは、毎年何百もの素晴らしい新機能のリクエストを受けています(結局のところ、お客様は最高です)。これらの素晴らしいアイデアは、お客様中心のイノベーションを推進する上で役立つと同時に、プロダクトマネージャーにとって最も難しい点の一つでもあります。それは、素晴らしいアイデアがたくさんある中で、何を開発するかをどう決めるかということです。
良いニュースとしては、適切な新機能を選び、それをリリースに多く組み込むのがかなり上手くなったということです(自慢するわけではありませんよ、本当なら)。Edge SWG 向け SGOS 7 のリリース時には、100件を超えるお客様からの機能リクエストに対応しました。クラウド側では、最近Agent Traffic Manager (ATM) をリリースし、20件もの機能リクエストに一挙に対応しました。最近、 LinkedIn に投稿しました(マーケティング部門の責任者が私をコントロールできないので)。投稿では、過去1年間のネットワークセキュリティ機能リクエストの対応ペースを示しました。ちなみに、このチームだけで129件のリクエストに対応しました。
しかし、リリースのペースは全体像の半分しか語っていません。真の試金石は、機能が実際に採用されるかどうかです。そして嬉しいことに、私たちの機能は「プレビュー」バッジを削除する前でも、本番環境でお客様に採用していただいています。「お客様の声に耳を傾ける」という言葉は、まさに本気でそう思っています。
そして、これは、あまり目立たない(しかし、それでも重要な)問題点を明らかにするために最も重要です。
驚くかもしれませんが、これらの機能リクエストは、皆さんが想像するほど、必ずしも従来のセキュリティ重視のものではないのです。SSEやゼロトラスト・プラットフォームについてアナリストに話を聞くと、彼らは95%の時間を各ベンダーのセキュリティ機能について話すことに費やします。これは必ずしも悪いことではありません。結局のところ、セキュリティこそが私たちの存在意義なのですから。
しかし、過去10年間、お客様からのアイデアを取り入れ、Cloud SWGを構築してきた中で、お客様のSSEに関する悩みの大半はセキュリティの有効性ではなく、データパスに起因するものであることがわかりました。SSEを導入したことがある方なら、私が何を言っているのかよくお分かりいただけると思います。
データパス: IYKYK
アナリストはデータパスの話は嫌います。非常に面倒だからです。彼らにとっては、あなたがまだ持っていない新しい「ピカピカのセキュリティオブジェクト」を指摘し、どこで購入できるかを手伝う方がずっと簡単です(彼らは間違いなく、そのための素晴らしいチャートを持っているはずです)。あなたもそのチャートを気に入って購入を決意します。数ヶ月後、何度か試行錯誤を繰り返しましたが、まだ導入目標は達成できず、ベンダーに不満を抱き、あんなに素晴らしいチャートがどうして間違った方向に導いてしまったのかと自問自答しています。
残念ながら、これは非常によくあることです。データによると、かなりの割合の顧客が、チャートに示されているベンダーのソリューションを採用していないことが示されています。なぜでしょうか?私の仮説は、顧客がデータパスの課題を考慮していないということです。アナリストは、この課題をプレゼンテーションとチャートから都合よく除外しています。
データパス、接続性…トマト、トマト
ベンダー以外では、「データパス」は「接続性」という用語でよく使われます。昔、ネットワークセキュリティがすべて企業ネットワークの範囲内に収まっていた時代は、セキュリティスタックへの接続は簡単でした。
しかし、SSEではそうではありません。SSEでは、これまで自社データセンターで終端していたすべてのフローをSSEスタック(他社データセンター)に移動する必要があります。そして、ネットワークの構築方法やトラフィック量によっては、データの移動作業がSSE導入における最も重要な課題となる可能性があります(だからこそ、SSEデータパスの実装を容易にする機能への需要があり、私たちはそれを実現することにこだわっているのです)。
SSE の旅を簡単にする機能
お客様の素晴らしいご尽力のおかげで、Cloud SWGのロードマップは主に3つの主要機能に焦点を当てています。これらの機能について知っていただくだけで、お客様の環境をより深く理解し、 SSE接続のニーズよりも「チャート」上の位置を重視してベンダーを選択するという苦労を回避できるようになります。
- ポリシーベースルーティング。数千ものコンテンツプロバイダーが、特定のソースIPアドレスまたは位置情報(あるいはその両方)にアプリをブロックしています。そのため、ユーザーは既にSaaSアプリに企業IPアドレスを登録している可能性が高いでしょう。また、ジオフェンシングのせいで、海外でホストされているビジネスクリティカルなアプリケーションへのアクセスに苦労している基幹業務チームもいるでしょう。ポリシーベースルーティングのような対策を講じなければ、SSEへの移行によってこれらのアプリへのアクセスが遮断される可能性があります。
- エージェント・トラフィック・マネージャー。パンデミック以前は、SSE接続の75%がサイト間トンネル経由でした。パンデミック中は、この数字が逆転し、SSEトラフィックの75%がエージェントを使用してクラウドにリダイレクトされました。ハイブリッドワークのシナリオが非常に多様化しているため、お客様はよりきめ細やかで柔軟なエージェント・トラフィック・インターセプト・ポリシーを必要としていました。幸いなことに、 ATM を使用すれば、最も複雑なハイブリッドワークのシナリオでも、当社のエージェントによって対応できます。
- Cloud SWG Express Connect 。従来のサイト間トンネルでは、大規模なマルチギガビットワークロードをSSEに接続するのは非常に困難です。IPsecまたはGRE経由で接続された10ギガビットワークロードには、トラフィックをトンネル全体に均等に分散するためのロードバランサを備えた5~10個のトンネルが必要になります。これは構築が非常に複雑で、非常に脆弱で、非常に静的です。しかし、この新しい高帯域幅接続機能(Googleとのパートナーシップにより実現され、現在プレビュー段階ですので、今後の展開にご期待ください)により、お客様は単一のトンネルを必要とせずに、大規模なワークロード(100Gbps以上)を安全にSSEに接続できます。
宿題です
これらの機能の概念に馴染みがない場合は、チームと協力してデータパスのニーズを深く掘り下げる時間を設けてください。SSEの導入を妨げる可能性のある、不便ではあるものの実際に起こりうるコーナーケースも考慮に入れるようにしてください。
購入前に、それらのシステムを SSE ベンダーに接続する方法を完全に検討しておく必要があります。
楽しみはまだ終わりません!このSSEシリーズの第3弾(そして最終回)は近日公開予定です。お楽しみに!
それまでの間、弊社のオンデマンド ウェビナー「SSE: 彼らが教えてくれないこと (しかし私たちが教えること)」をご覧ください。





