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

ID とアクセスを管理するためのセキュリティコントロールの推奨事項

ID は で作成することも AWS、外部 ID ソースに接続することもできます。 AWS Identity and Access Management (IAM) ポリシーを通じて、ユーザーが AWS リソースと統合アプリケーションにアクセスまたは管理するために必要なアクセス許可を付与します。効果的に ID とアクセスを管理することで、適切な人物とマシンが適切な条件下で適切なリソースにアクセスできることを確認できます。 AWS Well-Architected フレームワークは、ID とそのアクセス許可を管理するためのベストプラクティスを提供します。ベストプラクティスの例としては、一元化された ID プロバイダーの利用や、多要素認証 (MFA) などの強力なサインインメカニズムの使用などがあります。このセクションで説明するセキュリティコントロールは、これらのベストプラクティスを実装するのに役立ちます。

ルートユーザーアクティビティの通知をモニタリングして設定

を初めて作成するときは AWS アカウント、ルートユーザーと呼ばれる単一のサインインアイデンティティから始めます。ルートユーザーには、デフォルトで、そのアカウント内のすべての AWS のサービス とリソースに完全にアクセスできる権限があります。ルートユーザーについては、厳密に制御およびモニタリングし、ルートユーザーの認証情報を必要とするタスクにのみ使用する必要があります。

詳細については、以下のリソースを参照してください。

ルートユーザーのアクセスキーは作成しないでください

ルートユーザーは、最も権限のある AWS アカウントのユーザーです。ルートユーザーへのプログラムによるアクセスを無効にすると、ユーザーの認証情報が誤って公開され、クラウド環境が侵害されるリスクを軽減できます。 AWS アカウント やリソースにアクセスする際は、一時的な認証情報として IAM ロールを作成して使用することをお勧めします。

詳細については、以下のリソースを参照してください。

ルートユーザーの MFA を有効化

AWS アカウント ルートユーザーと IAM ユーザーに対して複数の多要素認証 (MFA) デバイスを有効にすることをお勧めします。これにより、 AWS アカウント のセキュリティレベルが引き上げられ、アクセス管理が簡素化されます。ルートユーザーは特権操作を実行できる権限の高いユーザーであるため、MFA を必須とすることが重要です。タイムベースドワンタイムパスワード (TOTP) アルゴリズムに基づいて数値コードを生成するハードウェア MFA デバイス、FIDO ハードウェアセキュリティキー、または仮想認証アプリケーションを使用できます。

2024 年、MFA は任意の のルートユーザーにアクセスする必要があります AWS アカウント。詳細については、 AWS セキュリティブログの「Secure by Design: AWS to enhance MFA requirements in 2024」を参照してください。このセキュリティプラクティスを拡張し、 AWS 環境内のすべてのユーザータイプに MFA を要求することを強くお勧めします。

可能であれば、ルートユーザーにはハードウェア MFA デバイスを使用することをお勧めします。仮想 MFA はハードウェア MFA デバイスと同じレベルのセキュリティを提供しない可能性があります。仮想 MFA は、ハードウェアの購入承認または納品を待っている間に使用できます。

数百のアカウントを管理する状況では AWS Organizations、組織のリスク許容度によっては、組織単位 (OU) 内の各アカウントのルートユーザーにハードウェアベースの MFA を使用することがスケーラブルではない場合があります。このような場合は、OU 内のアカウントのうち 1 つを OU 管理アカウントとして選択し、その OU 内の他のアカウントのルートユーザーを無効にすることができます。デフォルトでは、OU 管理アカウントは他のアカウントにアクセスできません。緊急時に OU 管理アカウントから他のアカウントにアクセスできるよう、事前にクロスアカウントアクセスを設定しておいてください。クロスアカウントアクセスを設定するには、メンバーアカウントに IAM ロールを作成し、OU 管理アカウントのルートユーザーのみがこのロールを引き受けられるようにポリシーを定義します。詳細については、IAM ドキュメントの「チュートリアル: IAM ロール AWS アカウント を使用して 全体でアクセスを委任する」を参照してください。

