JDBC Connection Pools considered unsafe
The conventional setup for a JDBC connection to database is through the use of connection pooling within the Application Server / Web Container or through an Application configuration files. These approach require the proliferation of access credentials information (username and password) to be widely distributed than acceptable by a Security Governance Policy. A configuration file or in any other standard readable location.
Typically applications have a configuration file that contains setup parameters to connect to a database. Some DBAs have problems with the fact that usernames and passwords are in clear text in config files.
I don't think this is possible with Oracle and JDBC, but I need some confirmation…
A possible compromise is to encrypt the password in the config file and decrypt it before setting up the connection. Of course, the decryption key should not be in the same config file. This will only solve accidental opening of the config file by unauthorized users.
There are two key approaches to JDBC Connections to database and both have a significant impact on the design of the system, such that it is not easy to move from one to the other without a significant rewrite. An Architect needs to consider the companies governance policy with regard to information technology security before choosing.
1) Every user has credentials, that are carried through the application, for the service that is being used by the Application; in your case the Oracle database uses those user credentials to connect to the database. The downside is that every user needs a credentials for each secure service. This is a reasonable secure approach but also requires the signficant extra work to provide and maintain the user credentials. Your database administrators will need to actively manage user credentials, which may run counter to your company’s security governance policies.
2) The Application database credentials are stored on a secure directory service, e.g. Secure LDAP. The Application accesses the directory service with the users’ credentials. The directory service returns the approriate credentials for the service being accessed.
In both cases the database credentials should be limited to perform the appropriate operations only. The credentials should reflect the requirements of the business processes, for example; they allow select from defined views/tables, insert into others, but not create, update or drop tables. In the second approach use seperate credentials for each major business process, e.g. Order Processing, Accounting, HR, etc.
However remember that security is like layers of an onion, if somebody has stripped away the layers to access the application, such that they can access the DB contection pool config file. They can probably Trojan the application to capture users’ credentials. This is where a good security governance policy comes in.
Security Governance is a complex issue that needs senior management commitment, because if you need this level of security for your live platform, it costs. You need to separate responsibilities of development from deployment, operations & user authority management. You may also need to have security auditors, who have full access to view changes but no ability to change the configuration. It if far from simple and is highly paid specialism.