Atom feed of this document
  
 

 Chapter 47. Compliance Overview

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:

  • Review common security principles.

  • Discuss common control frameworks and certification resources to achieve industry certifications or regulator attestations.

  • Act as a reference for auditors when evaluating OpenStack deployments.

  • Introduce privacy considerations specific to OpenStack and cloud environments.

 Security Principles

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.

  1. Layered Defenses: 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.

  2. Fail Securely: 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.

  3. Least Privilege: 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. 

  4. Compartmentalize: 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.

  5. Promote Privacy: The amount of information that can be gathered about a system and its users should be minimized.

  6. Logging Capability: 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.

Questions? Discuss on ask.openstack.org
Found an error? Report a bug against this page

loading table of contents...