Amazon Web Services ブログ

AWS 上でフォレンジック調査環境を構築する際の方策

このブログは “Forensic investigation environment strategies in the AWS Cloud” を翻訳したものです。

セキュリティのベースラインから逸脱してしまった場合、迅速に対応して問題を解決し、フォレンジック調査と根本原因分析を行いフォローアップすることが極めて重要です。事前に設定されたインフラと、ベースラインからの逸脱があった場合にフォローアップするための実践的な計画があれば、インシデントの影響、範囲、根本原因を判断するために必要な情報を抽出・分析し、自信を持って運用を再開することが可能になります。

セキュリティ・インシデントの「何が」「どのように」「誰によって」「どこで」「いつ」発生したのかについては、期限厳守で把握する必要があります。自動化されたインシデント対応という言葉をよく耳にしますが、これは反復可能で監査可能なプロセスを持ち、インシデントの解決を標準化し、証拠のアーティファクトを早く収集するためのものです。

同様に、テンプレートによって自動的に展開される、標準的で、人手を介さず、事前に設定済みで、繰り返し使用できるクリーンなフォレンジック環境を持つことで、組織は人的接触を最小限に抑え、大きな組織を汚染から守り、証拠収集と根本原因の分析を迅速化し、フォレンジックデータの完全性を保護することができます。フォレンジック分析プロセスは、データの保全、取得、分析を支援し、インシデントの根本原因を特定します。また、このアプローチにより、外部の法人や監査人への証拠の提示や移転が容易になります。AWS CloudFormation テンプレート、またはその他の Infrastructure as Code（IaC）プロビジョニングツールは、これらの目標の達成を支援し、一貫性があり、構造化されており、監査可能な結果をビジネスに提供することにより、全体的なセキュリティへの姿勢を改善することを可能にします。これらの環境をインフラストラクチャの一部として常設することは、十分に裏付けされ、実証済みであることにつながります。そして、使用方法についてチームを訓練する機会も得られます。

このブログでは、セキュアなベースラインの逸脱に対応するために、組織で利用できる戦略を紹介します。これらの戦略は、次の各トピックスでベストプラクティスを採用しています。

  • Amazon Web Services (AWS)  のアカウント構造
  • AWS Organizations  の組織単位 (OU) とサービス制御ポリシー (SCP)
  • Amazon Virtual Private Cloud (Amazon VPC) とネットワークインフラのフォレンジック
  • 収集すべき証拠のアーティファクト
  • 使用すべき AWS サービス
  • フォレンジック分析ツールのインフラ
  • 上記に対するユーザーアクセスと承認

具体的には、フォレンジックツールをインストールしたAmazon Elastic Compute Cloud (Amazon EC2)  インスタンスを使用して、証拠のアーティファクトを調べることができる環境を提供することに重点を置いています。

また、このブログは、すでに証拠となるアーティファクトの収集手順がある、または、それを実施しており、ここで説明するアカウントに証拠のアーティファクトを転送できることを前提にしています。アーティファクト収集を自動化する方法についてアドバイスをお探しの場合は、How to automate disk collection in AWS を参照してください。

インフラストラクチャーの概要

Well-Architected に沿ったマルチアカウントの AWS 環境は、Organizations で提供される構造に基づいています。企業が成長し、複数の AWS リージョンで複数のアカウントを使用してインフラストラクチャを拡張する必要がある場合、Organizations は、中央管理およびガバナンスを組み合わせた新しい AWS アカウントを自動的に作成し、統制および標準化された方法で行うことを支援します。この自動処理される集中型アプローチは、このブログの戦略で説明されているフォレンジック調査環境を作成するために使用されるべきものです。

このブログの例では、図1 に示すように、セキュリティとフォレンジックに別々の専用 OU とアカウントを持つ単純化された構造を使用しています。あなたの組織のアーキテクチャは異なるかもしれませんが、戦略は同じです。

注意：侵害されているインスタンスやリソースへのシャットダウンやアクセスを避けるといった場合に、侵害されているアカウント内でフォレンジック分析を迅速に行うことがあるかもしれませんが、このようなアプローチは本記事では取り上げていません。

Figure 1: AWS Organizations forensics OU example

図1： AWS Organizations のフォレンジック OU の例

図1 における最も重要な構成要素は以下の通りです。

セキュリティ OU は、セキュリティ関連のアクセスやサービスをホストするために使用されます。セキュリティ OU と関連する AWS アカウントは、セキュリティ組織が所有し管理する必要があります。

