In the cloud, organizations almost never work alone. Monitoring tools, data platforms, backup services and security products need access to the customer's cloud account to do their job. The common way to grant that access in AWS is called a cross-account role: the customer defines a role in its account with certain permissions and specifies that 'the vendor's AWS account may use this role.'
The advantage is clear: the customer does not need to hand the vendor passwords or permanent keys, and can revoke access at any moment. It is safer than the alternatives, and cloud providers recommend it. But it has a built-in weak point: the customer's security depends on the vendor's. Whoever gains access to the vendor's account can exploit every role all customers set up for it, all at once.
That is exactly what happened in the attack through Qubole, exposed this week by Wiz and Sentra: an attacker used credentials from an account linked to the vendor and got into many customers' accounts. And there is another problem: such roles stay in the account even after the organization stops working with the vendor, unless someone remembers to delete them. Large organizations sometimes have dozens of such roles, for vendors nobody remembers anymore.
How do you reduce the risk? First, inventory: know which roles exist, which vendor each belongs to and when it was last used. Cloud providers show this information, and cloud security tools do it automatically. Second, least privilege: a vendor that needs to read data from one folder does not need access to all storage. Third, narrow the trust: instead of trusting the vendor's entire account, trust only the specific identity it uses, and add a unique identifier (External ID) where the vendor supports it.
And the most important rule: managing vendor access is a process, not a one-time setting. Just as you deactivate a departing employee's badge, you must delete the access of a vendor whose contract has ended. In this week's attacks, that forgetfulness was the breach.
