Securing SA internal communications

SA includes several Core Components that communicate with each other over secured communication channels, typically the industry-standard protocols such as HTTPS. These components include:

The SA user running the SA Client on the user’s local desktop or server. The SA Client communicates securely using HTTPS to the SA Core. Users provide a user name and password to log in to SA; the credentials are authenticated either within SA or optionally by an external integrated LDAP server.

SA Server Agents running on the managed servers. The SA Server Agents act both as clients and servers when communicating with SA Core Components. All communication is encrypted, integrity checked, and authenticated using client certificates. A small number of Core Components can issue commands to the SA Agent over a specific TCP/IP port; the SA Agent can also call back to Core Components, each with its own specified port.

SA Core Components, which are back-end processes running on a small number of servers. SA Core Components communicate with each other and with the SA Agent, also using strongly authenticated TLS.

For customers running SA across multiple data centers, communication also occurs between SA cores over a secure channel provided using integrated certified messaging included in SA (SA Bus).

By protecting the communication channel between distributed components, SA prevents intruders from sniffing the network traffic or causing SA to perform unauthorized tasks on SA-managed servers.

• Communication between components in an SA Core
• Communication between Agents and SA Core components
• Communication between SA Cores

Communication between components in an SA Core

When an SA component must communicate with another component, it opens a secure (typically SSL/TLS) communication channel using a well-known port. Each SA component has a public-key certificate that is generated when SA is installed. The component uses its public-key certificate when authenticating itself to another component. In this fashion, most inter process communication is strongly authenticated, encrypted using the strongest ciphers available, and integrity checked.

TLS compliance

According to PCI DSS v3.1 standard, TLS v1.1 and TLS v1.2 are required to be used. Also, SSL and early TLS are no longer considered strong from the cryptography point of view.

Protocol switch tool

This is a script that automates and eases the change between TLS protocol versions. It can be called automatically from the patch installer or can be run manually by invoking it from command line as follows:

# /opt/opsware/oi_util/protocol_switch_tool/protocol_switch_tool.sh --backup (to back up the current configuration that can be later restored)

# /opt/opsware/oi_util/protocol_switch_tool/protocol_switch_tool.sh --protocol <TLSvX>

It is recommended to run the script with --help option first for more details.

Supportability

To use TLSv1.1 or TLSv1.2 protocols, all Cores and Satellites must be running an SA version that supports these protocols (a minimum of SA 10.23 is required). Mixed protocol environments are not officially supported.

Before switching to another TLS protocol version, ensure that all the integrated software products communicating with Server Automation support the chosen TLS protocol version. Otherwise, communication with the Server Automation components will fail.

Communication between Agents and SA Core components

The Server Agent participates in the strongly authenticated and encrypted SSL/TLS traffic described above. In addition, when Agents are directed to perform management tasks on a server, the typical flow of control messages (described below) help to ensure that only authorized users are performing those actions. It would be extremely difficult for an intruder to generate a valid command sequence directing the agent to perform an unauthorized task.

The following sequence describes a typical SA management task, namely provisioning software on a managed server. Other operations on managed servers follow the same general protocol:

1. The Data Access Engine opens a communication channel via HTTPS with the SA Server Agent, directing it to perform a management task.
2. The SA Agent calls back to the Data Access Engine to retrieve specifics about the task to perform. To open a communication channel, the Agent must present its public-key certificate, which the SA Core verifies against an internal database mapping the certificate itself to the machine’s IP and a unique machine identifier that SA generates when the agent is installed. This safeguard prevents users from simply copying the digital certificate and corresponding key to another machine in hopes of masquerading as the original managed server.

   After successfully opening the communication channel, the SA Agent receives the exact list of software to be installed and removed (as well as any scripts to execute, the order of software installation, and when to reboot during the provisioning process).

3. The SA Agent opens a communication channel to the Software Repository (also via HTTPS) and requests a download of the software it needs to install. Before the Software Repository initiates the download, it recomputes an SHA checksum for the package along with a secret key it knows. Only if the SHA checksum matches the checksum generated when the package was uploaded does the SA Agent receive the software it requested.

Asynchronous, agent-initiated calls to the SA Core provide scalable support for progress reporting and long-running operations, because the SA Core need not manage thousands of synchronous agent operations directly. SA supports these asynchronous calls from the Agent to the Core even in network environments where firewalls prevent Agents from initiating TCP connections, as the SA Gateway infrastructure provides bidirectional tunneling over unidirectional connections.

Other technical details of agent/core communications:

• Connections are TLS1.x (based on what the core set up is), mutually authenticated with X.509 certificates (the server checks the client’s certificate, and vice versa).
• Private keys for Core and Agent certificates are stored in files that are readable by root only.
• All certificates are generated at installation, are owned by the customer, and are not known to HPE.
• SA provides a Recertification tool for recertifying Cores and Agents prior to certificate expiration.
• Depending on your selected certificate mode, SA certificates are signed by SA internal self-signed Certificate Authorities (CAs) or by your external CA. For more information about the SA Certificate Modes, see SA certificate management.
  To avoid HTTPS security warnings in web browsers when using self-signed CAs, install an externally signed certificate in the SA instance of Apache.

Communication between SA Cores

If you are running SA across multiple data centers, SA automatically synchronizes relevant data across all SA-managed data centers. Broadly speaking, SA synchronizes two types of data: the SA model of servers (including all hardware, software, and configuration attribute information) and the software packages themselves.

• Replicating the SA model: SA uses integrated certified messaging to synchronize the SA model data. SA implements SSL to safeguard the messages flowing across the message bus. The actual messages themselves describe SQL changes that need to be made to the SA database at the receiving end of the communication.
• Replicating software packages: SA replicates software packages on demand. That is, they are only copied when they are needed. When the an administrator managing a server in the New Jersey data center directs SA to install a software package that does not exist in New Jersey's Software Repository, SA requests it from another data center. The actual file transfer uses the open source utility rsync, and the communication channel is secured using SSH.