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

クラウドを考慮した、Essential Eight 戦略の再解釈

元の Essential Eight 緩和戦略を以下に示します。これらは、Microsoft ベースのインターネット接続ネットワーク向けに設計されています。

前述のとおり、Essential Eight フレームワークは、クラウド環境向けには設計されていません。ただし、基礎となる原則が適用され、Essential Eight 戦略と AWS Well-Architected Framework のベストプラクティスの間には重複があります。

クラウドネイティブのさまざまなアプローチを取ると、セキュリティが向上し、コンプライアンス上の負担が大幅に軽減されます。オンプレミス環境では、あらゆるセキュリティを自社の責任で確保する必要があるものの、管理機能があらかじめ用意されているわけではありません。クラウドでワークロードを実行する場合、 AWS は当社のサービスを実行するインフラストラクチャを保護する責任があります。自動化およびマネージドサービスを利用すると、コンプライアンス上の負担を軽減することも可能です。マネージドサービスは抽象化サービスとも呼ばれ、 AWS のサービス がインフラストラクチャレイヤー、オペレーティングシステム、プラットフォームを AWS 運用し、ユーザーがエンドポイントにアクセスしてデータを保存および取得します。マネージドサービスの例として、Amazon Simple Storage Service (Amazon S3) と Amazon DynamoDB が挙げられます。詳細については、このガイドの「テーマ 1: マネージドサービスの使用」セクションを参照してください。

したがって、Essential Eight 戦略を AWS上のワークロードに当てはまるように変更するには、いくつかの再解釈が必要です。このガイドでは、Essential Eight 戦略を AWS テーマに変換します。

テーマの使用

このガイドは 8 つのテーマに分かれています。各 Essential Eight 戦略は、次のテーマの 1 つ以上にマッピングされ、各テーマは AWS Well-Architected フレームワークの 1 つ以上のベストプラクティスにマッピングされます。

各テーマには、トピックの概要、関連する AWS Well-Architected Framework のベストプラクティス、Essential Eight の成熟度を達成し、コンプライアンスをモニタリングする方法の手順が含まれています。こうした手順は、手動での手順や、AWS Config ルールによる自動化の設定方法を説明するものです。手動の手順には、検出結果に対処するための仕組みが必要です。詳細については、「」を参照してくださいテーマ 8: 手動プロセスの仕組みの実装。 AWS Config ルールは、非準拠のリソースを修復するために同様の監視または自動化を必要とします。 https://docs.aws.amazon.com/config/latest/developerguide/remediation.htmlこれらのテーマに沿ったガイダンスに従うと、クラウドのメリットが最大化するアプローチで Essential Eight の成熟度に到達できます。

クラウドを考慮した、Essential Eight 戦略の再解釈

Essential Eight フレームワークは、クラウド環境向けには設計されていないため、各 Essential Eight 戦略の基本原則を実装する際には、クラウドネイティブなアプローチを取ることが重要です。このアプローチは、2 つの重要な質問から導き出される現状によって異なります。

どのようなサービスを利用していますか?

AWS 責任共有モデル は、コンプライアンスと運用上の負担を軽減するのに有用です。マネージドサービスは、デプロイされたサービスの可用性、パフォーマンス、セキュリティ最適化 AWS を維持する責任を に移行します。サービス維持に伴う運用上および管理上の負担も軽減できるため、イノベーションへの取り組みにより多くの時間を割けるようになります。

マネージドサービスでは、Amazon API Gateway、AWS Lambda、DynamoDB などのサーバーレスサービスも提供されます。Amazon Relational Database Service (Amazon RDS) でデータベースを稼働させると、Amazon Elastic Compute Cloud (Amazon EC2) で稼働させる場合よりも、運用上の責任が少なくなります。

例えば、Patch オペレーティングシステムの Essential Eight 戦略をクラウドに適応させる場合は、使用しているサービスと、それらのリソースにパッチを適用する責任があるかどうかを考慮する必要があります。 AWS は、Lambda や DynamoDB などのフルマネージドサービスのパッチ適用を担当します。Amazon RDS や Amazon Redshift などのサービスでは、メンテナンスウィンドウの間に、お客様側でパッチ管理が必要になる場合があります。https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html

どのようなデプロイモデルを使用していますか?

組織では、ミュータブルまたはイミュータブルなインフラストラクチャのアプローチを取っていますか?

ミュータブルインフラストラクチャモデルでは、本番ワークロードの既存インフラストラクチャを更新し、修正します。クラウド導入前には、こうした標準的なデプロイ方法が取られます。サーバーインフラストラクチャの置き換えにはコストと時間が非常にかかると考えると、最も実用的なアプローチは、既存の本番サーバーを変更することだからです。クラウドでのミュータブルなアプローチの例には、アプリケーションの変更を、手動、あるいは、AWS Systems Manager Run Command や AWS CodeDeploy などのソフトウェアデプロイメントサービスを使用して、稼働中の EC2 インスタンスに直接デプロイする方法があります。

イミュータブルなインフラストラクチャモデルでは、既存のインフラストラクチャに更新、パッチ適用、変更などを行わず、本番環境のワークロード向けに新しいインフラストラクチャをデプロイします。イミュータブルなアプローチの例として、AWS CloudFormation または AWS Cloud Development Kit (AWS CDK) でアプリケーションスタックを定義することが挙げられます。こうしたサービスを使用すると、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを通じてアプリケーションスタックをデプロイできます。このアプローチでは、ローリングデプロイやブルー/グリーンデプロイなどのデプロイ手法を使用します。このアプローチの詳細については、 AWS Well-Architected フレームワークにある「イミュータブルなインフラストラクチャを使用してデプロイする」のベストプラクティスを参照してください。

例えば、オペレーションシステムへのパッチ適用の Essential Eight 戦略をクラウドに適応させる場合は、パッチ適用をデプロイモデルにどのように当てはめるかを考察する必要があります。ミュータブルなインフラストラクチャでは、リソースに手動でパッチを適用することも、自動化によって運用を効率化することもできます。イミュータブルなインフラストラクチャを採用している場合は、CI/CD パイプラインを通じて、最新のオペレーティングシステムバージョンを使用し、新しいインフラストラクチャをデプロイします。厳密に言うと、このモデルでは、パッチ適用という呼び方は誤っています。パッチ適用ではなく、置き換えによってインフラストラクチャを更新するからです。