보안 주체를 지정하는 방법 AWS 계정 보안 주체 IAM 역할 보안 주체 역할 세션 보안 주체 IAM 사용자 보안 주체 Identity Center 보안 주체 페더레이션 사용자 세션 보안 주체 AWS 서비스 보안 주체 옵트인 리전용 AWS 서비스 주체 모든 보안 주체 추가 정보

AWS JSON 정책 요소: Principal

리소스 기반 JSON 정책의 Principal 요소를 사용하여 리소스에 대한 액세스가 허용되거나 거부되는 보안 주체를 지정합니다.

리소스 기반 정책의 Principal 요소를 사용해야 합니다. IAM을 비롯한 여러 서비스가 리소스 기반 정책을 지원합니다. IAM 리소스 기반 정책 유형은 역할 신뢰 정책입니다. IAM 역할에서 역할 신뢰 정책의 Principal 요소를 사용하여 역할을 수임할 수 있는 사용자를 지정합니다. 크로스 계정 액세스인 경우에는 신뢰할 수 있는 계정의 12자리 식별자를 지정합니다. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, IAM Access Analyzer란 무엇일까요?를 참조하세요.

참고

역할을 생성한 이후 계정을 "*"로 변경하여 모두가 이 역할을 수임하도록 할 수 있습니다. 이렇게 하는 경우 다른 방법(예: 특정 IP 주소로만 액세스를 제한하는 Condition 요소)을 통해 역할에 액세스할 수 있는 사용자를 제한하는 것이 좋습니다. 역할을 모두 액세스할 수 있는 상태로 두지 마세요.

리소스 기반 정책을 지원하는 리소스의 다른 예에는 Amazon S3 버킷 또는 AWS KMS key(이)가 포함됩니다.

자격 증명 기반 정책에서는 Principal 요소를 사용할 수 없습니다. 자격 증명 기반 정책은 IAM 자격 증명(사용자, 그룹 또는 역할)에 연결할 수 있는 권한 정책입니다. 이 경우, 보안 주체는 암시적으로 정책이 연결된 자격 증명입니다.

보안 주체를 지정하는 방법

보안 주체를 지원하는 리소스 기반 정책이나 조건 키의 Principal 요소에 있는 보안 주체를 지정합니다.

정책에서 다음 보안 주체를 지정할 수 있습니다.

AWS 계정 및 루트 사용자
IAM 역할
역할 세션
IAM 사용자
페더레이션 사용자 세션
AWS 서비스
모든 보안 주체

그룹은 인증이 아니라 권한과 관련이 있고 보안 주체는 인증된 IAM 엔터티이기 때문에 정책(예: 리소스 기반 정책)에서 사용자 그룹을 보안 주체로 식별할 수 없습니다.

배열을 사용하여 다음 섹션에서 각 보안 주체 유형에 대해 둘 이상의 보안 주체를 지정할 수 있습니다. 배열은 하나 이상의 값을 갖습니다. 요소에 둘 이상의 보안 주체를 지정할 때는 각 보안 주체에 권한을 부여하십시오. 한 번에 하나의 보안 주체로 인증되기 때문에 이것은 논리적 AND(이)며 논리적 OR이(가) 아닙니다. 값을 두 개 이상 포함하는 경우 배열의 각 항목을 대괄호([ 및 ]) 및 쉼표로 구분합니다. 다음 예시 정책은 123456789012 계정 또는 555555555555 계정에 대한 권한을 정의합니다.


"Principal" : { 
"AWS": [ 
  "123456789012",
  "555555555555" 
  ]
}

참고

보안 주체 이름이나 ARN의 일부를 나타내기 위해 와일드카드를 사용할 수 없습니다.

AWS 계정 보안 주체