フォレンジック OU は、セキュリティ OU といくつかの類似性があり、重複した責任をもつかもしれませんが、それは別のエンティティであるべきです。それぞれ別に OU とアカウントを持つことにはいくつか理由があります。重要な理由をいくつか挙げると、フォレンジックチームがセキュリティチーム（またはその中のグループ）とは別のチームであるかもしれないこと、特定の調査が法的拘束を受けアクセス制限が追加されるかもしれないこと、そしてセキュリティチームのメンバーが調査の対象になるかもしれないことです。

Organizations、アカウント、そして様々なアクションに必要なパーミッションについて考えるとき、まず Organizations の中核機能である SCP に注目する必要があります。SCP は、組織内のすべてのアカウントに対して、利用可能な最大限の権限を統制することができます。この記事の例では、SCP を使用して、リソースコンテナとして使用されているフォレンジック OU の下のすべてのアカウントに、類似または同一の許可ポリシーを提供することができます。このポリシーは、他のすべてのポリシーを上書きし、必要な API コールを明示的に拒否または許可できることを保証するための重要なメカニズムです。SCP のいくつかの使用例は、AWS CloudTrail の無効化を制限し、ルートユーザーのアクセスを制限し、フォレンジック調査アカウントで行われたすべてのアクションが記録されることを保証することです。これによって、ユーザー、グループ、またはロールの個々のポリシーが変更されないように一元的に管理できます。

フォレンジック環境へのアクセスは、収集された証拠を変更または侵害することができる人は誰もいないという、最小権限の法則に即しているべきです。調査環境では、例外としてリスト化したアクションを除き、すべてのアクションを拒否することが最も簡単なアプローチです。デフォルトの「すべて拒否」から始めて、組織で確立されたフォレンジックプロセスを実行するために必要な最小限の権限に向かって作業を進めましょう。AWS Config  は、アカウントに加えられた変更を追跡し、これらの変更の証拠を提供するための貴重なツールになりえます。

制限付き SCP が適用されると、root アカウントや管理者アクセス権を持つものでさえ、その権限以上のアクセスはできないことに留意してください。したがって、環境の変化に応じて頻繁にプロアクティブなテストを行うことがベストプラクティスとなります。また、もし必要ならば、アカウントを外部のエンティティに移管するために、どのプリンシパルが保護ポリシーを削除できるかを必ず検証してください。最後に、制限的なパーミッションが適用される前に環境を作成し、フォレンジック OU の下にアカウントを移動させください。

フォレンジック調査専用の AWS アカウントを持つことは、大規模な組織をインシデント自体からの汚染の脅威から分離し、分析されるアーティファクトを独立させ完全性の保護を確実にし、調査の機密性を維持するために最適です。攻撃者が、侵害された AWS アカウントで利用できる全てのリソースを使用するとサービスクォータの上限に到達し、調査を行う Amazon EC2  さえも起動できなくなりますが、別々のアカウントにすることでこの状況も回避できます。

リージョンごとにフォレンジック調査アカウントを持つことは、調査能力を分析されるデータの近くに維持し、レイテンシーを低減し、データを移転させなければ各国のデータ保護規制の問題を回避できるため、良い実践でもあります。例えば、EU にあるデータを北米の調査チームが調査する必要があっても、北米のアーキテクチャが GDPR に適合していないため、データ自体を移動させることはできません。グローバルなお客様の場合、フォレンジックチームは世界中の異なる場所に置かれ、異なるプロセスを持っている場合があります。インシデントが発生したリージョンにフォレンジックアカウントを持つ方がよいでしょう。また、必要に応じて、アカウント全体を現地の法的機関や第三者監査人に提供することができます。とはいえ、AWS のインフラストラクチャは複数リージョンで構成されているが、1つの管轄区域や国だけの場合、1 つのリージョンに再作成可能な単一のアカウントを持ち、証拠のアーティファクトをそれぞれのリージョンから共有し保管すれば、長期的に管理しやすいアーキテクチャになります。

CloudFormation テンプレートまたは他の IaC メソッドを使用して自動化された方法で作成されたアカウントは、個別の調査ごとに全く新しい、人的オペレーションなしにフォレンジック分析インスタンスを再作成し、その整合性を確保することで、使用前の人的作業を最小限にすることができます。個人のアクセス権はセキュリティインシデント対応計画の一部分としてのみ与えられ、その場合でも環境を変更する権限は最小限か全くないものとします。調査後の環境は、ロックされた状態で保存されるか、削除され、次の調査のために、以前の成果物の痕跡を残さない新鮮で何も残っていない環境が作成されます。環境をテンプレート化することで、調査戦略、権限、ツールが意図したとおりに機能することを確認するためのテストも容易になります。

