@ -1,8 +1,11 @@
Factors affecting OpenStack deployment
When deploying OpenStack in an enterprise as a private cloud, it is
usually behind the firewall and within the trusted network alongside
@ -40,7 +43,7 @@ For more information OpenStack Security, see the `OpenStack Security
A security domain comprises of users, applications, servers or networks
that share common trust requirements and expectations within a system.
@ -89,7 +92,7 @@ OpenStack deployment topology. The domains and their trust requirements depend
upon whether the cloud instance is public, private, or hybrid.
The hypervisor also requires a security assessment. In a
public cloud, organizations typically do not have control
@ -106,7 +109,7 @@ important. However, enterprises can minimize vulnerability by avoiding
hardware sharing with others in a public cloud.
There are other services worth considering that provide a
bare metal instance instead of a cloud. In other cases, it is
@ -125,7 +128,7 @@ offers private Cloud-as-a-Service.
Consider security implications and requirements before designing the
physical and logical network topologies. Make sure that the networks are
@ -144,7 +147,7 @@ network onto dedicated Compute nodes. This prevents attackers
from having access to the networks from a compromised instance.
Securing a multi-site OpenStack installation brings
several challenges. Tenants may expect a tenant-created network
@ -169,3 +172,128 @@ Networking (neutron). Therefore an external system may be required
to manage mapping. Tenant networks may contain sensitive information requiring
accurate and consistent mapping to ensure that a tenant in one site
does not connect to a different tenant in another site.
Using remote resources for collection, processing, storage,
and retrieval provides potential benefits to businesses.
With the rapid growth of data within organizations, businesses
need to be proactive about their data storage strategies from
a compliance point of view.
Most countries have legislative and regulatory requirements governing
the storage and management of data in cloud environments. This is
particularly relevant for public, community and hybrid cloud models,
to ensure data privacy and protection for organizations using a
third party cloud provider.
Common areas of regulation include:
* Data retention policies ensuring storage of persistent data
and records management to meet data archival requirements.
* Data ownership policies governing the possession and
responsibility for data.
* Data sovereignty policies governing the storage of data in
foreign countries or otherwise separate jurisdictions.
* Data compliance policies governing certain types of
information needing to reside in certain locations due to
regulatory issues - and more importantly, cannot reside in
other locations for the same reason.
* Data location policies ensuring that the services deployed
to the cloud are used according to laws and regulations in place
for the employees, foreign subsidiaries, or third parties.
* Disaster recovery policies ensuring regular data backups and
relocation of cloud applications to another supplier in scenarios
where a provider may go out of business, or their data center could
* Security breach policies governing the ways to notify individuals
through cloud provider's systems or other means if their personal
data gets compromised in any way.
* Industry standards policy governing additional requirements on what
type of cardholder data may or may not be stored and how it is to
This is an example of such legal frameworks:
Data storage regulations in Europe are currently driven by provisions of
`Data protection framework <http://ec.europa.eu/justice/data-protection/> `_.
`Financial Industry Regulatory Authority
<http://www.finra.org/Industry/Regulation/FINRARules/>`_ works on this in
the United States.
Privacy and security are spread over different industry-specific laws and
* Health Insurance Portability and Accountability Act (HIPAA)
* Gramm-Leach-Bliley Act (GLBA)
* Payment Card Industry Data Security Standard (PCI DSS)
* Family Educational Rights and Privacy Act (FERPA)
Cloud security architecture
Cloud security architecture should recognize the issues
that arise with security management, which addresses these issues
with security controls. Cloud security controls are put in place to
safeguard any weaknesses in the system, and reduce the effect of an attack.
The following security controls are described below.
Typically reduce the threat level by informing potential attackers
that there will be adverse consequences for them if they proceed.
Strengthen the system against incidents, generally by reducing
if not actually eliminating vulnerabilities.
Intended to detect and react appropriately to any incidents
that occur. System and network security monitoring, including
intrusion detection and prevention arrangements, are typically
employed to detect attacks on cloud systems and the supporting
Reduce the consequences of an incident, normally by limiting
the damage. They come into effect during or after an incident.
Restoring system backups in order to rebuild a compromised
system is an example of a corrective control.
For more information, see See also `NIST Special Publication 800-53
The many different forms of license agreements for software are often written
with the use of dedicated hardware in mind. This model is relevant for the
cloud platform itself, including the hypervisor operating system, supporting
software for items such as database, RPC, backup, and so on. Consideration
must be made when offering Compute service instances and applications to end
users of the cloud, since the license terms for that software may need some
adjustment to be able to operate economically in the cloud.
Multi-site OpenStack deployments present additional licensing
considerations over and above regular OpenStack clouds, particularly
where site licenses are in use to provide cost efficient access to
software licenses. The licensing for host operating systems, guest
operating systems, OpenStack distributions (if applicable),
software-defined infrastructure including network controllers and
storage systems, and even individual applications need to be evaluated.
Topics to consider include:
* The definition of what constitutes a site in the relevant licenses,
as the term does not necessarily denote a geographic or otherwise
physically isolated location.
* Differentiations between "hot" (active) and "cold" (inactive) sites,
where significant savings may be made in situations where one site is
a cold standby for disaster recovery purposes only.
* Certain locations might require local vendors to provide support and
services for each site which may vary with the licensing agreement in