Cloud Security Best Practice: Limit Blast Radius with Multiple Accounts
This is one of those ideas that I’m pretty sure I picked up on while either at a presentation or working with a client, but I honestly can’t remember where I first heard it. That said, it’s become one of my absolutely essential cloud security recommendations for years now. It’s also a great example of using the cloud for security advantage, rather than getting hung up on the differences. I do know that I first heard the term blast radius from Shannon Lietz over at DevSecOps.org. Here’s the concept: Accounts at each cloud provider are completely segregated and isolated from each other. That is a core capability for multitenancy. It’s also the kind of thing a cloud provider can’t screw up if they want to stay in business. There is nothing limiting you from buying multiple accounts from a cloud provider. Heck, that’s sometimes kind of the problem, since any old employee (especially those developers) can sign up with nothing more than an email address and a credit card. Some cloud providers allow you to communicate across accounts. This is usually pretty restrictive, and both sides need to set it up, and only for very specific things. But these ‘things’ can include cross-connecting networks, migrating storage, or sharing other assets. Super admin (root) accounts are distinct for each account, and can’t be bridged. Thus you can use cloud provider accounts to segregate your environments! This seriously limits the blast radius of any security events, since there’s no way to bridge between accounts except those specific connections you allow. Use of multiple accounts is often an operational best practice anyway. I currently recommend multiple accounts per project for different environments (e.g. dev/test/prod/sec_monitoring). For me this started as a way to limit administrator activity. You can allow developers full admin access in their dev environment, but lock things down in test, and then lock them out completely in production. DevOps techniques can handle moving code and updates across environments. But talking with admins who manage much larger environments than I do emphasized how powerful this is in limiting security incidents. Some companies have hundreds, if not thousands, of accounts. If something bad happens, they blow the entire account away and build it from scratch. Clearly you need to be using automation and immutable infrastructure to pull this off. But think about the advantages. Every project is isolated. Heck, every environment is isolated. It makes it nearly impossible for an attacker to move laterally. This makes network segregation look passe. What’s the downside? This is much harder to manage, since there is no centralization. It absolutely relies on automation. You need to be super careful with your automation, so that doesn’t become the single point of failure. Not all cloud providers support it. I don’t know any large-scale cloud operations that haven’t eventually ended up with this approach. Even most new cloud projects on a smaller scale start this way, purely for operational reasons, if they use any kind of continuous delivery/deployment (DevOps). Think of accounts as disposable, because they are. Share:
