Solutions Enabler Security Configuration Guide · Security Configuration Guide . ... operations...

EMC Corporate Headquarters

Hopkinton, MA 01748-9103 1-508-435-1000 www.EMC.com

EMC CONFIDENTIAL – INTERNAL USE ONLY EMC CONFIDENTIAL – INTERNAL AND PARTNER USE ONLY DELETE IF THIS IS A PUBLIC DOCUMENT

EMC Solutions Enabler V7.4

Security Configuration Guide P/N 300-013-913 A01

EMC Corporation

Solutions Enabler V7.4 Security Configuration Guide 2

Copyright © 2012 EMC Corporation. All rights reserved.

Published May, 2012

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their respective owners.

EMC Corporation


Table of Contents

1 Overview ................................................................................................................................. 4

2 Security configuration settings ................................................................................................ 4

2.1 Introduction ...................................................................................................................... 4

2.2 Symmetrix access control ................................................................................................ 5

2.2.1 Securely identifying hosts with access IDs .............................................................. 5

2.2.2 Supporting access control in client/server mode ..................................................... 7

2.3 User authorization ............................................................................................................ 9

2.3.1 User identification .................................................................................................... 9

2.3.2 Support for all user groups ...................................................................................... 9

2.4 Log files and settings ..................................................................................................... 10

2.4.1 Log descriptions ..................................................................................................... 10

2.4.2 Log settings ........................................................................................................... 11

2.5 Communication security settings ................................................................................... 12

2.5.1 Port usage ............................................................................................................. 12

2.5.2 Port settings ........................................................................................................... 13

2.5.3 Client/server settings ............................................................................................. 13

2.5.4 Secure client/server support using SSL ................................................................ 15

2.5.5 Secure session settings summary ......................................................................... 17

2.6 Data security .................................................................................................................. 18

2.7 Other security considerations ........................................................................................ 19

2.7.1 Daemon processes on UNIX ................................................................................. 19

2.7.2 Securing directories for daemon processes .......................................................... 19

2.7.3 Securing Solutions Enabler configuration files ...................................................... 20

2.7.4 Running commands as a non-privileged use ........................................................ 21

3 Secure deployment and usage ............................................................................................. 22

3.1 Guidelines for securely deploying Solutions Enabler .................................................... 22

3.1.1 Securely enabling client/server operations ............................................................ 22

4 Secure maintenance ............................................................................................................. 23

4.1 Backup of Solutions Enabler state ................................................................................. 23

EMC Corporation


1 Overview This guide describes the security configuration settings available in Solutions Enabler, along with information on how to securely deploy, use, and maintain the product. It is divided into the following sections:

• Security Configuration Settings describes Solutions Enabler security settings.

• Secure Deployment and Usage provides instructions on how to deploy and use Solutions Enabler securely.

• Secure Maintenance provides recommendations for safeguarding data maintained by Solutions Enabler.

Note: This document only describes Solutions Enabler management operations and does not cover data access using device masking, Auto-provisioning, or IPSec capabilities.

2 Security configuration settings

2.1 Introduction Solutions Enabler security settings fall into the following categories:

• Symmetrix access control restricts host access to sets of devices across numerous Symmetrix arrays.

• User authorization assigns individual users or groups to roles that limit the management operations they can perform.

• Log files and settings control event logging and associated files.

• Communication security settings provide security for the product network communications.

• Data security settings ensure protection of the data handled by the product.

• Other security considerations describe other security settings critical to Solutions Enabler operations.

Note: When <SYMAPI_HOME> is used, it refers to the location of Solutions Enabler data and configuration files. The following are the default locations (unless overridden during a Windows installation):

Windows: C:\Program Files\EMC\SYMAPI UNIX (and UNIX-based systems): /var/symapi

Open VMS file locations are discussed in the EMC Solutions Enabler Installation Guide.

Note: When pathnames are presented in this document, they use a UNIX-specific format, using forward slashes (/) instead of backslashes (\) that are typically used in Windows platforms.

EMC Corporation


2.2 Symmetrix access control Symmetrix provides two types of access control mechanisms: the symacl command and the symauth commands. The symacl command provides host-based access control that can restrict host access to sets of devices across numerous Symmetrix arrays. This is known as symacl functionality and is also referred to as Symmetrix access control. The symauth command provides user-based authorization that assigns a user or group to a role to limit the management operations they can perform on a Symmetrix array. For detailed information on these commands, refer to the EMC Solutions Enabler Symmetrix Array Management CLI Product.

