クラウド環境におけるインシデントレスポンス 第1回

クラウド環境におけるインシデントレスポンス 第1回


クラウド環境におけるインシデントレスポンスで重要となる責任共有モデルおよびインシデント領域など、クラウド特有の性質や留意点について解説します。


要点

  • クラウドコンピューティングの普及やサイバー攻撃のハードルの低下に伴い、企業を取り巻くサイバーセキュリティのリスクは増加傾向にある。そのため、適切なインシデントレスポンスは、事業継続や影響の最小化等の観点から重要な事業課題の1つとなっている。
  • クラウド環境におけるインシデントレスポンスはオンプレミス環境と異なる特性を理解した上で、適切に対処する必要がある。
  • 各種ガイドラインを活用し、発生し得るインシデントに対して、計画的に対応の準備を進めることが重要となる。


はじめに

近年、クラウドコンピューティングの普及に伴い、企業のIT運用やセキュリティ管理は一層複雑化しています。

さらに、RaaS(Ransomware as a Service)やMaaS(Malware as a Service)の活性化などのサイバー犯罪市場の成熟化に加え、性能が向上したペネトレーションテストツールや生成AIなどの新興技術が悪用されることで、高度な知識や技術を持たない者でもサイバー攻撃を実行できるようになり、そのハードルは大幅に下がっています。また、ダークウェブや仮想通貨等の匿名性を確保する環境は、サイバー攻撃の実行およびマネタイズを容易にしており、企業を取り巻くサイバーセキュリティのリスクは増加する傾向にあります。

こうした状況の中、企業側での利活用が進むクラウド環境もサイバー攻撃の標的となる可能性が高まり、事業継続や影響の最小化等の観点から適切なインシデントレスポンスは、重要な事業課題の1つとなっています。

本記事では、クラウド環境におけるインシデントレスポンスを解説するシリーズの第1回として、クラウド環境の基本的な性質やインシデントレスポンスを行う上での留意点を解説します。

第2回以降、クラウド環境における脅威や具体的な対応事例等の紹介を予定しており、効果的なインシデントレスポンスや対応計画の整備・策定に有用な情報を発信する予定です。


インシデントレスポンスの概要

インシデントレスポンスは、一般社団法人JPCERTコーディネーションセンター(以下、「JPCERT/CC」)によると、以下のように定義されています。

インシデントが発生した後の被害を最小限にするための「事後」対応を、インシデント対応(レスポンス)と呼んでいます。

出典:JPCERT/CC「インシデント対応とは?」, www.jpcert.or.jp/ir/(2024年12月3日アクセス)


クラウド環境におけるインシデントレスポンスでは、オンプレミス環境(以下、「オンプレ」)とは異なるクラウド環境の特性を考慮した手続きを行う必要があります。この手続きを検討するにあたっては、クラウドサービスプロバイダー(以下、「CSP」)が提供するサービスの性質の理解に加え、責任共有モデルやインシデント対応時に証拠として保全可能な領域等についての理解が不可欠となります。十分な理解に基づき、事前に準備しなければ、迅速かつ的確なインシデントレスポンスの実現は困難となります。


責任共有モデル

クラウドサービスの利用者(以下、「CSC」)とクラウド基盤やサービスを提供するCSPの間には、利用者が全てを管理するオンプレとは異なる責任分担が生じます。

この責任範囲を明確化したものが責任共有モデルです。このモデルでは、一般的にCSPがクラウド基盤の保護を担当し、CSCがデータやアプリケーションの管理を行う仕組みとなっています。

ただし、責任共有モデルはCSPによって一律ではなく、利用するクラウドサービスの形態(IaaS、PaaS、SaaS)によって異なります。例えば、CSCがOSやミドルウェア等を自由にカスタマイズできるIaaS(Infrastructure as a Service)では、その自由度の高さ故にCSCの責任範囲が広い一方、CSPが用意したアプリケーション部分のみを自由にカスタマイズできるSaaS(Software as a Service)ではCSCの責任範囲は限定されます。以下、各サービス形態の特徴とインシデント対応時の調査範囲の概要となります。

図 2: CSC と CSP 責任共有リスクマトリックス5
出典:Cloud Security Alliance「Cloud-Incident-Response-Framework」, www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/06/Cloud-Incident-Response-Framework-4_30_21_J.pdf(2024年12月3日アクセス)

IaaS(Infrastructure as a Service)

IaaSは、仮想マシンやストレージ、ネットワークといった基盤的なリソースがCSCに提供されるモデルです。

CSPは物理インフラのセキュリティを担い、CSCは利用するOSやミドルウェア、アプリケーション、データなどのセキュリティを担います。このモデルでのインシデント対応では、OSやミドルウェア、アプリケーションレベルのログなどを収集し調査を行うことが一般的な対応となります。
 

PaaS(Platform as a Service)

PaaSは、アプリケーションの開発・テスト・デプロイを支援するプラットフォームが提供されるモデルです。CSPがオペレーティングシステムやミドルウェアのセキュリティを担い、CSCはアプリケーションとそのデータのセキュリティを担います。このモデルでのインシデント対応では、ミドルウェアやアプリケーションレベルのセキュリティイベントのログを調査することが一般的な対応となります。
 

SaaS(Software as a Service)

SaaSは、CSPが用意したアプリケーションがサービスとして提供されるモデルで、CSPがインフラからアプリケーションまでの大部分を管理します。CSCは主にユーザーアクセスの管理やアプリケーション上のデータの保護を管理します。このモデルでのインシデント対応では、認証・認可や設定変更等の活動、データの漏えいや整合性などを重点的に調査することが一般的な対応となります。

