openstack-manuals/doc/arch-design/source/legal-security-requirements.rst

===============================
Security and legal requirements
===============================

This chapter discusses the legal and security requirements you
need to consider for the different OpenStack scenarios.

Legal requirements
~~~~~~~~~~~~~~~~~~

Many jurisdictions have legislative and regulatory
requirements governing the storage and management of data in
cloud environments. 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.

Examples of such legal frameworks include the
`data protection framework <http://ec.europa.eu/justice/data-protection/>`_
of the European Union and the requirements of the
`Financial Industry Regulatory Authority
<http://www.finra.org/Industry/Regulation/FINRARules/>`_
in the United States.
Consult a local regulatory body for more information.

.. _security:

Security
~~~~~~~~

When deploying OpenStack in an enterprise as a private cloud,
despite activating a firewall and binding employees with security
agreements, cloud architecture should not make assumptions about
safety and protection.
In addition to considering the users, operators, or administrators
who will use the environment, consider also negative or hostile users who
would attack or compromise the security of your deployment regardless
of firewalls or security agreements.

Attack vectors increase further in a public facing OpenStack deployment.
For example, the API endpoints and the software behind it become
vulnerable to hostile entities attempting to gain unauthorized access
or prevent access to services.
This can result in loss of reputation and you must protect against
it through auditing and appropriate filtering.

It is important to understand that user authentication requests
encase sensitive information such as user names, passwords, and
authentication tokens. For this reason, place the API services
behind hardware that performs SSL termination.

.. warning::

   Be mindful of consistency when utilizing third party
   clouds to explore authentication options.

Security domains
~~~~~~~~~~~~~~~~

A security domain comprises users, applications, servers or networks
that share common trust requirements and expectations within a system.
Typically, security domains have the same authentication and
authorization requirements and users.

You can map security domains individually to the installation,
or combine them. For example, some deployment topologies combine both
guest and data domains onto one physical network.
In other cases these networks are physically separate.
Map out the security domains against specific OpenStack topologies needs.
The domains and their trust requirements depend on whether the cloud
instance is public, private, or hybrid.

Public security domains
-----------------------

The public security domain is an untrusted area of the cloud
infrastructure. It can refer to the internet as a whole or simply
to networks over which the user has no authority.
Always consider this domain untrusted. For example,
in a hybrid cloud deployment, any information traversing between and
beyond the clouds is in the public domain and untrustworthy.

Guest security domains
----------------------

Typically used for compute instance-to-instance traffic, the
guest security domain handles compute data generated by
instances on the cloud but not services that support the
operation of the cloud, such as API calls. Public cloud
providers and private cloud providers who do not have
stringent controls on instance use or who allow unrestricted
internet access to instances should consider this domain to be
untrusted. Private cloud providers may want to consider this
network as internal and therefore trusted only if they have
controls in place to assert that they trust instances and all
their projects.

Management security domains
---------------------------

The management security domain is where services interact.
The networks in this domain transport confidential data such as
configuration parameters, user names, and passwords. Trust this
domain when it is behind an organization's firewall in deployments.

Data security domains
---------------------

The data security domain is concerned primarily with
information pertaining to the storage services within OpenStack.
The data that crosses this network has integrity and
confidentiality requirements. Depending on the type of deployment there
may also be availability requirements. The trust level of this network
is heavily dependent on deployment decisions and does not have a default
level of trust.

Hypervisor-security
~~~~~~~~~~~~~~~~~~~

The hypervisor also requires a security assessment. In a
public cloud, organizations typically do not have control
over the choice of hypervisor. Properly securing your
hypervisor is important. Attacks made upon the
unsecured hypervisor are called a **hypervisor breakout**.
Hypervisor breakout describes the event of a
compromised or malicious instance breaking out of the resource
controls of the hypervisor and gaining access to the bare
metal operating system and hardware resources.

There is not an issue if the security of instances is not important.
However, enterprises need to avoid vulnerability. The only way to
do this is to avoid the situation where the instances are running
on a public cloud. That does not mean that there is a
need to own all of the infrastructure on which an OpenStack
installation operates; it suggests avoiding situations in which
sharing hardware with others occurs.

