# AWS Security Incident Response 設定の検証 オンボーディングが完了したら、実際のセキュリティイベントが発生する前に、登録、検出ソース、AWS Identity and Access Management (IAM) アクセス許可、封じ込め、通知が正しく設定されていることを検証できます。このセクションでは、AWS Management Consoleと AWS CLI の両方を使用したステップバイステップの検証手順について説明します。 **Topics** + [検証を行う前の確認](#config-validation-before) + [ステップ 1: 登録とメンバーシップを確認する](#config-validation-step1) + [ステップ 2: 検出ソースとトリアージを検証する](#config-validation-step2) + [ステップ 3: 自動検出結果パイプラインを検証する](#config-validation-step3) + [ステップ 4: 通知とインシデント対応チームを検証する](#config-validation-step4) + [ステップ 5: 封じ込めの準備状況を確認する (オプション)](#config-validation-step5) + [ステップ 6: 進行中のオペレーションを確認する](#config-validation-step6) + [検証チェックリスト](#config-validation-checklist) + [課金の検証](#config-validation-billing) + [トラブルシューティング](#config-validation-troubleshooting) + [関連リソース](#config-validation-related-resources) ## 検証を行う前の確認 ### Security Incident Response の設定を検証するための前提条件 これらの検証ステップを完了するには、次のものがあることを確認してください。 + コンソールまたは AWS Command Line Interface (AWS CLI) から**委任管理者アカウント** (オンボーディング時に指定したアカウント) へのアクセス + サブスクリプションをアクティブ化した AWS リージョン + メンバーシップ ID (AWS CLI を使用して検証する場合) ### ログの準備状況を確認する AWS Security Incident Response は、ユーザーに代わってログソースの有効化を行いません。調査中、エンジニアは環境内に既に存在するログに依存します。セットアップを検証する前に、対象となるすべてのアカウントと AWS リージョンで次のログが有効になっていることを確認します。これらのログがないと、調査中にセキュリティインシデント対応エンジニアが確認できる情報が制限されます。続行する前に有効にしてください。 + **AWS CloudTrail**: 管理イベントの証跡 (必須) + **Amazon VPC フローログ** (推奨) + 機密バケットへの **Amazon S3 サーバーアクセスログ** (推奨) + **Amazon Route 53 Resolver DNS クエリログ** (推奨) ### GuardDuty が有効になっていることを確認する 次のコマンドを使用して、Amazon GuardDuty がアカウントでアクティブであることを確認します。 ``` aws guardduty list-detectors ``` 空でないレスポンスは、現在の AWS リージョンで GuardDuty が有効になっていることを示します。このステップをアクティブな各リージョンに繰り返すか、GuardDuty 委任管理者アカウントを使用して組織全体を検証します。 **注記** AWS Security Incident Response の料金には、GuardDuty の使用コストは含まれません。詳細については、[GuardDuty の料金ページ](https://aws.amazon.com/guardduty/pricing/)を参照してください。 ## ステップ 1: 登録とメンバーシップを確認する ### AWS Security Incident Response コンソールを使用する場合 1. 委任管理者アカウントにサインインします。 1. [AWS Security Incident Response コンソール](https://console.aws.amazon.com/security-ir/)を開きます。 1. メンバーシップのステータスが **[Active]** であることを確認します。*[Pending]* のステータスは、オンボーディングが不完全であることを示します。 1. **[アカウントスコープ]** で、対象の OU が一覧に表示されていることを確認します。カバレッジは、個々のアカウントレベルではなく、組織単位 (OU) レベルで選択されます。選択した OU 内 (子 OU を含む) のすべてのアカウントが対象になります。 1. 一覧表示される**リージョン**がワークロードの実行リージョンに一致することを確認します。リージョンの選択は登録時にロックされます。セットアップ後に変更することはできません。 ### AWS CLI を使用する場合 委任管理者アカウントから次のコマンドを実行します。 ``` aws security-ir list-memberships ``` 上記のコマンドはメンバーシップ ID とステータスを返します。 インシデント対応チーム設定を始めとする完全なメンバーシップの詳細を取得するには、次のコマンドを実行します。 ``` aws security-ir get-membership --membership-id {{membership-id}} ``` コマンド出力を使用して次の情報を確認します。 + メンバーシップステータスが `Active` である + 一覧表示されたインシデント対応チームメンバーが目的のステークホルダーに一致する + 少なくとも 2 人のインシデント対応チームメンバーが設定されている (必須) ### 委任管理者を検証する 正しいアカウントが Security Incident Response の委任管理者として登録されていることを確認するには、次のコマンドを実行します。 ``` aws organizations list-delegated-administrators \ --service-principal security-ir.amazonaws.com ``` **注記** **ベストプラクティス:** 他の AWS セキュリティサービス (AWS Security Hub CSPM や GuardDuty など) に設定したものと同じ委任管理者アカウントを使用します。[AWS セキュリティリファレンスアーキテクチャ](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html)では、Security Tooling アカウントを使用することが推奨されます。 ## ステップ 2: 検出ソースとトリアージを検証する AWS Security Incident Response は、Security Hub CSPM から GuardDuty およびサードパーティーツールのセキュリティ検出結果をモニタリングします。このサービスは、サービスにリンクされたロールを使用して、オンボーディング時にアカウントにデプロイされた Amazon EventBridge ルールを介して検出結果を取り込みます。 ### トリアージサービスにリンクされたロールを確認する `AWSServiceRoleForSecurityIncidentResponse_Triage` サービスにリンクされたロールは、管理アカウントと対象範囲内のすべてのメンバーアカウントに存在する必要があります。 確認するには、管理アカウントと対象範囲内のメンバーアカウントで次のコマンドを実行します。 ``` aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage ``` ロールが存在する場合、応答が正常に返されます。`NoSuchEntity` エラーが発生した場合は、次のいずれかの操作を行います。 + **コンソールを使用してオンボーディングした場合:** ロールは自動的に作成されているはずです。AWS サポート に連絡する。 + **API または AWS CLI を使用してオンボーディングした場合:** ロールを手動で作成する手順については、「[API/CLI を使用して Security Incident Response を有効にし、インシデント対応チームを設定する](https://docs.aws.amazon.com/security-ir/latest/userguide/enable-sir-using-cli.html)」を参照してください。 ### サービスにリンクされたプライマリロールを確認する `AWSServiceRoleForSecurityIncidentResponse` ロールは、委任管理者アカウントにも存在する必要があります。ロールが存在することを確認するには、次のコマンドを実行します。 ``` aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse ``` ### プロアクティブレスポンスと EventBridge ルールを検証する AWS Security Incident Response コンソールで、**プロアクティブレスポンス**が有効として表示されることを確認します。有効な場合、サービスは以下を実行します。 + EventBridge ルールを介して GuardDuty および Security Hub CSPM から検出結果を取り込む + 顧客固有のコンテキスト (既知の IP、予期される IAM エンティティ) を使用して検出結果を自動的にトリアージする + 確認されたセキュリティ問題が特定されたときにプロアクティブな調査ケースを作成する + 良性であると判断された GuardDuty の検出結果 (GuardDuty コンソールの **[アーカイブ済み]** 検出結果で表示可能) をアーカイブする **EventBridge ルールがメンバーアカウントにデプロイされていることを確認する** EventBridge ルールがメンバーアカウントにデプロイされていることを確認するには、次の手順を実行します。 1. 対象のメンバーアカウントで Amazon EventBridge コンソールを開きます。 1. **[Rules]** (ルール) を選択します。 1. 名前に `SecurityIncidentResponse` を含むルールが存在し、**[有効]** になっていることを確認します。 ルールがない場合は、Security Incident Response コンソールからプロアクティブレスポンスのセットアップを再実行するか、AWS サポート に連絡してください。 ### サードパーティーの統合を検証する (該当する場合) サードパーティーの検出ツール (CrowdStrike Falcon、Trend Micro Cloud One、Fortinet Lacework FortiCNAPP など) を使用する場合は、調査結果が Security Hub CSPM を経由していることを確認します。 1. [AWS Security Hub CSPM コンソール](https://console.aws.amazon.com/securityhub/)を開きます。 1. **[統合]** に移動します。 1. サードパーティーベンダーの統合が **[結果を受け入れる]** と表示されることを確認します。 **注記** Security Hub CSPM 標準やコントロールを有効にする必要はありません。Security Incident Response でサードパーティーの検出結果を取り込むために必要なのは、ベンダー統合のみです。 ## ステップ 3: 自動検出結果パイプラインを検証する このステップでは、EventBridge パイプラインがアクティブであること、および検出結果が自動トリアージに達することを確認します。 ### GuardDuty サンプルの検出結果について GuardDuty の組み込みの **[結果サンプルの生成]** 機能は、サンプルとしてマークされた検出結果を生成します。自動トリアージは、サンプルの検出結果をフィルタリングしてノイズを防止します。検出結果はトリアージパイプライン全体を通過せず、Security Incident Response 設定の検証には使用できません。**このステップには使用しないでください。** ### GuardDuty テストドメインで検証する GuardDuty ドキュメントは、実際のセキュリティイベントを必要とせずに実際の検出結果を生成するテストドメイン (`guarddutyc2activityb.com`) を提供します。対象アカウントの Amazon EC2 インスタンスからこのドメインをクエリすると、Security Incident Response が取り込んで処理する検出結果が生成されます。 **テスト検出結果を生成するには:** 1. Systems Manager Session Manager または SSH を使用して、対象アカウントの Amazon EC2 インスタンスに接続します。 1. 次のコマンドを実行します。 ``` dig guarddutyc2activityb.com ``` 1. GuardDuty コンソールを開き、**[検出結果]** を選択します。検出結果は約 5 分以内に表示されます。 **予想されること:** + 自動トリアージは検出結果を処理し、本当のセキュリティイベントを示すものではないと判断します。 + 検出結果は GuardDuty に**アーカイブ**されます。表示するには、**[ステータス]** フィルターから **[アーカイブ済み]**を選択します。 + Security Hub CSPM を使用する場合、検出結果のワークフローステータスは `SUPPRESSED` に変わります。 + **プロアクティブケースは作成されません**。これは正しい動作です。ケースは、自動トリアージによって人間による調査を必要とするアクティビティが特定された場合にのみ開かれます。 **注記** テストの検出結果が 15 分以内に GuardDuty アーカイブリストに表示されない場合は、「[トラブルシューティング](#config-validation-troubleshooting)」を参照してください。使用可能な Amazon EC2 インスタンスがない場合は、ステップ 4 に進み、環境の準備ができたらこのテストに戻ります。 ## ステップ 4: 通知とインシデント対応チームを検証する ### インシデント対応チームを検証する Security Incident Response コンソールで、設定したインシデント対応チームメンバーを確認します。ケースが作成されると、すぐに各メンバーに E メール通知が送信されます。 または、次のコマンドで AWS CLI を使用して検証します。 ``` aws security-ir get-membership --membership-id {{membership-id}} ``` 以下を確認します。 + 意図したすべてのステークホルダーが一覧表示される + すべての E メールアドレスが正しい + 各メンバーのコミュニケーション設定が適切に設定されている (すべてのコミュニケーションオプションがデフォルトで有効になっている。メンバーが通知を受信していない場合は、設定がクリアされていないことを確認します) ### ケースウォッチャーの概要 ケースウォッチャーは、特定のケースを表示するアクセス許可が付与されているステークホルダーです。主要な詳細を以下に示します。 + **ウォッチャーはアカウントあたりではなく、ケースあたりで指定します。**ウォッチャーを 1 つのケースに追加しても、他のケースへのアクセスは付与されません。ウォッチャーがケースを表示できるようにするには、各ケースにウォッチャーを明示的に追加する必要があります。 + **ウォッチャーには表示専用のアクセス許可が付与されます。**ウォッチャーは、ケースの詳細を表示し、ケースの更新に関する通知を受け取ることはできますが、リソースに対して封じ込めまたは修復アクションを実行することはできません。 + 個々のケースごとに**最大 30 人のステークホルダー**を追加できます。 + 各ケースには、当該ケースのみにアクセスを付与するスコープ設定済みの IAM ポリシーが含まれ、最小特権アクセスが維持されます。 このケースごとのスコープは、関連する特定のケースのみを表示する必要があるマネージド検出と対応 (MDR) パートナーやサードパーティーの調査チームなどの外部当事者にアクセスを付与する場合に特に重要です。 ### テストケースで通知配信を検証する エンドツーエンドの通知フローを検証する最も効果的な方法は、事後対応 (セルフマネージド) テストケースを作成することです。 1. Security Incident Response コンソールで、新しい**セルフマネージドケース**を作成します。 1. ケースのタイトルと説明には、「**これは設定検証テストであり、実際のセキュリティイベントはありません**」と明記してください。 1. 設定されたすべてのインシデント対応チームメンバーが E メール通知を受信していることを確認します。 1. 通知が受信されたことを確認したら、ケースを閉じます。 **重要** AWS でサポートされるエンゲージメントをリクエストすると、テストケースの作成によってセキュリティインシデント対応エンジニアからの対応がトリガーされる場合があります。不要なエスカレーションを避けるため、ケースをテストとして明確にマークしてください。このステップを 1 回使用してチャネルが機能していることを確認し、ケースをすぐにクローズします。 ### ケース通知に期待すること ケースが (サービスによってプロアクティブに、またはチームによってリアクティブに) 作成されると、設定されたすべてのインシデント対応チームメンバーにケースの詳細を含む E メール通知が送信されます。 ### EventBridge 統合を検証する (設定されている場合) ケースイベントをサードパーティープラットフォーム (ServiceNow、Jira、Slack、PagerDuty など) にルーティングするように EventBridge を設定した場合は、テストケースがそれらのシステムで予期される通知をトリガーすることを確認します。 ## ステップ 5: 封じ込めの準備状況を確認する (オプション) **注記** **封じ込めはオプションです。デフォルトでは有効になっていません。**このセクションで説明する封じ込めインフラストラクチャは、封じ込めを有効にする場合にのみ必要です。Security Incident Response が環境のモニタリングと検出結果の調査を行う場合、またはケースを開く場合には必要ありません。 ### 封じ込めを有効にしていない場合 ここで検証するものはありません。Security Incident Response は、セキュリティイベント中のガイダンスと調査を提供しますが、明示的に承認しない限り、自動封じ込めアクションを実行しません。 ### 封じ込めを有効にしていない場合 **コンソールで封じ込めステータスを確認します。**封じ込めアクションが **[承認済み]** として表示されているかどうかを確認します。サポートされている封じ込めアクションには、以下に対するランブックが含まれます。 + 影響を受ける Amazon S3 バケット + 影響を受ける Amazon EC2 インスタンス + 影響を受ける IAM プリンシパル **CloudFormation StackSet がデプロイされていることを確認します。**封じ込めには、対象アカウントに IAM ロール (`AWSSecurityIncidentResponseContainment` と `AWSSecurityIncidentResponseContainmentExecution`) が必要です。 1. 管理アカウントで AWS CloudFormation を開きます。 1. **[StackSets]** を選択します。 1. Security Incident Response の封じ込め StackSet がすべてのターゲットアカウントで `SUCCEEDED` と表示されることを確認します。 StackSet がデプロイされていない場合、コンソールでの封じ込め承認では、実際の封じ込めアクションは実行されません。 **封じ込め設定を確認します。**Security Incident Response は、次の 3 つの封じ込めレベルをサポートしています。 + **Approval Required** (デフォルト): ユーザーのケースごとの明示的な承認なしにリソースのプロアクティブ封じ込めは実行されません。 + **Contain Confirmed**: 影響を受けたと確認されたリソースをプロアクティブに封じ込めます。 + **Contain Suspected**: 影響を受ける可能性が高いリソースをプロアクティブに封じ込めます。 設定を送信または更新するには、**[Technical: Security Incident Response Service / Other]** の AWS サポートケースタイプでケースを作成します。 **EC2 トリアージが必要な場合:** **[EC2 Triage による封じ込め]** CloudFormation テンプレートをデプロイします。これにより、セキュリティインシデント対応エンジニアが AWS Systems Manager を使用して Amazon EC2 インスタンスから調査データを収集することが許可されます。 ## ステップ 6: 進行中のオペレーションを確認する 初期検証が完了したら、これらのインジケータを使用して、Security Incident Response が期待どおりに継続的に動作していることを確認します。 ### ケースがないのは正常です Security Incident Response は、自動トリアージが人間による調査を必要とするアクティビティを特定した場合にのみ、プロアクティブケースを作成します。トリアージで検出結果が良性であると判断されると、ケースの作成やチームへの連絡は行われずに、検出結果がアーカイブされます。開いているケースがなく、アーカイブされた GuardDuty の検出結果のフローが一貫しているデプロイは、意図したとおりに動作しています。 環境が数日間アクティブになった後にケースと**アーカイブされた検出結果が両方とも表示されない場合は、パイプラインが接続されていない可能性があります。ステップ 2 と 3 を確認してください。 **注記** 5 日間顧客の応答がないプロアクティブケースは自動的にクローズされます。 ### ヘルスシグナルとしてアーカイブされた検出結果と抑制ルール Security Incident Response は検出結果を経時的に処理するため、2 つの観測可能なアーティファクトが作成されます。 + **アーカイブ済みの検出結果:** 自動トリアージで無害であると判断された検出結果。これらは時間の経過とともに蓄積され、GuardDuty コンソールの **[検出結果]** に表示さます。**[アーカイブ済み]** を選択します。 + **GuardDuty 抑制ルール:** 環境で予期されるアクティビティとして確認された検出結果タイプの場合、Security Incident Response は、名前付き抑制ルール (`SIRTriage-` のプレフィックス) をデプロイします。これらは、自動トリアージがアクティブに機能していることを示す最も明確な継続的なシグナルです。GuardDuty コンソールの **[抑制ルール]** に表示されます。 抑制ルールが作成されると、インシデント対応チームに通知されます。ルールが誤って作成された場合は、AWS サポート に連絡してロールバックをリクエストしてください。アーカイブされた検出結果は GuardDuty に 90 日間保持されます。 ### 月次アクティビティレポート Security Incident Response は、処理された検出結果、トリアージの結果、開かれたケースをまとめた月次アクティビティレポートをインシデント対応チームに送信します。最初の完全な暦月が経過してもチームがレポートを受け取っていない場合は、インシデント対応チームのメンバーがコミュニケーションを有効にしていることを確認してください。月次レポートに関連するその他の問題については、アカウントチームに問い合わせるか、**[Technical: Security Incident Response Service / Other]** のケースタイプでサポートケースを開き、次の情報を含めてください。 + お客様の組織名 + 予期される報告月/年 (「2026 年 5 月」など) + Security Incident Response のメンバーシップ ID (わかっている場合) + Security Incident Response メンバーシップの対象となるアカウント ID ### セキュリティインシデント対応エンジニアに期待すること ユーザーが AWS でサポートされるケースを作成するか、サービスがプロアクティブにケースを作成すると、セキュリティインシデント対応エンジニアが **15 分**以内に新しいケースを確認します。この 15 分間の確認 SLO は、アクティブなセキュリティイベントと調査の両方について、AWS がサポートするすべてのケースタイプに適用されます。最初の確認では、ケースがレビュー中であることを確認します。完全な評価タイムラインは、ケースの重要度と複雑さによって異なる場合があります。 プロアクティブケース (トリアージサービスがセキュリティ上の問題を確認したときに自動作成されるケース) の場合、自動トリアージが問題を確認した後、サービスがケースを作成し、ケースが開かれるとインシデント対応チームに通知されます。 ## 検証チェックリスト 次のチェックリストを使用して、設定が完了したことを確認します。 + ログソースが有効化されている： CloudTrail 管理イベント (必須)、Amazon VPC フローログ、Amazon S3 アクセスログ、DNS クエリログ (推奨) + GuardDuty がすべてのアカウントとアクティブなリージョンで有効になっている + Security Incident Response コンソールでメンバーシップステータスが **[Active]** になっている + リージョンが正しい (登録時にロックされます) + 委任管理者アカウントが正しい (Security Tooling アカウントが推奨されます) + アカウントスコープは意図した OU をカバーしている + `AWSServiceRoleForSecurityIncidentResponse_Triage` が管理アカウントに存在する + `AWSServiceRoleForSecurityIncidentResponse_Triage` が対象範囲内のメンバーアカウントに存在する + `AWSServiceRoleForSecurityIncidentResponse` が委任管理者アカウントに存在する + サードパーティーの統合 (該当する場合) が結果を受け入れると Security Hub CSPM に表示される + 名前に `SecurityIncidentResponse` を含む EventBridge ルールがメンバーアカウントに存在し、有効になっている + インシデント対応チームのメンバーが正しい連絡先情報で設定され、コミュニケーションが有効になっている + テストケースが作成され、すべてのチームメンバーが E メール通知を受信している + テストドメインの検出結果 (`guarddutyc2activityb.com`) が 15 分以内にアーカイブされる + 封じ込め StackSet が正常にデプロイされた (封じ込めが有効になっている場合) + 封じ込め設定が送信されている (封じ込めが有効になっている場合) + EventBridge 統合 (設定されている場合) がサードパーティープラットフォームにイベントを配信している + オペレーションの最初の 1 週間後に GuardDuty にアーカイブ済みの検出結果が表示される ## 課金の検証 **エンタープライズサポートと Unified Operations のお客様:** Security Incident Response は、サポートプランの一部として含まれます。追加コストは発生しません。AWS Cost Explorer または AWS Cost and Usage Report には Security Incident Response の料金は表示されません。 **その他のすべてのお客様:** 料金は取り込まれた検出結果の数に基づきます。1 か月あたり最初の 10,000 件の検出結果は無料です。詳細については、「[AWS Security Incident Response 料金表](https://aws.amazon.com/security-incident-response/pricing/)」を参照してください。 ## トラブルシューティング | 症状 | 考えられる原因 | 解像度 | | --- | --- | --- | | メンバーシップステータスが Pending である | オンボーディングが完了していない | セットアップ手順を完了します。「[ の開始方法](https://docs.aws.amazon.com/security-ir/latest/userguide/getting-started.html)」を参照してください。 | | list-memberships が空を返す | CLI リージョンがサブスクリプションリージョンに一致しません | アクティブ化したリージョンを指定します (--region {{region}})。 | | 管理アカウントに Triage SLR が見つからない | 作成せずに API/CLI からオンボーディングした | 手動で作成します (aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com")。 | | カバレッジにメンバーアカウントがない | SLR がメンバーアカウントにデプロイされていない | Security Incident Response コンソールからプロアクティブレスポンスのセットアップを再実行します。 | | アカウントに EventBridge ルールが存在しない | プロアクティブレスポンスの設定が不完全である | CloudFormation でのセットアップを再実行するか、StackSet の失敗を確認します。 | | GuardDuty サンプルの検出結果が処理されない | サンプルの検出結果が自動トリアージでフィルタリングされる (予期される処理) | GuardDuty でアーカイブ済みの検出結果を確認します。 | | テストドメインの検出結果 が 15 分後にアーカイブされない | EventBridge ルールがないか無効である、または GuardDuty が有効になっていない | ステップ 2 と 3 を検証します。 | | 延長期間後にケースがない | すべての検出結果がトリアージによってアーカイブされた (予期される処理)、またはパイプラインが接続されていない | GuardDuty でアーカイブ済みの検出結果を確認します。存在しない場合、EventBridge ルールとプロアクティブレスポンスを検証します | | GuardDuty の検出結果がトリアージされない | GuardDuty が有効になっていないか、検出結果を生成していない | GuardDuty が有効になっていることを確認します (aws guardduty list-detectors)。 | | サービスが検出結果を処理していない | 検出されたアクティビティが予期されたものと自動トリアージで判断された | GuardDuty のアーカイブ済みの検出結果と Security Hub CSPM SUPPRESSED の検出結果を確認します。 | | チームメンバーが通知を受信しない | E メールアドレスが正しくない、コミュニケーションが無効になっている、または E メールが迷惑フォルダーに配信されている | E メールアドレスと通信設定を検証し、迷惑メールフォルダを確認します。 | | 抑制アクションが実行されていない | StackSet がデプロイされていないか、設定が送信されていない | CloudFormation で StackSet のステータスを確認し、AWS サポート 経由で送信された設定を確認します。 | ## 関連リソース + [オンボーディングの前提条件](https://docs.aws.amazon.com/security-ir/latest/userguide/onboarding-prerequisites.html) + [ステップ 1: AWS Security Incident Response を有効にする](https://docs.aws.amazon.com/security-ir/latest/userguide/deploy-configure.html) + [サービスにリンクされたロールの使用](https://docs.aws.amazon.com/security-ir/latest/userguide/using-service-linked-roles.html) + [封じ込め](https://docs.aws.amazon.com/security-ir/latest/userguide/contain.html) + [AWS Organizations を用いて AWS Security Incident Response を使用するための考慮事項とレコメンデーション](https://docs.aws.amazon.com/security-ir/latest/userguide/considerations_important.html) + [API/CLI を使用して Security Incident Response を有効にし、インシデント対応チームを設定する](https://docs.aws.amazon.com/security-ir/latest/userguide/enable-sir-using-cli.html) + [AWS Security Incident Response 料金表](https://aws.amazon.com/security-incident-response/pricing/) + [Amazon GuardDuty の料金](https://aws.amazon.com/guardduty/pricing/)