そもそもクラウド上のワークロードとは？

現在、クラウド上で利用されるコンピューティングのワークロードは非常に多様化しています。一昔前はクラウド上のワークロードと言えば、AWS EC2のような仮想マシンが大半だったと思いますが、新しい技術（コンテナ/サーバレス等）の台頭と一般化により、ビジネスのニーズに合わせて、様々なワークロードが利用されるようになっています。弊社も多くのお客様・特にサービス開発の立場に近い部署の方と会話をしておりますが、ビジネスニーズに合わせて本当に多様なワークロードが利用されてきていることが伺えます。

クラウド上のワークロードについては、Palo Alto Networks社のホワイトペーパーにて分かりやすく整理されていますので、少しご紹介したいと思います。

「The Continuum of Cloud Native Topologies」

https://www.paloaltonetworks.com/resources/whitepapers/continuum-cloud-native-topologies

上図の通り、このホワイトペーパー内では、7つのワークロード分類として整理されていますが、この中で最もよく用いられている代表的なワークロードは以下の5つではないでしょうか。

• VMs（仮想マシン）
  恐らく最も一般的かつワークロードの数が多いのはこのVM（仮想マシン）であり、OS/アプリケーション/データが分離されていない形で運用されています。代表的なサービスとしては、Amazon EC2やGoogle Compute Engineのインスタンスが挙げられます。
• Containers（コンテナ）
  仮想マシンとは異なり、ホストOSのカーネルを共有することでCPUやメモリ等のリソースを隔離し、仮想的な空間を作り出す。Dockerの登場によって急速に普及。
  後述のCaaSとの違いは、基盤となるすべてのインフラの展開と運用にユーザーが清任を持つ必要がある点になります。（Amazon EC2上にユーザーが自分でDockerを構成して利用するようなイメージ）
• CaaS（コンテナ・アズ・ア・サービス）
  コンテナの使用が進み規模が大きくなるにつれ、Kubernetesのようなコンテナオーケストレータ―が利用されるようになると、その展開・運用に対する複雑性が課題になってきました。そこで、大手パブリッククラウドプロバイダーによって、オーケストレーターのコンテナ展開・管理機能をサービスとして利用できる手段が提供されています。代表的なサービスとしては、Google Kubernetes EngineやAmazon Elastic Container Service等が挙げられます。後述するOn-demand containersとの違いは、ユーザーが基盤となるVMとホストOSを直接管理できる（する必要がある）ということです。
• On-demand containers（オンデマンドコンテナ）
  上述のCaaSにおいては、ユーザーが基盤となるVMとホストOSを直接管理できますが、開発者にとっては、基盤となるホストOSやVMの知識や設定を必要とせず、コンテナを簡単に実行できることが求められるケースがあります。このオンデマンドコンテナのプラットフォームは基盤部分の考慮を必要とせず、コンテナのメリットを享受できるよう設計されたサービスとなります。代表的なサービスとしては、AWS FargateやAzure Container Instances等が挙げられます。後述するServerlessとの違いは、他のコンテナプラットフォームでも実行可能な通常のコンテナイメージを実行するという点です。
• Serverless（サーバレス）
  サーバレス技術は、開発者がアプリのコードだけをサービスに提供すると、サービスはその下にある残りのスタックを自動的にインスタンス化します。サーバレスにおいては、開発者はアプリのパッケージをアップロードするだけで、コンテナイメージやOSコンポーネントを用意する必要ありません。代表的なサービスとしては、Amazon LambdaやAzure Functions等が挙げられます。

CWPPの定義

Gartnerでは「2021 Gartner Market Guide for CWPP」の中で、CWPPを以下のように定義しています。

"workload-centric security products that protect server workloads in hybrid, multicloud data center environments."

様々なクラウド環境におけるサーバワークロードを保護する、ワークロード中心のセキュリティ製品ということですが、上記でワークロードの種別をご紹介したとおり、ワークロード自体も多様になっていますので、「多様なクラウド環境における多様なワークロードに対して一貫した可視化とコントロールができること」がCWPPの果たすべき役割だと考えています。クラウド環境自体もハイブリッドクラウド・マルチクラウド化が進んできていますので、これらにシームレスに対応できるかも重要なポイントです。