2.2.1 Securely identifying hosts with access IDs Symmetrix access control identifies individual management hosts with an access ID. There are two different approaches to generating access IDs:

• Hardware-based access ID: By default, a host's access ID is derived from hardware characteristics of that host. On x86 (32-bit Intel), x86_64 (64-bit Intel/AMD), and IA 64 platforms, a network interface MAC address is used. On other platforms, different characteristics of the host, such as a processor identifier, are used. For more information, refer to the next section.

• Alternate access ID: Optionally, a host's access ID can be generated at random or from a provided passphrase and stored to a secure location on disk. This functionality is supported for all platforms but is strongly recommended on platforms where the access ID is derived from a network interface MAC address. For more information, refer to Section 2.2.1.2 on page 6.

This functionality is available in Solutions Enabler 7.3.2 and higher.

• Note: For added security on x86 (32-bit Intel), x86_64 (64-bit), IA64, and BS2000 hardware platforms, it is recommended that you use alternate access IDs instead of hardware-based access IDs. For more information on using alternate access IDs, refer to Section 2.2.1.2 on page 6.

2.2.1.1 Hardware-based access IDs When MAC addresses generate access IDs, they may be unreliable or ineffective under certain circumstances, such as in clustering or virtual environments or following a hardware change. As a result, an alternate method for generating access IDs is available for x86 platforms, as explained in Section 2.2.1.2 on page 6.

Note: For IBM z/OS platforms, you must use job #14MSACL in RIMLIB to generate the unique ID for the host. This job is equivalent to the Solutions Enabler symacl –unique command, which returns an encrypted access ID for the host machine or operating node.

2.2.1.1.1 Enabling hardware-based access IDs 1. Confirm that the following option in the options file is disabled or removed:

SYMAPI_ALTERNATE_ACCESS_ID = DISABLE

2. Run the symacl -unique command to generate and display an encrypted access ID.

3. Add this access ID to the appropriate access groups.

EMC Corporation


2.2.1.2 Alternate access IDs Available for all platforms, alternate access IDs do not utilize the host’s hardware identifiers (such as MAC address) to generate an encrypted access ID. When enabled, Solutions Enabler can randomly generate an alternate access ID or generate an alternate access ID based on a passphrase or file specified in the symacl –unique command for a host, as explained in Section 2.2.1.2.1. It then securely stores this alternate access ID on the local disk. For more information on the symacl –unique command, refer to the symacl man page.

Enable the SYMAPI_ALTERNATE_ACCESS_ID value in the options file to use alternate access IDs. The options file is located in the following directory:

<SYMAPI_HOME>/config

When enabled and in use, two copies of the alternate access ID—a primary and backup—are securely stored on disk in the following files:

<SYMAPI_HOME>/config/lockboxp

<SYMAPI_HOME>/config/lockboxb

These files are encrypted. If the primary copy is found to be corrupt, the backup is used. These files hold other security-related information (and keys) in addition to these alternate access IDs. Therefore, do note delete these files.

Note: It is recommended that you maintain backup copies of these files and secure those backups appropriately. If these files are lost (for example, during a disk replacement or file system re-image), any alternate access IDs contained in those files are lost along with the other security information that Solutions Enabler stores there.

2.2.1.2.1 Enabling alternate access IDs 1. Add the following option in the options file:

SYMAPI_ALTERNATE_ACCESS_ID = ENABLE

2. Run the symacl -unique command. Solutions Enabler recognizes that the above option is set and, if one does not already exist for the host, generates an access ID, securely stores it on the local disk, and displays it.

Note: If you ran this command before enabling the above options file setting, the new alternate access ID is a different value than the hardware-based access ID you received prior to enabling this option. Any hardware-based access ID previously used to identify this host in an access group must be updated with the new alternate access ID using Solutions Enabler.

3. Add this new, alternate access ID to the appropriate access groups. When an access ID is required on this host, the alternate access ID that was stored to disk is used.

2.2.1.2.2 Disabling an alternate access ID 1. Change the following setting in the options file to (or remove the line from the options

file):

