경계가 있는 효과적인 권한 평가 권한 경계를 사용하여 다른 사용자에게 책임 위임

IAM 엔터티의 권한 범위

에서는 IAM 엔터티(사용자 또는 역할)에 대한 권한 경계를 AWS지원합니다. 권한 경계는 관리형 정책을 사용하여 자격 증명 기반 정책을 통해 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 엔터티의 권한 경계는 자격 증명 기반 정책 및 관련 권한 경계 모두에서 허용되는 작업만 수행하도록 허용합니다.

정책 유형에 대한 자세한 정보는 정책 유형 섹션을 참조하세요.

중요

권한 경계 정책이 연결된 IAM 사용자 또는 역할에는 Deny 효과를 포함하는 NotPrincipal 정책 요소가 있는 리소스 기반 정책 문을 사용하지 않도록 합니다. Deny 효과를 포함하는 NotPrincipal 요소는 NotPrincipal 요소에 지정된 값에 관계없이 권한 경계 정책이 연결된 IAM 보안 주체를 항상 거부합니다. 이로 인해 원래 리소스에 액세스할 수 있는 일부 IAM 사용자 또는 역할이 해당 리소스에 더 이상 액세스할 수 없습니다. NotPrincipal 요소 대신 액세스를 제한하기 위해 ArnNotEquals 조건 연산자를 aws:PrincipalArn 컨텍스트 키와 함께 사용하도록 리소스 기반 정책 문을 변경하는 것이 좋습니다. NotPrincipal 요소에 대한 자세한 내용은 AWS JSON 정책 요소: NotPrincipal 섹션을 참조하세요.

AWS 관리형 정책 또는 고객 관리형 정책을 사용하여 IAM 엔터티(사용자 또는 역할) 경계를 설정할 수 있습니다. 이 정책은 사용자 또는 역할에 대해 최대 권한을 제한합니다.

예를 들어, 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 작업을 허용하지 않기 때문입니다. 이 두 가지 정책을 감안할 때 Shirley는 AWS에서 작업을 수행할 권한이 없습니다. 다른 서비스(예: Amazon S3)에서 작업을 허용하려면 다른 권한 정책을 추가해야 합니다. 또는 권한 경계를 업데이트하여 그녀에게 IAM에서 사용자를 생성하도록 허용할 수도 있습니다.

경계가 있는 효과적인 권한 평가

IAM 엔터티(사용자 또는 역할)에 대한 권한 경계는 엔터티에 부여할 수 있는 최대 권한을 설정합니다. 사용자 또는 역할에 대한 효과적 권한을 변경할 수 있습니다. 사용자 또는 역할에 영향을 주는 모든 정책을 통해 부여되는 권한이 개체에 대한 유효 권한입니다. 계정 내에서 엔터티에 대한 권한은 자격 증명 기반 정책, 리소스 기반 정책, 권한 경계, 조직 SCP 또는 세션 정책에 영향을 받을 수 있습니다. 다양한 유형의 정책에 대한 자세한 정보는 IAM의 정책 및 권한 섹션을 참조하세요.

이러한 정책 유형 중 하나에서 작업에 대한 액세스가 명시적으로 거부된 경우 해당 요청이 거부됩니다. 여러 권한 유형에 의해 엔터티에 부여된 권한은 훨씬 더 복잡합니다. AWS의 정책 평가에 대한 자세한 정보는 정책 평가 로직 섹션을 참조하세요.

자격 증명 기반 정책과 경계 - 자격 증명 기반 정책은 사용자, 사용자 그룹 또는 역할에 연결된 인라인 또는 관리형 정책입니다. 자격 증명 기반 정책은 엔터티에 권한을 부여하며, 권한 경계는 이러한 권한을 제한합니다. 유효 권한은 두 정책 유형의 교집합입니다. 이들 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다.

리소스 기반 정책 - 리소스 기반 정책은 지정된 보안 주체가 정책이 연결된 리소스에 액세스하는 방식을 제어합니다.

IAM 사용자를 위한 리소스 기반 정책

동일한 계정 내에서 IAM 사용자 ARN(페더레이션 사용자 세션이 아님)에게 권한을 부여하는 리소스 기반 정책은 자격 증명 기반 정책 또는 권한 경계의 암시적 거부에 의해 제한되지 않습니다.

IAM 역할에 대한 리소스 기반 정책

IAM 역할 - IAM 역할 ARN에 권한을 부여하는 리소스 기반 정책은 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한됩니다.

