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.
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.
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.
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.
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.
Promote privacy
The amount of information that can be gathered about a
system and its users should be minimized.
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.