Connection to the PL / SQL database through a JAVA application. SAFETY ISO 27001

Question

Connection to the PL / SQL database through a JAVA application. SAFETY ISO 27001

Navigation

#1 by (2 votes)

2

My java application is currently connecting to a pl / sql database, the username and password of the connection are in the jdbc file:

jdbc.username = xxxxxxx
  jdbc.password = xxxxxxx
  jdbc.url = xxxxxxxxxxxx

and Spring uses this data to create the connection, and finds this through the applicationContext.xml file

<!-- Carregamento do Arquivo de Configuracoes do JDBC -->
    <context:property-placeholder location="xxxx" />

<!-- Configuracao do DataSource -->
<bean id="dataSource" class="xxxxx">
    <property name="driverClassName" value="${jdbc.driverClassName}" />
    <property name="url" value="${jdbc.url}" />
    <property name="username" value="${jdbc.username}" />
    <property name="password" value="${jdbc.password}" />
</bean>

ISO 27001 asks that the connection password is not statically fixed to the code, as developers will no longer be able to access the database password. Any ideas how I can resolve this?

java

asked by anonymous 04.07.2016 / 16:49

1 answer

How to document parameters received by function "func_get_args"? PanelGrid does not divide columns with Repeat

score 2 · Accepted Answer

The default way to resolve this in the Java EE architecture is that connections to the database or any external sources in production are provided through settings on the application server such as Tomcat, Glassfish, JBoss / Wildfly, WebSphere, WebLogic.

In this way, only people authorized to administer the application server in different environments can effectively view and modify the password. The application only "trusts" through the configuration that data sources will be provided at runtime.

This technique uses JNDI technology, where the server provides the data sources configured in the JNDI registry and the applications installed on it can query and consume those objects.

If your application does not use or can not use an application server, other, less secure mechanisms include providing the authentication data:

Through configuration files in protected directories
Through environment variables with specific names
Through parameters that are passed to the application at startup

However, in these cases you have to be very careful not to end up printing the password in logs or even showing in some part of the application. It is not uncommon for a tool to print parameters and environment variables if the program crashes, or some systems also include features that show environment variables, for example.