翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ワークロードの例: Amazon EC2 で稼働する COTS ソフトウェア
<a name="cots-software"></a>

このワークロードは、[テーマ 3: 自動化によるミュータブルなインフラストラクチャの管理](theme-3.md) の例を示すものです。

Amazon EC2 で稼働するワークロードは、 AWS マネジメントコンソールを使用して手動で構築したものです。開発者は、EC2 インスタンスにログインしてソフトウェアを更新することで、システムを手動で更新しています。

このワークロードに対し、クラウドチームとアプリケーションチームは、Essential Eight 戦略に対応できるよう、以下のアクションを実行します。

*アプリケーション制御*
+ クラウドチームは、エージェント (SSM AWS Systems Manager エージェント）、CloudWatch エージェント、SELinux をインストールして設定するように、一元化された AMI パイプラインを設定します。また、作成した AMI を、組織内のすべてのアカウントで共有します。
+ クラウドチームは AWS Config ルールを使用して、実行中のすべての [EC2 インスタンスが Systems Manager によって管理](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html)され、[SSM エージェント、CloudWatch エージェント、SELinux がインストールされている](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-applications-required.html)ことを確認します。
+ クラウドチームは、Amazon CloudWatch Logs の出力を、Amazon OpenSearch Service 上で稼働する一元化されたセキュリティ情報およびイベント管理 (SIEM) ソリューションに送信します。
+ アプリケーションチームは、、GuardDuty AWS Config、Amazon Inspector からの検出結果を検査および管理するためのメカニズムを実装します。クラウドチームは、アプリケーションチームが見逃した検出結果を特定する独自の仕組みを実装します。脆弱性管理プログラムを作成して検出結果に対処する方法について、詳細なガイダンスを確認したい場合は、「[AWSでのスケーラブルな脆弱性管理プログラムの構築](https://docs.aws.amazon.com/prescriptive-guidance/latest/vulnerability-management/introduction.html)」を参照してください。

*アプリケーションへのパッチ適用*
+ アプリケーションチームは、Amazon Inspector の検出結果に基づいてインスタンスにパッチを適用します。
+ クラウドチームは、ベース AMI にパッチを適用します。その AMI が変更された場合、アプリケーションチームはアラートを受け取ります。
+ アプリケーションチームは、ワークロードに必要なポートでのみトラフィックが許可されるように[セキュリティグループルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)を設定し、EC2 インスタンスへの直接アクセスを制限します。
+ アプリケーションチームは、個々のインスタンスにログインせず、[Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) を使用してインスタンスにパッチを適用します。
+ EC2 インスタンスグループで任意のコマンドを実行するために、アプリケーションチームは、[Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) を使用します。
+ まれに、アプリケーションチームがインスタンスに直接アクセスしなければならない場合は、[Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) を使用します。このアクセスアプローチでは、フェデレーティッド ID を使用し、監査目的でセッションアクティビティを記録します。

*管理者権限の制限*
+ アプリケーションチームは、ワークロードに必要なポートでのみトラフィックが許可されるように[セキュリティグループルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)を設定します。これにより、Amazon EC2 インスタンスへの直接アクセスを制限し、Session Manager を介した EC2 インスタンスへのアクセスをユーザーに求めます。
+ 一元化した、クラウドチームの ID フェデレーションを活用して、認証情報のローテーションと一元的なログ記録を行います。
+ CloudTrail 証跡と CloudWatch フィルターを作成します。
+ CodePipeline によるデプロイと CloudFormation スタック削除に Amazon SNS アラートを設定します。

*オペレーティングシステムへのパッチ適用*
+ クラウドチームは、ベース AMI にパッチを適用します。その AMI が変更された場合、アプリケーションチームはアラートを受け取ります。アプリケーションチームは、この AMI を使用して新しいインスタンスをデプロイし、Systems Manager の機能である[ステートマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)を使用して必要なソフトウェアをインストールします。
+ アプリケーションチームは、個々のインスタンスにログインせず、Patch Manager を使用してインスタンスにパッチを適用します。
+ EC2 インスタンスグループで任意のコマンドを実行するために、アプリケーションチームは、Run Command を使用します。
+ まれに、アプリケーションチームが直接アクセスしなければならない場合は、Session Manager を使用します。

*多要素認証*
+ 一元化された ID フェデレーションソリューション (「[コアアーキテクチャ](scenario.md#core-architecture)」セクションを参照) を活用します。このソリューションによって、MFA の適用や認証のログ記録を行い、疑わしい MFA イベントが発生した際は、アラートを生成するかそれらに自動的に対応します。

*定期バックアップ*
+ アプリケーションチームは、EC2 インスタンスと Amazon Elastic Block Store (Amazon EBS) ボリュームの AWS Backup プランを作成します。
+ アプリケーションチームは、バックアップからの復元を毎月手動で実行する仕組みを実装します。