SYMAPI_ALTERNATE_ACCESS_ID = DISABLE

2. Run the symacl -unique command. This command recognizes that the option was reset, and disables the alternate access ID stored on disk. A copy of the access ID remains securely stored on disk, but is not used. If you choose to enable the option in the future, the same value is used.

EMC Corporation


2.2.1.2.3 Changing a host's alternate access ID It is recommended that you have two administrative hosts available to change a host's alternate access ID. You cannot perform all the operations from the host that requires the access ID change. When you change the access ID for a given host, the host no longer has any valid Access Control entries, since the original access ID no longer applies, and the host may lose access to the storage array. You need a secondary host to reset the Access Control entries for the host’s new access ID.

For example, assume that you need to change the access ID for Host-1. Login to another administrative host, such as Host-2, and remove any existing Host-1 definitions from the access group for all Symmetrix arrays of which Host-1 has access. From Host-1, follow the steps outlined in Section 2.2.1.2.1 on page 6 to enable (or disable) the alternate access ID mechanism and obtain a new access ID. From Host-2, add Host-1 back into its access group using its new access ID to any Symmetrix arrays to which it requires access.

Note: The Solution 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 only have one such administrative host, and you are trying to change its alternate access ID, once that change is made, the host no longer can make Access Control changes (the new access ID is not yet in an access group). It is recommended that you enable a second administrative host (even temporarily to complete this operation) prior to completing this task.

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

Starting with Solutions Enabler 7.4, you can use the access ID of the client host instead of the server host. 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 make changes in the options file on the client and the server host, as explained in the following sections.

2.2.2.1 Server host options file settings On the server host, the following option controls the source of the access ID used for the client/server sessions:

SYMAPI_USE_ACCESS_ID = CLIENT | SERVER | ANY

The behavior of this option is as follows:

• When set to CLIENT, an access ID supplied by the client host is used. If the client did not provide an access ID, operations fail. This can occur if the client is running a version of Solutions Enabler earlier than 7.4 or if this functionality was not configured on the client.

• When set to SERVER (default), the server always uses its own access ID and ignores an access ID, if any, provided by the clients.

• When set to ANY, the server uses an access ID provided by a client. If one is not provided, the server uses its own access ID.

EMC Corporation


2.2.2.2 Client host options file settings The use of the alternate access ID, described earlier, must be enabled to use this functionality:

SYMAPI_ALTERNATE_ACCESS_ID = ENABLE

Additionally, you must set the following option to control whether the client can send its own access ID to the server for use there:

SYMAPI_CLIENT_SIDE_ACCESS_ID = ENABLE | DISABLE

The behavior of this option is as follows:

• When set to ENABLE, the client sends its access ID to the server in client/server mode. • When set to DISABLE (default), the client does not send its Access ID to the server in

client/server mode.

Important: After enabling the above two options, you must then run the symacl –unique command on the client side to generate the access ID and store it in the lockbox on the client side.

EMC Corporation


2.3 User authorization Symmetrix user authorization assigns individual users to roles that limit the management operations that they can perform. The roles define a set of restrictions for users. User authorization does not provide functionality-based control over access as Symmetrix access control does. Using the symauth command, SMC (Symmetrix Management Console), or Unisphere for VMAX 1.0, you assign users to management roles to restrict the types of operations they can perform. For additional information, refer to the EMC Solutions Enabler Symmetrix Array Management CLI Product Guide.

Solutions Enabler does not support an explicit authentication mechanism for users. When using SYMCLI commands, Solutions Enabler uses the credentials that users supply when logging onto the local system—as provided by the operating system. When using SMC or Unisphere for VMAX 1.0, the user’s authenticated identity is passed to Solutions Enabler.

2.3.1 User identification Internally, Solutions Enabler represents a user identity as a string that comprises the user’s name along with how (and where) they were originally authenticated. The possible encodings 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. [SMC or Unisphere for VMAX 1.0 only]

C:HostName\UserName A user authenticated by the private SMC or Unisphere for VMAX 1.0 authentication service on some host. [SMC or Unisphere for VMAX 1.0 only]

V:DomainName|UserName A user authenticated by a Virtualization Domain. [SMC or Unisphere for VMAX 1.0 only]

