To avoid potential security threats, customers operating DIVAnet must be concerned about authentication and authorization of the system.
These security threats can be minimized by proper configuration and by following the postinstallation checklist in Appendix A.
The critical security features that provide protections against security threats are:
Authentication - Ensures that only authorized individuals are granted access to the system and data.
Authorization - Access control to system privileges and data. This feature builds on authentication to ensure that individuals get only appropriate access.
DIVAnet services can perform authentication using several methods:
SSL / TLS Certificates - DIVAnet consults a certificate truststore when DIVAnet creates an outbound connection to a remote DIVAnet service. This helps to insure that DIVAnet is connecting to genuine DIVAnet services. To create a secure connection from the DIVAnet ClientAdapter to a ManagerAdapter instance, you must connect through the ManagerAdapter using a ConnectionType identified as WebServices.
Access Rules - While technically a form of access control, access rules can filter inbound connections based on the inbound IP address. This feature is necessary to help insure that only approved systems have appropriate access to DIVAnet services.
Caution:
DIVAnet services use database passwords as part of their configuration. Passwords must be changed immediately after installation and every 180 days (minimum) thereafter. After the change has been made, you must store the passwords in a safe location, offline, where they can be made available for Oracle Support if needed.User Login - Consider configuring a user login for DIVAnet UI, especially when accessing the UI from remote networks. To do this, use DIVAnetAdmin to create a username and password. Set the ClientAdapter parameter UserAuthEnabled to true. Then, configure DIVAnet UI to prompt for a username/password by setting the parameter userlogin to true in the divanetui.properties file.
Database Password - Consider using the DIVAnetAdmin option to encrypt the database password, especially if the database is remote or shared with other systems. Follow the instructions in DIVAnetAdmin to update the DIVAnet configuration files.
Access rules can be created to limit the operations that certain users or systems may perform in the distributed archive system. Access rules can be run in the following ways:
ClientAdapter /MultiDiva Mode - Restricts the types of DIVAnet requests that can be executed.
ManagerAdapter - Restricts the types of DIVArchive requests that can be executed to satisfy a DIVAnet request (possibly requested by a remote system).
Access rules can affect requests initiated from the DIVAnetUI or from an API socket connection (possibly initiated by a MAM or automation system).
A DIVAnet request can have access rules executed on it at the DIVAnet level or at the DIVArchive level. At the DIVAnet level, the ClientAdapter processes the request where the request was received. At the DIVArchive level, a remote ManagerAdapter processes DIVArchive requests issued to satisfy the DIVAnet request.
Oracle recommends you create the most restrictive set of rules that meet your application requirements. For example, if only administrators need to perform global deletes, insure that others are denied access to that functionality. If a group of system users only require access to a finite list of Sources and Destinations, insure that those users can issue requests against only those specific Sources and Destinations.
Also consider the sites used to satisfy requests. For example, if users on the local site have no reason to perform copies where neither the source nor target sites are the local site (this is possible using DIVAnet), configure these rules in the ClientAdapter configuration.
Finally, consider specific constructs in requests you want to exclude across the board. For example, if you do not need to address objects with only the Object Name (without the category), then exclude all requests having blank categories.
Additionally, each ClientAdapter WorkflowProfile contains the list of valid messages that can be processed by requests assigned to the WorkflowProfile. In MultiDiva Mode, this provides a way of excluding specific messages from processing (including informational messages).
Oracle recommends starting with the default rules defined in the AccessRules.xml.ini file even if you do not define your own access rules. For more information on DIVAnet Access Control features, refer to the Oracle DIVAnet Installation, Configuration, and Operations Guide at:
SSL/TLSYou can use SSL in the following components:
In the ClientAdapter, for web/UI connections. To enable, set the top-level parameter SSLWebServicePort in the ClientAdapter configuration to true (true is the default).
In the ClientAdapter, for DIVA API socket connections. To enable (you must be using DIVA API version 7.6. or greater), set the parameter SSLSocket in the ApiPorts section of the ClientAdapter configuration to true.
In the ManagerAdapter, for web service connections. To enable, set the top-level parameter SSLWebServicePort in the ManagerAdapter configuration to true (true is the default).
In the ManagerAdapter, for the socket connection to the DIVA Manager. To enable, set the top-level parameter ManagerSSLSocket to true (DIVA 7.6 or greater is required).
In the DbSync service, for web service connections. To enable, set the top-level parameter SSLWebServicePort in the DbSync configuration to true (true is the default).
In the connection to the Oracle database. To enable, in the database section of DIVAnet configuration files, set the parameter SecureMode to 1. You may need to set the cipher suite "SSL_DH_anon_WITH_3DES_EDE_CBC_SHA" in the Oracle listener configuration. In this release, DIVAnet does not support database authentication using SSL.
DIVAnet contains certificate data in two places: a private keystore, used for web services hosted on the local system, and a public keystore, used to verify web services that are invoked remotely. You can use the Java Keytool Utility to change the keystore password and add and delete certificates.
Refer to the following for more information regarding creating keystores:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#CreateKeystore
For DIVAnet web services, private key certificate data is stored in:
$DIVANET_HOME/Program/divanet/lib/diva129.jks
Exactly one certificate must appear in this keystore. This certificate is used for web services hosted by services running from this $DIVANET_HOME directory. It is recommended to replace the shipped certificate with a new certificate, and use a different certificate for each DIVAnet site in your network.
You must change the password of this keystore. Store the password information in a new file named $DIVANET_HOME/Program/divanet/lib/diva129.properties, and make this file readable by DIVAnet services (in Linux this user is divanetsvc), but not readable by casual users of the system (for example, the diva user in Linux). Use the following format for the file:
keystorePassword=newpassword
To configure DIVA API socket connections certificates in the DIVAnet product, see the Oracle DIVArchive 7.6 Security Guide.
Sometimes referred to as the truststore for web services, this data is located in:
$DIVANET_HOME/Java/lib/security/cacerts2
This certificate data is used in outbound web service calls (including DIVAnetUI). Multiple public keys can be loaded into this keystore.
If you added a new self-signed certificate into the DIVAnet private keystore, export the certificate using the keytool utility. All of the applications (DIVAnet services, DIVAnetUI, and so on) that invoke WebServices on this site should then add the exported certificate to their own public keystore.
Refer to the Oracle DIVArchive 7.6 Security Guide for information about the public keystore for DIVA API socket connections.