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.

Advertisements

6 Comments

Filed under Tech

6 responses to “Security In the Enterprise Public Cloud

  1. >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.

    I agree with the overall theme, but am not sure if the access management is the issue, companies struggle with. Windows, the dominant operating system in today’s enterprise, provides reach set of access control and management tools that are perfectly suitable for protection of various resource and asset classes. What is missing is not as much the tools to define and manage access control but rather the technology that would connect enterprise tools with their counterparts in the cloud.

    It would appear that in today’s world, there is no shortage of identity management technologies: LDAP, OpenID, oAuth, SAML. Similarly, a number of players offer tools that take advantage of these technologies to address identity and access control management problems: Google and Facebook, Ping Identity, Okta, RSA just to name a few.

    It is remarkable that pretty much all of the providers in identity management and access control space allow some form of integration with others. However, what all of them are missing is the cost-effective and scalable technology for integration with Microsoft Active Directory, where corporate America stores and manages it’s identity and access control rules.

    That presents a nice opportunity to build a business on: SaaS product that provides turn-key interoperability between MS Active directory and open standards: SAML, oAuth, OpenID is likely to be on the top of CIO’s wish list!

    • Hi Hovhannes –

      I’d agree that the Windows-server/Active-Directory model serves well enough in on-premises enterprises, albeit it’s a bit long in the tooth, not really roles-based, etc. – but, still, it serves.

      Less clear that it can so easily be applied to the cloud, or – especially – applied to hybrid cloud-enterprise setups. Can it really handle access rights for resources/services that are solely in the cloud, or (even harder) spread between cloud and premise? How would it handle the issue of certain resources being accessible, in a controlled way, across multiple companies? I know ADFS (AD Federation Services) could in principle handle some of it, but then again most cloud services are not built on Windows / AD making it hard to apply ADFS.

      LDAP, oAUTH, and SAML seem like implementation approaches rather than a broad system for solving the broad problem. There are of course startups working on integration between existing on-premise identity management systems and the cloud – Ping-Identity, Symplified, Conformity/IronStratus, Covisint, Apere, to my knowledge – using these mechanisms; however, they often have to handcraft solutions for each customer and each cloud service.

      I do think there is a broader opportunity here vs. the handcrafted solutions, something that encompasses identity, resource-access/policy rules, and cloud-premises integration, but its broad nature may (as previously suggested) make it a tough one for startups to attack successfully. IMHO.

  2. Hi Duncan,

    >Can it really handle access rights for resources/services that are solely in the cloud, or (even harder) spread between cloud and premise?
    I think, yes, it can. The short answer to your question is that Microsoft introduced a service, named “Azure AppFabric Access Control Service” (http://msdn.microsoft.com/en-us/library/dd582780.aspx), which serves that purpose and provides good integration for non-MS technologies (LAMP, Python, Java, Ruby etc.). It utilizes ADFS and adjustent Active Directory services.
    Azure AppFabric Access Control service is a relatively new in MS ecosystem. That is likely to be the reason why we don’t see as much adoption as one would expect. It is also not clear whether the service can scale well – it seems to require the cloud service to talk to it every time, when an access control decision is to be made. That, obviously, won’t fly with Salesforces and Facebooks of the world.

    I agree with your points on implementation approaches and challenges, faced by Ping, Simplified, Covisint etc.
    Their challenges are largely due to “we’ll integrate anything with everything” phylosophy, which makes it almost impossible to scale a business as you pointed out.
    Covisint is perhaps the worst in a sense that not only they play in identity management space but also in healthcare, automotive and others. Covisint evolved to be more of an integrator than identity and/or access control solution provider.

    The challenge of integration is the primary reason why I am inclined to see much more startup potential in identity management and authentication space rather than in access control as the latter inherently requires tight integration with the service it protects. Indeed, the goal of access control is to determine whether specific user is authorized to perform the operation, he or she requested, which translates to the need for access control to be part of the service. While it is possible that eventually services will adopt either a standardized representation of their access control rules or standardized mechanisms for communication with access control information providers, that, I think, is unlikely to happen anytime soon.
    At the same time, the standardization in identity management and authentication space is taking place today – it is hard to point to any mainstream SaaS service that would
    not support one or more open authentication mechanisms: OpenID, oAuth, SAML etc. What, I think, is missing, is the product or service that would serve a bridge between open protocols and the Active Directory and that could be turn-key deployed in the enterprise. Ideally, it would be a SaaS product that enterprise admins could enable and configure in a day. Simplified is the closest to the idea but AFAIK requires deployment of an on-site appliance and, apparently, requires 30-40 days of integration effort.
    To my knowledge, the engineering approach, Simplified took, relies on simplistic, on-the-surface connectivity with the Active Directory (at least that’s how it looked from their VC pitch). I think far superior usability and cost qualities can be achieved through PostPath style integration 🙂
    So, overall, I agree with your points, but think that there is an lucrative opportunity for a startup team, willing to dive into AD internals.

    Good to see you online! Thanks for an interesting blog!

  3. Hi again –

    In a funny kind of way, I do agree that Azure is currently the closest to a solution for hybrid cloud-premise identity+access-control.
    Yet, I would agree with El Reg’s comment from Friday:

    Red Hat: Cloud will anoint next Microsoft
    Don’t pick Microsoft again

    …surely Microsoft can’t be the answer? Again?

    The reason why I think this area is too broad to be ideal for a startup is very much the one you suggest, namely the range of applications you would need to integrate with successfully would be very broad. And yes, providing a Microsoft-like SHIM layer might help (for those applications that integrate with Microsoft AD), but that itself can be really hard… so I’m told…

  4. Have you ever heard of Janrain (http://www.janrain.com)? They seem to be reasonably close or, at least, going in the right direction with their product offering. Not exactly an enterprise solution, but clearly, an attempt to address the identity federation problem in the cloud.

    • We did have a quick look at Janrain in the context of “social login” and profile for a consumer app. It looks great, presuming the charge model is reasonable.

      On the other hand, we haven’t actually used it yet, preferring “by hand” auth and profile functionality.

      I agree with you that it might be a powerful enterprise offering, albeit I’m not sure how much they have positioned it that way vs. consumer and iPhone/iPad/Android oAuth offer.