Introduction
This is an extention of the previous article: Security Challenges in the Cloud, which introduces the security concerns encountered in cloud space. Since cloud computing paradigm encourages cloud users to use IaaS, PaaS and SaaS provided by third-party cloud service providers to host their data/applications and perform critical operations, it is important that the security requirements are accomplished by the service providers themselves. This article discusses how WSO2 StratosLive, as a comprehensive PaaS provider, meets these security challenges.
Applies To:
StratosLive 1.5.1
Overview of WSO2 StratosLiveWSO2 StratosLive is the public and 100% open source platform as a service (PaaS) operated by WSO2. In other words, it is the cloud middleware platform developed by WSO2, readily available as a service (PaaS) in the cloud. It includes the whole enterprise middleware products stack developed as different services in cloud.
How WSO2 StratosLive meets cloud's security challenges.
I encourage you to refer to my previous article on "Security Challenges in the Cloud" to get an understanding about some of the security concerns before continuing with this article. I have extracted the security challenges described in the previous article and discussed here how StratosLive has overcome them.
Availability:
To withstand the load and function with minimum or no downtime in the face of high loads ensuring availability, WSO2 StratosLive incorporates load balancers, clustering and auto-scaling.
Data isolation:
Data isolation in registry is achieved with the tenant domain id, in a shared schema, shared database pattern, while the registry data storage is hosted in a DMZ. If a tenant wants to store data related to an application that he has hosted, then he can create his own storage instance in the Data PaaS offerings provided with SLive such as RDS (Relational Databse as a Service) or Apache Cassandra as a service.
Data protection (during transport, processing and storage):
Data communication from the browser to back-end Admin Services happens over https (encrypted), which provides transport-level protection. Custom code deployed by tenants (webapps, web services) does not have access to data processing code which is protected by java security manager. The data storage is hosted in a DMZ (De Militarized Zone) which ensures that incoming connections from only a set of trusted hosts are granted access to the data storage. Also, the RDS instances that tenants can create are protected with username/password authentication.
Tenant isolation:
Each tenant is given a separate security domain such that each domain is isolated and does not have access to other domains.
For an example, when a tenant is created, a separate realm is created for that tenant which includes its own UserStoreManager, RealmConfiguration and AuthorizationManager so that user management and permission management happens without interfering with other tenants.
Logic/Execution isolation:
From architecture, design and code level of all most all the carbon components which are the building blocks of cloud middleware platform, are developed in a manner that supports multi-tenancy. (Multi-tenancy is serving multiple client organizations with multiple virtual instances isolated from one another, while there is a single instance of the software running on the server).
Also, different Axis2 contexts are created for each tenant where all the tenant specific states are kept which facilitates execution isolation for each tenant. (Apache Axis2 is the underlying web services engine used in WSO2 Carbon platform).
Protection form malicious code:
Since the middleware platform allows tenants to host their own code, privileged actions in the platform are being protected such that those operations can not be invoked by tenants' code deployed in the platform. This is achieved by restricting access to critical code through Java Security Manager. Access is allowed only from code that is signed properly.
Identity Management: This is the most widely discussed topic in cloud security which has following four key aspects.
1. Authentication : In addition to basic username, password based authentication, number of industry standard authentication mechanisms are supported.*. XMPP based Multifactor Authentication for stronger authentication
*. Federated authentication mechanisms such as OpenID provider and SAML2.
*. SAML2 based Single Sign On among all the services in SLive.
*. Authentication delegations mechanisms such as OAuth.
*. Cloud users are provided with the ability of securing communication to their services hosted in SLive with WS-Security mechanisms powered by Apache Rampart which is the security module of Axis2.
*. Further, tenants can integrate their custom webapps deployed SLive, with their tenant-specific user store in SLive in order to authenticate users into those webapps.
2. Authorization : Role based permission model as well as powerful, fine grained and flexible Policy Based Access Control with XACML are supported.
3. Auditing : Tenants' logs are isolated and each tenant admin can download logs related to its tenant from the Manager service. Distributed auditing mechanism is under development.
4. Administration : Currently two different user provisioning mechanisms are supported: Bulk User import and provisioning users from google app domain into SLive.
Image 2: Identity as a Service in StratosLive, which provides Identity and Entitlement Management Solutions.
Cloud Service Gateway: This can be introduced as a Private-Public Cloud bridge which facilitates the cloud consumers with a mechanism of securely connecting to public cloud from their internal network/private cloud.
Image 3: Deployment of Cloud Service Gateway.
Above is a list of mechanisms how SLive meets some of the common security challenges found in PaaS space. If you are interested in more, you can listen to the following two webinars conducted during WSO2 Summer School sessions in 2011.
Reference
No comments:
Post a Comment