This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Cloud-10 Multi Tenancy and Physical Security"
From OWASP
Vinaykbansal (talk | contribs) (Created page with '==R7: Multi Tenancy and Physical Security == Category:OWASP Cloud ‐ 10 Project __NOTOC__ <headertabs/>') |
Vinaykbansal (talk | contribs) |
||
Line 1: | Line 1: | ||
==R7: Multi Tenancy and Physical Security == | ==R7: Multi Tenancy and Physical Security == | ||
+ | Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients. It means physical resources (such as computing, networking, storage) gets shared, also the administrative functionality and support may also be shared. | ||
+ | Some of the cloud providers due to mult-tenancy may not allow audit and assessment within their infrastructure. | ||
+ | ==Security Risks== | ||
+ | # 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. | ||
+ | # 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. | ||
+ | # PaaS: Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives. | ||
+ | # 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. | ||
+ | # Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives). | ||
+ | ==Countermeasures== | ||
+ | # 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. | ||
+ | # 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]. | ||
+ | # 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. | ||
+ | # 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. | ||
+ | # 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:== | ||
+ | # http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html | ||
+ | # http://aws.amazon.com/vpc/ | ||
+ | # http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html | ||
+ | # http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/ | ||
+ | # http://people.csail.mit.edu/tromer/papers/cloudsec.pdf | ||
+ | # http://www.cloudsecurityalliance.org/csaguide.pdf | ||
[[Category:OWASP Cloud ‐ 10 Project]] | [[Category:OWASP Cloud ‐ 10 Project]] |
Revision as of 11:56, 22 February 2010
R7: Multi Tenancy and Physical Security
Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients. It means physical resources (such as computing, networking, storage) gets shared, also the administrative functionality and support may also be shared.
Some of the cloud providers due to mult-tenancy may not allow audit and assessment within their infrastructure.
Security Risks
- 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.
- 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.
- PaaS: Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
- 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.
- Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
Countermeasures
- 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.
- 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].
- 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.
- 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.
- 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:
- http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
- http://aws.amazon.com/vpc/
- http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
- http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
- http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
- http://www.cloudsecurityalliance.org/csaguide.pdf