Solutions Enabler uses these identities in a number of ways. A user name is included in records written to the Symmetrix array’s 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 Symmetrix arrays.

2.3.2 Support for all user groups In Solutions Enabler 7.4, user authorization now checks all groups to which a user belongs. During rights checking, each user group is examined for a role mapping and the “or” of all rights granted to each group. The symauth show –username command displays all groups to which a user belongs.

Authorization rules can be configured for a Symmetrix array that map either a user or group name to a management role. For both user and group authorization, the contained name can be fully qualified (such as D:Corp\Jones and D:Corp\Sales) or unqualified (such as Jones and Sales).

The rights that are called in for any of these entries matching the user's identity are granted to that user. Authorization entries with an unqualified user name are only considered if there is no user entry with a fully-qualified name that matches the user. Authorization entries with an unqualified group name are only considered if there are no group entries with a fully qualified-name matching the user. For more information, refer to the symauth man page.

EMC Corporation


2.4 Log files and settings

2.4.1 Log descriptions Solutions Enabler maintains the following log files.

Log type and location Description

Solutions Enabler log files <SYMAPI>/log/symapi_yyyymmdd.log

Where yyyymmdd is the numerical value for the year, month, and day. For example, symapi_20120920.log is the log for September 20, 2012.

Solutions Enabler writes errors and other significant conditions to this log.

By default, Solutions Enabler keeps these files forever. Setting the SYMAPI_LOGFILE_RETENTION option, as described in Section 2.4.2 on page 11, configures at what point in time to automatically remove these files.

Daemon log files <SYMAPI>/log/storXXXX.log0 <SYMAPI>/log/storXXXX.log1

Where storXXXX is the name of the daemon. For example: storapid.log0, storapid.log1, storgnsd.log0, storgnsd.log1.

Each Solutions Enabler daemon maintains a pair of log files. The daemons alternate between these two files, switching from one to the other, when the default maximum size of approximately 1 MB is reached.

EMC Corporation


Symmetrix Audit Log

Maintained on the Symmetrix array.

A secure audit log containing a record of configuration changes, security alarms, service operations, and security-relevant actions maintained on each Symmetrix array. Records are written to this by Solutions Enabler, software running on the Service Processor, and the Enginuity™ Operating Environment. Information from this log can be retrieved using the symaudit SYMCLI command.

For more information on this audit log, refer to the EMC Solutions Enabler Symmetrix Array Management CLI Product Guide.

You can configure the Solutions Enabler event daemon, storevntd, to automatically stream audit entries from this log to an external log service (EMC RSA Envision, syslog, Simple Network Management Protocol (SNMP), or the Windows Event Service) automatically as they appear. For more information on configuring the Solutions Enabler event daemon, refer to the EMC Solutions Enabler Installation Guide.

2.4.2 Log settings The following option setting controls how long the Solutions Enabler log files are retained.

Option name and Location Description

SYMAPI_LOGFILE_RETENTION = NN

<SYMAPI_HOME>/config/options

Solutions Enabler log files, discussed previously, can be automatically removed NN days after they were created.

Note: The log files might not be removed after the NN days are reached. This value indicates to the system when a given file can be removed by the logging logic during its normal operation.

Valid values for NN are between 5 and 1825 (or between 5 days and 5 years). If running on the Symmetrix service processor, you can only set this to the default value of 0 (keep them forever) or 30.

EMC Corporation


2.5 Communication security settings

2.5.1 Port usage The following network ports are used by Solutions Enabler.

Component Protocol Port Description

Solutions Enabler

TCP/IP 2707 In client/server mode, the Solutions Enabler server daemon, storsrvd, listens on this port for connections from client hosts.

You can change the default port as described in Section 2.5.2 on page 13.

Event Daemon TCP/IP Dynamically Assigned

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 side event daemon.

For information on setting a specific port value, refer to Section 2.5.2 on page 13.

CLARiiON TCP/IP 443 or 2163 A configuration file on CLARiiON® storage arrays controls whether it listens for connections from management hosts over ports 443 or 2163. When Solutions Enabler needs to communicate with an array, it attempts both values.

If a firewall or network address translator is present between communicating entities, these ports

or ones configured must be open. Typically, this is:

• A firewall between the Solutions Enabler client and the server hosts.

• A firewall between the management server and the CLARiiON array.

EMC Corporation


