설명
역할 신뢰 정책에서 Principal을 와일드카드로 지정하면 의도하지 않은 주체까지 신뢰 대상에 포함될 수 있습니다. 실제 역할 수임은 작업, 조건, 호출자 권한 등에도 달려 있으므로 전체 신뢰 관계를 확인해야 합니다.
IAM 관리형 정책에는 Principal을 넣을 수 없습니다. 관리형 정책은 연결된 신원의 작업 권한을 정하고, 역할 신뢰 정책은 누가 역할을 맡을 수 있는지 정합니다. 서비스 작업 허용과 sts:AssumeRole 신뢰를 구분하세요.
잠재적 영향
- 넓은 신뢰 관계와 필요한 호출 권한이 함께 충족되면 승인하지 않은 주체가 역할 권한을 사용할 수 있습니다.
- 잘못된 정책 유형에 주체를 넣으면 정책 배포가 실패하고 의도한 접근 통제가 적용되지 않을 수 있습니다.
해결 방법
- 정책 유형을 확인하고, 역할 수임 대상은 역할의 신뢰 정책에서 승인된 역할 ARN 또는 서비스 주체로 제한하세요.
- 교차 계정 접근은 호출자 권한과 신뢰 조건을 함께 검토하세요. 여러 고객을 대신하는 서드파티 위임에는 실제 제공자가 관리하는 고객별 외부 ID를 적용하세요.
- 역할 자체의 작업 권한도 최소화하고 정상 수임과 승인하지 않은 요청의 거부를 시험하세요.
예시
첫 예시는 관리형 정책에 허용되지 않는 Principal을 넣은 잘못된 구성입니다. 두 번째는 EC2를 위한 역할 신뢰 정책이며 역할 권한과 인스턴스 프로파일 연결은 생략했습니다. 기존 역할을 변경할 때는 전체 신뢰·권한 구성을 검토하세요.
변경 전
yaml
- name: IAM 정책 생성
community.aws.iam_managed_policy:
policy_name: ManagedPolicy
policy:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action: logs:CreateLogGroup
Resource: "*"
Principal:
Service: ec2.amazonaws.com
AWS: "*"
make_default: false
state: present
이 관리형 정책은 유효하지 않으며 logs:CreateLogGroup도 역할 수임 작업이 아닙니다. 이 구성으로 역할 신뢰가 생성되지는 않습니다.
변경 후
yaml
- name: Configure EC2 role trust
amazon.aws.iam_role:
name: ec2-service-role
assume_role_policy_document: >
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {"Service": "ec2.amazonaws.com"}
}
]
}
state: present
역할 신뢰를 EC2 서비스로 한정합니다. 실제 EC2 워크로드에 필요한 권한만 별도로 부여하세요.