Moving applications to the Cloud puts many enterprises in an accustomed position, the technology and processes that their business depends on aren’t under their sole control, but rather a mix of responsibilities. The move to the Cloud is not a simple “forklift” migration where bits are copied to a Cloud Provider, instead the architecture and assumptions must be reviewed and refreshed to meet the needs and constraints of Cloud systems.
Implementing authorization services with standards like XACML empowers the security architect to enforce policy via a Gateway and answer the authorization queries from the source with the freshest and most specific data. Often the information needed to resolve authorization requests is stored beyond the directory and only available in a database or other repository.
The Cloud presents real integration challenges to the enterprise, what Gartner calls Cloudstreams and Cloud Service Brokerages focus on “integration, governance, and security impact points.”
In Part 1, we examined four Anti-Patterns that enterprises should avoid as they move the Cloud. These four Anti-Patterns are at the heart of dealing with the “Complexity Kills” problem that Gartner’s research shows as a recurring theme in Cloud migrations.
| Anti-Pattern |
Description |
Mitigations |
| Low/No Access Control |
“we’ll see if it works and then turn on security later” |
Strong access control protocols for authentication and authorization |
| Replicating User Accounts |
copying in full or an extract your Enterprise directory to the Cloud Provider |
Retain enterprise provisioning on Cloud Consumer side |
| Copying Credentials |
Copying Enterprise Access Credentials to Cloud based services |
Implement Federated Identity |
| “Trusted” Proxy |
Gateway lacks support security services and standards |
Implement improved access control, audit logging and monitoring on the Gateway |
In Part 2, we looked at how open standards like SAML, Oauth, and OpenID can be used to mitigate the Anti-Patterns, when it comes to fine grained authorization and Attribute based Access Control that many Cloud applications require, standards like these are necessary but not sufficient for the overall identity architecture.
The old enterprise perimeter was based on network firewalls, but today applications are integrated, distributed via Cloud and consumed via Mobile apps. The network firewall is severely limited in this context. Fine grained authorization and Attribute Based Access Control help close out the gaps in Cloud Security by providing a Dynamic Perimeter that manages access control across these contexts.
Today’s reality is that users, systems and data are distributed. The genie is not going to be put back in the box, but access control policy enforcement can and should be centralized.
Centralizing access control policy enforcement is essential for:
- For Security architects to understand the boundaries in the system,
- For developers to know what and where to code for authorization operations
- For auditors to be able to review
- For testers to be able to identify vulnerabilities
Gateways are ideal for providing the Policy Enforcement Point function, to intercept requests before they reach the resource and ensure the request is authorized.
The trend line in access control points to more fine grained access control and to have authorization decisions be policy based (rather than hard coded).
The four Anti-Patterns that we discussed show why trends continue in the direction of increased granularity and policy based access control.
Low/no access control – “we’ll see if it works and then turn on security later”
Access control is too important to be left up to developer discretion. Authorization and access control should be configured in policy, not hard coded. Externalizing the application’s authorization gives the enterprise several important advantages, including flexibility to route authorization requests to the system that has the most specific and freshest information.
Replicating user accounts – copying in full or an extract your Enterprise directory to the Cloud provider
XACML separates the Policy Enforcement Point (PEP: which protects the app) from the Policy Decision Point (PDP: which has the information to grant or deny the authorization request). This logical separation enables the enterprise to deploy its PEP on the Cloud Provider side to implement authorization enforcement while routing requests to PDP’s with the freshest and most specific attributes to answer the authorization request.
Separating the PEP and PDP means that the Gateway can intercept the request to the resource, route the request to the system with the freshest and most specific information, and enforce the policy. This pattern allows for a flexible, best of breed authorization architecture with the PEP and PDP tuned to control the authorization workflow. The PEP is responsible to enforce the chain of responsibilities in authorization and the PDP carries out the responsibility via querying data sources to grant or deny access. Note, the information needed to make the grant or deny access may cross from Cloud Provider to enterprise Cloud.
Copying credentials – sometimes Enterprise copy credentials to Cloud based services; and thereby create a new pool of identity risk to manage.
Separating the PEP and PDP eliminates the need to hard code individual credentials to resolve access control challenges. This is because the PEP queries the PDP on behalf of the user to verify user’s attributes against the authorization target including the Resource and Action requested.
“Trusted” proxy – where trust is in name only
Trust, but verify means auditability. When authorization logic is strewn across millions of lines of code, auditing is impossible. Auditable systems must have authorization rules and logic that are clear and straightforward to review. Pulling key authorization policies out of the code and into XACML policies allows the Auditor to assess the target and ensure it meets the system owners’ goals.
Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and federal/Gov systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. He blogs at http://1raindrop.typepad.com.
