Dell EMC PowerStore 2.0 – Part5, Security Enhancements

So Far, we provided, an high level overview of the PowerStore 2.0 release, A deep dive into the DRE enhancements, NVMe Over FC integration with VMware and, the PowerStore 500T platform

Last year, PowerStore changed the storage industry forever with a revolutionary new platform that made IT solutions around the world more data-centric, intelligent and adaptable. PowerStore has since become the fastest-ramping new storage platform in Dell Technologies history, with customer deployments in over 60 countries – and numerous industry accolades, including two Product of the Year awards.

The new PowerStore 2.0 release introduces security & auditing enhancements:

Active Directory/OpenLDAP:

In addition to the local users management, PowerStoreOS 1.0 SP3 or later supports the Active Directory/OpenLDAP feature.

You can manage the directory server settings in Settings > Users > Directory Services. To individually map AD/LDAP users or groups to a role in PowerStore, go to Settings > Users > Users > LDAP tab. PowerStore supports one instance of a directory connection with one or multiple servers for redundancy.

The directory structure of Active Directory and OpenLDAP is similar, but the implementation of each directory server may use a different naming scheme and structure. A directory service is based on a hierarchical database that is referenced as a tree. Some implementations may represent the geographical structure of an organization, and other implementations show the organizational structure. Like a tree, the structure starts with a root which usually represents domain components (DC) of a computer network or organization and splits into multiple branches. Each branch starts with a structural object-like organizational unit (OU) or common name (CN). The tree can continue with more branches or end in leaf objects. Leaf objects can stand for individual items like a user, a group, or a computer. Within the tree, each leaf object is identified by a concatenated string of individual elements that are separated by commas and is called a distinguished name (DN). Each DN is unique in a directory.

For example, a user and group can have the same leaf name, but the path to the object makes the leaf instance a unique DN. To find the right leaf object for a user or group that is used for authentication, you can limit a lookup to certain parts of the tree by using a search path. A search path is useful when the directory represents a company structure, when using a filter for attributes, or when using a combination of both.

An example of a user object in a directory structured by the organization may look like this:

dn: cn=PowerStore User, ou=users, ou=Storage, dc=dell, dc=com

cn: PowerStore User

objectClass: person

sn: PowerStore u

id: pstuser

uidNumber: 1234

home: /home/pstuser

In this example, if the PowerStore users are only in the storage department, a good choice for the user search path would be: ou=users, ou=storage, dc=dell, dc=com. In the example, more information is used to narrow down the type of the object with a filter where objectClass is person.

The structure of groups is similar to users. The group might be as follows:

dn: cn=PowerStore Users, ou=groups, ou=Storage, dc=dell, dc=com

objectClass: Group

cn: PowerStore Users

member: cn=Powerstore User A, ou=users, ou=Storage, dc=dell, dc=com

member: cn=Powerstore User B, ou=users, ou=Storage, dc=dell, dc=com

member: cn=Powerstore User C, ou=users, ou=Storage, dc=dell, dc=com

Similar to the user object above, it is possible in that structure to limit the lookup only to the branch: ou=groups, ou=storage, dc=dell, dc=com, and filter for the objectClass Group to search for a group. The group example shows member attributes containing the distinguished name of each individual user. Other implementations may use the memberUid attribute where only the user UID is listed. In that case, the directory must ensure that UIDs are unique.

Remote Syslog Server

For security auditing, remote syslog support was introduced in PowerStoreOS 2.0. This feature allows the sending of PowerStore audit logs to up to two remote syslog servers. For the connection, TLS encryption can be enabled optionally.

The PowerStore storage system supports sending audit log messages to a maximum of two hosts. The hosts must be accessible from the storage system. Audit log message transfers can use a one-way authentication (Server CA Certificates) or an optional two-way authentication (Mutual Authentication Certificate). An imported certificate applies to each remote syslog server that is configured to use TLS Encryption.

To review or update remote logging settings, log in to PowerStore Manager and click Settings, and under Security select Remote Logging.

The following information appears on the Remote Logging page for Remote Syslog Servers:

● Disabled or Enabled – Status of the sending log information to a remote host.

● Host IP address – Where the storage system sends remote log information.

● Port number and protocol (UDP or TCP) – The storage system transfers audit log information through port 514 using the UDP protocol or port 1468 using the TCP protocol.

● Use certificate – A Server CA Certificate for one-way authentication with your remote syslog server is required to be imported for remote syslog servers that are configured to use TLS Encryption.

● Audit Types – Types of audit events to send to the remote syslog server. The following types of audit events can be selected to be sent to the remote syslog server:

○ Authentication

○ Authorization

○ Config (Configuration)

○ Logout

○ System

TLS 1.1 Support

Transport Layer Security (TLS) is a cryptographic protocol for secure communication over a computer network, Powerstore default encryption is based on TLS 1.2

TLS 1.1 has known vulnerabilities, but still used by a few legacy applications and as a result we’ve added the option to enable it via PowerStore manager, CLI, and Rest API

Please note that this operations affects connectivity for PowerStore Manager, Rest API, and PowerStore CLI.

Configure Transport Layer Security (TLS) for a PowerStore cluster through any of the following means:

● Transport Layer Security – A Transport Layer Security settings page that you can access from the PowerStore Manager (click Settings and, under Security, select Transport Layer Security).

● REST API server – Application interface that can receive REST API requests to configure Transport Layer Security settings. For more information about the REST API, see the PowerStore REST API Reference Guide.