Setting Up and Managing Elastic Charging Engine Security

Setting Up User Accounts and User Groups

Access to ECE files is controlled by creating user accounts and granting specific permissions in the Elastic Charging Controller (ECC). After you have created user groups and set permissions, users can log in through ECC and manage ECE files.

Create the following user accounts to manage ECE files:

UNIX accounts:
- An administrator to run and manage ECE processes
- If needed, users to manage the rated event files
- If needed, users to manage ECE file systems
Non-UNIX accounts:
- Users created for securing ECE processes from unauthorized access.

You must also create a UNIX user group that includes all users, including the administrator.

For information about the permissions that you should grant these users and groups, see "Managing ECE Permissions".

Creating UNIX User Accounts and Groups

Create UNIX accounts and groups using UNIX commands in ECC. To create user accounts, use the useradd command. To create groups, use the groupadd command.

Managing ECE Permissions

This section describes the permissions that you should restrict for a secure ECE installation. Strict governance of file permissions prevents accidental overwriting and misuse of the system.

About Permission Types

Access to ECE files is controlled by creating user accounts and granting specific permissions in ECC. For information about which user accounts to create, see "Setting Up User Accounts and User Groups". After you have created user groups and set permissions, users can log in through ECC and manage ECE files.

ECE uses the traditional UNIX read, write, and execute permission types. In ECC, use the chmod command to set file permissions and the chown command to change file owners.

The chmod command can change the permissions of files and directories that have been created. You use the setfacl command to set permissions for files that have not been created at the time of installation, such as log files in the ECE_home/logs directory.

Restrict permissions as much as possible. You may choose to have either a single administrative user with all permissions who runs ECE core processes and manages the rated event files and other directories, or to create multiple users with specific permissions to carry out these tasks.

Configuring Specific File Permissions

To ensure the integrity of the system, access to certain files should be tightly regulated.

Restrict access to the following files:

jmxremote.password: Ensure this file has read permission for the user and no permission to either the group or the world (Unix 400).
server.jks: Ensure only you have read permission.
charging-cache-config.xml: Ensure this file has only read permission for the user.
charging-coherence-override-mode.xml: Ensure this file has only read permission for the user.

To restrict access to these files:

Log in to ECC.
Go to the ECE_home/config directory.

Enter the following commands:

chmod 400 jmxremote.password
chmod 400 server.jks
chmod 400 charging-cache-config.xml
chmod 400 charging-coherence-override-mode.xml

Granting ECE User Permissions

Follow these guidelines when granting user permissions:

Grant the administrator user all permissions.
Grant execute permissions to only the user assigned to start processes.

Note:

On Linux, all directories must have an execute permission to the user.
If you created users to manage the rated event files, grant them read and write permissions for the rated event directory.
If you created users to manage file systems, grant them read and write permissions to the directories that they will manage.

To grant permissions to users, use the chmod command in ECC. To change file owners, use the chown command in ECC. To change the permissions for files, use the setfacl command.

The UNIX group containing all of the users should have the following directory permissions:

Read and write permission to ECE_home/config and ECE_home/logs
Read permission to ECE_home/lib
Read and execute permission to ECE_home/bin

About the Default umask for ECE Users

You control permissions for new files by adjusting the default umask. You check your current umask by entering the umask command with no additional parameters. Users can also change their umask if they wish.

The default umask is set to 007 to exclude all users that are not in the same group.

If no default umask is set, any new files will be created with read-write-execute permissions granted to all users. Instead of having a umask that changes the default permissions globally, run the setfacl command to set permissions for files. For example, to set all logs in the logs directory to 600 for the logs that are created and logs that will be created in the future:

