By Ed King
Everyone is familiar with the notion of securing the edge of the enterprise. With the growing adoption of cloud technologies, IT must now also think about securing the "edge of the Cloud". The edge of the Cloud is the perimeter around any Cloud environment where it touches the open Internet. In this post I examine just what security at the edge of the Cloud means, and how enterprises can achieve a Cloud security strategy that is consistent with their existing on-premise strategy. How an enterprise chooses to secure the edge of the Cloud has a direct impact on what Cloud strategy it adopts. The various flavors of SaaS, IaaS, PaaS, private, public and hybrid Cloud solutions all have individual security requirements that we will examine.
Edge-of-the-enterprise security includes what gets deployed in the demilitarized zone (DMZ) and beyond, and can be divided into the three following areas of network, application and data security:
- Network security focuses on keeping the bad guys out and securing communication channels. Technologies include network firewalls, intrusion prevention and detection systems (IDS/IPS) and virtual private networks (VPN).
- Application security is about giving good guys access to approved resources under the right context, by securing application access points. Technologies include web application firewalls (WAF), application/XML/SOA gateways and identity management.
- Data security is about maintaining the data on the inside, as well as securing any data going out. Technologies include leakage prevention (DLP), encryption and tokenization.
So how does edge-of-the-enterprise security apply to the edge of the Cloud? With public and hybrid Clouds there is at least one third-party company involved, so who owns what aspects of security needs to be clearly defined. By default, an enterprise should assume it has the ultimate responsibility for securing the Cloud services it uses, including security at the edge of the Cloud, despite whatever reassurances the Cloud provider might offer. The enterprise needs to define a security strategy for Cloud usage and delegate to Cloud service providers what they can provide and manage.
Security for the edge of the Cloud differs by the type of Cloud based services.
Software-as-a-Service (SaaS) Security
A SaaS vendor owns its application delivery infrastructure, which makes things simple but limiting for enterprises looking to secure SaaS. Enterprises have no say in how security is implemented and have to trust the SaaS vendor’s documented security policies and SAS-70 certification. In an earlier CSA blog we discussed how enterprises can adopt a “don’t-trust” model when dealing with Cloud based services.
While network security and data security are take-it-or-leave-it, some SaaS vendors offer a few application security options. Multi-factor authentication is a popular option, especially with software tokens such as Verisign ID Protection (VIP). Many SaaS vendors also provide SAML (Security Assertion Mark-up Language) based integration so enterprise users can single sign-on from on-premise identity management platforms such as CA SiteMinder, IBM Tivoli Access Manager, or Oracle Access Manager. OAuth based federation is also quickly catching on for enterprise use. This in-depth article on SSO to Cloud based services provides extra reading.
While enterprises have a limited choice when it comes to directly securing the edge of SaaS Clouds, they should as a minimum, ensure the protection of the API keys. API keys are used to authenticate applications calling SaaS APIs. API keys are frequently distributed directly to application developers and hard-coded into applications. This is a insecure and unscaleable practice. Consider using a DMZ-based solution to securely manage and store the API keys, and broker the authentication of on-premise applications to the SaaS. Technologies designed for this purpose go by a number of different names: API Server, API Gateway or Cloud Service Broker. These technologies also monitor data traffic going to the Cloud to block, mask or encrypt sensitive data. This podcast offers more information about API key security.
Infrastructure-as-a-Service (IaaS) Security
An IaaS vendor provides hardware, the operating system and some software options. Network security is typically provided as a standard service. Communication is secured using SSL and VPN. As with SaaS, network security for IaaS is also a take-it-or-leave-it proposition. In contrast to SaaS, since the enterprise has complete ownership of what applications are deployed in the IaaS environment, it has complete responsibility and a good degree of flexibility when securing its applications at the edge of the Cloud.
Application security starts with an application firewall. Network firewalls are not content aware and cannot protect applications against attacks such as cross-site scripting and injections. A WAF is good for protecting web applications but provides limited protection for APIs. API security products offer comprehensive API protection but lack WAF’s self-learning capabilities. Application firewalls should be deployed as standard services for the IaaS, so every time an application is deployed in the IaaS, an application firewall service is spun up to protect that application. Look for firewalls that can be deployed in the Cloud, can be spun up and down elastically, and can protect REST/JSON style APIs.
Once the IaaS perimeter is protected from attacks, the next task is to control access to the application resources, including the API and data. Identity management technologies typically handle access control and single sign-on (SSO) to enterprise applications deployed on-premise. For IaaS environments that are accessed exclusively via VPN, enterprises can treat the applications deployed there like on-premise application. This typically requires deploying an agent as the policy enforcement points (PEP) for each application. Deploying agents can be expensive and error prone, especially in a highly dynamic IaaS environment where applications are spun up and down frequently. Using a proxy based PEP is more scalable and secure for IaaS deployed applications. For applications that need to be accessible to third-parties, consider using a federation model instead of requiring third-parties to obtain VPN access. To enable proxy based access control and federation, enterprises have two technology options. Cloud based federation services are single-purpose products that do well for user/browser access. It is a good low-cost option if API access is not important. To support both user and API access to IaaS deployed applications, consider the API security products mentioned previously.
For data security, DLP technology can work equally well for applications deployed in IaaS and for applications deployed on-premise. DLP should be made available as a standardized service that can be automatically provisioned as part of the IaaS provisioning process. Since API security and security gateway products offer standard DLP functions as well, it may be feasible to use those products for both application and data security.
Platform-as-a-Service (PaaS) Security
PaaS lets enterprises develop and deploy applications completely in the Cloud. While there are public PaaS offerings such as CloudFoundry.com, Force.com,and Engine Yard, enterprise adoption of PaaS will likely be predominantly in the form of private Clouds. In terms of network security, application security and data security, PaaS is very similar to IaaS. Regardless how an application is developed, once it is deployed in the Cloud, the run-time security is much the same.
What is unique about PaaS is the infrastructure services required for the development of applications, especially those services that need to connect PaaS applications to on-premise systems. These services can be for integration of security, data, process or management. Take identity management as an example. Applications developed on PaaS should not have their own identity silos in the Cloud. These applications will need access to identity, policy and entitlement data from on-premise identity management systems. For instance, developers need an Account Service in the PaaS that can provide identity data from the corporate directory. Leading PaaS providers do offer a library of standard infrastructure services, but the backend integrations that connect these services to on-premise systems remain the responsibility of the enterprise.
To create these infrastructure services for PaaS involves two parts. First, create Cloud-ready APIs for on-premise systems. In other words, create REST style APIs out of existing SOAP based web services (or JavaAPI, JMS, MQ, PL/SQL or other legacy interfaces). Use a technology like an API Server to create, manage, deliver and secure these APIs so they can be exposed to the PaaS. Next, at the edge of the PaaS Cloud, deploy API Brokers to mediate the security and protocol requirements from different on-premise API sources. Vordel’s CTO Mark O’Neill has blogged about an interesting example of edge-of-the-Cloud security for VMware’s Horizon Applications Manager. See post here.
It’s Time to Take Edge-of-the-Cloud Security Seriously
Too often security is an afterthought when enterprises adopt new technologies. Cloud is no exception. Cloud computing introduces new wrinkles to existing security best practice and technologies. Cloud computing creates an additional perimeter, the edge of the Cloud, that the enterprise must now secure. How an enterprise chooses to secure the edge of the Cloud has a direct impact on what Cloud strategy is feasible. SaaS, IaaS, PaaS, private, public and hybrid Cloud solutions all carry their unique security requirements that need to be factored in. The good news is that enough security technologies already exist today to make secured Cloud computing a reality even for the most risk-averse enterprises.
Ed King is the VP of product marketing at Vordel.