2.5.2 Port settings Option location and name Description

storsrvd:port = NN <SYMAPI_HOME>/config/daemon_options

On the server hosts, this directs the Solutions Enabler server, storsrvd to listen for connections at this port instead of the default 2707.

If the default value is changed for the server, you must edit this entry for this server in <SYMAPI_HOME>/config/netcnfg, as explained in the next row.

SvcName - TCPIP HostName - NN SECURE <SYMAPI_HOME>/config/netcnfg

On client hosts, the netcnfg file maps service names (SvcName), used with the SYMCLI, to a host (HostName) and port (NN) on which the appropriate server is listening. If a non-default server port is configured, also make corresponding changes to the servers in this file. For more information, refer to Section 2.5.4.3 on page 16.

storevntd:event_listen_port = NN <SYMAPI_HOME>/config/daemon_options

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 side event daemon.

On client hosts, this setting directs the event daemon to listen at this specific port for events sent from the server host instead of using a random port assigned by the local operating system. This setting is automatically transmitted to the server hosts as needed.

2.5.3 Client/server settings In Solutions Enabler client/server mode, client host operations are automatically forwarded to the storsrvd daemon on a server host for execution. For additional information, refer to the EMC Solutions Enabler Installation Guide.

By default, traffic transmitted between client and server hosts is encrypted using SSL. A number of mechanisms are available to operate these connections in a secure manner as described next.

2.5.3.1 Starting the Solutions Enabler server The storsrvd daemon does not run by default. You must explicitly start it before it can accept connections from remote clients. Run the following command to start the storsrvd daemon:

stordaemon start storsrvd

You can configure the storsrvd daemon to start automatically whenever a server host starts by running the following command:

stordaemon install storsrvd -autostart

EMC Corporation


Daemons are started differently on z/OS and Open VMS platforms. The EMC Solutions Enabler Installation Guide provides detailed instructions on starting the Solutions Enabler server.

2.5.3.2 Restricting access to the Solutions Enabler server Use the <SYMAPI_HOME>/config/nethost file on a server host to restrict the hosts and users from which storsrvd accepts connections. If the nethost file is not present, connections are accepted from all client hosts.

Each line of the nethost file identifies authorized hosts with an optional comma-separated list of user names. If a host’s user list is omitted or is specified as an asterisk (*), all users connecting from that host are accepted. Note that no spaces are permitted between user names (such as joe,sally). For example:

# From Client host Saturn, all users may connect.

saturn *

# From Client host Jupiter, only users joe and sally may connect.

jupiter joe,sally

# An IP address can be used instead of a host name.

180.100.90.75 *

Connections from hosts or users not in the nethost file are refused. When a connection is refused, an error message containing the requesting client’s user and host name is written to the storsrvd.log0 or storsrvd.log1 file on the server.

2.5.3.3 Restricting functionality in the Solutions Enabler server Settings in the <SYMAPI_HOME>/config/options file on a server host can be used to restrict the functionality that storsrvd is allowed to perform on behalf of remote client hosts. The options are listed in the following table.

Option Name ( within <SYMAPI_HOME>/config/options )

Description

SYMAPI_ACC_ADMIN_VIA_SERVER Symmetrix access control changes.

This defaults to ENABLE.a

SYMAPI_ACC_DISPLAY_VIA_SERVER Symmetrix access control information displays.

This defaults to ENABLE. a

SYMAPI_ALLOW_SCRIPTS_VIA_SERVER Symmetrix TimeFinder pre-action and post-action scripts.

This defaults to DISABLE.

SYMAPI_CTRL_VIA_SERVER Symmetrix control operations in general.

This defaults to ENABLE. a

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

EMC Corporation


2.5.3.3.1 IBM z/OS-specific behavior for control operations By default, a Solutions Enabler server running on any z/OS host allows configuration changes when requested by a remote client (this is a change in behavior from previous releases). For additional information, refer to "Restricting Control Operations" in the EMC Solutions Enabler Installation Guide.

Caution: If control operations are left enabled by default, remote open systems users (client/server mode) can make changes to the Symmetrix configuration on your mainframe system.

2.5.4 Secure client/server support using SSL Solutions Enabler uses SSL to secure communications between client and server hosts where possible. Additionally, the product should only be used where network-layer authentication prevents rogue hosts from connecting or accessing network traffic.

