Contents

Dell PowerMax 2000 Storage Product Guide PDF

1 of 81
1 of 81

Summary of Content for Dell PowerMax 2000 Storage Product Guide PDF

Dell PowerMax Family Security Configuration Guide PowerMaxOS

July 2022 Rev. 07

Notes, cautions, and warnings

NOTE: A NOTE indicates important information that helps you make better use of your product.

CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid

the problem.

WARNING: A WARNING indicates a potential for property damage, personal injury, or death.

2018 - 2022 Dell Inc. or its subsidiaries. All rights reserved. Dell Technologies, Dell, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners.

Figures..........................................................................................................................................7

Tables........................................................................................................................................... 8

Preface.........................................................................................................................................................................................9 Revision history.................................................................................................................................................................. 13

Chapter 1: Overview.....................................................................................................................14 System Overview............................................................................................................................................................... 14 Points of access................................................................................................................................................................. 14 Code signing........................................................................................................................................................................15

Code signing methods.................................................................................................................................................15 Verifying the signature................................................................................................................................................15

Hardware root of trust..................................................................................................................................................... 19 Secure boot and Measured boot................................................................................................................................... 20 Secure firmware upgrade................................................................................................................................................20 Security controls map....................................................................................................................................................... 21

Chapter 2: Physical Security....................................................................................................... 22 Physical security controls................................................................................................................................................22 Port security.......................................................................................................................................................................22

Chapter 3: Solutions Enabler....................................................................................................... 23 Solutions Enabler overview.............................................................................................................................................23 Solutions Enabler checklist............................................................................................................................................. 23 SYMAPI home and bin directory locations.................................................................................................................. 25 Security controls map...................................................................................................................................................... 26 Access control................................................................................................................................................................... 26

Host-based access control ...................................................................................................................................... 26 User-based access control........................................................................................................................................28

Solutions Enabler logfiles.................................................................................................................................................29 Port usage...........................................................................................................................................................................29 Client/server security settings...................................................................................................................................... 30

Network encryption.................................................................................................................................................... 30 Securing remote connections using TLS/SSL...................................................................................................... 31 Server host security.................................................................................................................................................... 31 Client host security..................................................................................................................................................... 32 Secure session configuration summary..................................................................................................................33

Certificate files...................................................................................................................................................................34 Managing backward compatibility of certificates................................................................................................35 Configuring secure client/server support with custom certificates...............................................................35

Server security considerations.......................................................................................................................................37 Specifying nodes and addresses....................................................................................................................................38 Concurrent connections.................................................................................................................................................. 39 Control operations for IBM z/OS..................................................................................................................................40 File backup.......................................................................................................................................................................... 40

Contents

Contents 3

Audit log..........................................................................................................................................................................41 File protection............................................................................................................................................................... 41 Non-privileged user command use...........................................................................................................................41

Lockbox................................................................................................................................................................................42 Stable System Values (SSVs).................................................................................................................................. 42 Lockbox passwords.....................................................................................................................................................42 Password and SSV management.............................................................................................................................43

Daemon security settings................................................................................................................................................43 Daemon identity on UNIX.......................................................................................................................................... 43 Secure host directories..............................................................................................................................................44 Secure directory path.................................................................................................................................................44 Daemon connection authorization...........................................................................................................................45

SRM daemon connections.............................................................................................................................................. 45

Chapter 4: Unisphere.................................................................................................................. 46 Unisphere checklist...........................................................................................................................................................46 Security controls map.......................................................................................................................................................47 Unisphere access control................................................................................................................................................ 47

User-based access control........................................................................................................................................47 Audit log.........................................................................................................................................................................48 symauth rules............................................................................................................................................................... 49 Individual and group roles..........................................................................................................................................49 User IDs......................................................................................................................................................................... 49

User authorization............................................................................................................................................................. 51 Authorization for the Initial Setup User..................................................................................................................51 Unisphere REST API....................................................................................................................................................51 Multiple authorization roles....................................................................................................................................... 51

Unisphere and CA server certificates........................................................................................................................... 51 Port usage...........................................................................................................................................................................52 Link-and-launch security................................................................................................................................................. 52 Unisphere data security...................................................................................................................................................52 Security alert system........................................................................................................................................................53 Session inactivity...............................................................................................................................................................53 CyberSecIQ.........................................................................................................................................................................53 Serviceability in Unisphere.............................................................................................................................................. 53

Multi-factor authentication for SecurID................................................................................................................ 53 Certificate Management............................................................................................................................................54 SSC authentication..................................................................................................................................................... 55 Log file settings........................................................................................................................................................... 55

Chapter 5: SMI-S Provider.......................................................................................................... 56 SMI-S Provider Overview............................................................................................................................................... 56 SMI-S checklist..................................................................................................................................................................56 ECOM toolkit......................................................................................................................................................................57 Security controls map...................................................................................................................................................... 57 User-based access control..............................................................................................................................................57

User authorization....................................................................................................................................................... 57 User authentication.................................................................................................................................................... 58 Administrator user account.......................................................................................................................................58

4 Contents

Component access control............................................................................................................................................. 60 Log files and settings....................................................................................................................................................... 60

Displaying log files........................................................................................................................................................61 Port usage............................................................................................................................................................................61 Network encryption...........................................................................................................................................................61

Group Replication.........................................................................................................................................................61 Enabling Global Mode................................................................................................................................................. 62

Enable authentication for SMI-S................................................................................................................................... 62 Manage the Lockbox .......................................................................................................................................................62

Create the Lockbox.................................................................................................................................................... 62 Security alerts.................................................................................................................................................................... 63

Chapter 6: Container Applications...............................................................................................64 Overview of container applications.............................................................................................................................. 64 Container application access IDs...................................................................................................................................64

Client/server mode..................................................................................................................................................... 64

Chapter 7: PowerMax File............................................................................................................66 PowerMax File................................................................................................................................................................... 66 PowerMax File security controls map.......................................................................................................................... 67

Chapter 8: Embedded NAS.......................................................................................................... 68 Embedded NAS..................................................................................................................................................................68 Security controls map...................................................................................................................................................... 69

Chapter 9: Embedded Management............................................................................................. 70 Embedded Management..................................................................................................................................................70 Security controls map...................................................................................................................................................... 70 Embedded VASA Provider............................................................................................................................................... 71 Virtual machine ports........................................................................................................................................................72

Chapter 10: vApps....................................................................................................................... 73 vApps overview..................................................................................................................................................................73 vApps checklist.................................................................................................................................................................. 73 Security controls map.......................................................................................................................................................74 Deployment settings and points of access................................................................................................................. 75

Limiting access to management interfaces...........................................................................................................75 User authentication...........................................................................................................................................................75

VASA/eVASA Provider authentication...................................................................................................................76 Default user accounts.................................................................................................................................................76

Port usage........................................................................................................................................................................... 76 Log files and settings........................................................................................................................................................77

Log file management.................................................................................................................................................. 78 SSL certificates..................................................................................................................................................................78 Data security settings...................................................................................................................................................... 78 Serviceability.......................................................................................................................................................................79 Alerts.................................................................................................................................................................................... 79 ClamAV................................................................................................................................................................................ 79 Upgrades............................................................................................................................................................................. 79

Contents 5

Chapter 11: Data at Rest Encryption............................................................................................ 80 Overview............................................................................................................................................................................. 80 Key manager........................................................................................................................................................................81 Key protection.................................................................................................................................................................... 81

6 Contents

1 Import DELL_EMC.pub for verifying Dell EMC kits......................................................................................... 17

2 Verification with ultimate trust..............................................................................................................................17

3 Verification of Solutions Enabler kits without trust......................................................................................... 18

4 Verification of Solutions Enabler kits with trust............................................................................................... 18

5 Verification of Unisphere kit without trust.........................................................................................................19

6 Verification of Unisphere kit with trust...............................................................................................................19

7 Verification of Unisphere 360 kit without trust................................................................................................ 19

8 Verification of Unisphere 360 kit with trust...................................................................................................... 19

9 Solutions Enabler components............................................................................................................................. 26

10 Unisphere components...........................................................................................................................................47

11 Overview of Multi-factor authentication for SecurID.................................................................................... 54

12 SMI-S managed objects......................................................................................................................................... 57

13 PowerMax File managed objects......................................................................................................................... 67

14 Embedded NAS managed objects....................................................................................................................... 69

15 eManagement managed objects.......................................................................................................................... 70

16 eVASA Provider architecture - PowerMaxOS 10..............................................................................................71

17 eVASA Provider architecture - PowerMaxOS 5978 and earlier................................................................... 72

Figures

Figures 7

1 Typographical conventions used in this content.............................................................................................. 12

2 Revision history......................................................................................................................................................... 13

3 Solutions Enabler security configuration checklist.......................................................................................... 23

4 Ports used by the event daemon.........................................................................................................................30

5 Session negotiation behavior................................................................................................................................. 31

6 Host operating systems that support SSL........................................................................................................ 33

7 Secure sessions summary......................................................................................................................................33

8 Custom certificate configuration settings.........................................................................................................36

9 Options that restrict storsrvd functionality...................................................................................................... 38

10 storsrvd daemon session control options and values..................................................................................... 39

11 Files to back up........................................................................................................................................................ 40

12 Unisphere security configuration checklist....................................................................................................... 46

13 Unisphere component ports..................................................................................................................................52

14 SMI-S security configuration checklist.............................................................................................................. 56

15 Ports used by SMI-S................................................................................................................................................61

16 vApp security configuration checklist.................................................................................................................73

17 vApp default accounts............................................................................................................................................76

18 Network ports used in vApps................................................................................................................................76

Tables

8 Tables

Preface As part of an effort to improve its product lines, Dell Technologies periodically releases revisions of its software and hardware. Functions that are described in this document may not be supported by all versions of the software or hardware. The product release notes provide the most up-to-date information about product features.

Contact your Dell Technologies representative if a product does not function properly or does not function as described in this document.

NOTE: This document was accurate at publication time. New versions of this document might be released on Dell

