IAM エンティティのアクセス許可境界

AWS は、IAM エンティティ (ユーザーまたはロール) のアクセス許可の境界をサポートしています。アクセス許可の境界は、管理ポリシーを使用してアイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界により、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。

ポリシーの詳細については、「ポリシータイプ」を参照してください。

IAM エンティティ (ユーザーまたはロール) の境界を設定するには、AWS 管理ポリシーまたはカスタマー管理ポリシーを使用します。このポリシーでは、ユーザーやロールのアクセス許可の上限を設定します。

たとえば、ShirleyRodriguez という名前の IAM ユーザーが Amazon S3、Amazon CloudWatch、および Amazon EC2 のみを管理できるようにする必要があるとします。このルールを適用するには、次のポリシーを使用して ShirleyRodriguez ユーザーのアクセス許可の境界を設定できます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "cloudwatch:*",
                "ec2:*"
            ],
            "Resource": "*"
        }
    ]
}

ポリシーを使用してユーザーのアクセス許可の境界を設定する場合、このポリシーではユーザーのアクセス許可は制限しますが、それ自体のアクセス許可は提供しません。この例のポリシーでは、ShirleyRodriguez のアクセス許可の上限を Amazon S3、CloudWatch、および Amazon EC2 のすべてのオペレーションに設定します。Shirley は、IAM を含む他のどのサービスでもオペレーションを実行することはできません。実行を許可するアクセス許可ポリシーが適用されている場合でも同様です。たとえば、ShirleyRodriguez ユーザーに次のポリシーを追加できます。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:CreateUser",
    "Resource": "*"
  }
}

このポリシーでは、IAM のユーザーの作成を許可します。このアクセス許可ポリシーを ShirleyRodriguez ユーザーにアタッチすると、Shirley はユーザーを作成しようとしても、オペレーションは失敗します。アクセス許可の境界で iam:CreateUser オペレーションが許可されていないため、失敗します。これら 2 つのポリシーを考慮すると、Shirley には AWS でのオペレーションを実行するアクセス許可がありません。Amazon S3 などの他のサービスでのアクションを許可するには、別のアクセス許可ポリシーを追加する必要があります。または、IAM のユーザーの作成を許可するように、アクセス許可の境界を更新します。

境界を設定した場合の有効なアクセス許可の評価

IAM エンティティ (ユーザーまたはロール) のアクセス許可の境界では、エンティティに許可されるアクセス許可の上限が設定されます。これにより、ユーザーやロールの有効なアクセス許可が変わる場合があります。エンティティの有効なアクセス許可は、ユーザーやロールに影響するすべてのポリシーによって付与されるアクセス許可です。エンティティのアクセス許可は、アカウント内で、アイデンティティベースのポリシー、リソースベースのポリシー、アクセス許可の境界、Organizations SCP、またはセッションポリシーの影響を受ける場合があります。各種ポリシーの詳細については、「AWS Identity and Access Management でのポリシーとアクセス許可」を参照してください。

これらのいずれかのポリシータイプによって、オペレーションへのアクセスが明示的に拒否された場合、そのリクエストは拒否されます。複数のアクセス許可タイプによってエンティティに付与されたアクセス許可はさらに複雑です。AWS でのポリシーの評価の詳細については、「ポリシーの評価論理」を参照してください。

アイデンティティベースのポリシー (境界あり) – アイデンティティベースのポリシーは、ユーザー、ユーザーのグループ、またはロールにアタッチされているインラインポリシーまたは管理ポリシーです。アイデンティティベースのポリシーはエンティティにアクセス許可を付与し、アクセス許可の境界は、それらのアクセス許可を制限します。有効なアクセス許可は、両方のポリシータイプの共通部分です。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。

Organizations SCP - SCP は、AWS アカウント 全体に適用されます。この場合、アカウント内のプリンシパルによって行われるすべてのリクエストのアクセス許可が制限されます。IAM エンティティ (ユーザーまたはロール) は、SCP、アクセス許可の境界、およびアイデンティティベースのポリシーの影響を受けるリクエストを行うことができます。この場合、そのリクエストは、その 3 つすべてのポリシータイプで許可されている場合にのみ許可されます。有効なアクセス許可は、その 3 つすべてのポリシータイプの共通部分です。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。

