CSPMの利点と課題｜実際に運用してみて

クラウドサービスの設定不備に起因した事故や事例が取り上げられ、その対策としてCSPM（Cloud Security Posture Management）が注目されています。一方で、CSPM製品導入に係るコストや具体的にどのように運用していくのか、最終的にどのような効果があるのか等がよくわからないため、実際に社内で試してみるところまで話が進まないといったこともあるでしょう。

本稿では、実際のAWS（Amazon Web Service）環境にCSPMを導入した際のアラートなどを基に、運用していく中で見えてきた利点と課題についてご紹介したいと思います。読者の皆様のCSPM導入検討の一助となれば幸いです。

CSPMの始め方｜Prisma CloudとCloudscortの例

今回紹介する環境ではニューリジェンセキュリティ株式会社が提供しているCloudscort（クラウドスコート）^[i]とパロアルトネットワークス株式会社が提供しているPrisma Cloud（プリズマ クラウド）^[ii]の2製品を同一のAWS環境に導入しております。

細かい手順の違いはありますが、CSPMを導入する際は下図に示すように、それぞれの製品から提供されるテンプレートを対象のAWSアカウントにおいて指定されたパラメータを用いて実行することになります。この操作により検査用の実行権限が払い出され、検査時に当該権限を使用することで幅広いリソースを網羅的に検査することが可能となっています。

CloudFormationを使ってテンプレートからIAMロールを作成

各製品の機能差異について詳細は後述しますが、CloudscortとPrisma CloudではAWSのリージョン^[iii]の扱い方が異なっています。

Cloudscortでは対象のリージョンを指定する必要がありますが、Prisma Cloudでは対象のリージョンを指定する必要はありません。複数のリージョンを検査対象にしたい場合にはPrisma Cloudの方が有利に見えますが、検査オプションによっては使っていないリージョンに関しても検査が行われ、一時的にAWSのリソースを作成する（≒余計なコストが発生する）ことがあるため、製品選定をされる場合にはどのような検査オプションがあるのかを事前に把握しておくことをお勧めします。

検知したアラート

ここからはCSPMソリューションで検知されるEC2インスタンスにまつわるアラートを、各製品から1つずつ具体的に紹介したいと思います。

いずれも深刻度が「HIGH」以上で対応が必要となりますが、導入すると一度は目にすることになるものと、導入しないと気付かないと思われるものをピックアップしました。

①Cloudscort：SSH通信制限設定

こちらは読者の方もイメージしやすいのではないかと思いますが、EC2インスタンスに設定されているセキュリティグループにおいて、インターネットからのアクセスが可能になっている（＝「0.0.0.0/0」が設定されている）ものを検知したアラートになります。

上記設定があることで即時に侵害を受けるわけではありません。AWSが提供している多くのOSイメージのSSHアクセスは鍵認証が前提となっており、パスワードでの認証は無効となっているためです。ただし、業務要件により、自前でカスタマイズしたOSイメージなどではパスワード認証が許可されていたり、管理者権限での直接アクセスが可能となっている場合があり、そういったケースでは本設定により侵害されるリスクが高くなります。

Cloudscortでは危険度の高いイベントを優先して通知する機能を持ち、そのようなセキュリティグループが作成されるとリアルタイムで通知され、管理者はすぐに気づくことができるようになっています。

Cloudscortから送られてくるメールは以下になります。

※一部IDはマスクされています

