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 DIVArchive 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.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/TLSDIVAnet 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
Only the DIVAnet web services connections use SSL/TLS. In this release, connecting to DIVArchive or DIVAnet using a DIVArchive API socket connection will not use SSL/TLS.
DIVAnet 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
Sometimes referred to as the truststore, 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.