# 対応の自動化オプション
<a name="options-for-automating-response"></a>

 エータープライズ実装と組織構造の間でバランスを取ることが重要です。*図 4* は、AWS に実装した自動対応オプションごとに技術属性の違いをレーダーチャートで示しています。チャートでは、自動対応オプションの技術属性がチャートの中心から離れるほど、その技術属性は強くなります。例えば、AWS Lambda はスピードで優り、より少ない技術スキルセットを必要とします。AWS Fargate は柔軟性で優り、より少ないメンテナンスと技術スキルセットを必要とします。*表 1* に、これらのオートメーションオプションの概要と、オプションごとの技術属性の要約を示します。

![自動対応アプローチ間の技術属性の違い](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-security-incident-response-guide/images/image6.png)


* 図 4: 自動対応アプローチ間の技術属性の違い *

* 表 1: 自動対応のオプション *


|  AWS のサービスまたは機能  |  説明  |  属性の要約\*  | 
| --- | --- | --- | 
|  AWS Lambda  |  AWS Lambda のみを使用するシステム。組織のエンタープライズ言語を使用します。  |  スピード <br /> 柔軟性 <br /> メンテナンス <br /> スキルセット  | 
|  AWS Step Functions  |  AWS Step Functions、Lambda、SSM Agent を使用するシステム。  |  スピード <br /> 柔軟性 <br /> メンテナンス <br /> スキルセット  | 
|  AWS Config ルール による自動修復  |  AWS Config ルール と自動修復のセット。環境を評価し、承認済みの仕様内に環境を戻します。  |  メンテナンスとスキルセット <br /> スピードと柔軟性  | 
|  [SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)  |  オートメーションルールとドキュメントのセット。環境と内部システムの多くの部分をレビューし、修正を行います。  |  メンテナンスとスキルセット <br /> スピード <br /> 柔軟性  | 
|  AWS Fargate  |  AWS Fargate システム。オープンソースのステップ関数コードと Amazon CloudWatch や他のシステムからのイベントを使用して、検出と修復を促進します。  |  柔軟性 <br /> スピード <br /> メンテナンスとスキルセット  | 
|  Amazon EC2  |  フルインスタンスで実行するシステム。AWS Fargate オプションと似ています。  |  柔軟性 <br /> スピード <br /> メンテナンス <br /> スキルセット  | 

 \* 属性は、サービスまたは機能ごとに降順で示しています。例えば、AWS Lambda はスピードで優り、より少ない技術スキルセットを必要とします。AWS Fargate は柔軟性で優り、より少ないメンテナンスと技術スキルセットを必要とします。 

 これらのオートメーションオプションを AWS 環境で検討する場合は、一元化とスキャン期間 (1 秒あたりのイベント数 (EPS)) も考慮する必要があります。 

 *一元化*とは、中央アカウントを通じて組織のすべての検出と修復を推進することです。このアプローチは、すぐに使用できる最良の選択肢と思われ、これが現在のベストプラクティスになっています。ただし、状況によっては、このアプローチから逸脱する必要があります。どのような場合に逸脱するかは、下位アカウントの処理方法によって異なります。まず、[AWS Organizations のマルチアカウントフレームワーク](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/)または [AWS Control Tower](https://aws.amazon.com/controltower/) でセキュリティツールアカウントのアプローチを活用することから開始することをお勧めします。 

* 表 2: 一元化の長所と短所*


|   |  一元化  |  分散化  | 
| --- | --- | --- | 
|  長所  |  シンプルな設定管理 <br /> 対応をキャンセルまたは変更できない  |  シンプルなアーキテクチャ <br /> より高速な初期設定  | 
|  短所  |  アーキテクチャが複雑化する <br /> アカウントとリソースのオンボーディング/オフボーディング  |  管理すべきリソースが増える <br /> ソフトウェアベースラインの維持が困難  | 

 これらの実装間のコストを比較すると、エンタープライズとして最適なオプションを決定する際に役立つ場合があります。1 秒あたりのイベント数 (EPS) は、コストを最適に見積もるために役立つメトリクスです。最終的には、集中型または分散型のアプローチを使用する方がはるかに簡単で安価になる可能性がありますが、お客様がそのコストをお客様のアカウントでどのように具体的に評価するかは、AWS では確認できません。これらのイベントを中央アカウントに送信して対応する場合は、EPS を必ず考慮してください。EPS の数が多いほど、これらのイベントを一元化されたアカウントに送信するコストが高くなります。