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

# ID とアクセスを管理するためのセキュリティコントロールの推奨事項
<a name="identity-and-access-controls"></a>

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

**Topics**
+ [ルートユーザーアクティビティの通知をモニタリングして設定](#root-user-activity)
+ [ルートユーザーのアクセスキーは作成しないでください](#root-user-access-keys)
+ [ルートユーザーの MFA を有効化](#root-user-mfa)
+ [IAM のセキュリティのベストプラクティスに従う](#iam-best-practices)
+ [最小特権のアクセス許可を付与](#least-privilege)
+ [ワークロードレベルでアクセス許可ガードレールを定義](#workload-guardrails)
+ [IAM アクセスキーを定期的にローテーション](#rotate-keys)
+ [外部エンティティと共有されているリソースを識別](#resources-shared-externally)

## ルートユーザーアクティビティの通知をモニタリングして設定
<a name="root-user-activity"></a>

を初めて作成するときは AWS アカウント、*ルートユーザー*と呼ばれる単一のサインインアイデンティティから始めます。ルートユーザーには、デフォルトで、そのアカウント内のすべての AWS のサービス とリソースに完全にアクセスできる権限があります。ルートユーザーについては、厳密に制御およびモニタリングし、[ルートユーザーの認証情報を必要とするタスク](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)にのみ使用する必要があります。

詳細については、以下のリソースを参照してください。
+  AWS Well-Architected フレームワークで[最小特権アクセスを付与](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)する
+  AWS 規範ガイダンスで [IAM ルートユーザーのアクティビティをモニタリング](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-iam-root-user-activity.html)する

## ルートユーザーのアクセスキーは作成しないでください
<a name="root-user-access-keys"></a>

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

詳細については、以下のリソースを参照してください。
+ [IAM ルートユーザーアクセスキーがドキュメントに存在しないこと](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-4) AWS Security Hub CSPM 
+ [ルートユーザーのアクセスキーを削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user_manage_delete-key.html) (IAM ドキュメント)
+ [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) (IAM ドキュメント)

## ルートユーザーの MFA を有効化
<a name="root-user-mfa"></a>

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

2024 年、MFA は任意の のルートユーザーにアクセスする必要があります AWS アカウント。詳細については、 AWS セキュリティブログの[「Secure by Design: AWS to enhance MFA requirements in 2024](https://aws.amazon.com/blogs/security/security-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 アカウント を使用して 全体でアクセスを委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)する」を参照してください。

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

詳細については、以下のリソースを参照してください。
+ [ハードウェア TOTP トークンの有効化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root) (IAM ドキュメント)
+ [多要素認証 (MFA) 仮想デバイスの有効化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html) (IAM ドキュメント)
+ [FIDO セキュリティキーの有効化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_fido.html) (IAM ドキュメント)
+ [多要素認証 (MFA) でルートユーザーのサインインを保護する](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html#ru-bp-mfa) (IAM ドキュメント)

## IAM のセキュリティのベストプラクティスに従う
<a name="iam-best-practices"></a>

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

詳細については、以下のリソースを参照してください。
+ [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (IAM ドキュメント)
+ IAM ドキュメントの[AWS リソースでの一時的な認証情報の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) 

## 最小特権のアクセス許可を付与
<a name="least-privilege"></a>

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

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

詳細については、以下のリソースを参照してください。
+ [最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) (IAM ドキュメント)
+ [AWSにおける ABAC とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) (IAM ドキュメント)

## ワークロードレベルでアクセス許可ガードレールを定義
<a name="workload-guardrails"></a>

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

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

詳細については、以下のリソースを参照してください。
+  AWS Well-Architected フレームワークの[アカウントを使用してワークロードを分離](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_multi_accounts.html)する
+  AWS 規範ガイダンス[AWS のセキュリティリファレンスアーキテクチャ (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/) 
+  AWS Control Tower ドキュメントの [のコントロールについて AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/controls.html) 
+  AWS 規範ガイダンスの [でのセキュリティコントロールの実装 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/) 
+ [サービスコントロールポリシーを使用して、 セキュリティブログの AWS 「Organization」のアカウント間でアクセス許可ガードレールを設定する](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/?ref=wellarchitected) AWS 

## IAM アクセスキーを定期的にローテーション
<a name="rotate-keys"></a>

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

詳細については、以下のリソースを参照してください。
+ [長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) (IAM ドキュメント)
+  AWS 規範ガイダンスの [AWS Organizations および を使用して、IAM ユーザーアクセスキーを大規模に自動的にローテーション AWS Secrets Manager](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automatically-rotate-iam-user-access-keys-at-scale-with-aws-organizations-and-aws-secrets-manager.html)する
+ [アクセスキーの更新](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) (IAM ドキュメント)

## 外部エンティティと共有されているリソースを識別
<a name="resources-shared-externally"></a>

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

詳細については、以下のリソースを参照してください。
+ [IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-preview-access) (IAM ドキュメント)
+  AWS Well-Architected フレームワークで[パブリックアクセスとクロスアカウントアクセスを分析する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) 
+ [AWS Identity and Access Management Access Analyzerの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) (IAM ドキュメント)