Technologies Online Support (https://www.dell.com/support/home). Check to ensure that you are using the latest version

of this document.

Purpose This guide helps you to securely deploy and maintain PowerMax arrays, which include applications such as Solutions Enabler and Unisphere for PowerMax.

Audience This document is intended for security administrators and operators that need to understand and maintain PowerMax security.

Related documentation The following Dell publications provide additional information related to managing security for your software and storage system configuration. For a comprehensive list of documentation, see the Dell PowerMax Family Product Guide.

Dell PowerMax Family Site Planning Guide for PowerMax 2000 and PowerMax 8000

Provides planning information regarding the purchase and installation of a PowerMax 2000, 8000 with PowerMaxOS.

Dell EMC Best Practices Guide for AC Power Connections for PowerMax 2000, 8000 with PowerMaxOS

Describes the best practices to assure fault-tolerant power to a PowerMax 2000 or PowerMax 8000 array.

Dell PowerMax Family Product Guide

Provides information about PowerMax 2500 and 8500 with PowerMaxOS 10, and PowerMax 2000 and 8000 arrays with PowerMaxOS 5978.

Dell EMC Unisphere for PowerMax Release Notes

Describes new features and any known limitations for Unisphere for PowerMax.

Dell EMC Unisphere for PowerMax Installation Guide

Provides installation instructions for Unisphere for PowerMax.

Dell EMC Unisphere for

Describes the Unisphere for PowerMax concepts and functions.

Preface 9

PowerMax Online Help

Dell Solutions Enabler, VSS Provider, and SMI-S Provider Release Notes

Describes new features and any known limitations.

Dell Solutions Enabler Release Notes

Describes new features and any known limitations.

Dell Solutions Enabler Installation and Configuration Guide

Provides host-specific installation instructions.

Dell Solutions Enabler CLI Reference Guide

Documents the SYMCLI commands, daemons, error codes and option file parameters provided with the Solutions Enabler man pages.

Dell Solutions Enabler Array Controls and Management CLI User Guide

Describes how to configure array control, management, and migration operations using SYMCLI commands for arrays running HYPERMAX OS and PowerMaxOS.

Dell Solutions Enabler Array Controls and Management CLI User Guide

Describes how to configure array control, management, and migration operations using SYMCLI commands for arrays running Enginuity.

Dell Solutions Enabler SRDF Family CLI User Guide

Describes how to configure and manage SRDF environments using SYMCLI commands.

Dell Solutions Enabler SRDF Family State Tables Guide

Describes the applicable pair states for various SRDF operations.

SRDF Interfamily Connectivity Information

Defines the versions of PowerMaxOS, HYPERMAX OS and Enginuity that can make up valid SRDF replication and SRDF/Metro configurations, and can participate in Non-Disruptive Migration (NDM).

Dell SRDF Introduction

Provides an overview of SRDF, its uses, configurations, and terminology.

Dell Solutions Enabler TimeFinder SnapVX CLI User Guide

Describes how to configure and manage TimeFinder SnapVX environments using SYMCLI commands.

Dell EMC Solutions Enabler TimeFinder Family (Mirror, Clone, Snap, VP Snap) Version 8.2 and higher CLI User Guide

Describes how to configure and manage TimeFinder Mirror, Clone, Snap, VP Snap environments for Enginuity and HYPERMAX OS using SYMCLI commands.

Dell Solutions EnablerTimeFind

Describes how to configure and manage TimeFinder Clone environments for HYPERMAX OS and PowerMaxOS using SYMCLI commands.

10 Preface

er Clone CLI User Guide

Dell EMC Solutions Enabler SRM CLI User Guide

Provides Storage Resource Management (SRM) information that is related to various data objects and data handling facilities.

EMC Common Object Manager (ECOM) Toolkit Deployment and Configuration Guide

Describes how to securely deploy the EMC Common Object Manager (ECOM).

eVASA Provider Release Notes

Describes new features and any known limitations for eVASA Provider.

Dell vApp Manager for eVASA Provider Online Help

Describes the vApp Manager for eVASA Provider concepts and functions.

VASA Provider 9.2.0 Product Guide

Describes how to install and configure VASA Provider and vVol based VMs.

Dell EMC VASA Provider Release Notes

Describes new features and any known limitations for VASA Provider.

Dell EMC vApp Manager for Unisphere for VMAX Online Help

Describes the vApp Manager for Unisphere for VMAX concepts and functions.

Dell EMC vApp Manager for Solutions Enabler Online Help

Describes the vApp Manager for Solutions Enabler concepts and functions.

Dell EMC vApp Manager for eManagement Online Help

Describes the vApp Manager for embedded Management concepts and functions.

Dell EMC vApp Manager for VASA Provider Online Help

Describes the vApp Manager for VASA Provider concepts and functions.

Dell EMC PowerMax eNAS Release Notes

Describes the new features and identify any known functionality restrictions and performance issues that may exist in the current version.

Dell EMC PowerMax eNAS Quick Start Guide

Describes how to configure eNAS on a PowerMax storage system.

Dell EMC PowerMax eNAS File Auto Recovery with SRDF/S

How to install and use File Auto Recovery with SRDF/S.

Dell EMC PowerMax eNAS

A reference for command-line users and script programmers that provides the syntax, error codes, and parameters of all eNAS commands.

Preface 11

CLI Reference Guide

EMC Unisphere for VNX Online Help

Describes how to configure Embedded NAS.

EMC VNX Series Security Configuration Guide for VNX

Describes security settings and configuration for Embedded NAS.

EMC VNX Series Command Line Interface Reference for File

Describes CLI commands to manage access control, certificates, LDAP configuration, and other security- related activities for Embedded NAS.

Mainframe Enablers Installation and Customization Guide

Describes Mainframe Enablers installation requirements and provides installation and upgrade procedures. It also explains how to set up security using the EMCSAFI security interface.

Mainframe Enablers Release Notes

Lists new, changed, and deprecated features for the current release.

Typographical conventions Dell Technologies uses the following type style conventions in this document:

Table 1. Typographical conventions used in this content

Bold Used for names of interface elements

Examples: Names of windows, dialog boxes, buttons, fields, tab names, key names, and menu paths (what the user selects or clicks)

Italic Used for full titles of publications referenced in text

Monospace Used for: System code System output, such as an error message or script Pathnames, filenames, prompts, and syntax Commands and options

Monospace italic Used for variables

Monospace bold Used for user input

[ ] Square brackets enclose optional values.

| A vertical bar indicates alternate selections. The bar means "or".

{ } Braces enclose content that the user must specify, such as x or y or z.

... Ellipses indicate nonessential information that is omitted from the example.

Where to get help Dell Technologies support, product, and licensing information can be obtained as follows:

12 Preface

Product information

Dell Technologies technical support, documentation, release notes, software updates, or information about Dell Technologies products can be obtained at https://www.dell.com/support/home (registration required) or https://www.dell.com/en-us/dt/documentation/vmax-all-flash-family.htm.

Technical support

To open a service request through the Dell Technologies Online Support (https://www.dell.com/ support/home) site, you must have a valid support agreement. Contact your Dell Technologies sales representative for details about obtaining a valid support agreement or to answer any questions about your account.

Reporting security vulnerabilities Dell Technologies takes reports of potential vulnerabilities in our products very seriously. For the latest on how to report a security issue to Dell Technologies, see the Dell Technologies Product Security Response Center at http://www.emc.com/ products/security/product-security-response-center.htm.

Your comments Your suggestions help improve the accuracy, organization, and overall quality of the documentation. Send your comments and feedback to: powermaxcontentfeedback@dell.com

Revision history The following table lists the revision history of this document.

Table 2. Revision history

Revision Description and/or change

02 Initial release of the PowerMax Security Configuration Guide

03 Second release of the PowerMax Security Configuration Guide, Version 9.1.0

04 Third release of the PowerMax Security Configuration Guide, Version 9.2.0

05 Fourth release of the PowerMax Security Configuration Guide, Version 9.2.1

06 Fifth release of the PowerMax Security Configuration Guide, Version 10

Preface 13

Overview This chapter includes the following topics:

Topics:

System Overview Points of access Code signing Hardware root of trust Secure boot and Measured boot Secure firmware upgrade Security controls map

System Overview Dell storage arrays running PowerMaxOS provide industry-leading, information-centric security to secure people, infrastructure, and data. You can authenticate, authorize, and audit activities across systems and devices.

PowerMax arrays

The PowerMax family of arrays has four models:

PowerMax 2000 with a maximum capacity of 1 PBe (Petabytes effective) that can operate in open systems environments PowerMax 2500 with a maximum capacity of 4 PBe (Petabytes effective) that can operate in open systems and mainframe

environments PowerMax 8000 with a maximum capacity of 4 PBe that can operate in open systems, mainframe, or mixed open systems

and mainframe environments PowerMax 8500 with a maximum capacity of 18 PBe that can operate in open systems, mainframe, or mixed open systems

and mainframe environments

Points of access There are two points of access to an array running PowerMax: Direct access to the physical system Through array control management. You can manage an array through host management or from Embedded Management

(eManagement) directly on the array.

The following points of access must be secured in a PowerMax system:

Physical: Physical security includes limiting who has access to the data center and array hardware. It also includes monitoring port access under normal and service operations.

Host: Traditional host-based management enables you to manage multiple arrays from a single management interface. The host can be a physical server or a virtual machine. Host management applications include: Solutions Enabler: Solutions Enabler provides a comprehensive command-line interface, called SYMCLI, to manage your

storage environment. SYMCLI commands are invoked from the host, either interactively through the command line, or by using scripts.

Unisphere for PowerMax: Unisphere provides a web-based application that enables you to quickly and easily provision, manage, and monitor arrays.

SMI-S Provider (supported only in PowerMaxOS 5978 and earlier): SMI-S Provider supports the SNIA Storage Management Initiative (SMI), an ANSI standard for storage management. This initiative has developed a standard management interface that resulted in a comprehensive specification (SMI-Specification or SMI-S). SMI-S defines the

1

14 Overview

open storage management interface, to enable the interoperability of storage management technologies from multiple vendors. These technologies are used to monitor and control storage resources in multivendor or SAN topologies.

Solutions Enabler provides the interface between the SMI and the arrays. The Solutions Enabler components that are required for SMI-S Provider operations are included as part of the SMI-S Provider installation.

Mainframe Enablers: Dell Mainframe Enablers enable you to monitor and manage an array running PowerMaxOS. Embedded: Embedded applications are virtual machines that provide embedded functionality on the array. Embedded

applications use virtual hardware resources, including: Virtual hardware to run the software and embedded application (processor, memory, PCI devices, and virtual power

management) Virtual FA ports (on the director where the container is installed) Access to necessary drives (boot, root, swap, persist, shared)

Three embedded applications are available: Embedded NAS (eNAS - supported only in PowerMaxOS 5978 and earlier), Embedded Management (eManagement) and Embedded VASA Provider (eVASA). eNAS enables consolidated block and file storage without the expense and complexity of gateway hardware. eManagement embeds management software (Solutions Enabler, Unisphere for PowerMax and SMI-S) on the array, enabling you to manage the array without software being installed on a host. eVASA embeds VASA Provider on the array, enabling storage orchestration for vVols between VMware vSphere components and the PowerMax system.

Embedded applications are installed at the factory. No additional security procedures are required.

Code signing

Code signing is the process of adding a digital signature to product and application files (for example, drivers, binary files, configuration files, and so on) to confirm authenticity and integrity. Code signing enables customers to verify that code originates from Dell Technologies, and that the code has not been tampered with since its publication and digital signing by Dell.

Code signing methods

Dell uses these methods for code signing: Windows kits: Microsoft Authenticode Code SigningMicrosoft Authenticode is a digital signature format that relies on the

PKCS #7 standard to provide a way to sign the executable code for supported file formats. The Authenticode signature digitally signs the original content including all the executable code of the file. An Authenticode signature that passes the verification process indicates that none of the executable code that was signed has been tampered with.

Linux kits: GPG Code SigningPowerMax uses GNU Privacy Guard (GPG) to sign kits for Linux platforms. GPG is a public key cryptography implementation. This enables the secure transmission of files between Dell and customers. The customer can now verify that the origin of the files is genuine. The encryption and decryption stages of the transmission are split into two separate stages. The encryption portion is distributed as a free download and the decryption portion is sent through a secure channel.

Verifying the signature

The procedure is different for Microsoft Windows and Linux platforms kits.

Verifying for Microsoft Windows kits

When you try to install the software by running the package, a dialog box opens stating that you may be at risk when trying to install or use binaries that do not have a valid signature. A properly signed file gives access to the identification information of the organization that signed the code in a clear format. Because Dell uses a valid signature, the dialog box will clearly show that the publisher is Dell Technologies Inc.

Overview 15

Verifying Linux kits

To verify non-Windows platforms kits you must have GPG installed on the host that you want to verify.

NOTE: GPG can be downloaded from GnuPG. Download and install it on the host.

To verify GPG signing of kits: 1. Verify that GPG is installed on the host with the command: gpg --version.

2. Download the DELL EMC gpg public key, DELL_EMC.pub, from https://vmahopprd01.isus.emc.com/ artifactory/dell-gpg-pub-key/DELL_EMC.pub

3. Check the public key fingerprint to ensure that it is the correct key:

gpg --with-fingerprint DELL_EMC.pub 4. Import the public key to your GPG public keyring:

gpg --import DELL_EMC.pub 5. Download the PGP signature file of the DELL EMC non-Windows kits which are posted with kits, the signature file name is

.asc for Solutions Enabler and .sig for Unisphere. 6. Use the public key to verify PGP signature. If the signature is correct, this is confirmation that the software was not

tampered with. Solutions Enabler: gpg --verify .asc

Or, if the kit name has not changed, use:

gpg .asc Unisphere kit: gpg --verify .sig

Or, if the kit name has not changed, use:

gpg .sig U360 kit: gpg --verify .sig

Or, if the kit name has not changed, use:

gpg .sig

Trust public key

During signature verification you may see the following warning message: gpg: WARNING: This key is not certified with a trusted signature! To avoid this warning, the imported public key should be trusted with the following steps:

gpg --edit-key CFDF92EA10AAA1278589BD72EA8CC7F5B2E74730, where CFDF92EA10AAA1278589BD72EA8CC7F5B2E74730 is the public key of DELL_EMC.pub.

1. At the gpg> prompt type trust and press Enter.

2. Type 5 and press Enter.

This selects the 5 = I trust ultimately option.

3. Type quit to exit the gpg prompt.

The following images show sample commands and output for verification and verification with ultimate trust procedures.

16 Overview

Figure 1. Import DELL_EMC.pub for verifying Dell EMC kits

Figure 2. Verification with ultimate trust

Verification of Solutions Enabler kits

Overview 17

Figure 3. Verification of Solutions Enabler kits without trust

Figure 4. Verification of Solutions Enabler kits with trust

18 Overview

Verification of Unisphere kit

Figure 5. Verification of Unisphere kit without trust

Figure 6. Verification of Unisphere kit with trust

Verification of Unisphere 360 kit.

Figure 7. Verification of Unisphere 360 kit without trust

Figure 8. Verification of Unisphere 360 kit with trust

Hardware root of trust

PowerMax 2500/8500 arrays use an immutable, silicon-based Hardware Root-of-Trust (HWRoT) to cryptographically attest to the integrity of BIOS and BMC firmware. This root-of-trust is based on one-time programmable, read-only public keys that are provisioned by Dell in the factory to provide protection against malware tampering.

The BIOS boot process uses Intel Boot Guard technology which verifies that the digital signature of the cryptographic hash of the boot image matches the signature stored in silicon by Dell in the factory.

If Boot Guard validates successfully, the rest of the BIOS firmware modules are validated by using a chain of trust procedure until control is handed off to the operating system or hypervisor.

Overview 19

In detail, each BIOS module contains a hash of the next module in the chain. The key modules in BIOS are: IBB (Initial Boot Block), SEC (Security), PEI (Pre-EFI Initialization), MRC (Memory Reference Code), DXE (Driver Execution Environment), and BDS (Boot Device Selection).

If Intel Boot Guard authenticates the IBB (Initial Boot Block), then the IBB validates SEC+PEI before handing control to it. SEC+PEI then validates PEI+MRC which further validates the DXE+BDS modules. At this point, control is handed over to UEFI Secure Boot as explained in the next section.

Rapid recovery to a trusted image is implemented on the PowerMax platform when authentication fails. The rapid recovery is essential within the HWRoT implementation, and is automatically initiated by the BMC to guarantee maximum security and uptime is maintained.

Secure boot and Measured boot

Secure boot

Secure boot is the process of verification that the image to be booted is exactly the image that is expected to be used. Secure boot is used during Hardware Root of Trust, firmware load, and firmware upgrade.

Secure boot is extended through all the various images that must be booted all the way through the execution of the operating system image from bootloaders to firmwares to Initial BIOS to UEFI.

Secure Boot represents an industry-wide standard for security in the pre-boot environment. Computer system vendors, expansion card vendors, and operating system providers collaborate on this specification to promote interoperability.

PowerMaxOS 10 supports industry-standard UEFI (Unified Extensible Firmware Interface) Secure Boot which checks the cryptographic signatures of UEFI drivers, kernels, and other code that is loaded before the operating system runs.

As enabled on PowerMax, UEFI Secure Boot prevents unsigned (that is, untrusted) UEFI device drivers or operating system kernels from being loaded, displays error messages, and does not allow the device to function.

NOTE: The signed network-bootable bootloader is installed on the Control Station as part of the SymmWin install.

Measured boot

The process of storing hash values that are used for authentication during a secure boot sequence is called measured boot. Values are stored in the boot log within a TCG-defined trusted platform module (TPM), public keys, and the various signatures. The TPM values can be used via a token process by an upstream operating system or applications to attest to the expected execution of a secure boot process.

PowerMaxOS 10 supports two versions of TPM: TPM 2.0 FIPS + Common Criteria+ TCG certified TPM 2.0 China certified

The TPM can be used to perform public key cryptographic functions, compute hash functions, generate, manage, and securely store keys, and do attestation.

Attestation and remote attestation solutions in future releases can use the TPM to take measurements at boot time of a PowerMax hardware, hypervisor, BIOS, and operating system, and compare them in a cryptographically secure manner against base measurements that are stored in the TPM. If they are not identical, then the PowerMax array may have been compromised and system administrators can disable and disconnect the array either locally or remotely.

NOTE: TPM is enabled through BIOS in the factory.

Secure firmware upgrade

Secure firmware upgrade denotes use of cryptographic authentication of the digital signatures that are applied to the firmware bootloader and images to be used for updates of the running firmware before running the update process. Public key hashes of the bootloader and other images are verified.

PowerMax has used digital signatures on firmware updates for all components and subcomponents for several generations to assure that only authentic firmware is running on the platform.

Enhanced firmware authentication is embedded within many third-party devices which provide signature validation using their own Root-of-Trust mechanisms. This prevents the possible use of a compromised third-party update tool from being used to load malicious firmware into, for example, a NIC or storage drive (and bypassing the use of signed Dell update packages). Many

20 Overview

of the third-party PCIe and storage devices that are shipped with PowerMax use a hardware Root-of-Trust to validate their respective firmware updates.

If any firmware in any device is suspected of malicious tampering, IT administrators can rollback the platform firmware images to an earlier trusted version stored in PowerMax.

Security controls map

System components for PowerMax storage arrays

Overview 21

Physical Security This chapter describes physical security controls that you should put in place to ensure a secure environment. Topics include:

Topics:

Physical security controls Port security

Physical security controls You are responsible for providing a secure physical environment for an array running PowerMaxOS. A secure environment includes basic measures such as, providing sufficient doors and locks, permitting only authorized and monitored physical access to the system, providing a reliable power source, and following standard cabling best practices.

Port security A storage array includes several physical ports. Ensure that only authorized personnel have access to the ports and that they are used for their intended purpose.

2

22 Physical Security

Solutions Enabler This chapter contains the following topics:

Topics:

Solutions Enabler overview Solutions Enabler checklist SYMAPI home and bin directory locations Security controls map Access control Solutions Enabler logfiles Port usage Client/server security settings Certificate files Server security considerations Specifying nodes and addresses Concurrent connections Control operations for IBM z/OS File backup Lockbox Daemon security settings SRM daemon connections

Solutions Enabler overview Solutions Enabler provides a comprehensive command-line interface (SYMCLI) to manage your storage environment.

Solutions Enabler is available as a host-based component, as part of embedded management, or as a virtual application. This chapter addresses the host-based component.

SYMCLI commands are invoked from the host, either interactively on the command line, or using scripts.

Solutions Enabler 9.0 or greater is required to discover storage arrays running PowerMaxOS.

Solutions Enabler checklist The following checklist summarizes the security-related tasks that you should perform to improve the security of your deployment.

Table 3. Solutions Enabler security configuration checklist

Purpose of activity Task

Host-based access control

Restrict which hosts may access specific functionality. Configure SYMAPI options.

Use the symacl command to generate a unique ID for each management host.

Restrict actions hosts can run. Configure SYMAPI options and use the symacl command to enable use of Alternate Access IDs.

Define Access Control Groups, Pools, and Hosts to control what actions management hosts can run.

3

Solutions Enabler 23

Table 3. Solutions Enabler security configuration checklist (continued)

Purpose of activity Task

Restrict which hosts and users may perform management operations.

Use access control or user authorization to restrict hosts.

Client/server security settings

Reduce local attachments between hosts and storage arrays. Use Solutions Enabler in client/server mode to a storsrvd running on a remote host that is locally attached to the storage.

Protect access to Solutions Enabler resources through firewalls and NATs.

If a firewall or NAT router is used to protect network resources, you may need to: Configure the network resources to enable access to

specific ports. Modify related settings in daemon_options.

Certificate files

Require client verification by the server using client certificates.

Set security_clt_secure_lvl=MUSTVERIFY in the daemon_options file.

Strengthen your authentication by using custom certificates. Replace SYMAPI-generated security certificates with more secure customer-supplied certificates.

On client hosts

Control ports used by the client-side event daemon (storevntd).

Modify the port on which the client-side storevntd listens.

Specify the host (HostName) and port (NNNN) on which the server daemon is listening.

For SYMCLI users, modify the netcnfg file with the hostnames or IP addresses of your servers.

On server hosts

Control the port used by the server daemon (storsrvd). Modify the port on which storsrvd listens (resolve port conflicts).

Control startup of the server daemon (storsrvd). Use the stordaemon install command to configure storsrvd to be started automatically at system boot.

Limit the set of client hosts from which the server accepts connections.

Configure the following: /config/nethost file

The following entries in the /config/ daemon_options file:

max_sessions max_sessions_per_host max_sessions_per_user

Restrict the functionality that the storsrvd daemon is allowed to perform on behalf of remote client hosts.

Edit the following entries in the /config/ options file:

SYMAPI_ACC_ADMIN_VIA_SERVER SYMAPI_ACC_DISPLAY_VIA_SERVER SYMAPI_ALLOW_SCRIPTS_VIA_SERVER SYMAPI_CTRL_VIA_SERVER

Securing directories

Protect the SYMAPI directory and its contents so that only appropriate administrators have write access.

Protect the /config directory.

Protect the /db directory to grant non-root users access.

Configure daemon_users to authorize non-root users to use daemons.

Run SYMCLI commands as a non-root or non-administrator user.

24 Solutions Enabler

Table 3. Solutions Enabler security configuration checklist (continued)

Purpose of activity Task

Limit write access privileges to the /db directory to authorized users only.

Prevent unauthorized access to the Lockbox. Change the Lockbox password immediately after installation to best protect its contents.

Limit which users have write privileges to the config directory. Limit access to the /config directory to authorized users only.

All other users should have limited access (read-only or no access, if possible) to this directory.

Minimize injection attacks and other issues. Use the daemon_options secure_directory_path to specify which output directories daemons may write to.

Securing daemons

Reduce system exposure by using non-root execution of daemons.

Use the stordaemon setuser command to establish a non-root user for daemons, and directory permissions.

Securing SRM operations

Limit access to SRM functionality. Limit permission to the SRM daemon.

Edit the common daemon authorization file, daemon_users.

Limit security exposure by using a database account in SRM with minimal privileges.

Configure a minimally privileged account for SRM database access.

Protect directories and files. Restrict access privileges for directories and files.

Start up and shut down the database server manager instance.

Configure database startup options.

SYMAPI home and bin directory locations The Solutions Enabler and directories are found in the following locations by default:

Windows: C:\Program Files\EMC\SYMAPI... UNIX: /var/symapi/... z/OS: /var/symapi/... Pathnames that are presented in this document use a UNIX-specific format, that is, forward slashes (/) instead of the backslashes (\) typically used on Windows platforms.

Windows: C:\Program Files\EMC\SYMCLI\bin... UNIX: /usr/storapi/bin...

NOTE: By default, the location of is the same for both z/OS and UNIX.

The Dell Solutions Enabler Installation and Configuration Guide provides more information about:

Changing the location for on z/OS systems during installation.

OpenVMS file locations.

Solutions Enabler 25

Security controls map

Solutions Enabler Server

PowerMaxOS

Storage Array

Solutions Enabler Server Host

FC, iSCSI, FICON

Solutions

Enabler Client

Management Hosts

Unisphere for

PowerMax

SMI-S Provider

TLS

TLS

TLS

Figure 9. Solutions Enabler components

Access control Solutions Enabler provides two mechanisms to control access to arrays: host-based access and user-based access.

The symacl command provides host-based access control that can restrict host access to selected sets of devices across multiple arrays. Host-based access control limits the management operations a host can perform and provides highly granular control over management operations. Each host in the storage system is identified by an access ID. Host access information can be modified by attaching or detaching the host access ID, or by renaming the host. Functionality that is provided by the symacl command is called Symmetrix Access Control.

The symauth command provides user-based authorization that assigns a user or group to a role. Roles limit the management operations that users can perform on an array or individual storage groups.

NOTE: When configuring Symmetrix Access Control, you should:

Give access rights only to authorized hosts.

Assign only the privileges users require to perform their tasks.

Grant administration rights to a limited number of users, for example, assign administration rights to only known users

and a select administrative group.

The Dell Solutions Enabler Array Controls and Management CLI User Guide provides information about how to set up and perform host-based access control and user-based authorization with the symacl and symauth commands.

Host-based access control

Host authorization assigns rights to individual management hosts that limit the management operations that can be performed from there.

26 Solutions Enabler

You can use the symacl command or Unisphere to assign rights to individual access IDs which are used to identify these management hosts.

Host access IDs

Symmetrix Access Control identifies individual management hosts using access IDs, which are stored in a Lockbox. The Lockbox is associated with a particular host, which prevents copying the Lockbox from one host to another. There are two different methods to generate the access IDs:

Alternate access IDThe host access ID can be generated at random or from a user-defined passphrase, then stored in a secure location on the local disk.

Alternate access IDs are supported for all platforms. See Alternate access IDs for more information about alternate access IDs.

NOTE: Dell Technologies recommends that you use alternate access IDs on platforms where the hardware-based

access ID is derived from a network interface MAC address.

Hardware-based access ID (default)The host access ID is derived from hardware characteristics of that host: On x86_64 (64-bit Intel or AMD), and IA-64 platforms, a network interface MAC address is used. On other platforms, characteristics of the host, such as a processor identifier, are used.

NOTE: When MAC addresses generate access IDs, the IDs may be unreliable or ineffective under some circumstances,

including clustering environments, virtual environments, or following a hardware change. For added security on x86_64

(64-bit), IA-64, and BS2000 hardware platforms, Dell Technologies recommends that you use alternate access IDs instead

of hardware-based access IDs.

Alternate access IDs

Alternate access IDs are available for all platforms. When alternate access IDs are enabled, Solutions Enabler can:

Randomly generate an access ID. Generate an access ID based on a user-chosen passphrase, where the passphrase is either:

Entered on the command line in an option Entered in a file, whose name is specified in the command line

Enable alternate access IDs with the SYMAPI_ALTERNATE_ACCESS_ID option in the /config/options file.

Solutions Enabler securely stores the alternate access ID on the local disk in the Lockbox file. The symacl man page provides more information about the symacl unique command.

NOTE: Solutions Enabler access control changes must be made from an administrative host with ADMIN rights to the array

and rights to make symacl changes.

If you have only one such administrative host, and you change its alternate access ID, after that change is made, the host

can no longer make access control changes. This is because the new access ID is not yet in an access group.

Dell Technologies recommends that you enable a second administrative host before attempting to change a host alternate

access ID.

Client/server access IDs

By default, client/server mode operations are run on the server host using the access ID of the server. Access control checks are performed against the rules that are established for the server host, regardless of which client host initiated the operations.

You can use the access ID of the client host instead of the server host to perform the check. When this is enabled, access control rules must be established for, and checked against, the client hosts from which the operations are issued.

To use the access ID of the client host, you must edit the /config/options file on the client and the server host. On the server, the SYMAPI_USE_ACCESS_ID option controls the source of the access ID used for the client/ server sessions. On the client, the SYMAPI_ALTERNATE_ACCESS_ID option must be enabled to use alternate access IDs. Use the SYMAPI_CLIENT_SIDE_ACCESS_ID to control whether the client can send its own access ID to the server. By default the SYMAPI_CLIENT_SIDE_ACCESS_ID option is disabled (the client does not send its access ID to the server in client/server mode).

Solutions Enabler 27

For more information about setting server or client host access ID, see the Dell Solutions Enabler Array Controls and Management CLI User Guide.

User-based access control

User authorization assigns individual users to roles to limit the management operations that users can perform. User-based controls can be granted to the entire array or individual storage groups.

You can use the symauth command or Unisphere to assign users to roles.

When using the CLI, Solutions Enabler creates a user identity using the credentials that the user logged in to the local system with, as provided by the operating system. In Unisphere, the user's authenticated identity is passed to Solutions Enabler.

For information about the symauth command, see the Dell Solutions Enabler Array Controls and Management CLI User Guide.

For information about managing Unisphere user accounts, see the Dell Unisphere for PowerMax Installation Guide.

User identification

Internally, Solutions Enabler represents a user identity as a string assembled from the username and authentication source. The possible encoding structures are:

H:HostName\UserName A user authenticated by the local operating system.

D:DomainName\UserName A user authenticated by a specific domain on Windows.

L:ServerName\UserName A user authenticated by an LDAP server. (Unisphere)

C:HostName\UserName A user authenticated by the Unisphere authentication service on some host.

M:PowerMax ID\UserName A user authenticated by a management guest host running on the specified PowerMax array.

Solutions Enabler uses these identities in several ways. A username is included in records that are written to the array secure audit log. This identifies the user that initiated the activity being logged. A user identity is the basis for optional user authorization rules that restrict management access to arrays.

Support for all user groups

The symauth show username command shows the user identity and the identity of all the groups that the user belongs to.

Using this syntax, user authorization rules can be defined that map specific user or group identities to a management role. These management roles in turn map to a set of corresponding rights that they grant.

Within these authorization rules, user (or group) user or group names can be wildcards as follows:

Host and user Description

H:HostName\UserName That user who is logged in to that host.

H:HostName\* Any user who is logged in to that host.

UserName Any user with that name, regardless of how they have authenticated to the system or Unisphere.

During rights checking, a user is granted the combined rights that are called for by any authorization rules that match either their user or one of their group identities.

The symauth man page provides more information about this topic.

Multiple authorization roles

In Solutions Enabler 8.x, you can use the symauth command to assign up to four authorization roles. Each role is separated with a '+' character. For example:

StorageAdmin+Auditor+Monitor

28 Solutions Enabler

Output of the symauth list command shows authorization roles, ordered from most powerful to least powerful. For example:

StorageAdmin+Auditor+PerfMonitor

Storage Group Level Control

Symauth enables access rights to be granted to either the entire array or to individual storage groups. A wildcard storage group name can be used to grant access to multiple storage groups.

Solutions Enabler logfiles Solutions Enabler maintains three types of logfiles: Secure audit log, SYMAPI logfiles, and Daemon logfiles.

Secure audit log

The secure audit log records configuration changes, security alarms, service operations, and security-relevant actions on the array.

SYMAPI logfiles

The SYMAPI logfile records SYMAPI errors and other significant conditions. One logfile is created per day using a date format. A new logfile is started everyday on the first write after 12:00 am.

Daemon logfiles

The daemon logfiles record daemon errors and other significant conditions. Each daemon has two logfiles (.log0 and .log1). Logging alternates between the two files, switching to the other file each time that the maximum size specified by the daemon LOGFILE_SIZE parameter is reached. Each daemon writes to the .log0 file until its size exceeds that specified in the LOGFILE_SIZE option, at which point it switches to the .log1 file. It switches back to .log0 under the same conditions.

For more detail on logfiles, see the Dell Solutions Enabler Array Controls and Management CLI User Guide.

Port usage This section describes the ports Solutions Enabler uses to communicate between server and client hosts.

If a firewall or network address translator is present, these ports must be open. Typically, it is a firewall between the Solutions Enabler client and the server hosts.

Server ports

In client/server mode, the Solutions Enabler server (storsrvd daemon) listens by default at TCP/IP port 2707 for client connections.

You can configure a port by adding an entry to /config/daemon_options file. If you change the default port at the server, you must modify the /config/netcnfg configuration file at client hosts to reflect the use of the nondefault port.

To change the server port, the server must be down. To use a different port, specify it in the daemon_options file, then restart the storsrvd daemon.

Solutions Enabler 29

Event daemon ports

Using the asynchronous events in client/server mode: the event daemon at the client host listens at a TCP/IP port for events being forwarded from the event daemon at the server. By default, the client event daemon asks the operating system to pick an unused port for it to use.

You can configure a specific port to use by adding an entry to the /config /daemon_options file on the client host. The event daemon uses the following ports by default:

Table 4. Ports used by the event daemon

Port Protocol Description

Dynamically assigned

102465535

TCP In client/server mode, the event daemon (storevntd) on a client host listens on this port for asynchronous events sent to it from a server host. By default, this is picked at random by the client host event daemon.

514 TCP Port that the server listens on for events.

162 TCP Port that the application listens on for traps.

Client/server security settings In Solutions Enabler client/server mode, client host operations are automatically forwarded to the storsrvd daemon on a server host for execution.

By default, traffic that is transmitted between client and server hosts is encrypted using TLS/SSL.

This section describes the mechanisms to operate these connections in a secure manner.

Network encryption

Platforms where Solutions Enabler supports secure sessions default to securing all connections using TLS/SSL.

Solutions Enabler 8.1 and higher uses OpenSSL with the OpenSSL FIPS Object Module 2.0. OpenSSL support is as follows:

v9.2OpenSSL 1.0.2u v9.1OpenSSL 1.0.2q v8.4OpenSSL 1.0.2j v8.2OpenSSL 1.0.1q v8.1OpenSSL 1.0.1p

FIPS mode is supported on the following platforms:

Linux x86 platforms Windows x86 64-bit platforms

The version of TLS varies depending on the version of Solutions Enabler:

Solutions Enabler 8.0.2 server and a client on version 7.6.2 or later. The client and server use TLS 1.2 with Advanced Encryption Standard (AES) with 128-bit key, Galois Counter Mode (GCM), with Secure Hash Algorithm 1 (SHA-1).

In Solutions Enabler 8.0.2, SSL 2.0 and SSL 3.0 are disabled by both the client and server. Sessions are secured using TLS 1.0 or TLS 1.2.

Solutions Enabler 8.4TLS 1.0 and TLS 1.1 are disabled by both client and server. Sessions are secured using TLS 1.2 only.

Solutions Enabler 8.4 also disables all SHA-1 ciphers. Only AES-128 GCM encryption with SHA-256 ciphers is used.

NOTE: FIPS 140-2 mode is enabled by default.

30 Solutions Enabler

Securing remote connections using TLS/SSL

For platforms that support secure SYMAPI client and server communications, the initial default configuration is to negotiate only SECURE sessions. You can modify the security level at which the client and server are operating.

Before modifying the security level, you should:

Understand that the security level specifies the capability of the local side and the local sides expectation of the remote side.

Know whether the host is SSL-capable or SSL-incapable.

The possible security levels are:

Level 3 (SECURE)(Default) Indicates that only secure sessions will be negotiated between the client and server. This is the highest level of security, and it should only be used when there is no chance of an SSL-incapable client attempting to connect with the server, or an SSL-capable client connecting to an SSL-incapable server.

Level 2 (ANY)Indicates that either secure or non-secure sessions will be negotiated between the client and server on SSL-capable platforms.

Level 1 (NONSECURE)Indicates that only non-secure sessions will be negotiated between the client and server. This level is intended as a last resort in situations where SSL cannot be used for some reason or is undesirable. In addition, this level can also be useful in matters of performance and availability.

The default security level is SECURE on platforms that support secure communications and NONSECURE on platforms that do not support secure communications. The following messages may be issued by the server if SSL-related problems occur:

ANR0141E through ANR0145E ANR0147E ANR0148E ANR0150E through ANR0153E ANR0155E

The Dell Solutions Enabler Installation and Configuration Guide provides details about SYMAPI server daemon messages.

Session negotiation behavior

The following table details the type of session negotiated if a client and server are at the same or different security levels (implied or configured).

Table 5. Session negotiation behavior

Client security level Server security level Negotiated session type

SECURE SECURE SECURE

ANY SECURE

NONSECURE Rejected

NONSECURE NONSECURE NONSECURE

ANY NONSECURE

SECURE Rejected

ANY ANY SECURE

SECURE SECURE

NONSECURE NONSECURE

Server host security

NOTE: Dell Technologies strongly recommends that you synchronize host times for the server and client hosts before

generating and using OpenSSL certificates. Failure to synchronize host times could result in difficulty in establishing secure

connections.

You can configure server host security levels in two ways:

Solutions Enabler 31

Use the SYMAPI_SECURITY_LEVEL option in the /config/options file. This option specifies whether the server accepts only secure sessions from clients.

The default value for the SYMAPI_SECURITY_LEVEL option is SECURE. The server accepts only secure sessions from clients.

Use the SECURITY_LEVEL parameter in the /config/daemon_options file. The default for the SECURITY_LEVEL parameter is SECURE.

If both the SYMAPI_SECURITY_LEVEL option in the options file and SECURITY_LEVEL parameter in the daemon_options file are set, and are set to different levels, then the setting on the SYMAPI_SECURITY_LEVEL option in the options file overrides the setting on the SECURITY_LEVEL parameter in the daemon_options file.

NOTE: Dell Technologies strongly recommends that you use secure sessions. Non-secure sessions are not

recommended, however, you can allow non-secure sessions from clients by modifying the SYMAPI_SECURITY_LEVEL or

SECURITY_LEVEL options.

FIPS 140-2 encryption

To set whether to operate in FIPS 140-2 mode for client/server communication, use the SYMAPI_FIPS option in the /config/options file. When the SYMAPI_SECURITY_LEVEL option is set to SECURE, the SYMAPI_FIPS option enables or disables FIPS 140-2 compliant encryption of Solutions Enabler client/server sessions on Linux and Windows platforms. The default value for the SYMAPI_FIPS option is ENABLE.

For a full description of the SYMAPI_SECURITY_LEVEL and SYMAPI_FIPS options, see the Dell Solutions Enabler CLI Reference Guide.

Backward compatibility to pre-8.0 configuration files

Solutions Enabler 8.0 provides backward compatibility to 7.5 and earlier versions using the following logic to select the security level:

Look for SYMAPI_SECURITY_LEVEL in the /config/options file.

If SYMAPI_SECURITY_LEVEL is specified in the /config/options file, use it.

If the SYMAPI_SECURITY_LEVEL security level is not specified in the /config/options file, the server looks for storsrvd:security_level in the /config/daemon_options file.

If the storsrvd:security_level is not specified on the server, look for SYMAPI_SERVER_SECURITY_LEVEL. If the SYMAPI_SERVER_SECURITY_LEVEL is not specified, use the default for the platform: SECURE everywhere

except OVMS, BS2000, or IBM i, which use NONSECURE. If the SYMAPI_SERVER_SECURITY_LEVEL is specified, use the specified value and post a message saying it was

used instead of the storsrvd:security_level. If the storsrvd:security_level is specified, use it.

Verifying client security certificates

By default, if a client has a subject certificate, a server requires the certificate and verifies it. This behavior is controlled by the SECURITY_CLT_SECURE_LVL parameter in the /config/daemon_options file.

The default value for the SECURITY_CLT_SECURE_LVL parameter is VERIFY.

For a full description of the SECURITY_CLT_SECURE_LVL parameter, see the Dell Solutions Enabler CLI Reference Guide.

Client host security

By default, a Solutions Enabler client attempts to negotiate a secure session with the server when both the server and client are capable of secure sessions. It is not recommended that you disable secure communications, however, if you need to allow non-secure sessions between a client and server that cannot negotiate a secure session, you can modify the SYMAPI_SECURITY_LEVEL option in the /config/options file to allow non-secure sessions.

32 Solutions Enabler

netcnfg file

To configure session security for specific server hosts, modify the /config/netcnfg file for the server in question. This file maps service names to server hostnames (or IP addresses) and port numbers for Solutions Enabler SYMCLI commands. If you do not specify a security level, SECURE is used for secure-capable platforms, and NONSECURE is used for secure-incapable platforms, depending on the configuration of the server.

If both the SYMAPI_SECURITY_LEVEL option in the options file and the security level in the netcnfg file are set, and are set to different levels, then the security level in the netcnfg file takes precedence over the setting in the options file.

For more information on the security settings in the options and netcnfg files, see the Dell Solutions Enabler CLI Reference Guide.

Secure session configuration summary

The following table lists the host operating systems that support SSL.

Table 6. Host operating systems that support SSL

Operating systems that support SSL

AIX (64-bit)

HP-UX (64-bit)

HP-UX Itanium (64-bit)

Linux Itanium (64-bit)

Linux AMD (64-bit)

Solaris (64-bit)

Windows AMD (64-bit)

z/OS

NOTE: Solutions Enabler does not support SSL on iSeries, BS2000, or OpenVMS.

The following table provides a summary of the secure session settings. See the Dell Solutions Enabler CLI Reference Guide for more information.

Table 7. Secure sessions summary

Option name, possible values, and location Description

storsrvd:security_clt_secure_lvl =MUSTVERIFY | VERIFY | NOVERIFY

/config/daemon_options

On server hosts, controls how the server validates client certificates.

NOTE: This option is not supported on z/OS hosts, where it defaults to NOVERIFY.

MUSTVERIFY: The server requires clients to send a valid certificate.

VERIFY (default): The server verifies a clients certificate, if one is sent.

NOVERIFY: The server does not verify client certificates.

storsrvd:security_level =SECURE | NONSECURE | ANY

/config/daemon_options On server hosts, controls whether servers establish a secure session.

SECURE (default): Secure sessions are always used. All other connection types are refused.

NONSECURE: Non-secure sessions are used; secure sessions are not used.

Solutions Enabler 33

Table 7. Secure sessions summary (continued)

Option name, possible values, and location Description

ANY: A secure session is established when supported by the client; otherwise a non-secure session is used.

SYMAPI_SECURITY_LEVEL = SECURE | ANY | NONSECURE

/config/options Specifies whether the Solutions Enabler server accepts only secure sessions from clients. Applies to both server and client.

SECURE (default): Secure sessions are always used. All other connection types are refused.

NONSECURE: Non-secure sessions are used; secure sessions are not used.

ANY: A secure session is established when supported by the client; otherwise a non-secure session is used.

Certificate files Solutions Enabler uses OpenSSL to generate certificates for secure client/server communication. The client and server verify each other's identity based on the information that is contained in the certificates.

During installation, you have the option to install the certificate component. If you choose to install the certificate component, a default set of certificates is generated. These certificates are signed by a self-signed root certificate.

NOTE: Dell STRONGLY recommends that customers install their own certificates using their own internal certificate

authority.

Solutions Enabler uses a root certificate and key to generate subject certificates that identify client and server hosts. The root certificate is installed on the host. The installation process automatically generates a subject certificate for the host on which the install is run.

The generated certificates can be replaced with certificates that you generate or that are issued to you by a commercial certification authority.

Subject certificates are generated for both client and server hosts. The subject certificates represent the identity of the host, whether the host acts as a client or a server. A single set of certificates can be used in both the client and server.

The client and server can be configured separately to use other sets of certificates. By default, both the client and the server validate the certificate of the peer during secure session negotiation. The client always validates the server certificate; you cannot disable this validation when a secure session is negotiated.

The cert directory is at:

Windows: \config\cert UNIX and z/OS: /config/cert

NOTE: By default, the location of the cert directory is the same for z/OS as UNIX. The location for z/OS systems can

be changed during installation.

The following certificate files enable a client to verify a server identity and a server to verify a client's identity:

NOTE: If customers are installing their own certificates, these certificate files are not required.

symapisrv_cert_v9.*.pem is the default version 9.* subject certificate file, where v9.* is the Solutions Enabler version. It is created specifically for its particular host during installation. It is signed by the Dell Enterprise Storage Automation root certificate symapisrv_trust_v9.*.pem. This file must be in the cert directory on the SYMAPI client and server for client/server security to work.

symapisrv_trust_v9.*.pem is the Dell Enterprise Storage Automation Root certificate, where v9.* is the Solutions Enabler version. This file must be in the cert directory on every client and server.

symapisrv_key_v9.*.pem is the key file that is associated with the subject certificate, where v9.* is the Solutions Enabler version. It is created specifically for its host during installation. It is generated during the certificate creation process. This file must be in the cert directory on the SYMAPI client and server for client/server security to work.

symapisrv_cert_v8.*.pem is the default version 8.* subject certificate file, where v8.* is the Solutions Enabler version. It is created specifically for its host during installation. It is signed by the Dell Enterprise Storage Automation root certificate symapisrv_trust_v8.*.pem. This file must be in the cert directory on the SYMAPI client and server for client/server security to work.

34 Solutions Enabler

symapisrv_trust_v8.*.pem is the Dell Enterprise Storage Automation Root certificate, where v8.* is the Solutions Enabler version. This file must be in the cert directory on every client and server.

symapisrv_key_v8.*.pem is the key file associated with the subject certificate, where v8.* is the Solutions Enabler version. It is created specifically for its host during installation. It is generated during the certificate creation process. This file must be in the cert directory on the SYMAPI client and server for client/server security to work.

Solutions Enabler 8.0.x through 8.3.x support backward compatibility with pre-version 8.0. For backward compatibility with pre-8.0 versions, the following certificate files are also created in the cert directory:

symapisrv_cert.pem is the Solutions Enabler pre-version 8.x subject certificate file. It is created specifically for its particular host during installation. It is signed by the Dell SPEA pre-version 8.x root certificate. This file must be in the cert directory on the SYMAPI client and server for pre-version 8.x client/server security to work.

symapisrv_trust.pem is the Dell SPEA pre-version 8.x root certificate that is used to sign the SYMAPI certificate file. This file must be in the cert directory on every client and server for pre-version 8.x client/server security to work.

symapisrv_key.pem is the pre-version 8.x key file that is associated with the subject certificate. It is created specifically for its particular host during installation. It is generated during the certificate creation process. This file must be in the cert directory on the SYMAPI client and server for pre-version 8.x client/server security to work.

NOTE: Solutions Enabler 8.4 and higher does not support certificates that are generated before Solutions Enabler 8.0.

Managing backward compatibility of certificates

NOTE: This section applies to Solutions Enabler 8.0.x through 8.3.x. Solutions Enabler 8.4 and higher does not support

certificates generated before Solutions Enabler 8.0.

Solutions Enabler versions 8.0.x through 8.3.x. are backward compatible with certificates generated by earlier versions, back to 7.4. For example:

A Solutions Enabler 8.x server can verify a certificate generated by an older version. A Solutions Enabler 7.6 client can verify a server certificate generated with -san and -mode V76 options.

An older client (Solutions Enabler 7.5 or earlier), can verify a certificate generated by a Solutions Enabler 8.x server if the certificate CN contains either: A Fully Qualified Domain Name (FQDN)If the server host name can be resolved to a FQDN An IP address corresponding to the serverIf the server host name cannot be resolved to a FQDN

In cluster configurations, if the Solutions Enabler 8.x server certificate does not contain wildcards in the CN, the Solutions Enabler 7.5 client will not verify the server if the server fails over and presents a different host ID than that present in the CN.

If a Solutions Enabler 8.x server is running in a clustered environment, Solutions Enabler 7.5 and older clients must have certificates for each host node of the server cluster.

CAUTION: When generating certificates on Solutions Enabler 8.x servers, be careful not to add non-DNS host

names in the CN if Solutions Enabler 7.5 and older clients will connect to the server.

Configuring secure client/server support with custom certificates

NOTE: This section applies to customers that have server certificates available for all hosts running Solutions Enabler in

client/server mode. The steps noted here apply to Solutions Enabler 7.6 and later.

To maximize the security of client/server communications, Solutions Enabler needs to be configured to use certificate files signed by either a customer-managed root certificate authority, or by a commercial certification authority. While the default certificates generated by Solutions Enabler are intended to provide ease of use and moderate security, we recommend that all hosts use certificates provided by an internally managed certificate authority using the appropriate X.509 version 3 Basic Constraints and X. 509 version 3 Key Usage extensions, or by a commercial authority.

The following table provides a summary of the custom certificate configuration settings in Solutions Enabler.

Solutions Enabler 35

Table 8. Custom certificate configuration settings

Option name, possible values, and location Description

SYMAPI_SECURITY_ALT_CERT_FILE= /config/options

On client hosts, indicates the location of the certificate file to be used when connecting to a server that requires peer certificate validation.

SYMAPI_SECURITY_ALT_KEY_FILE= /config/options

On client hosts, indicates the location of the key file to be used when connecting to a server that requires peer certificate validation.

storsrvd:SECURITY_ALT_CERT_FILE= /config/daemon_options

On server hosts, indicates the location of the certificate file to be used to establish secure connections with client hosts.

storsrvd:SECURITY_ALT_KEY_FILE= /config/daemon_options

On server hosts, indicates the location of the key file to be used to establish secure connections with client hosts.

Peer certificate validation

When a Solutions Enabler storsrvd instance or client process receives a peer certificate, that certificate must be validated.

Solutions Enabler only accepts a peer certificate as valid if it has the public certificate key from the CA that signed the peer certificate. If client certificates within an organization are signed by multiple CAs, the server must have access to the CA public key for ALL clients that should be permitted to connect. Whenever a new CA certificate is added to the server, it must be placed in the /var/symapi/config/cert/ directory and the manage_server_cert update command must be run from that directory and the server daemon must be restarted.

In addition to validation against the Certificate Authority public key that signed a peer certificate, SE validates the peer certificate via name service lookup. For a host to validate a peer certificate this way, the common name (or one of the alternative names) on the certificate must resolve to the IP address of the peer. If no name service can be provided, the certificate is not validated, resulting in a terminated connection.

NOTE: A client or server instance still trusts certificates signed by any certificate authority public key located in the cert directory. To ensure that only the customer-provided certificates are trusted, we recommend that you remove the default

certificate authority files from the cert directory, and run the manage_server_cert update command to update

validation links.

Migrating from SE embedded certificates to custom certificates

If you are migrating from the embedded certificates provided by Solutions Enabler to custom certificates, be aware that removing the *.pem files from the server will cause connections to fail until all hosts are updated with the new CA files and client or server certificates. This will cause a temporary interruption in service, but this may be avoided by adding the CA files to all clients and the server before making other changes. The CA files must be updated with the manage_server_cert_update command before SE considers them a trusted authority. After all custom certificates are configured, the original symapisrv*.pem files can be deleted, and the server daemon safely restarted.

Configuring secure server support

Ensure you have the following required files for the server:

Custom certificate public key for the server host in .pem format Custom certificate private key for the server host in .pem format Certificate authority public key for all client-side host certificates

NOTE: The private CA key is NOT required by Solutions Enabler.

When the required files are available, Solutions Enabler must be configured to use a custom certificate on the server host and all client hosts. Ensure you have read the information about peer and custom certificates.

NOTE: This example is for Linux and UNIX.

1. Open a terminal and change the directory to /var/symapi/config/cert/.

36 Solutions Enabler

2. Remove all files with the .pem extension as well as the soft links in the directory these are usually named with the hash value and a numerical extension.

3. Place the three certificate files, that is, server certificate and key, and the client CA cert, in the /var/symapi/config/ cert/ directory.

4. Run the command manage_server_cert update from this directory to recreate the certificate hash links needed by Solutions Enabler.

5. Change the directory to /var/symapi/config/.

6. Open the daemon_options configuration file in an editor and ensure the following lines are present and uncommented (do not include the <> characters):

storsrvd:SECURITY_ALT_CERT_FILE = storsrvd:SECURITY_ALT_KEY_FILE =

NOTE: Use only the full filename, not the full path for the server certificate and key.

7. Start (or restart) the server daemon.

Configuring secure client support

Ensure you have the following required files for the server:

Custom certificate public key for the client host in .pem format Custom certificate private key for the client host in .pem format Certificate authority public key for all server-side host certificates

NOTE: The private CA key is NOT required by Solutions Enabler.

When the required files are available, Solutions Enabler must be configured to use a custom certificate on the server host and all client hosts. Ensure you have read the information about peer and custom certificates.

NOTE: This example is for Linux/UNIX

1. Open a terminal and change the directory to /var/symapi/config/cert/.

2. Remove all files with the .pem extension as well as the soft links in the directory these are usually named with the hash value and a numerical extension.

3. Place the three certificate files, that is, client certificate and key, and the server CA cert, in the /var/symapi/config/ cert/ directory.

4. Run the command manage_server_cert update from this directory to recreate the certificate hash links needed by Solutions Enabler.

5. Change the directory to /var/symapi/config/.

6. Open the options configuration file in an editor and ensure the following lines are present and uncommented (do not include the <> characters):

SECURITY_ALT_CERT_FILE = SECURITY_ALT_KEY_FILE =

NOTE: Use only the full filename, not the full path for the client certificate and key.

Server security considerations

Starting up the server

The storsrvd daemon does not run by default. You must explicitly start it before it can accept connections from remote clients. You can configure the daemon to start automatically whenever a server host starts.

The Dell Solutions Enabler Installation and Configuration Guide provides detailed instructions on starting the Solutions Enabler server.

Solutions Enabler 37

Restricting access to the server

The /config/nethost file on a server host restricts the hosts and users from which the storsrvd daemon accepts connections. If the nethost file is not present, connections are accepted from all client hosts.

NOTE: The server considers the contents of the nethost file before deciding whether it will negotiate a SYMAPI session

with the client. If the client host and user are not defined in the nethost file, a session will not be negotiated, regardless of

the security level.

The Dell Solutions Enabler Installation and Configuration Guide describes the nethost file.

Restricting server functionality

You can use settings in the /config/options file on a server host to restrict the functionality that the storsrvd daemon is allowed to perform on behalf of remote client hosts. Check to make sure all references to the options file have a path name of /config/options. You can edit the functionality options in the options file while the server is running. The running server uses the new settings for all future sessions.

Since the settings are not specified in the /daemon_options file, they cannot be changed using the stordaemon setvar command.

The following table lists the options in the options file that restrict storsrvd daemon functionality:

Table 9. Options that restrict storsrvd functionality

Option name (in /config/options) Description

SYMAPI_ACC_ADMIN_VIA_SERVER Enable or disable Symmetrix Access Control changes.

Default is ENABLE.

SYMAPI_ACC_DISPLAY_VIA_SERVER Enable or disable Symmetrix Access Control information displays.

Default is ENABLE.a

SYMAPI_ALLOW_SCRIPTS_VIA_SERVER Enable or disable TimeFinder pre-action and post-action scripts.

Default is DISABLE.

SYMAPI_CTRL_VIA_SERVER Enable or disable array control operations in general. Default is DISABLE.

a. When set to DISABLE, this class of functionality is not available through the server.

Specifying nodes and addresses A server can accept connections from Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) clients. The exact syntax is important if you specify the network address instead of the node name in the nethost file. If you incorrectly specify an address, connections from some clients may be denied.

Dell Technologies recommends that you specify the node name (or the FQDN), because proper DNS configuration usually ensures that the name of the client host is consistent, regardless of the network address.

If you must specify the address, keep these factors in mind:

The rules for specifying an IPv4 address are simple: Specify the complete address in its dotted-decimal form, without leading zeros in each octet. For example:

172.23.191.20 user1 10.243.142.82 user1

If you want to specify an IPv6 address, follow these shorthand rules (part of the IPv6 standard): Leading zeros in each quartet can be omitted.

38 Solutions Enabler

Contiguous sets of zeros can be replaced by two adjacent colons, but only once in an address. If there are multiple non-adjacent sets of contiguous sets of zeros, only one set of double colons can be used. The other set of zeros must be specified. For example:

3FFE:80C0:0:215::7 If you are uncertain about the address syntax, ask your network administrator to determine the exact syntax. For most UNIX and Linux hosts, the ifconfig a command can be used to display the IPv6 address of a machine. In a Microsoft Windows environment, use the ipconfig /all command to display the IPv6 address.

If you have IPv4 client hosts that connect to IPv6-capable servers on AIX or Linux, the client network address appears as IPv4-mapped addresses. The server host file validation logic takes this into account and treats IPv4-mapped addresses as though they are native IPv4 addresses. You can specify the regular IPv4 address as described in the first point above.

You may have to try a number of options to find the right address.

Concurrent connections The maximum number of concurrent connections from client hosts is controlled by the storsrvd:max_sessions parameter in the /config/daemon_options file. When a new session arrives that exceeds the threshold, it is refused.

The default and maximum value is 100.

Concurrent sessions may be limited based on the source hostname or username of the client:

Limiting by source hostBased on the IP address of the host where the client session originates. User name is not considered when counting concurrent connections from hosts.

Limiting by source userBased on the user identity format. Only two types of user identity formats are counted: The H: format identifies that the client user has been authenticated by the local operating system. This format is used

when the client comes from any UNIX or Linux type of host, or from a Windows host where the user has logged into the local system (not a Windows domain). In the host authentication case, the user is considered the same only when logging in from the same host with the same user name.

The D: format is used when the client user has logged into a Windows domain. In this case, a user can log in to the same domain from different host computers. Such a user identity is considered the same, regardless of the source host that initiates the session.

These two configuration statements are used for storsrvd control session refusal from specific sources:

storsrvd:max_sessions_per_host=value This option specifies the maximum number of concurrent sessions from any specific host. If a new session from the source host exceeds the threshold for that host, the session is refused.

storsrvd:max_sessions_per_user=value This option specifies the maximum number of concurrent sessions from any specific user. If a new session from the same user exceeds the threshold for that user, the session is refused.

storsrvd daemon session control options and values lists the storsrvd session control options and values.

NOTE: These options and values are only used by the storsrvd daemon and apply to SYMAPI remote sessions. There is

no impact on the use of the stordaemon control CLI or any other Solutions Enabler daemon.

Use the following best practices for setting the storsrvd session control options:

Set max_sessions_per_host and max_sessions_per_user to a value less than max_sessions. Specifically:

Set max_sessions to the highest number of concurrent sessions you can tolerate regardless of the source host or user of the session.

Set max_sessions_per_host and max_sessions_per_user to lower values, reflecting the maximum number of concurrent sessions from specific sources you will tolerate.

Both max_sessions_per_host and max_sessions_per_user can be used concurrently to count sessions.

You can set either max_sessions_per_host and max_sessions_per_user to 0, but doing so refuses all new connections. Dell Technologies recommends that if you want to refuse all sessions temporarily, set max_sessions to 0. To resume accepting new sessions, change max_sessions to a non-zero value.

Table 10. storsrvd daemon session control options and values

Option name Values Default Notes

max_sessions 0All new sessions are refused.

100 Default of 100 is compatible with previous releases.

Solutions Enabler 39

Table 10. storsrvd daemon session control options and values (continued)

Option name Values Default Notes

1100Maximum (host and user) sessions allowed.

max_sessions_per_host 0All new sessions are refused.

1100Maximum number of sessions allowed from a specific host.

NOLIMITDisables counting of sessions from a specific host.

NOLIMIT NOLIMIT value provides backward compatibility.

NOLIMIT is case-insensitive:

NOLIMIT = nolimit

max_sessions_per_user 0All new sessions are refused.

1100Maximum number of sessions allowed from a specific user.

NOLIMITDisables counting of sessions from a specific user.

NOLIMIT

Control operations for IBM z/OS By default, a Solutions Enabler server running on any z/OS host allows configuration changes when requested by a remote client. The Dell Solutions Enabler Installation and Configuration Guide provides additional information.

NOTE: If control operations are left enabled by default, remote Open Systems users (client/server mode) can make

changes to the array configuration on your mainframe system.

File backup Solutions Enabler maintains important configuration data in a number of files. It is important that you back up and protect these files at all times. If lost, functionality that depends on the data in these files may be affected.

Back up the following directories and their contents to preserve the Solutions Enabler configuration on a host:

/config /db /gns To retain the logs for audit purposes, include the /log directory in your backups.

Other directories under contain less critical data that is recreated by Solutions Enabler as needed.

The following table lists specific files you should regularly back up.

Table 11. Files to back up

File location Description

/config/emcpwddb.dat This file stores connectivity information (including user names and passwords) used to interact with storage arrays, and VMware and Hyper-V Virtual Infrastructure Services.

It is managed using the symcfg authorization SYMCLI command.

40 Solutions Enabler

Table 11. Files to back up (continued)

File location Description

The file is encrypted to protect its contents and prevent tampering.

/db/symapi_db.bin The Solutions Enabler database file contains array topology information; arrays, devices, directors, and other information.

/config/lockbox<*> This file contains sensitive configuration information. The file is encrypted to protect its contents to prevent tampering.

NOTE: There are multiple Lockbox files; represented by the *.

/gns/storgnsd.db The Solutions Enabler groups database file contains information about CGs, DGs and their contents.

Audit log

Storage system audit records come from the SYMAPI database and include all actions that are taken on that storage system.

The audit log resides on the storage system and has a maximum size of 40 MB. When the 40 MB limit is reached, the log begins to overwrite itself. In Unisphere release 9.2, operations that are run through Unisphere UI have been added to the audit log.

The audit log message catalog is a catalog of the audit messages that Solutions Enabler writes to storage systems. A new, standardized audit format has been adopted for storage systems running PowerMaxOS 10. You can specify the new format (instead of the legacy format) on storage systems running HYPERMAX OS 5977 or PowerMaxOS 5978.

The audit log: Has advanced search and filter capabilities, such as:

Specific time period (for example, last 24 hours, last week, specific date) Specific user (username, user role) Operation type and category Application type (Unisphere, CLI) Hostname Search phrase

Can query audit log records using the REST API. Records and the filtered audit log list can be exported to a .log file. This is facilitated with a REST endpoint.

File protection

Solutions Enabler stores its configuration files in the following directory:

/config Protect the files in the config directory by ensuring only authorized administrators have write access. All other users should have no access or read-only access.

Non-privileged user command use

After an initial installation of Solutions Enabler, most SYMCLI commands can only be run as a root user on UNIX systems and by an administrator on Windows systems. To allow other users to execute these commands (for example, symcfg discover), you must grant them write access to the following directories and their contents:

/config /db In addition, non-root users on UNIX and non-administrators on Windows must be authorized (using the stordaemon command) to manage daemons, and to use daemons in the process of running SYMCLI commands. To authorize these users, add an entry for a specific user in the file /config/daemon_users. For example:

Solutions Enabler 41

# Allow user 'jones' to make use of the storapid daemon: jones storapid # A * character at the end of a name can be used # as a simple wildcard. The following allows user 'jones' # to make use of any of the Solutions Enabler daemons: jones stor*

Lockbox Solutions Enabler uses a Lockbox to store and protect sensitive information. The Lockbox is associated with a particular host. This association prevents the Lockbox from being copied to a second host and used to obtain access.

The Lockbox is created at installation. During installation, the installer prompts the user to provide a password for the Lockbox, or if no password is provided at installation, a default password is generated and used with the Stable System values (SSVs, a fingerprint that uniquely identifies the host system). For more information about the default password, see Default Lockbox password.

Stable System Values (SSVs)

When Solutions Enabler is upgraded, values stored in the existing Lockbox are automatically copied to the new Lockbox.

Lockbox passwords

If you create the Lockbox using the default password during installation, change the password immediately after installation to best protect the contents in the Lockbox.

For maximum security, select a password that is hard to guess. It is very important to remember the password.

WARNING: Loss of this password can lead to situations where the data stored in the Lockbox is unrecoverable.

Dell cannot recover a lost lockbox password.

Passwords must meet the following requirements:

8 - 256 characters in length Include at least one numeric character Include at least one uppercase and one lowercase character Include at least one of these non-alphanumeric characters: ! @ # % &

Lockbox passwords may include any character that can be typed in from US standard keyboard.

The new password must not be the same as the previous password.

Default Lockbox password

When you install Solutions Enabler, you are asked whether you want to use the default password for the Lockbox. If you choose to use the default, the installation process establishes the default Lockbox password in the following format:

nodename@SELockbox1

where: nodename is the hostname of the computer on which you are installing.

Operating systems have different methods of determining the node name:

UNIX: The installation program uses the hostname command to determine the node name. Normally, the node name is set in the /etc/hosts file.

Windows: The value of the COMPUTERNAME system environment variable, converted to lower case. z/OS: The gethostname() function is used to get the node name of the machine.

If the value of nodename is stored in upper case letters, it is converted to lower case for the default password.

NOTE: Dell Technologies strongly recommends that you change the default password. If you allow the installation program

to use the default password, note it for future use. You need the password to reset the Lockbox Stable System values or

generate or replace SSL certificates for client/server operations.

42 Solutions Enabler

Password and SSV management

Lockbox administrative interactions include:

Changing the password used to protect the Lockbox. Resetting the saved SSVs in the Lockbox after attributes on the host change, making the Lockbox inaccessible to user-

initiated SYMAPI and SYMCLI calls.

Two symcfg commands allow administrative interactions with the Lockbox:

symcfg -lockbox [-password ] reset -ssv setpw [-new_password ]

NOTE: Both commands require the existing password.

Daemon security settings Solutions Enabler uses a number of helper daemon processes:

storapid storevntd storgnsd storrdfd storsrmd storsrvd storstpd storwatchd

Daemon identity on UNIX

On UNIX, daemons run as a root user by default.

Some daemons can be configured to run with an identity other than a root user. The daemons that may run as a non-root user are:

storevntd storgnsd storrdfd storsrvd storstpd storwatchd (Unix only)

NOTE: The storapid (base) daemon must run as root.

You can configure daemon user identity at the following times:

During installation, in either the interactive or silent install process. Refer to the Dell Solutions Enabler Installation and Configuration Guide for how to choose non-root daemon execution during installation.

Post-installation using the stordaemon command. For information on which daemons are affected by this option, refer to the stordaemon man page.

If you are running daemons as a non-root user:

When configured to run as a non-root user, all daemons must run as the same user. stordaemon setuser sets the UNIX setuid bit on the daemon executables to the named user.

stordaemon setuser alters permissions of directories and files under /var/symapi such that the named user can create and delete, read, write the files it needs during normal operation.

To configure all daemons to run under the bin user account:

stordaemon setuser all -user bin Authorized users are allowed to control daemons using the stordaemon command line utility. For example, to start the SRM daemon:

Solutions Enabler 43

stordaemon start storsrmd Non-root and non-administrative users must be defined in the daemon_users file to obtain authorization for using daemons and other daemon services.

For additional information, refer to:

The stordaemon man page. The /config/README.daemon_users file installed with Solutions Enabler.

Secure host directories

The Solutions Enabler daemons can run with root privileges for UNIX systems and system account file privileges for Windows systems.

These privileges are typically greater than the privileges granted to users making use of the daemon processes. This can present security vulnerabilities in situations where a user through a CLI, or some other application, provides a pathname on which a daemon can operate, such as a backup file to be written to or read from.

To prevent these security vulnerabilities for the storsrvd daemon running as a root user, you can specify a list of secure directories in which the storsrvd daemon can read, write, and execute files. Existing mechanisms protect the Solutions Enabler database and log file locations. Specify a list of secure directories for the storsrvd daemon to protect other operations, such as backups and restores.

NOTE: When daemons are running as a non-root user, the secure_directory_path option is ignored. In this case, the

privileges of the non-root user are used when attempting to write output files in specific directories.

Secure directory path

Review the following before specifying a secure_directory_path for the storsrvd daemon running as a root user:

The supplied pathname directories must exist when the daemon is started or the daemon_options file is reloaded.

Nonexistent paths are ignored.

All subdirectories below the specified directories are also treated as being secure.

A total of 32 secure directory locations can be maintained. Once the storsrvd daemon has read the security_directory_path statement, directories specified cannot be

removed without changing the value in the daemon_options file and restarting the daemon.

New directories can be added while the storsrvd daemon is running by editing the daemon_options file and reloading it using the following command:

stordaemon action storsrvd cmd reload If the secure_directory_path option is not present, no security checks are performed.

The secure_directory_path option does not apply to the following pathnames:

Pathnames provided in the options or daemon_options files.

These files are assumed to be protected by an administrator.

An exception is the path named in the storstpd:dmn_root_location option:

If storstpd is running as root, and was started by a non-root user using the stordaemon command, storstpd validates that the path in the dmn_root_location option is also specified in the secure_directory_path option.

Pathnames accessed (read or written) by the SYMCLI itself.

In client/server mode, these occur under the identity of the user and are subject to standard access control checks against the user identity.

Pathnames accessed by an API on the client host in client/server mode because these occur under the identity of the user and are not a security risk.

44 Solutions Enabler

Windows platforms

On Windows platforms, the secure directory path is a list of directories separated by a semicolon (;). Use the backslash (\) when specifying each directory name.

To apply the secure_directory_path to the storsrvd daemon:

storsrvd:secure_directory_path = c:\Temp\dir1;c:\Users\SE

UNIX platforms

On UNIX platforms, the secure directory path is a list of directories separated by a semicolon (;) or a colon (:). Use the forward slash (/) when specifying each directory name.

To apply the secure_directory_path to the storsrvd daemon:

storsrvd:secure_directory_path = /tmp/dir1;/opt/dir2;/users/se

Listing secure directories

To display a list of secure directories in effect for the storsrvd daemon: stordaemon getvar storsrvd name secure_directory_path

Daemon connection authorization

By default, daemons only accept connection requests from users running with root or administrator privileges.

For non-root users to use this feature, create a /config/daemon_users file (initially installed as README.daemon_users) with a list of allowed usernames.

Privileged users are automatically authorized, and do not need to be added to the file. Solutions Enabler daemons make connections between one another. Daemon-to-daemon connections are automatically authenticated and authorized.

For more information on authorizing daemon connections, see the Dell Solutions Enabler Installation and Configuration Guide.

SRM daemon connections Access to SRM functionality is controlled by limiting permission to the SRM daemon. This access is controlled using the common daemon authorization file, /config/daemon_users.

NOTE: You should protect this file so that only privileged administrators can modify it.

Users meeting any of the following criteria are permitted to control and use the SRM daemon:

Authorized users: UNIX users with root access, and Windows users that are a members of the Administrators group Users listed in the daemon_users file located on each host from which they require access

For any directories and files being accessed for SRM control and mapping operations, operating-system-level permission is required.

For more information on defining SRM operations available to users and setting operating system level permissions, see the Dell Solutions Enabler SRM CLI User Guide.

Solutions Enabler 45

Unisphere This chapter contains the following topics:

Topics:

Unisphere checklist Security controls map Unisphere access control User authorization Unisphere and CA server certificates Port usage Link-and-launch security Unisphere data security Security alert system Session inactivity CyberSecIQ Serviceability in Unisphere

Unisphere checklist The following checklist summarizes the security-related tasks you should perform to improve the security of your deployment.

Table 12. Unisphere security configuration checklist

Purpose of activity Task

Access control

Authenticate users with a user account stored on an LDAP- SSL (LDAPS) server.

Set up LDAP-SSL authentication.

User-based access control

Restrict the management operations users can perform. Assign users the minimum access they require.

Certificate files

Replace default certificates with customer-supplied certificates for secure communications.

Replace pre-generated SSL certificates.

4

46 Unisphere

Security controls map

Figure 10. Unisphere components

Unisphere access control Unisphere supports the following types of user authentication:

Windows (local and domain-based): Users have a Windows account on the Symmetrix Management Application Server (SMAS) server. Users log in with a Windows domain username and password.

LDAP: User accounts are stored on an LDAP server, which may be accessible over LDAPS (LDAP with TLS 1.2 support). To use this method, a user with Administrator or SecurityAdmin privileges must set up LDAP-SSL authentication in Unisphere.

NOTE: For PowerMaxOS 5978 and earlier, if the customer does not configure LDAPS trusted certificate, the currently

deprecated approach (to be removed in the next release), LDAPS connection becomes subject to man-in-the-middle

attack. In this case, Dell Technologies strongly recommends the use of VPN to protect Unisphere to LDAPS server

connection.

NOTE: Use the RootCA TLS certificate to secure LDAP communications.

Local users: Users can have local Unisphere accounts. Users log in with their Unisphere username and password. Local user accounts are stored locally on the SMAS server host and work in much the same way as the other methods to validate user credentials. To use this method, a Unisphere Initial Setup User, Administrator, or SecurityAdmin user must create a local Unisphere user account.

The Dell Unisphere for PowerMax Installation Guide and Unisphere online help include instructions on how to create users and configure LDAP authentication.

For PowerMaxOS 5978 and earlier, external applications establish trust in Unisphere using the sequence described in Link-and- launch security.

User-based access control

Unisphere uses roles and groups to restrict which management operations a user can perform on an array.

Unisphere 47

The steps to create and manage user accounts, including user authorization, are described in the Dell Unisphere for PowerMax Installation Guide and Unisphere online help.

Default user account

The Initial Setup User account is created during installation.

The Unisphere installer software creates the Initial Setup User as a temporary local user. The Initial Setup User has an Administrator role, and is used to install and set up Unisphere. When a user with Administrator or SecurityAdmin privileges is assigned to an array, the Initial Setup User can no longer access or view the array from the Unisphere console.

NOTE: You should delete the Initial Setup User local directory login account after configuring the array. The authorization

rule for this user must be preserved on the array for exclusive use by Unisphere.

Instructions for creating the Initial Setup User are described in the Dell Unisphere for PowerMax Installation Guide and Unisphere online help.

User roles

Unisphere includes the following user roles:

NoneProvides no permissions. MonitorPerforms read-only (passive) operations on an array excluding the ability to read the audit log or access control

definitions. StorageAdminPerforms all management (active or control) operations on an array in addition to all Monitor operations.

This role does not allow users to perform security operations. AdministratorPerforms all operations on an array, including security operations in addition to all StorageAdmin and Monitor

operations. SecurityAdminPerforms security operations on an array in addition to all Monitor operations. AuditorGrants the ability to view, but not modify, security settings for an array (including reading the audit log, symacl list,

and symauth) in addition to all Monitor operations. This is the minimum role that is required to view the audit log. Perf MonitorPerforms the same operations as a monitor, with the addition of being able to set performance alerts and

thresholds. Initial Setup UserDefined during installation, this temporary role provides administrator-like permissions for adding local

users and roles to Unisphere. Local replicationPerforms local replication operations (SnapVX or legacy Snapshot, Clone, BCV). To create Secure

SnapVX snapshots, a user must have Storage Admin rights at the array level. This role also automatically includes Monitor rights.

Remote replicationPerforms remote replication (SRDF) operations involving devices and pairs. Users can create, operate on, or delete SRDF device pairs but cannot create, modify, or delete SRDF groups. This role also automatically includes Monitor rights.

Device managementGrants user rights to perform control and configuration operations on devices. Note that Storage Admin rights are required to create, expand, or delete devices. This role also automatically includes Monitor rights.

For additional information about user roles and permissions and the Initial Setup User, see the Unisphere online help.

Audit log

Storage system audit records come from the SYMAPI database and include all actions that are taken on that storage system.

The audit log resides on the storage system and has a maximum size of 40 MB. When the 40 MB limit is reached, the log begins to overwrite itself. In Unisphere release 9.2, operations that are run through Unisphere UI have been added to the audit log.

The audit log message catalog is a catalog of the audit messages that Solutions Enabler writes to storage systems. A new, standardized audit format has been adopted for storage systems running PowerMaxOS 10. You can specify the new format (instead of the legacy format) on storage systems running HYPERMAX OS 5977 or PowerMaxOS 5978.

The audit log: Has advanced search and filter capabilities, such as:

Specific time period (for example, last 24 hours, last week, specific date) Specific user (username, user role) Operation type and category

48 Unisphere

Application type (Unisphere, CLI) Hostname Search phrase

Can query audit log records using the REST API. Records and the filtered audit log list can be exported to a .log file. This is facilitated with a REST endpoint.

symauth rules

You can use the symauth command or Unisphere to create the symauth rules. The requirements vary depending on which method you use to create the symauth rule:

If you use only Unisphere to create the symauth rule: After installation use Unisphere to create at least one Administrator user. You can use any username and password-credentialed authority to create the Administrator user. This Administrator user ensures that you can use Unisphere to create the symauth rules when arrays are added or

removed. If you use the temporary Initial Setup User to create a symauth rule:

After installation create at least one Administrator user on each array. When an array is added, use the Solutions Enabler CLI to create authorization rules for at least one Administrator user on

the new array.

Special characters in x.509 client certificates

Solutions Enabler does not support the following characters in the common name (CN) or user principal name (UPN) extracted from a client's X.509 certificate:

@ : ? ; | < > [ ] + = , * / \

These characters are stripped from the client's X.509 certificate. For example:

The userPrincipalName attribute:

John.q.public@anysite.com

Is changed to the Unisphere username:

John.q.publicanysite.com

The symauth rule must use the stripped username.

Individual and group roles

Users access an array or component directly through a role assignment or indirectly through membership in a user group that has a role assignment.

User groups enable administrators to assign roles to multiple users simultaneously. User groups are created on the SMAS server according to its operating system and assigned roles with Unisphere.

If a user has two different role assignments (one as an individual and one as a member of a group), the permissions assigned to the user are combined.

For example, if a user is assigned a Monitor role and a StorageAdmin role through a group, the user is granted Monitor and StorageAdmin rights.

User IDs

The following section describes the SYMAPI format to create users and roles.

NOTE: This format is shown in the footer bar of the Unisphere GUI, but not in the User/Role list view or the creation

wizard.

Users and user groups are mapped to their respective roles by IDs. These IDs consist of a three-part string in the form:

Type:Domain\Name

Unisphere 49

If a user is matched by more than one mapping, the user authorization mechanism uses more specific mapping, as follows:

If an exact match is found, for example, D:sales\putman, that is used.

If a partial match is found, for example, D:*\putman, that is used.

If an unqualified match is found, for example, putman, that is used.

Otherwise, the user is assigned a role of None.

Valid values for Type, Domain, and Name are as follows:

Type Type of security authority used to authenticate the user or group. Possible types are:

L A user or group authenticated by LDAP. In this case, Domain specifies the fully qualified name of the domain controller on the LDAP server.

For example: L:danube.com\FinanceL:danube.com\Finance indicates that user group Finance will log in through domain controller danube.com.

When configured, individual LDAP users and groups can log in to Unisphere using a simple username, or simple group name, respectively. For example, Finance.

C A user or group authenticated by the SMAS server.

For example: C:Boston\Legal indicates that user group Legal will log in through Unisphere server Boston.

H A user or group authenticated by logging into a local account on a Windows host. In this case, Domain specifies the hostname.

For example: H:jupiter\mason indicates that user mason will log in on host jupiter.

D A user or group authenticated by a Windows domain. In this case, Domain specifies either the simple domain name (for individual users) or the FQDN (for groups).

For example: D:sales\putman indicates that the user putman will log in through the Windows domain sales.

When configured, individual Windows domain users can log in to Unisphere using a simple username. For example, putman.

Group Windows domain users can log in to Unisphere using either a simple domain name\group name or an FQDN or group name.

V A user or group authenticated by a virtualization domain. In this case, Domain specifies the virtualization domain name.

Domain Within role definitions, IDs can be either fully qualified (as above), partially qualified, or unqualified.

When the Domain portion of the ID string is an asterisk (*), the asterisk is treated as a wildcard, meaning any host or domain.

NOTE: When configuring group access, the Domain portion of the ID must be fully qualified.

For example:

D:ENG\jones Fully qualified path with a domain and username (for individual domain users).

D:ENG.xyz.com \ExampleGroup

Fully qualified domain name and group name (for domain groups).

D:*\jones Partially qualified that matches username jones with any domain.

H:HOST\jones Fully qualified path with a hostname and username.

H:*\jones Partially qualified that matches username jones within any host.

jones Unqualified username that matches any jones in any domain on any host.

Name Specifies the username relative to that authority. It cannot be longer than 32 characters and spaces are allowed if delimited with quotes.

User names can be for individual users or user groups.

50 Unisphere

User authorization User authorization restricts the management operations users can perform on an array.

By default, authorization is enforced within Unisphere against the respective authorization rules database of a given array. This enforcement is done regardless of the authorization control setting (Enabled or Disabled) for that array. SYMCLI uses this authorization control state to determine enforcement of rules. Unisphere always behaves as if symauth is enabled (an exception is the Initial Setup User).

A user with Administrator or SecurityAdmin privileges can map individual users or groups of users to specific user roles. Roles determine what operations users can perform.

Authorization for the Initial Setup User

The authorizations on an array determine the privileges the Initial Setup User has on the array. The relationship between the Initial Setup User and authorizations is defined by:

If authorization is enabled, authorization rules are always enforced. The Initial Setup User could be locked out if no authorization 'smc' rule exists for the user.

If authorization is disabled and there are no authorization rules on the array, the Initial Setup User is granted Admin privileges.

If authorization is disabled and there are no Admin or SecurityAdmin authorization rules on the array, the Initial Setup User is granted Admin privileges. All other rules are enforced as defined.

When authorization is disabled and Admin or SecurityAdmin authorization rules are defined on the array, if the Initial Setup User does NOT have an authorization rule explicitly defined, the Initial Setup User will have NO permissions. All other rules are enforced as defined.

Regardless of whether authorization is enabled or disabled on the array, the ISU 'smc' rule (with a minimum role of StorageAdmin) must exist on the array for Unisphere to manage the array. The Unisphere local directory ISU account should still be deleted in accordance with the security guideline.

Unisphere REST API

Before you can use the Unisphere REST API, you must assign user authorization for each storage array that a user is permitted to access. Users can be assigned the following roles:

Monitor StorageAdmin Administrator SecurityAdmin

The StorageAdmin and Admin roles can initiate GET, POST, PUT, and DELETE methods. Monitor and SecurityAdmin roles can only initiate GET methods.

For information on how to assign user roles, see the Dell Unisphere for PowerMax Installation Guide and Unisphere online help.

Multiple authorization roles

A user or group can be assigned up to four authorization roles.

Unisphere and CA server certificates At installation, the installer generates and installs the self-signed server certificate used for HTTPS.

You should replace this certificate with the one issued by a trusted third-party.

For Unisphere 9.2 and earlier, you need the keystore password to replace a certificate. The keystore password is generated during installation and is stored in the following file:

/jboss/domain/configuration/host.xml where is the directory where SMAS is installed.

Unisphere 51

Open the file and search for keystore alias="tomcat" key-password=.

The key/trust store must contain all CA certificates needed for full certificate trust chain verification.

For information on how to replace, list, and delete certificates, see the Dell Unisphere for PowerMax Installation Guide.

For information on certificate management in Unisphere 10, see the Serviceability in Unisphere section in this chapter.

Port usage Unisphere components use the following ports:

Table 13. Unisphere component ports

Component Protocol Port

https TCP 8443

CLI TCP CLI 9999 (bound to the localhost, and not remotely accessible)

Remoting TCP 4447

postgresql TCP 3324 (bound to the localhost, and not remotely accessible)

Link-and-launch security

NOTE: This feature is not available in Unisphere 10.

Link-and-launch clients connect to Unisphere using HTTPS. The client and Unisphere are required to establish mutual trust. That is, the client side trusts that the server is authentic.

NOTE: Link-and-launch is unavailable if Unisphere is installed with the X.509 certificate-based client authentication option.

The link-and-launch client (acting as SSL client) must establish trust either:

Explicitly, importing the Unisphere self-signed certificate into the client's trust store Implicitly, if the Unisphere self-signed certificate (generated during installation) is replaced with a certificate issued by a

mutually-trusted CA (a CA trusted by both Unisphere and the link-and-launch client).

Trust with the client's launching application is established by explicit registration (by Admin or SecurityAdmin) of the link-and- launch client ID.

The client must provide a valid username of the Unisphere user in whose context the link-and-launch is performed. Once trust is established, a one-time password (token) is issued to trusted link-and-launch clients. The tokens are then exchanged as a means to provide single sign on into Unisphere.

NOTE: Unisphere supports link-and-launch only in the context of users with Admin, StorageAdmin, or Monitor roles.

When the transport is fully secured (by mutual trust establishment) and the user is validated (during initial registration connection), Unisphere issues the client a one-time password (OTP).

In the request that follows, the client exchanges the OTP for a launch token. The exchange must take place within the OTP time-to-live of 10 minutes, otherwise the process (of OTP acquisition and OTP-to-token exchange) must be started again.

The token is valid only for a single launch-and-link until the Unisphere server reboots.

Unisphere data security You can export and import some Unisphere configuration settings to conveniently configure multiple installations.

Exported settings are protected with a customer-defined, one-time password.

The password must be communicated out-of-band as necessary.

52 Unisphere

Security alert system Users with Administrator or StorageAdmin privileges can configure Unisphere to deliver alert notifications for SNMP, e-mail, and Syslog.

The steps to configure alerts, manage alert thresholds, and view alert-related information are described in the Dell Unisphere for PowerMax Installation Guide and Unisphere online help.

Session inactivity Unisphere sessions are checked every eight hours for activity.

The timeout interval is not configurable.

CyberSecIQ CyberSecIQ is an as a service cloud-based storage security analytics application that provides security assessment and measures the overall cyber security risk level of storage systems using intelligent, comprehensive, and predictive analytics.

CyberSecIQ uses Secure Remote Services to collect system logs, system configurations, security configurations and settings, alerts, and performance metrics from the Unisphere system.

Prerequisites for the application include: The Secure Remote Services gateway has already been registered in Unisphere. The Secure Remote Services gateway must be directly connected to Unisphere. Sending data to CloudIQ setting must be enabled. There must be at least one local array in Unisphere.

Serviceability in Unisphere

Unisphere supports the display of embedded applications. NOTE: vApp Manager functionality available in PowerMaxOS 5978 and earlier is now available through the Unisphere UI.

See Unisphere Online Help for details.

Through System > Serviceability on the Unisphere UI, you can: View information about versions View the status of applications Manage the configuration of products and applications

Multi-factor authentication for SecurID

Unisphere for PowerMax 10 introduces a new Authentication Authority for Multi-factor authentication (MFA) with SecurID. The user provides the RSA token and password for Unisphere on the log in screen. Unisphere for PowerMax first authenticates with RSA Authentication Manager with the SecurID token. If the RSA authenticate manager validates the token Unisphere for PowerMax then authenticates against Local Directory, Windows AD or LDAP for two-factor authentication.

NOTE: The token and password are entered in the password field of the log in screen as concatenated values. There should

be no spaces or any other characters between them.

Unisphere 53

Figure 11. Overview of Multi-factor authentication for SecurID

Certificate Management

Certificate management for PowerMaxOS 10 includes: Managing the server certificates Managing the trusted certificates Managing the smart card trusted certificates

NOTE: In all cases of trusted certificate management Dell recommends importing ONLY trust anchor, that is, root CA,

certificates necessary for validation, including OCSP and CRL. Importing intermediate CA certificates is not recommended,

unless required for the anchor establishment. Note that such an importation disables OCSP and CRL validation of that

certificate.

Manage server certificates

Unisphere supports the management of certificates.

1. Open the Settings panel.

2. Select Security > Server Certificates.

3. Select one of the following:

Upload Certificate (Dell Recommended)Upload a Root CA certificate, an intermediate CA certificate, and CA Reply.

Click Restart Unisphere Server.

NOTE: The Unisphere server must be restarted in order to reflect the new certificates.

Generate Certificate Signing Request (CSR) (Dell Recommended)Enter values for Common Name (CN), Subject Alternative Names (comma-separated IP or DNS names), Organization, Organization Unit, Location, State, and Country.

Click Download CSR.

54 Unisphere

Replace with Self-Signed CertificateEnter values for Common Name (CN), Subject Alternative Names (comma- separated IP or DNS names), Organization, Organization Unit, Location, State, and Country.

Click Replace with Self-Signed Certificate.

Download Server Certificate ChainClick Download Server Certificate Chain.

4. Click Close.

Manage the trusted certificates

Unisphere supports the management of the trusted certificates.

1. Open the Settings panel.

2. Select Security > Trusted Certificates. The list of trusted certificates is displayed.

3. The following operations can be selected for a trusted certificate:

Click an item in the list to view additional information about a selected certificate. Click Revoke to revoke a certificate. Click Upload to upload a certificate. Click Download to download a certificate.

4. Click Close.

Manage the smart card trusted certificates

Unisphere supports the management of the smart card trusted certificates.

1. Open the Settings panel.

2. Select Security > Smart Card Trusted Certificates. The list of smart card trusted certificates is displayed.

3. The following operations can be selected for a smart card trusted certificate:

Click an item in the list to view additional information about a selected certificate. Click Revoke to revoke a certificate. Click Upload to upload a certificate. Click Download to download a certificate.

4. Click Close.

SSC authentication

Secure Service Credential (SSC) offers secure authentication and access control for the vendor's service personnel, which is granted by the customer.. SSC authentication bypasses RSA SecurID multi-factor authentication, if the latter is enabled.

The default setting for the SSC user is Block.

NOTE: SSC authentication is supported only for embedded management.

Log file settings

On the Applications > VP Settings page you can set the log level, log file retention period, and enable the download of symapi_debug logs.

Unisphere 55

SMI-S Provider

NOTE: SMI-S Provider is supported only in PowerMaxOS 5978 and earlier.

This chapter contains the following topics:

Topics:

SMI-S Provider Overview SMI-S checklist ECOM toolkit Security controls map User-based access control Component access control Log files and settings Port usage Network encryption Enable authentication for SMI-S Manage the Lockbox Security alerts

SMI-S Provider Overview SMI-S Provider is supported only in PowerMaxOS 5978 and earlier.

Dell SMI-S Provider supports the SNIA Storage Management Initiative (SMI), an ANSI standard for storage management. Solutions Enabler provides the interface between the SMI and arrays running PowerMaxOS 5978.

SMI-S checklist The following checklist summarizes the security-related tasks you should perform to improve the security of your deployment.

Table 14. SMI-S security configuration checklist

Purpose of activity Task

User-based access control

Restrict user access to specific functionality. Configure user authentication, create cstadmin and cstuser accounts, and map users to roles.

Log files and settings

Administer SMI-S log files. Display SMI-S log files.

Securely deploy SMI-S

Enable authentication. Enable authentication for CIM and non-CIM requests.

Create the Lockbox

Create a Lockbox to store and protect sensitive information. Create the Lockbox.

5

56 SMI-S Provider

ECOM toolkit SMI-S uses the Dell EMC Common Object Manager (ECOM) Toolkit to implement security at a variety of levels. ECOM uses SSL and TLS protocols to secure and protect network requests, responses, and indication deliveries. Refer to the Dell EMC Common Object Manager (ECOM) Toolkit Deployment and Configuration Guide for information about:

ECOM port security Securing ECOM communication

Security controls map

SMI-S Client

Application

ECOM

SMI-S Provider

Solutions Enabler

HTTPS

CIM/XML

Request

HTTPS

CIM/XML

Response

HTTPS

CIM/XML

Indication/Alert

Figure 12. SMI-S managed objects

User-based access control This section describes user authorization, user authentication, and administrator user account.

User authorization

User access control to the SMI provider is provided by the ECOM authorization and security toolkit.

The ECOM login page can be accessed at https://{hostname}:5989/ecomconfig.

The default login credentials are:

username: admin password: #1Password

SMI-S Provider 57

User authentication

ECOM supports three types of authorities: LocalDirectory (default), LDAP, and OSLogin. These authorities grant the user access.

To authenticate, ECOM requires user information following one of these two formats along with the user password:

user information := [ authority '/' ] [ domain '\' ] < username >

or

user information := [ domain '\' ] < username > [ '@' authority ]

If the authority recognizes the user, the authentication succeeds and ECOM returns a valid security token.

Configure authentication

The default authority is LocalDirectory. LocalDirectory is used if the authority information is not provided by the user.

You can specify the local directory authority as any substring from the local directory name as defined in the config.xml configuration file (the default is LocalDirectoryTest). For example:

admin LocalDir/admin LocalDirectory/admin LocalDirectoryTest/admin admin@LocalDir admin@LocalDirectory admin@LocalDirectoryTest

LDAP servers can also be used as the authority to authenticate a user. For example:

PSO-AD-Authority/admin PSO-SunOneAuthority/lennon admin@PSO-AD-Authority lennon@PSO-SunOneAuthority

Windows users can also be authenticated by the OSLogin authority.

The string "OSLogin" is used as the authority name in order to authenticate OS users.

Both local and domain users can be authenticated:

If no domain is specified, the user is treated as a "local user" (default). If the domain is explicitly specified, the user is treated as a "domain user".

Both the FQDN and the domain name can be used during authentication. The user-supplied domain entry will be converted into the FQDN.

For example:

OSLogin/Administrator Administrator@OSLogin OSLogin/CORP\mccartney CORP\mccartney@OSLogin OSLogin/corp.localdomain\ringo corp.localdomain\ringo@OSLogin

Administrator user account

ECOM requires a user account under the LocalDirectory authority named administrator.

This section describes the commands used to create the administrator role, create a user, and assign the user to the role.

58 SMI-S Provider

Create a cstadmin role

Use the cstadmin create-role command to create a new role.

The syntax for the cstadmin create-role command is:

cstadmin create-role -app= -cstdir= -description -passphrase=

(mandatory)Name of the role.

-app=

(optional)Name of the application bootstrap file.

-cstdir=

(optional)Path to the CST configuration directory.

-description

(optional)Description for the role.

-threshold

(optional)Sets the Lockbox SSV threshold.

-passphrase=

(optional)Passphrase for the Lockbox.

For example:

$ cstadmin create-role administrator -cstdir=. Enter lockbox passphrase: Confirm passphrase: cstadmin: Role administrator created in role database RoleManagement.

Create a cstadmin user

Use the cstadmin create-user command to create a local directory user account.

The syntax for the cstadmin create-user command is:

cstadmin create-user -app= -cstdir= -description -passphrase= -password=

(mandatory)Name of the local directory account.

-app=

(optional)Name of the application bootstrap file.

-cstdir=

(optional)Path to the CST configuration directory.

-description

(optional)Description for the user.

-passphrase=

(optional)Passphrase for the Lockbox.

-password=

(optional)Initial password for the account.

For example:

$ cstadmin create-user lennon -cstdir=c:/cst/lockbox Enter new user's password: Confirm passphrase:

SMI-S Provider 59

Enter lockbox passphrase cstadmin: User lennon created with account manager LocalDirectoryTest.

Create a role mapping

Use the cstadmin add-rolemember command to add an identity to a role.

The syntax for the cstadmin add-rolemember command:

cstadmin add-rolemember -app= -cstdir= -group -passphrase=

Type of authority.

Name of authority.

The account name to add.

Role name to add.

-app=

(optional) - Name of the application bootstrap file.

-cstdir=

(optional) - Path to the CST configuration directory.

-passphrase=

(optional) Passphrase for the Lockbox.

For example:

$ cstadmin add-rolemember LocalDirectory LocalDirectoryTest lennon administrator -cstdir=c:/cst/lockbox Enter lockbox passphrase cstadmin: Role administrator added to lennon from account manager LocalDirectoryTest.

Component access control Access control for SMI-S Provider components is provided by Dell EMC Common Object Manager (ECOM).

Dell EMC Common Object Manager (ECOM) Toolkit Deployment and Configuration Guide describes the steps to complete this task.

Log files and settings If SecurityLoggingEnabled is set to true in the Security_settings.xml configuration file (located at /conf/), ECOM logs security-related information to the file securitylog.txt.

Whether security logging is enabled or not, security-related information is always logged to the file cimomlog.txt.

cimomlog.txt and securitylog.txt are located at:

/log/

60 SMI-S Provider

Displaying log files

Use the ECOM web server to administer logs and security. The server can be accessed from:

https:// : /ecomconfig where is a secure port as defined in Port_settings.xml.

Dell EMC Common Object Manager (ECOM) Toolkit Deployment and Configuration Guide describes the steps to complete this task.

Port usage Table 15. Ports used by SMI-S

Component Service Protocol Port Description

CIMXMLAdapter ECOM CIM/XML 5989 Secure HTTPS CIM/XML

WSManProtocolAdapte ECOM WS-MAN 5986 Secure HTTPS WS- MAN

EDAAAdapter ECOM Rest 5989 Secure HTTPS EDAA Rest

Network encryption RSA BSAFE library is included in all ECOM distributions to support SSL.

ECOM's secure communication capabilities are configured in the file Security_settings.xml located at /conf/.

The relevant parameter settings in the file are:

CertificatesDirectory

The relative path to ECOM SSL certificates directory from . Default: conf/ssl.

SSLCertFile

The SSL certificate file name in CertificatesDirectory. The default value is: ecomtls.crt.

SSLKeyFile

The SSL private key file name in CertificatesDirectory. The default is: ecomtls.pk.

SSLCAFile

The CA file name in CertificatesDirectory, is needed if SSLClientAuthentication is enabled. The default is: ecomtls.ca.

SSLClientAuthentication

The option that controls whether the client SSL certificate should be verified or not.

SSLProtocol

The option that controls the method functions used to specify the various protocols supported by TLS and SSL connections for both the client and the server.

SSLCipherSuite

The option that controls the supported cipher suites of the SSL connection.

Group Replication

The Dell SMI-S Provider supports the SNIA SMI-S Replication Services profile. The Replication Services profile offers client applications the ability to manage replication using groups, also known as Group Replication. The Solutions Enabler global name service (GNS) can be started in Global Mode which will store the replication group information into the PowerMaxOS system.

SMI-S Provider 61

The advantage to storing replication group information in the storage array is that it centralizes the group data and makes it accessible to different hosts/servers accessing the same system.

The default installation of Solutions Enabler with SMI-S has the default GNS in Local Mode. In this mode, the replication group information is stored on the host running the Solutions Enabler SMI-S service.

Enabling Global Mode

These steps must be completed before any replication group operations are initiated.

1. Shut down the ECOM service.

2. Shut down Solutions Enabler daemons.

3. In the SYMAPI/config/options file add or enable the SYMAPI_USE_GNS = ENABLE option.

4. Start the ECOM service. The ECOM service will automatically start the Solutions Enabler daemons.

Enable authentication for SMI-S To enable authentication for:

CIM requests - set the configuration parameter CIMRequest_AuthenticationEnabled to true.

Non-CIM requests - set NonCIMRequest_AuthenticationEnabled.

Manage the Lockbox SMI-S uses a Lockbox to store and protect sensitive information.

The Lockbox must be initialized with a user account created and mapped to the administrator role.

The Lockbox must be located at /conf/cst/.

Create the Lockbox

Use the cstadmin initialize command to create the Lockbox in the specified directory.

The command creates a new Lockbox in the specified directory used to store keys, signed configuration files and signatures.

The syntax for the cstadmin initialize command:

cstadmin initialize -attended -overwrite -set-lockbox-policy -threshold -two-factor

(mandatory)Path to CST configuration directory. Contains CSTconfiguration files. The Lockbox will be created in this directory.

-attended

(optional)Attended Lockbox.

-overwrite

(optional)Overwrites existing Lockbox.

-set-lockbox-policy

(optional)Sets Lockbox passphrase policy.

-threshold

(optional)Sets the Lockbox SSV threshold.

-two-factor

(optional)Two factor Lockbox.

62 SMI-S Provider

For example:

$ cstadmin initialize c:/cst/lockbox Enter lockbox passphrase: Confirm passphrase: cstadmin: Lockbox c:\cst\lockbox\csp.clb initialized.

Security alerts SMI-S Provider manages alerts as follows:

SMI-S Provider registers to receive all Solutions Enabler storage-related events from Solutions Enabler. SMI-S Provider converts the storage-related events to indication objects. The indication objects are sent to the ECOM indication handler, which then delivers the objects to listening client

applications.

SMI-S Provider 63

Container Applications Application containers are virtual machines that provide embedded applications on the storage array. This chapter contains the following topics:

Topics:

Overview of container applications Container application access IDs

Overview of container applications The PowerMaxOS converged operating system provides an open application platform for running data services. PowerMaxOS includes a light-weight hypervisor that enables multiple operating environments to run as virtual machines on the storage array.

Application containers are virtual machines that provide embedded applications on the storage array. Each container virtualizes hardware resources required by the embedded application, including:

Hardware needed to run the software and embedded application (processor, memory, PCI devices, power management) VM ports, to which LUNs are provisioned Access to necessary drives (boot, root, swap, persist, shared, DB)

Embedded NAS (eNAS) is a data service offered as a container application. eNAS enables consolidated block and file storage without the expense and complexity of gateway hardware.

Embedded Management (eManagement) is a container application that allows you to manage arrays running PowerMaxOS without requiring a dedicated management host.

Embedded VASA Provider (eVASA) enables storage orchestration for vVols between VMware vSphere components and the PowerMax system.

Container applications are installed at the factory. No additional security procedures are required.

Container application access IDs The access ID for a container application is a shared secret between Solutions Enabler and PowerMaxOS. Solutions Enabler generates the access ID based on the type of container application during first boot.

When a container application issues a syscall, PowerMaxOS validates the access ID, and associates the privilege check with the appropriate group.

Container application access IDs have the following characteristics:

Traditional access IDs (generated using attributes of the hardware), are not valid for container applications. The shared secret is not visible through any interface. Customers cannot disable alternate access ID mode or change the access ID.

Client/server mode

By default, client/server mode operations use the access ID of the server. Access control checks are performed against the rules established for the server host.

Customers may prefer to apply client host privileges rather than those of the host.

To change the access control privileges to the client, perform the following:

On the client host:

Set the SYMAPI option SYMAPI_CLIENT_SIDE_ACCESS_ID to ENABLE

6

64 Container Applications

symcli -option set SYMAPI_USE_ACCESS_ID -value CLIENT This tells SYMAPI to send the client access ID to the server.

On the server host:

Set the SYMAPI option SYMAPI_USE_ACCESS_ID to CLIENT or ANY.

CLIENT - (default value) The server expects all clients to send their access IDs. The server will never use the container application access ID.

ANY - If the client sends an access ID, the server uses it. If the client does not send an access ID, the server uses the container application access ID.

Customers may change the server side setting using vApp Manager.

NOTE: Admin privileges on each host are required to modify access for that host.

Container Applications 65

PowerMax File This chapter includes the following topics.

Topics:

PowerMax File PowerMax File security controls map

PowerMax File

NOTE: PowerMax File is supported only in PowerMaxOS 10.

PowerMax File is a Dell scalable, HA-based NAS solution. PowerMax File is a containerized solution that provides File protocol capabilities over a 64-bit file system (UFS64). Each node resides as a container instance inside the File nodes (one container per node). PowerMax File uses the lightweight hypervisor that is provided in PowerMaxOS to create and run a set of virtual machines on storage array controllers. These virtual machines host two major elements of PowerMax File: software-defined NAS (SDNAS) and File Platform. These virtual machines are distributed based on the mirrored pair architecture of the storage array to evenly consume resources for both performance and capacity. All block and file resources are managed through the intuitive, easy-to-use Unisphere for PowerMax management interface. PowerMax File extends the value of storage arrays running PowerMaxOS to File storage by enabling customers to use vital enterprise features including Multi-Appliance (up to eight File Nodes), Sync and Async replication.

PowerMax File extends the value of storage arrays running PowerMaxOS to file storage by enabling customers to use vital enterprise features including service-level objective (SLO)-based provisioning, Host I/O limits, and FAST technologies for both block and file storage.

The PowerMax File guest runs in a virtual environment that is created by a container. Containers identify the resources (memory, ports, and LUNs) used by their guest. When a guest is created, PowerMaxOS assigns an internal IP address that is not exposed to the customer network. MAC address filtering prevents unauthorized access between guests on the array internal network. For more information, see the Dell PowerMax Family Product Guide and the Dell PowerMax File Quick Start Guide.

7

66 PowerMax File

PowerMax File security controls map

Figure 13. PowerMax File managed objects

The security features and tasks of the PowerMax File guest running on the storage array are the same as those for the PowerStore series.

PowerMax Series Security Configuration Guide for PowerMax File provides information on the following security-related topics: Access control Logging Communication security Data security settings Security maintenance Advanced management

CAUTION: Customers are responsible for securing their PowerMax File and PowerStore deployment. Pre-

configured settings may not be sufficiently secure for their needs. PowerMax Series Security Configuration Guide for PowerMax File provides additional information.

PowerMax File 67

Embedded NAS This chapter provides information on the security configuration required for embedded NAS (eNAS), an embedded application available on storage arrays running PowerMaxOS. Topics include:

Topics:

Embedded NAS Security controls map

Embedded NAS

NOTE: eNAS is supported only in PowerMaxOS 5978 and earlier.

Embedded NAS (eNAS) uses the lightweight hypervisor provided in PowerMaxOS to create and run a set of virtual machines on storage array controllers. These virtual machines host two major elements of eNAS: software data movers and control stations. These virtual machines are distributed based on the mirrored pair architecture of the storage array to evenly consume resources for both performance and capacity. All block and file resources are managed through the intuitive, easy-to-use Unisphere for VNX management interface.

eNAS extends the value of storage arrays running PowerMaxOS to file storage by enabling customers to use vital enterprise features including service-level objective (SLO)-based provisioning, Host I/O limits, and FAST technologies for both block and file storage.

The eNAS guest runs in a virtual environment created by a container. Containers identify the resources (memory, ports, and LUNs) used by their guest. When a guest is created, PowerMaxOS assigns an internal IP address that is not exposed to the customer network. MAC address filtering prevents unauthorized access between guests on the array's internal network.

8

68 Embedded NAS

Security controls map

PowerMaxOS

Storage Array

MMCS Service Access

eNAS

Data Mover

Guest Access

Customer Management

Network

HTTPS, other protocols

Credentials

Control Station with EMC Unisphere (for VNX)

Director 1

Data Mover Control Station with EMC

Unisphere (for VNX)

Director 2

Unisphere for PowerMax Link & Launch (Host or eMGMT)

eNAS

HTTPS

HTTPS

Clients

NFS, CIFS

NFS, CIFS

Figure 14. Embedded NAS managed objects

The security features and tasks of the eNAS guest running on the storage array are the same as those for the VNX series.

EMC VNX Series Security Configuration Guide for VNX provides information on the following security-related topics: Access control Logging Communication security Data security settings Security maintenance Advanced management

EMC VNX Series Command Line Interface Reference for File provides information the CLI commands to manage access control, certificates, LDAP configuration, and other security-related activities.

CAUTION: Customers are responsible for securing their eNAS and VNX deployment. Pre-configured settings

may not be sufficiently secure for their needs. EMC VNX Series Security Configuration Guide for VNX provides

additional information.

Embedded NAS 69

Embedded Management This chapter provides information on the security configuration required for Embedded Management (eManagement). eManagement enables you to manage an array running PowerMaxOS without software being installed on a host. Topics include:

Topics:

Embedded Management Security controls map Embedded VASA Provider Virtual machine ports

Embedded Management Embedded Management (eManagement) embeds management software (Solutions Enabler, SMI-S (available only in PowerMaxOS 5978 and earlier), Unisphere for PowerMax) on the storage array, enabling customers to manage the array without installing software on a host.

NOTE: eManagement manages a single storage array running PowerMaxOS and any SRDF attached arrays. Customers with

multiple storage arrays who want a single control pane can use the traditional host-based management interfaces.

eManagement is enabled at the Dell factory.

Security controls map

NOTE: SMI-S and vApp Manager are supported only in 5978 and earlier.

PowerMaxOS

Storage Array

MMCS Service Access

eMGMT

Solutions Enabler (server)

SMI-S Unisphere for

PowerMax

vApp Manager

Guest Access

Customer Management

Network

HTTPS, other protocols

Solutions Enabler

eMGMT Clients

Unisphere for PowerMax

SMI-S Provider

TLS

TLS

TLS

Credentials

Figure 15. eManagement managed objects

9

70 Embedded Management

NOTE: MMCS service access and guest access to the array are distinct and separate operations. Service users do not have

access to any traffic on the guest interface.

Embedded VASA Provider

Embedded VASA Provider (eVASA) embeds VASA Provider software (Solutions Enabler, ECOM, and VASA Provider) on the storage array, enabling customers to perform control operations on Virtual Volumes (vVols). The following images show the architecture for PowerMaxOS 10 and PowerMaxOS 5978 and earlier.

Figure 16. eVASA Provider architecture - PowerMaxOS 10

Embedded Management 71

Figure 17. eVASA Provider architecture - PowerMaxOS 5978 and earlier

Virtual machine ports Virtual machine (VM) ports are associated with virtual machines to avoid contention with physical connectivity. VM ports are addressed as ports 32-63 on each director FA emulation.

LUNs are provisioned on VM ports using the same methods as provisioning physical ports.

A VM port can be mapped to one VM only. However, a VM can be mapped to multiple ports.

72 Embedded Management

vApps NOTE: This chapter is relevant only to PowerMaxOS 5978 and earlier. See the Unisphere chapter for

functionality in PowerMaxOS 10 and later.

This chapter contains the following topics:

Topics:

vApps overview vApps checklist Security controls map Deployment settings and points of access User authentication Port usage Log files and settings SSL certificates Data security settings Serviceability Alerts ClamAV Upgrades

vApps overview Dell delivers virtual appliances (vApps) for:

Unisphere for PowerMax Solutions Enabler VASA Provider/eVASA Provider

vSphere Storage APIs for Storage Awareness (VASA) Provider orchestrates the lifecycle of Virtual Volumes (vVols) and their derivatives: snapshots, clones, and fast-clones. It also provides storage topology, capabilities and status information to the vCenter and the ESXi hosts. eVASA Provider delivers the same functionality, with the difference that it is embedded.

NOTE: The Guest OS and Embedded Management virtual appliances are pre-installed at the factory.

vApps checklist The following checklist summarizes security-related tasks you should perform to improve the security of your deployment.

Table 16. vApp security configuration checklist

Purpose of activity Task

User-based access controlManage user accounts Manage user authentication

Log files and settingsManage log files Download log files

Certificate filesReplace generated certificates with customer-supplied (trusted) certificates for secure communications

Replace pre-generated SSL certificates

Security settingsPerform antivirus scans, download scan logs, and edit the antivirus configuration file

Manage ClamAV (open-source antivirus software)

10

vApps 73

Security controls map

vApp managed objects

74 vApps

Deployment settings and points of access Each vApp is installed from a single Open Virtualization Format (OVF) archive and deployed in a standard ESXi appliance.

There are three points of access:

vApp Manager SSH VM console

vApps are designed to be managed by the vApp Manager. There is no direct user access except when SSH is explicitly enabled for troubleshooting. No components can be individually managed.

vApp Manager

vApp Manager is a browser-based user interface console contained within each vApp that allows you to perform management and configuration tasks for the vApp. vApp Manager is the sole management interface for accessing vApps and is accessed via a secure https layer. For example:

https://hostname:5480

SSH

You can enable the SSH port for an SSH session to troubleshoot the appliance or storage system. The default state of the SSH port is disabled.

You must log in to vApp Manager to enable or disable the SSH port. Authentication is required for login.

CAUTION: Troubleshooting the appliance or storage system should only be done under the direction of

Customer Support.

Virtual machine console

You can access the VM console via the ESXi server. The following activities are supported through ESXi server access:

Network configuration Upgrades Setting timezones

Limiting access to management interfaces

You can limit access to management interfaces from a defined list of hosts. In vApp Manager, you can specify an IP or host name to restrict the vApp client access to only that domain. Both the server and client components must be part of the same network.

For information on how to change the domain name, see the vApp Manager online help.

User authentication vApp Manager users can:

Configure and update vApp options Retrieve log files

The vApp Manager provides two types of user authentication:

Local directory authentication (username and password) Lightweight Directory Access Protocol (LDAP) authentication

LDAP allows for distributed directory information services over a network of hosts. A client must provide a set of parameters to configure LDAP, which then allows connection to the LDAP server, and secures communication between hosts on the network.

vApps 75

You can add new local users or map existing LDAP users. New users are assigned the admin role.

LDAP admin users can be either a "user" or "group" type. All users belonging to an LDAP group can perform all vApp Manager operations.

The vApp Manager contains online help that describes the steps to manage user authentication, including:

Configuring LDAP Changing the LDAP configuration Importing certificates Adding user accounts Removing user accounts Changing user passwords

VASA/eVASA Provider authentication

Authentication and authorization between vCenter and VASA Provider is achieved by registering VASA Provider in the vSphere Web Client for vCenter. For information about registering VASA Provider, see the Dell VASA Provider Release Notes. Dell Technologies recommends that you change the default password for security.

After VASA Provider is registered, certificates are the authorization mechanism. The certificate authorities can be owned by VMware Certificate Authority (VMCA), Dell, or a third party.

Default user accounts

A default user account is created during installation. The default user can be removed, but only by an LDAP user.

vApp Manager has one or two default user accounts:

Table 17. vApp default accounts

vApp Username Password

Unisphere for PowerMax seconfig seconfig

Solutions Enabler seconfig seconfig

VASA Provider vpconfig vpconfig

eVASA Provider seconfig seconfig

The first time you log in you will be prompted to change the password for the default user account. You can subsequently change the password at any time.

A second default user account is created if you enable SSH. The default SSH user account for all vApps is:

username: cseadmin password: cseadmin

You can change the password for the default SSH account at any time.

Port usage vApp Manager uses the network ports listed in the following table. All other ports are blocked.

Table 18. Network ports used in vApps

Component Protocol Port Description

SSH TCP 22 SSH port. This port can be enabled/disabled using vApp Manager.

Default: disabled.

Solutions Enabler TCP 2707 Standard Dell Solutions Enabler server port for client-server communication.

76 vApps

Table 18. Network ports used in vApps (continued)

Component Protocol Port Description

vApp Manager TCP 5480 Port where the vApp JBoss web server listens for vApp Manager requests.

Listening port for uploading certificates and licenses to Unisphere for PowerMax vApp Manager over HTTP.

SMI TCP 5989 Standard Dell SMI port.

VASA Provider TCP 5989 Standard Dell secure port. VASA Provider does not conflict with SMI-S port usage since the vApps are installed in separate OVF packages.

eVASA Provider TCP 5989 Standard Dell secure port. This port is exclusive to VASA Provider within the eVASA container.

vApp for Unisphere for PowerMax

TCP 8443 Standard Dell Unisphere for PowerMax listening port.

Log files and settings You can use the vApp Manager to download the following log files from the vApp:

Daemon log files, including: storapid storgnsd storrdfd storevntd storsrmd storwatchd storstpd storsrvd ecom univmax

Appliance (vApp Manager) log files First level log files and other diagnostic information obtained by the Dell Grab files.

The vApp Manager online help describes the steps to download log files.

VASA Provider Log Files

The VASA Provider log files are located in: VASA Provider 9.0 and earlier: /opt/emc/vvol/log VASA Provider 9.1 and later: /opt/emc/vvol/ecom/log .

The log files are:

HTTP_trace.log VVolProvider- .log cimomlog.txt udb.log vp.log securitylog.txt

eVASA Provider Log Files

The eVASA Provider log files are located in three locations:

vApps 77

/data/vvol/logs/ The log file is: vp.log

/opt/emc/vvol/ecom/log The log files are: HTTP_trace.log VVolProvider- .log cimomlog.txt securitylog.txt cstlog.log

/shared/vvol/db/log/ The log file is: udp.log

Log file management

Logging levels, log file retention, and synchronization between the log files and the ESX timer are not configurable.

Log file entries cannot be streamed to an external log service, such as syslog.

This is a disk usage alert which tracks filesystem usage. It alerts the user when any of the filesystems grow more than 80 percent.

SSL certificates SSL certificates for the vApp Manager cannot be modified.

You can use the vApp Manager to import an alternate (custom) SSL certificate for the storsrvd daemon. The vApp Manager online help describes the steps to create and update SSL certificates.

The certificate is used when stordaemon command requests are made from a remote client. Certificates can be self-signed or CA-signed.

Importing an alternate certificate for the storsrvd daemon requires the following files:

Private key file Replacement certificate file Trust certificate file

These files must be in a .pem format. For example:

customer_key.pem The common name (CN) of the certificate must include storsrvd followed by a space, and the fully qualified name of the host where the certificate will be installed. For example:

storsrvd my.host.com

Data security settings The vApp Manager persistent data files include the following appliance configuration files:

Daemon Option file Option file Network configuration file symapi.db file daemon specific files

To download the persistent files using vApp Manager, click the Download > Persistent Data.

Downloaded data files are saved to a .zip file (including a .gpg file) named:

product-name_export_persistenent_data_date_time.zip

78 vApps

The data is fully encrypted. The encryption key is not configurable and cannot be modified.

Starting in Solutions Enabler 8.0.2, vApp Manager verifies that there is sufficient space to create the .zip file. If there is not sufficient space, a message similar to the following is displayed:

Insufficient space to compress persistent data. Please try cleaning up temporary files. You can click the CLEAR FILES button to create sufficient space to complete the compression and download.

NOTE: In Unisphere for PowerMax deployments, you must stop and restart SMAS in order to clear the files. The steps to

start and stop SMAS are described in the Dell Unisphere for PowerMax Installation Guide.

Serviceability There are no special login details to vApp Manager for service personnel.

Dell Service Personnel may ask you to enable SSH access for troubleshooting the vApp. Ensure SSH is disabled except on request from Dell.

Security patches and other updates are applied by upgrading the vApp installation image from the VM console.

Alerts vApp Manager has two pop-up alerts:

Virus update alertDisplayed when an update for ClamAV is available. ClamAV is an antivirus package that detects viruses, trojans, malware, and other malicious threats.

Log file usage alertDisplayed when a log file reaches 80 percent of available capacity.

These alerts are display-only. They are not forwarded to an alert notification manager.

ClamAV The vApp Manager is packaged with ClamAV, an open source (GPL) antivirus capability designed to detect viruses, trojans, malware, and other malicious threats on the appliance virtual machine. ClamAV supports on-demand scanning, antivirus updates, access to scan log files, and editing the ClamAV configuration file.

Information on managing ClamAV is included in the vApp Manager online help.

Upgrades Updates to vApp are installed using a full ISO upgrade.

Patching is not supported.

vApps 79

Data at Rest Encryption This chapter contains the following topics:

Topics:

Overview Key manager Key protection

Overview Data at Rest Encryption (D@RE) provides hardware-based, on-array, back-end encryption for PowerMax storage arrays. Back- end encryption protects your information from unauthorized access when drives are removed from the system. D@RE provides encryption using back-end I/O modules that incorporate AES-XTS data-at-rest encryption, designed to be FIPS 140-2 Level 1 compliant. These modules encrypt and decrypt data as it is being written to or read from a drive. All configured SSD drives are encrypted, including both RAID groups and spares. In addition, all array Vault contents are encrypted.

From PowerMaxOS 10, D@RE is supported using self-encrypting drives (SEDs). A SED is a solid-state drive that provides hardware-based data encryption. All user data that is written or read to or from the drive media is encrypted and decrypted using a Data Encryption Key (DEK). The benefits of SED include line rate encryption and decryption of the I/Os, drive vendor- based FIPS 140 certification, standard Trusted Computing Group (TCG)-based drive security configuration, and instant user data erasure.

NOTE: Before using SEDs in a PowerMax array, verify that the tamper-proof seal is intact, this indicates that the drive has

not been tampered with. Also, it is a good idea to monitor the seal from time to time, to ensure that it is still intact.

D@RE can use either of the following methods for key management:

Dell Key Trust Platform (KTP) Interface with an OASIS Key Management Interoperability Protocol (KMIP) compliant external key manager

See the Dell PowerMax Family Product Guide for information about D@RE architecture and components.

D@RE keys are self-managed, and there is no need to replicate keys across volume snapshots or remote sites. The key manager provides a separate, unique data encryption key (DEK) for all drives in the array including spares.

By securing data on enterprise storage, D@RE ensures that the potential exposure of sensitive data on discarded, misplaced, or stolen media is reduced or eliminated. As long as the key used to encrypt the data is secured, encrypted data cannot be read. In addition to protecting against threats related to physical removal of media, this also means that media can readily be repurposed by destroying the encryption key used for securing the data previously stored on that media.

D@RE is compatible with all PowerMax system features, allows for encryption of any supported logical drive types or volume emulations, and delivers powerful encryption without disruption to existing applications or infrastructure.

D@RE protects against unauthorized data access when drives are lost, failed, or stolen. Features include:

Secure replacement for failed drives that cannot be overwritten. Delete the applicable keys, and the data on the failed drive is unreadable.

Protection against stolen drives. When a drive is removed from the array, the key stays behind, making data on the drive unreadable.

Faster drive sparing. Drive replacement operations crypto-shred data by destroying any keys associated with the removed drive.

Secure array retirement. Simply delete all copies of keys on the array, and all remaining data is unreadable. All configured drives are encrypted, including RAID groups and spares. PowerVault data is encrypted on Flash I/O modules. You can use SYMCLI (symcfg list -v), Unisphere (icon on the front panel), vApp Manager, and SMI-S to show whether

D@RE is enabled on a storage array.

11

80 Data at Rest Encryption

D@RE is a licensed feature. For new systems, D@RE is pre-configured and installed at the factory. If you are using the embedded key manager, no user management of D@RE security features are required or possible. If you are using an external key manager, additional configuration steps are required to connect to the key servers.

NOTE: If you have an existing storage array running PowerMaxOS without D@RE enabled, you must upgrade to enable

D@RE. The upgrade is disruptive and requires re-installing the array, and may involve a full data back up and restore. Before

you upgrade, you must plan how to manage any data already on the array. Professional Services offers services to help you

upgrade to D@RE.

Key manager D@RE provides enterprise-level key management by integrating with a KMIP compliant external key manager. For a list of supported key managers, see E-Lab Interoperability Navigator (ELN) at https://elabnavigator.dell.com/eln/elnhome.

The key manager provides a separate, unique DEK for each disk in the array, including spare drives. As long as the key used to encrypt the data is secured, encrypted data cannot be read. When D@RE is enabled:

The key manager generates a Key Encryption Key (KEK). When a RAID group or pool is configured, the key manager generates an encryption key (DEK) for each drive. Every drive

has a unique key. When a drive is added or replaced, a new DEK is generated. After drive replacement, the old key is destroyed both in the array configuration and key manager.

DEKs and KEKs can be used only on the array where they are generated (embedded key manager) or requested from (KMIP compliant external key manager). DEKs are encrypted with a KEK and pushed from the Key Manager to the controller as necessary during normal operations, such as when a new drive is added.

NOTE: In PowerMaxOS 10 SEDs, the DEK is internal to the drive.

When data requiring data-at-rest-encryption is replicated to another array, D@RE must be separately enabled at both the primary and secondary sites. There is no need to share D@RE encryption keys between sites to protect replicated data, as the drives at each site will have independent encryption keys local to that array.

The audit log records all key management events.

Key protection The local keystore file is encrypted with a 256-bit AES key derived from a randomly generated password file. This password file is secured in the Lockbox. The Lockbox is protected using MMCS-specific stable system values (SSVs) of the primary MMCS. These are the same SSVs that protect Secure Service Credentials (SSC).

Compromising the MMCS drive or copying Lockbox and keystore files off the array causes the SSV tests to fail. Comp

Manualsnet FAQs

If you want to find out how the PowerMax Dell works, you can view and download the Dell PowerMax 2000 Storage Product Guide on the Manualsnet website.

Yes, we have the Product Guide for Dell PowerMax as well as other Dell manuals. All you need to do is to use our search bar and find the user manual that you are looking for.

The Product Guide should include all the details that are needed to use a Dell PowerMax. Full manuals and user guide PDFs can be downloaded from Manualsnet.com.

The best way to navigate the Dell PowerMax 2000 Storage Product Guide is by checking the Table of Contents at the top of the page where available. This allows you to navigate a manual by jumping to the section you are looking for.

This Dell PowerMax 2000 Storage Product Guide consists of sections like Table of Contents, to name a few. For easier navigation, use the Table of Contents in the upper left corner.

You can download Dell PowerMax 2000 Storage Product Guide free of charge simply by clicking the “download” button in the upper right corner of any manuals page. This feature allows you to download any manual in a couple of seconds and is generally in PDF format. You can also save a manual for later by adding it to your saved documents in the user profile.

To be able to print Dell PowerMax 2000 Storage Product Guide, simply download the document to your computer. Once downloaded, open the PDF file and print the Dell PowerMax 2000 Storage Product Guide as you would any other document. This can usually be achieved by clicking on “File” and then “Print” from the menu bar.