An auditor in a separate account must inspect production resources as read-only.
Do not create the same long-term user in every account.
Which method is most appropriate?
Create a read-only role in the target account and let the auditor assume it with AWS STS, separating the trust relationship from the permissions.
Detailed explanation
A cross-account role and STS temporary credentials separate trust from permissions and avoid shared long-term users.
A cross-account role and STS temporary credentials separate trust from permissions and avoid shared long-term users.
Sharing root credentials violates least privilege, traceability, and credential protection.
Sharing root credentials violates least privilege, traceability, and credential protection.
Public access is not restricted to the auditor or to read-only use.
Public access is not restricted to the auditor or to read-only use.
Cross-account access also needs a trust and role configuration in the target account.
Cross-account access also needs a trust and role configuration in the target account.
Check official documentation
Compare the following points with the official documentation.
AWS STS AssumeRoleとクロスアカウントIAMロールの公式説明を確認する。
What to confirm
アカウント間のアクセスをロール引き受けと一時認証情報で設計できる。
Key points
- Cross-account role
- AWS STS
- Trust policy
- Temporary credentials
Notes
- Environment: AWS公式IAM・STSドキュメントの確認
- Confirm current AWS service behavior and security guidance in the official documentation.
Foundation review
Trust versus permission
The trust policy identifies who may enter the role; the permissions policy defines what the session may do.
Account boundary
The target account must participate in the cross-account configuration; a source-account policy alone is insufficient.