Home > Storage > PowerScale (Isilon) > Product Documentation > Security and Compliance > Dell PowerScale OneFS: Security Considerations > PowerScale OneFS zero trust
This section focuses on applying the zero trust architecture to a Dell PowerScale cluster. PowerScale OneFS combines the three layers of storage architecture—file system, volume manager, and data protection—into a scale-out NAS cluster. A PowerScale cluster consists of multiple nodes, which are rack-mountable enterprise appliances containing memory, CPU, networking, Ethernet or low-latency InfiniBand interconnects, and storage media. As such, each node in the distributed cluster has compute and storage or capacity capabilities.
This data model is used to apply zero trust on a PowerScale cluster to interpret and refine the original framework. Data is the primary and permanent asset from a data-model perspective and a data-center perspective. Applications are developed to meet new requirements and replace existing applications, but data remains the permanent asset. Data is an organization’s single most valuable asset, described by the term data capital, as stated in the MIT Technology Review. Given the significance and value of an organization's data, the PowerScale zero trust implementation is based on a data capital principle of prioritizing data over other assets.
Each section of this paper may not apply to every organization. The implementation in this paper is provided as a model. Administrators are encouraged to use and reference the model to meet their organization's workflow and specific IT requirements.
The PowerScale zero trust architecture is based on the NIST Cybersecurity Framework (CSF) and the data model. The NIST CSF is a set of best practices for organizations to secure their data with the five principles of identify, protect, detect, respond, and recover. The data model is applied given the data capital principle. Combining the framework from the NIST CSF and the data model provides the basis for the PowerScale zero trust architecture in five key stages, as shown in the following figure.
In the first step in applying the zero trust architecture based on the NIST CSF and the data model, you must locate, sort, and tag the dataset. Next, you can specify roles and limit access. Then, you encrypt the data and apply cybersecurity, which is a critical component in today’s environment. Finally, use monitoring to provide ongoing insights into cluster health.
Besides the configuration steps provided in this section, review this white paper in its entirety and review the OneFS Security Configuration Guide at OneFS Info Hubs with the relevant release for more security configuration and hardening considerations.
The first step to securing a PowerScale cluster is to understand the dataset. Although this step seems obvious, the importance of completing this process impacts the ability to secure data effectively. Understanding the data includes locating, sorting, and tagging the data. Locating the data is a cumbersome and tedious process to complete manually. We recommend using Superna Eyeglass Search & Recover to understand your unstructured data and provide insights through a single pane of glass.
Eyeglass Search & Recover allows customers to maximize data value by locating it. You can locate data through a complete content index that provides a current data index with changes, as shown in the following figure. Also, the index includes OneFS snapshots with version history, file recovery, and full content searching. For more information about Eyeglass Search & Recover, see Eyeglass Search & Recover Product Overview.
After you locate, identify, and index the data, the next step in applying the zero trust architecture is to associate roles to the indexed data. Rather than allowing all administrators and users to access all data, the role-specific administrators and users have access to a subset of the data necessary for their responsibilities.
OneFS provides Role Based Access Control (RBAC), limiting system access based on an administrative role. You can use RBAC to minimize the administrators who have full system access to a PowerScale cluster, allowing each administrator to manage a subset of the cluster and data only, as shown in the following figure. While defining the roles and access, consider that administrators only require minimal access specific to their roles. You may grant other permissions in the future as required. Conversely, from a user perspective, each user only requires access to the subset of data where they practice, and you can provide other permissions in the future as required. Furthermore, you can disable root access altogether.
For more information about RBAC, see the document PowerScale OneFS Authentication, Identity Management, and Authorization. For disabling root access, see the OneFS Security Configuration Guide at OneFS Info Hubs for the relevant release.
Note: As a best practice, before deploying a production PowerScale cluster, test a security configuration on the PowerScale simulator in a lab environment. Then, update all system login access information before placing a system on the network. Ensure that only necessary services and protocols are enabled. Before deploying a PowerScale cluster, consider the data protocols and services required for an environment. If the plan does not include the use of specific protocols, consider disabling those. See the document OneFS Security Configuration Guide at OneFS Info Hubs for the relevant release, for information about disabling protocols.
As a best practice for any enterprise system, enforce that system access requires custom passwords and settings rather than the default vendor-configured settings. Unauthorized malicious parties gain system access by first trying system defaults and publicly known settings. OneFS allows administrators to define login settings at the initial system deployment or to update a production cluster. For configuration steps, see the OneFS CLI Administration Guide at OneFS Info Hubs for the relevant release.
Note: As a best practice, before deploying a production PowerScale cluster, design the system access hierarchy containing the profiles that you want. This action minimizes complications in the future, as security profiles do not require modifications.
Ensure that every individual with access to the cluster has a specific identification and is authenticated through a secure process. The identification and authentication processes provide accountability for all actions within a system. Administrators define user identification and authentication within a PowerScale cluster.
Local authentication is available, allowing you to locally create each ID, which is not recommended for an aggressive security posture. On the contrary, external authentication is available through Active Directory or an LDAP provider. See the document PowerScale OneFS Authentication, Identity Management, and Authorization and the OneFS CLI Administration Guide at OneFS Info Hubs for the relevant release for more information about defining user identification and options.
Also consider requirements defining lockout duration, idle sessions, cryptography, password complexity, and password expiration. Implementing these requirements in OneFS is explained in the OneFS Security Configuration Guide at OneFS Info Hubs for the relevant release.
As you update access requirements, configure cluster auditing. Auditing can detect many potential sources of data loss, including fraudulent activities, inappropriate entitlements, unauthorized access attempts, and a range of other anomalies that are risk indicators. Also, PowerScale OneFS can audit system configuration and protocol events through APIs, allowing events to be tracked and recorded. For more information about auditing in OneFS, see the document File System Auditing with Dell PowerScale and Dell Common Event Enabler. Configuring auditing in OneFS is also explained in the OneFS CLI Administration Guide at OneFS Info Hubs for the relevant release.
As a best practice to strengthen authentication, require multifactor authentication for SSH. For more information about multifactor authentication, see the PowerScale OneFS Authentication, Identity Management, and Authorization white paper. For more information, on disabling the WebUI, see Disabling nonessential HTTP componentsDisabling nonessential HTTP components.
For the next step in deploying the zero trust architecture, use encryption to protect the data from theft and man-in-the-middle attacks.
Data at rest is inactive data that is physically stored on persistent storage. Encrypting data at rest with cryptography ensures that the data is protected from theft if someone removes drives or nodes from a PowerScale cluster.
PowerScale OneFS provides Data at Rest Encryption (D@RE) using SEDs, ensuring that data is encrypted during writes and decrypted during reads. Data stored on the SEDs are encrypted and decrypted with a 256-bit data AES encryption key, referred to as the data encryption key (DEK). OneFS takes the standard SED encryption further by wrapping the DEK for each SED in an authentication key (AK). Further preventing unauthorized access, the AKs for each drive are placed in a key manager (KM) that is stored securely in an encrypted database, the key manager database (KMDB). The KMDB is encrypted with a 256-bit universal key (UK). Finally, the 256-bit universal key is stored external to the PowerScale cluster using a key management interoperability protocol (KMIP)-compliant key manager server, as shown in the following figure.
For more information about DARE and configuring the feature, see PowerScale Data at Rest EncryptionPowerScale Data at Rest Encryption.
Data in flight is active data that is in the transmission process. Encrypting the transmission process secures the data from man-in-the-middle attacks. While client access is encrypted with protocols that support encryption, this step also applies to data replication.
PowerScale OneFS supports the SMB3 and NFS v4.1 protocols, allowing users to encrypt data in flight. OneFS supports encryption of all SMB shares as a global rule, or it can be configured for a single SMB share. SMB encryption secures data access with over the wire encryption between a client and the PowerScale cluster. SMB encryption can be used by clients that support SMB3 encryption, including Windows Server 2012, 2012 R2, 2016, Windows Client 8, and Windows 10. Configuring SMB encryption does not require additional infrastructure. For more information about SMB encryption and configuring the feature, see the document PowerScale: Solution Design and Considerations for SMB Environments. Further, configure OneFS to reject the older clients that lack SMB encryption support access.
Although SMB supports encryption natively, NFS requires additional Kerberos authentication to encrypt data in flight. OneFS 9.3.0.0 and later versions support NFS v4.1, allowing Kerberos support to encrypt traffic between the client and the PowerScale cluster. See the document PowerScale OneFS NFS Design Considerations and Best Practices for more information about NFS and configuring the feature.
Once the protocol access is encrypted, the next step is encrypting data replication. OneFS supports over-the-wire, end-to-end encryption for SyncIQ data replication, protecting and securing in-flight data between clusters. A global setting enforces encryption on all incoming and outgoing SyncIQ policies. For more information about SyncIQ encryption and configuring the feature, see the document PowerScale SyncIQ: Architecture, Configuration, and Considerations.
Protection from cyber threats must be part of any security model. Besides the zero trust model explained in this paper, cyber protection is another key component. Superna Eyeglass Ransomware Defender for PowerScale provides cyber resiliency. It protects a PowerScale cluster by detecting attack events in real time and recovering from cyberattacks. Using innovative air-gap technology, Ransomware Defender creates a dataset copy in a cyber vault outside of the production environment. Further, event triggers create an automated response with real-time access auditing, as shown in the following figure. As a result, failover and failbacks are automated, and data is recovered quickly. See the document PowerScale Cyber Protection Suite Reference Architecture | Dell Technologies Info Hub for more information.
The final step in applying a zero trust architecture is to monitor the cluster constantly through several tools. InsightIQand Ransomware Defender provide insights into the cluster performance and their other functions.
Dell also offers CloudIQ, ensuring proactive cybersecurity assessments protect infrastructure. CloudIQ combines proactive monitoring, machine learning, and predictive analytics, allowing administrators to take quick action. As a result, IT administrative operations are simplified for on-premises infrastructure and data protection in the cloud. Also, CloudIQ monitors PowerScale and supports a broad range of Dell products providing easy management through a single pane of glass. CloudIQ cybersecurity insights follow a three-step process: reduce risk, manage policy, and improve productivity. The closed-loop cybersecurity process is shown in the following figure. For more information about CloudIQ, see Dell CloudIQ - AIOps for Intelligent IT Infrastructure Insights.
Further, consider using the PowerScale OneFS SDK to create custom applications specific to an environment or IT administration requirements. The SDK uses the OneFS API to configure, manage, and monitor cluster functionality. Also, the SDK can perform operations on files and directories on the cluster. Combined, these applications provide greater visibility into a PowerScale cluster.
For more information on InsightIQ, see PowerScale InsightIQ - Info Hub | Dell US.