setfacl -m user::rw-,group::---,other::--- ECE_HOME/logs/*.log

About External Permissions

Permissions for non-UNIX accounts are defined within the permissions.xml file. When you install ECE, you create a principal administrator alias and password for Oracle Coherence cluster security, which is granted all permissions. The following example shows the content of permissions.xml after installation:

<permissions>
  <grant>
    <principal>
      <class>javax.security.auth.x500.X500Principal</class>
      <name>CN=Administrator,OU=DN</name>
    </principal>
    <permission>
      <target>*</target>
      <action>all</action>
    </permission>
  </grant>
</permissions>

where Administrator and DN are the DName credentials that were entered in the KeyStore Credentials screen at installation.

Managing Passwords in ECE

Access to ECE files is controlled by creating user accounts and granting specific permissions in ECC. For information about which user accounts to create, see "Setting Up User Accounts and User Groups". For information about granting permissions, see "Managing ECE Permissions".

Each UNIX-based user account is password protected and can be managed through ECC. These passwords do not expire by default. You can choose to set up password expiration using the chage command.

In addition to UNIX-based user accounts, you also create a non-UNIX account for access to external applications. ECE connects to Oracle Communications Billing and Revenue Management (BRM) and Pricing Design Center (PDC) to load and store the pricing and customer data required to charge for network events. For secure communication between these applications, credentials are stored in the Oracle wallet. See "About Managing External Application Passwords".

The passwords from ECE used to integrate with external systems do not expire by default. Change the secret keys used to encrypt them regularly.

About Managing External Application Passwords

When installing ECE, the passwords that you enter for Oracle Coherence security are automatically encrypted. The encryption keys are stored in the server.jks file, and the password to the keys are stored in the jmxremote.password file. The server.jks file is created in ECE_home/config when you install ECE. You can check the validity of the KeyStore. See "Checking Keystore Validity" for more information.

The passwords that you enter for the boundary systems (such as BRM and PDC) are stored in the Oracle wallet when you install ECE. If the password used to connect to BRM or PDC is changed or if a new BRM or PDC instance is added, you can add or modify the password in the ECE wallet by using ECE Mbeans. See "Storing or Modifying Passwords in ECE Wallet" for more information.

Storing or Modifying Passwords in ECE Wallet

To store or modify a password in the ECE Oracle wallet:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
Expand the ECE Configuration node.
Expand the node of the component and instance for which you want to set or modify the password.

For example, if you want to modify the BRM password, expand charging.connectionConfigurations.brmConnection.
Expand Operations.
Click SetPassword.
Specify the following values:
- password. Enter the password you want to add or modify.
- walletPassword. Enter the password of the ECE Oracle wallet.
Click the SetPassword button.

Checking Keystore Validity

To check keystore validity:

Log in to ECC.
Enter the following commands:
```
keytool -list -v -keystore server.jks
password: storepassword
```
where storepassword is the password to the keystore.

ECC returns the contents of server.jks, indicating that the keystore is valid.

If ECC denies permission, ensure that you have set the permissions to server.jks as described in "Configuring Specific File Permissions".

If ECC does not return the contents of the JKS file, it could be because the user forgot the password. Access will be denied until the ECE user goes through the company approved process for recreating the keystore with appropriate accounts.

The ECE installer creates a self signed certificate. Your company's authorized personnel can create a certificate and get it signed by a signing authority or self sign it. Deployment of all keystores must be validated for authenticity.

Setting Up Cluster Security

This section explains how to perform tasks related to ECE cluster security. To restrict access to the ECE cluster (an Oracle Coherence cluster), you must set up an authorized hosts list. You can optionally enable SSL for intra-cluster communication, in which case you must also enable Well Known Addresses (WKA).

Adding Trusted Hosts

The trusted host list is set up at installation in the Coherence Grid Security screen of the Installer. This list allows only specified hosts to connect to the cluster. You can add more hosts to the list in the charging override file.

The override file contains a section <authorized-hosts-list> that contains host address of each physical machine participating in the cluster. The address could be a server host name or an IP address. IP address is preferred if the hosts are multi-homed. Only the IP address that the network is binding to should be given. Using IP addresses also allows you to set a range of IP addresses which is not possible when using host names.

To add trusted hosts:

Open the ECE_home/config/charging-coherence-override-secure-prod.xml file in a text editor.
In the trusted hosts list, add new trusted hosts below those specified at installation by adding the following text:
```
<cluster-config>
  <authorized-hosts>
    <host-address>host_ip1</host-address>
    <host-address>new_host_ip</host-address>
    <host-range>
      <from-address>ip_range_start1</from-address>
      <to-address>ip_range_end1</to-address>
    </host-range>
    <host-range>
      <from-address>new_ip_range_start</from-address>
      <to-address>new_ip_range_end</to-address>
    </host-range>
  </authorized-hosts>
</cluster-config>
```
where:
- host_ip1 is the pre-existing IP address of a host specified at installation.
- new_host_ip is a specific host that you are adding.
- ip_range_start1 is the beginning of a pre-existing range of IP addresses specified at installation.
- ip_range_end1 is the end of the pre-existing range of IP addresses specified at installation.
- new_ip_range_start is the beginning of the new range of IP addresses.
- new_ip_range_end is the end of the new range of IP addresses.
You can choose to enter new_host_ip, both new_ip_range_start and new_ip_range_end, or all three.
Save and close the file.

Securing Intra-Cluster Communication

Intra-cluster communication can be strengthened by enabling SSL. ECE supports SSL versions 2 and 3 and TLS version 1. For an overview of common SSL concepts, see Oracle Coherence Security Guide.

You should expect enabling SSL to have a negative impact on ECE performance. As such, SSL should only be enabled if required. Consider the implications of the performance degradation before enabling intra-cluster SSL.

By default, SSL is not enabled. You can select to enable it when you run the ECE installer. You can also enable SSL after installing ECE. See "Performing a Secure ECE Installation" in BRM Security Guide.

Enabling SSL Within the ECE Cluster

To enable SSL:

Enable WKA. See "Enabling Well Known Addresses".
Open the ECE_home/config/ece.properties file.
Search for the following system property:
```
tangosol.coherence.override=
```

Add charging-coherence-override-secure-prod.xml as follows:

tangosol.coherence.override=charging-coherence-override-secure-prod.xml

Open the ECE_home/config/defaultTuningProfile.properties file.

Search for the following system properties:

tangosol.coherence.ssl.storepassword=
tangosol.coherence.ssl.keypassword=

Set the properties as follows so that two-way SSL can use server.jks for encrypted data:
```
tangosol.coherence.ssl.storepassword=keystorepassword
tangosol.coherence.ssl.keypassword=coherencepassword
```
where:
- keystorepassword is the password to server.jks
- coherencepassword is the password for Oracle Coherence grid security alias that was entered in the KeyStore Credentials screen at installation
Save and close the files.

To generate an SSL self-signed certificate:

Log in to the ECC.
Run the following command:
```
keytool -genkeypair -dname "cn=Administrator, ou=DN" -alias admin -keypass password -keystore ECE_home/config -storepass storepassword
```
where:
- Administrator and DN are the DName credentials that were entered in the KeyStore Credentials screen at installation
- password is the key password for the admin alias
- storepassword is the password for the KeyStore
You can choose to set certificate expiry using the -validity option.

You can optionally have the certificate signed by a signing authority, but for ECE functionality a self-signed certificate is sufficient.

Enabling Well Known Addresses

The Well Known Addresses (WKA) mechanism allows cluster members to discover and join a cluster using unicast instead of multicast. You may need to enable WKA if your data center policy prohibits multicast. If you enable SSL for intra-cluster communication, you must enable WKA.

To enable WKA:

Open the ECE_home/config/charging-coherence-override-secure-prod.xml file.

Specify cluster members by adding text as follows:

<cluster-config>
  <unicast-listener>
    <well-known-addresses>
      <socket-address id="id">
        <address>ip_address</address>
        <port>port</port>
      </socket-address>
      ...
    </well-known-addresses>
  </unicast-listener>
</cluster-config>

where:

id is the ID for a particular cluster member
ip_address is the IP address of the cluster member
port is the value specified in the member's unicast listener port

Ensure that the list of WKA members is the same on every cluster member so that no cluster member operates independently from the rest of the cluster.

For more information about setting up a WKA host list, see the discussion of Well Known Addresses in Oracle Coherence Developer's Guide.

Securing Inter-Cluster Communication

Inter-cluster communication between the ECE cluster and the BRM system can be strengthened by enabling SSL.

BRM Gateway can connect to the Connection Manager (CM) by using SSL. See "Enabling SSL Communication between BRM Gateway and the CM" for information.

Enabling SSL Communication between BRM Gateway and the CM

If you use SSL to secure connections between Java PCM clients and the CM, you must enable SSL communication between BRM Gateway and the CM.

For information about enabling SSL for Java PCM clients in BRM, see "Enabling SSL/TLS for Java PCM Clients".

To enable SSL communication between BRM Gateway and the CM:

Do one of the following, where BRM_home is the directory in which you installed BRM:
- If you enabled one-way SSL server and client authentication in the CM, verify that the BRM_home/wallet/client/cwallet.sso file was copied into your ECE installation (in the directory of your choice).
- If you enabled two-way SSL server and client authentication between the CM and its PCM clients, verify that the BRM_home/wallet/server/cwallet.sso file was copied into your ECE installation (in the directory of your choice).
  
  For information about enabling two-way SSL server and client authentication between the CM and its PCM clients, see "Enabling SSL/TLS in Connection Managers".
If the file listed in the previous step is not in your ECE installation, copy it from BRM to the ECE directory of your choice.
Copy the following JAR files to the ECE_home/lib directory:
- BRM_home/jars/osdt_cert.jar
- BRM_home/jars/osdt_core.jar
- BRM_home/jars/oraclepki.jar
Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
Expand the ECE Configuration node.
Expand charging.connectionConfigurations.brmConnection.
Expand Attributes.
Specify values for the following attributes:
- sslEnabled: Change the value from 0 to 1.
- wallet: Enter the path to the directory on your ECE installation where you copied your Oracle wallet from your BRM environment (cwallet.sso).
Stop and restart BRM Gateway.

See "Starting and Stopping the BRM System" for information.

SSL communication between BRM Gateway and the CM is now enabled.

Setting Up Password-less SSH Between the Driver and Servers

You must set up bi-directional password-less Secure Shell (SSH) logins between the driver machine and each server machine for ECC to work. Password-less SSH allows servers to connect to the driver and synchronize ECE files.

To set up password-less SSH:

Log in to the ECC.
Run the following commands:
```
ssh-keygen -t dsa
ssh-copy-id -i ~/.ssh/id_dsa.pub user@host
```
where:
- user is the user name set for all host machines at installation in the ECE Cluster Details screen.
- host is the name of the server for which the password-less SSH is being established.

To test passwordless SSH:

Log in to ECC.
Run the following command:
```
ssh user@host
```
where:
- user is the user name set for all host machines at installation in the ECE Cluster Details screen.
- host is the name of the server for which the password-less SSH is being established
If a password is requested, password-less SSH setup has failed. Ensure that you have followed the steps for setting up password-less SSH correctly and run the test again.