• To：20000-00000011-AWSCSPM-00001 ご担当者様
•  
• ご利用中のAWS環境に関して、Cloudscortが推奨する適切な設定が行われていません。
• 下記の通りご報告いたします。
•  
• ■処理日時　　　　：2024-01-25 11:44:19
• ■アラートID　　　：AC24012510000071
• ■環境名　　　　　：20000-00000011-AWSCSPM-00001
• ■AWSアカウントID ：054321XXXXXX
• ■リージョン　　　：ap-northeast-1
• ■内容　　　　　　：セキュリティグループのインバウンドルールにおいて、SSH通信元のIPアドレスを制限してください。
• - 参考URL : https://docs.aws.amazon.com/console/securityhub/EC2.13/remediation
• - AwsAccountId: 054321XXXXXX
• - Type : AwsEc2SecurityGroup
• - ResourceId : arn:aws:ec2:ap-northeast-1:054321XXXXXX:security-group/sg-046a5c49820XXXXXX
•  
• [本アラートに対応する CIS Benchmark 1.5 の項目は 5.1, 5.2 です]
• セキュリティグループのインバウンドルールにおいて、送信元IPアドレスを制限することが推奨されます。
• 送信元IPアドレスを制限していない場合、許可されていない悪意のあるユーザから接続できる可能性があり、当該リソースが侵害されるリスクがあります。
•  
• CIS Benchmark 1.5の項番5.1, 5.2では、セキュリティグループやネットワークACLのインバウンドルールを設定することが推奨されています。
• ■検知種別　　　　：未然防御
• ■重要度　　　　　：Critical

Cloudscortでは設定されている項目に関して、参考URLやガイドラインに照らし合わせてどのような問題があるかを内容として提示しているため、管理者にとっては必要十分な情報が載っていると思われます。

なお、今回の環境ではこのような設定に関して、AWS Config^[iv]による対策を実施しており、特に攻撃によく利用されるSSHとRDPに関しては、AWS Configが検知した後に当該ルールを削除するように設定しているため、リスクのある設定が継続して残る可能性は無い状況でした。

他方で、すべての処理がAWS側で行われていたため、具体的にどのようなセキュリティグループがいつ作成されたのかを確認するためには膨大なCloudTrail^[v]ログを参照する必要があり、追跡には大きな負荷が伴う状態となっておりました。Cloudscortは危険度の高い内容を管理者に代わって仕分けするため、Cloudscortを導入することでそういった管理者の負荷の軽減が期待できます。

②Prisma Cloud：IMDSv2利用必須設定

EC2インスタンスから「メタデータ」と呼ばれるEC2インスタンス等の様々な静的・動的情報を固定IPアドレス169.254.169.254へhttpアクセスすることで取得できてしまう、IMDS（Instance Metadata Service）^[vi][vii]に関するアラートです。

2019年11月より前のIMDSv1はhttpのGETメソッドを使ったアクセスのみをサポートしておりましたが、悪用される可能性のある脆弱性を含むことから、2019年11月にIMDSv2としてトークンを利用したセッション指向のアクセス方法が追加されました。

EC2インスタンスを起動する際の初期設定では、従来のIMDSv1とIMDSv2のいずれも使用できる状態となっていますが、先に述べたようにIMDSv1には脆弱性があることから、現在はIMDSv1 の使用を禁止してIMDSv2のみが使用できる状況にすることが推奨されています。

Prisma CloudはIMDSv1が有効になっているEC2インスタンスを常時監視しており、すでに稼働中のEC2インスタンスだけでなく、新規に作成されたEC2インスタンスについても即座に検査を行って必要に応じてアラートを出力します。

Prisma Cloudから送られてくるメールは以下になります。

文面には概要のみが記載されている代わりにCSVファイルが添付されており、詳細はCSVファイルを参照する形になります。CSVファイルではEC2インスタンスのホスト名や抵触するガイドライン、推奨する対応方法などの情報が記載されております。

例えば、推奨する対応方法は下記の内容となっています。

1. Log in to the AWS Console
2. In the console, select the specific region from the region drop-down on the top right corner, for which the alert is generated.
3. Refer 'Configure instance metadata options for existing instances' section from follwoing URL
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
   
   NOTE: Make a precaution before you enforce the use of IMDSv2, as applications or agents that use IMDSv1 for instance metadata access will break.

Prisma CloudではAWSの広範な環境を自動で監視するようになっているため、危険なイベントが発生したタイミングだけではなく、既存の（EC2インスタンスなどの）リソースに関しても検査を実施し、アラートを上げることができるようになっています。