ルートユーザーの認証情報に対して、複数の MFA デバイスを有効にすることをお勧めします。任意の組み合わせの MFA デバイスを最大で 8 台登録できます。

詳細については、以下のリソースを参照してください。

IAM のセキュリティのベストプラクティスに従う

IAM ドキュメントには、 AWS アカウント および リソースの保護に役立つベストプラクティスのリストが含まれています。これには、最小特権の原則に従ってアクセス権と許可を設定するための推奨事項が含まれています。IAM セキュリティのベストプラクティスの例としては、ID フェデレーションの設定、MFA の必須化、一時的な認証情報の使用などがあります。

詳細については、以下のリソースを参照してください。

最小特権のアクセス許可を付与

最小特権とは、タスクを実行するために必要なアクセス許可のみを付与する際のプラクティスです。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。

属性ベースのアクセス制御 (ABAC) は、タグなどの属性に基づいてアクセス許可を定義する認可戦略です。グループ属性、ID 属性、リソース属性を使用して、個々のユーザーのアクセス許可を定義するのではなく、規模に応じてアクセス許可を動的に定義できます。例えば、ABAC を使用して、プロジェクトに関連付けられた特定のタグを持つリソースにのみ、開発者グループがアクセスできるように設定できます。

詳細については、以下のリソースを参照してください。

ワークロードレベルでアクセス許可ガードレールを定義

マルチアカウント戦略を使用すると、ワークロードレベルでガードレールを柔軟に定義できるため、ベストプラクティスとされています。 AWS セキュリティリファレンスアーキテクチャは、アカウントを構築する方法に関する規範的なガイダンスを提供します。これらのアカウントは AWS Organizations の組織として管理され、アカウントは組織単位 (OU) ごとにグループ化されます。

AWS Control Tower などのAWS のサービスを使用すると、組織全体のコントロールを一元管理できます。組織内の各アカウントまたは OU に明確な目的を定義し、その目的に従ってコントロールを適用することをお勧めします。 は、リソースの管理とコンプライアンスのモニタリングに役立つ予防、検出、プロアクティブのコントロール AWS Control Tower を実装します。予防コントロールは、イベントの発生を防ぐように設計されています。検出コントロールは、イベントが発生した後に、検出、ログ記録、警告を行うように設計されています。プロアクティブコントロールは、リソースのプロビジョニング前にスキャンして、非準拠リソースのデプロイを防ぐように設計されています。

詳細については、以下のリソースを参照してください。

IAM アクセスキーを定期的にローテーション

長期的に認証情報を必要とするユースケースでは、アクセスキーを更新するのがベストプラクティスです。アクセスキーは 90 日以内ごとにローテーションすることをお勧めします。アクセスキーをローテーションすることにより、侵害されたアカウントや終了したアカウントに関連付けられているアクセスキーが使用されるリスクが低くなります。また、紛失、侵害、盗難にあった可能性のある古いキーを使用したアクセスを防止します。アクセスキーをローテーションしたら、必ずアプリケーションを更新してください。

詳細については、以下のリソースを参照してください。

外部エンティティと共有されているリソースを識別

外部エンティティは、別のユーザー、ルートユーザー、IAM ユーザーまたはロール、フェデレーティッドユーザー AWS アカウント、、匿名 (または認証されていない) ユーザーなど、 AWS 組織外のリソース、アプリケーション、サービス AWS のサービス、またはユーザーです。セキュリティのベストプラクティスは、IAM Access Analyzer を使用して、外部エンティティと共有されている Amazon Simple Storage Service (Amazon S3) バケットや IAM ロールなど、組織とアカウントのリソースを識別することです。これにより、セキュリティ上のリスクであるリソースやデータへの意図しないアクセスを特定できます。

詳細については、以下のリソースを参照してください。