# はじめに
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/NSyUlhDc_d0?si=PguieeTI3HrUbTDs)
**Topics**
+ [
# オンボーディングガイド
](onboarding-guide.md)
+ [
# RACI マトリックス
](raci-matrix.md)
+ [
# メンバーアカウントを選択する
](select-a-membership-account.md)
+ [
# メンバーシップの詳細を設定する
](setup-membership-details.md)
+ [
# アカウントを AWS Organizations に関連付ける
](associate-accounts-with-aws-organizations.md)
+ [
# プロアクティブレスポンスとアラートのトリアージワークフローを設定する
](setup-monitoring-and-investigation-workflows.md)
# オンボーディングガイド
AWS Security Incident Response オンボーディングガイドでは、前提条件、 オンボーディング、封じ込めアクションについて説明します。
**重要**
前提条件
デプロイにおける唯一の前提条件は、[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) を有効にすることです。
必須ではありませんが、Security Incident Response のメリットを最大化するためにも、すべてのアカウントとアクティブ AWS リージョン で [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) と [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-are-securityhub-services.html) を有効にすることをお勧めします。
GuardDuty とセキュリティインシデント対応を確認します。
[GuardDuty ベストプラクティスガイド](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) を確認します。
AWS Security Hub CSPM は、サードパーティーのエンドポイント検出および対応 (EDR) ベンダー (CrowdStrike、FortinetCNAPP (Lacework)、Trend Micro など) からの検出結果を取り込みます。これらの検出結果が Security Hub CSPM に取り込まれると、Security Incident Response によって自動的にトリアージされ、プロアクティブなケースが作成されます。Security Hub CSPM でサードパーティー EDR を設定するには、[検出と分析](https://docs.aws.amazon.com//security-ir/latest/userguide/detect-and-analyze.html) を参照してください。
Security Hub CSPM でサードパーティー EDR を設定するには:
1. Security Hub の CSPM 統合ページに移動して、サードパーティーの統合が存在することを確認します。
1. コンソールから、Security Hub CSPM サービスページに移動します。
1. **統合** (例として Wiz.IO を使用) を選択します。
![\[Security Hub CSPM の統合ページには、利用可能なサードパーティ統合が表示されます。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Security_Hub_CSPM.png)
1. 統合するベンダーを検索する
![\[サードパーティーベンダーの統合を検索・選択するための検索インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Integrations.png)
**注記**
プロンプトが表示されたら、アカウントまたはサブスクリプション情報を入力します。この情報を入力すると、Security Incident Response がサードパーティーの検出結果を取り込みます。サードパーティー検出結果の取り込みに対する料金を確認するには、Security Hub CSPM の「**統合**」ページを参照してください。
# Security Incident Response のデプロイと設定
1. **[サインアップ]** を選択します。
![\[サインアップボタンを使用した AWS Security Incident Response サインアップページ。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/AWS_Security_incident_Response.png)
1. 管理アカウントから委任管理者として **セキュリティツール** アカウントを選択します。
+ [セキュリティリファレンスアーキテクチャ](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/introduction.html)
+ [委任管理者のドキュメント](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html)
![\[委任管理者アカウントを選択するための、中央会員アカウントページを設定します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Set_Up_Central_Membership_Account.png)
1. 委任された管理者のアカウントにログイン
1. メンバーシップの詳細を入力し、アカウントを関連付ける
![\[メンバーシップの詳細を入力し、アカウントを関連付けます。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Define_Membership_Details.png)
# Security Incident Response アクションを承認する
このページでは、セキュリティインシデント対応が AWS 環境で自動モニタリングと封じ込めアクションを実行することを承認する方法について説明します。プロアクティブ対応モニタリングと封じ込めアクション設定という 2 つの異なる認可機能を有効にすることができます。これらの機能は独立しており、セキュリティ要件に基づいて個別に有効にすることができます。
# プロアクティブレスポンスを有効にする
プロアクティブレスポンスは、組織全体での Amazon GuardDuty と AWS Security Hub CSPM の統合から生成されたアラートを Security Incident Response が監視して調査できるようにします。有効にすると、セキュリティインシデント対応は、サービス自動化を使用して優先度の低いアラートをトリアージし、チームが最も重要な問題に集中できるようにします。
オンボーディング中にプロアクティブ対応を有効にするには:
1. セキュリティインシデント対応コンソールで、オンボーディングワークフローに移動します。
1. Security Incident Response が組織内のすべての対象アカウントとサポートされるアクティブな AWS リージョン リージョン全体での検出結果を監視できるようにするサービス許可を確認します。
1. [**サインアップ**] を選択して機能を有効にします。
![\[セキュリティインシデント対応が検出結果をモニタリングするために必要なアクセス許可を表示するサービスアクセス許可確認画面。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Review_Service_Permissions.png)
![\[プロアクティブ対応モニタリングを有効にするためのサインアップ確認画面。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Review_and_Sign_Up.png)
この機能により、AWS Organizations 内のすべての対象メンバーアカウントにサービスリンクロールが自動的に作成されます。ただし、管理アカウントには AWS CloudFormation スタックセットを使用してサービスリンクロールを手動で作成する必要があります。
**次のステップ:** Security Incident Response の Amazon GuardDuty および AWS Security Hub CSPM との連動に関する詳細については、「*AWS Security Incident Response ユーザーガイド*」の「*検出と分析*」を参照してください。
# 封じ込めアクションの設定を定義する
封じ込めアクションにより、AWS Security Incident Response はアクティブなセキュリティインシデント中に迅速な対応策を実行できます。これらのアクションは、環境内のセキュリティインシデントの影響をすばやく軽減するのに役立ちます。
**重要**
Security Incident Response では、封じ込め機能がデフォルトで有効化されていません。封じ込め設定を使用して、封じ込めアクションを明示的に承認する必要があります。
AWS Security Incident Response エンジニアがユーザーに代わって封じ込めアクションを実行できるようにするには、必要な IAM ロールを作成する [AWS CloudFormation StackSet](https://docs.aws.amazon.com/security-ir/latest/userguide/working-with-stacksets.html) をデプロイするだけでなく、組織またはアカウントレベルの封じ込め設定を定義する必要があります。アカウントレベルの設定は、組織レベルの設定よりも優先されます。
**前提条件:** AWS サポート ケースを作成する許可が必要です。
**封じ込めオプション:**
+ **承認が必要** (デフォルト): 個別のケースごとに明示的な承認を得ることなくリソースのプロアクティブな封じ込めを実行しない。
+ **確認されたリソースを封じ込める:** 侵害されたことが確認されているリソースのプロアクティブな封じ込めを実行する。
+ **疑わしいリソースを封じ込める:** AWS Security Incident Response エンジニアリングが実行した分析に基づいて、侵害された可能性が高いリソースのプロアクティブな封じ込めを実行する。
封じ込め設定を定義するには:
1. Security Incident Response の封じ込めアクションの設定をリクエストする [AWS サポート ケースを作成](https://docs.aws.amazon.com/security-ir/latest/userguide/create-support-case.html) します。
1. サポートケースで、以下を指定します:
+ 封じ込めアクションが承認される必要がある AWS Organizations ID または特定のアカウント ID
+ ご希望の封じ込め方法 (承認が必要、封じ込め確定、または封じ込め疑い) を選択してください。
+ 承認する封じ込めアクションのタイプ (EC2 インスタンスの分離、認証情報の更新、セキュリティグループの変更など)
1. AWS サポート がお客様と連携して封じ込めの設定を行います。必須の IAM ロールを作成するために不可欠な AWS CloudFormation StackSet をデプロイする必要があります。必要な場合は AWS サポート がサポートを提供できます。
設定されている場合、アクティブなセキュリティインシデント中に AWS Security Incident Response が承認された封じ込めアクションを実行し、環境を保護するための支援を提供します。
**次のステップ:** 封じ込め設定を行ったら、セキュリティインシデント対応コンソールでインシデント中に実行された封じ込めアクションをモニタリングできます。
# Security Incident Response のデプロイ後
AWS は、既存のインシデント対応フレームワークを置き換える代わりに、それと統合します。
1. 運用統合機能を確認して、現在のプラクティスを強化してください。
1. OU レベルのメンバーシップサポートのデモ、EventBridge の活用、ならびに Jira-ITSM との統合を視聴して、より効率的なセキュリティ運用を実現してください。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/lVSi5XyMlws)
# インシデント対応チームを更新する
1. サブスクライブ済みであることと、この *オンボーディングガイド* で説明されているオンボーディングステップが完了していることを確認します。
1. 左側のナビゲーションからインシデント対応チームを選択します。
1. チームに追加するチームメイトを選択します。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Teamates.png)
**注記**
チームには、組織のリーダーシップ、法律顧問、MDR パートナー、クラウドエンジニアなどが含まれます。最大 10 人のメンバーを追加できます。各メンバーの名前、タイトル、E メールアドレスのみを含めます。
# AWS がサポートするケース
AWS Security Incident Response は、サブスクリプションベースのケース管理ポータルを提供します。ここでは、組織が Security Incident Response と直接やり取りします。15 分の SLO を使用して、セキュリティ調査とアクティブなインシデントを支援します。事後対応ケースに制限はありません。AWS サポート対象ケースの作成のドキュメントを参照してください。
**調査チームの展開**
ケース管理ポータル経由でウォッチャーと IAM ポリシーを追加することで、ケースに対する可視性を外部関係者に付与できます。これらのオプションは、パートナー、法務チーム、または対象分野のエキスパートに使用します。
**ウォッチャーをケースに追加するには:**
1. Security Incident Response ケースポータルから任意のケースを開きます。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Cases.png)
1. [アクセス許可] タブを選択します。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Overview.png)
1. [追加] を選択します。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Watchers.png)
**注記**
各ケースには、当該ケースのみにアクセスを許可する事前設定済みの IAM ポリシーが含まれており、最小権限の原則が維持されます。このポリシーを、サードパーティの MDR パートナーや特定の調査チームが貢献できるように、IAM ロールまたはユーザーに直接コピー＆ペーストしてください。
# GuardDuty の検出結果と抑制ルール
AWS Security Incident Response は、CrowdStrike、FortinetCNAPP (Lacework)、Trend Micro からのすべての Amazon GuardDuty 検出結果と AWS Security Hub CSPM 検出結果をプロアクティブに取り込み、トリアージして、応答します。当社の自動トリアージテクノロジーは、内部分析要件を排除します。このサービスは、GuardDuty と Security Hub で無害な検出結果に対する抑制ルールと自動アーカイブルールを作成します。Amazon GuardDuty コンソールの「検出結果」でこれらのルールを表示または変更します。
有効な GuardDuty 抑制ルールを確認するには、以下の手順を実行してください。
1. Amazon GuardDuty コンソールを開きます。
1. **[検出結果]** を選択します。
1. ナビゲーションペインで、**[抑制ルール]** を選択します。**抑制ルール** ページには、アカウントのすべての抑制ルールのリストが表示されます。
1. ルールの設定を確認または変更するには、ルールを選択し、**アクション** メニューから **抑制ルールの更新** を選択します。
**注記**
SIEM テクノロジーを使用している組織では、GuardDuty 検出結果のボリュームが時間の経過とともに大幅に減少しており、Security Incident Response サービスと SIEM 両方の効率が向上しています。
# Amazon EventBridge
Amazon EventBridge は、セキュリティインシデント対応のイベント駆動型アーキテクチャを有効にし、ケースアクティビティがダウンストリームサービス (SNS、Lambda、SQS、Step-Functions) または外部ツール (Jira、ServiceNow、Teams、Slack、PagerDuty) をトリガーできるようにします。
**EventBridge ルールを設定するには:**
1. Amazon EventBridge にアクセスする
1. **[バス]** ドロップダウンから **[ルール]** を選択します。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Amazon_EventBridge_rules.png)
1. **[Create Rule]** (ルールの作成) を選択します。
1. ルールの詳細を入力します。
1. [**次へ**] を選択します。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Define_Rule.png)
1. **[AWS サービス]** にスクロールして、ドロップダウンメニューから **[AWS Security Incident Response]** を選択します。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Event_Pattern_Security.png)
1. **[イベントタイプ]** ドロップダウンから、パターンを作成するイベントまたは API コールを選択します。
1. パターンは、手動で編集して複数のイベントを含めることができます。
1. [**次へ**] を選択します。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Event_Pattern.png)
**注記**
イベントに 1 つ、または複数のターゲット (Amazon Simple Notification Service、AWS Lambda、SSM ドキュメント、Step-Function) を選択します。必要に応じて、クロスアカウントターゲットを設定します。
EventBridge 統合メニューの Partner Event Sources でパートナー統合パターンを確認できます。利用可能なパートナーには、Atlassian (Jira)、DataDog、New Relic、PagerDuty、Symantec、Zendesk などがあります。
![\[AWS のサービスは、EventBridge のデフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンに一致すると、EventBridge は、そのルールで指定されたターゲットに、イベントを送信します。\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/Amazon_EventBridge_Partners.png)
# 統合と外部ツールワークフロー
**JIRA または ServiceNow を Security Incident Response と統合するための AWS ソリューション**
Jira および ServiceNow との双方向統合のために、完全に開発されたソリューションをデプロイします。これらの統合により、AWS Security Incident Response ケースと ITSM プラットフォーム間の双方向通信が可能になり、ケースの更新が対応する Jira タスクに自動的に反映されます。
**統合の利点**
既存の ITSM プラットフォームとの AWS Security Incident Response の統合は、インシデントの追跡と対応のワークフローを一元化することでセキュリティ運用を効率化します。これらの事前構築されたソリューションによってカスタム開発が不要になるため、セキュリティチームは AWS ネイティブなインシデント管理システムとエンタープライズ全体のインシデント管理システムの両方に対する可視性を維持できるようになります。イベント駆動の自動化向けの Amazon EventBridge を活用することで、更新がプラットフォーム間でリアルタイムかつシームレスに受け渡されるため、セキュリティインシデントがどこで発生しても、それらを一貫的に追跡できるようになります。この統合アプローチにより、セキュリティアナリストのコンテキスト切り替えが軽減され、対応時間が短縮され、インシデント対応ライフサイクル全体で包括的な監査証跡が提供されます。
EventBridge ルールを設定するには:
1. Amazon EventBridge にアクセスする
1. **[バス]** ドロップダウンから **[ルール]** を選択します。
# 外部ツールワークフロー
セキュリティインシデント対応は、複数の方法で外部ツールやパートナーと統合されます。
+ *SIEM 統合:* Security Incident Response エンジニアは、AWS がサポートするケースが送信されたときに、お客様のチームと並行してこれらの検出結果を分析および調査するための支援を提供します。ハイブリッド環境とマルチクラウド環境間の相関関係を特定し、プロバイダー間の脅威アクターの動きをスコープするのに役立ちます。
+ *既存のセキュリティオペレーションを強化:* 従来の GuardDuty レスポンスワークフローをより効率的で並列なレスポンスモデルに置き換えます。現在、多くの組織がケース管理を通じた検出ワークフローに SIEM テクノロジーを利用しています。このサービスは、特に GuardDuty (および一部の Security Hub CSPM) の検出結果に対して効率的な代替手段を提供します。このソリューションは、高度な自動トリアージテクノロジーと人的監視を活用して、ポータルにプロアクティブケースを作成し、同時に対応チームに通知し、調整された修復作業のために当社のセキュリティインシデント対応エンジニアを関与させます。
+ *サードパーティーの調査チーム:* 当社のセキュリティインシデント対応エンジニアは、パートナーや MDR プロバイダーと直接連携します。
# 付録 A: 連絡先
メタデータを事前にセキュリティインシデント対応エンジニアに提供いただくことで、プロファイル作成時間を短縮し、初期段階から当社のトリアージ技術の信頼性を向上させることができます。これは、脅威検出結果の取り込みとお客様の「既知の健全な環境」の作成を開始する際に特定される初期段階の誤検知を減らすために役立ちます。
**IR および SOC 担当者連絡先情報**
| 入力 | IR \$1 SOC 担当者: 役割、氏名、メールアドレス | プライマリエスカレーション連絡先とセカンダリエスカレーション連絡先 | 内部、既知の CIDR 範囲 | 外部、既知の CIDR 範囲 | 追加のクラウドサービスプロバイダー | 作業 AWS リージョン | DNS サーバー IP (Amazon Route 53 Resolver 以外の場合) | VPN \$1 リモートアクセスソリューションと IP アドレス | 重要アプリケーション名 \$1 アカウント番号 | 一般的ではないが広く使用されているポート | EDR \$1 AV \$1 使用される脆弱性管理ツール | IDP \$1 拠点 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | SOC Commander、John Smith、jsmith@example.com | Primary | 10.0.0.0/16 | 5.5.60.0/20 (Azure) | Azure | us-east-1、us-east-2 | 該当なし | Direct Connect、パブリック VIF 116.32.8.7 | Nginx Webserver (例: 重要) \$1 1234567890 | 8080 | CrowdStrike Falcon | Entra、Azure |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
環境のメタデータ情報を送信するには、 [AWS サポートケース](https://repost.aws/knowledge-center/get-aws-technical-support) を作成します。
**メタデータを送信するには**
1. メタデータテーブルに環境情報を入力します。
1. 以下の詳細を含む AWS サポート ケースを作成します。
+ **ケースタイプ:** テクニカル
+ **サービス:** セキュリティインシデント対応サービス
+ **カテゴリ:** その他
1. 完成したメタデータテーブルをケースに添付します。
# RACI マトリックス
次の RACI マトリックスは、セキュリティインシデント対応の実装プロセス全体のロールと責任を定義します。RACI は、責任 (Responsible (R))、説明責任 (Accountable (A))、協議 (Consulted (C))、情報提供 (Informed (I)) の略です。
| アクティビティ | お客様 | AWS アカウントチーム | SIR チーム |
| --- | --- | --- | --- |
| オンボーディング前 |
| 主要な利害関係者を特定する | R | | I |
| 検出結果のソースを検証する | R | C | I |
| [サードパーティー EDR 統合] Security Hub CSPM | R | C | I |
| GuardDuty 検証/ヘルスチェック | C | R | I |
| アカウントスコープを決定する | R | | |
| エスカレーションプロトコルを確立する | R | I | C |
| AWS Organizations を有効にする | R | C | |
| アカウントを AWS Organizations に関連付ける | R | I | |
| 委任管理者/セキュリティツールアカウントを選択する | R | I | |
| オンボーディング |
| メンバーシップの詳細を設定する | R | I | |
| チュートリアル (プロアクティブレスポンスとアラートのトリアージワークフローをセットアップする、サービスリンクロールを管理アカウントにデプロイする、封じ込めアクションを承認する) | R | C | I |
| デプロイ後の設定 |
| 運用上の統合機能を確認する | R | C | I |
| セキュリティインシデント対応の事後対応ケースを送信する | R | | |
| Amazon EventBridge との統合を設定する | R | C | C |
| サードパーティーツールを接続する (Jira、ServiceNow、PagerDuty、Teams など) | R | I | C |
| サービスの詳細とデモ | A | R | C |
**RACI の定義:**
+ **責任 (Responsible (R))** - タスクを完了するために作業を実行する当事者
+ **説明責任 (Accountable (A)** - タスクの正しい完了について最終的に回答できる当事者
+ **協議 (Consulted (C)** - 意見が求められ、双方向のコミュニケーションがある当事者
+ **情報提供 (Informed (I)** - 進捗状況を最新の状態に維持し、一方向のコミュニケーションがある当事者
# メンバーアカウントを選択する
メンバーシップアカウントは、アカウントの詳細の設定、インシデント対応チームの詳細の追加と削除、およびすべてのアクティブなセキュリティイベントと履歴セキュリティイベントの作成と管理に使用できる AWS アカウントです。AWS Security Incident Response メンバーシップアカウントは、Amazon GuardDuty や AWS Security Hub CSPM などのサービス向けに有効化したものと同じアカウントに一致させることをお勧めします。
AWS Organizations を使用した AWS Security Incident Response メンバーシップアカウントの選択には 2 つのオプションがあります。Organizations の管理アカウントまたは Organizations の委任管理者アカウントでメンバーシップを作成できます。
**委任管理者アカウントを使用する:** AWS Security Incident Response 管理タスクとケース管理は、委任管理者アカウント内にあります。他の AWS セキュリティおよびコンプライアンスサービスに設定したのと同じ委任管理者を使用することをお勧めします。12 桁の委任管理者アカウント ID を指定し、そのアカウントにログインして続行します。
**重要**
セットアップの一環として委任管理者アカウントを使用する場合、AWS Security Incident Response は必要なトリアージのサービスリンクロールを AWS Organizations 管理アカウントで自動作成できません。
IAM を使用して、AWS Organizations 管理アカウントにこのロールを作成できます
AWS Organizations 管理アカウントにログインします。
[AWS CloudShell](https://console.aws.amazon.com/cloudshell/home) ウィンドウにアクセスするか、任意の方法を使って CLI 経由でアカウントにアクセスします。
CLI コマンド `aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" --no-cli-pager` を使用する
(オプション) コマンドが機能したことを確認するには、コマンド `aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage` を実行できます
**現在ログインしているアカウントを使用する**: このアカウントを選択すると、現在のアカウントが AWS Security Incident Response メンバーシップの中心となるメンバーシップアカウントとして指定されます。組織内の個人は、このアカウントを通じてサービスにアクセスして、アクティブケースと解決済みケースを作成、アクセス、管理する必要があります。
AWS Security Incident Response を管理するための十分なアクセス許可があることを確認してください。
アクセス許可を追加する具体的な手順については、「[IAM ID のアクセス許可の追加および削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
「[AWS Security Incident Response managed policies](https://docs.aws.amazon.com/security-ir/latest/userguide/aws-managed-policies.html)」を参照してください。
IAM アクセス許可を確認するには、以下の手順に従います。
+ *IAM ポリシーを確認する:* ユーザー、グループ、またはロールに添付されている IAM ポリシーを確認して、必要なアクセス許可が付与されていることを確認します。これを行うには、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) に移動し、`Users` オプションを選択し、特定のユーザーを選択し、概要ページで、添付されたすべてのポリシーのリストを表示できる `Permissions` タブに移動します。各ポリシー行を展開して詳細を表示できます。
+ *アクセス許可をテストする:* アクセス許可を検証するために必要なアクションを実行してみてください。例えば、ケースにアクセスする必要がある場合は、`ListCases` を実行してみてください。必要なアクセス許可がない場合は、エラーメッセージが表示されます。
+ *AWS CLI または SDK を使用する:* AWS Command Line Interface または、任意のプログラミング言語の AWS SDK を使用して、アクセス許可をテストできます。例えば、AWS Command Line Interface を使用している場合、`aws sts get-caller-identity` コマンドを実行して現在のユーザーのアクセス許可を確認できます。
+ *AWS CloudTrail ログを確認する: *[CloudTrail ログを確認](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html) して、実行しようとしているアクションがログに記録されているかどうかを確認します。これにより、アクセス許可の問題を特定できます。
+ *IAM ポリシーシミュレーターを使用する:*[ IAM ポリシーシミュレーター](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)は、IAM ポリシーをテストし、それがアクセス許可に与える影響を確認できるツールです。
**注記**
特定のステップは、AWS サービスや実行しようとしているアクションに応じて異なる場合があります。
# メンバーシップの詳細を設定する
+ メンバーシップとケースを保存する AWS リージョン を選択します。
**警告**
初回メンバーシップ登録後にデフォルトの AWS リージョン を変更することはできません。
+ 完全なメンバーシップカバレッジを AWS Organizations 全体に提供するか、組織単位 (OU) を使用して AWS Organizations の一部に提供するかを選択します。
+ オプションで、このメンバーシップの名前を選択できます。
+ メンバーシップ作成ワークフローの一部としてプライマリ連絡先とセカンダリ連絡先を提供する必要があります。これらの連絡先は、インシデント対応チームの一部として自動的に含まれます。1 つのメンバーシップに対して少なくとも 2 つの連絡先が存在する必要があります。これにより、少なくとも 2 つの連絡先がインシデント対応チームに含まれるようになります。
+ メンバーシップのオプションタグを定義します。タグは、AWS コストを追跡し、リソースを検索するのに役立ちます。
# アカウントを AWS Organizations に関連付ける
セットアップ中に AWS Organizations 全体を関連付けることを選択した場合、組織内のすべてのメンバーアカウントにメンバーシップ資格が付与されます。関連付けられたアカウントは、アカウントが組織に追加または削除されると自動的に更新されます。
セットアップ中に AWS Organizations の一部を関連付けることを選択し、メンバーシップを特定の組織単位 (OU) に制限した場合、選択した OU 内すべてのアカウントにメンバーシップ資格が付与されます。これには、選択した OU のサブ OU の下にあるアカウントが含まれます。関連付けられたアカウントは、アカウントが OU に追加または削除されるたびに自動更新されます。
組織単位に関するベストプラクティスの詳細については、「[Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)」を参照してください。
# プロアクティブレスポンスとアラートのトリアージワークフローを設定する
AWS Security Incident Response は、Amazon GuardDuty と Security Hub CSPM の統合から生成された脅威アラートを監視して調査します。この機能を使用するには、[Amazon GuardDuty を有効にする必要があります](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)。AWS Security Incident Response は、サービス自動化を使用して優先度の低いアラートをトリアージし、チームが最も重要な問題に集中できるようにします。AWS Security Incident Response が Amazon GuardDuty および AWS Security Hub CSPM とどのように連携するかの詳細については、ユーザーガイドの「[検出と分析](https://docs.aws.amazon.com/security-ir/latest/userguide/detect-and-analyze.html)」セクションを参照してください。
オンボーディング問題が発生した場合は、[AWS サポート ケースを作成](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)して追加のサポートを受けてください。AWS アカウント ID やセットアッププロセス中に発生した可能性のあるエラーなどの詳細を必ず含めてください。
**注記**
Amazon GuardDuty 抑制ルール、アラートのトリアージ設定、またはプロアクティブレスポンスのワークフローに関する質問については、**[調査と問い合わせ]** ケースタイプを使用して AWS がサポートするケースを作成し、AWS Security Incident Response チームに相談することができます。詳細については、[AWS でサポートされているケースを作成する](create-an-aws-supported-case.md)を参照してください。
この機能を使用すると、AWS Security Incident Response は対象のすべてのアカウント、および組織でサポートされているアクティブな AWS リージョンの検出結果をモニタリングおよび調査できます。この機能を実現するために、AWS Security Incident Response は AWS Organizations 内の対象のすべてのメンバーアカウントのサービスにリンクされたロールを自動的に作成します。ただし、管理アカウントの場合、モニタリングを有効にするには、サービスにリンクされたロールを手動で作成する必要があります。
*サービスは、サービスにリンクされたロールを管理アカウント内に作成できません。このロールは、[AWS CloudFormation スタックセットを使用](https://docs.aws.amazon.com/security-ir/latest/userguide/working-with-stacksets.html) して管理アカウント内に手動で作成する必要があります。*
# プロアクティブ対応による自動アーカイブを理解する
プロアクティブ対応とアラートのトリアージを有効にすると、AWS Security Incident Response が Amazon GuardDuty と Security Hub CSPM のセキュリティ検出結果を自動的にモニタリングしてトリアージします。この自動トリアージワークフローの一環として、検出結果は次の基準に基づいて自動的にアーカイブされます:
**自動アーカイブの動作:**
+ **無害な検出結果:** 自動トリアージプロセスによって検出結果が無害 (真のセキュリティ脅威ではない) であると判断された場合、AWS Security Incident Response は検出結果を Amazon GuardDuty に自動的にアーカイブし、抑制ルールを作成して、今後同様の検出結果がアラートを生成しないようにします。
+ **抑制ルール:** このサービスは、環境の既知の正常なパターン (予想される IP アドレス、IAM エンティティ、通常の運用動作など) に一致する検出結果に対し、Amazon GuardDuty と Security Hub CSPM の両方で抑制ルールと自動アーカイブルールを作成します。
+ **アラートボリュームの削減:** SIEM テクノロジーを使用している組織では、サービスが組織の環境を学習し、無害な検出結果を自動的にアーカイブしていくにつれて、Amazon GuardDuty の検出結果ボリュームが大幅に減少します。これにより、AWS Security Incident Response のサービスと SIEM の両方の効率が向上します。
**アーカイブされた検出結果の表示:**
自動的にアーカイブされた検出結果と、AWS Security Incident Response によって作成された抑制ルールを確認できます:
1. [Amazon GuardDuty コンソール] に移動する
1. [**検出結果**] を選択する
1. 検出結果フィルターから [**アーカイブ済み**] を選択する
1. 各ルールの横にある下矢印を選択して、抑制ルールを確認する
**重要な考慮事項:**
+ アーカイブされた検出結果は 90 日間 Amazon GuardDuty に保持され、その期間中いつでも表示することができます
+ 抑制ルールは、Amazon GuardDuty コンソールからいつでも変更または削除できます
+ 自動トリアージプロセスは、継続的に環境に適応し、時間の経過とともに精度を向上させ、誤検出を削減します
**封じ込め:** セキュリティインシデントが発生した場合、AWS Security Incident Response は、侵害されたホストの分離や認証情報のローテーションなど、封じ込めアクションを実行して、影響を迅速に軽減できます。Security Incident Response では、封じ込め機能がデフォルトで有効化されていません。これらの封じ込めアクションを実行するには、まずサービスに必要なアクセス許可を付与する必要があります。これは、必要なロールを作成する [AWS CloudFormation StackSet](https://docs.aws.amazon.com/security-ir/latest/userguide/working-with-stacksets.html) をデプロイすることで実行できます。