What steps should the Engineer perform to prevent this outcome?
Create an IAM user and generate a set of long-term credentials. Provide the credentials to AnyCompany. Monitor access in IAM access advisor and plan to rotate credentials on a recurring basis.
Request an external ID from AnyCompany and add a condition with sts:Externald to the role’s trust policy.
Require two-factor authentication by adding a condition to the role’s trust policy with aws:MultiFactorAuthPresent.
Request an IP range from AnyCompany and add a condition with aws:SourceIp to the role’s trust policy.
Explanations:
Creating an IAM user with long-term credentials does not address the primary concern of protecting the role ARN from being deduced by other customers of AnyCompany. This approach may also lead to credential leakage and does not offer best practices for AWS security.
Requesting an external ID and adding it as a condition in the role’s trust policy helps prevent the “confused deputy problem.” This ensures that only the legitimate client (Example Corp.) can assume the role by requiring knowledge of the external ID, thus enhancing security against unauthorized access.
While requiring two-factor authentication (MFA) adds an extra layer of security for user access, it does not specifically address the risk of other customers deducing the role ARN. The MFA condition would not prevent the role ARN from being potentially exposed.
Requesting an IP range and adding it to the role’s trust policy may limit access based on IP address but does not secure the role ARN itself from being deduced by other customers. This approach also risks locking out legitimate users if their IP changes.
As I see it, the answer is:
Request an external ID from AnyCompany and add a condition with sts:Externald to the role’s trust policy.