Swivel Secure and the Cloud

Transcription

1 Swivel Secure and the Cloud Authentication for Cloud Application Abstract This document describes the issues relating to authenticating to cloud applications and how the Swivel authentication platform can address these issues. 19 th April 2011 Chris Russell

2 Swivel and the Cloud 2 Contents Introduction... 3 Authentication and the Cloud... 4 The Cloud is a public place... 4 The Cloud and Passwords... 4 Authentication Policies and Access Control... 5 New Models for Authentication... 5 How Federated Authentication Works... 5 Swivel and Cloud Authentication... 6 Summary... 8

3 Swivel and the Cloud 3 Introduction The benefits of moving enterprise applications from an on-premise to a cloud implementation are well documented. The economies of scale that can be gained by many customers of a service sharing the same software and hardware infrastructure can lead to cost-savings as well as allowing an enterprise to focus on its core business and leave the software service provider to manage their enterprise applications. One of the perceived barriers to moving to cloud applications is that of security, and an element of this is the strength and management of access management in relation to cloud applications. This paper looks at some of these issues and how they can be addressed. It also illustrates that a consistent approach to cloud and non-cloud applications can be achieved.

4 Swivel and the Cloud 4 Authentication and the Cloud There are a number of factors to consider when adopting cloud applications in relation to how people authenticate to these services. Specifically how those people *not* authorised to access your corporate data may attempt to do so. The Cloud is a public place Whereas security by obscurity is not a valid approach, the fact that all users of a cloud application may have exactly the same authentication experience on exactly the same URL is a factor to consider. It gives a potential attacker a head start in an attempt to attain illegal access. For example many cloud application providers are proud to inform the world at large about who their customers are. The norm for accessing many of these cloud applications is to use an address as the username. The format of addresses for an organisation is in the public domain. As are the names of senior management. So the fact that my enterprise uses a cloud application is in the public domain, as is the username used by senior management to access that cloud application. This means I have all the information I need in order to execute a number of different attacks against that account. The Cloud and Passwords The public nature of cloud applications makes passwords particularly vulnerable. Furthermore, for many users of cloud applications, the password they need to access the cloud application is yet another password for them to remember. This is in addition to their other enterprise passwords and all the passwords they use for their personal cloud applications (e.g. Facebook). This makes the reuse of passwords inevitable. One concern for an enterprise is that the username and password that an employee uses to access a personal cloud application such as Facebook, maybe the same username and password they use to access corporate data via an enterprise cloud application. This means that there is a good chance that amongst the credentials attained from breaches such as the Sega breach that there were a good number of valid sets of credentials of other cloud applications, including enterprise cloud applications.

5 Swivel and the Cloud 5 Sega explained that it had reset all passwords and urged customers to change their log-on details on other services and websites where they used the same credentials 1 Authentication Policies and Access Control When adopting a cloud application in most circumstances the authentication mechanisms and policies may be determined by the cloud provider. This means you may be restricted in your choice of authentication methods by the cloud provider and that you may not be able to stipulate different forms of authentication for different users etc. Also user-access to the cloud application may need to be managed separately from the core business processes that apply when users join or leave an organisation. Multiple cloud applications will mean multiple control points for user access. New Models for Authentication A range of technologies and protocols are now available that mean new models for authentication can now be adopted. Rather than an application (cloud or otherwise) making an authentication request an internal back-end system, applications can make authentication requests across the internet to a trusted third-party (an Identity Provider or IdP). The strength of this approach for cloud applications is that authentication is no longer the responsibility of the cloud application provider but it is the responsibility of the enterprise that owns the data that the user is attempting to access. This means that enterprises that are all sharing the same cloud application can all control and manage their own authentication, meaning they get the best of both worlds. How Federated Authentication Works Traditionally the application has been responsible for requesting and checking a user s authentication credentials. However if I am attempting to access Company A s corporate data held by a cloud application then it make more sense for me to prove who I am to Company A to be issued with some form of token that indicates I have done this, then for the cloud application to trust this token. This is the basis for the federated approach to authentication. 1 Source:

6 Swivel and the Cloud 6 Check Credentials User-name Credential Request Access Redirec Traditional Approach Create/Delete Accounts Federated Approach User-name Credential Configure Service Enterprise Enterprise The resultant use case is as follows User attempts to access Company A s data within cloud application Cloud application redirects user to Company A s Identity Provider (IdP) IdP prompts user for their username and authentication credentials IdP checks credentials and, if they are correct, issues the user with a token, and redirects the user back to the cloud application The cloud application validates the token and allows the user access via the appropriate account. This approach has the following advantages Company can implement whatever authentication mechanism they feel is appropriate for each user group Company can use same credentials for all cloud (and non-cloud) applications Company can grant/revoke access independent of cloud application provider Swivel and Cloud Authentication Swivel Secure has developed a number of cloud application solutions that mean you can use Swivel as your authentication platform for you cloud applications. These applications use an additional piece of software that is deployed on an internet facing server. This software interprets the inbound cloud

7 Swivel and the Cloud 7 authentication request, displays a user-authentication page, collects the user s credentials and submits them to the Swivel authentication platform. If the credentials are correct the IdP issues the required token (or SAML assertion). There are IdPs that work with SAML and ADFS and provide solutions for GoogleDocs Salesforce.com Azure Office 365 As the IdPs are standards based, they should work with other cloud applications that support SAML and ADFS standards. Active Directory remains single reference point. Swivel IdP Swivel Authentication Platform Active Directory User Internet SAML SSL VPN API RADIUS But as Swivel also can be used to authenticate your on-premises VPNs and web application it can provide the same authentication experience across both. As Swivel offers a range of authentication experiences within the same platform it is also possible to tailor the user s authentication based on the service they are accessing. For example a super-user accessing a cloud CRM system may be required to use full two-factor authentication whereas a user who can only access a small proportion of the CRM data may only be required to complete strong (eg TURing based) authentication. The use of the Swivel authentication platform for all authentications across on-premises and cloud applications means that Swivel becomes a single access control point for all these applications. As the Swivel authentication platform can also synchronise with an enterprises directory service eg Active Directory, it can automatically respond to changes within the organisation. So when a user leaves an organisation and their account is moved, disabled or deleted, the Swivel

8 Swivel and the Cloud 8 authentication platform will automatically remove their Swivel account and thus revoke access to all cloud and on-premise applications. Summary By deploying the Swivel authentication platform to secure your cloud applications you can Retain control over who can access your corporate data in the cloud Have a single access control point for all services. Customise the authentication experience Tailor the authentication experience for different users and different services Yet retain the same Swivel model across all services Allow users to the same credential for all cloud and non-cloud access And deliver both security and usability.