IAM 역할 세션 - 동일한 계정 내에서 IAM 역할 세션 ARN에 권한을 부여하는 리소스 기반 정책은 수임된 역할 세션에 직접 권한을 부여합니다. 세션에 직접 부여된 사용 권한은 자격 증명 기반 정책, 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한되지 않습니다. 역할을 맡고 요청을 할 때 요청을 수행하는 보안 주체는 역할 자체의 ARN이 아니라 IAM 역할 세션 ARN입니다.

IAM 역할 및 페더레이션 사용자에 대한 리소스 기반 정책

IAM 페더레이션 사용자 세션 - IAM 페더레이션 사용자 세션은 GetFederationToken 호출을 통해 생성된 세션입니다. 페더레이션 사용자가 요청을 할 때 요청을 수행하는 보안 주체는 페더레이션된 IAM 사용자의 ARN이 아니라 페더레이션 사용자 ARN입니다. 동일한 계정 내에서 페더레이션 사용자 ARN에게 권한을 부여하는 리소스 기반 정책은 세션에 직접 권한을 부여합니다. 세션에 직접 부여된 사용 권한은 자격 증명 기반 정책, 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한되지 않습니다.

그러나 리소스 기반 정책이 페더레이션한 IAM 사용자의 ARN에 권한을 부여하는 경우, 세션 중에 페더레이션 사용자가 요청한 요청은 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한됩니다.

조직 SCP - SCP는 전체 AWS 계정에 적용됩니다. SCP는 해당 계정 내 보안 주체가 보낸 모든 요청에 대한 권한을 제한합니다. IAM 엔터티(사용자 또는 역할)는 SCP, 권한 경계 및 자격 증명 기반 정책의 영향을 받는 요청을 수행할 수 있습니다. 이 경우, 세 정책 유형 모두에서 허용하는 경우에만 해당 요청이 허용됩니다. 유효 권한은 세 정책 유형 모두의 교집합입니다. 이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다.

AWS Organizations에서 계정이 조직의 멤버인지 여부를 알아볼 수 있습니다. 조직 멤버가 SCP의 영향을 받을 수 있습니다. AWS CLI 명령 또는 AWS API 작업을 사용하여 이 데이터를 보려면 조직 엔터티에 대해 organizations:DescribeOrganization 작업 권한이 있어야 합니다. 조직 콘솔에서 작업을 수행할 추가 권한이 있어야 합니다. SCP가 특정 요청에 대한 액세스를 거부하는지 여부를 확인하거나 유효 권한을 변경하려면 AWS Organizations 관리자에게 문의하세요.

세션 정책 - 세션 정책은 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 세션에 대한 권한은 세션을 생성하는 데 사용되는 IAM 엔터티(사용자 또는 역할)와 세션 정책에서 가져옵니다. 엔터티의 자격 증명 기반 정책 권한은 세션 정책과 권한 경계에 제한을 받습니다. 이 정책 유형 집합의 유효 권한은 세 정책 유형 모두의 교집합입니다. 이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다. 세션 정책에 대한 자세한 정보는 세션 정책을 참조하세요.

권한 경계를 사용하여 다른 사용자에게 책임 위임

권한 경계를 사용하여 사용자 생성과 같은 권한 관리 작업을 계정의 IAM 사용자에 위임할 수 있습니다. 이로써 권한의 특정 경계 내에서 다른 사용자가 작업을 대신 수행할 수 있는 권한이 부여됩니다.

예를 들어, María가 X-Company AWS 계정 관리자라고 가정하세요. Maria가 Zhang에게 사용자 생성 업무를 위임하고자 합니다. 하지만 Zhang이 다음 회사 규칙에 따라 사용자를 생성하는지 확신해야 합니다.

사용자는 IAM을 사용하여 사용자, 그룹, 역할 또는 정책을 생성하고 관리할 수 없습니다.
사용자의 Amazon S3 logs 버킷 액세스가 거부되고 사용자가 i-1234567890abcdef0 Amazon EC2 인스턴스로 액세스할 수 없습니다.
사용자는 사용자 자체 경계 정책을 제거할 수 없습니다.

이런 규칙을 시행하기 위해서는 María는 아래와 같은 세부 정보가 포함된 작업을 완료합니다.

María는 XCompanyBoundaries 관리형 정책을 생성하여 계정의 모든 새로운 사용자에 대한 권한 경계로서 사용할 수 있습니다.
María는 DelegatedUserBoundary 관리형 정책을 생성하여 Zhang에 대한 권한 경계로서 할당합니다. Maria는 관리자 사용자의 ARN을 기록하고 정책에서 사용하여 Zhang이 해당 ARN에 액세스하지 못하도록 합니다.
María는 DelegatedUserPermissions 관리형 정책을 생성하여 Zhang에 대한 권한 정책으로서 연결합니다.
María가 Zhang에서 그의 새로운 책임과 제한을 알려줍니다.

