翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# で Essential Eight 成熟度を達成するための示唆的なケーススタディ AWS
この章では、 AWSで Essential Eight の成熟度到達を目指す政府機関の示唆的な導入事例について説明します。
**Topics**
+ [シナリオおよびアーキテクチャの概要](scenario.md)
+ [ワークロードの例: サーバーレスデータレイク](serverless-data-lake.md)
+ [ワークロードの例: コンテナ化されたウェブサービス](containerised-web-service.md)
+ [ワークロードの例: Amazon EC2 で稼働する COTS ソフトウェア](cots-software.md)
# シナリオおよびアーキテクチャの概要
この政府機関は、 AWS クラウドで 3 つのワークロードを運用しています。
+ ストレージと抽出、変換、ロード (ETL) オペレーション AWS Lambda に Amazon Simple Storage Service (Amazon S3) を使用する[サーバーレスデータレイク](serverless-data-lake.md)
+ [コンテナ化されたウェブサービス](containerised-web-service.md): Amazon Elastic Container Service (Amazon ECS) で稼働させ、Amazon Relational Database Service (Amazon RDS) のデータベースを使用している
+ [Commercial Off-The-Shelf (COTS) ソフトウェア](cots-software.md): Amazon EC2 で稼働させている
*クラウドチームは*、組織の一元化されたプラットフォームを提供し、 AWS 環境のコアサービスを実行します。クラウドチームは、 AWS 環境にコアサービスを提供します。各ワークロードは、独立した*アプリケーションチーム* (*開発チーム*または*デリバリーチーム*とも呼ばれる) が所有しています。
## コアアーキテクチャ
クラウドチームでは、 AWS クラウドで以下の機能を構築済みです。
+ ID Microsoft フェデレーションは、Entra ID (以前の *Azure Active Directory*) インスタンス AWS IAM アイデンティティセンター にリンクします。フェデレーションでは、MFA、ユーザーアカウントの自動有効期限、および AWS Identity and Access Management (IAM) ロールを介した有効期間の短い認証情報の使用が適用されます。
+ 一元化され、EC2 Image Builder を使用する AMI パイプラインで、OS とコアアプリケーションにパッチを適用しています。
+ Amazon Inspector を利用して、脆弱性を特定しており、セキュリティ関連の検出結果はすべて Amazon GuardDuty に送信し、一元管理しています。
+ アプリケーション制御ルールの更新、サイバーセキュリティイベントへの対応、コンプライアンス上の不備確認を行う仕組みが確立されています。
+ AWS CloudTrail はログ記録とモニタリングに使用されます。
+ セキュリティイベント (ルートユーザーのログインなど) が発生したら、アラートが発行されます。
+ SCP および VPC エンドポイントポリシーにより、 AWS 環境のデータ境界を確立しています。
+ SCP により、アプリケーションチームが CloudTrail や AWS Configなどのセキュリティおよびログ記録サービスを無効化できないようにしています。
+ AWS Config 検出結果は AWS 組織全体から 1 つの に集約され、セキュリティ AWS アカウント が確保されます。
+ AWS Config [ACSC Essential 8 コンフォーマンスパック](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-acsc_essential_8.html)は、組織内のすべての AWS アカウント で有効になっています。
# ワークロードの例: サーバーレスデータレイク
このワークロードは、[テーマ 1: マネージドサービスの使用](theme-1.md) の例を示すものです。
データレイクは、ストレージに Amazon S3 を使用し、ETL AWS Lambda に Amazon S3 を使用します。これらのリソースは AWS Cloud Development Kit (AWS CDK) アプリで定義されます。システムへの変更は、 を通じてデプロイされます 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 戦略に対応できるよう、以下のアクションを実行します。
*アプリケーション制御*
+ GuardDuty の [Lambda Protection](https://docs.aws.amazon.com/guardduty/latest/ug/lambda-protection.html) と Amazon Inspector の [Lambda スキャン](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html)を有効にします。
+ [Amazon Inspector の検出結果を検査および管理](https://docs.aws.amazon.com/inspector/latest/user/findings-managing-automating-responses.html#findings-managing-eventbridge-tutorial)する仕組みを実装します。
*アプリケーションへのパッチ適用*
+ Amazon Inspector の Lambda スキャンを有効にし、非推奨ライブラリや脆弱なライブラリにアラートを設定します。
+ アプリケーションチームは、 AWS Config がアセット検出の AWS リソースを追跡できるようにします。
*管理者権限の制限*
+ 「[コアアーキテクチャ](scenario.md#core-architecture)」セクションで説明したように、アプリケーションチームでは、デプロイパイプラインの承認ルールによって、本番環境にデプロイする際のアクセスを既に制限しています。
+ ともに一元化された ID フェデレーションおよびログ記録ソリューション (「[コアアーキテクチャ](scenario.md#core-architecture)」セクションを参照) を活用します。
+ アプリケーションチームは証 AWS CloudTrail 跡と Amazon CloudWatch フィルターを作成します。
+ アプリケーションチームは、CodePipeline デプロイと AWS CloudFormation スタック削除の Amazon Simple Notification Service (Amazon SNS) アラートを設定します。
*オペレーティングシステムへのパッチ適用*
+ Amazon Inspector の Lambda スキャンを有効にし、非推奨ライブラリや脆弱なライブラリにアラートを設定します。
*多要素認証*
+ 一元化された ID フェデレーションソリューション (「[コアアーキテクチャ](scenario.md#core-architecture)」セクションを参照) を活用します。このソリューションによって、MFA の適用や認証のログ記録を行い、疑わしい MFA イベントが発生した際は、アラートを生成するかそれらに自動的に対応します。
*定期バックアップ*
+ アプリケーションチームは、 AWS CDK アプリケーションや Lambda 関数、設定などの[コードをコードリポジトリ](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)に保存します。
+ バージョニングと Amazon S3 Object Lock を有効にして、オブジェクトの削除や変更を防ぎます。
+ データセット全体を別の AWS リージョンに複製せず、Amazon S3 が備える耐久性を活用します。
+ アプリケーションチームは、データ主権 AWS リージョン 要件を満たす別の でワークロードのコピーを実行します。Amazon DynamoDB グローバルテーブルと Amazon S3 [クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario)を使用して、プライマリリージョンからセカンダリリージョンにデータを自動的にレプリケートします。
# ワークロードの例: コンテナ化されたウェブサービス
このワークロードは、[テーマ 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 回自動的に実行し、復旧手順の有効性を検証します。
# ワークロードの例: Amazon EC2 で稼働する COTS ソフトウェア
このワークロードは、[テーマ 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 プランを作成します。
+ アプリケーションチームは、バックアップからの復元を毎月手動で実行する仕組みを実装します。