今回CSPMを導入しているAWSアカウントには100以上のEC2インスタンスが作成されており、その多くがIMDSv2のみを利用する設定ではなかったことから、当初は大量のアラートが発生しました。

特に、開発のために日々ビルドし直されるようなEC2インスタンスについては毎日アラートが発生し、根本的な対応のためにはアプリケーションのソースコードの修正が必要となるため、一筋縄での対処が難しく、最終的に管理者側でIMDSv1のみに対応していた関数をIMDSv2に対応するよう修正して問題を解決する形になりました。

最近のOSイメージを利用したEC2インスタンスでは、基本的にIMDSv2に対応しています。そのため、EC2インスタンスの設定を変更するだけで対応は完了する場合ありますが、関係者が多く存在することから、対応されないまま放置されるケースもあり、活動を始めて約半年が経過した現時点でようやく撲滅できる目途が付いたという状況です。

CSPMの機能差異について

ここまでCSPMで検出された代表的なアラートをあげましたが、以下表に示すように一口にCSPMと言っても、製品によって検出する結果や範囲が大きく異なることがわかります。

CloudscortとPrisma Cloudの比較

例に挙げたCloudscortの検出結果は直ちに対応しないと重大なセキュリティリスクにつながるものですが、それらを日々AWSのマネジメントコンソールから確認するのは運用的に無理があります。

自前でメール通知する仕組みを構築することも可能ではありますが、そういった機能をあらかじめ用意しているCSPMソリューションを導入することで、運用のための開発を避けることができます。

また、AWSをはじめとしたパブリッククラウドサービスでは、日々新しいサービスや機能がリリースされており、それらをユーザ側で常に確認するのは非常に困難です。先の例でPrisma Cloudで検出されたIMDSv2がその最たるもので、こうした新しい機能をCSPM側でウォッチし、他の検出結果と併せて確認することができるのはユーザにとってメリットがあるでしょう。

おわりに

CSPMソリューションについて、アラートなどの例も交えて実状をお伝えいたしました。

CSPM運用はパブリッククラウドサービスを利活用していく上では必要不可欠な要素ですが、ユーザ側で対策するだけでは十分とは言えないのが事実です。先述したように、今回の環境ではAWS Configを利用してインターネットからのアクセスを自動で削除できるようにしておりましたが、EC2インスタンスのIMDS設定についてはほとんど意識できておらず、CSPMソリューションを導入して気づくことができました。

また、CSPMを導入すると、様々なケースでアラートを検知します。日々発生するアラートを仕分けするのがまず重要ですが、“仕分け”という新たな運用が追加となるため、既存の運用業務と併せて、管理者の負荷が高まる可能性があります。

アラートの抑止をすることで仕分けを不要とすることも可能ですが、抑止の判断は難しく、明確な理由があるケースは稀です。そのため大抵の場合、“代替の対策を施した上で”抑止とするなど、何らかの対応が発生することもあります。

情報漏洩や設定不備によるリスク・影響を鑑みると、CSPMは必須といっても過言ではありませんが、上記のように運用が大変であるのも事実です。今回ご紹介したCloudscortとPrisma Cloudに関して、当社ではお客様をご支援するサービスをご用意しております。CSPMの導入のご検討、実際にお使いの上でのお悩み事やご相談事項がありましたら、お気軽に弊社担当までお問い合わせいただければ幸いです。

[i] Cloudscort（https://www.nuligen.com/service/cloudscort）

[ii] Prisma Cloud（https://www.paloaltonetworks.jp/prisma/cloud）

[iii] リージョンとゾーン：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

[iv] AWS Config：https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/WhatIsConfig.html

[v] AWS CloudTrail：https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-user-guide.html

[vi] インスタンスメタデータの取得：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

[vii] デフォルトでの Amazon EC2 インスタンスメタデータサービス IMDSv2：https://aws.amazon.com/jp/blogs/news/amazon-ec2-instance-metadata-service-imdsv2-by-default/