# インシデント対応
<a name="a-incident-response"></a>

**Topics**
+ [SEC 10 インシデントの予測、対応、復旧はどのように行いますか?](w2aac19b7c15b5.md)

# SEC 10 インシデントの予測、対応、復旧はどのように行いますか?
<a name="w2aac19b7c15b5"></a>

組織に支障をきたすことを最小限に抑えるために、セキュリティインシデントのタイムリーで効果的な調査、対応、復旧に備えることが重要です。

**Topics**
+ [SEC10-BP01 重要な人員と外部リソースを特定する:](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 インシデント管理計画を作成する](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 フォレンジック機能を備える:](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 封じ込め機能を自動化する](sec_incident_response_auto_contain.md)
+ [SEC10-BP05 アクセスを事前プロビジョニングする](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 ツールを事前デプロイする](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 ゲームデーを実施する](sec_incident_response_run_game_days.md)

# SEC10-BP01 重要な人員と外部リソースを特定する:
<a name="sec_incident_response_identify_personnel"></a>

 組織がインシデントに対応するのに役立てるため、社内外の担当者、リソース、法的義務を特定します。 

クラウド上でのインシデントレスポンスへのアプローチを他のチーム (顧問弁護士、経営陣、ビジネスステークホルダー、AWS サポートサービスなど) と連携して定義する場合、重要な人物、ステークホルダー、関連する担当者を特定する必要があります。依存性を減らし、応答時間を短縮するために、チームや専門のセキュリティチーム、応答者が利用するサービスについて教育を受け、実践的な演習をする機会を持つようにしてください。

