Security guide editorial edits
No textual changes, just markup and style, mainly: * Add missing <filename> markup * Change capitalization * Wrap some overly long lines * Remove extra whitespace before ":" * Replace "--" with emdash Change-Id: I9126a91c5d1f78feacb10c639b26f37fc6815a99 Partial-Bug: #1217503
This commit is contained in:
Andreas Jaeger
parent
633694bde8
commit
2dad59797d
@ -18,7 +18,7 @@
|
||||
resources must be exposed to only systems within the
|
||||
department's network, which is entirely air-gapped from all
|
||||
other networks. The cloud can access other network services on
|
||||
the Organization's Intranet. For example, the authentication and
|
||||
the organization's intranet such as the authentication and
|
||||
logging services.</para>
|
||||
</section>
|
||||
<section xml:id="ch006_introduction-to-case-studies-idp46720">
|
||||
|
||||
@ -93,22 +93,22 @@
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><para> </para></td>
|
||||
<td colspan="4"><para><emphasis>Attacker Position /
|
||||
Privilege Level</emphasis></para></td>
|
||||
<td colspan="4"><para><emphasis>Attacker position /
|
||||
Privilege level</emphasis></para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold"> </emphasis></para></td>
|
||||
<td><para><emphasis role="bold"
|
||||
>External</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">Cloud
|
||||
User</emphasis></para></td>
|
||||
user</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">Cloud
|
||||
Admin</emphasis></para></td>
|
||||
admin</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">Control
|
||||
Plane</emphasis></para></td>
|
||||
plane</emphasis></para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">Privilege Elevation (3
|
||||
<td><para><emphasis role="bold">Privilege elevation (3
|
||||
levels)</emphasis></para></td>
|
||||
<td><para>Critical</para></td>
|
||||
<td><para>n/a</para></td>
|
||||
@ -116,7 +116,7 @@
|
||||
<td><para>n/a</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">Privilege Elevation (2
|
||||
<td><para><emphasis role="bold">Privilege elevation (2
|
||||
levels)</emphasis></para></td>
|
||||
<td><para>Critical</para></td>
|
||||
<td><para>Critical</para></td>
|
||||
@ -124,7 +124,7 @@
|
||||
<td><para>n/a</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">Privilege Elevation (1
|
||||
<td><para><emphasis role="bold">Privilege elevation (1
|
||||
level)</emphasis></para></td>
|
||||
<td><para>Critical</para></td>
|
||||
<td><para>Critical</para></td>
|
||||
@ -133,7 +133,7 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">Denial of
|
||||
Service</emphasis></para></td>
|
||||
service</emphasis></para></td>
|
||||
<td><para>High</para></td>
|
||||
<td><para>Medium</para></td>
|
||||
<td><para>Low</para></td>
|
||||
@ -141,10 +141,10 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">Information
|
||||
Disclosure</emphasis></para></td>
|
||||
<td><para>Critical / High</para></td>
|
||||
<td><para>Critical / High</para></td>
|
||||
<td><para>Medium / Low</para></td>
|
||||
disclosure</emphasis></para></td>
|
||||
<td><para>Critical / high</para></td>
|
||||
<td><para>Critical / high</para></td>
|
||||
<td><para>Medium / low</para></td>
|
||||
<td><para>Low</para></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
||||
@ -1,4 +1,8 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE chapter [
|
||||
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
|
||||
%openstack;
|
||||
]>
|
||||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns="http://docbook.org/ns/docbook"
|
||||
@ -15,8 +19,8 @@
|
||||
life-cycle process.</para>
|
||||
<section xml:id="ch013_node-bootstrapping-idp44768">
|
||||
<title>Secure bootstrapping</title>
|
||||
<para>Nodes in the cloud -- including compute, storage, network,
|
||||
service, and hybrid nodes -- should have an automated
|
||||
<para>Nodes in the cloud—including compute, storage, network,
|
||||
service, and hybrid nodes—should have an automated
|
||||
provisioning process. This ensures that nodes are provisioned
|
||||
consistently and correctly. This also facilitates security
|
||||
patching, upgrading, bug fixing, and other critical changes.
|
||||
@ -125,8 +129,8 @@
|
||||
<tr>
|
||||
<td><para><emphasis role="bold"
|
||||
>Register</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">What Is
|
||||
Measured</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">What is
|
||||
measured</emphasis></para></td>
|
||||
<td><para><emphasis role="bold"
|
||||
>Context</emphasis></para></td>
|
||||
</tr>
|
||||
|
||||
@ -21,9 +21,9 @@
|
||||
<para>Secure shell (SSH)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>OpenStack management utilities (for example,
|
||||
<systemitem class="service">nova-manage</systemitem>,
|
||||
<systemitem class="service">glance-manage</systemitem>)</para>
|
||||
<para>OpenStack management utilities such as
|
||||
<systemitem class="service">nova-manage</systemitem> and
|
||||
<systemitem class="service">glance-manage</systemitem></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Out-of-band management interfaces, such as IPMI</para>
|
||||
|
||||
@ -122,7 +122,7 @@
|
||||
<para>These include:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Password Policy Enforcement: Requires user passwords
|
||||
<para>Password policy enforcement: Requires user passwords
|
||||
to conform to minimum standards for length, diversity of
|
||||
characters, expiration, or failed login attempts.</para>
|
||||
</listitem>
|
||||
@ -234,8 +234,8 @@
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp270544">
|
||||
<title>Policies</title>
|
||||
<para>Each OpenStack service has a policy file in json format,
|
||||
called <emphasis role="bold">policy.json</emphasis>. The policy
|
||||
<para>Each OpenStack service has a policy file in JSON format,
|
||||
called <filename>policy.json</filename>. The policy
|
||||
file specifies rules, and the rule that governs each resource. A
|
||||
resource could be API access, the ability to attach to a volume,
|
||||
or to fire up instances.</para>
|
||||
@ -244,8 +244,8 @@
|
||||
could also be further customized. Note that your users must be
|
||||
assigned to groups/roles that you refer to in your
|
||||
policies.</para>
|
||||
<para>Below is a snippet of the Block Storage service policy.json
|
||||
file.</para>
|
||||
<para>Below is a snippet of the Block Storage service
|
||||
<filename>policy.json</filename> file.</para>
|
||||
<programlisting language="json"><xi:include href="../common/samples/authentication.json" parse="text"/></programlisting>
|
||||
<para>Note the <emphasis role="bold">default</emphasis> rule
|
||||
specifies that the user must be either an admin or the owner of
|
||||
|
||||
@ -53,13 +53,15 @@
|
||||
<section xml:id="ch025_web-dashboard-idp242624">
|
||||
<title>HTTP Strict Transport Security (HSTS)</title>
|
||||
<para>It is highly recommended to use HTTP Strict Transport
|
||||
Security (HSTS).</para>
|
||||
<para>NOTE: If you are using an HTTPS proxy in front of your web
|
||||
Security (HSTS).</para>
|
||||
<note>
|
||||
<para>If you are using an HTTPS proxy in front of your web
|
||||
server, rather than using an HTTP server with HTTPS
|
||||
functionality, follow the <link
|
||||
xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#secure-proxy-ssl-header"
|
||||
>Django documentation on modifying the SECURE_PROXY_SSL_HEADER
|
||||
variable</link>.</para>
|
||||
</note>
|
||||
<para>See the chapter on PKI/SSL Everywhere for more specific
|
||||
recommendations and server configurations for HTTPS
|
||||
configurations, including the configuration of HSTS.</para>
|
||||
|
||||
@ -30,7 +30,7 @@
|
||||
network.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>The <command>nova</command> command-line utility can
|
||||
return a URL for the VNC console for access by the
|
||||
<systemitem class="service">nova</systemitem> Java VNC
|
||||
@ -39,14 +39,18 @@
|
||||
bridge from the public network to the management
|
||||
network.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="ch026_compute-idp51760">
|
||||
<title>Security considerations</title>
|
||||
<itemizedlist><listitem>
|
||||
<para>The <systemitem class="service">nova-novncproxy</systemitem>and nova-xvpvncproxy services by default open public-facing ports that are token authenticated.</para>
|
||||
<para>The <systemitem
|
||||
class="service">nova-novncproxy</systemitem> and
|
||||
<systemitem class="service">nova-xvpvncproxy</systemitem>
|
||||
services by default open public-facing ports that are
|
||||
token authenticated.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<!-- TODO - check if havana had this feature -->
|
||||
<para>By default, the remote desktop traffic is not encrypted. Havana is expected to have VNC connections secured by Kerberos.</para>
|
||||
</listitem>
|
||||
@ -85,7 +89,10 @@
|
||||
<section xml:id="ch026_compute-idp83168">
|
||||
<title>Security considerations</title>
|
||||
<itemizedlist><listitem>
|
||||
<para>The nova-spicehtml5proxy service by default opens public-facing ports that are token authenticated.</para>
|
||||
<para>The <systemitem
|
||||
class="service">nova-spicehtml5proxy</systemitem>
|
||||
service by default opens public-facing ports that are
|
||||
token authenticated.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The functionality and integration are still evolving. We will access the features in the next release and make recommendations.</para>
|
||||
|
||||
@ -127,9 +127,10 @@
|
||||
</section>
|
||||
<section xml:id="ch027_storage-idpC123">
|
||||
<title>File permissions</title>
|
||||
<para>/etc/swift contains information about the ring
|
||||
topology and environment configuration. The following
|
||||
permissions are recommended:</para>
|
||||
<para>The <filename>/etc/swift</filename> directory
|
||||
contains information about the ring topology and
|
||||
environment configuration. The following permissions are
|
||||
recommended:</para>
|
||||
<screen><prompt>#</prompt> <userinput>chown -R root:swift /etc/swift/*</userinput>
|
||||
<prompt>#</prompt> <userinput>find /etc/swift/ -type f -exec chmod 640 {} \;</userinput>
|
||||
<prompt>#</prompt> <userinput>find /etc/swift/ -type d -exec chmod 750 {} \;</userinput></screen>
|
||||
@ -147,7 +148,7 @@
|
||||
<informaltable>
|
||||
<thead>
|
||||
<tr>
|
||||
<td>Service Name</td>
|
||||
<td>Service name</td>
|
||||
<td>Port</td>
|
||||
<td>Type</td>
|
||||
</tr>
|
||||
@ -282,7 +283,7 @@ Group swift</programlisting>
|
||||
<para>Create the file
|
||||
<filename>$YOUR_APACHE_DOC_ROOT/swift/proxy-server.wsgi</filename>:</para>
|
||||
<programlisting>from swift.common.wsgi import init_request_processor application, conf, logger, log_name = \
|
||||
init_request_processor('/etc/swift/proxy-server.conf','proxy-server')</programlisting>
|
||||
init_request_processor('/etc/swift/proxy-server.conf','proxy-server')</programlisting>
|
||||
</section>
|
||||
<section xml:id="ch027_storage-idpF1">
|
||||
<title>HTTP listening port</title>
|
||||
@ -363,11 +364,12 @@ Group swift</programlisting>
|
||||
<!-- Object Storage Authentication -->
|
||||
<section xml:id="ch027_storage-idpI1">
|
||||
<title>Other notable items</title>
|
||||
<para>In /etc/swift/swift.conf on every service node there is
|
||||
a "swift_hash_path_suffix" setting. This is provided to
|
||||
reduce the chance of hash collisions for objects being
|
||||
stored and avert one user overwriting the data of another
|
||||
user.</para>
|
||||
<para>In <filename>/etc/swift/swift.conf</filename> on every
|
||||
service node there is a
|
||||
<option>swift_hash_path_suffix</option> setting. This is
|
||||
provided to reduce the chance of hash collisions for objects
|
||||
being stored and avert one user overwriting the data of
|
||||
another user.</para>
|
||||
<para>This value should be initially set with a
|
||||
cryptographically secure random number generator and
|
||||
consistent across all service nodes. Ensure that it is
|
||||
|
||||
@ -42,7 +42,14 @@
|
||||
<section xml:id="ch028_case-studies-identity-management-idp131936">
|
||||
<title>Bob's public cloud</title>
|
||||
<para>Bob must support authentication by the general public, so he elects to use provide for username / password authentication. He has concerns about brute force attacks attempting to crack user passwords, so he also uses an external authentication extension that throttles the number of failed login attempts. Bob's Management network is separate from the other networks within his cloud, but can be reached from his corporate network via ssh. As recommended earlier, Bob requires administrators to use two-factor authentication on the Management network to reduce the risk from compromised administrator passwords.</para>
|
||||
<para>Bob also deploys the Dashboard to manage many aspects of the cloud. He deploys the Dashboard with HSTS to ensure that only HTTPS is used. He has ensured that the Dashboard is deployed on a second-level domain due to the limitations of the same-origin policy. He also disables HORIZON_IMAGES_ALLOW_UPLOAD to prevent resource exhaustion.</para>
|
||||
<para>Bob decides to use VNC for his virtual console for its maturity and security features.</para>
|
||||
<para>Bob also deploys the dashboard to manage many aspects of
|
||||
the cloud. He deploys the dashboard with HSTS to ensure that
|
||||
only HTTPS is used. He has ensured that the dashboard is
|
||||
deployed on a second-level domain due to the limitations of the
|
||||
same-origin policy. He also disables
|
||||
<option>HORIZON_IMAGES_ALLOW_UPLOAD</option> to prevent resource
|
||||
exhaustion.</para>
|
||||
<para>Bob decides to use VNC for his virtual console for its
|
||||
maturity and security features.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -9,20 +9,21 @@
|
||||
<para>In order to secure OpenStack Networking, an understanding of the workflow process for tenant instance creation needs to be mapped to security domains.</para>
|
||||
<para>There are four main services that interact with OpenStack Networking. In a typical OpenStack deployment these services map to the following security domains:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>OpenStack Dashboard: Public and Management</para>
|
||||
<para>OpenStack dashboard: Public and management</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>OpenStack Identity: Management</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>OpenStack Compute Node: Management and Guest</para>
|
||||
<para>OpenStack compute node: Management and guest</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>OpenStack Network Node: Management, Guest, and possibly Public depending upon neutron-plugin in use.</para>
|
||||
<para>OpenStack network node: Management, guest, and possibly
|
||||
public depending upon neutron-plugin in use.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>SDN Services Node: Management, Guest and possibly
|
||||
Public depending upon product used.</para>
|
||||
<para>SDN services node: Management, guest and possibly
|
||||
public depending upon product used.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><inlinemediaobject><imageobject role="html">
|
||||
|
||||
@ -1,4 +1,8 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE chapter [
|
||||
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
|
||||
%openstack;
|
||||
]>
|
||||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns="http://docbook.org/ns/docbook"
|
||||
@ -9,7 +13,7 @@
|
||||
<para>This section discusses OpenStack Networking configuration best practices as they apply to tenant network security within your OpenStack deployment.</para>
|
||||
<section xml:id="ch034_tenant-secure-networking-best-practices-idp44592">
|
||||
<title>Tenant network services workflow</title>
|
||||
<para>OpenStack Networking provides users real self services of network resources and configurations. It is important that Cloud Architects and Operators evaluate their design use cases in providing users the ability to create, update, and destroy available network resources.</para>
|
||||
<para>OpenStack Networking provides users real self services of network resources and configurations. It is important that cloud architects and operators evaluate their design use cases in providing users the ability to create, update, and destroy available network resources.</para>
|
||||
</section>
|
||||
<section xml:id="ch034_tenant-secure-networking-best-practices-idp46080">
|
||||
<title>Networking resource policy engine</title>
|
||||
@ -27,19 +31,35 @@
|
||||
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_networking_auth.html">Authentication
|
||||
and authorization section</link> in the <citetitle>OpenStack
|
||||
Cloud Administrator Guide</citetitle>.</para>
|
||||
<address>It is important to review the default networking resource policy and modify the policy appropriately for your security posture.</address>
|
||||
<para>If your deployment of OpenStack provides multiple external access points into different security domains it is important that you limit the tenant's ability to attach multiple vNICs to multiple external access points -- this would bridge these security domains and could lead to unforeseen security compromise. It is possible mitigate this risk by utilizing the host aggregates functionality provided by OpenStack Compute or through splitting the tenant VMs into multiple tenant projects with different virtual network configurations.</para>
|
||||
<note><para>It is important to review the default networking
|
||||
resource policy and modify the policy appropriately for your
|
||||
security posture.</para></note>
|
||||
<para>If your deployment of OpenStack provides multiple external
|
||||
access points into different security domains it is important
|
||||
that you limit the tenant's ability to attach multiple vNICs to
|
||||
multiple external access points—this would bridge these
|
||||
security domains and could lead to unforeseen security
|
||||
compromise. It is possible mitigate this risk by utilizing the
|
||||
host aggregates functionality provided by OpenStack Compute or
|
||||
through splitting the tenant VMs into multiple tenant projects
|
||||
with different virtual network configurations.</para>
|
||||
</section>
|
||||
<section xml:id="ch034_tenant-secure-networking-best-practices-idp51440">
|
||||
<title>Security groups</title>
|
||||
<para>The OpenStack Networking Service provides security group functionality using a mechanism that is more flexible and powerful than the security group capabilities built into OpenStack Compute. Thus, when using OpenStack Networking, <emphasis>nova.conf</emphasis> should always disable built-in security groups and proxy all security group calls to the OpenStack Networking API. Failure to do so will result in conflicting security policies being simultaneously applied by both services. To proxy security groups to OpenStack Networking, use the following configuration values:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>firewall_driver : must be set to 'nova.virt.firewall.NoopFirewallDriver' so that <systemitem class="service">nova-compute</systemitem> does not perform iptables-based filtering itself.</para>
|
||||
<para><option>firewall_driver</option> must be set to
|
||||
<literal>nova.virt.firewall.NoopFirewallDriver</literal> so
|
||||
that <systemitem class="service">nova-compute</systemitem>
|
||||
does not perform iptables-based filtering itself.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>security_group_api : must be set to 'neutron' so that all security group requests are proxied to the OpenStack Network Service.</para>
|
||||
<listitem>
|
||||
<para><option>security_group_api</option> must be set to
|
||||
<literal>neutron</literal> so that all security group
|
||||
requests are proxied to the OpenStack Networking
|
||||
service.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</itemizedlist>
|
||||
<para>Security groups and security group rules allow administrators and tenants the ability to specify the type of traffic and direction (ingress/egress) that is allowed to pass through a virtual interface port. A security group is a container for security group rules. When a virtual interface port is created in OpenStack Networking it is associated with a security group. If a security group is not specified, the port will be associated with a 'default' security group. By default this group will drop all ingress traffic and allow all egress. Rules can be added to this group in order to change the behaviour.</para>
|
||||
<para>When using the security group API through OpenStack Compute, security groups are applied to all virtual interface ports on an instance. The reason for this is that OpenStack Compute security group APIs are instance based and not virtual interface port based as OpenStack Networking.</para>
|
||||
</section>
|
||||
|
||||
@ -49,19 +49,25 @@ ssl-key=/path/to/ssl/server-key.pem</programlisting>
|
||||
<programlisting>ssl = true</programlisting>
|
||||
<para>Optionally, if you wish to restrict the set of SSL ciphers used for the encrypted connection. See <link xlink:href="http://www.openssl.org/docs/apps/ciphers.html">http://www.openssl.org/docs/apps/ciphers.html</link> for a list of ciphers and the syntax for specifying the cipher string:</para>
|
||||
<programlisting>ssl-ciphers = 'cipher:list'</programlisting>
|
||||
<para>The server certificate, key, and certificate authority (CA) files should be placed in the $PGDATA directory in the following files:</para>
|
||||
<para>The server certificate, key, and certificate authority
|
||||
(CA) files should be placed in the $PGDATA directory in the
|
||||
following files:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>$PGDATA/server.crt - Server certificate</para>
|
||||
<para><filename>$PGDATA/server.crt</filename> - Server
|
||||
certificate</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>$PGDATA/server.key - Private key corresponding to server.crt</para>
|
||||
<listitem>
|
||||
<para><filename>$PGDATA/server.key</filename> - Private key
|
||||
corresponding to <filename>server.crt</filename></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>$PGDATA/root.crt - Trusted certificate authorities</para>
|
||||
<listitem>
|
||||
<para><filename>$PGDATA/root.crt</filename> - Trusted
|
||||
certificate authorities</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>$PGDATA/root.crl - Certificate revocation list</para>
|
||||
<listitem>
|
||||
<para><filename>$PGDATA/root.crl</filename> - Certificate
|
||||
revocation list</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -79,7 +79,7 @@
|
||||
<blockquote>
|
||||
<para>"Sanitization is the process used to remove information from system media such that there is reasonable assurance that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, and destroying media information, prevent the disclosure of organizational information to unauthorized individuals when such media is reused or released for disposal." [NIST Special Publication 800-53 Revision 3]</para>
|
||||
</blockquote>
|
||||
<para>General data disposal and sanitization guidelines as adopted from NIST recommended security controls. Cloud Operators should:</para>
|
||||
<para>General data disposal and sanitization guidelines as adopted from NIST recommended security controls. Cloud operators should:</para>
|
||||
<orderedlist><listitem>
|
||||
<para>Track, document and verify media sanitization and disposal actions.</para>
|
||||
</listitem>
|
||||
|
||||
@ -6,33 +6,77 @@
|
||||
xml:id="ch049_case-studies-tenant-data">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Case studies: tenant data</title>
|
||||
<para>Returning to Alice and Bob, we will use this section to dive into their particular tenant data privacy requirements. Specifically, we will look into how Alice and Bob both handle tenant data, data destruction, and data encryption.</para>
|
||||
<para>
|
||||
Returning to Alice and Bob, we will use this section to dive
|
||||
into their particular tenant data privacy
|
||||
requirements. Specifically, we will look into how Alice and Bob
|
||||
both handle tenant data, data destruction, and data
|
||||
encryption.
|
||||
</para>
|
||||
<section xml:id="ch049_case-studies-tenant-data-idp44416">
|
||||
<title>Alice's private cloud</title>
|
||||
<para>As stated during the introduction to Alice's case study,
|
||||
data protection is of an extremely high priority. She
|
||||
needs to ensure that a compromise of one tenant's data
|
||||
does not cause loss of other tenant data. She also has
|
||||
strong regulator requirements that require documentation
|
||||
of data destruction activities. Alice does this using the
|
||||
following:</para>
|
||||
<para>
|
||||
As stated during the introduction to Alice's case study, data
|
||||
protection is of an extremely high priority. She needs to
|
||||
ensure that a compromise of one tenant's data does not cause
|
||||
loss of other tenant data. She also has strong regulator
|
||||
requirements that require documentation of data destruction
|
||||
activities. Alice does this using the following:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>Establishing procedures to sanitize tenant data when a program or project ends</para> </listitem>
|
||||
<listitem><para>Track the destruction of both the tenant data and metadata via ticketing in a CMDB</para> </listitem>
|
||||
<listitem><para>For Volume storage:</para> </listitem>
|
||||
<listitem><para>Physical Server Issues</para> </listitem>
|
||||
<listitem><para>To provide secure ephemeral instance storage, Alice implements qcow2 files on an encrypted filesystem.</para> </listitem>
|
||||
</itemizedlist>
|
||||
<listitem>
|
||||
<para>Establishing procedures to sanitize tenant data when
|
||||
a program or project ends.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Track the destruction of both the tenant data and
|
||||
metadata via ticketing in a CMDB.</para>
|
||||
</listitem>
|
||||
<listitem><para>For Volume storage:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Physical server issues</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>To provide secure ephemeral instance storage,
|
||||
Alice implements qcow2 files on an encrypted
|
||||
filesystem.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="ch049_case-studies-tenant-data-idp51856">
|
||||
<title>Bob's public cloud</title>
|
||||
<para>As stated during the introduction to Bob's case study, tenant privacy is of an extremely high priority. In addition to the requirements and actions Bob will take to isolate tenants from one another at the infrastructure layer, Bob also needs to provide assurances for tenant data privacy. Bob does this using the following:</para>
|
||||
<para>
|
||||
As stated during the introduction to Bob's case study, tenant
|
||||
privacy is of an extremely high priority. In addition to the
|
||||
requirements and actions Bob will take to isolate tenants from
|
||||
one another at the infrastructure layer, Bob also needs to
|
||||
provide assurances for tenant data privacy. Bob does this
|
||||
using the following:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>Establishing procedures to sanitize customer data when a customer churns</para> </listitem>
|
||||
<listitem><para>Track the destruction of both the customer data and metadata via ticketing in a CMDB</para> </listitem>
|
||||
<listitem><para>For Volume storage:</para> </listitem>
|
||||
<listitem><para>Physical Server Issues</para> </listitem>
|
||||
<listitem><para>To provide secure ephemeral instance storage, Bob implements qcow2 files on an encrypted filesystems.</para> </listitem>
|
||||
<listitem>
|
||||
<para>Establishing procedures to sanitize customer data
|
||||
when a customer churns.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Track the destruction of both the customer data and
|
||||
metadata via ticketing in a CMDB.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>For Volume storage:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Physical server issues</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>To provide secure ephemeral instance storage, Bob
|
||||
implements qcow2 files on an encrypted filesystems.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</chapter>
|
||||
</chapter>
|
||||
|
||||
@ -47,27 +47,27 @@
|
||||
<title>Selection criteria</title>
|
||||
<para>As part of your hypervisor selection process, you will need to consider a number of important factors to help increase your security posture. Specifically, we will be looking into the following areas:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>Team Expertise</para>
|
||||
<para>Team expertise</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Product or Project maturity</para>
|
||||
<listitem>
|
||||
<para>Product or project maturity</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Certifications, Attestations</para>
|
||||
<listitem>
|
||||
<para>Certifications, attestations</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Additional Security Features</para>
|
||||
<listitem>
|
||||
<para>Additional security features</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Hypervisor vs. Baremetal</para>
|
||||
<listitem>
|
||||
<para>Hypervisor vs. baremetal</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Hardware Concerns</para>
|
||||
<listitem>
|
||||
<para>Hardware concerns</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>Common Criteria</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</itemizedlist>
|
||||
<para>Additionally, the following security-related criteria are highly encouraged to be evaluated when selecting a hypervisor for OpenStack deployments:<itemizedlist><listitem>
|
||||
<para>Has the hypervisor undergone Common Criteria certification? If so, to what levels?</para>
|
||||
</listitem>
|
||||
@ -123,7 +123,7 @@
|
||||
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><para>Identification and Authentication</para></td>
|
||||
<td><para>Identification and authentication</para></td>
|
||||
<td><para>Identification and authentication using pluggable authentication modules (PAM) based upon user passwords. The quality of the passwords used can be enforced through configuration options.</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
@ -158,23 +158,23 @@
|
||||
<td><para>Role-based access control (RBAC) allows separation of roles to eliminate the need for an all-powerful system administrator.</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>Object Reuse</para></td>
|
||||
<td><para>Object reuse</para></td>
|
||||
<td><para>File system objects as well as memory and IPC objects will be cleared before they can be reused by a process belonging to a different user.</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>Security Management</para></td>
|
||||
<td><para>Security management</para></td>
|
||||
<td><para>The management of the security critical parameters of the system is performed by administrative users. A set of commands that require root privileges (or specific roles when RBAC is used) are used for system management. Security parameters are stored in specific files that are protected by the access control mechanisms of the system against unauthorized access by users that are not administrative users.</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>Secure Communication</para></td>
|
||||
<td><para>Secure communication</para></td>
|
||||
<td><para>The system supports the definition of trusted channels using SSH. Password based authentication is supported. Only a restricted number of cipher suites are supported for those protocols in the evaluated configuration.</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>Storage Encryption</para></td>
|
||||
<td><para>Storage encryption</para></td>
|
||||
<td><para>The system supports encrypted block devices to provide storage confidentiality via dm_crypt.</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>TSF Protection</para></td>
|
||||
<td><para>TSF protection</para></td>
|
||||
<td><para>While in operation, the kernel software and data are protected by the hardware memory protection mechanisms. The memory and process management components of the kernel ensure a user process cannot access kernel storage or storage belonging to other processes.</para><para>Non-kernel TSF software and data are protected by DAC and
|
||||
process isolation mechanisms. In the evaluated
|
||||
configuration, the reserved user ID root owns the
|
||||
@ -193,74 +193,71 @@
|
||||
<para>Several cryptography algorithms are available within OpenStack for identification and authorization, data transfer and protection of data at rest. When selecting a hypervisor, the following are recommended algorithms and implementation standards to ensure the virtualization layer supports:</para>
|
||||
|
||||
<informaltable rules="all" width="80%"><colgroup><col/><col/><col/><col/><col/></colgroup>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<thead>
|
||||
<tr>
|
||||
<td>Algorithm</td>
|
||||
<td>Key length</td>
|
||||
<td>Intended purpose</td>
|
||||
<td>Security function</td>
|
||||
<td>Implementation standard</td>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">Algorithm</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">Key Length</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">Intended Purpose</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">Security Function</emphasis></para></td>
|
||||
<td><para><emphasis role="bold">Implementation Standard</emphasis></para></td>
|
||||
<td>AES</td>
|
||||
<td>128, 192, or 256 bits</td>
|
||||
<td>Encryption / decryption</td>
|
||||
<td>Protected data transfer, protection for data at rest</td>
|
||||
<td>RFC 4253</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>AES</para></td>
|
||||
<td><para>128, 192, or 256 bits</para></td>
|
||||
<td><para>Encryption / Decryption</para></td>
|
||||
<td><para>Protected Data Transfer, Protection for Data at Rest</para></td>
|
||||
<td><para>RFC 4253</para></td>
|
||||
<td>TDES</td>
|
||||
<td>168 bits</td>
|
||||
<td>Encryption / decryption</td>
|
||||
<td>Protected data transfer</td>
|
||||
<td>RFC 4253</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>TDES</para></td>
|
||||
<td><para>168 bits</para></td>
|
||||
<td><para>Encryption / Decryption</para></td>
|
||||
<td><para>Protected Data Transfer</para></td>
|
||||
<td><para>RFC 4253</para></td>
|
||||
<td>RSA</td>
|
||||
<td>1024, 2048, or 3072 bits</td>
|
||||
<td>Authentication, key exchange</td>
|
||||
<td>Identification and authentication, protected data transfer</td>
|
||||
<td>U.S. NIST FIPS PUB 186-3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>RSA</para></td>
|
||||
<td><para>1024, 2048, or 3072 bits</para></td>
|
||||
<td><para>Authentication, Key Exchange</para></td>
|
||||
<td><para>Identification and Authentication, Protected Data Transfer</para></td>
|
||||
<td><para>U.S. NIST FIPS PUB 186-3</para></td>
|
||||
<td>DSA</td>
|
||||
<td>L=1024, N=160 bits</td>
|
||||
<td>Authentication, key exchange</td>
|
||||
<td>Identification and authentication, protected data transfer</td>
|
||||
<td>U.S. NIST FIPS PUB 186-3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>DSA</para></td>
|
||||
<td><para>L=1024, N=160 bits</para></td>
|
||||
<td><para>Authentication, Key Exchange</para></td>
|
||||
<td><para>Identification and Authentication, Protected Data Transfer</para></td>
|
||||
<td><para>U.S. NIST FIPS PUB 186-3</para></td>
|
||||
<td>Serpent</td>
|
||||
<td>128, 192, or 256 bits</td>
|
||||
<td>Encryption / decryption</td>
|
||||
<td>Protection of data at rest</td>
|
||||
<td><link xlink:href="http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf">http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf</link></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>Serpent</para></td>
|
||||
<td><para>128, 192, or 256 bits</para></td>
|
||||
<td><para>Encryption / Decryption</para></td>
|
||||
<td><para>Protection of Data at Rest</para></td>
|
||||
<td><para><link xlink:href="http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf">http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf</link></para></td>
|
||||
<td>Twofish</td>
|
||||
<td>128, 192, or 256 bits</td>
|
||||
<td>Encryption / decryption</td>
|
||||
<td>Protection of data at rest</td>
|
||||
<td><link xlink:href="http://www.schneier.com/paper-twofish-paper.html">http://www.schneier.com/paper-twofish-paper.html</link></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>Twofish</para></td>
|
||||
<td><para>128, 192, or 256 bit</para></td>
|
||||
<td><para>Encryption / Decryption</para></td>
|
||||
<td><para>Protection of Data at Rest</para></td>
|
||||
<td><para><link xlink:href="http://www.schneier.com/paper-twofish-paper.html">http://www.schneier.com/paper-twofish-paper.html</link></para></td>
|
||||
<td>SHA-1</td>
|
||||
<td>-</td>
|
||||
<td>Message Digest</td>
|
||||
<td>Protection of data at rest, protected data transfer</td>
|
||||
<td>U.S. NIST FIPS 180-3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>SHA-1</para></td>
|
||||
<td><para>-</para></td>
|
||||
<td><para>Message Digest</para></td>
|
||||
<td><para>Protection of Data at Rest, Protected Data Transfer</para></td>
|
||||
<td><para>U.S. NIST FIPS 180-3</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para>SHA-2 (224, 256, 384, or 512 bits)</para></td>
|
||||
<td><para>-</para></td>
|
||||
<td><para>Message Digest</para></td>
|
||||
<td><para>Protection for Data at Rest, Identification and Authentication</para></td>
|
||||
<td><para>U.S. NIST FIPS 180-3</para></td>
|
||||
<td>SHA-2 (224, 256, 384, or 512 bits)</td>
|
||||
<td>-</td>
|
||||
<td>Message digest</td>
|
||||
<td>Protection for data at rest, identification and authentication</td>
|
||||
<td>U.S. NIST FIPS 180-3</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
|
||||
@ -1,4 +1,8 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE chapter [
|
||||
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
|
||||
%openstack;
|
||||
]>
|
||||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns="http://docbook.org/ns/docbook"
|
||||
@ -89,7 +93,11 @@
|
||||
<para><emphasis>Position Independent Executable (PIE)</emphasis>: Produces a position independent executable, which is necessary for ASLR.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Address Space Layout Randomization (ASLR)</emphasis> : This ensures that both code and data regions will be randomized. Enabled by the kernel (all modern linux kernels support ASLR), when the executable is built with PIE.</para>
|
||||
<para><emphasis>Address Space Layout Randomization
|
||||
(ASLR)</emphasis>: This ensures that both code and data
|
||||
regions will be randomized. Enabled by the kernel (all
|
||||
modern linux kernels support ASLR), when the executable is
|
||||
built with PIE.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Putting this all together, and adding in some additional useful protections, we recommend the following compiler options for gcc when compiling QEMU:</para>
|
||||
@ -151,8 +159,16 @@
|
||||
<imageobject role="fo">
|
||||
<imagedata contentdepth="100%" fileref="static/sVirt Diagram 1.png" format="PNG" scalefit="1" width="100%"/>
|
||||
</imageobject>
|
||||
</inlinemediaobject></para>
|
||||
<para>As shown above, sVirt isolation is provided regardless of the guest Operating System running inside the virtual machine -- Linux or Windows VMs can be used. Additionally, many Linux distributions provide SELinux within the operating system, allowing the virtual machine to protect internal virtual resources from threats.</para>
|
||||
</inlinemediaobject>
|
||||
</para>
|
||||
<para>
|
||||
As shown above, sVirt isolation is provided regardless of the
|
||||
guest Operating System running inside the virtual
|
||||
machine—Linux or Windows VMs can be used. Additionally,
|
||||
many Linux distributions provide SELinux within the operating
|
||||
system, allowing the virtual machine to protect internal
|
||||
virtual resources from threats.
|
||||
</para>
|
||||
<section xml:id="ch052_devices-idp523744">
|
||||
<title>Labels and categories</title>
|
||||
<para>KVM-based virtual machine instances are labelled with their own SELinux data type, known as svirt_image_t. Kernel level protections prevent unauthorized system processes, such as malware, from manipulating the virtual machine image files on disk. When virtual machines are powered off, images are stored as svirt_image_t as shown below:</para>
|
||||
|
||||
@ -10,16 +10,16 @@
|
||||
<para>Deployers or users of OpenStack with strong security requirements may want to consider deploying these technologies. Not all are applicable in every situation, indeed in some cases technologies may be ruled out for use in a cloud because of prescriptive business requirements. Similarly some technologies inspect instance data such as run state which may be undesirable to the users of the system.</para>
|
||||
<para>In this chapter we explore these technologies and describe the situations where they can be used to enhance security for instances or underlying instances. We also seek to highlight where privacy concerns may exist. These include data pass through, introspection, or providing a source of entropy. In this section we highlight the following additional security services:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>Entropy to Instances</para>
|
||||
<para>Entropy to instances</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Scheduling Instances to Nodes</para>
|
||||
<listitem>
|
||||
<para>Scheduling instances to nodes</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Trusted Images</para>
|
||||
<listitem>
|
||||
<para>Trusted images</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Instance Migrations</para>
|
||||
<listitem>
|
||||
<para>Instance migrations</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section xml:id="ch055_security-services-for-instances-idp122544">
|
||||
@ -64,7 +64,7 @@
|
||||
partition up their compute host resources. Each node can have
|
||||
multiple aggregates (see the <link
|
||||
xlink:href="http://docs.openstack.org/trunk/config-reference/content/host-aggregates.html">Host
|
||||
Aggregates</link> section of the <citetitle>OpenStack
|
||||
aggregates</link> section of the <citetitle>OpenStack
|
||||
Configuration Reference</citetitle> for more information on
|
||||
creating and managing aggregates).</para>
|
||||
</section>
|
||||
@ -179,35 +179,38 @@
|
||||
<title>Live migration risks</title>
|
||||
<para>At various stages of the live migration process the contents of an instances run time memory and disk are transmitted over the network in plain text. Thus there are several risks that need to be addressed when using live migration. The following in-exhaustive list details some of these risks:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para><emphasis>Denial of Service (DoS)</emphasis> : If something fails during the migration process, the instance could be lost.</para>
|
||||
<para><emphasis>Denial of Service (DoS)</emphasis>: If something fails during the migration process, the instance could be lost.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Data Exposure</emphasis> : Memory or disk transfers must be handled securely.</para>
|
||||
<listitem>
|
||||
<para><emphasis>Data exposure</emphasis>: Memory or disk transfers must be handled securely.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Data Manipulation</emphasis> : If memory or disk transfers are not handled securely, then an attacker could manipulate user data during the migration.</para>
|
||||
<listitem>
|
||||
<para><emphasis>Data manipulation</emphasis>: If memory or disk transfers are not handled securely, then an attacker could manipulate user data during the migration.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Code Injection</emphasis> : If memory or disk transfers are not handled securely, then an attacker could manipulate executables, either on disk or in memory, during the migration.</para>
|
||||
<listitem>
|
||||
<para><emphasis>Code injection</emphasis>: If memory or disk transfers are not handled securely, then an attacker could manipulate executables, either on disk or in memory, during the migration.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="ch055_security-services-for-instances-idp183744">
|
||||
<title>Live migration mitigations</title>
|
||||
<para>There are several methods to mitigate some of the risk associated with live migrations, the following list details some of these:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>Disable Live Migration</para>
|
||||
<para>Disable live migration</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Isolated Migration Network</para>
|
||||
<listitem>
|
||||
<para>Isolated migration network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Encrypted Live Migration</para>
|
||||
<listitem>
|
||||
<para>Encrypted live migration</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</itemizedlist>
|
||||
<section xml:id="ch055_security-services-for-instances-idp187568">
|
||||
<title>Disable live migration</title>
|
||||
<para>At this time, live migration is enabled in OpenStack by default. Live migrations can be disabled by adding the following lines to the nova policy.json file:</para>
|
||||
<para>At this time, live migration is enabled in OpenStack
|
||||
by default. Live migrations can be disabled by adding the
|
||||
following lines to the nova <filename>policy.json</filename>
|
||||
file:</para>
|
||||
<programlisting>"compute_extension:admin_actions:migrate": "!",
|
||||
"compute_extension:admin_actions:migrateLive": "!",</programlisting>
|
||||
</section>
|
||||
|
||||
@ -22,25 +22,81 @@
|
||||
</itemizedlist>
|
||||
<section xml:id="ch061_compliance-overview-idp48672">
|
||||
<title>Security principles</title>
|
||||
<para>Industry standard security principles provide a baseline for compliance certifications and attestations. If these principles are considered and referenced throughout an OpenStack deployment, certification activities may be simplified.</para>
|
||||
<orderedlist><listitem>
|
||||
<para><emphasis>Layered Defenses</emphasis>: Identify where risks exist in a cloud architecture and apply controls to mitigate the risks. In areas of significant concern, layered defences provide multiple complementary controls to further mitigate risk. For example, to ensure adequate isolation between cloud tenants, we recommend hardening QEMU, using a hypervisor with SELinux support, enforcing mandatory access control policies, and reducing the overall attack surface. The foundational principle is to harden an area of concern with multiple layers of defense such that if any one layer is compromised, other layers will exist to offer protection and minimize exposure.</para>
|
||||
<para>Industry standard security principles provide a baseline
|
||||
for compliance certifications and attestations. If these
|
||||
principles are considered and referenced throughout an OpenStack
|
||||
deployment, certification activities may be simplified.</para>
|
||||
<variablelist>
|
||||
<varlistentry><term>Layered defenses</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Identify where risks exist in a cloud architecture and
|
||||
apply controls to mitigate the risks. In areas of
|
||||
significant concern, layered defences provide multiple
|
||||
complementary controls to further mitigate risk. For
|
||||
example, to ensure adequate isolation between cloud
|
||||
tenants, we recommend hardening QEMU, using a hypervisor
|
||||
with SELinux support, enforcing mandatory access control
|
||||
policies, and reducing the overall attack surface. The
|
||||
foundational principle is to harden an area of concern
|
||||
with multiple layers of defense such that if any one
|
||||
layer is compromised, other layers will exist to offer
|
||||
protection and minimize exposure.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry><term>Fail securely</term>
|
||||
<listitem>
|
||||
<para>
|
||||
In the case of failure, systems should be configured to
|
||||
fail into a closed secure state. For example, SSL
|
||||
certificate verification should fail closed by severing
|
||||
the network connection if the CNAME doesn't match the
|
||||
server's DNS name. Software often fails open in this
|
||||
situation, allowing the connection to proceed without a
|
||||
CNAME match, which is less secure and not
|
||||
recommended.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry><term>Least privilege</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Only the minimum level of access for users and system
|
||||
services is granted. This access is based upon role,
|
||||
responsibility and job function. This security principal
|
||||
of least privilege is written into several international
|
||||
government security policies, such as NIST 800-53
|
||||
Section AC-6 within the United States.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry><term>Compartmentalize</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Systems should be segregated in a such way that if one
|
||||
machine, or system-level service, is compromised the
|
||||
security of the other systems will remain
|
||||
intact. Practically, the enablement and proper usage of
|
||||
SELinux helps accomplish this goal.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Fail Securely</emphasis>: In the case of failure, systems should be configured to fail into a closed secure state. For example, SSL certificate verification should fail closed by severing the network connection if the CNAME doesn't match the server's DNS name. Software often fails open in this situation, allowing the connection to proceed without a CNAME match, which is less secure and not recommended.</para>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Promote privacy</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The amount of information that can be gathered about a
|
||||
system and its users should be minimized.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Logging capability</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Appropriate logging is implemented to monitor for
|
||||
unauthorized use, incident response and forensics. It is
|
||||
highly recommended that selected audit subsystems be
|
||||
Common Criteria certified, which provides non-attestable
|
||||
event records in most countries.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Least Privilege</emphasis>: Only the minimum level of access for users and system services is granted. This access is based upon role, responsibility and job function. This security principal of least privilege is written into several international government security policies, such as NIST 800-53 Section AC-6 within the United States.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Compartmentalize</emphasis>: Systems should be segregated in a such way that if one machine, or system-level service, is compromised the security of the other systems will remain intact. Practically, the enablement and proper usage of SELinux helps accomplish this goal.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Promote Privacy</emphasis>: The amount of information that can be gathered about a system and its users should be minimized.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Logging Capability</emphasis>: Appropriate logging is implemented to monitor for unauthorized use, incident response and forensics. It is highly recommended that selected audit subsystems be Common Criteria certified, which provides non-attestable event records in most countries.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -11,8 +11,8 @@
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis role="bold">Implementation and Operation of
|
||||
Security Controls.</emphasis> Aligning the information
|
||||
<emphasis role="bold">Implementation and operation of
|
||||
security controls.</emphasis> Aligning the information
|
||||
system with in-scope standards and regulations involves
|
||||
internal tasks which must be conducted before a formal
|
||||
assessment. Auditors may be involved at this state to
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
</section>
|
||||
<section xml:id="ch063_compliance-activities-idp46224">
|
||||
<title>Risk assessment</title>
|
||||
<para>A Risk Assessment framework identifies risks within an organization or service, and specifies ownership of these risks, along with implementation and mitigation strategies. Risks apply to all areas of the service, from technical controls to environmental disaster scenarios and human elements, for example a malicious insider (or rogue employee). Risks can be rated using a variety of mechanisms, for example likelihood vs impact. An OpenStack deployment risk assessment can include control gaps that are described in this book.</para>
|
||||
<para>A risk assessment framework identifies risks within an organization or service, and specifies ownership of these risks, along with implementation and mitigation strategies. Risks apply to all areas of the service, from technical controls to environmental disaster scenarios and human elements, for example a malicious insider (or rogue employee). Risks can be rated using a variety of mechanisms, for example likelihood vs impact. An OpenStack deployment risk assessment can include control gaps that are described in this book.</para>
|
||||
</section>
|
||||
<section xml:id="ch063_compliance-activities-idp47920">
|
||||
<title>Access and log reviews</title>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user