Every cloud tool you have trialled probably still holds a role in your AWS account. Cost optimisation platforms, monitoring products, backup services and security posture tools all work the same way: you create a role, their account assumes it, and the access continues until somebody removes it. CISA’s recommended practices for identity and access management make the point that third-party access needs the same lifecycle as employee access, and it rarely gets it.
How much access these roles usually have
More than the product needs, because vendors ask for a managed policy that covers every feature they might offer. Read-only sounds harmless until you consider what reading includes: configuration of every resource, contents of parameter stores where teams put credentials, function code, database snapshots metadata and user policies that describe your entire permission model. A monitoring tool with broad read access has enough information to plan an attack even without write permissions, and several products request write access for remediation features nobody enabled.
The trust policy is the part to read
Permissions decide what the role can do and the trust policy decides who can assume it. Two failures recur. The first is a trust policy naming a vendor’s account without requiring an external identifier, which leaves you open to a confused deputy problem where another customer of the same vendor can request access to your resources. The second is a wildcard principal, which allows any AWS account to assume the role, and that appears more often than it should in roles created hastily from a documentation example.
“List every role in your accounts whose trust policy names an account you do not own, then match each one to a live contract. In most reviews at least one belongs to a product the client stopped using, and nobody can say whether that vendor still exists. A role with no owner and no contract is standing access granted to a stranger.”
See also: Fly Business Class to India on a Budget: Secrets Airlines Don’t Tell You
William Fieldhouse, Director, Aardwolf Security Ltd
Conditions worth adding
Require an external identifier for every third-party role, generated by you and unique per vendor. Add condition keys restricting which source resources may be used where the vendor supports it, and consider restricting by source address for products that connect from a stable range. Enable CloudTrail alerting on assume role events from external accounts, since legitimate use follows a pattern and an assumption at an unusual hour from an unfamiliar address is worth a question. None of this stops a compromised vendor, and all of it narrows what a compromise reaches.
Recertification and offboarding
Review third-party roles twice a year alongside your supplier list, and treat the end of a contract as an event that removes access rather than an accounting change. Ask each vendor what they store from your environment and where, since a posture tool holding a copy of your configuration is holding a map of your estate. An AWS penetration testing engagement will show what each role can actually reach, which is usually more than the vendor’s documentation suggests, and an accredited testing company can help you set the conditions that keep the useful access without the rest.
Frequently asked questions about vendor cloud access
These questions come up whenever a cloud supplier review takes place.
Is read-only access low risk?
It is lower risk than write access and not low risk. Configuration data, code and metadata are enough to plan an intrusion, and read permissions on parameter stores or secrets managers can expose credentials directly.
Should vendors have permanent roles at all?
For continuous products, yes, with conditions and monitoring. For occasional work such as a migration or an assessment, create the role for the engagement and delete it afterwards rather than leaving it dormant.
