クラウドコンピューティングが急速に普及する現代において、クラウド上のデータとアプリケーションの安全性を確保することは今まで以上に重要になっています。その課題に対処するための最適なソリューションとして、日本でも徐々に認知度が高まってきているのがCWPPです。今回は、CWPPの概要と必要性について個人の意見を交えつつ解説します。
本題に入る前にお知らせです！
＝＝＝＝＝＝＝
【CSPMマネージドサービス SmartOneCloudSecurity】
SmartOneCloudSecurityは、PrismaCloudを用いたCSPMマネージドサービスです。PrismaCloudの導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、PrismaCloudを利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。PrismaCloudのPoCの相談も受けています。
New!! 2023/4より、CWPPの導入サポートも始めました！
CWPPの概要
CWPPとは？
CWPPはCloud Workload Protection Platformの略で、クラウド環境でホストされているワークロードやデータの保護を支援するために設計されたセキュリティソリューションの一種です。
クラウド上で実行されるワークロードに対して、リアルタイムでの監視/分析や、セキュリティ上の脆弱性、潜在的な脅威を検出し対処する、といったことを行います。
下の図に主だったセキュリティソリューションを纏めています。CWPPはCSPMと同じくクラウド環境に対するセキュリティソリューションになりますが、それぞれ守備範囲が違っています。
イメージとしてはEPPやEDRに近しいのですが、EPPは守備範囲が業務で使うパソコンやモバイルデバイスで、CWPPはよりクラウドに特化して、例えばオートスケールに容易に対応できるとか、コンテナ間の論理的な通信を監視できたりというように、クラウドのリソースを守備範囲としているところが違いになります。
最近ですとコンテナの利用が進んでいて、コンテナ環境に対してのセキュリティ対策として利用される形が多くなってきています。
CWPPとCSPMとのすみ分け
もう少しイメージを掴んでもらうために、企業がクラウド環境のセキュリティ対策を検討する際によく比較される、CSPMとCWPPとの棲み分けについて図示してみました。
CSPMは、一言で言うと、各クラウドサービスの管理コンソール上で設定/確認できる範囲が守備範囲になっています。一方、CWPPは管理コンソールでは設定/確認ができない、インスタンスの中身（＝ワークロード）が守備範囲になり、実際に稼働するホストやコンテナなど、ワークロードレベルでの脅威の検出や、アタックへの防御を行います。
ですので、CSPM、CWPPどちらかだけ対策すればいいというわけではなく、クラウド環境のセキュリティ対策を包括的に実施するには、どちらの考えも必要になってきます。
ワークロードとは？
ワークロードについても少し触れておきます。
ワークロードはクラウドインフラ上で実行されているタスクやアプリケーションを指していますが、CWPPではもう少し広く捉えてそれらをホストしているプラットフォームも含んでワークロードと呼んでいます。
AWSの例でいうと、EC2、ECS/EKS、コンテナとそれらの上で実行されているアプリケーションもワークロードですし、LambdaやFargateもワークロードで、それらを防御するのがCWPPソリューションです。
CWPPの必要性
ここからなぜCWPPが必要になるかを解説します。
コンテナへの攻撃が増加傾向
ポイントはいくつかあるのですが、まずシンプルにコンテナに対しての攻撃が増加傾向にあります。
2023年2月にNICTがNICTER観測レポートを出していますので引用しますが、Dockerに対しての攻撃が2021年から継続して行われており、攻撃対象としての順位も年々上がってきています。コンテナの考え方自体は昔からあるものですが、利用され始めたのはここ最近の話で、監視や運用の仕組みの整理はまだこれからという状況です。また、Docker以外にはIoT機器が攻撃対象の上位になっています。DockerもIoTもここ最近使われ始めていて、必要なセキュリティ対策がしっかり取られている状況ではなく、そのような環境が狙われるのはイメージしやすいと思います。
コンテナ型仮想実行環境を提供するDockerにおいて遠隔管理の機能を提供するDocker REST APIの2375/TCPと2376/TCPは上位に観測され、これらのサービスを狙う攻撃が2021年から継続しています。
IoT機器で依然として使用されているTelnet（23/TCP）を狙った攻撃が占める割合が、2021年の11.0%から23.0%へと増加したことにあります。IoT機器が使用する特徴的なポート番号はこれまでにもボットネットの攻撃対象として多く観測されていましたが、2022年は特に23/TCPを含むポートセット宛の攻撃が活発に観測されました。
監視の難しさ
少し前に仮想通過を不正にマイニングするクリプトジャックの攻撃が話題になりました。これは、コンテナという環境が多数のリソースで構成されていてマイニング利益を出しやすいという特性もあるのですが、監視が難しいというのも１つのポイントになります。
これはクラウドの責任共有モデルも関係していて、アプリケーションやデータを守るのはユーザー自身となっているのですが、守る具体的な手段がユーザー側に十分に提供されている状況ではないことが対策を難しくしているように思います。
これは1例ですが、AWSのECSサービスのベストプラクティスガイドから抜粋で、ランタイム防御はサードパーティ製品の利用が推奨されています。
ランタイム防御は、CWPPのいくつかある機能の中心となるもので、マルウェアのダウンロードをブロックしたり不正なアクティビティを検出したりする機能のことです。ここを対策しようとすると、AWSのネイティブ機能を利用するだけでは防御しきれない状態と言えそうです。
ランタイムセキュリティを設定するときは、次のアクションを実行することをお勧めします。
ランタイム防衛にサードパーティーソリューションを使用する
※出典：Amazon Elastic Container Service – のベストプラクティスガイド
少し古い話題ではありますが、以前にテスラ社がクリプトジャッキングの被害にあったとニュースになりました。この話のポイントは、どうやって攻撃されたかではなくどうやって気づいたかで、気づいたのはテスラ社ではなく、巡回していたセキュリティのサードベンダだったということです。こちらは実際に起こった事例として紹介しておきます。
※参考：Tesla and Jenkins Servers Fall Victim to Cryptominers
取るべき対策
コンテナを守るために具体的に何を対策しないといけないかに触れます。
参考となるのは、NIST（米国国立標準技術研究所）が発行しているNIST SP800-190「アプリケーションコンテナセキュリティガイド」です。
SP800-190は、コンテナ技術のセキュリティ対策に焦点を当てたガイドラインで、コンテナ化されたアプリケーションのデプロイメントと運用に関連して、セキュリティリスクとそのリスクへの対応方法を纏めたものです。
詳細は下記参考に日本語訳されたガイドラインのリンクを記載していますので、実際のものを参照いただきたいのですが、例えばセキュリティリスクに関しては3章に纏められており、それを見ると、レジストリ、コンテナイメージ、コンテナ実行環境、オーケストレータ、ホストOSといった、ワークロードとして定義されているもの全てに対して、大きくは、脆弱性を管理する、セキュリティ上脆弱な設定を見直す、実行環境を防御するという観点で、自動的に監視して異常を検出させる必要があるというようなことが記載されています。
これら１つ１つを自前で監視、大作するという仕組みを準備するのはかなり大変です。そこでCWPPソリューションの出番になりますが、例えばこういったセキュリティリスクに対して監視し、設定不備の検出や、ものによっては自動的に設定を修復するといったことを簡易に行える、それがCWPPソリューションになります。
まとめ
CWPP（Cloud Workload Protection Platform）は、クラウド環境におけるあらゆるワークロードのセキュリティを強化するためのソリューションです。特にコンテナに関しては、具体的に攻撃が増えているにも関わらず対策することが難しくなっています。今回はCWPPの必要性を共有するところまででしたが、安心してクラウドサービスを利用できるよう、もう少し踏み込んだ内容を今後更新できるようにしていきます。
・CSPMについても解説している記事があるので、気になる方は見てみてください！