# 自動デプロイ - StackSets
**注記**
StackSets を使用してデプロイすることをお勧めします。ただし、単一アカウントのデプロイ、テストまたは評価の目的の場合は、[スタックのデプロイ](deployment.md)オプションを検討してください。
ソリューションを開始する前に、このガイドに記載されているアーキテクチャ、ソリューションコンポーネント、セキュリティ、設計に関する考慮事項を確認してください。このセクションのステップバイステップの手順に従ってソリューションを設定し、AWS Organizations 内にデプロイします。
**デプロイ時間:** StackSets パラメータによって、1 つのアカウントごとに約 30 分。
## 前提条件
[AWS Organizations](https://aws.amazon.com/organizations/) は、マルチアカウントの AWS 環境とリソースを一元的に管理するのに役立ちます。StackSets は AWS Organizations で最適に機能します。
以前に、このソリューションの v1.3.x 以前をデプロイしたことがある場合は、既存のソリューションをアンインストールする必要があります。詳細については、「[ソリューションを更新する](update-the-solution.md)」を参照してください。
このソリューションをデプロイする前に、AWS Security Hub のデプロイを確認してください。
+ AWS Organizations には、委任された Security Hub の管理者アカウントが必要です。
+ Security Hub は、リージョン全体の検出結果を集約するように設定する必要があります。詳細については、AWS Security Hub ユーザーガイドの「[リージョン間の検出結果を集約する](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html)」を参照してください。
+ AWS を使用するリージョンごとに、組織の [Security Hub をアクティブ化](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-prereq-config.html)する必要があります。
この手順では、AWS Organizations を使用する複数のアカウントがあり、AWS Organizations の管理者アカウントと AWS Security Hub の管理者アカウントを委任していることを前提としています。
**このソリューションは、[AWS Security Hub および AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-are-securityhub-services.html) の両方と連動することに注意してください。**
## デプロイの概要
**注記**
このソリューションの StackSets のデプロイでは、サービスマネージドとセルフマネージドの StackSets を組み合わせて使用しています。セルフマネージド StackSets では、サービスマネージド StackSets ではまだサポートされていないネストされた StackSets を使用しているため、今のところは使用する必要があります。
AWS Organizations の[委任された管理者アカウント](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html)から StackSets をデプロイします。
**プランニング**
次のフォームを使用して、StackSets のデプロイを支援することができます。データを準備し、デプロイ中に値をコピーして貼り付けます。
```
AWS Organizations admin account ID: _______________
Security Hub admin account ID: _______________
CloudTrail Logs Group: ______________________________
Member account IDs (comma-separated list):
___________________,
___________________,
___________________,
___________________,
___________________
AWS Organizations OUs (comma-separated list):
___________________,
___________________,
___________________,
___________________,
___________________
```
[(オプション) ステップ 0: チケット作成統合スタックをデプロイする](#step-0-stackset)
+ チケット作成機能を使用する場合は、まずチケット作成統合スタックを Security Hub 管理者アカウントにデプロイします。
+ このスタックから Lambda 関数名をコピーし、管理者スタックへの入力として指定します (ステップ 1 を参照)。
[ステップ 1: 委任された Security Hub の管理者アカウントで管理者スタックを起動する](#step-1-stackset)
+ セルフマネージド StackSets を使用して、AWS Security Hub の管理者と同じリージョンの AWS Security Hub の管理者アカウントで `automated-security-response-admin.template` AWS CloudFormation テンプレートを起動します。このテンプレートはネストされたスタックを使用します。
+ インストールするセキュリティ標準を選択します。デフォルトでは、SC のみが選択されます (推奨)。
+ 使用する既存のオーケストレーターロググループを選択します。前回のインストールで `SO0111-ASR- Orchestrator` がすでに存在する場合は、`Yes` を選択します。
+ ソリューションのウェブ UI を有効にするかどうかを選択します。この機能を有効にする場合は、管理者ロールを割り当てる E メールアドレスも入力する必要があります。
+ ソリューションの操作の正常性に関連する CloudWatch メトリクスを収集するための設定を選択します。
セルフマネージド StackSets の詳細については、「*AWS CloudFormation ユーザーガイド*」の「[セルフマネージドのアクセス許可を付与する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html)」を参照してください。
[ステップ 2: AWS Security Hub のメンバーアカウントごとに修復ロールをインストールする](#step-2-stackset)
ステップ 2 のテンプレートはステップ 1 で作成された IAM ロールを参照するため、ステップ 1 でデプロイが完了するまで待ちます。
+ サービスマネージド StackSet を使用して、AWS Organizations のアカウントごとに 1 つのリージョンで `automated-security-response-member-roles.template` AWS CloudFormation テンプレートを起動します。
+ 新しいアカウントが組織に加わったときに、このテンプレートを自動的にインストールすることを選択します。
+ AWS Security Hub の管理者アカウントのアカウント ID を入力します。
+ 同じアカウントで以前のデプロイまたは同時デプロイとリソース名が競合しないようにするために使用する `namespace` の値を入力します。最大 9 文字の小文字の英数字の文字列を入力します。
[ステップ 3: 各 AWS Security Hub メンバーアカウントとリージョンでメンバースタックを起動する](#step-3-stackset)
+ セルフマネージド StackSets を使用して、同じ AWS Security Hub の管理者が管理する AWS Organizations のすべてのアカウントに AWS リソースがあるすべての AWS リージョンで、`automated-security-response-member.template` テンプレートを起動します。
**注記**
サービスマネージド StackSets がネストされたスタックがサポートされるまでは、組織に加わる新しいアカウントに対してこの手順を実行する必要があります。
+ インストールするセキュリティ標準プレイブックを選択します。
+ CloudTrail ロググループの名前を指定します (一部の修復で使用されます)。
+ AWS Security Hub の管理者アカウントのアカウント ID を入力します。
+ 同じアカウントで以前のデプロイまたは同時デプロイとリソース名が競合しないようにするために使用する `namespace` の値を入力します。最大 9 文字の小文字の英数字の文字列を入力します。これは、メンバーロールスタックに選択した `namespace` の値と一致する必要があります。また、名前空間の値はメンバーアカウントごとに一意である必要はありません。
## (オプション) ステップ 0: チケットシステム統合スタックを起動する
1. チケット機能を使用する場合は、まずそれぞれの統合スタックを起動します。
1. Jira または ServiceNow 用に提供されている統合スタックを選択するか、独自のカスタム統合を実装するためのブループリントとして使用します。
**Jira スタックをデプロイするには**:
1. スタック名を入力します。
1. Jira インスタンスに URI を指定します。
1. チケットを送信する Jira プロジェクトのプロジェクトキーを指定します。
1. Jira `Username` と `Password` を保持する新しいキーと値のシークレットを Secrets Manager に作成します。
**注記**
ユーザー名を `Username` として、API キーを `Password` として指定することで、パスワードの代わりに Jira API キーを使用することを選択できます。
1. このシークレットの ARN をスタックへの入力として追加します。
**スタック名、Jira プロジェクト情報、Jira API 認証情報を指定します。**
![\[チケットシステム統合スタック jira\]](http://docs.aws.amazon.com/ja_jp/solutions/latest/automated-security-response-on-aws/images/ticket-system-integration-stack-jira.png)
**Jira フィールド設定**:
Jira スタックをデプロイした後、Lambda 関数で `JIRA_FIELDS_MAPPING` 環境変数を設定することで、Jira チケットフィールドをカスタマイズできます。この JSON 文字列は、デフォルトの Jira チケットフィールドを上書きし、Jira API フィールド構造に従う必要があります。
`JIRA_FIELDS_MAPPING` が空の場合、またはフィールドが指定されていない場合のデフォルト値:
+ **priority**: `{"id": "3"}` (中優先度)
+ **issuetype**: `{"id": "10006"}` (タスク)
+ **accountId**: `GET /rest/api/2/myself` API エンドポイントを使用して自動的に取得
カスタムフィールドを使用した設定例:
```
{
"reporter": {"accountId": "123456:494dcbff-1b80-482c-a89d-56ae81c145a4"},
"priority": {"id": "1"},
"issuetype": {"id": "10006"},
"assignee": {"accountId": "123456:another-user-id"},
"customfield_10001": "custom value"
}
```
一般的な Jira フィールド ID:
+ **優先 ID**: 1 (最高)、2 (高)、3 (中)、4 (低)、5 (最低)
+ **問題タイプ ID**: Jira プロジェクトによって異なります (タスクの場合は 10006 など)
+ **アカウント ID**: 形式 `123456:494dcbff-1b80-482c-a89d-56ae81c145a4`
Jira フィールド ID とアカウント ID は、Jira REST API を使用して確認できます。
+ アカウント ID の `GET /rest/api/2/myself`
+ 優先 ID の `GET /rest/api/2/priority`
+ 問題タイプ ID の `GET /rest/api/2/project/{projectKey}`
詳細については、「[Jira REST API v2 問題の POST 形式](https://developer.atlassian.com/server/jira/platform/rest/v10000/api-group-issue/#api-api-2-issue-post)」を参照してください。
**ServiceNow スタックをデプロイするには**:
1. スタック名を入力します。
1. ServiceNow インスタンスの URI を指定します。
1. ServiceNow テーブル名を指定します。
1. 書き込み先のテーブルを変更するアクセス許可を持つ API キーを ServiceNow に作成します。
1. キー `API_Key` を使用して Secrets Manager でシークレットを作成し、そのシークレットの ARN をスタックへの入力として提供します。
**スタック名、ServiceNow プロジェクト情報、ServiceNow API 認証情報を指定します。**
![\[チケットシステム統合スタック servicenow\]](http://docs.aws.amazon.com/ja_jp/solutions/latest/automated-security-response-on-aws/images/ticket-system-integration-stack-servicenow.png)
**カスタム統合スタックを作成するには**: ソリューションオーケストレーター Step Functions が修復ごとに呼び出すことができる Lambda 関数を含めます。Lambda 関数は、Step Functions から提供された入力を受け取り、チケット発行システムの要件に従ってペイロードを構築し、システムにチケットの作成をリクエストする必要があります。
## ステップ 1: 委任された Security Hub 管理者アカウントで管理者スタックを起動する
1. Security Hub の管理者アカウントで、[管理者スタック](https://solutions-reference.s3.amazonaws.com/automated-security-response-on-aws/latest/automated-security-response-admin.template) (`automated-security-response-admin.template`) をデプロイします。通常、1 つのリージョンの組織ごとに 1 つです。このスタックはネストされたスタックを使用するため、このテンプレートをセルフマネージド StackSet としてデプロイする必要があります。
### パラメータ
| パラメータ | デフォルト | 説明 |
| --- | --- | --- |
| **Load SC Admin Stack** | `yes` | SC コントロールの自動修復のために管理コンポーネントをインストールするかどうかを指定します。 |
| **Load AFSBP Admin Stack** | `no` | FSBP コントロールの自動修復のために管理コンポーネントをインストールするかどうかを指定します。 |
| **Load CIS120 Admin Stack** | `no` | CIS120 コントロールの自動修復のために管理コンポーネントをインストールするかどうかを指定します。 |
| **Load CIS140 Admin Stack** | `no` | CIS140 コントロールの自動修復のために管理コンポーネントをインストールするかどうかを指定します。 |
| **Load CIS300 Admin Stack** | `no` | CIS300 コントロールの自動修復のために管理コンポーネントをインストールするかどうかを指定します。 |
| **Load PC1321 Admin Stack** | `no` | PC1321 コントロールの自動修復のために管理コンポーネントをインストールするかどうかを指定します。 |
| **Load NIST Admin Stack** | `no` | NIST コントロールの自動修復のために管理コンポーネントをインストールするかどうかを指定します。 |
| **Reuse Orchestrator Log Group** | `no` | 既存の `SO0111-ASR-Orchestrator` CloudWatch Logs グループを再利用するかどうかを選択します。これにより、以前のバージョンのログデータを失うことなく、再インストールとアップグレードを簡素化できます。このアカウントに以前のデプロイからの `Orchestrator Log Group` がまだ存在する場合は、既存の `Orchestrator Log Group` を再利用し、`yes` を選択します。それ以外の場合は、`no` を選択します。v2.3.0 より前のバージョンからスタックの更新を実行する場合は、`no` を選択します。 |
| **ShouldDeployWebUI** | `yes` | API Gateway、Lambda 関数、CloudFront ディストリビューションなどのウェブ UI コンポーネントをデプロイします。検出結果と修復ステータスを表示するためのウェブベースのユーザーインターフェイスを有効にするには、[はい] を選択します。この機能を無効にした場合でも、自動修復を設定し、Security Hub CSPM カスタムアクションを使用してオンデマンドで修復を実行できます。 |
| **AdminUserEmail** | *(オプション入力)* | 管理者ユーザーの E メールアドレス。このユーザーは、ASR ウェブ UI への完全な管理者アクセスを持ちます。ウェブ UI が有効になっている場合に**のみ**必要です。 |
| **Use CloudWatch Metrics** | `yes` | ソリューションをモニタリングするために CloudWatch メトリクスを有効にするかどうかを指定します。これにより、メトリクスを表示するための CloudWatch ダッシュボードが作成されます。 |
| **Use CloudWatch Metrics Alarms** | `yes` | ソリューションの CloudWatch メトリクスアラームを有効にするかどうかを指定します。これにより、ソリューションによって収集された特定のメトリクスのアラームが作成されます。 |
| **RemediationFailureAlarmThreshold** | `5` | コントロール ID あたりの修復失敗の割合のしきい値を指定します。例えば、`5` と入力すると、コントロール ID が特定の日に 5% を超える修復に失敗すると、アラームが表示されます。 このパラメータは、アラームが作成された場合にのみ機能します (「**CloudWatch メトリクスアラームを使用する**」パラメータを参照)。 |
| **EnableEnhancedCloudWatchMetrics** | `no` | `yes` の場合、追加の CloudWatch メトリクスを作成し、CloudWatch ダッシュボードで、CloudWatch アラームとして、すべてのコントロール ID を個別に追跡します。 これに伴う追加コストについては、「[コスト](cost.md#additional-cost-enhanced-metrics)」セクションを参照してください。 |
| **TicketGenFunctionName** | *(オプション入力)* | オプション。チケット発行システムを統合しない場合は、空白のままにします。それ以外の場合は、[ステップ 0](deployment.md#step-0) のスタック出力から Lambda 関数名を指定します。例: `SO0111-ASR-ServiceNow-TicketGenerator`。 |
**StackSet オプションを設定する**
![\[stackset オプションを設定する\]](http://docs.aws.amazon.com/ja_jp/solutions/latest/automated-security-response-on-aws/images/configre-stackset-options.png)
1. **[Account numbers]** パラメータに、AWS Security Hub の管理者アカウントのアカウント ID を入力します。
1. **[Specify regions]** パラメータで、Security Hub の管理者がオンになっているリージョンのみを選択します。このステップが完了するまで待ってから、ステップ 2 に進みます。
## ステップ 2: AWS Security Hub のメンバーアカウントごとに修復ロールをインストールする
サービスマネージド StackSets を使用して、[メンバーロールテンプレート](https://solutions-reference.s3.amazonaws.com/automated-security-response-on-aws/latest/automated-security-response-member-roles.template)、`automated-security-response-member-roles.template` をデプロイします。この StackSet は、メンバーアカウントごとに 1 つのリージョンにデプロイする必要があります。ASR オーケストレーターステップ関数からのクロスアカウント API コールを許可するグローバルロールを定義します。
### パラメータ
| パラメータ | デフォルト | 説明 |
| --- | --- | --- |
| **名前空間** | *<入力必須>* | 最大 9 文字の小文字の英数字の文字列を入力します。修復 IAM ロール名のサフィックスとして追加する一意の名前空間。メンバーロールとメンバースタックに、同じ名前空間を使用する必要があります。この文字列はソリューションのデプロイごとに一意である必要がありますが、スタックの更新時に変更する必要はありません。名前空間の値は、メンバーアカウントごとに一意である必要は**ありません**。 |
| **Sec Hub アカウント管理者** | *<入力必須>* | AWS Security Hub 管理者アカウントの 12 桁のアカウント ID を入力します。この値は、管理者アカウントのソリューションロールにアクセス許可を付与します。 |
1. 組織のポリシーに従って、組織全体 (通常) または組織単位にデプロイします。
1. AWS Organizations の新しいアカウントにこれらのアクセス許可が付与されるように、自動デプロイをオンにします。
1. **[Specify regions]** パラメータで、1 つのリージョンを選択します。IAM ロールはグローバルです。この StackSets がデプロイされている間に、ステップ 3 に進むことができます。
**StackSet の詳細を指定する**
![\[stackset の詳細を指定する\]](http://docs.aws.amazon.com/ja_jp/solutions/latest/automated-security-response-on-aws/images/specify-stackset-details.png)
## ステップ 3: 各 AWS Security Hub メンバーアカウントとリージョンでメンバースタックを起動する
[メンバースタック](https://solutions-reference.s3.amazonaws.com/automated-security-response-on-aws/latest/automated-security-response-member.template)はネストされたスタックを使用するため、セルフマネージド StackSet としてデプロイする必要があります。AWS Organizations の新しいアカウントへの自動デプロイはサポートされていません。
### パラメータ
| パラメータ | デフォルト | 説明 |
| --- | --- | --- |
| **Provide the name of the LogGroup to be used to create Metric Filters and Alarms** | *<入力必須>* | CloudTrail が API コールをログに記録する CloudWatch Logs グループの名前を指定します。これは CIS 3.1～3.14 修復に使用されます。 |
| **Load SC Member Stack** | `yes` | SC コントロールの自動修復のためにメンバーコンポーネントをインストールするかどうかを指定します。 |
| **Load AFSBP Member Stack** | `no` | FSBP コントロールの自動修復のためにメンバーコンポーネントをインストールするかどうかを指定します。 |
| **Load CIS120 Member Stack** | `no` | CIS120 コントロールの自動修復のためにメンバーコンポーネントをインストールするかどうかを指定します。 |
| **Load CIS140 Member Stack** | `no` | CIS140 コントロールの自動修復のためにメンバーコンポーネントをインストールするかどうかを指定します。 |
| **Load CIS300 Member Stack** | `no` | CIS300 コントロールの自動修復のためにメンバーコンポーネントをインストールするかどうかを指定します。 |
| **Load PC1321 Member Stack** | `no` | PC1321 コントロールの自動修復のためにメンバーコンポーネントをインストールするかどうかを指定します。 |
| **NIST メンバースタックのロード** | `no` | NIST コントロールの自動修復のためにメンバーコンポーネントをインストールするかどうかを指定します。 |
| **Create S3 Bucket For Redshift Audit Logging** | `no` | FSBP RedShift.4 修復のために S3 バケットを作成する場合は、`yes` を選択します。S3 バケットと修復の詳細については、「*AWS Security Hub ユーザーガイド*」の「[Redshift.4 修復](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-redshift-4)」を参照してください。 |
| **Sec Hub Admin Account** | *<入力必須>* | AWS Security Hub 管理者アカウントの 12 桁のアカウント ID を入力します。 |
| **名前空間** | *<入力必須>* | 最大 9 文字の小文字の英数字の文字列を入力します。この文字列は、IAM ロール名とアクションログ S3 バケットの一部になります。メンバースタックデプロイとメンバーロールスタックデプロイには同じ値を使用します。文字列はソリューションのデプロイごとに一意である必要がありますが、スタックの更新時に変更する必要はありません。 |
| **EnableCloudTrailForASRActionLog** | `no` | CloudWatch ダッシュボードのソリューションによって実施される管理イベントをモニタリングする場合は、`yes` を選択します。このソリューションは、`yes` を選択した各メンバーアカウントに CloudTrail 証跡を作成します。この機能を有効にするには、ソリューションを AWS Organization にデプロイする必要があります。**さらに、この機能は同じアカウント内の 1 つのリージョンでのみ有効にできます。**これに伴う追加コストについては、「[コスト](cost.md#additional-cost-action-log)」セクションを参照してください。 |
**Accounts**:
![\[アカウント\]](http://docs.aws.amazon.com/ja_jp/solutions/latest/automated-security-response-on-aws/images/accounts.png)
**Deployment locations**: アカウント番号または組織単位のリストを指定できます。
**Specify regions**: 検出結果を修復するすべてのリージョンを選択します。デプロイオプションは、アカウントとリージョンの数に応じて調整できます。リージョンの同時実行は並列にすることができます。