As much as we love to be the masters of the obvious, we don’t really need to discuss the movement to cloud computing. It’s happening. It’s disruptive. Blah blah blah. Finding someone to dispute any of that can be challenging, but clearly when the computing power and storage delivering your key IT services may or may not reside in a facility you control, things are a little different. The idea of a privileged user morphs in a cloud context by adding another layer of abstraction via the cloud management environment. Thus regardless of your adoption of cloud computing at this point, you’ve got to factor the cloud into your PUM (privileged user management) initiative.
Or do you? Let’s play a little Devil’s advocate here. When you think about it, isn’t cloud computing just more happening faster? You still have the same old operating systems acting as guests in a public or private cloud environment, but with an enhanced ability to spin up machines much faster than ever before. If you are able to provision and manage the entitlements of these new servers, it’s all good, right? Simplistically, yet. But in reality the same old same old won’t work in this new reality. Though we do appreciate the perspective of the ostrich. Unfortunately burying your head in the sand on cloud privileged users won’t change the situation. Let’s take a look at how cloud computing is fundamentally different than the physical world.
Cloud Risks
First of all, any cloud initiative adds another layer of management abstraction. You manage cloud resources though either the virtualization console (like vCenter or XenCenter) or a public cloud management interface. This adds a new set of privileged users and entitlements requiring management. Moreover, this cloud stuff is (relatively) new and as such, management capability lags well behind what you get in the traditional data center. That doesn’t mean cloud management isn’t evolving rapidly (it is), but the tools and processes just aren’t there to the same degree, which introduces risk to the environment.
For example, without proper entitlements set, anyone gaining access to the cloud console can create and tear down any instance in your account. Or they can change access keys, add access or entitlements, change permissions, etc for the entire virtual data enter. Again, this doesn’t mean you shouldn’t move forward full speed ahead with cloud initiatives. It just means you need to take due care to not introduce unintended consequences from the flexibility of the cloud model.
You also have a number of new risks driven by the flexibility of provisioning new computing resources. Any privileged user could spin up a new instance and that instance may not include proper agentry/instrumentation to plug into the cloud management environment. Remember, you don’t have the coarse control of network access to protect the environment. Management and security largely needs to be implemented within the instances, and can’t rely on the cloud infrastructure to provide it. All of this again provides the urgency to implement proper protections for cloud console.
Thus you’ll want to take a similar lifecycle approach to protecting the cloud console as you do with more traditional devices.
The Lifecycle in the Clouds
To revisit our earlier research, the Privileged User Lifecycle involves restricting access, protecting credentials, enforcing entitlements, and monitoring P-user activity, but adding the complexity of the cloud context. What does that look like?
Restrict Access (Cloud)
As in the physical world you’ve got a few options to restrict access to sensitive devices, which vary dramatically whether you talk private cloud or public cloud. To revisit, you can implement access controls within the network, on the devices themselves (via agents), or run all connections through a proxy of sorts and only allow management connections via the proxy.
Private cloud console: For the most part, the same tactics describe in the Restrict Access post work, but with caveats. Network access control gets a lot more complicated with the inherent abstraction of the private cloud. Agentry requires pre-authorized instances that have the proper software. If you consider a proxy, you’ll also need some kind of agent on the instance to lock management connections to the proxy. But that’s required in the traditional datacenter. The difference is the need for tight integration with the cloud console. As instances come and go, knowing the instances are there and which policy groups the devices require is the challenge. To fill this gap, third party cloud management software providers are emerging to add finer grained access control to private cloud environments.
Public cloud console: Obviously restricting access within the network is a non-starter in the public cloud. You can set up specific security groups to restrict traffic and do have some granularity as to what IP addresses and protocols can access the instances, which would be fine in a shared administrator context. But you aren’t able to restrict access to specific users on specific devices (required by most compliance mandates) at the network layer because you have little control over the network in a public cloud. That leaves us with agentry on the instances, but little ability to stop an unauthorized party from accessing the instance. Another less viable option is a proxy, and you can’t really restrict access per se as the console literally lives on the Internet. So you’ll need to use the other aspects of the lifecycle to protect the instances in a public cloud environment.
Though there are some areas of innovation emerging relative to cloud management, including the ability to manage on demand. This means access to manage instances (usually via SSH on Linux instances) is off by default. Only when management is required would the cloud console open up a management port(s) via policy and only for certain authorized users at specific times. That approach address a number of the challenges with always on/always accessible cloud instances, and as such looks to be an interesting model for managing the cloud moving forward.
Protect Credentials (Cloud)
When you think about protecting the credentials to cloud computing resources, you’ve got an expanded idea of credentials. Basically now you need to worry about three groupings of credentials:
- Credentials for the cloud console(s)
- Credentials for instances
- Credentials for API access
The real question is which of these groups can (and should) be stored in a password vault as described in the Protect Credentials post. Optimally the answer is yes, for everything. But in reality it’s not so simple. The most straightforward credential to store in the vault is the console credential. For a private cloud environment, gaining access to the vault is no different than accessing traditional data center devices, so that’s not an issue.
It’s a little more complicated for public cloud, as you’d need to log into the proxy or have the credentials transferred to an agent on your device if you opt for an device-based approach. In both cases it’s achievable, and given the capabilities of the cloud console, recommended. Another option is to rely on Federation to allow existing trusted credentials to be used to federate access to the cloud console. For example, Amazon AWS supports Federation within their Identity Management features, so that is another option to use existing credentials for access to the cloud console.
In terms of accessing cloud instances through a vault, it’s possible but will take some work. Basically upon starting an instance, you’d need to have the credentials sent and stored within the vault. So the instance would have to have some means to bootstrap the credential generation and storage process. Clearly something that can be automated. The proxy (or agent on administrator’s device) would manage the keys for access, as well as the root/administrator account credentials. Will this add some latency, especially in a public cloud context? Maybe, and as such needs to be weighed versus the security risks of sharing root account, which we covered in the Introduction to this series.
Finally, what about API access? This would require a similar capability to how the password vaulting products support applications today. Basically the credentials are stored in the vault and the application makes a call to the vault to get the credential, the credential is then securely transferred to the application, which then uses the credential. In the case of the cloud management API, the automation capability would need to make a call to the vault to get the API credentials and then use the credentials accordingly. So this requires a bunch of integration that either you’ll have to do, or the vaulting vendor does it. At this point, we’re not familiar with any vault vendor that has done this integration with a cloud services API yet, but we figure it’ll happen soon, given the market adoption of the public cloud platform.
Enforce Entitlements (Cloud)
Once the administrator gains access to the instance, how can you enforce finer grained controls? Remember, without proper entitlements anyone with access to the cloud console can do pretty much anything. Some of the more mature and robust public cloud providers do provide the ability for finer grained control, but it’s largely a manual process. In private cloud-land, you’re still dealing with a rapidly maturing environment where a lot of the capabilities just aren’t there yet, including limitations on the capabilities offered by the virtualization platform vendors. Thus the emergence of third party offerings to fill this gap, both on the private and public cloud fronts. Do we believe these fine-grained control capabilities need to be integrated features of the cloud management console? Of course, and we expect that to happen over time. But for the time being, to gain true control over who can do what within your cloud environment, you’ll need to look at a third party offering.
In terms of some of the command blocking features to control what an administrator can do on an instance (as described in the Enforce Entitlements post), the approach is the same as in the physical world. You’ll need to either install an agent on the instance that pulls the policy from the management console, or you route the management traffic through a proxy that would block unauthorized commands. Does the cloud architecture complicate things? A bit, in that routing management traffic through a central point could add latency, but again it’s a tradeoff of latency versus security.
Monitor Privileged Users (Cloud)
Similar to enforcing entitlements, privileged user monitoring in the cloud involves the same decision points as in the physical world. In terms of recording sessions, routing through the proxy involves the same tradeoff (latency and possible inconvenience vs. security). And recording via a device-based agent could exact a performance toll on the instance.
The real tradeoff has to do with storing the logs/sessions. Do you aggregate in the cloud or send back to a central location, perhaps causing latency or additional network traffic? Of course, there are storage security and integrity requirements that required for any cloud-based repository, which may favor a centralized, on-premise option that can be more easily controlled.
The Need for Consistency
Regardless of how you decide to manage privileged users on cloud-based instances, we can’t stress the importance of consistency enough. The eventual goal is to set one policy for privileged users and enforce it consistently everywhere. Right now, that involves using multiple tools for the various steps in the PUM lifecycle, which is predictable given the early stage of the cloud computing market. Over time we expect better integration between PUM offerings focused on traditional data centers and those built for the cloud. Though do be wary of the potential for vendors to cloud-wash their offerings, alleging support for cloud computing, but really just implementing the same product on cloud instances.
You’ll want to look for integration with the cloud consoles and cloud APIs as a start. Without support for those functions, you are missing an entire area of exposure.
Speaking of integration, no management capability can stand alone. So we’ll wrap up the series with a look at enterprise integration and what other system management functions the PUM tools need to support to be useful in the enterprise context.
- Mike Rothman (0) Comments
