| Oracle® Retail Advanced Science Engine Security Guide Release 14.1 E59123-01 |
|
 Previous |
 Next |
The application supports the use of the Oracle Database 12 c Release 1. The database must be secured using the recommendations provided in the Oracle Database Security Guide. This chapter provides additional specific guidance for securing the database for use with the application. It includes the following sections:
Before you start setting up the database, ensure that you have installed all the critical patch updates (CPU) and patches for the database. Critical patch updates and patch sets for Oracle products are made available on the My Oracle Support Web site along with documentation or instructions on how you can install them.
The following recommendations should be considered for the schema owners:
Database Administrators should create an individual schema owner for each database schema (specify application schemas).
The schema owners should only have enough access privileges to install the application.
For more information on creating database user accounts and the specific access privileges for the schema owners, see the section Creating the Data User Accounts in the chapter Setting Up the Database of the relevant installation guide.
It is recommended that the user ID and password comply with the following policies:
Do not use group, shared, or generic accounts and passwords.
Require a minimum password length of at least seven characters.
Use passwords containing both numeric and alphabetic characters.
Do not allow an individual to submit a new password that is the same as any of the last four passwords used.
Limit repeated access attempts by locking out the user ID after not more than six attempts.
Set the lockout duration to 35 minutes or until an administrator enables the user ID.
|
Note: You can also choose to change user passwords at least every 90 days. In case you do choose to set this policy, ensure that the passwords set up in the connection pools for the application data sources in the WebLogic Server Administration Console are also updated to reflect the latest password. Once updated, the WebLogic server will need to be restarted for the changes to take effect. |
The following recommendations should be considered for the database:
The database should be on its own dedicated server.
The database server should be in a private network.
The database server should be in a locked secure facility and inaccessible to non-administrator personnel.
The database should only be accessed using trusted network hosts.
The database server should have minimal use of ports and any communications should be under secure protocols.
The database server should be behind a firewall.
Any database user beyond the schema application owner should be audited.
Only minimal rights should be granted to the owner of database processes and files such that only this owner has the right to read and write from the database related files and no one else has the capability to read and write from such files.
Password policies can be enforced using database profiles. The options in the following table are based on version 12c Release 1 of Oracle Database. The options can be changed using a SQL statement, for example:
alter profile appsample limit
| Option | Setting | Description |
|---|---|---|
| PASSWORD_LOCK_TIME | 30 | Time account will be locked in minutes |
| FAILED_LOGIN_ATTEMPTS | 4 | Maximum number of login attempts before the account is locked |
| PASSWORD_GRACE_TIME | 3 | Number of days a user has to change an expired password before the account is locked |
| PASSWORD_REUSE_MAX | 10 | Number of unique passwords the user must supply before the first password can be reused |
| PASSWORD_VERIFY_FUNCTION | <routine_name> | Name of the procedure that can be created to ensure the password is acceptable |
Password policies can be enforced using a password complexity verification script, for example:
UTLPWDMG.SQL
Secure Sockets Layer (SSL) is the standard protocol for secure communications, providing mechanisms for data integrity and encryption. This can protect the messages sent and received by the database to applications or other clients, supporting secure authentication and messaging. Configuring SSL for databases requires configuration on both the server and clients, which include application servers.
This section covers the steps for securing Oracle Retail Application Clusters (RAC) database. Similar steps can be followed for single node installations also.
The following steps are one way to configure SSL communications on the database server:
Obtain an identity (private key and digital certificate) and trust (certificates of trusted certificate authorities) for the database server from a Certificate Authority.
Create a folder containing the wallet for storing the certificate information. For Real Application Cluster (RAC) systems, this directory can be shared by all nodes in the cluster for easier maintenance.
mkdir /oracle/secure_wallet
Create a wallet in the path. For example,
orapki wallet create -wallet /oracle/secure_wallet -auto_login
Import each trust chain certificate into the wallet as shown in the following example:
orapki wallet add -wallet /oracle/secure_wallet -trusted_cert -cert <trust chain certificate>
Import the certificate into the wallet, as shown in the following example:
orapki wallet add -wallet /oracle/secure_wallet -user_cert -cert <certificate file location>
Update the listener.ora by adding a TCPS protocol end-point first in the list of end points.
LISTENER1=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcps)(HOST=<dbserver name>)(PORT=2484))
(ADDRESS=(PROTOCOL=tcp)(HOST=<dbserver name>)(PORT=1521)))
Update the listener.ora by adding the wallet location and disabling SSL authentication.
WALLET_LOCATION = (SOURCE= (METHOD=File) (METHOD_DATA= (DIRECTORY=wallet_location))) SSL_CLIENT_AUTHENTICATION=FALSE
Update the sqlnet.ora with the same wallet location information and disabling SSL authentication.
WALLET_LOCATION = (SOURCE= (METHOD=File) (METHOD_DATA= (DIRECTORY=wallet_location))) SSL_CLIENT_AUTHENTICATION=FALSE
Update the tnsnames.ora to configure a database alias using TCPS protocol for connections.
<dbname>_secure=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCPS)(HOST=<dbserver>)(PORT=2484)))
(CONNECT_DATA=(SERVICE_NAME=<dbname>)))
Restart the database listener to pick up listener.ora changes.
Verify the connections are successful to the new <dbname>_secure alias.
At this point either the new secure alias can be used to connect to the database, or the regular alias can be modified to use TCPS protocol.
Export the identity certificate so that it can be imported on the client systems.
orapki wallet export -wallet /oracle/secure_wallet -dn <full dn of identity certificate> -cert <filename_to_create>
The following steps are one way to configure SSL communications on the database client:
Create a folder containing the wallet for storing the certificate information.
mkdir /oracle/secure_wallet
Create a wallet in the path. For example,
orapki wallet create -wallet /oracle/secure_wallet -auto_login
Import each trust chain certificate into the wallet, as shown in the following example:
orapki wallet add -wallet /oracle/secure_wallet -trusted_cert -cert <trust chain certificate>
Import the identity certificate into the wallet, as shown in the following example:
orapki wallet add -wallet /oracle/secure_wallet -trusted_cert -cert <certificate file location>
|
Note: On the client the identity certificate is imported as a trusted certificate, whereas on the server it is imported as a user certificate. |
Update the sqlnet.ora with the wallet location information and disabling SSL authentication.
WALLET_LOCATION = (SOURCE= (METHOD=File) (METHOD_DATA= (DIRECTORY=wallet_location))) SSL_CLIENT_AUTHENTICATION=FALSE
Update the tnsnames.ora to configure a database alias using TCPS protocol for connections.
<dbname>_secure=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCPS)(HOST=<dbserver>)(PORT=2484)))
(CONNECT_DATA=(SERVICE_NAME=<dbname>)))
Verify the connections are successful to the new <dbname>_secure alias.
At this point either the new secure alias can be used to connect to the database, or the regular alias can be modified to use TCPS protocol.
The following steps are one way to configure SSL communications for a Java Database Connectivity (JDBC) thin client:
Create a folder containing the keystore with the certificate information.
mkdir /oracle/secure_jdbc
Create a keystore in the path. For example,
keytool -genkey -alias jdbcwallet -keyalg RSA -keystore /oracle/secure_jdbc/truststore.jks -keysize 2048
Import the certificate into the trust store as shown in the following example:
keytool -import -alias db_cert -keystore /oracle/secure_jdbc/truststore.jks -file <db certificate file>
JDBC clients can use the following URL format for JDBC connections:
jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS= (PROTOCOL=tcps) (HOST=<dbserver>) (PORT=2484)) (CONNECT_DATA= (SERVICE_NAME=<dbname>)))
You need to set the properties as shown in Setting Properties, either as system properties or as JDBC connection properties.
To configure Oracle Wallet for batch script execution, complete the following steps:
Create a wallet (for example, in /home/jdbc/wallet_db):
mkstore -wrl /home/jdbc/wallet_db -create
Store the credentials in the wallet:
mkstore -wrl /home/jdbc/wallet_db -createCredential RME_DB rme_schema
In the environment setup script, specify the wallet location:
export TNS_ADMIN=/home/jdbc/wallet_db
Create tnsnames.ora in the wallet location:
RME_DB=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=SERVICE_0)))
Create sqlnet.ora in the wallet location:
WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/home/jdbc/wallet_db)))SQLNET.WALLET_OVERRIDE=TRUESSL_CLIENT_AUTHENTICATION=FALSE
