Another day, another cloud security mishap. Some company exposes recordings of your kids to the Internet and then comes under Senatorial scrutiny. A security firm managing security clearance information turns out to be insecure.
Well, this cloud business is hard, isn’t it? There are lots of moving parts and they’re all buried under lots of other moving parts, so that you can’t even see half of them! We’re not sure that excuses a cloud-native firm getting its account hijacked so badly that it goes out of business, though.
It’s easy for admins to avoid anything other than basic configuration, or to assume that their cloud provider has them covered. It’s not actually Amazon’s fault if you leave an S3 bucket spilling your data all over the Internet, though. They just provide the infrastructure. What you do with it is up to you, and it’s important to understand where the cloud service provider’s responsibility ends and yours begins.
How can you manage a cloud technology stack properly and keep its various parts humming along securely, amid all this complexity?
Jim Reavis, founder and CEO of the Cloud Security Alliance, says that the cloud stack layers new levels of functionality atop old ones. It may start with the physical layer, but managing the creation, moving and destruction of virtualized operating systems and applications introduces more levels.
The stack becomes more complex as the industry invents more layers in the cake. “Some of the new layers on top of that are serverless, like containerization,” he says. Then, let’s not forget the various shared storage components and databases that these layers use.
“The layers of abstraction are all about simplifying activities for developers, operations and management,” he adds. “You’re trying to make some of the lower areas places where you don't necessarily touch.”
Say hi to your API
Instead of handling these lower levels of the cloud directly, the API becomes an important tool in accessing different layers of the stack. It’s the lingua franca for developers and operators that want to manipulate infrastructure, and as such it’s the key to the kingdom.
That makes securing the APIs important. Start by authenticating the client, and then enforce SSL encryption to ensure that the client is talking to an authenticated server.
Commercial identity and access management (IAM) tools can handle authentication, meaning that you don’t have to code it directly into the API. This has two advantages. The first is that you don’t have to maintain authentication code that has been implemented in duplicate across a range of applications and interfaces. The second is that you can fold the client/server authentication process into a broader user identification system.
Finally, on the API security side proper vulnerability management and patching of the infrastructure hosting the API is a crucial part of the security process. While APIs may be the major touchpoints for developers and operations staff in a cloud environment, it’s still important to understand and secure each of the layers on which they rely.
Putting a hard shell around each component
Hardening components at each layer of the technology stack is important. Virtual machines should be security hardened, as should containers.
Other aspects of the cloud stack that should be hardened include your servers, applications and underlying databases. Automate compliance by codifying the rules for hardening your system as configuration parameters into your software. This will be more efficient than imposing security rules as written policies that business departments can ignore.
The hardened configuration can be audited at set intervals to ensure that the system is taking the security measures it is supposed to. If there are any problems, you can use configuration management tools to correct things and ensure that your cloud-based infrastructure is compliant with the necessary rules. This automation concept underpins the DevOps discipline, and it is a crucial part of a cloud deployment.
Automate all the things
Automation supports the idea of continuous deployment that lies at the heart of a well-managed cloud infrastructure, says Reavis.
“The traditional software development ecosystem is just a few updates annually,” he adds. “What is most typical in a continuous deployment model in cloud is several updates a week or even a day.”
Using automated cloud management tools is a way to tighten up that deployment and ensure that the many moving parts in the underlying cloud stack supports it properly.
In a clean continuous improvement/deployment pipeline, automation can help a team re-mediate any deviation from system hardening guidelines in minutes rather than hours.
Automation can help weed out human error in configuration. Cloud admins shouldn’t overlook its importance here. Each layer is a foundation for the one above it, and should introduce security measures appropriate for that layer that more abstracted layers can rely on, but there’s another rule to follow: one component shouldn’t break another’s security.
Unfortunately that happens all-too often, in ways that seem subtle internally, but have apocalyptic effects externally. Poorly configured parts of the technology stack can allow people to do some bizarre things. A configuration mishap can leave storage instances open to the world or NoSQL databases serving up records to whoever wants it through a publicly exposed interface. You don’t want your servers showing up on Shodan simply through a lack of training.
There’s an extra measure to secure data should you overlook a misconfigured cog in your cloud stack, of course: encrypt the darn stuff.
This becomes particularly important in a cloud environment which will typically rely on shared storage. Because you don’t have control over the physical storage, encrypting that data is a sensible approach to avoid any problems with unauthorized access.
The other part of the equation is encryption key management. This means not leaving the encryption keys in your cloud service provider’s ignition. Store them yourself, properly, in a hardware security module or virtual HSM.
For every component of the cloud stack, then, there already exist the tools to help you lock things down. From IAM to automated deployment, from configuration management to encryption, there are options from different providers, many of which may be open source.
There are broad guidelines you can subscribe to and follow to help secure a cloud-based stack of moving parts. These include the CSA’s Security Guidance for Critical Areas of Focus in Cloud Computing v4.0 that was released in July. Beyond this, thought, the implementation details will be platform specific and will leave you reaching for separate guidelines.
These exist for OpenStack, Microsoft’s Azure, and Amazon’s AWS. A mixture of general best practice and platform-specific implementation will help you avoid becoming the next headline.
As Reavis puts it, there was at the start of cloud a notion that these things would be vanilla. They aren’t, making it vital you go beyond the default settings in any mixed cloud.
This article was supported by: Rackspace