This chapter discusses how to implement security during system administration of Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).
See BRM Elastic Charging Engine Security Guide for an overall discussion of how to install, configure, and use ECE securely as well as information about security prerequisites.
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 in the keystore.jks file exclusively for securing ECE processes from unauthorized access. See "About the Keystores" for more details.
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".
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.
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/oceceserver/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.
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).
keystore.jks: ensure only you have read permission.
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-XXX.xml: ensure this file has only read permission for the user.
To restrict access to these files:
Log in to ECC.
Navigate to the ECE_Home/oceceserver/config directory.
Enter the following commands:
chmod 400 jmxremote.password chmod 400 keystore.jks chmod 400 server.jks chmod 400 charging-cache-config.xml chmod 400 charging-coherence-override-mode.xml
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/oceceserver/config and ECE_Home/oceceserver/logs
Read permission to ECE_Home/oceceserver/lib
Read and execute permission to ECE_Home/oceceserver/bin
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
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.
For more information about initial configuration of these fields, see BRM Elastic Charging Engine Installation Guide.
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 ECE and these other applications, credentials are encrypted and stored in the keystore. 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.
When installing ECE, the passwords that you enter for Oracle Coherence security and for connecting to BRM or PDC are automatically encrypted. The encryption keys are stored in keystores and the password to the keys are stored in the jmxremote.password file. You can use the encrypt utility from ECC to update the encrypted BRM and PDC passwords.
The keystores are file-based credential stores that store the encryption keys used by ECE for cluster security.
ECE uses two keystores:
keystore.jks: used for secure communication between ECE and BRM or PDC
server.jks: used for Oracle Coherence cluster security and enabling SSL across the cluster nodes
Each key in a keystore has an alias name and is password protected. The keystores themselves are also password protected.
The Installer prompts you for the following key credentials when you install ECE:
The alias name and key password for Oracle Coherence cluster security.
The key password for connecting to BRM and PDC. The password and alias name are the same for all BRM and PDC instances. The alias name cannot be changed.
The password for the keystores. The Installer automatically uses the same password for keystore.jks and server.jks.
For more information about the initial configuration of the key credentials, see BRM Elastic Charging Engine Installation Guide.
The keystore.jks and server.jks files are created in ECE_Home/oceceserver/config when you install ECE.
ECE uses keystore.jks to ensure secure interaction between ECE and the BRM and PDC updaters. ECE communicates with BRM and PDC using the following clients and XML files:
Pricing Updater: encrypted password stored in JMSConfiguration.xml
BRM Gateway: encrypted password stored in JMSConfiguration.xml, encrypted connect string stored in BRMConnectionConfiguration.xml
Customer Updater: encrypted password stored in QueueConfiguration.xml
When one of these clients tries to connect to BRM or PDC, it gets an encrypted password from the configuration file. To decrypt this password, the client uses the key password from jmxremote.password to access the key from keystore.jks. The client then uses this key to decrypt the encrypted password and connect to BRM or PDC.
If the password used to connect to BRM or PDC is changed or if a new BRM or PDC instance is added, you must encrypt the new password and manually update the encrypted password in the configuration files. Encrypting the password ensures secure communication between ECE and BRM or PDC.
To encrypt a new password for BRM or PDC:
Log in to ECC.
Enter the following command:
encrypt string keystore_pw
where string is the new password to be encrypted and keystore_pw is the password to the keystore.
The encrypt utility returns a message containing the encrypted value for the new password.
To update the encrypted password in the configuration files:
Do one of the following:
If you are updating a BRM password:
Open the ECE_Home/oceceserver/config/BRMConnectionConfiguration.xml file.
Search for the following text:
<BRMConfigurations>
<BRMConnectionConfiguration>
<ConnectString>password</ConnectString>
</BRMConnectionConfiguration>
</BRMConfigurations>
Change the value of password to the new encrypted password returned by the encrypt utility.
Open the ECE_Home/oceceserver/config/QueueConfiguration.xml file.
Search for the following text:
<QueueConfigurations>
<GatewayEntry>
<QueueConfiguration>
<HostName>host</HostName>
<Port>port</Port>
<sid>sid</sid>
<UserName>user</UserName>
<Password>password</Password>
<QueueName>queuename</QueueName>
<BatchSize>size</BatchSize>
</QueueConfiguration>
</GatewayEntry>
</QueueConfigurations>
The values for host, port, sid, user, queuename, and size are already populated. Do not change them.
Change the value of password to the new encrypted password returned by the encrypt utility
If you are updating a PDC password:
Open the ECE_Home/oceceserver/config/JMSConfiguration.xml file.
Search for the following text:
<MessagesConfigurations>
<JMSDestination>
<Password>password</Password>
</JMS Destination>
</MessagesConfigurations>
Change the value of password to the new encrypted password returned by the encrypt utility.
Save and close the updated files.
Restart the node. For information about restarting nodes, see "Starting and Stopping ECE".
To check keystore validity:
Log in to ECC.
Enter the following commands:
keytool -list -v -keystore server.jks password: storepassword keytool -list -v -storetype jceks -keystore keystore.jks password: storepassword
where storepassword is the password to the keystore.
ECC returns the contents of server.jks and keystore.jks, indicating that the keystore is valid.
If ECC denies permission, ensure that you have set the permissions to server.jks and keystore.jks as described in "Configuring Specific File Permissions".
If ECC does not return the contents of the JKS files, it could be for the following reasons:
The keystore JKS file was corrupted.
A system administrator must recreate the keystore.
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.
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).
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/oceceserver/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.
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 BRM Elastic Charging Engine Security Guide for more information about SSL.
To enable SSL:
Enable WKA. See "Enabling Well Known Addresses".
Open the ECE_Home/oceceserver/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/oceceserver/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/oceceserver/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.
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 Well Known Addresses (WKA).
To enable WKA:
Open the ECE_Home/oceceserver/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.
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.
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 the discussion of implementing system security in BRM System Administrator's Guide.
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 the discussion of enabling SSL in the CM in BRM System Administrator's Guide.
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/oceceserver/lib directory:
BRM_Home/jars/osdt_cert.jar
BRM_Home/jars/osdt_core.jar
BRM_Home/jars/oraclepki.jar
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, 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 BRM Gateway" for information.
SSL communication between BRM Gateway and the CM is now enabled.
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. For more information about this screen, see BRM Elastic Charging Engine Installation Guide.
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. For more information about this screen, see BRM Elastic Charging Engine Installation Guide.
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.