フォレンジック・インフラストラクチャへのアクセス

調査環境の設置場所が決まったら、誰がどのようにアクセスし、どのようなパーミッションが必要かを考える必要があります。フォレンジック調査チームは、セキュリティインシデント対応チームとは別のチーム、同じチーム、またはその一部にすることができます。最小権限を維持する一環として、調査を行う個人のグループに正確なアクセス権を提供する必要があります。

フォレンジック手順の様々なニーズに応じて、それぞれ必要な権限のみを持つ特定のロールを作成する必要があります。SCP やここで説明した他の状況と同様に、権限なしで開始し、テンプレート化された環境を確立してテストしながら、必要な権限のみを追加してください。例として、フォレンジックアカウント内に以下のロールを作成することができます。

対応者 – 証拠を取得する

調査員 – 証拠の分析を行う

データ管理者 – 証拠を管理する（コピー、移動、削除、有効期限）

アナリスト – 分析、トレンド、予測のためにフォレンジックレポートにアクセスする（脅威のインテリジェンス）

役割ごとにアクセス手順を定め、対応策の手順書に記載しておくことをおすすめします。これにより、最小権限のアクセスと環境の完全性を確保することができます。例えば、セキュリティインシデント対応計画のオーナーが、環境へのアクセス要求を確認し、承認するプロセスを確立します。また、Two-person rule という方法もあります。ログイン時のアラートは、環境の完全性への信頼を高め、不正なアクセスを監視するために追加できるセキュリティ対策です。

調査役は、一般的に Amazon Elastic Block Store (Amazon EBS)  のスナップショット、メモリダンプ、ログ、または Amazon Simple Storage Service (Amazon S3)  バケットなどの、収集したオリジナルのアーティファクトへの読み取り専用アクセスを持つことが望まれます。証拠のオリジナルソースは保護されるべきです。MFA 削除と S3 バージョニングは、そうするための 2 つの方法です。オリジナルを不変にしておくことが不可能な場合、特にアーティファクトに何らかの変更が生じる場合は、コピーのコピーに対して作業を行う必要があります。これについては、以下でさらに詳しく説明します。

証拠は、アクセスを絶対に必要とする役割、すなわち調査員とデータ管理者のみがアクセスできるようにすべきです。潜在的な内部脅威者が調査を知ることを防ぐために、証拠にアクセスし分析する役割以外からの読み取りアクセスも拒否する必要があります。

フォレンジック・インフラストラクチャの完全性の保護

組織、アカウント構造、役割を構築したら、アカウント自体の内部で最適な戦略を決定する必要があります。収集したアーティファクトの分析は、EC2 インスタンス上でホストされるフォレンジック分析ツールで行うことができ、理想的にはフォレンジックアカウントの専用 Amazon VPC 内に配置するとよいです。この Amazon VPC は、これまでと同じ制限的なアプローチで構成する必要があり、完全に分離して監査可能で、唯一のリソースは手元のフォレンジックタスク専用にする必要があります。

これは、Amazon VPC のサブネットにはインターネットゲートウェイがなく、したがって、すべての S3 アクセスは、S3 VPC エンドポイントを介して行われなければならない可能性を示唆しています。VPC フローログは、すべてのネットワークトラフィックの記録を行うために、Amazon VPC レベルで有効にする必要があります。セキュリティグループは、厳格に制限する必要があり、フォレンジックツールの要件に関連しないすべてのポートを拒否する必要があります。SSH と RDP のアクセスは、すべての接続とアクティビティを記録するように構成された踏み台ホスト、AWS Systems Manager Session Manager など、監査可能なメカニズムによって制限および管理されるべきです。

グラフィカルなインターフェイスを持つ Systems Manager Session Manager の使用が必要な場合でも、RDP またはその他の方法でアクセスすることができます。Session Manager を使用して実行されたコマンドと応答は、Amazon CloudWatch とS3 バケットにログを記録することができます。これにより、フォレンジックツールの Amazon EC2 インスタンスで実行されたすべてのコマンドの監査が可能になります。また、必要に応じて管理者権限を制限することも可能です。また、新しいセッションが開始されたときにAmazon Simple Notification Service (Amazon SNS) 通知を受け取るように設定することも可能です。