Note: Solutions Enabler does not support SSL on iSeries, BS2000, OpenVMS, or Linux on PPC hosts.

2.5.4.1 Network encryption By default, traffic transmitted between client and server hosts is encrypted using SSL. The following cryptographic algorithms are employed:

SSLv3 with AES-256 + SHA1

2.5.4.2 Server host secure session control By default, the Solutions Enabler server accepts only secure sessions from clients. To allow non-secure sessions from clients that cannot, or are not configured to negotiate secure sessions, do one of the following:

• To accept both secure and non-secure sessions, change the following setting to ANY in the daemon_options file in <SYMAPI_HOME>/config:

storsrvd:security_level = ANY

• To accept only non-secure sessions, change the following setting to NONSECURE in the daemon_options file in <SYMAPI_HOME>/config:

storsrvd:security_level = NONSECURE

Important: You can also use the options file to specify the security level for a server, as explained in Section 2.5.5 on page 17. The security level value in the daemon_options file always takes precedence over the security level setting in the options file. If this setting is not in the daemon_options file but is in the options file, the server issues message ANR149D, indicating the options file security level was used.

EMC Corporation


2.5.4.3 Client host secure session control By default, the Solutions Enabler client attempts to negotiate a secure session with the server when both are capable of doing so. On client hosts, do one of the following to allow non-secure sessions with a server that cannot:

• To require a client to negotiate non-secure sessions to all servers, change the following setting to NONSECURE in the options file in <SYMAPI_HOME>/config:

SYMAPI_SERVER_SECURITY_LEVEL = NONSECURE

• To allow a mix of secure and non-secure sessions to servers, depending on the capability of the server, change the following setting to ANY in the options file in <SYMAPI_HOME>/config:

SYMAPI_SERVER_SECURITY_LEVEL = ANY

To configure the session security for specific server hosts, specify NONSECURE or ANY in the<SYMAPI_HOME>/config/netcnfg file for the server in question. This file maps service names to server host names (or IP addresses) and port numbers for Solutions Enabler SYMCLI commands.

The format of records in the netcnfg file is as follows:

<ServiceName> - TCPIP <HostName> <IP-Address> <Port> <SecurityLevel>

Where:

<ServiceName> is the name by which the server is known. This is the same value used by the SYMCLI_CONNECT environment variable for SYMCLI commands.

<HostName> is the name of the host on which the server resides. Specify either <HostName> or <IP-Address>.

<IP-Address> is the IP address of the server. Specify either <HostName> or <IP-Address>.

<Port> is the port number (default 2707) on which the server is listening.

<SecurityLevel> is one of three security levels: SECURE negotiates secure sessions, NONSECURE negotiates non-secure sessions, and ANY negotiates both secure and non-secure sessions. If you do not specify a security level, ANY is used for secure-capable platforms and NONSECURE is used for secure-incapable platforms, depending on the configuration of the server.

Important: The security level specified in <SYMAPI_HOME>/config/netcnfg takes precedence over the one in the options file.

2.5.4.4 Certificate management and validation Solutions Enabler installs a root certificate and key for use in generating subject certificates that identify client and server hosts. The installation process automatically generates a subject certificate for the host on which the install is executed. The generated certificates can be replaced with certificates you generate or that are issued to you by a commercial Certificate Authority (CA).

Subject certificates are generated for both client and server hosts, and the single-generated certificate/key pair typically is for both the client and the server. By default, during secure session negotiation, both the client and the server validate the certificate of the peer. The client always validates the server’s certificate, and you cannot disable this validation when a secure session is negotiated.

EMC Corporation


However, you can configure a server to bypass the validation of a client certificate. To disable such a validation, set the security_clt_secure_lvl statement to NOVERIFY in the daemon_options file in <SYMAPI_HOME>/…

storsrvd:security_clt_secure_level = NOVERIFY

To enable a server to validate client certificates, set the security_clt_secure_lvl statement to VERIFY in the daemon_options file in <SYMAPI_HOME>/…

storsrvd:security_clt_secure_level = VERIFY

Section 2.5.5 on page 17 provides a summary of the values of the security_clt_secure_lvl statement. Note that the server does not require a client certificate if the client is running a version of Solutions Enabler that is incapable of sending one. For additional information, refer to the EMC Solutions Enabler Installation Guide.

