# 権限の管理 アクセス許可を管理して、AWS とワークロードへのアクセスを必要とするユーザー ID やマシン ID へのアクセスを制御します。権限を使用すると、誰が何に、どのような条件でアクセスできるかを制御できます。特定のユーザー ID およびマシン ID にアクセス権限を設定し、必要とするリソースに対するサービスアクションへのアクセスのみを許可します。さらに、アクセスを取得するために満たすべき条件を指定できます。 さまざまなタイプのリソースにアクセスを付与する方法は多数あります。その 1 つは、異なるポリシータイプを使用する方法です。 IAM の[アイデンティティベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)は管理またはインラインで、ユーザー、グループ、ロールなどの IAM ID にアタッチされます。これらのポリシーを使用すると、そのアイデンティティが実行できる内容 (そのアクセス許可) を指定できます。アイデンティティベースのポリシーはさらに分類できます。 **管理ポリシー** – AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンのアイデンティティベースのポリシーです。管理ポリシーには 2 種類あります。 + **AWS 管理ポリシー** – AWS が作成および管理する管理ポリシー。 + **カスタマー管理ポリシー** – AWS アカウントで作成および管理する管理ポリシー。カスタマー管理ポリシーでは、AWS マネージドポリシーよりも正確にポリシー管理できます。 アクセス許可を付与するには、マネージドポリシーのほうが好ましい方法です。ただし、単一のユーザー、グループ、ロールに直接追加するインラインポリシーを使用することもできます。インラインポリシーは、ポリシーと ID の間の厳密な 1 対 1 の関係を維持します。アイデンティティを削除すると、インラインポリシーは削除されます。 ほとんどの場合、[最小特権](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)の原則に従って独自のカスタマー管理ポリシーを作成する必要があります。 [リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)をリソースにアタッチします。例えば、Amazon S3 バケットポリシーはリソースベースのポリシーです。これらのポリシーでは、リソースと同じアカウントまたは別のアカウントにあるプリンシパルにアクセス許可を付与します。リソースベースのアクセス許可をサポートするサービスのリストについては、「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 [アクセス許可の境界](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)は、マネージドポリシーを使用して、管理者が設定できるアクセス許可の上限を設定できます。これによって、IAM ロール作成などのアクセス許可の作成および管理の権限を開発者に委任しながらも、付与できるアクセス許可を制限して、自分でそのアクセス許可の範囲を拡大できないように制限できます。 AWS の[属性ベースのアクセス制御 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) を使用すると、タグと呼ばれる属性に基づいて権限を付与できます。これらのタグは、IAM プリンシパル (ユーザーまたはロール) と AWS リソースにアタッチできます。管理者は、IAM プリンシパルの属性に基づいて権限を適用する再利用可能な IAM ポリシーを作成できます。例えば、管理者は 1 つの IAM ポリシーを使用して、プロジェクトタグに一致する AWS リソースへのアクセス権を組織内のデベロッパーに付与できます。デベロッパーチームがプロジェクトにリソースを追加すると、属性に基づいて権限が自動的に適用されるため、新しいリソースごとにポリシーを更新する必要がなくなります。 [組織 のサービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_scp) を使用して、組織または組織単位 (OU) のメンバーアカウントのアクセス許可の上限を定義します。SCP では、アイデンティティベースのポリシーまたはリソースベースのポリシーで、アカウント内のエンティティ (ユーザーまたはロール) に付与するアクセス許可が制限されますが、アクセス許可は付与されません。 [セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)は、ロールまたはフェデレーションユーザーを引き受けます。AWS CLI または AWS API セッションポリシーを使ってロールまたはユーザーのアイデンティティベースのポリシーがセッションに付与する許可を制限する際、セッションポリシーを渡します。セッションポリシーでは、作成したセッションのアクセス許可が制限されますが、アクセス許可は付与されません。詳細については、「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。 **Topics** + [SEC03-BP01 アクセス要件を定義する](sec_permissions_define.md) + [SEC03-BP02 最小特権のアクセスを付与します](sec_permissions_least_privileges.md) + [SEC03-BP03 緊急アクセスのプロセスを確立する](sec_permissions_emergency_process.md) + [SEC03-BP04 アクセス許可を継続的に削減する](sec_permissions_continuous_reduction.md) + [SEC03-BP05 組織のアクセス許可ガードレールを定義する](sec_permissions_define_guardrails.md) + [SEC03-BP06 ライフサイクルに基づいてアクセスを管理する](sec_permissions_lifecycle.md) + [SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](sec_permissions_analyze_cross_account.md) + [SEC03-BP08 組織内でリソースを安全に共有する](sec_permissions_share_securely.md) + [SEC03-BP09 サードパーティーとリソースを安全に共有する](sec_permissions_share_securely_third_party.md)