Security
The IBM PureApplication platform provides a secure environment for deploying and maintaining workloads. Both IBM PureApplication System and IBM PureApplication Software have security models that provide workload and management isolation. In addition, both provide mechanisms to collate workloads from a management perspective, but isolate workloads from a physical and logical perspective. You can use this approach to meet stringent security policies and use the PureApplication platform with sensitive and regulated data.
This chapter provides a look at the facilities that PureApplication System and PureApplication Software provides that you can use to integrate them into your existing security framework.
This chapter covers the following topics:
11.1 System management
The PureApplication System is managed by the PureApplication System Manager (PSM). The PSM is accessible by administrators through the management network connection. On the PureApplication System, this connection is typically through ports 64 of the Top of Rack (TOR) switches. The management connection is not a typical out of band management connection; it is a highly available aggregated link between the rack and the customer data center.
Each PureApplication System has two PSMs, each of which have a static IP address that is accessible over the management network. The leader PSM is assigned a floating IP address. The floating IP address is what administrators typically use to access the system management interface (also known as the system console).
PureApplication Software also has a PSM. The PSM consists of the software stack that is installed on a Red Hat Linux system that is provided by the customer. This PSM is physically isolated from the hypervisors that host deployed workload virtual machines (VMs).
Whether working with PureApplication System or PureApplication Software, the PSM has processes that need access to the VMs for management purposes. Depending on your security needs, this access can be done in a couple of ways.
First, the management node (PSM) talks to VMs through a management Ethernet interface (eth0 or en0) on the VMs. This activity is done on a virtual LAN (VLAN) that is used only within the rack for each cloud group. All communication is done internal to the rack over Internet Protocol version 6 (IPv6) addresses.
If you are on the system and using externally managed cloud groups, you provide IP addresses for cloud management. These IP addresses that are used for cloud management are in separate IP Groups from the data IPs that you use for access to the VMs. Each externally managed cloud group can have multiple external management IP groups. This approach allows VMs within a cloud group to be logically isolated. In this scenario, management traffic from the PSM exits the rack on the management ports and is routed to the VMs through the data ports.
If you are working with PureApplication Software, all VM management traffic goes over the data network. It is possible to have multiple data networks that are defined to achieve the level of logical isolation that you need.
After workload VMs are deployed, they can be managed through the PureApplication System system console. Most middleware patterns provide their own user interface consoles. These consoles can be accessed through the PureApplication System system console or directly. In many enterprises, it is preferable to have a separation of duties between the system and the middleware. Using this approach, the PureApplication workload administrator does not need access to the PureApplication System system console. In fact, they do not need to know where their new environment is hosted.
11.1.1 Management system security
To help protect the integrity and confidentiality of the management system, PureApplication System compute nodes encrypt the data and binary images on the hard disk drive (HDD) and solid-state disk (SSD) by using the Advanced Encryption Standard (AES) encryption algorithm with a 256-bit key size. Encryption keys are not stored on the disk, but are stored instead in the Trusted Platform Module (TPM) on the system management computer circuit board. Configuration data and binary images are not visible to operating system (OS) users. OS users log in to a restricted shell that does not support shell scripts. OS users cannot start or stop OS processes, and they do not have access to file systems.
11.1.2 System console SSL certificates
Hypertext Transfer Protocol Secure (HTTPS) is an internet communication protocol that protects the integrity and confidentiality of data that is transferred between the client and server. The IBM PureApplication platform uses HTTPS to give users access to the system console for performing both administrative and user actions in a secure way.
Instead of using the default Secure Sockets Layer (SSL) certificates that are generated by IBM, as a security administrator, you might prefer to use enterprise SSL certificates of your organization. By doing so, you ensure that the PureApplication platform is in compliance with your corporate security policies.
You can import your system console SSL certificates and keys into the PureApplication platform without any assistance from an IBM service representative. You can also restore the original console SSL certificate and key that was in the system before they were updated.
System console SSL certificates can be imported into the PureApplication platform by using the following mechanisms:
•IBM PureApplication System system console
•IBM PureApplication System command-line interface (pure.cli)
•IBM PureApplication System REST API
This publication shows how to import system console SSL certificates by using the PureApplication System system console. For other configuration methods, such as using CLI or REST API, go to the IBM PureApplication System IBM Knowledge Centers:
•Using the CLI for system management, SSL:
•REST API for system management, SSL:
 
Note: To import SSL certificates into the PureApplication platform, you must be assigned the Security administration role with permission to manage security (Full permission).
To import SSL certificates into the PureApplication platform, complete the following steps:
1. Click System → System Security from the PureApplication System system console.
2. Expand Import Console Certificate and Key (Figure 11-1).
Figure 11-1 Import Console Certificate and Key
3. In the Certificate File field, browse to and select the certificate file to be imported. The certificate file must have a .crt file extension.
The certificate file should be in privacy enhanced mail (PEM) format. PEM is a standard for sending secure email over the Internet. The first few lines of a valid certificate file in PEM format look similar to Example 11-1.
Example 11-1 Beginning of a valid certificate file in privacy enhanced mail format
-----BEGIN CERTIFICATE-----
MIIC9zCCAd8CAmmrMA0GCSqGSIb3DQEBBQUAMEExDDAKBgNVBAoTA0lCTTEYMBYG
4. In the Private Key File field, browse and select the key file to be imported. The key file must have a .key file extension.
The key file should be in PEM format. The first few lines of a valid key file in PEM format should look similar to Example 11-2.
Example 11-2 Beginning of a valid key file in privacy enhanced mail format
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA0RLL5O6Or3PsiigRwekXlibcfw4At6E4vqbdhbAB/ErfV/gi
5. (Optional) You can also restore the original console SSL certificate and key that was in the system before they were updated. To restore the original certificate and key files that were included with the system, select Restore back to original certificate and private key.
6. Click Submit, as shown in Figure 11-2.
Figure 11-2 SSL certificate and private key files selected
7. After you click Submit, the console restarts approximately 10 seconds after the request is completed and the following message displays on the console:
Your settings were changed successfully
8. Click the web browser refresh icon to confirm that PSM is working correctly with the updated SSL certificates.
9. Update the certificate and key on the other PSM. Perform a failover to the other PSM, and repeat steps 1 on page 302 - 8 by using the same certificate and key files.
 
