261 lines
14 KiB
XML
261 lines
14 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="security-legal-requirements">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Security and legal requirements</title>
|
|
<para>This chapter discusses the legal and security requirements you
|
|
need to consider for the different OpenStack scenarios.</para>
|
|
<section xml:id="legal-requirements">
|
|
<title>Legal requirements</title>
|
|
<para>Many jurisdictions have legislative and regulatory
|
|
requirements governing the storage and management of data in
|
|
cloud environments. Common areas of regulation include:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Data retention policies ensuring storage of
|
|
persistent data and records management to meet data
|
|
archival requirements.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Data ownership policies governing the possession and
|
|
responsibility for data.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Data sovereignty policies governing the storage of
|
|
data in foreign countries or otherwise separate
|
|
jurisdictions.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>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.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Examples of such legal frameworks include the <link
|
|
xlink:href="http://ec.europa.eu/justice/data-protection/">data
|
|
protection framework</link> of the European Union and the
|
|
requirements of the <link
|
|
xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">
|
|
Financial Industry Regulatory Authority</link> in the United
|
|
States. Consult a local regulatory body for more information.
|
|
</para>
|
|
</section>
|
|
<section xml:id="security-overview">
|
|
<title>Security</title>
|
|
<para>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.</para>
|
|
<para>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.</para>
|
|
<para>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.</para>
|
|
<warning>
|
|
<para>Be mindful of consistency when utilizing third party
|
|
clouds to explore authentication options.</para>
|
|
</warning>
|
|
</section>
|
|
<section xml:id="security-domains">
|
|
<title>Security domains</title>
|
|
<para>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.</para>
|
|
<para>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.</para>
|
|
<simplesect>
|
|
<title>Public security domains</title>
|
|
<para>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.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Guest security domains</title>
|
|
<para>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 tenants.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Management security domains</title>
|
|
<para>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.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Data security domains</title>
|
|
<para>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.</para>
|
|
</simplesect>
|
|
</section>
|
|
<section xml:id="hypervisor-security">
|
|
<title>Hypervisor-security</title>
|
|
<para>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
|
|
<firstterm>hypervisor breakout</firstterm>.
|
|
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.</para>
|
|
<para>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.</para>
|
|
</section>
|
|
<section xml:id="security-baremetal">
|
|
<title>Baremetal security</title>
|
|
<para>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 tenants. 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.</para>
|
|
<important>
|
|
<para>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.</para>
|
|
</important>
|
|
<para>More information on OpenStack Security can be found in the
|
|
<link xlink:href="http://docs.openstack.org/security-guide"><citetitle>OpenStack
|
|
Security Guide</citetitle></link>.</para>
|
|
</section>
|
|
<section xml:id="networking-security">
|
|
<title>Networking Security</title>
|
|
<para>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:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Firewalls</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Overlay interconnects for joining separated tenant networks</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Routing through or avoiding specific networks</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>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.</para>
|
|
</section>
|
|
<section xml:id="security-multi-site">
|
|
<title>Multi-site security</title>
|
|
<para>Securing a multi-site OpenStack installation brings
|
|
extra challenges. Tenants may expect a tenant-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.</para>
|
|
<para>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.</para>
|
|
<para>Just as tenants in a single-site deployment need isolation
|
|
from each other, so do tenants in multi-site installations.
|
|
The extra challenges in multi-site designs revolve around
|
|
ensuring that tenant 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.
|
|
Tenant networks may contain sensitive information requiring
|
|
that this mapping be accurate and consistent to ensure that a
|
|
tenant in one site does not connect to a different tenant in
|
|
another site.</para>
|
|
</section>
|
|
<section xml:id="openstack-components-multi-site">
|
|
<title>OpenStack components</title>
|
|
<para>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.</para>
|
|
<para>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.</para>
|
|
<para>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.</para>
|
|
</section>
|
|
</chapter>
|
|
|