# SEC03-BP02 最小特権のアクセスを付与します
特定の条件下で特定の AWS リソースに対する特定のアクションを許可して、アイデンティティに必要なアクセスのみを付与します。グループと ID 属性を利用して、個々のユーザーのアクセス許可を定義するのではなく、規模に応じてアクセス許可を動的に設定します。たとえば、開発者のグループに、扱うプロジェクトのリソースのみを管理することを許可できます。これにより、開発者がグループから削除されると、アクセスポリシーに変更を加えることなく、そのグループがどこでアクセスコントロールに使用されたかを問わず、開発者のアクセスが取り消されます。
**一般的なアンチパターン:**
+ デフォルトでユーザーに管理者アクセス許可を付与する
+ ルートアカウントを日常業務に使用する
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
最小権限の [原則を設定することで、](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 特定のタスクを実行するための必要最小限の機能セットのみを実行する許可が ID に与えられるようになり、使いやすさと効率のバランスを取ることができます。この原則を適用すると、意図しないアクセスは制限され、誰がどのリソースにアクセス権限があるかを監査できます。AWS では、ルートユーザー以外のアイデンティティは、デフォルトではアクセス許可を持ちません。ルートユーザーの認証情報は、厳重に制御し、 [特定のタスクにのみ使用する必要があります](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)。
ポリシーを使用して、フェデレーティッド ID、マシン、リソース (S3 バケットなど) が使用する IAM ロールなどの IAM またはリソースエンティティにアタッチされたアクセス許可を明示的に付与できます。ポリシーの作成およびアタッチでは、AWS がアクセスを許可するために必要なサービスアクション、リソース、条件を指定できます。AWS では、アクセスを最小限にするために役立つさまざまな条件を用意しています。例えば、 `PrincipalOrgID ` [条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を使用すると、AWS Organizations の識別子が検証されるため、AWS 組織内でアクセスを付与できます。
AWS のサービスがユーザーに代わって行うリクエスト (AWS CloudFormation による AWS Lambda 関数の作成など) を制御するには、 `CalledVia ` 条件キーを使用します。さまざまなポリシータイプを積み重ねて、アカウント内でアクセス許可すべてを効果的に制限する必要があります。例えば、アプリケーションチームが独自の IAM ポリシーを作成できるようにする一方、 [アクセス許可の境界](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) を使用して、そのチームが付与できる最大限のアクセス許可を制限できます。
アクセス許可の管理をスケールして最小特権の原則を遵守するのに役立つ AWS の機能がいくつかあります。[属性ベースのアクセスコントロール](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) では、リソースの *[タグ](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)* に基づいてアクセス許可を制限できます。リソースに適用されるタグと呼び出し側の IAM プリンシパルに基づいた認可の決定が可能となります。それにより、タグ付けとアクセス許可ポリシーを組み合わせて、多数のカスタムポリシーを必要としない、きめ細かいリソースアクセスを実現できます。
また、最小特権ポリシーの作成を迅速に行うために、アクティビティの実行後に CloudTrail のアクセス許可に基づいてポリシーを作成することもできます。[IAM Access Analyzer は、アクティビティに基づいて IAM ポリシーを自動生成できます](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)。また、IAM アクセスアドバイザーを組織レベルまたは個々のアカウントレベルで使用して [最終アクセスの情報を追跡し、特定のポリシーを適用できます](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)。
これらの詳細を確認して不必要なアクセス許可を削除する頻度を定めます。AWS 組織内でアクセス許可のガードレールを確立し、すべてのメンバーアカウント内で最大限のアクセス許可を制御する必要があります。例えば [AWS Control Tower などのサービスには、規範に基づいて管理される予防的コントロールが含まれており、](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 独自のコントロールを定義できます。
## リソース
**関連するドキュメント:**
+ [IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Techniques for writing least privilege IAM policies (最小特権の IAM ポリシーを作成するテクニック)](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity (IAM Access Analyzer は、アクセスアクティビティに基づいて IAM ポリシーを生成することにより、最小特権のアクセス許可の実装を容易にする)](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [最終アクセス情報を使用した AWS のアクセス許可の調整](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [IAM でのポリシータイプと使用する状況](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [IAM Policy Simulator を使用した IAM ポリシーのテスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [AWS Control Tower のガードレール](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Zero Trust architectures: An AWS perspective (ゼロトラストアーキテクチャ: AWS の視点)](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [How to implement the principle of least privilege with CloudFormation StackSets (CloudFormation StackSets を使用して最小特権の原則を実装する方法)](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
**関連動画:**
+ [Next-generation permissions management (次世代のアクセス許可管理)](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust: An AWS perspective (ゼロトラスト: AWS の視点)](https://www.youtube.com/watch?v=1p5G1-4s1r0)
+ [How can I use permissions boundaries to limit IAM users and roles to prevent privilege escalation? (アクセス許可の境界を使用して IAM ユーザーとロールの範囲を限定し、権限の昇格を防ぐにはどうすればよいですか?)](https://www.youtube.com/watch?v=omwq3r7poek)
**関連サンプル:**
+ [ラボ: ロールの作成を委任する IAM アクセス許可の境界](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html)