Note: Do not forget to put the system in maintenance mode to prevent compute nodes from temporarily moving to a quiesced state before you initiate a failover. You can perform a PSM failover by using one of the following methods:
•Run a PSM failover command on the leader management node.
•Power off the leader management node from the console.
•Run a PSM restart command on the leader management node (or PSM restart remote from the non-leader management node).
•Soft press the leader PSM on the physical rack.
For more information about user-initiated failover operation, go to the IBM Knowledge Center:
Select the PureApplication System type, such as W2700 2.1.0 → Troubleshooting and support → Using diagnostic tools → PureApplication System Administrative Interface → psm command.
10. Download the CLI interface tool again and connect to PSM to ensure that it is updated with the new certificate and private key file.
 
Note: If you cannot access the console after completing this procedure, contact your IBM service representative.
Updating peer certificates in a multi-system environment
If you are using the PureApplication multi-system setup and updated the SSL certificates in one of the systems in your management domain, you should update the other system’s truststore database with the updated certificates. To do so, complete the following steps:
1. Open the CLI from your client and connect to the node on which you updated the SSL certificates, as shown in Example 11-3.
Example 11-3 Open the CLI from your client and connect to the node on which you updated the SSL certificates
# cd /directory/path/to/purecli/bin directory
# ./pure -h <PureApplication_Management_IP> -u admin
password:
>>
2. Obtain the rack location name (peername), as shown in Example 11-4.
Example 11-4 Rack location name
>>> admin.racks[0].location_name
1000202
3. Open the CLI from your client, and connect to the other node in the multi-rack setup, as shown in Example 11-5.
Example 11-5 Open the PureApplication CLI and connect to the other node
# cd /directory/path/to/purecli/bin directory
# ./pure -h <PureApplication_Management_IP_of_otherNode_in_Multi> -u admin
password:
>>
4. Check the peer certificates on the system, as shown in Example 11-6.
Example 11-6 List the peer certificates on the system
>>> deployer.peercertificate._list()
[
{
"algorithmName": "SHA1withRSA",
"alias": "ipas:1000202",
"issuer": "CN=IBMPureSystems, OU=IBM PureSystems, O=IBM",
"md5": "E19E3E88421D90698D76BEFBB69034B7",
"notAfter": "Mon Mar 06 02:48:52 UTC 2034",
"notBefore": "Tue Mar 11 02:48:52 UTC 2014",
"owner": "CN=IBMPureSystems, OU=IBM PureSystems, O=IBM",
"sha1": "C3DDE64B69BE11D7030B06AF860779A53E9829C8",
"sha256": "08DBD9AEE224CC10427F2B2AD130BE701DFCF8F0F4792D0300E0E53740C3B3EE"
 
}
]
>>>
5. List the peer certificate by name, as shown in Example 11-7.
Example 11-7 List peer certificates
>>> deployer.peercertificate._get(‘1000202’)
{
"algorithmName": "SHA1withRSA",
"alias": "ipas:1000202",
"issuer": "CN=IBMPureSystems, OU=IBM PureSystems, O=IBM",
"md5": "E19E3E88421D90698D76BEFBB69034B7",
"notAfter": "Mon Mar 06 02:48:52 UTC 2034",
"notBefore": "Tue Mar 11 02:48:52 UTC 2014",
"owner": "CN=IBMPureSystems, OU=IBM PureSystems, O=IBM",
"sha1": "C3DDE64B69BE11D7030B06AF860779A53E9829C8",
"sha256": "08DBD9AEE224CC10427F2B2AD130BE701DFCF8F0F4792D0300E0E53740C3B3EE"
}
6. Import the certificate file, as shown in Example 11-8 on page 305.
Example 11-8 Import a peer certificate
>>> deployer.peercertificate._import({’certfilepath’:’C:\RedbooksCert.crt’, ’peername’:’1000202’})
 