보안 주체를 지원하는 리소스 기반 정책이나 조건 키의 Principal 요소에 있는 AWS 계정 식별자를 지정할 수 있습니다. 이렇게 하면 계정에 권한을 위임합니다. 다른 계정에 대한 액세스를 허용하면 해당 계정의 관리자는 해당 계정의 자격 증명(IAM 사용자 또는 역할)에 대한 액세스 권한을 부여해야 합니다. AWS 계정을 지정하는 경우 계정 ARN(arn:aws:iam::account-ID:root)을 사용하거나 "AWS": 접두사와 그 뒤에 계정 ID가 따라오는 약식 형태를 사용할 수 있습니다.

예를 들어, 계정 ID 123456789012의 경우 다음 방법 중 하나를 사용하여 Principal 요소에서 해당 계정을 지정할 수 있습니다.


"Principal": { "AWS": "arn:aws:iam::123456789012:root" }


"Principal": { "AWS": "123456789012" }

계정 ARN과 단축된 계정 ID도 같은 방식으로 작동합니다. 둘 다 계정에 권한을 위임합니다. Principal 요소에서 계정 ARN 사용해도 계정의 루트 사용자에게만 권한이 제한되지는 않습니다.

참고

단축된 계정 ID를 포함하는 리소스 기반 정책을 저장하면 서비스에서 이를 보안 주체 ARN으로 변환할 수 있습니다. 이렇게 해도 정책의 기능은 변경되지 않습니다.

일부 AWS 서비스는 계정 보안 주체를 지정하기 위한 몇 가지 옵션을 추가로 지원합니다. 예를 들어 Amazon S3에서는 다음 형식을 사용하여 정식 사용자 ID를 지정할 수 있습니다.


"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }

또한 배열을 사용하여 둘 이상의 AWS 계정(또는 표준 사용자 ID)을 보안 주체로 지정할 수 있습니다. 예를 들어, 세 가지 방법 모두를 사용하여 보안 주체를 버킷 정책에 지정할 수 있습니다.


