翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

サイバーフォレンジック

AWS SRA文脈では、米国国立標準技術研究所 (NIST) が提供するフォレンジックの次の定義を使用します。「情報の整合性を保持し、データの厳密な保管チェーンを維持しながら、データの識別、収集、検査、分析に科学を適用する」（出典: NIST Special Publication 800-86 – Guide to Integrating Forensic Techniques into Incident Response）。

セキュリティインシデント対応におけるフォレンジック

このセクションのインシデントレスポンス (IR) ガイダンスは、フォレンジックと、さまざまなサービスやソリューションが IR プロセスをどのように改善できるかを念頭に置いてのみ提供されています。

AWS Security Incident Response Guide には、Word Customer Incident Response Team (Word Word) の経験に基づいて、AWS Cloud のセキュリティインシデントに対応するためのベストプラクティスが記載されています。 AWS AWS CIRTAWS CIRT のその他のガイダンスについては、AWS CIRT ワークショップと AWS CIRT の教訓を参照してください。

米国国立標準技術研究所サイバーセキュリティフレームワーク (NISTCSF） は、IR ライフサイクルにおける準備、検出と分析、封じ込め、根絶、復旧、インシデント後のアクティビティの 4 つのステップを定義します。これらのステップは順次実施できます。ただし、サイクルの次のステップに進んだ後に一部のステップを繰り返す必要があるため、そのシーケンスは周期的であることが多いです。例えば、封じ込めて根絶した後は、再び分析して、敵を環境から排除できたことを確認する必要があります。

分析、封じ込め、根絶、分析に戻るというこの繰り返しのサイクルにより、新しい侵害指標 (IoCs) が検出されるたびにより多くの情報を収集できます。Those IoCs は、さまざまな観点から役立ちます。攻撃者が環境を危険にさらすために取った措置のストーリーを伝えてくれます。また、適切なインシデント発生後のレビューを実施することで、防御と検出を強化して、将来的にインシデントを防止したり、敵の行動をより早く検出したりして、インシデントの影響を軽減することができます。

この IR プロセスはフォレンジックの主な目的ではありませんが、ツール、手法、ベストプラクティスの多くは IR と共有されています (特に分析ステップ)。例えば、インシデントが検出されると、フォレンジック収集プロセスでは証拠を収集します。次に、証拠の調査と分析が extract IoCs に役立ちます。最終的には、フォレンジックレポートが IR 後の活動に役立ちます。

対応を迅速化し、IR 関係者の負担を軽減するために、フォレンジックプロセスを可能な限り自動化することをお勧めします。さらに、フォレンジック収集プロセスが終了し、汚染を防ぐために証拠が安全に保管されたら、さらに自動分析を追加することもできます。詳細については、AWS 規範ガイダンスウェブサイトの「インシデント対応とフォレンジックを自動化する」パターンを参照してください。

フォレンジックアカウント

次の図は、専用のフォレンジックアカウントで設定できる AWS セキュリティサービスを示しています。この図は、フォレンジックアカウントで検出または通知を提供するために使用される Word サービスを示す Security Tooling アカウントを示しています。 AWS

フォレンジックアカウントは、セキュリティ OU 内の独立した専用の Security Tooling アカウントです。フォレンジックアカウントの目的は、組織のフォレンジックチームがフォレンジックプロセスのすべてのフェーズ (収集、検査、分析、報告) を実施できるように、標準的で事前設定された繰り返し可能なクリーンルームを提供することです。さらに、対象とするリソースの隔離と隔離のプロセスもこのアカウントに含まれています。

フォレンジックプロセス全体を別のアカウントにまとめることで、収集、保存されたフォレンジックデータに追加のアクセス制御を適用できます。以下の理由により、フォレンジックアカウントと Security Tooling アカウントを分けることをお勧めします。

フォレンジックアカウントには、フォレンジック収集プロセスにおける人的介入を最小限に抑えながら、大規模な証拠収集を促進するための自動化機能を含める必要があります。追跡と報告のメカニズムを簡素化するために、リソースの対応と隔離の自動化もこのアカウントに含まれます。

このセクションで説明するフォレンジック機能は、組織がその機能をアクティブに使用していない場合でも、使用可能なすべての AWS リージョンにデプロイする必要があります。特定の AWS リージョンを使用する予定がない場合は、サービスコントロールポリシー (SCP) を適用して AWS リソースのプロビジョニングを制限する必要があります。さらに、フォレンジックアーティファクトの調査と保管を同じリージョン内で行うことで、データレジデンシーや所有権に関する規制環境の変化に伴う問題を回避できます。

このガイダンスでは、前述のようにログアーカイブアカウントを使用して、フォレンジックアカウントで実行したAPIsを含む、AWS APIs を使用して環境で実行されたアクションを記録します。このようなログがあると、アーティファクトの取り扱いミスや改ざんの申し立てを防ぐのに役立ちます。有効にする詳細のレベルに応じて ( CloudTrail AWS ドキュメントの「管理イベントのログ記録」と「データイベントのログ記録」を参照）、ログには、アーティファクトの収集に使用されたアカウント、アーティファクトが収集された時刻、およびデータ収集のために実行されたステップに関する情報を含めることができます。アーティファクトを Amazon S3 に保存することで、高度なアクセスコントロールを使用したり、オブジェクトにアクセスしたユーザーに関する情報を記録したりすることもできます。アクションの詳細なログがあれば、他のユーザーは必要に応じて後でプロセスを繰り返すことができます (対象のリソースがまだ使用可能であることを前提としています)。

Amazon GuardDuty

Amazon GuardDuty は、AWS アカウントとワークロードを保護するために、悪意のあるアクティビティや不正な動作を継続的にモニタリングする検出サービスです。一般的なAWSSRAガイダンスについては、「 Security Tooling アカウント」セクションの「Amazon GuardDuty」を参照してください。

GuardDuty の検出結果を使用して、侵害された可能性のある EC2 インスタンスのディスクイメージとメモリイメージをキャプチャするフォレンジックワークフローを開始できます。これにより、人間とのやり取りが減り、フォレンジックデータ収集の速度が大幅に向上します。 GuardDuty を Amazon EventBridge と統合して、new GuardDuty の検出結果への応答を自動化できます。

GuardDuty 検出結果タイプのリストが増加しています。フォレンジックワークフローを開始する検出結果タイプ (Amazon EC2、Amazon EKS、マルウェア保護など) を検討する必要があります。

封じ込めおよびフォレンジックデータ収集プロセスと GuardDuty 検出結果の統合を完全に自動化して、ディスクおよびメモリアーティファクトの調査をキャプチャし、EC2 インスタンスを隔離できます。例えば、すべての受信ルールと送信ルールがセキュリティグループから削除された場合、ネットワーク ACL を適用して既存の接続を中断し、IAM ポリシーをアタッチしてすべてのリクエストを拒否できます。

AWS Security Hub

AWS Security Hub は、AWS のセキュリティ体制を包括的に把握し、セキュリティ業界標準とベストプラクティスに照らして環境をチェックするのに役立ちます。Security Hub は、AWS 統合サービス、サポートされているサードパーティー製品、および使用する可能性のあるその他のカスタムセキュリティ製品からセキュリティデータを収集します。セキュリティの傾向を継続的にモニタリング・分析し、特に優先度の高いセキュリティ問題を特定するのに役立ちます。一般的なAWSSRAガイダンスについては、「 Security Tooling アカウント」セクションのAWS Security Hub」を参照してください。

Security Hub は、セキュリティ体制のモニタリングに加えて、Amazon EventBridge との統合をサポートし、特定の検出結果の修復を自動化します。例えば、Word Lambda 関数または AWS AWS Step Functions ワークフローを実行してフォレンジックプロセスを実装するようにプログラムできるカスタムアクションを定義できます。

Security Hub のカスタムアクションは、権限のあるセキュリティアナリストやリソースが封じ込めとフォレンジックの自動化を実装するための標準化されたメカニズムを提供します。これにより、フォレンジック証拠の封じ込めとキャプチャにおける人的介入が減ります。自動プロセスに手動チェックポイントを追加して、フォレンジックコレクションが実際に必要かどうかを確認できます。

Amazon EventBridge

Amazon EventBridge は、アプリケーションをさまざまなソースのデータに簡単に接続できるようにするサーバーレスイベントバスサービスです。セキュリティオートメーションによく使用されます。一般的なAWSSRAガイダンスについては、「 Security Tooling アカウント」セクションの「Amazon EventBridge」を参照してください。

例えば、 EventBridge を Step Functions でフォレンジックワークフローを開始するメカニズムとして使用して、 GuardDuty などのセキュリティモニタリングツールの検出に基づいてディスクとメモリのイメージをキャプチャできます。または、より手動で使用することもできます。 EventBridge はタグ変更イベントを CloudTrail で検出し、Step Functions でフォレンジックワークフローを開始できます。

AWS Step Functions

AWS Step Functions は、AWS Lambda 関数やその他の AWS サービスと統合してビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。Step Functions のグラフィカルコンソールでは、アプリケーションのワークフローを一連のイベント駆動型ステップとして確認できます。Step Functions はステートマシンとタスクに基づいています。Step Functions では、ワークフローをステートマシンと呼びます。ステートマシンは、一連のイベント駆動型ステップです。ワークフローの各ステップはステートと呼ばれます。タスク状態は、Lambda などの別の AWS サービスが実行する作業単位を表します。タスク状態は、任意の AWS サービスまたは API を呼び出すことができます。Step Functions の組み込みコントロールを使用して、ワークフロー内の各ステップの状態を調べて、アプリケーションが期待どおりに実行されていることを確認します。ユースケースによっては、Step Functions に Lambda などの AWS サービスを呼び出してタスクを実行させることができます。また、手動による介入が必要なアプリケーション用に実行時間が長い自動化されたワークフローを作成することもできます。

Step Functions は、AWS ログで検証できる、繰り返し可能で自動化された一連の定義済みステップをサポートしているため、フォレンジックプロセスでの使用に最適です。これにより、人間の関与を排除し、フォレンジックプロセスにおけるミスを防ぐことができます。

AWS Lambda

AWS Lambda を使用すると、サーバーのプロビジョニングや管理を行わずにコードを実行できます。支払いは、使用したコンピューティング時間に対する料金のみになります。コードが実行されていないときに料金は発生しません。Lambda は可用性の高いコンピューティングインフラストラクチャでコードを実行し、コンピューティングリソースに関するすべての管理を行います。これには、サーバーおよびオペレーティングシステムのメンテナンス、容量のプロビジョニングおよび自動スケーリング、さらにログ記録などが含まれます。Lambda がサポートするいずれかの言語ランタイムでコードを指定し、コードを Lambda 関数に整理します。Lambda サービスは、必要な場合にのみ関数を実行し、自動的にスケーリングします。

フォレンジック調査では、Lambda 関数を使用すると、Lambda コードで定義されている反復可能で自動化された定義済みのステップにより、一定の結果を得ることができます。Lambda 関数を実行すると、適切なプロセスが実装されたことを確認するのに役立つログが作成されます。

AWS KMS

AWS Key Management Service (AWS KMS) は、暗号化キーを作成および管理し、幅広い AWS サービスおよびアプリケーションでの使用を制御するのに役立ちます。一般的なAWSSRAガイダンスについては、「 Security Tooling アカウント」セクションのAWSKMS」を参照してください。

フォレンジックプロセスの一環として、ビジネスへの影響を最小限に抑えるため、データの収集と調査は隔離された環境で行う必要があります。このプロセスではデータのセキュリティと整合性が損なわれることはありません。そのため、侵害された可能性のあるアカウントとフォレンジックアカウント間で、スナップショットやディスクボリュームなどの暗号化されたリソースを共有できるようにするプロセスを導入する必要があります。これを実現するには、組織は、関連する AWS KMSポリシーが暗号化されたデータの読み取りをサポートし、フォレンジックアカウントの AWS KMSキーでデータを再暗号化してデータを保護することを確認する必要があります。