11.2 Resource isolation
One key concept of cloud computing is resource sharing. System users or applications all share the resources that are available on the cloud. Resource sharing is also a fundamental requirement for having multi-tenant systems. As a cloud environment, the PureApplication platform is no exception. Resources, such as processors, memory, storage, network, and compute nodes, are all shared among cloud resource consumers. Sharing resources might raise questions of data confidentiality, security, and resource contention. In the PureApplication platform, the system provides secure and protected resources against all of those security threats.
Although resource sharing offers major cost benefits to business, the ability to isolate resources to protect data confidentiality, integrity, and privacy is the main concern of enterprise customers. To provide an environment on which enterprises can have a secure IT environment for their infrastructure and applications, PureApplication System and PureApplication Software provide resource isolation and data segregation through networking, cloud groups, and access control.
From the network perspective, PureApplication System isolates management traffic and customer data traffic by using separate external physical networks. An additional level of resource isolation among deployments is supported through the construction of cloud groups, IP groups, and environment profiles. Figure 11-3 shows the logical and physical resource isolation.
Figure 11-3 Resource Isolation in the PureApplication platform
However, if you are working with PureApplication Software, management traffic goes over the data network. It is possible to have multiple data networks that are defined to achieve the level of logical isolation that you need.
11.2.1 Cloud groups
The PureApplication platform groups computing resources into cloud groups. Cloud groups are a collection of hypervisors, storage, and IP groups. Cloud groups provide physical isolation for workload run times. They allow different application tiers to have dedicated processors.
Different PureApplication users take advantage of cloud groups in unique ways:
•Some clients prefer to isolate workloads based on data classification.
•Other clients prefer to isolate their workloads by line of business or application tier.
•Other clients choose to have large cloud groups with all their applications together.
These customers rely on the logical isolation that PureApplication can provide in concert with its ability to balance dynamically workloads and arbitrate resource contentions with runtime priority settings.
In PureApplication System, cloud groups can be an internally managed cloud group or externally managed cloud group. Figure 11-4 shows those cloud group types.
Figure 11-4 High-level data flow of externally and internally managed cloud groups
When you create a cloud group, you specify whether the cloud is to be managed internally or externally, as shown in Figure 11-5 on page 307.
For internally managed cloud groups, you specify a management VLAN for the cloud group. All VMs that are deployed have an IPv6 address that is generated and assigned for management traffic. For externally managed cloud groups, you provide one or more VLANs for VM management.
Figure 11-5 Describe a new cloud group
When a cloud group is created, the management VLANs are automatically assigned to the correct ports in the TOR switches and chassis switches. In addition, the management VLAN is also added to the Virtual I/O Server (VIOS) (for PureApplication System W1700/2700) or the Distributed Virtual Switches (DVSs) (for PureApplication System W1500/2500).
IBM Knowledge Center has documented instructions for creating and adding cloud groups. For more information about adding cloud groups, see the IBM Knowledge Center at the following website:
Storage isolation is also set up when you create a cloud group. In the PureApplication System, a host group is created and the host bus adapters (HBAs) of the compute nodes are added automatically. In PureApplication Software, the SAN administrator is responsible for ensuring that the host groups are created correctly and that the storage is discoverable by VMware.
11.2.2 IP groups
Whenever the PureApplication platform deploys VMs, it assigns IP addresses to the VMs so that VMs can be reached over the designated network. The PureApplication platform has those IPs assigned to VMs from IP groups.
IP groups are a way of differentiating sets of IPs within a subnet. Subnets are useful because you can use them to provision firewall rules for a group of IPs ahead of time so that they are ready for use when needed. By having extra IPs in a pool that are configured, you can have a continuous availability strategy that still maintains security standards.
When you create an IP group, you specify settings such as gateway, subnet, and domain name system (DNS) for use in connecting to the enterprise network and VLAN for the network traffic. You then define a pool of IP addresses within the specified subnet, as shown in Figure 11-6.
Figure 11-6 Describe an IP group
You can use IP groups to partition a subnet. You can also partition the subnet into smaller groupings. You can create IP groups with duplicate subnet information. You can enter IP addresses by specifying a range in the console or by using the CLI.
A single deployment can use IPs from multiple IP groups. This way, you can isolate your web, application, and data tiers. They can be on different ranges of the same subnet or on separate VLANs.
IBM Knowledge Center has documented instructions for creating and administering IP Groups, which can be found at the following website:
11.2.3 Environment profiles
The PureApplication platform environment profiles bring various deployment configurations, cloud groups (include physical compute nodes and virtual network settings, such as IP groups and VLANs), and resource allocation limits (virtual processor limits, memory limits, and storage limits) all together and group them as a profile. In doing so, environment profiles provide resource isolation through a grouping of cloud groups (and physical compute nodes) and IP groups. Through a combination of cloud groups and IP groups, an environment profile can have virtual network isolation from other environment profiles, both management networks and customer data networks.
An environment profile can do the following tasks:
•Define the operational environments, for example, production, development, test, or quality assurance.
•Define a VM name format within the operational environment.
•Specify whether the PureApplication platform or the pattern deployer provides the IP address of the deployment (auto IP assignment from a pool or manual IP assignment in deployment).
•Segment the clouds and IP groups within the clouds to specific environments.
•Assign aliases to the cloud resources, such as clouds and IP groups.
•Assign sections within the clouds to specific users or groups.
•Define a specific time zone for use in deployments.
11.2.4 Access controls
Resource isolation through cloud groups, IP groups, and environment profiles provides cloud resource isolation in terms of both networking and compute resources. However, an enterprise might need to have fine-grained access control to set up environment profiles and isolate cloud resources so that different users or groups of users are permitted to use a different set of cloud resources.
PureApplication platform management provides workload resource and cloud resource isolation such that users can deploy only workload patterns to cloud resources to which they are explicitly granted access rights.
User access to cloud resources is managed by using the environment profiles. Users must be explicitly granted read access rights to an environment profile to deploy virtual application patterns and Virtual System Patterns (VSPs) to that environment profile. Workload administrators with full permission roles must have read access rights to cloud resources to accomplish the following tasks:
•Create an environment by using those cloud resources.
•Grant other users access rights to the environment profile.
•Deploy shared services to the environment profile.
11.3 System security
The PureApplication platform includes the following key security features:
•The root key for disk-based encryption is tied to the system, and is private and protected.
•No user-provided logic can be run on the system.
•Local users with full hardware administrative permissions can use a Secure Shell (SSH) connection to manage the PSMs.
•Monitoring of security-related events can be enabled on the system.
•Account policies can be created for local users.
•Your own console SSL certificates and keys can be imported into the system.
•Users and user groups can be synchronized in a multi-system environment.
•You can manage your console session idle timeout.
11.3.1 Disk-based encryption
A key is used to encrypt the contents of the SSD and the HDDs. The key is specific to each system and cannot be modified. All the local file systems, such as the SSD and the HDDs, are encrypted. By encrypting the file systems, the information is tied to the specific system and is unreadable even if it is physically compromised.
Here are the contents of the SSD:
•OS
•System software
•Root passwords of the deployed VMs
•Hypervisor management endpoint passwords
•Secure access keys
To protect this sensitive information, there is no user access to the SSD.
The HDDs are in user serviceable trays that can be removed. However, encryption ensures that any person attempting to access the system to remove these drives cannot access the data.
11.3.2 System-level access
During the life of the PureApplication System, there will be times when IBM representatives must access components within the rack for maintenance. In these cases, a system administrator must grant IBM the right to log in.
The IBM service representative account provides service and support personnel access to the hardware within the rack. This approach allows for advanced troubleshooting and problem resolution. This approach does not allow IBM to see your workloads or your data. This situation provides only the minimum access for servicing the system.
As a system administrator, to grant IBM the right to log in to the system, complete the following steps:
1. Click System → System Troubleshooting from the PureApplication System system console.
2. Select the Enable IBM service representative account access check box at the top of the window.
A new Secret key text field appears in the window, as shown in Figure 11-7.
Figure 11-7 Secret Key generation window for IBM service representative account access
3. Click Generate to generate the secret key. The secret key is generated by the system, as shown in Figure 11-8.
Figure 11-8 Generated secret key
4. Copy the secret key and send it to the IBM service representative.
5. After the IBM service representative finishes the service tasks, disable the IBM service representative account access by completing the following steps:
a. Click System → System Troubleshooting from the PureApplication System system console.
b. Clear the Enable IBM service representative account access check box at the top of the window.
 
