Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Enterprise Storage 7

2 About this guide Edit source

There a three main pillars of security:

  • Confidentiality: Protect information from unauthorized access.

  • Integrity: Ensure that information is accurate, consistent and only changed via authorized operations.

  • Availability: The ressource is available when needed.

This guide is mainly concerned with confidentiality and integrity. Availability is something you can configure in SUSE Enterprise Storage easily depending on your requirements. It is important that you consider the availability requirements you have and create the cluster accordingly. For example, high availability requirements ensure that you do not have a single point of failure. Especially Ceph Monitor nodes are critical and need to be available at all times. SUSE Enterprise Storage makes it easy for you to have more nodes for a given service than what you need during normal operations. The more important a service is to you the more redundancy you need to build into the system.

When you plan for availability, make sure the SUSE Enterprise Storage environment is not isolated. The requirements also affect other systems that interact with SUSE Enterprise Storage transitively. For example, if you use LDAP for authentication, then a highly available SUSE Enterprise Storage cluster does not help you if the LDAP server is not reachable.

Confidentiality needs to consider the life cycle of the data in question and the hardware that is used to hold the data. You not only need to take measures to ensure the confidentiality of data while it's kept in SUSE Enterprise Storage, you also need to consider how to safely discard data once you remove hardware.

Integrity requires that the cluster is in a trusted state and that data can only be modified by authorized subjects. Keeping the cluster up to date is the most important step in ensuring the integrity of the cluster. Ensuring that only authorized subjects can change data requires that permissions are handed out in a controlled and granular way. To ensure that this does not deteriorate over time, ensure that you regularly review existing permissions and have processes in place that revoke them if necessary.

This guide will not give you a set of commands you can run to ensure security. The new system needs to be integrated into your organizational security framework and the concrete steps often depend on your local configurations. For example, the recommendations on how to structure the network and which ports need to made available then need to be translated into changes of you existing networking hardware, such as firewalls.

Some suggested changes have performance implications. Changing a plain text to a encrypted protocol causes the cluster to have more work. This may not be noticeable (such as full disk encryption for OSDs, where the CPU is not the limiting factor), but you need to check for your setup if this causes issues for you with workloads that are realistic for your environment.

Print this page