Skip Headers
Oracle® Retail Merchandising Security Guide
Release 14.1.1
E61235-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

19 General Security Considerations

This chapter discusses how to securely install the Oracle Retail Price Management (RPM) application. To obtain a secure configuration, follow the instructions and advice provided below.

The RPM application is installed on the server; however it is used in the distributed environment. Both client and server security must be taken into consideration when hardening application deployment. You need to reference your desktop and server operation system security guides, if available for more information on reinforcing security for the execution environment.

In particular, only valid users should have access to the client workstations running clients for the application. Since the RPM user interface has no inactivity timeouts, a reasonable locking policy should be established to lock out computer screens after some time of inactivity. Security policy should be established at the desktop level to monitor unsuccessful login attempts. System administrator should guarantee that the operation system has the latest mandatory update patches.

As RPM client executes in the Java sandbox, it is important to keep Java runtime up-to-date with the latest security patches. Java runtime can be provided by either a browser plug-in or by standalone JVM such as the one shipped with JDK. You need to make sure that runtime configuration for appropriate Java version is correct. See Figure 19-1 for example on how Java runtime environment settings window looks like.

Figure 19-1 Java Runtime Environment Settings Window

Surrounding text describes Figure 19-1 .

Ensure the following:

System administrator should restrict users from modifying security setting for Java runtime. At the same time the user should be allowed to accept JNLP security requests. Only signed trusted code should be downloaded and run. The system should check that the certificate matches hostname of the server. The retailer should be registered as a trusted publisher with the workstation. SSL should be enabled on the client.

For more information of how secure the internal network used to access RPM server(s), see Network Security Configuration Guide. This should include both physical and logical security of the network. Only SSL enabled communication should be used.

Only the desktops on the intranet should be allowed accessing the application server. The best approach is to limit the set of client computers on the network that can access the application server. That can be done at the network level to prevent guest users on the local network from even seeing the application server.

Only system administrators should have access to the application server(s). Business users (even power users) should not have accounts on the application server computers. If such accounts do exist, the OS account privileges should prevent business user from accessing application server files/directories associated with ReIM application.

The users running batches should not be system administrators. The best approach is to have a single dedicated user for running batches, rather than having multiple users running batches ad hoc. At the same time RPM application does not prevent any valid application user from running batches. The main difference between batch user and regular users is that batch user credentials exist in the Secure Wallet. Installer is the one responsible for placing batch user credentials into the wallet, so by default there will be only a single batch user. At the same time nothing is preventing the system admin from adding additional valid RPM users into Secure Wallet (by running provided scripts).

RPM both consumes and produces data files. File consumption is done on the client side where a user can select a file on the file system containing a Price Event Item List. Only CSV and Excel file types are allowed. It is recommended that the file transfer to the client workstation is done through secure FTP (in case the file is not generated on the same workstation). File generation is done on the server. It is recommended to keep the file being uploaded for audit purposes. It is up to the retailer to provide the process for that. The files can be kept in an audit directory or using any other appropriate document management system that would allow easy retrieval later on. Generated price event files are transmitted through secure FTP.