Note: The IBM service representative account must be enabled before the IBM service representative can log in to take corrective actions. The account remains enabled for 7 days from the time of activation. It becomes automatically disabled after 7 days pass unless the system administrator manually disables it.
11.3.3 Roles and permissions
The PureApplication platform provides security role-based access control (RBAC) at both the system level and resource level. This combination of access control provides a balance between security roles at the overall system level and more granular access control at the resource level, for example, individual cloud groups, IP groups, virtual appliances, and compute nodes. The role-based authorization design is based on both the separation of duty security principle and the least privileged security principle.
System-level roles
Access control permissions for the PureApplication platform are divided into major functional areas and assigned according to the administrator roles as follows:
•Workload resources administration
•Cloud group administration
•Hardware administration
•Auditing
•Block storage replication administration
•Security administration
If a user does not have permission to complete a task, the menu items are not presented to them.
Users can be granted management responsibility of one or more of these functional areas. Within each area, an administrator can be granted either a read-only security role or a full permission security role. An administrator with a full permission security role can perform all administrative actions of that area, and an administrator with a read-only security role can monitor the configuration and status, but cannot make changes.
No single administrator needs to have all areas of administrative authorities. The preferred practice is to divide the management responsibilities among administrators so that no single administrator has all the administrator roles. For example, a user who has the auditing role is responsible for managing security auditing configuration, archiving security auditing records, monitoring, and analyzing any abnormality in system operations. An auditing administrator ideally should not have other areas of administrative responsibility, both to avoid any conflicts of interest and to be able to hold effectively users accountable for their actions.
An administrator with any one of the full permission security roles can delegate his own security roles to other users if that the administrator also has a delegation security role, as shown in Figure 11-9 on page 313.
Figure 11-9 Delegation
Resource-level roles
Resource-level roles refer to the security roles and access control permissions that are required to administer individual resources in the system, for example, cloud groups, IP groups, compute nodes, and storage devices. At the resource level, administration responsibility for the workload resources administration, cloud group administration, hardware administration, and security administration functional areas is further divided into subroles to support the least privileged security principle. For example, users and groups who are responsible for creating and administering deployment patterns can be granted the Create new patterns security role and not the full-permission Workload resources administration writer role.
This model of providing more granular access control at the resource level is designed to limit access to only those resources that must be managed at a particular time. The level of access (read, write, all, or none) that is assigned to specific resources can be selected individually. For example, a user may be granted read access to some resources, and write access to other resources.
Roles and permissions are documented in the IBM Knowledge Center. For more information about each security role and its restrictions, see the following website:
11.3.4 User account policies
User account policies are used to protect user accounts from being used by attackers to intrude into enterprise systems. User account policies include a failed login attempt policy, an account lock-out policy, a password policy and password expiration policy, and so on.
Having a well-prepared user account policy provides security protection for the PureApplication platform from the security threats, and provides protection for your users’ passwords by forcing a password policy.
The PureApplication platform has the user account policies feature only for local users. If your PureApplication platform is configured to authenticate users on a Lightweight Directory Access Protocol (LDAP) server, some policies do not apply even if they are enabled. For example, users who violate the “Number of allowed consecutive failed attempts to authenticate” policy are not locked out if they are LDAP users.
 
