At the recent RSA 2019 show in San Francisco, I was talking to an IT director who stopped by our booth about how his organization secures its public cloud deployments. He told me that “We have over 500 separate AWS accounts in use, it helps all our development and cloud teams to manage the workloads they are responsible for without crossover or account bloat, and it also makes it easier to control cloud usage costs: all the accounts are billed centrally, but each account is a separate cost center with a clear owner”.
I asked about security, and he replied that each account had different logins, meaning fewer staff had access to each account, helping to protect each account. While it’s true that having hundreds of separate public cloud accounts will help to keep a closer eye on cloud costs, it also creates huge complexity when trying to manage the connectivity and security of applications and workloads. Especially when making changes to applications that cross different public cloud accounts, or when introducing infrastructure changes that touch many – or even all- accounts.
As discussed in our recent blog on public cloud security, securing applications and data in these environments can be challenging. It’s far easier for application teams to spin up cloud resources and move applications to them, than it is for IT and security teams to get visibility and control across their growing cloud estates.
Even if you are using a single public cloud platform like AWS, each account has its own security controls – and many of them. Each VPC in every region within the account has separate security groups and access lists: even if they embody the same policy, you need to write and deploy them individually. Any time you need to make a change, you need to duplicate the work across each of these elements.
Then there’s the question of how security teams get visibility into all these cloud accounts with their different configurations, to ensure they are all properly protected according to the organization’s security policy. It’s almost impossible to do this using manual processes without overlooking – or introducing – potential vulnerabilities.
So how do the teams in charge of those hundreds of accounts manage them effectively?
Here are my three key steps:
The first challenge to address is a lack of visibility into all your AWS cloud accounts, from one vantage point. The security teams need to be able to observe all the security controls, across all account/region/VPC combinations.
The majority of network security policy changes need to touch a mix of the cloud providers’ own security controls as well as other controls, both in the cloud and on-premise. No cloud application is “an island” – it needs to access resources in other parts of the organization’s estate. When changes to network security policies in all these diverse security controls are managed from a single system, security policies can be applied consistently, efficiently, and with a full audit trail of every change.
In order to manage multiple public cloud accounts efficiently, automation is essential. Security automation dramatically accelerates change processes and enables better enforcement and auditing for regulatory compliance. It also helps organizations overcome skill gaps and staffing limitations.
With an automation solution handling these steps, organizations can get holistic, single-console security management across all their public cloud accounts, as well as their private cloud and on-premise deployments. For more tips and best practices, check out my whiteboard video lessons which show how to manage security efficiently across hybrid environments which use AWS.
Receive notifications of new posts by email.