작업 1: María는 먼저 관리형 정책을 생성하여 새로운 사용자에 대한 경계를 정의해야 합니다. María는 Zhang이 사용자에게 필요한 권한 정책을 사용자에게 부여할 수 있도록 허용하지만 사용자를 제한하고자 합니다. 이렇게 하기 위해서는 마리아는 XCompanyBoundaries라는 다음 고객 관리형 정책을 생성합니다. 이 정책은 다음을 수행합니다.

사용자에게 여러 서비스에 대한 전체 액세스 권한을 부여
IAM 콘솔에서 제한된 자체 관리 액세스 허용 즉, 콘솔에 로그인한 후 암호를 변경할 수 있습니다. 초기 암호를 설정할 수 없습니다. 이 작업을 허용하려면 "*LoginProfile" 작업을 AllowManageOwnPasswordAndAccessKeys 문에 추가합니다.
Amazon S3 로그 버킷 또는 i-1234567890abcdef0 Amazon EC2 인스턴스로의 사용자 액세스 거부


{
    "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"
        }
    ]
}

각 설명문은 다른 목적이 있습니다.

이 정책의 ServiceBoundaries 설명문은 지정된 AWS 서비스에 대한 완전한 액세스를 허용합니다. 이런 서비스의 새로운 사용자 작업이 사용자에 연결된 권한 정책에 따라서만 제한된다는 의미입니다.
AllowIAMConsoleForCredentials 문에서 모든 IAM 사용자를 나열할 수 있는 액세스를 허용합니다. 이 액세스는 AWS Management Console의 사용자 페이지를 탐색하는 데 필요합니다. 또한 계정의 암호 요구 사항을 확인하도록 허용합니다. 이 액세스는 자신의 고유 암호를 변경할 때 필요합니다.
AllowManageOwnPasswordAndAccessKeys 문을 통해 사용자가 고유한 콘솔 암호와 프로그래밍 방식의 액세스 키만 관리할 수 있습니다. 이는 Zhang 또는 다른 관리자가 새로운 사용자에게 전체 IAM 액세스를 포함하는 권한 정책을 할당할 때 중요합니다. 이 경우, 해당 사용자가 자신 또는 다른 사용자의 권한을 변경할 수 있습니다. 이 설명문은 이런 상황을 방지할 수 있습니다.
DenyS3Logs 설명문은 logs 버킷 액세스를 명시적으로 거부합니다.
DenyEC2Production 설명문은 i-1234567890abcdef0 인스턴스 액세스를 명시적으로 거부합니다.

작업 2: María는 Zhang이 모든 X-Company 사용자를 생성하도록 허용하지만 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": "*"
        }
    ]
}

각 설명문은 다른 목적이 있습니다.

CreateOrChangeOnlyWithBoundary 설명문은 Zhang이 IAM 사용자를 생성하도록 허용하지만 Zhang이 권한 경계를 설정할 때 XCompanyBoundaries 정책을 사용할 경우에만 가능합니다. 이 설명문은 또한 장이 기존 사용자에 대한 권한 경계를 설정하도록 허용하지만 장이 동일한 정책을 사용할 때만 가능합니다. 마지막으로, 이 설명문은 Zhang이 이 권한 경계 설정을 통해 사용자에 대한 권한 정책을 관리하도록 허용합니다.
CloudWatchAndOtherIAMTasks 설명문은 Zhang이 사용자, 그룹 및 정책 관리 작업을 완료하도록 허용합니다. 그는 NotResource 정책 요소에 나열되지 않은 IAM 사용자의 암호를 재설정하고 액세스 키를 생성할 수 있는 권한이 있습니다. 따라서 그는 사용자가 로그인 문제를 해결하도록 지원할 수 있습니다.
NoBoundaryPolicyEdit 설명문은 Zhang이 XCompanyBoundaries 정책을 업데이트할 수 있는 액세스를 거부합니다. 장은 자신 또는 다른 사용자에 대한 권한 경계를 설정하는 데 사용되는 어떤 정책도 변경할 수 없습니다.
NoBoundaryUserDelete 문에서는 Zhang이 자신 또는 다른 사용자에 대해 권한 경계를 삭제하기 위해 액세스할 때 이를 거부합니다.

그런 다음 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"
        }
    ]
}

각 설명문은 다른 목적이 있습니다.