フォレンジック専用の Amazon EC2 インスタンスがインターネットに直接アクセスできないかもしれないことを考えると、分析用に適切にインストールされ更新されたツールのセットで標準化された Amazon Machine Images (AMI)  を事前に構成し展開するプロセスを作成する必要があるかもしれません。このプロセスには、いくつかのベストプラクティスが適用されます。AMI の OS は、脆弱な領域を減らすためにハードニングされている必要があります。これは、AWS が提供する AMI や、自分で作成し管理したものなど、承認された OS イメージから始めることで実現します。

次に、不要なプログラム、パッケージ、ライブラリ、およびその他のコンポーネントを削除します。セキュリティパッチを含むすべてのアップデートとパッチが適用されていることを確認します。ホストベースのファイアウォールや侵入検知ツールを設定するのもよい予防策です。さらに、接続されたディスクが常に暗号化されていることを確認します。

OS がサポートされている場合は、EC2 Image Builder を使用してゴールデンイメージを作成することをおすすめします。ゴールデンイメージは、セキュリティパッチや機能を最新の状態に保つために、少なくとも毎月リビルドして更新する必要があります。EC2 Image Builder と他のツールを組み合わせることで、例えば、CIS（Center for Internet Security）ベンチマークで強化された AMI を生成する自動パイプラインの作成が可能になり、ハードニングプロセスを容易にすることができます。独自のハードニングイメージを維持したくない場合は、AWS Marketplace で CIS ベンチマーク AMI を見つけることができます。

フォレンジックツールのインフラ要件（最小限の CPU、メモリ、ストレージ、ネットワーク要件など）を念頭に置き、適切な EC2 インスタンスタイプを選択することも必要になってきます。さまざまなタイプのインスタンスがありますが、最小要件と予想されるワークロードに基づいて、コストとパフォーマンスの適切なバランスを維持できるか確認する必要があります。

この環境構築の目標は、証拠を収集し、包括的な調査を行い、安全なオペレーションに効果的に戻すための手段を提供することです。証拠収集は、ブログ記事 How to automate incident response in the AWS Cloud for EC2 instances で説明する自動化戦略によって行うのが最適です。証拠収集プロセスでは、証拠を取得したら直ちにハッシュ化することが強く推奨されます。ハッシュ、ひいては証拠そのものは、その後の転送やアクセス後に検証することができ、証拠の完全性が維持されることが保証されます。法的措置が取られた場合、オリジナルの証拠を保存することは非常に重要です。
証拠とアーティファクトには、以下のものが挙げられますが、これらに限定されるわけではありません。

  • すべての EC2 インスタンスのメタデータ
  • Amazon EBS のディスクスナップショット
  • S3 へストリームされた EBS ディスク
  • メモリダンプ
  • ルート EBS ボリュームのハイバネーションによりキャプチャされたメモリ
  • CloudTrail ログ
  • AWS Config ルールの検出結果
  • Amazon Route 53 のDNS リゾルバ  のクエリログ
  • VPC フローログ 
  • AWS Security Hub の検知結果
  • Elastic Load Balancing  アクセスログ
  • AWS WAF  のログ
  • カスタムアプリケーションのログ
  • システムログ
  • セキュリティログ
  • サードパーティーのログ

CloudTrail ログのような上記のコントロールプレーンログへのアクセスは、以下の2つの方法のうちのいずれかで行うことができます。理想的には、ログは中央の場所に存在し、必要に応じて調査するために読み取り専用でアクセスできるようにすることです。しかし、一元化されていない場合、必要に応じてソースアカウント内のオリジナルログに読み取りアクセスを与えることができます。AWS Config、Amazon GuardDuty 、Security Hub、Amazon Detective など、セキュリティアカウント内で見つかった特定のサービスログへの読み取りアクセスは、分析中に発見した証拠と侵害の指標を関連付けるために必要になる場合があります。
前述したように、すべての証拠の変更不可なバージョンを持つことが不可欠です。これは、以下の例に限らず、様々な方法で達成することができます。

  • Amazon EBS スナップショット (ハイバネーションで生成されたメモリダンプを含む)
    • オリジナルの Amazon EBS ディスクをスナップショットし、フォレンジックアカウントに共有し、ボリュームを作成するために使用し、オフライン分析のために読み取り専用としてマウントします。
  • 手動でキャプチャした Amazon EBS ボリューム
    • dc3dd などの Linux ツールにより、S3 バケットにボリュームをストリームし、ハッシュを提供し、次の箇条書きから S3 のメソッドを使用して 改変不可にすることが可能です。
  • S3 バケットに保存されたメモリダンプなどのアーティファクト
    • S3 Object Lock  は、一定時間または無期限でオブジェクトの削除や上書きを防ぐことができます。
    • MFA delete  を有効にすると、オブジェクトを永久に削除するために、要求者が多要素認証を使用することを要求します。
    • Amazon S3 Glacier  は、不変の証拠を長期的に保持したい場合、Vault Lock 機能を提供します。
  • ディスクボリューム
    • Linuxの場合：リードオンリーモードでマウントします。
    • Windowsの場合： 商用またはオープンソースの書き込みブロックアプリケーションのいずれかを使用します。
  • CloudTrail：
  • AWS Systems Manager のインベントリ
  • AWS Config データ
    • デフォルトでは、AWS Config のデータは S3 バケットに格納され、上記の方法で保護することができます。