2.5.5 Secure session settings summary The following table provides a summary of the secure session settings:

Option name, possible values, and location Description

storsrvd:security_level = SECURE | NONSECURE | ANY <SYMAPI_HOME>/config/deamon_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.

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

storsrvd:security_clt_secure_lvl = MUSTVERIFY | VERIFY | NOVERIFY <SYMAPI_HOME>/config/daemon_options

On server hosts: Controls how the server validates client certificates.

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

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

NOVERIFY: The server does not verify client certificates.

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

EMC Corporation


SYMAPI_SERVER_SECURITY_LEVEL= SECURE | NONSECURE | ANY <SYMAPI_HOME>/config/options

On client hosts: Controls whether clients establish a secure session.

On server hosts: Controls whether servers establish a secure session if the security level option in the daemon_options file is not set (refer to Section 2.5.4.2 on page 15).

This defaults to SECURE.

2.6 Data security 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 impacted.

File location Description

<SYMAPI_HOME>/config/emcpwddb.dat Stores connectivity information—including user names and passwords—used to interact with CLARiiON storage arrays and VMware/Hyper-V Virtual Infrastructure Services.

It is managed via the symcfg authorization SYMCLI command.

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

<SYMAPI_HOME>/config/lockboxp <SYMAPI_HOME>/config/lockboxb

These encrypted files (two copies: a primary and backup) contain security keys including encryption keys used by Solutions Enabler on this host.

These files are encrypted to protect its contents and prevent tampering.

<SYMAPI_HOME>/db/symapi_db.bin This is the Solutions Enabler database file. When managing CLARiiON arrays, connectivity information–including user names and passwords–may be stored here if the user performs actions requiring it. If present, these passwords are encrypted to protect them and prevent tampering.

EMC Corporation


2.7 Other security considerations

2.7.1 Daemon processes on UNIX Solutions Enabler uses a number of helper daemon processes: storapid, storsrmd, storsrvd, storgnsd, storrdfd, storevntd, storwatchd. On UNIX, these daemons run as root by default as a result of their executables being marked setuid-to-root.

The storsrvd, storgnsd, storevntd, and storwatchd daemons can optionally be configured to run as an identity other than root. This can be set during Solutions Enabler installation using the -daemonuid=Name option, which, when used with the -silent option changes ownership of daemons to non-root user, or post-install using the stordaemon command. For information on which daemons are affected by this option, refer to the stordaemon man page. For example, the following command configures the GNS daemon to run under the bin user account:

stordaemon setuser storgnsd -user bin

For example, the following command configures all daemons to run under the bin user account: stordaemon setuser all -user bin

For additional information, refer to the stordaemon man page. Also refer to the <SYMAPI_HOME>/config/README.daemon_users file that is installed with Solutions Enabler.

2.7.2 Securing directories for daemon processes The Solutions Enabler daemons can run with setuid-to-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 these daemon processes. This can present security vulnerabilities in situations where a user through a CLI or some other application provides a pathname on which one of the SE daemons can operate, such as a backup file to be written to or read from.

To prevent these security vulnerabilities for daemons running as root, you can specify a list of secure directories in which these daemons can read, write, and execute files. Since there are mechanisms already in place to protect the Solutions Enabler database and log file locations, this can protect other operations, such as backups and restores.

Note: This feature is most useful when applied to the Solutions Enabler server daemon, storsrvd, since it runs as root (or administrator), and can operate on files on behalf of client users.

2.7.2.1 Specifying a secure directory path Review the following before specifying a secure_directory_path for a daemon process running as root:

• The supplied pathname directories must exist when the daemon is started or the daemon_options file is reloaded. The nonexistent paths are ignored. All sub-directories below the specified directories are also treated as being secure.

• A total of 32 secure directory locations can be maintained.

• Once storsrvd 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 storsrvd is running by editing the daemon_options file and reloading it using the command stordaemon action storsrvd –cmd reload.

EMC Corporation


• If the secure_directory_path option is not present, the behavior is as it was before SE 7.4, (in other words, no security checks are performed).

• The secure_directory_path option does not apply to the following pathnames:

o Pathnames provided in the options or daemon_options files. These files are assumed to be protected by an administrator.

