Difference between revisions of "Cloud-10 Multi Tenancy and Physical Security"

Revision as of 19:28, 29 August 2010

R7: Multi Tenancy and Physical Security

Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

Security Risks

1. Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
2. SaaS: Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
3. PaaS: Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
4. IaaS: Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.
5. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).

Countermeasures

1. Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.
2. For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
3. Tenants should have control on administrative access to all their resources running. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.
4. Virtual Private Cloud (VPC): It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
5. Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].

Reference:

1. http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
2. http://aws.amazon.com/vpc/
3. http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
4. http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
5. http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
6. http://www.cloudsecurityalliance.org/csaguide.pdf