"Principal": { 
  "AWS": [
    "arn:aws:iam::123456789012:root",
    "999999999999"
  ],
  "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}

IAM 역할 보안 주체

보안 주체를 지원하는 리소스 기반 정책이나 조건 키의 Principal 요소에 있는 IAM 역할 보안 주체 ARN을 지정할 수 있습니다. IAM 역할은 자격 증명입니다. IAM에서 자격 증명은 권한을 할당할 수 있는 리소스입니다. 역할은 다른 인증된 자격 증명을 신뢰하여 해당 역할을 수임합니다. 여기에는 AWS의 보안 주체 또는 외부 자격 증명 공급자(IdP)가 포함됩니다. 보안 주체 또는 자격 증명이 역할을 맡으면 수임된 역할의 권한이 있는 임시 보안 자격 증명을 수신합니다. AWS에서 작업을 수행하기 위해 이러한 세션 자격 증명을 사용하면 역할 세션 보안 주체가 됩니다.

IAM 역할은 IAM에 존재하는 자격 증명입니다. 역할은 AWS의 보안 주체 또는 외부 ID 공급자의 사용자와 같은 다른 인증된 자격 증명을 신뢰합니다. 보안 주체 또는 자격 증명이 역할을 맡으면 임시 보안 자격 증명을 수신합니다. 그런 다음 이러한 자격 증명을 역할 세션 보안 주체로 사용하여 AWS에서 작업을 수행할 수 있습니다.

리소스 기반 정책에서 역할 보안 주체를 지정하는 경우 보안 주체에 대한 유효 사용 권한은 해당 역할에 대한 사용 권한을 제한하는 모든 정책 유형에 의해 제한됩니다. 여기에는 세션 정책과 권한 경계가 포함됩니다. 역할 세션에 대한 유효한 사용 권한을 평가하는 방법에 대한 자세한 내용은 정책 평가 로직을(를) 참조하세요.

Principal 요소에서 ARN 역할을 지정하려면 다음 형식을 사용하십시오.


"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

중요

역할 신뢰 정책의 Principal 요소에 특정 IAM 역할을 가리키는 ARN이 포함되어 있으면, 정책을 저장할 때 해당 ARN이 해당 역할의 고유 보안 주체 ID로 변환됩니다. 그러면 누군가가 해당 역할을 제거하고 다시 만들어 본인의 권한을 에스컬레이션할 위험을 완화할 수 있습니다. IAM은 신뢰 정책이 표시될 때 역할 ARN로 역변환을 다시 사용하기 때문에 일반적으로 콘솔에서는 이 ID가 표시되지 않습니다. 그러나 해당 역할을 삭제하면 관계가 깨집니다. 역할을 다시 만들더라도 해당 정책이 더 이상 적용되지 않습니다. 새 역할의 새 보안 주체 ID가 신뢰 정책에 저장된 ID와 일치하지 않기 때문입니다. 이 경우 AWS가 더 이상 유효한 ARN에 다시 매핑할 수 없기 때문에 보안 주체 ID가 리소스 기반 정책에 나타납니다. 결과적으로 신뢰 정책의 Principal 요소에서 참조된 역할을 삭제하고 다시 만드는 경우, 보안 주체 ID를 올바른 ARN으로 바꾸도록 정책에서 역할을 편집해야 합니다. 정책을 저장하면 ARN이 다시 해당 역할의 새로운 보안 주체 ID로 변환됩니다.

또는 리소스 기반 정책에서 역할 보안 주체를 보안 주체로 지정하거나 aws:PrincipalArn 조건 키를 사용하는 광범위한 권한 정책을 생성할 수 있습니다. 이 키를 사용하면 역할 세션 보안 주체에게 결과 세션의 ARN이 아니라 수임된 역할의 ARN을 기반으로 권한이 부여됩니다. 이는 AWS은(는) 조건 키 ARN을 ID로 변환하지 않기 때문입니다. 역할 ARN에 부여된 권한은 역할을 삭제한 다음 동일한 이름으로 새 역할을 생성하면 유지됩니다. 자격 증명 기반 정책에 명시적 거부가 포함되지 않는 한, 권한 경계 또는 세션 정책과 같은 자격 증명 기반 정책 유형은 Principal 요소에서 와일드카드(*)와 함께 aws:PrincipalArn 조건 키를 사용하여 부여한 권한을 제한하지 않습니다.

역할 세션 보안 주체

보안 주체를 지원하는 리소스 기반 정책이나 조건 키의 Principal 요소에 있는 역할 세션을 지정할 수 있습니다. 보안 주체 또는 자격 증명이 역할을 맡으면 수임된 역할의 권한이 있는 임시 보안 자격 증명을 수신합니다. AWS에서 작업을 수행하기 위해 이러한 세션 자격 증명을 사용하면 역할 세션 보안 주체가 됩니다.

역할 세션 보안 주체에 사용하는 형식은 역할을 수임하는 데 사용된 AWS STS 작업에 따라 다릅니다.

또한 관리자는 역할 세션이 발행되는 방식을 제어하는 프로세스를 설계할 수 있습니다. 예를 들어 예측 가능한 세션 이름을 생성하는 원클릭 솔루션을 사용자에게 제공할 수 있습니다. 관리자가 이를 수행하는 경우, 정책 또는 조건 키에서 역할 세션 보안 주체를 사용할 수 있습니다. 그렇지 않으면 역할 ARN을 aws:PrincipalArn 조건 키의 보안 주체로 지정할 수 있습니다. 역할을 보안 주체로 지정하는 방법에 따라 결과 세션에 대한 유효한 권한이 변경될 수 있습니다. 자세한 내용은 IAM 역할 보안 주체 단원을 참조하십시오.

수임된 역할 세션 보안 주체

수임된 역할 세션 보안 주체는 AWS STS AssumeRole 작업을 사용하여 발생하는 세션 보안 주체입니다. 이 작업을 사용하여 역할을 수임할 수 있는 보안 주체에 대한 자세한 내용은 AWS STS 자격 증명 비교을(를) 참조하세요.

Principal 요소에서 수임된 역할 세션 ARN을 지정하려면 다음 형식을 사용하십시오.


"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

Principal 요소에 수임된 역할 세션을 지정할 때 와일드카드 “*”를 사용하여 모든 세션을 의미할 수 없습니다. 보안 주체는 항상 특정 세션의 이름을 지정해야 합니다.

OIDC 세션 보안 주체

OIDC 세션 보안 주체는 AWS STS AssumeRoleWithWebIdentity 작업을 사용하는 경우에 발생하는 세션 보안 주체입니다. 외부 OIDC 공급자(IdP)를 사용하여 로그인한 다음 이 작업을 사용하여 IAM 역할을 수행할 수 있습니다. 이렇게 하면 아이덴티티 페더레이션을 활용하고 역할 세션을 발행합니다. 이 작업을 사용하여 역할을 수임할 수 있는 보안 주체에 대한 자세한 내용은 AWS STS 자격 증명 비교을(를) 참조하세요.

OIDC 공급자로부터 역할을 발행하면 OIDC 공급자에 대한 정보가 포함된 이 특별한 유형의 세션 보안 주체를 얻게 됩니다.

정책에서 이 보안 주체 유형을 사용하여 신뢰할 수 있는 웹 자격 증명 공급자를 기반으로 액세스를 허용하거나 거부합니다. 역할 신뢰 정책의 Principal 요소에서 OIDC 역할 세션 ARN을 지정하려면 다음 형식을 사용합니다.


"Principal": { "Federated": "cognito-identity.amazonaws.com" }


"Principal": { "Federated": "www.amazon.com" }


"Principal": { "Federated": "graph.facebook.com" }


"Principal": { "Federated": "accounts.google.com" }

SAML 세션 보안 주체

SAML 세션 보안 주체는 AWS STS AssumeRoleWithSAML 작업을 사용하여 발생하는 세션 보안 주체입니다. 외부 SAML 자격 증명 공급자(IdP)를 사용하여 로그인한 다음 이 작업을 사용하여 IAM 역할을 수행할 수 있습니다. 이렇게 하면 아이덴티티 페더레이션을 활용하고 역할 세션을 발행합니다. 이 작업을 사용하여 역할을 수임할 수 있는 보안 주체에 대한 자세한 내용은 AWS STS 자격 증명 비교을(를) 참조하세요.

SAML 자격 증명 공급자로부터 역할을 발행하면 SAML 자격 증명 공급자에 대한 정보가 포함된 이 특별한 유형의 세션 보안 주체를 얻게 됩니다.

정책에서 이 보안 주체 유형을 사용하여 신뢰할 수 있는 SAML 자격 증명 공급자를 기반으로 액세스를 허용하거나 거부합니다. Principal 요소에서 SAML 아이덴티티 역할 세션 ARN을 지정하려면 다음 형식을 사용하세요.


"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

IAM 사용자 보안 주체

리소스 기반 정책의 Principal 요소 또는 보안 주체를 지원하는 조건 키에서 IAM 사용자를 지정할 수 있습니다.

참고

Principal 요소에서 Amazon 리소스 이름(ARN)의 사용자 이름 부분은 대/소문자를 구분합니다.


"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }


"Principal": {
  "AWS": [
    "arn:aws:iam::AWS-account-ID:user/user-name-1", 
    "arn:aws:iam::AWS-account-ID:user/user-name-2"
  ]
}

Principal 요소로 사용자를 지정할 때는 "모든 사용자"의 의미로 와일드카드(*)를 사용할 수 없습니다. 보안 주체는 항상 특정 사용자가 되어야 하기 때문입니다.

중요

역할 신뢰 정책의 Principal 요소에 특정 IAM 사용자를 가리키는 ARN이 포함되어 있으면, IAM은 정책을 저장할 때 ARN을 사용자의 고유한 보안 주체 ID로 변환합니다. 그러면 누군가가 해당 사용자를 제거하고 다시 만들어 본인의 권한을 에스컬레이션할 위험을 완화할 수 있습니다. 일반적으로 콘솔에서는 이 ID가 보이지 않습니다. 신뢰 정책이 표시될 때 해당 사용자의 ARN으로 다시 역변환되기 때문입니다. 그러나 해당 사용자를 삭제하면 관계가 깨집니다. 사용자를 다시 생성해도 정책은 더 이상 적용되지 않습니다. 새 사용자의 새 보안 주체 ID가 신뢰 정책에 저장된 ID와 일치하지 않기 때문입니다. 이 경우 AWS가 더 이상 유효한 ARN에 다시 매핑할 수 없기 때문에 보안 주체 ID가 리소스 기반 정책에 나타납니다. 결과적으로 신뢰 정책의 Principal 요소에서 참조된 사용자를 삭제하고 다시 만드는 경우, 역할을 편집하여 현재의 잘못된 보안 주체 ID를 올바른 ARN으로 바꿔야 합니다. IAM은 정책을 저장하면 ARN이 다시 해당 사용자의 새로운 보안 주체 ID로 변환됩니다.

IAM Identity Center 보안 주체

IAM Identity Center에서는 리소스 기반 정책의 보안 주체를 AWS 계정 보안 주체로 정의해야 합니다. 액세스를 지정하려면 조건 블록에 있는 권한 세트의 역할 ARN을 참조합니다. 자세한 내용은 IAM Identity Center 사용 설명서에서 리소스 정책, Amazon EKS 및 AWS KMS의 권한 세트 참조를 참조하세요.

AWS STS 페더레이션 사용자 세션 보안 주체

보안 주체를 지원하는 리소스 기반 정책이나 조건 키의 Principal 요소에 있는 페더레이션 사용자 세션을 지정할 수 있습니다.

중요

AWS에서는 루트 사용자 액세스 필요와 같이 필요한 경우에만 AWS STS 페더레이션 사용자를 사용하는 것이 좋습니다. 대신, 역할을 사용하여 권한 위임.

AWS STS 페더레이션 사용자 세션 보안 주체는 AWS STS GetFederationToken 작업을 사용하여 발생하는 세션 보안 주체입니다. 이 경우, AWS STS에서는 IAM 역할을 사용하는 대신 아이덴티티 페더레이션을 임시 액세스 토큰을 얻는 방법으로 사용합니다.

AWS에서 IAM 사용자 또는 AWS 계정 루트 사용자는 장기 액세스 키를 사용하여 인증할 수 있습니다. 이 작업을 사용하여 페더레이션할 수 있는 보안 주체에 대한 자세한 내용은 AWS STS 자격 증명 비교을(를) 참조하세요.

IAM 페더레이션 사용자 - IAM 사용자는 해당 IAM 사용자에 대한 페더레이션 사용자 세션 보안 주체를 생성하는 GetFederationToken 작업을 사용하여 페더레이션합니다.
페더레이션 루트 사용자 - 루트 사용자는 해당 루트 사용자에 대한 페더레이션 사용자 세션 보안 주체를 생성하는 GetFederationToken 작업을 사용하여 페더레이션합니다.

IAM 사용자 또는 루트 사용자가 이 작업을 사용하여 AWS STS에서 임시 자격 증명을 요청하면 임시 페더레이션 사용자 세션이 시작됩니다. 이 세션의 ARN은 페더레이션된 원래 자격 증명을 기반으로 합니다.

Principal 요소에서 페더레이션 사용자 세션 ARN을 지정하려면 다음 형식을 사용하십시오.


"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }

AWS 서비스 보안 주체

보안 주체를 지원하는 리소스 기반 정책이나 조건 키의 Principal 요소에 있는 AWS 서비스를 지정할 수 있습니다. 서비스 보안 주체는 서비스의 식별자입니다.

AWS 서비스에서 위임할 수 있는 IAM 역할을 서비스 역할이라고 합니다. 서비스 역할에는 신뢰 정책이 포함되어 있어야 합니다. 신뢰 정책은 역할을 수임할 수 있는 보안 주체를 정의하는 역할에 연결된 리소스 기반 정책입니다. 일부 서비스 역할에는 신뢰 정책이 미리 정의되어 있습니다. 그러나 신뢰 정책에 서비스 보안 주체를 지정해야 하는 경우도 있습니다. IAM 정책의 서비스 보안 주체는 "Service": "*"일 수 없습니다.

중요

서비스 보안 주체의 식별자에는 서비스 이름이 포함되어 있고 일반적으로 다음과 같은 형식을 갖습니다.

service-name.amazonaws.com

서비스 보안 주체는 서비스가 정의합니다. 일부 서비스에 대한 서비스 주체는 AWS IAM으로 작업하는 서비스을(를) 열고 Service-linked role(서비스 연결 역할) 열에서 서비스에 Yes(예)가 선택되어 있는지 확인한 다음 Yes(예) 링크를 열어 해당 서비스에 대한 서비스 연결 역할 문서를 통해 확인할 수 있습니다. 서비스 보안 주체를 보려면 서비스 연결 역할 권한 섹션을 참조하세요.

다음 예제는 서비스 역할에 연결할 수 있는 정책을 보여줍니다. 이 정책은 Amazon ECS 및 Elastic Load Balancing의 두 서비스가 역할을 수임할 수 있도록 합니다. 그러면 서비스가 해당 역할에 할당된 권한 정책에서 부여한 모든 작업을 수행할 수 있습니다(표시되지 않음). 여러 서비스 보안 주체를 지정할 때 Service 요소를 두 개 지정하면 안 됩니다. 하나만 지정할 수 있습니다. 대신 여러 서비스 보안 주체의 배열을 하나의 Service 요소의 값으로 사용합니다.


"Principal": {
    "Service": [
        "ecs.amazonaws.com",
        "elasticloadbalancing.amazonaws.com"
   ]
}

옵트인 리전용 AWS 서비스 주체

여러 AWS 리전에서 리소스를 시작할 수 있으며 이러한 리전 중 일부는 반드시 옵트인해야 합니다. 옵트인해야 하는 전체 지역 목록은 AWS 일반 참조 가이드의 AWS 리전 관리를 참조하세요.

옵트인 리전의 AWS 서비스가 동일한 리전 내에서 요청을 보내는 경우 서비스 주체 이름 형식은 해당 서비스 주체 이름의 리전별이 아닌 버전으로 식별됩니다.

service-name.amazonaws.com

옵트인 리전의 AWS 서비스가 다른 리전에 교차 리전 요청을 보내면 서비스 주체 이름 형식이 해당 서비스 주체 이름의 리전별 버전으로 식별됩니다.

service-name.{region}.amazonaws.com

예를 들어 Amazon SNS 주제가 리전 ap-southeast-1에 있고 Amazon S3 버킷이 옵트인 리전 ap-east-1에 있다고 가정해 보겠습니다. SNS 주제에 메시지를 게시하도록 S3 버킷 알림을 구성하려고 합니다. S3 서비스에서 SNS 주제에 메시지를 게시할 수 있도록 하려면 해당 주제의 리소스 기반 액세스 정책을 통해 S3 서비스 주체에게 sns:Publish 권한을 부여해야 합니다.

주제 액세스 정책에서 S3 서비스 주체 s3.amazonaws.com의 리전별이 아닌 버전을 지정하는 경우 버킷에서 주제로의 sns:Publish 요청이 실패합니다. 다음 예제에서는 SNS 주제 액세스 정책의 Principal 정책 요소에 리전별이 아닌 S3 서비스 주체를 지정합니다.


"Principal": { "Service": "s3.amazonaws.com" }

버킷은 옵트인 리전에 있고 요청은 동일한 리전 외부에서 이루어지므로 S3 서비스 주체는 리전별 서비스 주체 이름 s3.ap-east-1.amazonaws.com으로 표시됩니다. 옵트인 리전의 AWS 서비스가 다른 리전에 요청할 때는 리전별 서비스 주체 이름을 사용해야 합니다. 리전별 서비스 주체 이름을 지정한 후 버킷이 다른 리전에 있는 SNS 주제에 sns:Publish 요청을 하면 요청이 성공합니다. 다음 예제에서는 SNS 주제 액세스 정책의 Principal 정책 요소에 리전별 S3 서비스 주체를 지정합니다.


"Principal": { "Service": "s3.ap-east-1.amazonaws.com" }

옵트인 리전에서 다른 리전으로의 리전 간 요청에 대한 리소스 정책 또는 서비스 주체 기반 허용 목록은 리전별 서비스 주체 이름을 지정한 경우에만 성공합니다.

참고

IAM 역할 신뢰 정책의 경우 리전별이 아닌 서비스 사용자 이름을 사용하는 것이 좋습니다. IAM 리소스는 글로벌 리소스이므로 모든 리전에서 동일한 역할을 사용할 수 있습니다.

모든 보안 주체

와일드카드(*)를 사용하여 리소스 기반 정책의 Principal 요소 또는 보안 주체를 지원하는 조건 키에 모든 보안 주체를 지정할 수 있습니다. 리소스 기반 정책은 권한을 부여하고 조건 키는 정책 문의 조건을 제한하는 데 사용됩니다.

중요

퍼블릭 또는 익명 액세스 권한을 부여하려는 경우가 아니면 Allow 효과가 있는 리소스 기반 정책의 Principal 요소에 와일드카드(*)를 사용하지 않는 것이 좋습니다. 그렇지 않으면 Principal 요소에서 의도한 보안 주체, 서비스 또는 AWS 계정을 지정한 다음 Condition 요소에서 액세스를 추가로 제한하세요. 이는 특히 다른 보안 주체가 계정의 보안 주체가 될 수 있도록 허용하기 때문에 IAM 역할 신뢰 정책에 특히 해당됩니다.

리소스 기반 정책의 경우 Allow 효과와 함께 와일드카드(*)를 사용하면 익명 사용자(퍼블릭 액세스)를 포함한 모든 사용자에게 액세스 권한이 부여됩니다. 계정 내의 IAM 사용자 및 역할 보안 주체의 경우 다른 권한이 필요하지 않습니다. 다른 계정의 보안 주체의 경우 계정에 리소스에 액세스할 수 있는 자격 증명 기반 권한도 있어야 합니다. 이를 크로스 계정 액세스라고 합니다.

익명 사용자의 경우 다음 요소는 동일합니다.


"Principal": "*"


"Principal" : { "AWS" : "*" }

보안 주체 이름이나 ARN의 일부를 나타내기 위해 와일드카드를 사용할 수 없습니다.

다음 예제는 Deny와 함께 NotPrincipal 지정 대신 Condition 요소에 지정된 보안 주체를 제외한 모든 보안 주체를 명시적으로 거부하는 데 사용할 수 있는 리소스 기반 정책을 보여줍니다.


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
      "Effect": "Deny",
      "Action": "s3:*",
      "Principal": "*",
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket/*",
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
        }
      }
    }
  ]
}

추가 정보

자세한 내용은 다음 자료를 참조하세요.

Amazon Simple Storage Service 사용 설명서의 버킷 정책 예제
Amazon Simple Notification Service 개발자 안내서의 Amazon SNS에 대한 정책 예제
Amazon Simple Queue Service Developer Guide(Amazon Simple Storage Service 개발자 안내서)의 Amazon SQS policy examples(Amazon SQS 정책 예제)
AWS Key Management Service 개발자 안내서의 키 정책
AWS 일반 참조의 계정 식별자
OIDC 페더레이션

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

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

문서 규칙

Effect

NotPrincipal