Between teaching classes and working with clients, I spend a fair bit of time talking about particular cloud providers. The analyst in me never wants to be biased, but the reality is there are big differences in terms of capabilities, and some of them matter.
Throwing out all the non-security differentiators, when you look at cloud providers for enterprises there are some critical security capabilities you need for security and compliance. Practically speaking, these quickly narrow down your options.
My criteria are more IaaS-focused, but it should be obvious which also apply to PaaS and SaaS:
- API/admin logging: This is the single most important compliance control, a critical security control, and the single biggest feature gap for even many major providers. If there isn’t a log of all management activity, ideally including that by the cloud provider itself, you never really know what’s happening with your assets. Your only other options are to constantly snapshot your environment and look for changes, or run all activity through a portal and still figure out a way to watch for activity outside that portal (yes, people really do that sometimes).
- Elasticity and autoscaling: If it’s an IaaS provider and it doesn’t have autoscaling, run away. That isn’t the cloud. If it’s a PaaS or SaaS provider who lacks elasticity (can’t scale cleanly up or down to what you need), keep looking. For IaaS this is a critical capability because it enables immutable servers, which are one of the cloud’s best security benefits. For IaaS and PaaS it’s more of a non-security advantage.
- APIs for all security features: Everything in the cloud should be programmatically manageable. Cloud security can’t scale without automation, and you can’t automate without APIs.
- Granular entitlements: An entitlement is an access right/grant. The provider should offer more than just ‘admin’. Ideally down to each feature or API call, especially for IaaS and PaaS.
- Good, easy, SAML support that maps to the granular entitlements: Federated identity is the only reasonable way to manage all your users in the cloud. Fortunately, we nearly always see this one available. Unfortunately, some cloud providers make it a pain in the ass to set up.
- Multiple accounts and cross-account access: One of the best ways to compartmentalize cloud deployments is to use entirely different accounts for different projects and environments, then connect them together with granular entitlements when needed. This limits the blast radius if someone gets into the account and does something bad. I frequently recommend multiple accounts for a single cloud project, and this is considered normal. It does, however, require security automation, which ties into my API requirement.
- Software Defined Networking: Most major IaaS providers give you near complete control over your virtual networks. But some legacy providers lack an SDN, leaving you are stuck with VLANs or other technologies that don’t provide the customization you need to really make things work. Read my paper on cloud network security if you want to understand more.
- Regions/locations in different countries: Unless the cloud provider only want business in their country of origin, this is required for legal and jurisdictional reasons. Thanks to Brian Honan for catching my omission.
This list probably looks a hell of a lot different than any of the other ones you’ve seen. That’s because these are the foundational building blocks you realize you need once you start working on real cloud projects.
I’m probably missing some, but if I break this out all I’m really talking about are:
- Good audit logs.
- Decent compartmentalization/segregation at different levels.
- Granular rights to enforce least privilege.
- A way to manage everything and integrate it into operations.
Please let me know in the comments or via Twitter if you think I’m missing anything. I’m trying to keep it relatively concise.
Reader interactions
4 Replies to “Critical Security Capabilities for Cloud Providers”
I must be missing something. Hasn’t the provider solved the biggest problem already by authenticating the user and ensuring whether this specific account is authorized to perform the requested task? Doesn’t the provider have the information ‘account x has performed activity y to instance z at time/date’?
It feels like all disparate services need to centralize at least for authentication and authorization at one point and should be able to log then.
Or is the logging usually happening in the background, completely isolated from the account authentication and provisioning? That would indeed cause quite a challenge.
It is actually a VERY hard problem in a large multi tenant environment. How to you capture and segregate it out? How do you consistently capture it across multiple, disparate services? I hear it takes years to implement.
“API/admin logging: This is the single most important compliance control, a critical security control, and the single biggest feature gap for even many major providers”
This just blows my mind! This should be the easiest to implement, given the centralized and standardized interfaces and it is indeed the most important control that allows you to keep your provider (and your admins) honest. Anything satisfying you hear from providers on why they suck at this?
“If it’s an IaaS provider and it doesn’t have autoscaling, run away. ”
You probably mean “API based provisioning”. If you don’t have that in IaaS, you are playing with demoware. Autoscaling can be a third party plug on if you have API based provisioning.
Other than that: great post!