Hey You, Get Out of My Cloud!

Written by Jim Mandelbaum, Gigamon Field CTO

When we take a cloud solution to production how do we know who has access to that data? The process of deploying the production environment has certainly involved several groups and individuals. Who still has access and what can they do with it? How do we know?

When we think of moving to the cloud, we primarily focus on getting the sizing right, the networks communicating and the data paths robust enough to support the planned traffic load. We focus on the costs associated with running the services and most importantly we are hopefully looking at leveraging automation.

Who has access to what?

When the cloud architecture is being built, it has a team that usually focuses on the networking rules and limitations. The developers are focused on ensuring the applications have the rights needed to properly share data between the services. Who is looking at how those rights overlap? Who is tracking the over-provisioned, or temporarily provisioned accounts and users? This is a common theme and why vendors always harp on the “Shared Responsibility Model”

What about the Shared Responsibility Model?

I think it’s always important to remind folks about the Shared Responsibility Model. It’s important to remember that the vendors don’t care about the data once you store or move it on their network. Their job is to provide you the ability to deploy your data and applications easily and provide redundant infrastructure that is always up and running. That’s about the extent of their responsibility. This is something that cross-functional teams need to understand as they deploy your cloud services, as most don’t know, or have been explained, this fact.

Getting back to the who has access

When we look at the network post-deployment, we need to understand who still has access to the resources. Did the developers’ rights get removed after they did their work? A common mistake in cloud deployments is retaining developer permissions/rights in a production environment; this creates not only security risk, but also data integrity problems, and also tends to violate compliance mandates. Developers should never have access to production data; they should be limited to a QA/test and Dev environment scope.

Another overlooked risk is around the accounts used for non-life form entitles, service accounts. When we start providing automation in the cloud there is always a need to have roles with rights to do certain things. These roles then get entitlements assigned to them to perform certain tasks. How often do we audit these accounts? Do they have the least privileges to do what is needed? Are they over-provisioned?

Quite often there is a simple role that is used by many services that has high levels of rights to make development automation easier. Is this the right way to proceed, or is having a few different roles that are more granularly defined a more secure option? One best practice is to always allocate a service account to a role to ensure easy management as well as understanding of the abilities of the account. Documenting and securing roles to insure they are not modified is also important.

Involve the teams early

Typically, these questions get asked by the Identity and Access teams but quite often they are not involved with cloud operations. Being able to ask the question “who has access to what and what can they do with it” is often overlooked in the cloud. Asking these questions early with the development teams, the architecture teams, and the cloud teams will insure a smaller threat landscape in the end. Get everyone involved at the start and make it everyone’s responsibility to limit rights in your cloud deployment