Note: User account policy configuration steps require an account with the security administration role with permission to manage security (full permission).
To configure user account policies, complete the following steps:
1. Click System → System Security from the PureApplication System system console.
2. In the User Account Policies section, select or clear the check boxes in front of the individual policies to enable or disable them, as shown in Figure 11-10.
Figure 11-10 User Account Policies on the PureApplication platform
3. For enabled policies, click the values beside the individual policies to change their values. The minimum number of characters in the password policy is always enabled and requires a value of at least 1.
4. Click Save beside each value that you update.
IBM Knowledge Center has documented descriptions of each value of the policy items. For descriptions of each value, go to the following website:
11.3.5 User and User Group management
User and User Group management is a vital feature of all multi-user systems and one of the core areas where IT security comes into play. Moreover, almost all of the industry regulations have something to say about it and mandate some strict IT policies regarding user management, access rights, and permissions.
The PureApplication platform provides detailed User and Group management features that can help you protect your environment from internal and external security threats and achieve compliance with IT policies.
Preferred security practices
As a preferred security practice, always try to minimize the assignment of multiple management responsibilities to users or user groups and give them only what they need. Putting users and groups on a need-to-have basis provides a more secure environment and a more manageable environment.
When you create users in the PureApplication platform, they automatically receive the default permission to deploy objects, such as VSPs, into the cloud. You must manually assign additional permissions to users.
When making these additional permission assignments, consider using the separation of duties (SoD) strategy to protect the integrity of the auditor role. Isolate the assignment of auditing permissions to one or more users who do not have other powerful administrative capabilities, such as the system or cloud administration permissions.
Auditors are responsible for monitoring activities and detecting any abnormal activities in the system, and system administrators are responsible for administering resources in the system. These different responsibilities must be assigned to different individuals.
PureApplication System implements two other SoD-oriented policies to help you control user activity in the cloud. These policies limit the authority to assign user permissions.
•Only users with the following roles can make permission assignments:
 – Workload resources administration with Manage workload resources (full permission)
 – Cloud group administration with Manage all cloud groups (full permission)
 – Hardware administration with Manage hardware resources (full permission)
 – Security administration with Manage security (full permission)
 – Auditing with Manage auditing (full permission)
•Users must have at least one of the five full permission administrator roles and the delegation security role to delegate their security roles to other users.
Thus, you can create a sound SoD implementation in which no single user can perform any action that is not recorded. All of these measures protect the integrity of your environment.
Managing system users
IBM Knowledge Center has documented instructions regarding managing system users. You can find information about managing system users at the following website:
Managing user groups
IBM Knowledge Center has documented instructions regarding managing user groups. You can find information about managing user groups at the following website:
11.3.6 Directory server integration (LDAP)
You can use the PureApplication platform to integrate with an existing LDAP server for user and group management. You can use this approach to use standard user authentication credentials. You can centrally manage group membership.
The PureApplication platform supports Generic LDAP, IBM Tivoli Directory Server, and Microsoft Active Directory, which implement the LDAP Version 3 specification RFC 4511. When using a secure LDAP server that is load balanced, be careful to accept the base security certificate. For more information about secure LDAP connections and certificates, see 11.3.7, “Secure LDAP communication” on page 317.
The PureApplication platform reads user and group entries from LDAP servers. PureApplication System can search for users, groups, and users as static members of groups. The system does not support environments in which LDAP groups are organized as attributes of users, either static or dynamic.
 
Note: If your PureApplication platform is configured to authenticate users on an LDAP server, some user account policies do not apply even though they are enabled.
IBM Knowledge Center has documented instructions regarding integrating the PureApplication platform with various LDAP servers. You can find the integration instructions for IBM PureApplication System W2700 v2.1.0.0 at the following website:
•Integrating with IBM Directory Server
•Integrating with Microsoft Active Directory
•Integrating with Oracle LDAP Server
•Integrating with LDAP Server Cluster
For other models and different versions of the PureApplication platform, you can find the instructions at the IBM Knowledge Center by selecting the PureApplication System type, such as W2500 2.1.0 → Administering the system → Administering users and security → Integrating PureApplication System with LDAP servers.
A sample configuration for IBM Directory Server is shown in Figure 11-11 on page 317.
Figure 11-11 Sample configuration for IBM Directory Server
11.3.7 Secure LDAP communication
When you integrate PureApplication System or PureApplication Software with an LDAP server, The PureApplication platform reads user and group entries from the LDAP server and can search for users, groups, and users as static members of groups. Data traffic between the PureApplication platform and LDAP server carries sensitive information. Because of this sensitive data, your corporate security policy might require encrypted connections from the PureApplication platform to the LDAP server. Otherwise, data is carried in plain text, which is an insecure way to carry sensitive data.
For a secure LDAP connection, LDAP Server provides confirmation to the PureApplication platform that it connected to the correct server for LDAP queries and that there is no man­in­the­middle attack in progress. To have such a secure LDAP connection, the PureApplication platform should have trustworthy copies of the appropriate X.509 signer (CA) certificates of the LDAP servers so that it can perform correct validation checks during the initial communication.
As a preferred security practice, you should always use a secure LDAP connection (LDAPS) wherever it is available to protect sensitive data.
To configure a secure LDAP connection between the PureApplication platform and LDAP Server, complete the following steps:
1. Click System → System Security from PureApplication System system console.
2. Expand LDAP Settings.
3. Enter the LDAPS protocol, LDAP server host name, and port number on the LDAP provider URL field, as shown in Figure 11-12.
Figure 11-12 Provide an LDAP provider URL
4. After you provide a valid secure LDAP provider URL, a new field named “Security certificate” is displayed under the LDAP provider URL row. Click accept in the Security certificate field. A certificates window opens, as shown in Figure 11-13.
Figure 11-13 LDAP server X.509 certificates
5. Click OK to accept the certificate.
 
