Security In the Enterprise Public Cloud

We listed the following areas that need to be “solved” to enable enterprise public cloud:

• Management and monitoring
• Flexibility
• Security / privacy
• Data separability
• Service separability
• Redundancy, backup, reliability

Let’s drill into security and privacy.

“Traditional” security within an enterprise is border-and-access-based. The edge of the corporate network is a heavily fortified firewall. Within the enterprise, much data flows over the network in unencrypted “in the clear” form. Access to individual servers, data repositories, network devices, or applications and services is provided via a username/password scheme; typically, username/password is centralized to a single-signon-username+password-system such as Microsoft’s Active Directory, with group membership and/or roles in the central repository defining access for each user. Data is typically not encrypted when stored. Physical access to the data is guarded by locked server rooms or locked server cabinets.

Very little of this traditional model can survive the move to the cloud.

While the “border” concept can be emulated by using a virtualized private area in the cloud with virtualized private network tunnel between enterprise network and the cloud, this is quite unsatisfactory – i) it requires users to login to the VPN before accessing services; ii) it prevents access to services on devices that do not have VPN support built-in; and iii) it requires a leap of faith to believe that the virtualized privacy can really be as secure as the physically-based privacy of a conventional corporate network.

Instead, in a public cloud, service will typically be provided from publicly accessible (not hidden behind a firewall) front-end servers; back-end servers, which contain the actual data, will be hidden from public access. There are opportunities for providing fortified-front-servers (fortified against hacking); and for providing the “hidden” backend servers, and seamless configuration of both and of the connections between front-end and back-end.

Client-server access will always be encrypted – unlike within today’s enterprise – usually with SSL. The need for handling massive numbers of enterprise SSL connections, together with load-balancing and other related systems, is going to be substantial. Any security or tracking system that relies on being able to access network traffic will have to be replaced with application-level security features. There are powerful vendors in the access-systems today – F5, Cisco, Juniper – yet it certainly seems possible that there is room for major innovation there, too, in scalability, manageability, and in the ability to efficiently handle the more complex/obscure network protocols used in enterprise IT.

The concept and implementation of identity and and access rights need to be reworked for the public enterprise cloud. FaceBook, with FaceBook-connect, have made real progress with respect to consumer identity – but that is based on FaceBook’s proprietary system, and is not designed for the enterprise. A number of consumer services, including Twitter, are using OAuth; but that is only a solution to part of the problem. The “identity/access” problem includes the issue of allowing cross-company access to services when desired – one of the benefits of putting services in the cloud should be to enable people to collaborate more broadly – yet cross-company access would need to be achieved without driving a hole through individual company security policies and systems. Public cloud identity systems would need to be synchronized and/or federated with on-customer-premise identity/access-rights systems, and controlled by customer IT administrators – which, in both cases, is in sharp contrast to consumer identity systems like FaceBook’s that are very much run and administered by the cloud service provider.

A public-enterprise-cloud identity system that can handle the complexity of enterprise access rights, role definitions, and hybrid cloud-premise access and administration would be a very valuable asset.

Data encryption of “data at rest” – stored data – is a huge issue for enterprise cloud. System adminstrators at the cloud provider will inevitably have access to stored data, at least in some circumstances, creating risks of abuse or theft. Encryption is often difficult, in that cloud applications would need access to the encrypted data – yet enabling data access by cloud applications makes the data accessible independent of the enterprise customer. Finally, government authorities can subpoena access to stored data at the cloud provider without the knowledge of the enterprise customer – a so-called “blind subpoena” – whereas if data is stored at the customer premises, the government would have to subpoena the enterprise directly, revealing to them that some kind of investigation was going on.

Some modest level of protection can be enabled by having the cloud provider encrypt the data, with the cloud provider holding the encryption keys. Applications can use non-reversibly-derived keys (also used during the actual encryption algorithm), so that simply pasting originating keys into apps does not provide access. Access to keys amongst cloud provider personnel can be more restrictive than access to servers and storage.

As an extension, the customer could hold the originating keys, with only derived keys being transferred to the cloud provider; the derived keys would be used in applications and in data encryption, but the originating keys would be required in any data management tools (tools designed to access the data in the raw), preventing those keys being used by cloud system administrators.

Although these kind of schemes are better than nothing, they are eminently hackable. For instance, a skilled hacker could hack the binaries of the data management tools to work with derived keys rather than originating keys; and they could do so relatively easily if they could get access to the source code of the tools. Or they could hack the applications to intercept the data at the points at which it is unencrypted by the application.

Many mid-sized business would likely be willing to tolerate these hacking risks. With encrypted data in the cloud, the setup is arguably still more secure than the setups mid-sized enterprises are running today on-premise, even taking into account the additional risks of the cloud. A startup that delivered easily deployed, enterprise-holds-the-originating-keys, encryption systems in the cloud might find that they have broad appeal.

One further extension to the derived-key approach would be to have the applications dynamically fetch from the customer-premise a derived form (or part thereof) of the encryption key (or sequence of keys), and then to (non-rerversibly) derive a actual, final key. Dynamic fetching of part of the key would at least avoid the need to store the key, even in derived form, in the cloud; but it is still vulnerable to hacking of admin tools or of applications.

Even that doesn’t solve the challenges of encryption at large enterprises. For some large-enterprise applications, only genuinely encryption-secured data, in which only the enterprise has in-the-clear access at all times, would be satisfactory.

Genuinely-secured-data would be achievable for cloud-based filing systems – the customer would hold the keys, and file system drivers would be provided for a variety of customer’s client and middle-ware systems that made use of the keys. The cloud-provider would never have access. A startup could be based around the management of those keys and drivers.

The problem, though, is that nothing could be deployed in the cloud to make better use of the data – no search, no processing, no display of data deployed in the cloud could take place, because applications deployed in the cloud would not have access to the data.

The only “complete” solution is to produce a means of application distribution – hybrid cloud-premise applications –  in which the portions of the application that require access to the data “in the clear” are performed in the client, or on the customer premises. For instance, for search, an on-premise appliance might produce encrypted search indexing, and encrypted indexes could be stored in the cloud. Another example – for an Intranet server, encrypted web pages could be delivered to clients for decryption; javascript applets would run at the client; and any click or other data action would then read/write encrypted material from/to the cloud.

Hybrid-cloud deployment to allow full encryption in the public cloud thus requires a major re-architecting of the applications themselves, on both client and server sides. To that extent – because it is so broad – it is problematic for startups, though a startup could produce some of the fundamental technologies. It might be easier for a major application vendor – Oracle, perhaps? Or Microsoft? – to get the necessary breadth of traction.

Overall, we can see multiple startup opportunities – and multiple as-yet unsolved problems – in public-enterprise-cloud security.