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

# ワークロードの例: コンテナ化されたウェブサービス
<a name="containerised-web-service"></a>

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

このウェブサービスは Amazon ECS 上で稼働し、Amazon RDS のデータベースが使用されています。アプリケーションチームは CloudFormation 、 テンプレートでこれらのリソースを定義します。コンテナは EC2 Image Builder で構築し、Amazon ECR に保存します。アプリケーションチームは、 を通じてシステムに変更をデプロイします AWS CodePipeline。このパイプラインの使用は、アプリケーションチームに制限されています。このチームでコードリポジトリにプルリクエストを行う場合は、[2 人制](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/best-practice-5.2---implement-least-privilege-policies-for-source-and-downstream-systems..html)が適用されます。

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

*アプリケーション制御*
+ [Amazon Inspector で Amazon ECR コンテナイメージのスキャン](https://docs.aws.amazon.com/inspector/latest/user/scanning-ecr.html)を有効にします。
+ [ファイルアクセスポリシーデーモン (fapolicyd)](https://github.com/linux-application-whitelisting/fapolicyd/blob/main/README.md) セキュリティツールを EC2 Image Builder パイプラインに構築します。詳細については、ACSC ウェブサイトの「[Implementing Application Control](https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening-and-administration/system-hardening/implementing-application-control)」を参照してください。
+ ログの出力が Amazon CloudWatch Logs に記録されるように、Amazon ECS タスク定義を設定します。
+ Amazon Inspector の検出結果を検査および管理する仕組みを実装します。

*アプリケーションへのパッチ適用*
+ Amazon Inspector で Amazon ECR コンテナイメージのスキャンを有効にし、非推奨ライブラリや脆弱なライブラリにアラートを設定します。
+ Amazon Inspector の検出結果への対応を自動化します。新しいイベントが検出されると、Amazon EventBridge がトリガーとなり、ターゲットのデプロイパイプライン、つまり、CodePipeline が開始されます。
+ アプリケーションチームは、 AWS Config がアセット検出の AWS リソースを追跡できるようにします。

*管理者権限の制限*
+ アプリケーションチームでは、デプロイパイプラインの承認ルールによって、本番環境にデプロイする際のアクセスを既に制限しています。
+ 一元化した、クラウドチームの ID フェデレーションを活用して、認証情報のローテーションと一元的なログ記録を行います。
+ CloudTrail 証跡と CloudWatch フィルターを作成します。
+ CodePipeline によるデプロイと CloudFormation スタック削除に Amazon SNS アラートを設定します。

*オペレーティングシステムへのパッチ適用*
+ Amazon Inspector で Amazon ECR コンテナイメージのスキャンを有効にし、OS のパッチ更新にアラートを設定します。
+ Amazon Inspector の検出結果への対応を自動化します。新しいイベントが検出されると、EventBridge がトリガーとなり、ターゲットのデプロイパイプライン、つまり、CodePipeline が開始されます。
+ Amazon RDS イベント通知をサブスクライブして、更新情報が通知されるようにし、こうした更新を手動で適用するか、Amazon RDS で自動適用するかについて、ビジネス所有者と共に、リスクに基づく判断を下します。
+ メンテナンスイベントの影響を軽減するために、Amazon RDS インスタンスをマルチアベイラビリティーゾーンクラスターとして設定します。

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

*定期バックアップ*
+ アプリケーションチームは、Amazon RDS クラスターのデータのバックアップを自動化 AWS Backup するように を設定します。
+ CloudFormation テンプレートをコードリポジトリに保存します。
+ アプリケーションチームは、[別のリージョンでワークロードのコピーを作成し、自動テストを実行する自動パイプラインを開発します](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (AWS ブログ記事）。このパイプラインでは、自動テストの実行後、スタックを破棄します。このパイプラインを 1 か月に 1 回自動的に実行し、復旧手順の有効性を検証します。