o Pathnames accessed (read or written) by the SYMCLI itself. In client/server mode, these occur under the identity of the user and are not a security risk.

o 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.

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

To apply the secure_directory_path to the storsrvd daemon:

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

2.7.2.1.2 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 the directory name.

To apply the secure_directory_path to the storsrvd daemon:

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

2.7.2.1.3 Listing secure directories To display a list of secure directories in effect for the storsrvd daemon:

stordaemon getvar storsrvd –name secure_directory_path

2.7.3 Securing Solutions Enabler configuration files Solutions Enabler stores its configuration files in the following directory:

<SYMAPI_HOME>/config

Protect the files in the config directory by making sure only authorized Solutions Enabler administrators have write access to this directory.

EMC Corporation


2.7.4 Running commands as a non-privileged use Following 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:

<SYMAPI_HOME>/config/db/

Similarly, non-root users on UNIX and non-administrators on Windows must be authorized to explicitly (via stordaemon) or implicitly (via ordinary commands) make use of the Solutions Enabler daemons. This is done by adding an entry for a specific user in the file <SYMAPI_HOME>/config/daemon_users. For example:

# 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*

For additional information, refer to the <SYMAPI_HOME>/config/README.daemon_users file installed with Solutions Enabler.

EMC Corporation


3 Secure deployment and usage

3.1 Guidelines for securely deploying Solutions Enabler • Protect the <SYMAPI_HOME>/config directory and its contents so that only appropriate

administrators have write access. [Section 2.7.3 on page 20]

• If running SYMCLI commands as a non-root user (non-administrator on Windows), add those users to the daemon_users file as appropriate. Also protect the <SYMAPI_HOME>/db directory to grant them access. [Section 2.7.4 on page 21]

• To limit the amount of disk space used by Solutions Enabler log files, arrange for these files to be cleaned up automatically after some period of time. [Section 2.4.2 on page 11]

• Use Symmetrix access control and/or Symmetrix user authorization to restrict which hosts and users may perform management operations. [Section 2.2 on page 5 and Section 2.3 on page 9]

• When using access control, obtain an access ID using the hardware-based or the recommended alternate access ID operation. [Section 2.2.1 on page 5]

3.1.1 Securely enabling client/server operations • If a Firewall or NAT router exists between client and server hosts, you may need to

configure specific ports and allow those to pass through. [Section 2.5.1 on page 12]

• If you need to disable client/server secure sessions for some or all client hosts, change the security level settings. [Section 2.5.5 on page 17]

• For improved network security, replace the generated SSL certificates on the server side with your own certificates [Section 2.5.4.4 and the EMC Solutions Enabler Installation Guide]

• On server hosts:

o Arrange for the storsrvd daemon to automatically start by the operating system. [Section 2.5.3.1 on page 13]

o If necessary, modify the port on which the storsrvd daemon listens. [Section 2.5.2 on page 13]

o If you want to limit the set of client hosts that the server will accept connections from, configure the nethost file. [Section 2.5.3.2 on page 14]

o If you want to limit functionality that the server makes available to remote client hosts, configure the specific options. [Section 2.5.3.3 on page 14, for z/OS Section 2.5.3.3.1 on page 15]

o UNIX only: Since the storsrvd daemon is network facing, consider having it run as something other than root. [Section 2.7.1 on page 19]

o Secure directories for the storsrvd daemon. [Section 2.7.2 on page 19]

• On client hosts:

o For SYMCLI users, modify the netcnfg file with the host names or IP addresses of your servers. [Section 2.5.2 on page 13 and Section 2.5.4.3 on page 16]

o If using asynchronous events through the event daemon, modify the port on which the client event daemon listens. [Section 2.5.1 on page 12]

EMC Corporation


4 Secure maintenance

4.1 Backup of Solutions Enabler state Backup the following directories and their contents to preserve the Solutions Enabler configuration on a host:

<SYMAPI_HOME>/config <SYMAPI_HOME>/db

The other directories under <SYMAPI_HOME> contain less critical data that is recreated by Solutions Enabler as needed.

Date post:	02-May-2018
Category:	Documents
Upload:	truongdat
View:	239 times
Download:	2 times

Solutions Enabler Security Configuration Guide · Security Configuration Guide . ... operations...

Documents