Note: Use the “Certificate number to store” drop-down menu to allow the system to trust a clustered LDAP environment on which each LDAP server has a unique X.509 certificate that is issued by a common certificate authority (CA). By configuring the PureApplication platform to trust the common CA, by default the system trusts all certificates that are issued by the trusted CA.
6. The security certificate field shows the status (Figure 11-14 on page 319).
Figure 11-14 Security certificate accepted
For the remaining configuration settings, see 11.3.6, “Directory server integration (LDAP)” on page 315.
11.4 Workload security
Workload is a broad term. It can include OS, runtime environment, middleware products, applications that run on these middleware, and agents for various tasks, such as backup agents, monitoring agents, and security agents. All of those different software components require different security standards and practices. Moreover, there is no one single security standard or security policy with which workload should be in compliance. Every enterprise has different requirements and IT policies regarding security.
The PureApplication platform has powerful and flexible features and tools hat you can use to implement your security policies and customize OS and middleware without any problem.
Workloads that are deployed by the PureApplication platform are based on a standard OS image. The OS image can be customized by the client to meet their needs. For Virtual System, Virtual Application, and Shared Service patterns, a common OS image is used. On PureApplication System, a default IBM OS Image is provided. For PureApplication Software, this is optional. On either platform, it is optional to use your own image with deployments.
The OS image that comes with the PureApplication platform by default can be customized to meet your IT standards and workload needs. Also, you can create a pattern component and add it to your pattern for customized workloads. In the PureApplication platform, you can achieve customization by using one of the following methods:
•Use script packages or add-ons.
•Use a plug-in development kit (PDK) to create software components.
•Use the Extend and Capture feature of the PureApplication platform to create customized OS images.
•Use IBM Image Construction and Composition Tool (ICCT) to create customized OS images.
OS customization can include configuration changes, service activation and deactivation, and software installation, such as installing a security software agent. Instead of providing instructions for each of those tasks, this section provides general guidance, a high-level solution, and the tools that are used to implement the solution in this publication.
Depending on the requirement of the customization, you can use script packages, add-ons, software components, the Extend and Capture feature, or ICCT to implement your corporate security solution or configure the system so that it can be compliant with your IT policies and meet your needs.
IBM Knowledge Center has documented instructions for using script packages, add-ons, the Extend and Capture feature, and the ICCT tool. For more information, see the following topics in the IBM Knowledge Center:
•Managing Script Packages
•Managing add-ons
•Plug-in Development and Creating Software Components
•Extending and Capturing virtual images
•Working with IBM Image Construction and Composition Tool
11.4.1 LDAP user authentication for OS
Authenticating a deployed workload OS with an enterprise LDAP directory server is a common integration scenario for many enterprise IT organizations. Most of the modern OSs support LDAP authentication for user and group management of the system. However, there is no one single authentication scenario because there are different LDAP servers and different configuration steps for different OSs on the market.
The PureApplication platform OS images use local user and group management by default. The workload OS that is deployed with each VM on the PureApplication platform does not have LDAP integration by default. However, anyone who needs LDAP integration for workload OS can easily add LDAP integration to the default OS by using customization tools and methods that are provided by the PureApplication platform.
The easiest way to configure LDAP integration for workload OS is to use script packages. You can create script packages to install software and then modify OS configuration files.
The IBM developerWorks article Integration of OS authentication with Microsoft Active Directory on IBM PureApplication System can help you with integration with a Microsoft Active Directory and provides a solid base even if your corporate LDAP server is different than Microsoft Active Directory. To access this article, go to the following website:
11.4.2 Patch management
Every enterprise should closely monitor the systems and applications against possible vulnerabilities and problems. Otherwise, those vulnerabilities can be used by attackers to access data or damage the system. The enterprise can suffer as the result of those attacks unless they have a good patch management policy and preferred practices.
Software patching is the process of fixing software problems and replacing the vulnerable parts of the software with updated ones. Generally, patches are discovered after the software components are delivered to the customer or made available for general use.
Because PureApplication System includes hardware components, network devices, compute nodes, OS, and middleware software, there are different patches that are applicable to the PureApplication environment. The patches can be grouped into four main categories:
•OS patches
•Middleware software patches
•Firmware patches
•System management software patches
IBM delivers firmware patches and system management software patches as a system update fix pack file for the PureApplication platform. This system update fix pack includes updates for hardware firmware (such as network switch, chassis, storage, compute node, and SAN switch) and management software.
This publication covers patch management in the following chapters:
•See Chapter 7, “Operating system maintenance” on page 155 for PureApplication platform OS patches
•See Chapter 8, “IBM middleware maintenance” on page 205 for PureApplication platform middleware maintenance.
•See Chapter 9, “System and integrated components maintenance” on page 241 for PureApplication platform system update fix packs.
As a preferred security and system management practice, always keep your systems and applications up-to-date by applying updates from IBM.
11.5 Security monitoring
Security monitoring is the one of the most important tasks to be performed in an environment such as the PureApplication platform, which brings infrastructure and middleware software together as an expert-integrated system. Because of that importance, collecting, analyzing, and taking necessary actions for security events and audit data is vital. Security monitoring provides collection and analysis of the data and helps you detect indications and warnings of any possible misuse and intrusion attempts so that you can take preventive actions and respond quickly.
11.5.1 Security and administrative event auditing
Because of enterprise compliance to regulatory policies, an auditing function is a must have feature. PureApplication System and PureApplication Software have an auditing function that is used for storing and recording activities about user actions, administrative actions, and security-related events that occur on the system. PureApplication System and PureApplication Software provide all the required information to describe who performed what action on which resource when, from where (source address), and whether the attempt was successful or not, and if not, what caused the failure.
The auditing function provides accountability, which is a mandatory regulatory requirement for enterprises. By using the auditing data that PureApplication System and PureApplication Software provide, users and administrators are held accountable for the actions they perform on the system. These users and administrators actions include deployment-related actions and all administrative actions that affect data confidentiality, integrity, and system availability.
From the security perspective, audit functions provide all the required information as audit data that is packaged for you to analyze and determine whether any incident that compromised your system occurred. This technique provides security protection of your infrastructure from security threats and all the information regarding auditing. This information can be used to improve your security system and enable you to take all necessary security measures immediately against threats both from the internal and external network.
Security auditing is a fundamental part of regulatory policies for the enterprises to protect data confidentiality, integrity, and system availability. For this reason, the audit function in PureApplication System and PureApplication Software is enabled by default, and nobody including the system administrators, can disable it.
PureApplication System and PureApplication Software store audit records in an internal database. After the number of records exceeds a threshold in the internal database, one of the followings actions can occur:
•If there is external storage configured, the system exports those records to external storage as audit packages, including two files: a CSV file with records, and its checksum file.
•If there is no configured external storage, the system exports those records as an audit package that includes a CSV file with records and its checksum file, and places it on internal storage. PureApplication System and PureApplication Software regularly clean up those auditing packages to stay within file system space constraints. This cleanup can lead to a loss of security event audit records if an external storage server is not configured on the system.
 