정책의 IAM 설명문은 IAM에 대한 Zhang의 완전한 액세스를 허용합니다. 그러나, Zhang 권한 경계가 몇 가지 IAM 작업만 허용하기 때문에 Zhang의 효과적인 IAM 권한은 그의 권한 경계에 의해서만 제한됩니다.
CloudWatchLimited 설명문은 Zhang이 CloudWatch에서 5가지 작업을 수행할 수 있도록 허용합니다. Zhang 권한 경계는 CloudWatch의 모든 작업을 허용하기 때문에 그의 효과적인 CloudWatch 권한은 그의 권한 정책에 의해서만 제한됩니다.
S3BucketContents 설명문은 Zhang이 ZhangBucket Amazon S3 버킷을 나열할 수 있도록 허용합니다. 그러나, Zhang 권한 경계는 어떠한 Amazon S3 작업도 허용하지 않기 때문에 Zhang은 그의 권한 정책과 상관없이 어떠한 S3 작업도 수행할 수 없습니다.

참고
Zhang의 정책을 통해 자신은 액세스할 수 없는 Amazon S3 리소스에 액세스할 수 있는 사용자를 생성할 수 있습니다. Maria는 이러한 관리 작업을 위임하여 Amazon S3에 대한 액세스 권한이 있는 Zhang을 효과적으로 신뢰합니다.

그러면 María는 DelegatedUserPermissions 정책을 Zhang 사용자에 대한 권한 정책으로서 연결합니다.

작업 4: María는 새로운 사용자를 생성하도록 Zhang에게 지침을 내립니다. María는 Zhang에게 새로운 사용자가 원하는 모든 권한을 통해 새로운 사용자를 생성할 수 있지만 XCompanyBoundaries 정책을 권한 경계로서 할당해야 한다고 말합니다.

Zhang은 다음 작업을 완료합니다.

Zhang은 AWS Management Console로 사용자를 생성합니다. 그는 사용자 이름 Nikhil를 입력하고 사용자에 대한 콘솔 액세스를 가능하게 합니다. 위의 정책에서는 사용자가 IAM 콘솔에 로그인한 후에만 암호를 변경할 수 있으므로 암호 재설정 필요 옆의 확인란 선택을 취소합니다.
권한 설정 페이지에서 Zhang은 Nikhil가 업무를 할 수 있도록 허용하는 IAMFullAccess 및 AmazonS3ReadOnlyAccess 권한 정책을 선택합니다.
Zhang은 María의 지침을 잊고 Set permissions boundary(권한 경계 설정) 섹션을 넘깁니다.
Zhang은 사용자 세부 정보를 검토하고 사용자 생성을 선택합니다.

작업은 실패하고 액세스는 거부됩니다. Zhang의 DelegatedUserBoundary 권한 경계는 그가 생성하는 어떠한 사용자도XCompanyBoundaries 정책을 권한 경계로서 가지고 있어야 합니다.
Zhang은 이전 페이지로 돌아갑니다. 그는 권한 경계 설정 페이지에서 XCompanyBoundaries 정책을 선택합니다.
Zhang은 사용자 세부 정보를 검토하고 사용자 생성을 선택합니다.

사용자가 생성됩니다.

Nikhil이 로그인할 경우, 그는 권한 경계에 의해 거부된 작업 이외의 IAM 및 Amazon S3에 액세스할 수 있습니다. 예를 들어, 그는 IAM에 자신의 암호를 변경할 수 있지만 다른 사용자를 생성하거나 그의 정책을 편집할 수 없습니다. Nikhil은 Amazon S3에 대한 읽기 전용 액세스 권한이 있습니다.

누군가가 logs 버킷에 Nikhil이 버킷에 객체를 넣을 수 있도록 허용하는 리소스 기반 정책을 추가하더라도 그는 여전히 이 버킷에 액세스할 수 없습니다 logs 버킷에 대한 작업이 권한 경계에 의해 명시적으로 거부되었기 때문입니다. 정책 유형에 포함된 명시적 거부로 인해 요청이 거부됩니다. 하지만 Secrets Manager 암호에 연결된 리소스 기반 정책이 Nikhil이 secretsmanager:GetSecretValue 작업을 수행하도록 허용하는 경우 Nikhil은 암호를 불러와서 암호화를 해제할 수 있습니다. 그 이유는 Secrets Manager 작업이 Nikhill의 권한 경계에 의해 명시적으로 거부되지 않았고 권한 경계에서의 묵시적 거부가 리소스 기반 정책을 제한하지 않기 때문입니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

사용되지 않는 AWS 관리형 정책

자격 증명과 리소스 비교

IAM 엔터티의 권한 범위

중요

경계가 있는 효과적인 권한 평가

권한 경계를 사용하여 다른 사용자에게 책임 위임

참고