自分のアカウントが AWS Organizations の組織のメンバーであるかどうかを確認できます。組織のメンバーは、SCP による影響を受ける可能性があります。AWS CLI コマンドまたは AWS API オペレーションを使用してこのデータを表示するには、Organizations エンティティに対する organizations:DescribeOrganization アクションのアクセス許可が必要です。Organizations コンソールでオペレーションを実行するには、追加のアクセス許可が必要です。SCP が特定のリクエストへのアクセスを拒否しているかどうかを確認する、または有効なアクセス権限を変更するには、AWS Organizations 管理者に連絡してください。

セッションポリシー - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。セッションのアクセス許可は、セッションの作成に使用する IAM エンティティ (ユーザーまたはロール) と、セッションポリシーから派生します。エンティティのアイデンティティベースのポリシーのアクセス許可は、セッションポリシーとアクセス許可の境界で制限されています。この一連のポリシータイプの有効なアクセス許可は、その 3 つすべてのポリシータイプの共通部分です。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。セッションポリシーの詳細については、「セッションポリシー」を参照してください。

アクセス許可の境界を使用した他のユーザーへの責任の委任

アクセス許可の境界を使用して、アクセス許可の管理タスク (ユーザーの作成など) をアカウントの IAM ユーザーに委任できます。これにより、アクセス許可の特定の境界内で、ユーザーの代わりに他のユーザーがタスクを実行できます。

例えば、María は X-Company の AWS アカウント の管理者であるとします。彼女は、ユーザーの作成業務を Zhang を委任したいと考えます。しかし、Zhang が以下の社内ルールに従ってユーザーを作成することを確認する必要があります。

これらのルールを適用するために、María は以下のタスクを実行します (各タスクの詳細は後述します)。

タスク 1: María は、最初に管理ポリシーを作成して、新しいユーザーの境界を定義する必要があります。María は、必要なアクセス許可ポリシーをユーザーに付与することを Zhang に許可しますが、これらのユーザーを制限したいと思います。これを行うには、次のカスタマー管理ポリシーを XCompanyBoundaries という名前で作成します。このポリシーは以下の処理を実行します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ServiceBoundaries",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "cloudwatch:*",
                "ec2:*",
                "dynamodb:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIAMConsoleForCredentials",
            "Effect": "Allow",
            "Action": [
                "iam:ListUsers",
                "iam:GetAccountPasswordPolicy"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowManageOwnPasswordAndAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:*AccessKey*",
                "iam:ChangePassword",
                "iam:GetUser",
                "iam:*ServiceSpecificCredential*",
                "iam:*SigningCertificate*"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::logs",
                "arn:aws:s3:::logs/*"
            ]
        },
        {
            "Sid": "DenyEC2Production",
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0"
        }
    ]
}

ステートメントごとに用途は異なります。