対応能力を強化するために、外部の専門知識および異なる視点を備えた社外の AWS セキュリティパートナーを探しておくことをお勧めします。信頼できるセキュリティパートナーは、馴染みのない潜在的なリスクや脅威を特定するのに役立ちます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  組織内の主要な人員を特定する: インシデント対応と復旧に必要な組織内の人員の連絡先リストを保持します。 
+  外部パートナーを特定する: 必要に応じて、インシデント対応と復旧を支援できる外部パートナーと連携します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS インシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **関連動画:** 
+  [AWS 環境のセキュリティインシデントの準備と対応 ](https://youtu.be/8uiO0Z5meCs)

 **関連する例:** 

# SEC10-BP02 インシデント管理計画を作成する
<a name="sec_incident_response_develop_management_plans"></a>

 インシデントへの応答、インシデント時の伝達、インシデントからの復旧に役立つ計画を作成します。たとえば、ワークロードと組織にとって起こる可能性が最も高いシナリオで、インシデント応答計画を作成してみましょう。内部および外部に伝達およびエスカレーションする方法を含めます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 インシデント管理計画は、セキュリティインシデントの潜在的な影響への対応、復旧、軽減に不可欠です。インシデント管理計画は、セキュリティインシデントをタイムリーに特定し、修復、対応するための体系的なプロセスです。

 クラウドには、オンプレミス環境と同じオペレーション上のロールと要件があります。インシデント管理計画を作成する際は、ビジネス成果とコンプライアンス要件と最も合致する対応および復旧戦略を組み込むことが重要です。例えば、米国の FedRAMP 準拠のワークロードを AWS で運用している場合は、 [『NIST SP 800-61 Computer Security Handling Guide』を遵守することが役に立ちます](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf)。同様に、ヨーロッパの PII (個人を特定できる情報) データを含むワークロードを運用しているときは、 [EU 一般データ保護規則 (GDPR) で義務付けられているようにデータレジデンシー関連の問題に対してどのように防御、対応するかといったシナリオを考慮します](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en)。

 AWS で運用するワークロードについてインシデント管理計画を策定する際は、 [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)から始め、インシデント対応に向けた多層防御アプローチを構築することを目指します。このモデルでは、AWS はクラウドのセキュリティを管理します。クラウド内のセキュリティについてはお客様の責任です。つまり、お客様はコントロールを保持するとともに、実装しようとするセキュリティコントロールに責任を持つということです。『 [AWS Security Incident Response Guide』(AWS セキュリティインシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) には、クラウド中心のインシデント管理計画を策定するための重要なコンセプトと基本的なガイダンスが記載されています。

 効果的なインシデント管理計画は、クラウド運用の目標に沿って継続的に繰り返し、最新の状態に保つ必要があります。インシデント管理計画を作成して進化させるにあたり、以下に記載の実装計画を使用することを検討してください。 
+  **インシデント対応の教育とトレーニング: ** 定義されたベースラインからの逸脱 (間違ったデプロイ、設定ミスなど) が発生した場合は、対応と調査が必要になる可能性があります。これを適切に行うために、自社の AWS 環境内でセキュリティインシデント対応に使用できるコントロールと機能を理解するとともに、インシデント対応に関与するクラウドチームの準備を整え、教育とトレーニングを行うプロセスを把握する必要があります。 
  +  [プレイブック](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) および [ランブック](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) は、インシデントへの対応方法のトレーニングで一貫性を確保するのに効果的なメカニズムです。まず、インシデント対応中に頻繁に実行する手順の最初のリストを作成し、継続的に繰り返しながら新しい手順の学習や採用を行います。
  +  スケジュールされた [ゲームデーをとおして、プレイブックとランブックを広めます](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)。ゲームデーの期間中、制御された環境でインシデント対応をシミュレーションします。それにより、チームは対応方法を思い出し、インシデント対応に関与する各チームがワークフローを熟知していることを検証できます。シミュレーションされたイベントの結果をレビューし、改善点を特定し、さらにトレーニングや追加ツールが必要か判断します。
  +  セキュリティは全員の任務と見なす必要があります。普段、ワークロードを運用するすべてのスタッフを関与させることで、インシデント管理プロセスの集合知を構築します。これにはビジネスのすべての側面、つまり、運用、テスト、開発、セキュリティ、ビジネスオペレーション、ビジネスリーダーが含まれます。 
+  **インシデント管理計画をドキュメント化する: ** アクティブなインシデントの記録、対応、進捗に関するコミュニケーション、通知の提供のためのツールとプロセスをドキュメント化します。インシデント管理計画の目標は、通常のオペレーションができるだけ迅速に復旧され、ビジネスへの影響が最小限に抑えられ、すべての関係者に情報が提供されることを検証することです。インシデントの例としては、ネットワーク接続の損失やパフォーマンス低下、応答しないプロセスまたは API、スケジュール済みだが実行されないタスク (パッチ適用の失敗など)、アプリケーションデータまたはサービスの利用不可、セキュリティイベントに起因する計画外のサービス中断、認証情報の漏洩、設定ミスによるエラーがあります (ただし、これらに限定されません)。 
  +  インシデント解決に責任を持つ主な所有者 (ワークロード所有者など) を特定します。誰がインシデントを管理するか、またどのようにコミュニケーションを取るかについて、明確なガイダンスを用意します。外部ベンダーなど複数の当事者をインシデント解決プロセスに関与させる場合は、インシデント解決で求められる、さまざまなチームやスタッフの役割と責任を記述した *責任分担 (RACI) マトリックス*を作成することを検討します。

     RACI マトリックスには以下を記述します。 
    +  **R: ** *Responsible * - 作業を行いタスクを完了する実行責任者。
    +  **A: ** *Accountable * - 指定されたタスクの正常な完了に対して最終的な権限を持つ説明責任者またはステークホルダー。
    +  **C: ** *Consulted * - 意見を求められる相談先。一般的には対象分野の専門家。
    +  **I: ** *Informed * - 進捗について通知を受ける情報提供先。多くの場合、タスクの完了や成果物についてのみ通知される。
+  **インシデントを分類する: ** インシデントを定義し、重大度と影響度のスコアに基づき分類することで、インシデントをトリアージして解決するための体系的なアプローチが可能となります。次の推奨事項は、インシデントを数値化するための *影響と解決の緊急マトリックス* を説明するものです。例えば、影響度: 低、緊急度: 低のインシデントは、重大度: 低のインシデントと見なされます。 
  +  **高 (H): ** ビジネスは多大な影響を受けます。AWS リソースに関連するアプリケーションのクリティカルな機能は使用できません。本番システムに影響を及ぼすほとんどのクリティカルイベントのために用意されています。インシデントの影響は急速に拡大し、修復には時間的制約があります。 
  +  **中 (M): ** AWS リソースに関連するビジネスサービスまたはアプリケーションは、適度に影響を受けますが、パフォーマンスが低下した状態で機能します。サービスレベル目標 (SLO) に寄与するアプリケーションは、サービスレベルアグリーメント (SLA) の範囲内で影響を受けます。システムは、能力が低下した状態で機能することができ、財務的影響および評判上の影響はあまりありません。 
  +  **低 (L): ** AWS リソースに関連するビジネスサービスまたはアプリケーションの非クリティカルな機能が影響を受けます。システムは、能力が低下した状態で機能することができ、財務的影響および評判上の影響は最小限にとどまります。 
+  **セキュリティコントロールを標準化する: ** セキュリティコントロールを標準化する目的は、オペレーションの結果に関する一貫性、トレーサビリティ、再現性を実現することです。インシデント対応に欠かせない重要なアクティビティについて標準化を推進します。以下に例を挙げます。 
  +  **アイデンティティとアクセスの管理: ** データへのアクセスを制御し、人間とマシンアイデンティティの両方の権限を管理するためのメカニズムを確立します。シングルサインオンとロールベースの権限を含むフェデレーテッドセキュリティを使用して、貴社独自のアイデンティティとアクセスの管理をクラウドに拡張し、アクセス管理を最適化します。アクセス管理を標準化するためのベストプラクティスの推奨事項と改善計画については、 [セキュリティの柱に関するホワイトペーパーの「ID とアクセス管理」のセクション](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) を参照してください
  +  **脆弱性管理: ** AWS 環境で、攻撃者がシステムを侵害、悪用するために用いる可能性のある脆弱性を特定するためのメカニズムを確立します。予防的コントロールと発見的コントロールの両方をセキュリティメカニズムとして実装し、セキュリティインシデントの潜在的な影響に対応し、その影響を緩和します。脅威のモデル化などのプロセスを、インフラストラクチャ構築およびアプリケーションデリバリーライフサイクルの一環として標準化します。
  +  **構成管理: ** 標準構成を定義し、AWS クラウド にリソースをデプロイする手順を自動化します。インフラストラクチャとリソースの両方のプロビジョニングを標準化すると、間違ったデプロイによる設定ミスや意図しない人的な設定ミスのリスクの軽減に役立ちます。このコントロールを実装するためのガイダンスと改善計画については、『運用上の優秀性の柱』のホワイトペーパーの [「設計原則」のセクション](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) を参照してください。
  +  **監査コントロールのためのログ記録と監視: ** リソースの障害、パフォーマンス低下、セキュリティの問題を監視するためのメカニズムを実装します。これらのコントロールを標準化すると、システムで発生したアクティビティの監査証跡が提供され、問題のタイムリーなトリアージと修復に役立ちます。SEC04 [(「セキュリティイベントは、どのように検出して調査するのですか?」) のベストプラクティスは、](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) このコントロールを実装するためのガイダンスを提供しています。
+  **オートメーションを使用する: ** オートメーションにより、インシデントのタイムリーで大規模な解決が可能となります。AWS は、インシデント対応戦略の枠組みの中で自動化を行うサービスを複数提供しています。オートメーションと人の介入との適切なバランスを見つけることに重点を置きます。プレイブックとランブックでインシデント対応を構築しながら、繰り返し可能なステップを自動化します。AWS Systems Manager Incident Manager などの AWS サービスを使用して [IT インシデントの解決を迅速化します](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/)。デベロッパーツールを [使用して、](https://aws.amazon.com/devops/) バージョン管理を提供し、[Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) と Infrastructure as Code (IaC) のデプロイを自動化し、人間の介入を排除します。該当する場合は、Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、AWS Config、Amazon Macie などのマネージドサービスを使用して検出とコンプライアンス評価を自動化します。Amazon DevOps Guru などの機械学習を使用して検出機能を最適化し、異常な動作パターンの問題が発生する前に検出します。
+  **根本原因分析と、教訓から得られたアクションを実施します。** 過去のインシデント対応レビューの一環として、教訓を取り込むためのメカニズムを実装します。インシデントの根本原因により、より大規模な検出、設計上の欠陥、設定ミス、再発の可能性が明らかになった場合、問題として分類されます。そのような場合、問題を分析および解決して、通常のオペレーションの中断を最小限に抑えます。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Security Incident Response Guide (AWS セキュリティインシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST: Computer Security Incident Handling Guide ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

 **関連動画:** 
+  [AWS のインシデント対応とフォレンジックの自動化 ](https://youtu.be/f_EcwmmXkXk)
+ [ ランブック、インシデントレポート、インシデント対応の DIY ガイド ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS 環境のセキュリティインシデントの準備と対応 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **関連サンプル:** 
+  [ラボ : Jupyter を使用したインシデント対応プレイブック - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) 
+ [ ラボ: Incident Response with AWS Console and CLI (AWS コンソールと CLI を使用したインシデント対応) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP03 フォレンジック機能を備える:
<a name="sec_incident_response_prepare_forensic"></a>

 インシデントレスポンダーがフォレンジック調査が対応計画に適合する時期と方法を理解しておくことが重要です。組織は収集される証拠と、プロセスで使用されるツールを定義する必要があります。外部のスペシャリスト、ツール、オートメーションなど、適切なフォレンジック調査能力を特定し、準備します。前もって下す重要な決定は、ライブシステムからデータを収集するかどうかです。システムの電源を切ったり再起動したりすると、揮発性メモリの内容やアクティブなネットワーク接続などの一部のデータが失われます。 

対応チームは、AWS Systems Manager、Amazon EventBridge、および AWS Lambda などのツールを組み合わせて、オペレーティングシステムおよびトラフィックミラーリング内でフォレンジックツールを実行し、ネットワークパケットキャプチャを取得し、非永続的証拠を収集できます。ログ分析やディスクイメージの分析などその他のアクティビティは、レスポンダーがアクセスできるカスタマイズされたフォレンジックワークステーションとツールを備えた専用のセキュリティアカウントで実行します。

関連ログは、高い耐久性と整合性を提供するデータストアに定期的に送信します。レスポンダーは、それらのログにアクセスできる必要があります。AWS には、Amazon Athena、Amazon OpenSearch Service (OpenSearch Service)、および Amazon CloudWatch Logs Insights などログ調査をやりやすくするツールがいくつかあります。さらに、Amazon Simple Storage Service (Amazon S3) Object Lock を使って安全に証拠を保持します。このサービスは WORM (write-once- read-many) モデルに従っており、定義済みの期間オブジェクトが検出されたり上書きされたりするのを防ぎます。フォレンジック調査技術には専門的なトレーニングが必要なため、外部のスペシャリストとの連携が必要になる場合があります。

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  フォレンジック機能を確認する: 組織のフォレンジック調査機能、利用可能なツール、外部スペシャリストを調査します。 
+  [インシデント対応とフォレンジックの自動化 ](https://youtu.be/f_EcwmmXkXk)

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 

# SEC10-BP04 封じ込め機能を自動化する
<a name="sec_incident_response_auto_contain"></a>

インシデントの封じ込めおよび復旧を自動化し、対応時間を短縮するとともに組織的影響を軽減します。

プレイブックからプロセスやツールを作成して実践したら、ロジックをコードベースのソリューションに分解します。そうすることによって、多くの応答者が応答を自動化し、応答者によるばらつきや推測作業を取り除くためのツールとして使用することができます。これにより、対応のライフサイクルを高速化できます。次の目標は、このコードを人間の対応者ではなく、アラートやイベント自体によって呼び出すことで完全な自動化を実現し、イベント駆動型の対応を有効にすることです。これらのプロセスではまた、セキュリティシステムに関連データを自動的に追加する必要があります。たとえば、希望しない IP アドレスからのトラフィックが関与するインシデントが起こると、AWS WAF ブロックリストまたは Network Firewall ルールグループに自動的に入力されて、それ以上のアクティビティが防止されます。

![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)


*図 3: AWS WAF が既知の悪意ある IP アドレスのブロックを自動化します。*

イベント駆動型の対応システムでは、検出メカニズムによって対応メカニズムがトリガーされ、自動的にイベントが修正されます。イベント駆動型の応答機能を使用すれば、検出メカニズムから応答メカニズムが動作するまでの時間を短縮できます。このイベント駆動型アーキテクチャを作成するには、AWS Lambda を使用できます。AWS Lambda は、イベントに応答してコードを実行し、基盤となるコンピューティングリソースを自動的に管理するサーバーレスコンピューティングサービスです。例えば、AWS CloudTrail サービスが有効な AWS アカウントがあるとします。AWS CloudTrail が無効になっている場合は `(cloudtrail:StopLogging API 呼び出しを通じて)、` Amazon EventBridge を使用して特定の `(cloudtrail:StopLogging API 呼び出しを通じて)、` イベントをモニタリングし、 AWS Lambda 関数を起動して `cloudtrail:StartLogging` を呼び出してログを再開できます。

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 封じ込め機能を自動化します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+ [AWS インシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **関連動画:** 
+  [AWS 環境のセキュリティインシデントの準備と対応](https://youtu.be/8uiO0Z5meCs) 

# SEC10-BP05 アクセスを事前プロビジョニングする
<a name="sec_incident_response_pre_provision_access"></a>

インシデント対応者が AWS に事前プロビジョニングされた正しいアクセス権を持っていることを検証しておき、調査から復旧までに必要な時間を短縮します。

 **一般的なアンチパターン:** 
+  ルートアカウントをインシデント対応に使用する 
+  既存のユーザーアカウントに変更を加える 
+  ジャストインタイムの権限昇格を提供する際に IAM アクセス許可を直接操作する 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>

AWS は、可能であれば長期的な認証情報への依存を削減または排除し、一時的な認証情報と *ジャストインタイム* の権限昇格メカニズムを優先することを推奨します。長期的な認証情報は、セキュリティリスクにさらされやすく、オペレーションのオーバーヘッドを増大させます。ほとんどの管理タスクと、インシデント対応タスクについては、管理アクセスの一時的な昇格と併せて [ID フェデレーション](https://docs.aws.amazon.com/identity/federation/) を実装することを [お勧めします](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)。このモデルでは、ユーザーはより高いレベルの権限 (インシデント対応ロールなど) への昇格をリクエストします。ユーザーに昇格の資格がある場合、リクエストは承認者に送信されます。リクエストが承認された場合、ユーザーは、一時的な [AWS 認証情報](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) のセットを受け取り、これを使用してタスクを完了できます。これらの認証情報の期限が切れたら、ユーザーは新たな昇格リクエストを送信する必要があります。

 インシデント対応の大半のケースでは、一時的な権限昇格を使用することをお勧めします。そのための適切な方法は、 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) および [セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) を使用してアクセスのスコープを定義することです。 

 ID フェデレーションを使用できないケースがあります。例えば次のケースです。 
+  侵害を受けた ID プロバイダー (IdP) に関連する停止状態 
+  設定ミスや人的エラーに起因する、フェデレーションアクセス管理システムの障害 
+  分散型サービス拒否 (DDoS) イベントやシステムがレンダリング不可となるなどの悪意あるアクティビティ 

 上記のケースでは、緊急 *break glass * アクセス設定により、インシデントの調査とタイムリーな修復を許可する必要があります。AWS は、 [適切なアクセス許可を持つ IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) を使用することをお勧めします。IAM ユーザーがタスクを実行し AWS のリソースにアクセスするための適切な許可を付与します。ルート認証情報は、 [ルートユーザーアクセスが必要なタスク](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)のみに使用します。インシデント対応者が AWS と他の関連システムへの適切なレベルのアクセス権を持っていることを検証するには、専用のユーザーアカウントへの事前プロビジョニングをお勧めします。このユーザーアカウントには特権アクセスが必要で、アカウントは厳格に制御、監視されなければなりません。このアカウントは、必要なタスクの実行で要求される最小特権で構成しなければなりません。アクセス権のレベルは、インシデント管理計画の一環として作成されたプレイブックに基づいている必要があります。 

 ベストプラクティスとして、特定の目的のための専用のユーザーとロールを使用します。IAM ポリシーの追加によりユーザーまたはロールアクセスを一時的に昇格させると、インシデント対応中にユーザーがどのアクセス権を持っていたかが明確でなくなり、昇格された権限が取り消されないリスクが生じます。 

 できるだけ多くの依存関係を削除し、できるだけ多くの障害シナリオでアクセスが可能になることを検証することが重要です。そのためには、インシデント対応ユーザーが、専用のセキュリティアカウントで AWS Identity and Access Management ユーザーとして作成されており、既存のフェデレーションまたはシングルサインオン (SSO) ソリューションにより管理されていないことを検証するためのプレイブックを作成します。個々のインシデント対応者は、自分の名前が付いたアカウントを持つ必要があります。アカウント設定では、 [強力なパスワードポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) および多要素認証 (MFA) を適用する必要があります。インシデント対応プレイブックで AWS マネジメントコンソール へのアクセスのみが要求されている場合、そのユーザーのアクセスキーが設定されてはならず、アクセスキー作成を明示的に禁止する必要があります。これは IAM ポリシーまたはサービスコントロールポリシー (SCP) で設定できます。詳細は、『AWS Security Best Practices for [AWS Organizations SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)』(AWS Organizations SCP のための AWS セキュリティベストプラクティス) に記載されています。ユーザーは、他のアカウントのインシデント対応ロールを引き受ける以外の権限を持つべきではありません。 

 インシデント対応中、調査、修復、または復旧アクティビティをサポートするためのアクセス権を社内または社外の他の個人に付与する必要が生じる可能性があります。この場合、前述のプレイブックメカニズムを使用します。また、インシデント完結後直ちに追加のアクセス権を取り消すためのプロセスが必要です。 

 インシデント対応ロールの使用が適切に監視および監査されていることを検証するには、この目的のために作成された IAM ユーザーアカウントが個人間で共有されないようにすること、および特定のタスクで必要な場合を除き、AWS アカウント ルートユーザーが使用されないようにすることが [不可欠です](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。ルートユーザーが必要な場合 (例えば、特定のアカウントへの IAM アクセスが利用できない場合) は、用意されたプレイブックに従って別個のプロセスを使用し、ルートユーザーのパスワードと MFA トークンの使用の可否を検証します。 

 インシデント対応ロールのための IAM ポリシーを設定するには、 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) を使用し AWS CloudTrail ログに基づいてポリシーを生成することを検討します。そのためには、非本番アカウントのインシデント対応ロールに管理者アクセス権を付与し、プレイブックを一通り実行します。完了したら、実行されたアクションのみを許可するポリシーを作成できます。このポリシーは、すべてのアカウントのすべてのインシデント対応ロールに適用できます。各プレイブックについて個別の IAM ポリシーを作成すると、管理と監査が容易になるでしょう。プレイブックの例には、ランサムウェア、データ侵害、本番環境へのアクセス不可、その他のシナリオについての対応計画が含まれています。 

 インシデント対応ユーザーアカウントを使用して、 [別の AWS アカウント アカウントのインシデント対応専用の IAM ロールを引き受けます](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。これらのロールは、セキュリティアカウントのユーザーのみが引き受け可能なように設定する必要があります。信頼関係では、呼び出しプリンシパルが MFA を使用して認証されたことを要求する必要があります。ロールは、スコープが厳密に定義された IAM ポリシーを使用してアクセスを制御する必要があります。これらのロールに対するすべての `AssumeRole` リクエストが CloudTrail ログに記録され、アラートが送信されるようにします。また、これらのロールを使用して実行されたアクションがログに記録されるようにします。 

 IAM ユーザーアカウントと IAM ロールの両方を CloudTrail ログで見つけやすくするために、これらに明快な名前を付けることを強くお勧めします。例えば、IAM アカウントに `<USER_ID>break-glass` 、IAM ロールに `BREAK-GLASS-ROLE` という名前を付けます。

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) を使用して、AWS アカウントの API アクティビティをログに記録します。また、 [インシデント対応ロールの使用状況に関するアラートを設定する](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)必要があります。ルートキーを使用する際のアラートの設定に関するブログ記事を参照してください。インストラクションに変更を加えて、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) メトリクスフィルターを `AssumeRole` イベント (インシデント対応 IAM ロールに関連する) に対して設定できます。 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 インシデント対応ロールは高いレベルのアクセス権を持っている可能性があるため、これらのアラートは幅広いグループに送信され、速やかに対応が取られることが重要です。 

 インシデント対応中、対応者は、IAM によって直接保護されていないシステムへのアクセスが必要となる可能性があります。これには Amazon Elastic Compute Cloud インスタンス、Amazon Relational Database Service データベース、Software-as-a-Service (SaaS) プラットフォームが含まれます。SSH や RDP などのネイティブプロトコルではなく、[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) を使用して Amazon EC2 インスタンスへの管理アクセスを行うことを強くお勧めします。このアクセスは、IAM を使用して制御できます。それにより安全が確保され、監査が行われます。また、 [AWS Systems Manager Run Command ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)を使用してプレイブックの一部を自動化することも可能です。それにより、ユーザーのエラーを減らし、復旧にかかる時間を短縮できます。データベースとサードパーティーツールへのアクセスでは、アクセス認証情報を AWS Secrets Manager に保管し、インシデント対応者ロールにアクセス権を付与することをお勧めします。 

 最後に、インシデント対応 IAM ユーザーアカウントの管理は、 [Joiners、Movers、および Leavers プロセス](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) に追加し、定期的にテストして、意図されたアクセスのみが許可されていることを検証する必要があります。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [Managing temporary elevated access to your AWS environment (AWS 環境へのアクセスの一時的な昇格の管理)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS Security Incident Response Guide (AWS セキュリティインシデント対応ガイド) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [IAM ユーザー用のアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [AWS での多要素認証 (MFA) の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ Configuring Cross-Account Access with MFA (MFA を使用したクロスアカウントアクセスの設定) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies (IAM Access Analyzer を使用した IAM ポリシーの設定) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (マルチアカウント環境の AWS Organizations サービスコントロールポリシーのためのベストプラクティス) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (AWS アカウントのルートアクセスキーを使用した場合の通知の受信方法) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Create fine-grained session permissions using IAM managed policies(AWS マネージドポリシーを使用して、きめ細かいセッション許可を作成する) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **関連動画:** 
+ [AWS のインシデント対応とフォレンジックの自動化 ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [ランブック、インシデントレポート、インシデント対応の DIY ガイド](https://youtu.be/E1NaYN_fJUo) 
+ [AWS 環境のセキュリティインシデントの準備と対応 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **関連サンプル:** 
+ [ ラボ: AWS Account Setup and Root User (AWS アカウントのセットアップとルートユーザー) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ ラボ: Incident Response with AWS Console and CLI (AWS コンソールと CLI を使用したインシデント対応) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06 ツールを事前デプロイする
<a name="sec_incident_response_pre_deploy_tools"></a>

 復旧までの調査時間を短縮できるように、セキュリティ担当者は適切なツールを AWS に事前にデプロイしておきます。 

セキュリティエンジニアリングとオペレーションの機能を自動化するために、AWS の包括的な API とツールセットを使用できます。ID 管理、ネットワークセキュリティ、データ保護、モニタリング機能を完全に自動化し、すでに導入されている一般的なソフトウェア開発方法を使用して提供できます。セキュリティオートメーションを構築すれば、担当者がセキュリティ上の位置づけを監視し、イベントに手動で応答する代わりに、システムが監視、レビューを行い応答を開始できます。AWS サービス間で検索可能で関連性の高いログデータをインシデント対応者に自動的に提供する効果的な方法は、次を有効にすることです: [Amazon Detective](https://aws.amazon.com/detective/).

インシデント対応チームが同じ方法でアラートに対応し続けると、アラート疲れになるリスクがあります。時間の経過とともに、チームはアラートに対する感度が鈍くなり、通常の状況の処理で間違いを犯したり、異常なアラートを見逃したりする可能性があります。自動化を利用すれば、繰り返し発生する通常のアラートを処理する機能を使用してアラート疲れを回避し、機密性の高いインシデントや独自のインシデントの処理を人間に任せることができます。Amazon GuardDuty, AWS CloudTrail Insights、および Amazon CloudWatch Anomaly Detection などの異常の検出システムを統合することで、よくあるしきい値ベースのアラートの負担を減らすことができます。

プロセス内のステップをプログラムで自動化すれば、手動プロセスを改善できます。イベントに対する修復パターンを定義したら、そのパターンを実行可能なロジックに分解して、そのロジックを実行するコードを記述できます。その後、対応者は、そのコードを実行して問題を修正します。時間の経過とともに、より多くのステップを自動化し、最終的には一般的なインシデントのクラス全体を自動的に処理できるようになります。

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのオペレーティングシステム内で実行されるツールでは、AWS Systems Manager Run Command の使用を評価する必要があります。このコマンドを使うと、Amazon EC2 インスタンスのオペレーティングシステムにインストールしたエージェントを使用して、インスタンスをリモートで安全に管理できます。その際、Systems Manager Agent (SSM Agent) が必要です。これは多くの Amazon マシンイメージ (AMI) にデフォルトでインストールされています。ただし、一度インスタンスが侵害されると、そのインスタンス上で実行されているツールやエージェントからの応答は信頼できる応答とみなされません。

 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ツールを事前デプロイする: セキュリティ担当者がインシデント発生時に適切な対応ができるよう、AWS に適切なツールをあらかじめ配備しておきます。 
  +  [ラボ : AWS マネジメントコンソール と CLI を使用したインシデント対応 ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
  + [ Jupyter を使用したインシデント対応プレイブック - AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
  +  [AWS セキュリティオートメーション ](https://github.com/awslabs/aws-security-automation)
+  リソースのタグ付けを実施する: インシデント発生時にリソースを特定できるように、調査中のリソースのコードなどの情報をリソースにタグ付けします。
  + [AWS のタグ付け戦略 ](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Incident Response Guide (AWS インシデント対応ガイド) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)

 **関連動画:** 
+  [ ランブック、インシデントレポート、インシデント対応の DIY ガイド ](https://youtu.be/E1NaYN_fJUo)

# SEC10-BP07 ゲームデーを実施する
<a name="sec_incident_response_run_game_days"></a>

ゲームデーは、シミュレーションや演習とも呼ばれ、現実的なシナリオでインシデント管理計画や手順を練習するための体系的な機会を提供する内部イベントです。これらのイベントは、実際のシナリオで使用されるのと同じツールやテクニックを使って、レスポンダーを訓練するものでなければなりません。ゲームデーは基本的に、準備をすることで対応能力を反復的に高めていくものです。ゲームデーのアクティビティを実行すべき理由は、次のとおりです。 
+ 準備態勢を検証する
+ 自信の向上 - シミュレーションやトレーニングスタッフから学ぶ
+ コンプライアンスまたは契約上の義務に準拠する
+ 認定のためのアーティファクトを生成する
+ 俊敏性 - 段階的な改善
+ 高速化とツールの改善
+ コミュニケーションとエスカレーションを詳細化する
+ まれで予期外の事態に備える

このような理由から、シミュレーションアクティビティへの参加は、ストレスの多いイベント時の組織の有効性を高めるという価値があります。現実的で有益なシミュレーションアクティビティを開発するのは簡単な作業ではありません。すでに把握しているイベントを処理する手順や自動化のテストには一定のメリットがありますが、予想外の事象に対して自身をテストして継続的に改善するクリエイティブな [セキュリティインシデント対応のシミュレーション (SIRS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) アクティビティへの参加も重要です。

環境、チーム、ツールに合わせたカスタムのシミュレーションを作成します。問題を見つけて、それに関するシミュレーションを設計します。これは、漏洩した認証情報、不要なシステムと通信しているサーバー、または不正な露出をもたらす設定ミスなどが考えられます。組織に精通したエンジニアを特定して、シナリオと参加する別のグループを作成してもらいます。シナリオは現実的で、十分に価値のある挑戦的なものであるべきです。ロギング、通知、エスカレーション、ランブックまたは自動化の実行を実践する機会も含まれているはずです。シミュレーション中、レスポンダーは技術的および組織的スキルを発揮し、リーダーはインシデント管理スキルを高めるために参加する必要があります。シミュレーションの終わりには、チームの努力を称え、さらなるシミュレーションの反復、繰り返し、拡張の方法を探します。

[AWS は、インシデント対応ランブックのテンプレートを作成しました。](https://github.com/aws-samples/aws-incident-response-playbooks) これは、対応策の準備だけでなく、シミュレーションのベースとしても活用できます。計画時、シミュレーションは 5 段階に分けられます。

**証拠の収集: **この段階では、内部チケッティングシステム、モニタリングツールからのアラート、匿名のヒント、または公共のニュースなどさまざまな手法を使ってアラートを取得します。次にチームはインフラストラクチャとアプリケーションログのレビューを開始して、侵害のソースを特定します。このステップでは、内部エスカレーションとインシデントリーダーシップも関与する必要があります。特定されたら、チームがインシデントの封じ込めに取り掛かります。

**インシデントを封じ込める: **チームはインシデント発生を特定し、侵害のソースを突き止めます。チームは次に、侵害された認証情報の無効化、コンピューティングリソースの隔離、またはロールのアクセス許可の取り消しなど、封じ込めるためのアクションを取る必要があります。

**インシデントを根絶する **これでインシデントが封じ込められたため、チームは侵害を受けやすいアプリケーションやインフラストラクチャ設定の脆弱性を軽減する作業に取り掛かります。これには、ワークロードに使用された認証情報のローテーション、アクセスコントロールリスト (ACL) の修正、またはネットワーク設定の変更などが含まれます。

**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  実行 [本番環境で実行する](https://wa.aws.amazon.com/wat.concept.gameday.en.html): 主なスタッフやマネジメントが関与するさまざまな脅威に対してシミュレーションされた [インシデント](https://wa.aws.amazon.com/wat.concept.incident.en.html) 対応 [イベントを](https://wa.aws.amazon.com/wat.concept.event.en.html) 実行します (ゲームデー)。
+  教訓を把握する:  [本番環境で実行する](https://wa.aws.amazon.com/wat.concept.gameday.en.html) から得た教訓は、プロセスを改善するためのフィードバックループの一部であるべきです。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+ [AWS Incident Response Guide (AWS インシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) 

 **関連動画:** 
+ [ ランブック、インシデントレポート、インシデント対応の DIY ガイド ](https://youtu.be/E1NaYN_fJUo)