64b6c9261e
Current folder name New folder name Book title ---------------------------------------------------------- basic-install DELETE cli-guide DELETE common common NEW admin-guide-cloud Cloud Administrators Guide docbkx-example DELETE openstack-block-storage-admin DELETE openstack-compute-admin DELETE openstack-config config-reference OpenStack Configuration Reference openstack-ha high-availability-guide OpenStack High Availabilty Guide openstack-image image-guide OpenStack Virtual Machine Image Guide openstack-install install-guide OpenStack Installation Guide openstack-network-connectivity-admin admin-guide-network OpenStack Networking Administration Guide openstack-object-storage-admin DELETE openstack-security security-guide OpenStack Security Guide openstack-training training-guide OpenStack Training Guide openstack-user user-guide OpenStack End User Guide openstack-user-admin user-guide-admin OpenStack Admin User Guide glossary NEW OpenStack Glossary bug: #1220407 Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7 author: diane fleming
42 lines
4.0 KiB
XML
42 lines
4.0 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch061_compliance-overview"><?dbhtml stop-chunking?>
|
||
<title>Compliance Overview</title>
|
||
<para>An OpenStack deployment may require compliance activities for many purposes, such as regulatory and legal requirements, customer need, privacy considerations, and security best practices. Compliance, when done correctly, unifies and strengthens the other security topics discussed in this guide. This chapter has several objectives:</para>
|
||
<itemizedlist><listitem>
|
||
<para>Review common security principles.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Discuss common control frameworks and certification resources to achieve industry certifications or regulator attestations.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Act as a reference for auditors when evaluating OpenStack deployments.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Introduce privacy considerations specific to OpenStack and cloud environments.</para>
|
||
</listitem>
|
||
</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>
|
||
</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>
|
||
</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>
|
||
</section>
|
||
</chapter>
|