advertisement
CHAPTER 2
Access Control
This chapter describes a variety of access control features implemented on the VNX for file/unified and VNX for block systems.
Topics include: l l l l l l l l l
...................................................................................... 16
Security for management access
........................................................................16
.................................................................................................... 17
..................................................................................................... 22
............................................................................... 25
........................................................................................ 27
................................................................................................. 27
.................................................................................. 28
Login banner and message of the day
................................................................ 28
Access Control 15
Access Control
Access control settings
Unisphere programs use different strategies to authenticate users; this prevents unauthorized users from accessing VNX systems. These strategies are described in the following sections.
Both Unisphere and CLI provide the same level of security with encrypted, authenticated communications.
Security for management access
On any VNX storage system, the following management applications can be used to access the system: l l l l l l l
Unisphere - One of the two main applications you use to configure, monitor, and manage VNX systems. Unisphere is a web-based GUI that can be launched by pointing the browser to the IP address of either the Control Station or the Storage
Processors (SPs).
Command Line Interface (CLI) - The other main program you use to manage VNX systems. The CLI is separate for block and file services. Block CLI can be installed and run from any host that has network connectivity to the VNX. File CLI can be accessed by opening a remote session to the Control station using SSH.
Unisphere Service Manager (USM) - This software allows you to update, install and maintain VNX system hardware and software as well as provide contact and system information to your service provider.
Unisphere Host Agent or server utility - These optional software programs run on
SAN-attached hosts. Their main function is to help communicate host attributes and LUN/volume mappings to the storage system.
Unisphere Initialization Utility - This optional software allows you to initialize VNX for block systems and network settings from a workstation.
VNX Installation Assistant (VIA) - This software allows you to initialize VNX unified
(block and file) and VNX for file systems and network settings from a workstation.
SNMP management software - This optional software allows you to monitor the state of VNX systems.
l l
Admsnap and admhost - These optional management utilities help you manage
SnapView
™
and SAN Copy
™
replication objects.
Remote support services - Remote EMC support is available for VNX systems.
Many customers use this customer service software to allow EMC to help them configure and monitor their systems.
l
Unisphere Server software - This software executes the storage management functions described in this guide. In this guide, this software is also called the storage management server. This software is pre-installed on VNX SPs and
Control Station. This software can optionally be installed on Windows XP or
Windows Server.
As shown in
VNX Management components , the various components communicate
with the VNX system by both in-band and out-of-band. In-band communication travels over the data connection to the VNX system, while out-of-band communication travels over the management connection to the VNX system.
16 VNX1, VNX2 Security Configuration Guide for VNX
Figure 1 VNX Management components
Access Control
It is imperative that management access to the VNX is controlled and limited to authorized users and applications. To secure management access, VNX implements the following main functions: l l l l l
Authentication - Identify who is making a request.
Authorization - Determine if the requestor has the right to exercise the request.
Privacy - Protect against snooping of data.
Trust - Verify the identity of communicating parties.
Audit - Keep a record of who did what, and when.
Authentication
Management applications on a VNX system use authentication to prevent unauthorized users from accessing the system.
Unisphere authentication
Unisphere authenticates users by using usernames and passwords. In Unisphere, the administrator can create user accounts with easy-to-use dialog boxes. When you connect to Unisphere through the browser on your computer, a Java applet is delivered to your browser. The applet establishes a secure connection over SSL/TLS with the storage management server (software that executes the storage management functions) on the VNX through port 443.
Note
Even though https:// is not displayed in the browser, the connection is secure.
EMC recommends that you connect to Unisphere through https://<vnx_ip> (port
443), although for VNX for block it is possible to connect through http://<vnx_ip>
(port 80).
Authentication 17
Access Control
Note
On a Control Station, all HTTP management traffic directed to port 80 will be redirected automatically to the HTTPS port (443).
When you start a session, Unisphere prompts you for a username, password, and scope (local, global, or LDAP). These credentials are encrypted and sent to the storage management server. The storage management server then attempts to find a match within the user account information. If a match is found, you are identified as an authenticated user.
Note
If authentication fails, you can attempt to retry authenticating from the same IP address a maximum of six times. If the sixth attempt fails, the system will block any authentication attempt from the same IP address for four minutes; that is, the system will not respond to another attempt for four minutes. The failure count clears when an initial authentication succeeds or a new authentication attempt succeeds four minutes after the previous failures.
With the exception of VNX gateways, the storage management server also uses authentication and encryption when communicating with other storage management servers. Communication between storage management servers occurs when information is replicated throughout the domain. For example, when user account information changes, the information is replicated to each instance of the storage management server in the domain.
VNX for block CLI authentication
VNX for block CLI requires that user credentials be passed with each command. You can provide user credentials in either of the following ways: l l
You can provide credentials with each command.
You can use the addusersecurity command to create a file on the host that stores user credentials. If you enter a VNX for block CLI command without credentials, the CLI gets your credentials from this file and sends your credentials with the command.
If you do not explicitly include your credentials with CLI commands, this security file must contain valid Unisphere credentials. This file is stored in your home directory and its contents are encrypted. This file and its encryption key are protected by access control lists (ACLs) and a machine-specific pass phrase.
VNX for file CLI authentication
For VNX for file CLI, you need to connect by remote terminal using SSH into the
Control Station and log in to the Control station using either a local or global account, or an account with LDAP authentication using SSH. There are two default local
accounts on the Control Station (discussed in Default accounts ) or you can create a
new local account for this purpose.
Logging in to the system using the Control Station CLI
When a domain-mapped user logs in to the Control Station CLI, the domain name provided must match the domain name or fully qualified domain name known to VNX
OE for File.
The supported domain-mapped user login formats for LDAP domain-mapped users are:
18 VNX1, VNX2 Security Configuration Guide for VNX
Access Control l l
<domain name>\<user> (for example, mycompany\anne)
<user>@<domain name> (for example, anne@mycompany)
The domain name can be specified as the fully qualified domain name. For example: l l
<fully qualified domain name>\<user> (for example, mycompany.com\anne)
<user>@<fully qualified domain name> (for example, [email protected])
Note
Users can only log in under a single domain. Consequently, mycompany and mycompany.com are treated as the same domain.
The supported domain-mapped user login formats for storage domain-mapped users are: l l storageDomain\<user> (for example, storageDomain\anne)
<user>@storageDomain (for example, anne@storageDomain)
Note
storageDomain is a case-sensitive keyword, not a variable, and you must type it exactly as shown.
User scope
User accounts on a storage management server can have one of three scopes: l l l
Local - This user can access only a single VNX.
Global - This user can access the entire Unisphere domain.
LDAP - This user has an account in the LDAP directory, and can access any storage system that uses the LDAP server to authenticate users.
The local scope is ideal when access to a single VNX is required. Users with global scope are easier to manage because you can use one account to access all VNX storage systems within a Unisphere domain. Users with LDAP scope are the most flexible because the accounts are not specific to the storage systems.
There may be duplicate usernames with different scopes. For example, a user "Sarah" with a global scope is different from a user "Sarah" with an LDAP scope.
Authentication with LDAP or Active Directory
The storage management server can authenticate users against directory servers, such as Active Directory (Active Directory is Microsoft's directory server), using
LDAP or LDAPS. Authentication against an LDAP server simplifies management because you do not need a separate set of credentials for VNX storage system management. It is also more secure because enterprise password policies can be enforced identically for the storage environment and the server environment.
Managing an LDAP Domain (file/unified and block)
In a VNX domain, the same LDAP server is used for both file/unified and block setup.
To manage an LDAP domain, log in to Unisphere and use All Sysems > Domains >
Users (task list) > Manage LDAP Domain to define server connections, accept or validate the related certificates, and map user group roles. As an alternative method, you can select a system, and then use Settings > Security Settings (task list) >
Manage LDAP Domain. After this one-time setup, logins to Unisphere or CLI can be authenticated with an LDAP account. For more information about how to set up connection to an LDAP server, refer to the Unisphere online help.
User scope 19
Access Control
LDAP service configuration options
Before Unisphere or CLI can authenticate LDAP users, it must be configured to communicate with the LDAP service. Unisphere allows you to add the IP addresses and LDAP connection parameters of the LDAP servers. You will need to obtain the
LDAP connection parameters from the LDAP service administrator. When configuring the LDAP service in Unisphere, note the following best practices: l l
For highly available communications with the LDAP service, create service connections with two LDAP servers. If one of the servers is unavailable, the storage management server will send the authentication request to the secondary
LDAP server.
For the highest levels of security, configure the service connections to use the
LDAPS protocol if your LDAP server supports it. This will ensure that all communication between the storage management server and the LDAP server is encrypted with SSL/TLS so that no user credentials are sent in plain text.
The LDAP configuration needs to be performed only once for each Unisphere domain; the configuration will be replicated to all other nodes within the domain.
Role mapping
Managing an LDAP Domain (gateway)
To manage an LDAP configuration for a VNX gateway system, log in to Unisphere and select your system, and then use Settings > Security Settings (task list) > Manage
LDAP Domain to configure the Control Station so it can access the LDAP-based directory server. For more information about how to set up connection to an LDAP server, refer to the Unisphere online help.
After this one-time setup, where Unisphere is configured with connection information for the LDAP server and Unisphere roles are mapped to LDAP groups, logins to
Unisphere or CLI can be authenticated with an LDAP account. For a VNX gateway system, LDAP configuration information is specific to the VNX gateway system and is not replicated to any other system.
Once communications are established with the LDAP service, specific LDAP groups must be given access to Unisphere by mapping them to Unisphere roles. The LDAP service only performs the authentication. Once authenticated, the user's authorization is determined by the assigned Unisphere role. The most flexible configuration is to create LDAP groups that correspond to Unisphere roles. This allows you to control access to Unisphere by managing the members of the LDAP groups.
Note
LDAP user level role mapping that is related to storage processors (SPs) and
Unisphere roles can be configured by using the VNX for block CLI. See the VNX
Command Line Interface (CLI) Reference for Block for more information.
For example, assume that there is an LDAP group called "Storage Admins" of which
Bob and Sarah are members. Another LDAP group exists called "Storage Monitors" of which Mike and Cathy are members. The "Storage Admins" group can be mapped to the Unisphere Administrator role, giving Bob and Sarah full control of the storage systems. The "Storage Monitors" group can be mapped to the Unisphere Operator role, giving Mike and Cathy read-only access to the storage systems. If six months later Mike becomes a more trusted administrator, he can be given full access to the storage systems (Administrator role) simply by adding him to the "Storage Admins"
LDAP group.
20 VNX1, VNX2 Security Configuration Guide for VNX
Access Control
Credential caching and account synchronization (block)
The storage management server locally caches credentials for an LDAP user once the user has been authenticated. This caching minimizes traffic to the LDAP service and enhances the user experience by eliminating latency due to authentication requests.
Keep in mind that the storage management server authenticates all commands that modify the storage system configuration and not just at login. Caching eliminates redundant authorization requests to the LDAP server.
By default, Unisphere will clear the local cache every 24 hours to force synchronization with the accounts on the LDAP server. In an environment where user accounts are changing often and credentials need to be flushed, this synchronization interval may be tuned down to 30 minutes without noticeable performance impact.
Alternatively, manual synchronization forces an immediate clearing of the local cache.
This is useful if an employee is terminated and their access to the storage system needs to be removed in a timely fashion.
Default accounts
Default accounts exist for management access and service access.
Default Management Accounts - See Authentication configuration
for information on default management accounts and how to change the related passwords.
Default Service Accounts - Default combinations exist for the management port and service port for access by EMC service personnel. EMC strongly encourages you to
change the management port username/password combination (see Secure serviceability settings (block)
for more details). Service personnel will need the username and password, so be prepared to disclose this information.
Authentication configuration
Security is initialized differently for VNX unified/file and VNX for block systems.
VNX unified/file systems will have the following management accounts factory installed: l l root - This is a VNX for file local account and provides root-level privileges on the control station.
nasadmin - This is a VNX for file local account and provides administrator level privileges on the control station.
l sysadmin - This is a global system account and provides administrator level privileges for both VNX for file and VNX for block.
A system account is a special global account that is needed for internal communication between block and file services. VNX unified/file systems require at least one system account. You cannot delete this system account unless another global administrator account or global security administrator account is available.
VNX Installation Assistant (VIA) is the utility for initializing VNX unified/file systems.
EMC recommends to change the default password for the three accounts when first initializing a VNX unified/file system using VIA.
VNX for block systems do not have any default management accounts. The Unisphere
Initialization wizard is the utility used for initializing VNX for block systems. Security can be initialized on VNX for block systems in the following ways: l l
User can choose to create a global account when initializing the system using
Unisphere Initialization wizard.
User can create a global account when first logging into Unisphere.
Default accounts 21
Access Control
A system account is not created by default on VNX for block systems because it is not needed; however, adding another VNX unified/file system to the VNX for block system's local domain would require a system account and the user will be prompted accordingly to create a system account.
For all VNX systems (VNX unified/file and VNX for block), at least one global account is required. This account must have the "administrator" or "security administrator" role. An LDAP server(s) can be configured if LDAP authentication is desired, and other global or local accounts can also be created.
Security functions having to do with configuring authentication can be performed either from Unisphere or secure CLI.
User actions performed without authentication
VNX systems will not permit any actions without authentication.
Component authentication (block)
SCSI's primary authentication mechanism for iSCSI initiators is the Challenge
Handshake Authentication Protocol (CHAP). CHAP is an authentication protocol that is used to authenticate iSCSI initiators at target login and at various random times during a connection. CHAP security consists of a username and password. You can configure and enable CHAP security for initiators and for targets. Log in to Unisphere and use All Systems > System List and right-click the entry for the storage system for which you want to configure CHAP, then use > iSCSI > CHAP Management. To enable CHAP, select your system and then use Settings > Network > Settings for
Block. For more information on configuring and enabling CHAP, refer to the Unisphere online help.
The CHAP protocol requires initiator authentication. Target authentication (mutual
CHAP) is optional.
Authorization
The Storage Management Server authorizes user activity based on the role of the user. A role is a collection of access privileges that provides the account administrator with a simple tool for assigning access rights. Unisphere and VNX for file CLI authorize user activity based on the role of the user. VXN for block CLI is based on user credential authentication. Unisphere roles include eight main roles (Operator, Network
Administrator, NAS Administrator, SAN Administrator, Storage Administrator,
Administrator, Security Administrator, and VM Administrator) and three Data
Protection roles (Local Data Protection, Data Protection and Data Recovery).
Note
The main Unisphere roles and data protection roles can have global or local scopes.
Main Unisphere roles
The main roles include: l l
Operator - Read-only privilege for storage and domain operations; no privilege for security operations.
Network Administrator - All operator privileges and privileges to configure DNS, IP settings, and SNMP.
22 VNX1, VNX2 Security Configuration Guide for VNX
Access Control l l l l l l
NAS Administrator - Full privileges for file operations. Operator privileges for block and security operations.
SAN Administrator - Full privileges for block operations. Operator privileges for file and security operations.
Storage Administrator - Full privileges for file and block operations. Operator privileges for security operations.
Security Administrator - Full privileges for security operations including domains.
Operator privileges for file and block operations.
Administrator - Full privileges for file, block, and security operations. This role is the most privileged role.
VM Administrator - Enables you to view and monitor basic storage components of your VNX system through vCenter by using VMware's vSphere Storage APIs for
Storage Awareness (VASA).
Note
The combination of Security Administrator and Storage Administrator privileges is equivalent to those of an Administrator.
As a security and system integrity best practice, superusers (administrators in
Unisphere) should not run with full administrative privileges for day-to-day operations.
The security administrator role should be used to segment authorized actions between separate accounts. By dividing administrative privileges into security administrator and storage administrator roles, storage administrator accounts will be authorized only to perform storage related actions, and security administrator accounts will only be authorized to perform domain and security related functions. With the security administrator role, accounts with full administrative privileges can be reduced to one and duties can be separated for day-to-day operations.
Unisphere requires the creation of user accounts, where a user account is identified as the unique combination of username, role, and scope. This ability provides flexibility in setting up user accounts. It is expected that most IT personnel will be assigned a global operator account so they can monitor every storage system in the domain. Also, they can be assigned local storage administrator accounts for each specific storage system they are authorized to configure.
You can create global user accounts, each with privileges appropriate to their responsibilities. To create new global user accounts in your local domain, log in to
Unisphere and use All Systems > Domains > Users (task list) > Manage Global
Users. Alternatively, select your system, and then use Settings > Security > User
Management (task list) Global Users. You can only access the global users feature from Settings if your selected system is a system in your local domain.
You can create local user accounts for file and block systems, each with privileges appropriate to their responsibilities. A local user for block can only manage block features on the local system. Similarly, a local user for file can only manage file server features on the local system. To create new local user accounts for block, log in to
Unisphere and select your VNX for block system, and then use Settings > User
Management (task list) Local Users for Block. To create new local user accounts for file, log in to Unisphere and select your VNX for file system, and then use Settings >
User Management (task list) Local Users for File.
For more information on creating user accounts, refer to the Unisphere online help.
Data Protection roles
Data Protection (Replication) tasks are often performed by third-party personnel. In the earlier releases, a user needed storage administrator-level privileges to perform
Data Protection roles 23
Access Control
24 data protection tasks; however, allowing third-party personnel this level of access could pose a security threat. To solve this problem, VNX systems have three Data
Protection roles:
Note
None of these roles allows the user to create new data protection objects such as snapshots, clones, SAN Copy sessions, or mirrors. The user can control only existing data protection objects. Users can view the domain for objects that they cannot control; this allows them to have a fuller understanding of their environment.
l l
Local Data Protection - Has privileges only to do SnapView (snapshots and clones) and Snapsure (Checkpoints) tasks; however, data recovery operations like rollback a snapshot or reverse synchronize a clone are not allowed. Also, this role does not have privilege to create new storage objects.
Data Protection - Includes all local data protection privileges, MirrorView, and SAN
Copy tasks; however, data recovery tasks such as promoting a secondary and fracturing a mirror are not allowed. Also, this role does not have privilege to create new storage objects.
l
Data Recovery - Includes all local data protection and data-protection role privileges and the ability to do data recovery tasks; however, this role does not have privilege to create new storage objects.
Capabilities of data protection roles
lists the data protection tasks and which roles have privilege to perform those tasks.
VNX for File CLI role-based access provides
detailed information about how role-based access is used to determine which of the
VNX for file CLI commands (task) a particular user can execute.
Table 2 Capabilities of data protection roles
Task Local data protection
Snapview
Start a (consistent) snap session
Stop a (consistent) snap session
Activate a session to a snapshot
LUN
Deactivate a session from a snapshot LUN
Synchronize a clone
Fracture a clone
Roll back a snap session
Reverse synchronize a clone
Mirrorview
Synchronize a mirror / consistency group
Fracture a mirror / consistency group
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Data protection
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
No
Data recovery
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
VNX1, VNX2 Security Configuration Guide for VNX
Access Control
Table 2 Capabilities of data protection roles (continued)
Task
Control the update parameters of an asynchronous mirror
Modify the update frequency of an asynchronous mirror
Throttle a mirror / consistency group
Promote a synchronous or asynchronous secondary mirror / consistency group
SAN Copy
Start a session
Stop a session
Pause a session
Resume a session
Mark a session
Unmark a session
Verify a session
Throttle a session
No
No
No
No
No
No
No
No
No
No
No
Local data protection
No
Data protection
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Data recovery
Yes
Yes
Yes
Yes
Component access controls
Component access control settings define access to the product by external and internal systems or components.
Component authorization
A storage group is an access control mechanism for LUNs. It segregates groups of
LUNs from access by specific hosts. When you configure a storage group, you identify a set of LUNs that will be used by only one or more hosts. The storage system then enforces access to the LUNs from the host. The LUNs are presented only to the hosts in the storage group, and the hosts can see only the LUNs in the group (LUN masking). To configure a storage group, select your system and then use Host >
Storage Groups. For more information on configuring a storage group, refer to the
Unisphere online help.
IP filtering adds another layer of security by allowing administrators and security administrators to configure the storage system to restrict administration access to specified IP addresses. These settings can be applied to the local storage system or to the entire domain of storage systems. See
Secure serviceability settings (block) for
more details about IP filtering.
Component access controls 25
Access Control
VNX for file CLI role-based access
The administrative user account you use to access the command line interface is associated with specific privileges, also referred to as roles. A role defines the privileges (operations) a user can perform on a particular VNX object. The ability to select a predefined role or define a custom role that gives a user certain privileges is supported for users who access VNX through the CLI, EMC Unisphere
™
, and the XML
API.
VNX for File CLI role-based access provides detailed information about how role-
based access is used to determine which of the VNX for file CLI commands a particular user can execute.
Windows-styled credentials for UNIX users
VNX for file allows you to create a common Windows-style (NT) credential. Users therefore have the same credentials regardless of their file access protocol, providing more consistent access control. Managing a Multiprotocol Environment on VNX describes how to configure this feature.
Protecting session tokens
The connection between a user and Unisphere and between two VNX for file systems uses SHA1 to generate checksums to protect the session tokens (cookies) that identify users after they log in. The SHA1 secret value used to generate the checksums is set at random during installation; however, to enhance security, you can change the default SHA1 secret value. When you change this value, existing session tokens (cookies) are no longer valid and current users of Unisphere will have to log in again. You must be root to modify Control Station properties. Refer to
Protect session tokens for detailed information.
CIFS Kerberos authentication
By default, VNX for file allows both Kerberos and NTLM authentication. Since
Kerberos is now the recommended authentication method in Windows environments, you may want to disable NTLM authentication. The server_cifs man page describes how to configure this setting and Configuring and Managing CIFS on VNX describes authentication.
NFS security settings
Although generally regarded as a vulnerable file-sharing protocol, you can make NFS more secure by using the following configuration settings: l l l
Defining read-only access for some (or all) hosts
Limiting root access to specific systems or subnets
Hiding export and mount information if a client does not have mount permissions for the file system corresponding to that entry
In addition, if strong authentication is required, you can configure Secure NFS, which uses Kerberos. Configuring NFS on VNX describes how to configure these settings.
All NFS exports are displayed by default. To hide NFS exports, you must change the value of the forceFullShowmount for mount facility parameter using the server_param command.
26 VNX1, VNX2 Security Configuration Guide for VNX
Access Control
Access policies for NFS and CIFS
The VNX for file set of customizable access modes allow you to choose the best possible interaction between NFS and CIFS access for your environment. Managing a
Multiprotocol Environment on VNX describes how to configure this feature.
You can select how security attributes are maintained and the type of interaction between NFS and CIFS users including: l l l
NATIVE
UNIX
NT l l
SECURE
MIXED l
MIXED_COMPAT
The MIXED access policy is required when using NFSv4.
Data security settings
Data security settings enable definition of controls to prevent data permanently stored by the product to be disclosed in an unauthorized manner.
Data integrity
VNX systems use several proprietary data integrity features to protect customer data on the system.
Encryption of data at rest
For information concerning the Data at Rest Encryption (D@RE) feature which is pertinent only to VNX systems running VNX operating environment (OE) for Block
versions 5.33 and later, see Data Security Settings
.
For more information about encryption of data at rest, please see the document
Approaches for Encryption of Data-At-Rest in the Enterprise on the EMC Online Support website at http://Support.EMC.com
.
Password policy
Strong passwords are an important element of a security strategy. To ensure that sufficiently strong passwords are chosen by all VNX for file local users, you can define a password quality policy that enforces a certain complexity for user-defined passwords. This feature does not apply to domain-mapped users, whose passwords are governed by policies within the domain.
The default password policy includes the following requirements: l l l l
A minimum password length of 8 characters
A maximum of 3 attempts to define a new password of acceptable value before the command fails
A minimum of 3 characters that were not in the previous password
A minimum of one numeral in the new password
Access policies for NFS and CIFS 27
Access Control
Note
There is currently no requirement to use special characters (such as !, @, #, $, %, &,
^, and *) or lower and uppercase characters in the password.
VNX for file also supports a default password expiration period of 120 days.
Note
Changes made to the password quality policy apply only to a password defined after the policy is revised.
Physical security controls
The area where the storage systems reside should be chosen or configured to provide physical security for the VNX systems. These include 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.
In addition, the serial port connection requires particular care. EMC and our service partners are capable of enabling emergency access with a serial connection to the storage processor. The customer is responsible for managing the authorized access to the management port as described in
Secure serviceability settings (block)
as well as for locating the storage system in a physically secure environment. This includes appropriate protection of physical access to the storage processor including the serial port for emergency service.
Restricting anonymous root login on the serial console and SSH enhances system
security on VNX for file/unified systems. See Restrict anonymous root login for more
information.
Protecting the GRUB boot loader with a password increases the security of the system. Setting a password for GRUB requires root access and can be accomplished by logging in to the CLI as the root user. Set the password in the GRUB configuration file. This file is often located in one of several locations; for example, /etc/ grub.conf, or /boot/grub/grub, or /boot/grub/menu.lst. To set a plain-text password, edit your GRUB configuration file by adding the following line before the first uncommented line:
password
<password>
Login banner and message of the day
A login banner and message of the day (MOTD) provide a way for an administrator to communicate with VNX for file users. The same login banner is seen from the command line interface and Unisphere. The MOTD is seen only from the command line interface. You must be root to modify Control Station properties.
To configure the banner through Unisphere, select System > System
Management(task list) > Control Station Properties. You can find a description of this feature in Unisphere online help.
28 VNX1, VNX2 Security Configuration Guide for VNX
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Related manuals
advertisement
Table of contents
- 3 Contents
- 7 Preface
- 9 Introduction
- 10 Overview
- 10 User interface choices
- 10 Terminology
- 12 Related features and functionality information
- 13 Unisphere management suite related white papers
- 15 Access Control
- 16 Access control settings
- 16 Security for management access
- 17 Authentication
- 17 Unisphere authentication
- 18 VNX for block CLI authentication
- 18 VNX for file CLI authentication
- 19 User scope
- 19 Authentication with LDAP or Active Directory
- 21 Default accounts
- 22 User actions performed without authentication
- 22 Component authentication (block)
- 22 Authorization
- 22 Main Unisphere roles
- 23 Data Protection roles
- 25 Component access controls
- 25 Component authorization
- 26 VNX for file CLI role-based access
- 26 Windows-styled credentials for UNIX users
- 26 Protecting session tokens
- 26 CIFS Kerberos authentication
- 26 NFS security settings
- 27 Access policies for NFS and CIFS
- 27 Data security settings
- 27 Data integrity
- 27 Encryption of data at rest
- 27 Password policy
- 28 Physical security controls
- 28 Login banner and message of the day
- 29 Logging
- 30 Log settings
- 30 Audit logging on a VNX for block system
- 31 VNX and RSA Envision
- 31 Auditing on a VNX for file system
- 32 Data at Rest Encryption audit logging
- 33 Communication Security
- 34 Communication security settings
- 34 Port usage
- 34 Ports used by Unisphere components on VNX for block
- 35 How VNX for file works on the network
- 36 Defense in depth
- 36 Network services on VNX for file
- 37 Session timeout on VNX for file
- 37 Private networks
- 37 VNX for file primary network services
- 54 VNX for file outgoing network connections
- 59 Network encryption
- 59 SSL configuration on VNX unified/file systems
- 60 Using HTTPS
- 60 Using SSL with LDAP
- 60 SSL certificates
- 61 Connecting to the directory server using SSL
- 62 Planning considerations for Public Key Infrastructure on VNX for file
- 62 Personas
- 63 Certificate Authority (CA) certificates
- 64 Using the Control Station as the CA
- 64 Customer-Supplied Certificates for Control Station
- 65 IP packet reflect on VNX for file systems
- 65 Effect of filtering management network
- 65 vSphere Storage API for Storage Awareness (VASA) support
- 66 Special configurations
- 66 Proxy servers
- 67 Unisphere client/server and NAT
- 67 Other security considerations
- 69 Data Security Settings
- 70 Data at Rest Encryption overview
- 71 Data at Rest Encryption feature activation
- 72 Rebooting Storage Processors through Unisphere
- 72 Rebooting Storage Processors through VNX OE for Block CLI
- 73 Encryption status
- 73 Backup keystore file
- 74 Data in place upgrade
- 76 Hot spare operations
- 76 Adding a disk drive to a VNX with encryption activated
- 77 Removing a disk drive from a VNX with encryption enabled
- 77 Replacing a chassis and SPs from a VNX with encryption enabled
- 79 Security Maintenance
- 80 ESRS on Control Station
- 80 ESRS Device Client on Storage Processor
- 81 ESRS IP Client
- 82 Secure serviceability settings (block)
- 82 Secure remote support considerations
- 83 Security-patch management
- 83 Malware detection
- 85 Advanced Management Capabilities
- 86 Remote management
- 86 Internet Protocol version 6 (IPv6) addressing for a management port
- 86 Support for VLAN tagging
- 86 SNMP management
- 87 Management support for FIPS 140-2
- 89 Secure deployment and usage settings
- 90 Implementing Unisphere in secure environments
- 93 TSL cipher suites
- 94 Supported TLS cipher suites
- 99 LDAP-based directory server configuration
- 100 Active Directory Users & Computers
- 101 Ldap Admin
- 105 VNX for file CLI role-based access
- 106 CLI role-based access setup
- 115 VNX for file CLI security configuration operations
- 116 Configuring password policy
- 116 Define password policy interactively
- 116 Define specific password policy definitions
- 117 Set password expiration period
- 117 Configuring session timeout
- 118 Change the session timeout value
- 118 Disable session timeout
- 118 Protect session tokens
- 119 Configuring network encryption and authentication using the SSL protocol
- 119 Using HTTPS on VNX for file
- 119 Using SSL with LDAP on VNX for file
- 119 Change the default SSL protocol
- 120 Change the default SSL cipher suite
- 121 Postrequisites
- 121 Configuring PKI
- 121 Creating the certificate provided by the persona
- 121 Using the Control Station as the CA
- 122 Obtaining CA certificates
- 122 Generate a key set and certificate request
- 125 Send the certificate request to the CA
- 126 Import a CA-signed certificate
- 128 List the available CA certificates
- 129 Acquire a CA certificate
- 131 Import a CA certificate
- 132 Generate a new Control Station CA certificate
- 132 Display the certificate
- 134 Distribute the Control Station CA certificate
- 134 Request and Install Customer-Supplied Certificates for Control Station
- 137 Managing PKI
- 138 Display key set and certificate properties
- 138 Check for expired key sets
- 139 Clear key sets
- 139 Display CA certificate properties
- 140 Check for expired CA certificates
- 141 Delete CA certificates
- 141 Customize a login banner
- 142 Create a MOTD
- 142 Restrict anonymous root login
- 143 Locking accounts after a specific number of failed logins
- 145 VNX for block SSL certificate import
- 146 VNX for block SSL certificate requirements
- 146 Adding or changing a Storage Processor SSL certificate using a Web browser
- 147 Adding or changing a Storage Processor SSL certificate using openssl
- 148 Creating SHA2 certificate using openssl
- 151 Index