クラウド環境でのインシデントが発生した場合、該当のクラウド環境のモデルに基づき、責任範囲を正確に把握して対応する必要があります。責任範囲の誤認は対応の遅れや証拠保全の失敗などのリスクを生じさせることから、インシデント発生前の平時段階から、管理対象のクラウド環境における想定リスクを洗い出し、「どのような調査を行うのか」また「どのような情報を保全すべきなのか」を検討しておくことが重要です。また、クラウド環境におけるサイバー攻撃は既述のとおり高度化しているため、MITREのATT&CK® Cloud Matrix等の外部情報の収集や専門家の関与が推奨されます。 


インシデント領域

CSPごとに名称や定義に若干の違いはありますが、インシデントが発生した際に影響を受ける可能性のある領域は、一般的に以下の2つに分類できます。
 

管理プレーン(Control Plane)

クラウド環境全体の設定や制御を担う領域を指します。この領域への侵害は、API(Application Programming Interface)操作や管理者権限の不正使用により、仮想マシンの作成やセキュリティ対策の停止・無効化など、クラウド環境全体に影響を与える可能性があります。調査における観点としては、主に不審なAPIの操作ログやアカウント認証などの設定変更の有無などが挙げられます。
 

リソースプレーン(Data Plane)

クラウド上のリソース(仮想マシン、コンテナ、ストレージなど)に対する制御などを担う領域を指します。この領域における主な調査対象としては、仮想マシンのディスクイメージやアプリケーションログ、リソース操作のログなどが挙げられます。なお、仮想マシンに対する侵害が確認された場合でも、前述の管理プレーンへの影響を考慮した対応(APIログの分析など)を進め、より網羅的な調査を行うことが望まれます。

また、クラウド環境とオンプレが連携している場合、侵害の影響範囲は双方に波及する可能性があるほか、侵害原因を正確に特定するためにオンプレからクラウド環境、またはその逆も含めた横断的な調査が効果的です。


証拠保全

責任共有モデルやインシデント領域によって調査・解析の対象となるデータは異なりますが、特にログデータの分析が重要と言えます。クラウド環境のログデータは特定のサービスタイプに合わせて異なるレイヤーで記録され、主に下記4つのカテゴリに分類できます。

  • 管理・監査ログ:クラウド内の管理活動を記録
  • データログ:データの変更、エクスポートなどを記録
  • ネットワークトラフィックログ:ネットワーク通信の概要または詳細を記録
  • サービス固有のログ:特定のサービスに関する操作を記録

多くのクラウド環境において、初期設定から変更していない場合、調査に必要なログの保持期間やデータソースが限定的となり、問題の早期発見や原因究明が困難になるリスクが生じます。また、個人情報保護法やPCI DSS(Payment Card Industry Data Security Standard)、SOX(Sarbanes-Oxley)法、HIPAA(医療保険の携行性と責任に関する法)といった法規制への対応が不十分な場合、罰則や社会的信用を失うリスクも生じます。さらにクラウドサービスを顧客向けのサービスや製品用のプラットフォームとして利用している場合、十分な調査結果を得られないことはサービスや製品の契約上の要件を満たさない可能性が生じる点にも留意が必要です。このように保全や解析時の充足性などの技術的観点だけでなく、法規制の要件や推奨事項等を満たす上でも、適切な設定および管理体制を整えることが重要となります。

特に管理プレーンのログは、保持期間やダウンロード可能なログエントリー件数が制限されることがあり、インシデント対応前にそれら制限事項を理解し、適切な保管設定や方法を検討する必要があります。例えば、インシデント対応時の分析に必要な期間のログを確実に取得するに、日常的にログをSIEM(セキュリティ情報イベント管理)やストレージサービスにエクスポートし、一定期間保存する方法が挙げられます。この方法は十分なデータ保管と同時に、攻撃者による改ざんや証拠隠滅(アンチ・フォレンジック)の試みを阻止するための対策としても効果が期待できるため、推奨されます。

また、リソースプレーンに関する調査を行う場合、各種ログに加え、仮想ディスクイメージなどが調査対象となります。クラウドの特性上、システム構成(例: 自動スケーリングによるリソースの動的管理など)によっては、リソースを削除した段階で調査に有用な痕跡が消失する可能性がある点にも注意を払う必要があり、これらを踏まえた証拠保全の手法の整備が必要不可欠となります。


最後に

クラウド環境で円滑にインシデント対応を行うためには、利用中のサービスで取得可能なログの種類や保存期間を理解し、発生し得るインシデントに対して計画的に対応の準備を進めることが必要です。

この準備にあたっては、CSA(Cloud Security Alliance®)が公開している「クラウドインシデントレスポンス(CIR)フレームワーク」が、より効果的な対応計画の策定に有用と考えます。

また、CIS(Center for Internet Security®)が公開している「CIS Benchmarks™」は各種ITプラットフォーム(OS、クラウドサービス、アプリケーション、ネットワークデバイスなど)の設定基準を明確にしたドキュメントで、システム設定におけるセキュリティ強化や規制順守のために広く活用されています。

これらのガイドラインの活用に加え、経験豊富な専門家のサポートを得ることが成功への鍵となります。

対応が困難な場合や不安がある場合には、専門家へご相談されることをご検討ください。



【共同執筆者】

柳 裕二、清水 裕子、茂木 和馬
EY Japan Forensic & Integrity Services


サマリー 

クラウド環境におけるインシデントレスポンスで重要となる責任共有モデルおよびインシデント領域など、クラウド特有の性質や留意点について解説します。


この記事について

You are visiting EY jp (ja)
jp ja