説明
ロールの信頼ポリシーで 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 ワークロードに必要な権限だけを別途付与してください。