Note: By configuring an external storage server for archiving audit record packages externally, you can analyze event logs offline and automate the event log archival to meet various compliance and regulation requirements process. Communication with external storage servers is protected by using SSH.
Configuring an external storage server
Configure an external storage server so that PureApplication System or PureApplication Software can automatically push audit record packages to an external storage area when the internal database has reached its threshold.
 
Note: You must be assigned the System level, Auditing role with permission to Manage auditing (Full permission) to configure an external storage server for audit packages.
An external storage server for audit packages is configured from the External Storage Server tab, which is accessed by clicking System → Auditing from PureApplication System system console.
The PureApplication platform IBM Knowledge Center has documented instructions for the configuration of an external storage server. That information can be found at the following website:
Here are some important points to consider when configuring an external storage server for audit packages:
•Always use Rivest-Shamir-Adleman (RSA) key encryption instead of user ID and password authentication to better secure your external storage server.
•Make sure that the external storage server has enough space to store archived security audit packages according to your audit policy. The size of an audit package depends on the number of records it stores, and the number of audit packages that the system generates depends on the activities that are performed on the system. An average size for an audit package is 20,000 records (about 1 MB). You can plan storage space by taking that size into account.
•The External Storage Server (The Secure Shell server) RSA public key size cannot exceed 4096 bits.
•The Public key (external storage server) field might intuitively mislead you to provide the public key of the account (the user account on the external storage system) that you use for the SSH connection. Pay attention to this field and provide a public key of the external storage server (SSH Host public key), not the public key of the account on the external storage server. The /etc/ssh directory is usually the location of the SSH host public key (ssh_host_rsa_key.pub), but the location can vary depending on the system. The reason for using the SSH host public key instead of using the public key of the account is to provide more secure communication.
 
Note: The SSH Host key provides a fingerprint that the SSH client (PSM in our case) can use to validate that it is connecting to the server that it thinks it is. The SSH client software checks the server's (host) public key against data that the server sends encrypted with the host private key. This technique requires the host SSH client to have a copy of SSH host public key.
A sample external storage server configuration is shown in Figure 11-15.
Figure 11-15 A sample external storage server configuration for audit packages
11.5.2 Enabling security events
The auditing system stores and records all activities about user actions, administrative actions, and security-related events that occur on the system. However, those activities cannot be monitored on the event console in real time by default. If you want to monitor security-related events on the system console, PureApplication System and PureApplication Software can be configured to send security-related events to the console in real time. By sending events in real time, you can learn about potential security breaches when they occur on the system.
Security events in the following categories can be sent to system console:
•System restore
•Subnets (IP groups)
•Roles
•User account policies
•User token
•Users
•Groups
•Group memberships
•IP address configurations
•LDAP configurations
•Audit configurations
•Compute nodes
•Email configurations
•SNMP configurations
Moreover, the system administrator or a user with the audit management role can create security events in the system for a particular user’s logon and logoff actions.
Activating security event monitoring
To configure PureApplication System or PureApplication Software to send security-related events to the console in real time, complete the following steps.
 