Baremetal security
~~~~~~~~~~~~~~~~~~

There are other services worth considering that provide a
bare metal instance instead of a cloud. In other cases, it is
possible to replicate a second private cloud by integrating
with a private Cloud-as-a-Service deployment. The
organization does not buy the hardware, but also does not share
with other projects. It is also possible to use a provider that
hosts a bare-metal public cloud instance for which the
hardware is dedicated only to one customer, or a provider that
offers private Cloud-as-a-Service.

.. important::

   Each cloud implements services differently.
   What keeps data secure in one cloud may not do the same in another.
   Be sure to know the security requirements of every cloud that
   handles the organization's data or workloads.

More information on OpenStack Security can be found in the
`OpenStack Security Guide <https://docs.openstack.org/security-guide>`_.

Networking security
~~~~~~~~~~~~~~~~~~~

Consider security implications and requirements before designing the
physical and logical network topologies. Make sure that the networks are
properly segregated and traffic flows are going to the correct
destinations without crossing through locations that are undesirable.
Consider the following example factors:

* Firewalls
* Overlay interconnects for joining separated project networks
* Routing through or avoiding specific networks

How networks attach to hypervisors can expose security
vulnerabilities. To mitigate against exploiting hypervisor breakouts,
separate networks from other systems and schedule instances for the
network onto dedicated compute nodes. This prevents attackers
from having access to the networks from a compromised instance.

Multi-site security
~~~~~~~~~~~~~~~~~~~

Securing a multi-site OpenStack installation brings
extra challenges. Projects may expect a project-created network
to be secure. In a multi-site installation the use of a
non-private connection between sites may be required. This may
mean that traffic would be visible to third parties and, in
cases where an application requires security, this issue
requires mitigation. In these instances, install a VPN or
encrypted connection between sites to conceal sensitive traffic.

Another security consideration with regard to multi-site
deployments is Identity. Centralize authentication within a
multi-site deployment. Centralization provides a
single authentication point for users across the deployment,
as well as a single point of administration for traditional
create, read, update, and delete operations. Centralized
authentication is also useful for auditing purposes because
all authentication tokens originate from the same source.

Just as projects in a single-site deployment need isolation
from each other, so do projects in multi-site installations.
The extra challenges in multi-site designs revolve around
ensuring that project networks function across regions.
OpenStack Networking (neutron) does not presently support
a mechanism to provide this functionality, therefore an
external system may be necessary to manage these mappings.
Project networks may contain sensitive information requiring
that this mapping be accurate and consistent to ensure that a
project in one site does not connect to a different project in
another site.

OpenStack components
~~~~~~~~~~~~~~~~~~~~

Most OpenStack installations require a bare minimum set of
pieces to function. These include OpenStack Identity
(keystone) for authentication, OpenStack Compute
(nova) for compute, OpenStack Image service (glance) for image
storage, OpenStack Networking (neutron) for networking, and
potentially an object store in the form of OpenStack Object
Storage (swift). Bringing multi-site into play also demands extra
components in order to coordinate between regions. Centralized
Identity service is necessary to provide the single authentication
point. Centralized dashboard is also recommended to provide a
single login point and a mapped experience to the API and CLI
options available. If needed, use a centralized Object Storage service,
installing the required swift proxy service alongside the Object
Storage service.

It may also be helpful to install a few extra options in
order to facilitate certain use cases. For instance,
installing DNS service may assist in automatically generating
DNS domains for each region with an automatically-populated
zone full of resource records for each instance. This
facilitates using DNS as a mechanism for determining which
region would be selected for certain applications.

Another useful tool for managing a multi-site installation
is Orchestration (heat). The Orchestration service allows
the use of templates to define a set of instances to be launched
together or for scaling existing sets.
It can set up matching or differentiated groupings based on regions.
For instance, if an application requires an equally balanced
number of nodes across sites, the same heat template can be used
to cover each site with small alterations to only the region name.