また、クラウドネイティブなアプリケーション環境においては、開発パイプラインの中で事前にワークロードに含まれ得るリスク（脆弱性やコンプライアンス違反等）をスキャンできることも重要になります。この点は特に、多くの企業にとって従来型のサーバ向けセキュリティ製品と大きく位置づけが異なると感じられるポイントではないかと思います。

CWPPが提供する機能

上記でも少し触れましたが、CWPPが提供すべき機能として大きく2つの観点があり、これらについて、それぞれ複数の機能を利用しながら実現しています。

これらを多様なクラウド環境・多様なワークロードに対して、一貫性を持って提供できることがCWPPに期待される機能と言えます。

• Development Scanning（開発段階でのスキャン）

• Runtime Protection（ランタイム保護）

CWPPはいつ導入検討すべきなのか？

ここまでご説明したCWPPはどのようなタイミングで導入を検討するべきなのでしょうか？ これまで多くのお客様とコミュニケーションさせて頂く中で、大きく2つの観点があると考えています。

• 新しいワークロードの本格利用時
  多くの企業ではワークロードとして、物理マシンや仮想マシンがまだまだ多くの割合を占めていると思いますが、ビジネス要件から新しいワークロード（特に上述したCaaSやOn-demand containers、Serverless）を本格的に利用することになった場合、多様なワークロードに対して一貫した可視化・コントロールができるCWPPを変化に合わせた新しいセキュリティ対策として検討されることがよいと思います。また、従来から利用しているサーバ向けセキュリティ製品が技術的に新しいワークロードに対応できない（AWS Fargateを利用する場合エージェントが導入できない等）場合もあるかと思います。加えて、コンテナ技術を活用することで、開発と運用の境目が曖昧になり、よりDevOps的な開発スタイルが求められますので、開発段階でセキュリティリスクを検出して、開発の流れにスムーズに適用できるCWPPの機能は必要要件になってきます。
• パブリッククラウドサービス設定監査方法の検討時
  パブリッククラウドを利用している中で、社内に多数作成されてしまったアカウントの管理や、各利用部門での設定不備によるインシデント発生のリスクなどが課題となり、パブリッククラウドサービスの設定監査を検討される企業が多くあります。特にAWSとAzureなど複数のクラウドを用途によって利用する、いわゆるマルチクラウドとなる場合、各パブリッククラウド側のネイティブサービスのみでは一元的な監査が難しいため、CSPM（Cloud Security Posture Management）と呼ばれるパブリッククラウドサービス上の設定を自動的に監査・リスクを検出してくれる仕組みの導入が必要になってきます。CSPMの詳細について本記事では触れませんが、昨今の流れとして本記事のテーマであるCWPPとCSPMはその特性上融合が進んでおり、同じ製品・ライセンスの中でどちらの機能も利用できるものが出てきています。（弊社で販売をさせて頂いているPalo Alto Network社 Prisma Cloudがまさしくそのような形となっています。）
  そのため、CSPMをパブリッククラウドの設定監査ツールとして検討することと合わせて、そこで動作するワークロード自体の保護を同じプラットフォーム上で提供されるCWPPに寄せていくことは、将来の投資対効果・リスクへの一元的な対応という観点で非常に意味のあるものとなります。

まとめ

CWPPはワークロードの多様化・ワークロードが動作するクラウド環境の多様化といった流れに沿って登場したセキュリティ製品となります。デジタルトランスフォーメーションによる積極的なデジタル技術の活用の動きもあり、このような流れは今後も引き続き加速していくことが想定されることから、CWPPのようなセキュリティ対策の検討は企業にとってますます重要事項になっていきます。

弊社では、Prisma Cloudのご導入を通じて、国内でも非常に先進的なCWPPの導入案件を多く支援させて頂いております。詳細をお知りになりたい場合は、ぜひお気軽にお問合せください。