注：KMS のような AWS サービスは、暗号化を有効にするのに役立ちます。KMS は AWS サービスと統合されており、AWS ワークロード全体でデータを暗号化するための鍵の運用を簡素化します。

Amazon EBS ディスクをフォレンジックアカウントに証拠として共有する使用例として、次の図2 は、証拠を保存して作業するために使用する簡略化された S3 バケットのバケットとフォルダの構造です。

図2 は、フォレンジックアカウントの S3 バケット構造を示しています。S3 バケットとフォルダは、受信データ（例えば、Amazon EBS ディスクから）を保持するために作成され、それは dc3dd を使用して Incoming Data > Evidence Artifacts にストリーミングで保存されます。次に、データはそこから別のバケット（ Active Investigation > Root Directory > Extracted Artifacts ）内のフォルダにコピーされ、フォレンジックAmazon EC2 インスタンスにインストールされたツールで分析されます。また、Active Investigation の下には、分析中に作成した調査メモのフォルダ (Investigation Notes) や、このブログ記事の最後で説明する最終報告書用のフォルダ (Investigation Report) があります。最後に、リーガルホールド用のバケットとフォルダです。ここには、特定のバージョンで証拠の成果物を保持するためのオブジェクトロックが配置されます。

Figure 2: Forensic account S3 bucket structure

図2： フォレンジックアカウントの S3 バケット構造

検討事項

最後に、インシデントの深刻度によっては、オンプレミスのネットワークやインフラも危険にさらされる可能性があります。このような事態に備え、セキュリティ対応者が使用できる代替環境を用意しておけば、緊急時に対応できないといったリスクを低くすることができます。Amazon Workspaces  などのサービスは、完全に管理された持続的なデスクトップ仮想化サービスであり、対応者がデジタルフォレンジックやインスデント対応ツールにアクセスしてタスクを実行できる、すぐに使える独立した環境を提供します。

調査ツールとは別に、コミュニケーションサービスは対応の調整にとって最も重要なものの一つです。Amazon WorkMail  と Amazon Chime を使用すれば、通常のチャネルとは別にその機能を提供することができます。

まとめ

フォレンジック調査のゴールは、証拠に裏付けられた最終報告書を提出することです。これには、何がアクセスされたか、誰がアクセスしたか、どのようにアクセスしたか、データが流出したかどうか、などが含まれます。このレポートは、刑事や民事の調査、または侵害の通知を必要とする状況など、法的な状況において必要となる場合があります。それぞれの状況に応じた適切な対応と報告プロセスを構築するために、どのようなアウトプットが必要かを事前に決定しておく必要があります。根本原因の分析は、将来同様のインシデントが発生しないよう、リソースと環境を整えるために必要な情報を提供する上で不可欠です。報告書には、根本原因分析だけでなく、結論を導き出すための方法、手順、ツールも記載する必要があります。

この記事では、フォレンジック環境の作成と保守を開始し、チームが AWS のサービスを使用して高度なインシデント解決調査を実行できるようにする方法を紹介しました。上記のようにフォレンジック環境の基盤を実装することで、自動化されたディスク収集を使用してフォレンジックデータ収集機能の反復処理を開始し、セキュリティイベント発生に備えることができます。

この記事に関するご意見・ご感想は、以下のコメント欄からお寄せください。このブログについて質問がある場合は、AWS Security, Identity, and Compliance フォーラム  のいずれかに新しいスレッドを立ち上げるか、AWS Support  に連絡してください。

AWS Security のハウツー、ニュース、機能アナウンスメントをもっと知りたい場合は、Twitter にてフォローしてください。

翻訳はソリューションアーキテクトの佐藤 航大が担当しました。原文はこちらです。