タスク 2: María は、すべての X-Company ユーザーを作成することを Zhang に許可しますが、条件として XCompanyBoundaries をアクセス許可の境界とします。そのために、次のカスタマー管理ポリシーを DelegatedUserBoundary という名前で作成します。このポリシーでは、Zhang に許可されるアクセス許可の上限を定義します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CreateOrChangeOnlyWithBoundary",
            "Effect": "Allow",
            "Action": [
                "iam:AttachUserPolicy",
                "iam:CreateUser",
                "iam:DeleteUserPolicy",
                "iam:DetachUserPolicy",
                "iam:PutUserPermissionsBoundary",
                "iam:PutUserPolicy"
            ],
            "Resource": "*",
            "Condition": {
               "StringEquals": {
                 "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries"
                }
            }
        },
        {
            "Sid": "CloudWatchAndOtherIAMTasks",
            "Effect": "Allow",
            "Action": [
              "cloudwatch:*",
              "iam:CreateAccessKey",
              "iam:CreateGroup",
              "iam:CreateLoginProfile",
              "iam:CreatePolicy",
              "iam:DeleteGroup",
              "iam:DeletePolicy",
              "iam:DeletePolicyVersion",
              "iam:DeleteUser",
              "iam:GetAccountPasswordPolicy",
              "iam:GetGroup",
              "iam:GetLoginProfile",
              "iam:GetPolicy",
              "iam:GetPolicyVersion",
              "iam:GetRolePolicy",
              "iam:GetUser",
              "iam:GetUserPolicy",
              "iam:ListAccessKeys",
              "iam:ListAttachedRolePolicies",
              "iam:ListAttachedUserPolicies",
              "iam:ListEntitiesForPolicy",
              "iam:ListGroups",
              "iam:ListGroupsForUser",
              "iam:ListMFADevices",
              "iam:ListPolicies",
              "iam:ListPolicyVersions",
              "iam:ListRolePolicies",
              "iam:ListSSHPublicKeys",
              "iam:ListServiceSpecificCredentials",
              "iam:ListSigningCertificates",
              "iam:ListUserPolicies",
              "iam:ListUsers",
              "iam:SetDefaultPolicyVersion",
              "iam:SimulateCustomPolicy",
              "iam:SimulatePrincipalPolicy",
              "iam:UpdateGroup",
              "iam:UpdateLoginProfile",
              "iam:UpdateUser"
            ],
            "NotResource": "arn:aws:iam::123456789012:user/Maria"
        },
        {
            "Sid": "NoBoundaryPolicyEdit",
            "Effect": "Deny",
            "Action": [
                "iam:CreatePolicyVersion",
                "iam:DeletePolicy",
                "iam:DeletePolicyVersion",
                "iam:SetDefaultPolicyVersion"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:policy/XCompanyBoundaries",
                "arn:aws:iam::123456789012:policy/DelegatedUserBoundary"
            ]
        },
        {
            "Sid": "NoBoundaryUserDelete",
            "Effect": "Deny",
            "Action": "iam:DeleteUserPermissionsBoundary",
            "Resource": "*"
        }
    ]
}

ステートメントごとに用途は異なります。

次に María は、Zhang ユーザーのアクセス許可の境界として DelegatedUserBoundary ポリシーを割り当てます。

タスク 3: アクセス許可の境界ではアクセス許可の上限を設定するだけで、それ自体はアクセスを付与しないため、Maria は Zhang のアクセス許可ポリシーを作成する必要があります。次のポリシーを DelegatedUserPermissions という名前で作成します。このポリシーでは、設定された境界内で、Zhang が実行できるオペレーションを定義します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "IAM",
            "Effect": "Allow",
            "Action": "iam:*",
            "Resource": "*"
        },
        {
            "Sid": "CloudWatchLimited",
            "Effect": "Allow",
            "Action": [
                "cloudwatch:GetDashboard",
                "cloudwatch:GetMetricData",
                "cloudwatch:ListDashboards",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics"
            ],
            "Resource": "*"
        },
        {
            "Sid": "S3BucketContents",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::ZhangBucket"
        }
    ]
}

ステートメントごとに用途は異なります。

次に María は、DelegatedUserPermissions ユーザーのアクセス許可ポリシーとして Zhang ポリシーをアタッチします。

タスク 4: María は、新しいユーザーを作成する手順を Zhang に伝えます。新しいユーザーを作成して必要なアクセス権を付与できますが、アクセス許可の境界として XCompanyBoundaries ポリシーを割り当てる必要があることを説明します。

Zhang は以下のタスクを実行します。

Nikhil は、サインインすると、アクセス許可の境界で拒否されているオペレーションを除いて、IAM と Amazon S3 にアクセスできます。たとえば、IAM で自分のパスワードは変更できますが、別のユーザーを作成したり、自分のポリシーを編集したりすることはできません。Nikhil は Amazon S3 への読み取り専用アクセス権を持っています。

リソースベースのポリシーを logs バケットに追加して Nikhil がそのバケットにオブジェクトを配置できるようにしても、Nikhil はこのバケットにアクセスできません。理由は、logs バケットのアクションはすべて、彼のアクセス許可の境界によって明示的に拒否されているためです。いずれかのポリシータイプで明示的に拒否されていると、リクエストは拒否されます。ただし、Secrets Manager シークレットにアタッチされているリソースベースのポリシーで、secretsmanager:GetSecretValue アクションの実行を Nikhil に許可している場合、Nikhil は、そのシークレットを取得して復号できます。これは、Secrets Manager オペレーションは、彼のアクセス許可境界によって明示的に拒否されており、アクセス許可の境界の暗黙的な拒否により、リソースベースのポリシーが制限されないためです。