Multi-Account Boundaries

What Is Multi-Account Boundaries?

An account is the strongest blast-radius boundary a cloud provider gives you, and it holds only while the trust crossing it is scoped. Every role carries two policies: what it can do, and who may become it. A tight permissions policy on a role the whole organization may assume is no boundary. You'll read a cross-account trust policy that names the org with no condition and assume your way into production. Remediation is two layers: a named principal with a condition, then an SCP ceiling above the account itself.

What You'll Learn in Multi-Account Boundaries

• A role has two policies: one for what it can do, one for who may become it. A tight permissions policy on a role anyone can assume is still a problem.
• A trust policy naming the whole organization lets the weakest account define the security of the strongest.
• An account contains a compromise by default, unless a trust relationship was created to cross it.
• A service control policy sets a ceiling above the account, so a member-account administrator cannot grant the permission back.

Multi-Account Boundaries — Training Steps

1. The cheapest door in

   Bob is not in production. He is in Dremwick's sandbox account, holding a CI runner credential that leaked in a public build log. Sandbox holds nothing worth stealing, which is exactly why nobody watches it closely. He starts by asking what else the organisation contains.

2. A door with the whole account on the guest list

   Bob looks for roles in prod that dev is allowed to assume. He finds one meant for audit tooling, and reads its trust policy.

3. Walk through it

   Bob assumes the role. Nothing exotic: the trust policy says his account is welcome, so AWS hands him production credentials.

4. What prod looks like from inside

   The assumed session is an ordinary production principal now. Bob asks what it can see.

5. Every contract Dremwick holds

   The contracts export is the commercial core of the business: who buys the power, at what price, for how long. Bob streams it straight to his terminal.

6. What actually failed?

   Before the response, name the failure precisely.

7. Our pricing is in someone else's bid

   Dremwick lost a tender to a rival whose bid undercut them by a margin that only makes sense if the rival knew their strike prices. Commercial escalated it; the trail leads back to a session in the production account that came from dev.

8. Open the organisation

   Alice opens the organisation view: the account tree, the trust policy on the cross-account role, and the guardrails above each organisational unit.

9. The whole account on the guest list

   The trust policy is the hole. It names the dev account, not the tool that was supposed to use it.

10. Name the one principal that may cross

    Alice rewrites the trust policy so it names the audit tooling role specifically, and requires an external id that only that tooling knows.