近年、クラウドの需要増とそれに対する攻撃の増加により、インシデント発生のリスクが高まりつつあります。本記事では、弊社で対応した「設定ミスを起因としてクラウド環境上で発生したインシデント」の実例を元に、必要な調査対応と事前準備について取り上げます。
パブリッククラウドの需要増と攻撃の増加
世界のパブリッククラウド市場規模は年々拡大しています。総務省の発行する情報通信白書令和5年度によると、図に示す通り、2021年には前年度比28.6%増の4106億ドル（当時のレートで45兆621億円相当）となっており、予測値ではありますが2026年にはさらにその倍以上の9152億ドル[1]と、引き続き需要が増える傾向が続くとみられています。すでに、クラウド環境を対象にした攻撃は多く確認されており、クラウド市場の拡大に伴い、クラウド環境を狙う攻撃が今後さらに増加していくと考えられます。
世界のパブリッククラウド市場規模
引用：総務省「情報通信白書令和5年版」
2023年のCrowdStrike社のレポートによれば、クラウドサービスに対する需要の急増と、クラウドの管理と制御の複雑さにより、環境を適切に保護するための知識のギャップが生じているとの指摘があります。本レポートによると、安全でない構成や組み込みのクラウドプラットフォーム機能が攻撃者によって悪用され、侵入に発展した事例を数多く確認してきたとされています。
また、攻撃者が設定ミスや管理ツールの悪用といったクラウドに対する専門性を高めており、クラウド環境への攻撃は前年度より95％増加しているとのことです[2]。2024年のCrowdStrike社のレポートにおいても、2022年から2023年にかけてクラウド環境への侵入は75%増加していることが確認されています[3]。
これらのことから、クラウド環境におけるインシデント発生のリスクは年々上昇しており、需要の拡大により、クラウド環境を狙う攻撃が今後も引き続き増加していくと考えられます。
設定ミスを起因としてクラウド環境で起きたインシデントの実例
弊社にご相談いただくインシデントでも、クラウドの設定ミスに起因する侵入やマルウェアの配置といった事象を確認しています。
一般にクラウド環境のサーバにはSSH接続が使用されますが、クラウド環境初期構築時の設定ミスによってSSHのパスワード認証方式でインターネットに公開してしまう事例が発生しています（下図）。
弊社で確認した侵害例においては、推測可能な文字列がパスワードに設定されていたため、攻撃者に容易にパスワードを特定されてしまい、インターネット経由でのSSH接続の侵入を許していました。これにより、攻撃者は侵害起点となるサーバのコントロールを奪取し、その後に侵害起点のサーバから、クラウド環境内部の別のサーバへ侵害を拡大し、マルウェアを配置、永続化しました。
インシデントの実例
クラウド環境でのインシデント発生時に求められる対応とは
一般的にインシデントが発生した際には、その発生原因と侵害範囲を特定し、適切な対策を実施することが必須です。また、情報漏洩の疑いがある場合には個人情報保護委員会やステークホルダーへの報告が求められます。
上記対応を行う際、オンプレミス環境では、NW機器が取得していたログや、物理サーバのディスクを対象に調査を実施する必要があります。対してクラウド環境では各クラウドサービスのログや、仮想マシンイメージが調査の対象となります。調査対象とするデータについては次項で詳しく取り上げていきます。
調査対象とするデータについて
クラウドサービスのログ
弊社で確認した侵害例では、表に示すログを調査する必要がありました。これらのログを侵害例に当てはめたものを図に示します。
調査対象のログ概要
各調査対象のログを示す図
図に関する各クラウドベンダーのサービス名称を表に示します。表に記載する通り、各クラウドベンダーにおけるサービス名称については異なります。これらの名称のうち一部は過去に変更されたことがあり、今後も変更されることがありますのでご注意ください。なお、あくまでここで挙げたサービスは一部であり、各クラウドベンダー独自のサービスが数多く存在する点をご留意ください。
また、侵害の対象が上述の事例のようにクラウド環境に構築されたサーバではなく、クラウド環境自体（≒クラウド環境を制御できるアイデンティティの侵害）である場合には、サービスのログの他にも、サービスのリソース利用や認証に係るログから侵害の痕跡が得られる可能性もあります。
調査対象となるサービスおよびログ
仮想マシンイメージ
仮想マシンイメージを調査することで、攻撃者が内部でどのような侵害を行っていたか、より詳細を把握することが可能です。特に侵害起点と推定されるサーバからは、原因を特定するための情報や横展開の詳細な情報などが得られることがあります。
また、攻撃者が配置したマルウェアの検体を取得できた場合には、通信の宛先情報や、具体的な攻撃行動について把握を行うことができます。DNSのログと組み合わせてマルウェアの通信先と通信を行った他サーバを特定することも可能です。さらに、サーバ内の様々な痕跡から、攻撃者がサーバ内で行った行動や、情報持ち出しの痕跡が得られることがあります。
ただし、侵害の規模によってはすべて調査を行うことは現実味を欠きますので、クラウドサービスのログ調査と組み合わせて、重要な仮想マシンに台数を絞って調査を行うことが推奨されます。加えての仮想マシンイメージの調査には、フォレンジックや、マルウェア解析といった高度な技術が必要となります。インシデントの状況や社内リソースを踏まえ、場合によっては外部委託も検討する必要があります。
インシデントに備えた事前準備
クラウドサービスのログ取得設定
クラウド環境でインシデントが発生した際には、それに対応する様々なサービスのログを対象とし、調査にあたります。ただし、各クラウドサービスによって、取得するために必要な設定、記録の仕方や保存期間、かかるコストなどが異なるほか、デフォルトではログ取得が有効化されていないサービスも多く存在しています。そこが落とし穴となり、インシデント発生時に調査を実施したいが、必要なログが存在しない（取得していない）という場合があります。
例えば表に記載しているOCIのVirtual Cloud Networkサービスは、サービス設定よりログ取得設定を有効化していない場合にはログが保存されません。
このような場合、通信の追跡が困難なため、横展開の調査をする際にNW接点のあるホストをすべて調べることが必要となります。その結果、不要な仮想マシンイメージの調査台数が増え、調査に必要な期間が長くなることが推測されます。加えて横展開被疑の仮想マシン内部でログの消去が行われた場合には調査が難航し、影響範囲の特定がさらに難しくなることが予想されます。
各クラウドベンダーに独自のセキュリティサービスが存在し、それらを活用することで、様々なインシデントに対する対応が可能となります。それぞれの使用環境に合わせて、事前にどのようなインシデントが発生しうるかを検討し、その対応に必要なログ取得設定を行うことで、インシデントに備えることが必要です。
詳細につきましては、各クラウドベンダーのセキュリティやインシデントレスポンスに係るベストプラクティスをご確認いただくことを推奨します。各クラウドベンダーの公式のドキュメントの１例を参考文献[4][5][6][7][8]に記します。
仮想マシンイメージの取得方法を定める
弊社で確認した侵害例のように、攻撃者がクラウド環境上のサーバに対して侵入し、マルウェアの配置や永続化、他サーバへの横展開等を行った場合には、クラウドサービスのログから侵害の全容を把握することは困難です。
このような場合には配置されたマルウェアの解析や、サーバのフォレンジック調査を行うことで、侵害による被害範囲や影響をより深く把握することが可能です。そのため、イメージをクラウド上から取得したうえで、それに対してフォレンジック調査を行う必要があります。
一般的にクラウドの仮想マシンイメージは以下の手順で取得可能です。
- ①仮想マシンの停止
- ②仮想マシンイメージの作成
- ③仮想マシンイメージをストレージにエクスポート
- ④仮想マシンイメージのダウンロード
ただし、上記の手順を実施するうえで注意点があります。
まず、仮想マシンの停止を行う際には揮発性データが消失します。そのため、ファイルレスマルウェア実行の疑いがある場合には、対象の仮想マシンのメモリイメージの取得を行うことも選択肢に入るでしょう。実際にクラウド環境ではないものの、稼働中のサーバ上で不審なプロセスがメモリの大半を占有しているという相談を受け、現地でメモリ取得し調査を行ったケースもあります。
また、仮想マシンの停止が運用上困難な場合もあります。その場合は、停止をせずに仮想マシンイメージを作成することも可能です。インシデントの状況とサーバの可用性を加味した判断が必要です。
上記のようにメモリ取得を行う場合はもちろん、仮想マシンの停止ができない場合や、仕様上イメージの取得ができないクラウドベンダーをご利用の場合には、マシンの内部から調査に必要なデータを収集する必要があります。
仮想マシンのイメージの取得が可能か、可能な場合はどういった手順・拡張子で取得するか、不可能な場合はどのような手法で内部の必要なデータを取得するか、事前に有事のデータ取得方法について定めておくことが望ましいです。
調査の委託及びデータの引き渡し
仮想マシンのイメージを調査する場合には、フォレンジックや、マルウェア解析といった高度な専門技術を活用した調査が必要となり、場合によっては外部に委託を行うことも想定されます。
データ授受の方法としては、主に以下に記載する4パターンが挙げられます。
- ①自社テナントへのアクセス権を調査ベンダーに付与し、データのエクスポートを依頼する
- ②データのダウンロード用URLを調査ベンダー側に提供する
- ③自社テナントから調査ベンダーのテナントへデータをコピーする
- ④自社でデータをエクスポートし、記憶媒体に保存して調査ベンダーに引き渡す
自社の使用しているクラウドではどのようなエクスポートの方法が存在し、社内規則と照らし合わせて有事の際にはどのようにデータを引き渡すことが可能か、事前に検討し定めておくことで、深刻なインシデントが発生した際、よりシームレスなインシデント対応が可能となります。
おわりに
クラウド環境上でインシデントが発生した場合、発生原因と侵害範囲を調査し、対策と報告を適切に行うことが求められます。事前に発生しうるインシデントを検討し必要なログ取得の設定を行うこと、対応の準備をしておくことが必要です。弊社ではクラウド環境で発生したインシデント対応の支援も行っております。お気軽にご相談ください。
[1][情報通信白書令和5年版]データセンター市場及びクラウドサービス市場の動向
https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd248200.html
[2]2023 Threat Hunting Report | CrowdStrike
https://www.crowdstrike.com/resources/reports/threat-hunting-report/
[3]CrowdStrike 2024 Global Threat Report | CrowdStrike
https://www.crowdstrike.com/global-threat-report/
[4]エージェントレスマシンのスキャン-Microsoft Defender for Cloud | Microsoft Learn
https://learn.microsoft.com/ja-jp/azure/defender-for-cloud/concept-agentless-data-collection
[5]AWS Security Incident Response Guide-AWS Security Incident Response Guide (amazon.com)
https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html
[6]セキュリティのベストプラクティスとパターン-Microsoft Azure | Microsoft Learn
https://learn.microsoft.com/ja-jp/azure/security/fundamentals/best-practices-and-patterns
[7]Cloudセキュリティベストプラクティスセンター | Google Cloud
https://cloud.google.com/security/best-practices?hl=ja#google-cloud-security-best-practices-center
[8]セキュリティおよびコンプライアンスの効果的な戦略について(oracle.com)
https://docs.oracle.com/ja/solutions/oci-best-practices/effective-strategies-security-and-compliance1.html