Note: You must be assigned the System level, Auditing role with permission to Manage auditing (Full permission) to perform these steps. Administrators who are assigned the Auditing role with permission to View all auditing reports (Read-only) can only view security monitoring configurations.
1. Click System → Auditing from the PureApplication System system console.
2. Expand Security Monitoring.
3. To enable a security event in the table, complete the following steps:
a. In the Category column, locate the security event that you want to monitor.
b. Select the check box in the Enable column.
c. To refresh the table, click the Refresh icon above the table.
d. (Optional) To reset the table to its default content, click the Reset icon above the table.
After the configuration is complete, the security monitoring table looks similar to Figure 11-16.
Figure 11-16 Enable security monitoring
Activating security events for a specific user
You can create security events based on a specific user’s logging in or logging off the system actions. By doing so, you can monitor a specific user on the system.
To create a security event for a specific user, complete the following steps:
1. Click System → Auditing from the PureApplication System system console.
2. Expand Security Monitoring.
3. Click the plus sign icon (above the table).
4. In the new window, select a user from the list.
5. Add a description of the event.
6. Select the user action that you want to monitor, for example, the action of logging in or logging off the system (Figure 11-17).
Figure 11-17 Create a security event for a specific user
7. Select Enable to enable the security monitoring event.
8. Click OK. Details about the new event are added to the table, as shown in Figure 11-18.
Figure 11-18 Security event added to the table
11.5.3 Forwarding security events
PureApplication System and PureApplication Software have an event forwarding feature. You can use this feature to forward Simple Network Management Protocol (SNMP) traps to an enterprise monitoring system in your environment. When creating an SNMP trap destination, you can filter the events so that only security events are forwarded to the trap destination you create.
To configure security events forwarding, complete the following steps:
1. Click System → System Settings from the PureApplication System system console.
2. Expand Events.
3. Click Create trap destinations.
4. Provide the trap destination information, such as IP address, port number, community string, SNMP version, and filter (Figure 11-19).
Figure 11-19 Create trap destination with filtering security events only
11.6 Special situations: Peeling back the covers
Most enterprises have groups to manage switches for the data and storage networks. PureApplication System is a pre-integrated appliance with network and storage switches. However, PureApplication System does not bring any extra impact or workload in terms of network management and configuration because PureApplication System is a pre-integrated and pre-configured appliance.
The network or SAN team must understand the configuration of the switches or check port status. PureApplication System provides read-only access to network and SAN switches so that network or SAN team can get what they need.
11.6.1 Network topology
If you click Hardware → Network Topology in the PureApplication System system console, you can see a table that lists the virtual network links within the rack (Figure 11-20). You can use this view to see each VLAN that the links carry. You can see how the connections are mapped to IP groups, compute nodes, and to compute nodes.
Figure 11-20 Link Connections
In the same window with Network Topology, you can also see a table that is called Compute Nodes that shows which VMs are on each compute node. You can use this capability to see the high-level data flow within the rack.
11.6.2 Network switches
For a more detailed view, you can look at the individual network devices. Although PureApplication System does not allow direct management of the switches, it does provide limited access to run certain commands.
In the system console, click Hardware → Network Devices, which opens a menu of the switches in the rack. You can choose either of the TOR switches or any of the switches in the chassis.
The TOR that is used in PureApplication System is a Blade Network Technology (BNT) Networking Operating System RackSwitch G8264. You can see the firmware and software levels by clicking Hardware → Network Devices in the system console.
Running the “show vlan” command from the user interface displays the VLAN configuration for the switch (Figure 11-21).
Figure 11-21 Running a read-only command on network switches
You can view the “show vlan” command output to verify exactly how each VLAN is carried in and out of the TOR switches.
The other command that you can use on the TOR switches is “show mac-address-table”. This command shows you all of the Media Access Control (MAC) addresses that it has cached (Figure 11-22). This list tells you all the MAC addresses along with the port and VLAN information that is known. This capability is useful for determining where communication is lost between the PureApplication System and customer data networks if there is a network problem.
Figure 11-22 show mac-address-table command output
Chassis Network Switch is a model EN4093 Ethernet switch. It has some of the same commands available as the TOR. The most useful is “show vlan” (Figure 11-23 on page 331).
Figure 11-23 Run show vlan command on the chassis switch
11.6.3 SAN switches
The SAN switch is a IBM Flex System FC5022 12-port 16Gb ESB SAN Scalable Switch.
You can run commands to see the setup of the switch and the zone configuration. From the zone information, you can see the security configuration that keeps the volumes for each cloud group separate from the others.
This capability is even more interesting when using PureApplication System features that require Fibre Channel connectivity external to the rack that includes block storage replication and external block storage. In these cases, you see the port configuration in the chassis SAN switches for the additional ports.
For Block Storage Replication, the additional ports plug into the SAN switches on another PureApplication System rack. For external storage, these ports plug directly into a Storage Volume Controller. In either case, the additional ports show up in the SAN switch configuration so that you can verify that the settings are valid and match your security standards.
For more information about storage, see Chapter 5, “Storage” on page 103.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset