The Service Gateway as a Control Agent
A service gateway is a new class of platform designed for massive scalability and control for mediating service interactions from the Enterprise to the cloud. As a control agent, the gateway sits at the edge of the physical network and provides runtime enforcement of security policies, threat prevention, quality of service enforcement, and the mediation of identities and credentials for cloud services. The service gateway is also able to enforce persistent security properties on Enterprise data. This is an important point and refers to message level data protection such as encryption and digital signature operations. This capability extends the perimeter of the Enterprise directly into the cloud provider itself by protecting the data even while it is outside of Enterprise control.
The service gateway also has additional properties such as compatibility with any Enterprise and cloud service, is itself scalable through virtualization in the private cloud, and the capability to run on low cost, commodity server hardware already deployed throughout the Enterprise. Moreover, the service gateway must help preserve and leverage existing Enterprise IT investments from major ISV vendors and must also provide integration and compatibility with existing software investments such as identity management and access control systems.
The Figure depicts the service gateway deployed at the traditional Enterprise perimeter. The service gateway has an outward defensive posture towards the cloud and improves security around the four areas of cloud security under the Enterprise control. The service gateway connects to existing information systems, identity management systems, and security monitoring systems and may also broker interactions directly from the end-user via a browser. It is also important that the service gateway be scalable in software with no dependencies on specialized XML processing hardware or custom ASIC. Otherwise, the cost, development, and scalability benefits of virtualized control points will be lost as specialized hardware cannot be effectively virtualized across general purpose hardware.
In this model, the service gateway is an edge-oriented policy enforcement point (PEP). It enforces security, threat, authentication, and authorization policies that are typically set and controlled in the identity management policy decision point (PDP). The split between PEP and PDP allows the Enterprise to control policies locally but have these policies enforced at the network edge, as traffic flows in and out of the organization.
Also shown in this picture is the identity management PDP communicating with existing enterprise information systems, which may include directories, middleware, databases or other applications. In this communication, the PDP is using additional context, such as resources and attributes to make policy decisions that are enforced at the external control point.
With respect to event monitoring, the application level security gateway can send logs and events to a security information management product which can aid in correlation and search for security and compliance as data moves from the Enterprise to the cloud.
API Protection and Strong Authentication
For API protection the service gateway acts as a secure proxy for all application level interactions with the cloud service provider, performing content scanning, attack protection and mitigating denial of service attacks. For strong authentication, while the gateway cannot invent strong authentication requirements at the cloud provider when they don’t exist, it can enforce strong authentication of the cloud service when available. This enables the Enterprise to know who it is talking to as well as enable increase capability of internal systems to call cloud services securely through the use of pre-built cloud connectors on the service gateway, saving development and testing costs inside the Enterprise itself.
Message Level Protection and Confidentiality
For data protection at the message level, a key attribute of the service gateway is to extend data protection into the cloud to increase control and compliance. This can be done by selective field level data protection on sensitive data done transparently by the service gateway before the messages reach the cloud. This type of data protection, when done properly, also aids in supporting compliance for standards such as PCI DSS that require encryption of specific pieces of information such as credit card numbers, names and customer addresses.
Auditing and Monitoring
For audit and monitoring, the service gateway is the single point control for data entering or leaving the Enterprise and given the full application level proxy capabilities of this control point, it can audit and log every interaction. Moreover, when responding to threatening events such as authentication failures, content threats and excessive traffic it can feed this information into Enterprise security information management (SIEM) systems to help build a comprehensive security event dashboard for the Enterprise. A SIEM system working in concert with the service gateway can alert a security administrator of a chain of events that involve the misuse of cloud computing resources such as an insider attack.
For example, a SIEM system can generate a predictive alert based on an Enterprise user downloading a “password” file internally first and then subsequently logging in to a cloud service and uploading the fi le to an infrastructure (IaaS) service, which could signal the use of cheap cloud computing resources for a brute force attack on the stolen password fi le. Service gateways are unique in their ability to capture not just network level events, but the full application level traffic, which can reveal details such as message-level method calls, parameters, request sizes, content-types, identity tokens and message rate, all of which can be expressed in log files that can be effectively captured and searched by Enterprise SIEM systems to build a cloud security dashboard that reveals a significant amount of forensic data regarding the usage of cloud services in the Enterprise.
Access Control and Authorization
For user authentication and authorization, Enterprises have invested heavily in Web access management, identity federation and identity management systems and are just now beginning to layer fine grained authorization capabilities into their architecture. Enterprise Web access management systems are a key system for managing and enforcing security policies, and are generally called a PDP, or policy decision point. From the perspective of the identity and access management system, it is the single source of managed security policy for authentication and authorization. The PDP extends its reach into the applications and infrastructure with policy enforcement points (PEPs) that are either embedded in the application container or act as security proxies, such as security gateways, that can parse and inspect the full application payload and stop traffic to request decisions from the PDP. This model allows centralized control of policies and along with distributed enforcement through PEPs throughout the internal enterprise architecture and the enterprise edge.
A typical use case that combines the capabilities of the enforcement point and decision point is a web services-based transaction bearing identity credentials within the XML message. In this case, the cloud service and the enterprise are passing XML documents back and forth and the service gateway is intercepting inbound traffic, performing content attack prevention, throttling, denial of service enforcement and then extracting the identity and credentials and passing this to the internal identity and access management system for an access policy decision. A second usage model involves a control point for identity federation (federated SSO) between internal identity systems and cloud-based SaaS applications. To date, cloud service providers each handle identities in their own way, but many such as Google and Salesforce.com offer federation through technologies such as SAML and OAuth.
The enterprise challenge then becomes how to broker existing enterprise identities and sessions, which are often stored in LDAP or databases or accessed through deployed identity systems, to the cloud, without a “forklift” style upgrade. A concrete example of this would be an Enterprise user attempting to access a cloud-based SaaS application. In this case, the user who is already logged in to the Enterprise network needs to be able to seamlessly access the SaaS service without a second login and without the SaaS service needing critical Enterprise employee data. We can also consider the case of authorization as an additional check on top of federated single sign-on. It has already been noted that cloud providers currently offer very coarse levels of access control and are opaque to existing fine grained authorization logic deployed inside the Enterprise. The introduction of cloud services in the Enterprise without an enforcement point simply offers users a way around fine grained authorization controls already in place. Even worse, Enterprises may have spent time and money getting fine grained authorization controls implemented and then face additional difficulties in scaling these controls to cloud services. It may make sense for an identity management system or security gateway to help bridge this gap. In other words, before requests for cloud services leave the Enterprise they can be identified as targeting specific resources with well-defined actions, all at the message level. These resources and appropriate actions can then be checked against the subjects and attributes provisioned in existing authorization system deployed in the Enterprise.
DESIRED MODEL: Centralized control of policies through a PDP with distributed enforcement through PEPs across internal architecture and Enterprise edge.