Lock up Your Data Warehouse – Part 2
By KLaker on Jul 26, 2009
Continuing on with this theme of securing your data warehouse…The next stage, having secured the transmission of all data be accessed via SQL net, is to make sure that all tools and applications, or as many as possible, use these encrypted network transmission processes. Lets look at some of these tools in more detail:
This requires the use of SQLDeveloper 1.5 or later. There are a number of ways to configure database connections in SQLDeveloper and SQLDeveloper 1.5 added the option to use the OCI/Thick driver rather than the standard JDBC connection. This option is located in the Database: Advanced Parameters section of the Preferences page.
Once this preference has been set it is then possible to define a connection based on an existing TNSNAMES.ora entry.
However, the trick is to make sure you have set your TNS_ADMIN directory prior to launching SQLDeveloper. Personally, I use a batch file to set my environment variables and launch SQLDeveloper so I know all my paths are correctly set. Without this information it is very difficult to determine which TNSNAMES.ora file SQLDeveloper is using to generate the list of TNS entries, especially if you have lots of Oracle homes as I do on my laptop.
Assuming you can find the correct the TNS entry then test the connection to make sure everything is working correctly.
If you have left the tracing parameters in your SQLNET.ora file as per the last blog post on this subject you should see a trace file created once the connection has been established. Executing a query will show that the network encryption is active and being used. As before you search for the “na_tns:” string in the trace file:
2009-07-01 14:35:59.236239 : na_tns:Secure Network Services is available.
2009-07-01 14:35:59.236298 : nau_adi:entry
2009-07-01 14:35:59.236354 : nau_adi:exit
2009-07-01 14:35:59.236411 : na_tns: authentication is not active
2009-07-01 14:35:59.236470 : na_tns: encryption is active, using RC4_256
2009-07-01 14:35:59.236530 : na_tns: crypto-checksumming is not active
This obviously shows that encryption is working but it would be nice if we could see what is happening on the network in real-time. This would allow us to check to see if the data is actually visible or not.
If we turn off all the security features and then execute a query from SQLDeveloper the sniffer will pick up the following which shows all the data that was returned from the database as a result of executing the query “SELECT * FROM products”
If we now turn on all the data encryption features described in the previous blog posting the trace looks very different:
In this case the data is encrypted and it is impossible to extract any meaning from the data being passed back to SQLDeveloper.
How do you control clients using ODBC? The temptation is to use the standard Microsoft but I find this provides too little control over the configuration process.
In my opinion it is better to install the Oracle ODBC driver that comes with the Database Client as this gives you more control and feedback over which TNSNAMES.ora file is being used.
Once you have defined the basic connection details and selected the correct TNS entry from the pull-down list it is always advisable to test the connection. If a successful connection is created a trace file will be generated that will show that the network encryption is active and being used. As before you search for the “na_tns:” string in the trace file.
To support data encryption for connections via JDBC Thin drivers there are additional libraries that need to be loaded as part of your project. All the security features have been built-in to the Java implementation. In the java environment the parameters that are usually managed by the SQLNet.ora file are instead defined within the oracle.jdbc.OracleConnection interface. However, there is a degree of caution needed here because Oracle only ships one version of its JDBC classes JAR file. This means the single JAR file has to conform to export regulations. Therefore, only settings permitted suitable for export markets are supported. Depending on where you are based and your specific security requirements this may or may not be an issue.
In terms of implementing data encryption and data integrity within a connection, you need to use the Java properties object, that is, an instance of java.util.Properties, to set the data encryption and integrity parameters supported by the JDBC Thin driver.
The following example instantiates a Java properties object and then uses the properties object in opening a connection to the database:
Properties prop = new Properties();
prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES, "( DES40C )");
prop.setProperty(OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPES, "( MD5 )");
OracleDataSource ods = new OracleDataSource();ods.setProperties(prop);ods.setURL("jdbc:oracle:thin:@localhost:1521:main");
Connection conn = ods.getConnection();
The parentheses around the values encryption type and checksum type allow for lists of values. When multiple values are supplied, the server and the client negotiate to determine which value is to be actually used.
There is a lot more information about this in the Oracle Database JDBC Developer's Guide and Reference 11g Release which you can access via OTN. I would recommend Chapter 9 as this deals specifically with JDBC client-side security features.
That is it. We have now successfully secured all data communications between our data warehouse and client applications using SQLNet, ODBC or JDBC. This means that anyone using a packet sniffer on your network is not going to be able to intercept data as it moves around the network. The next step is to directly encrypt the key sensitive data elements within the database. This provides the next level of “complete piece of mind” that only Oracle Security can provide.
If you have not started to look at data security within your data warehouse now is good time to start. In the next few postings I will look at some of the other security features you can add to your data warehouse to help you protect your most valuable asset.
For those customers who are currently evaluating solutions from the various data vendors (and hopefully you have included Oracle in your list!) make sure you look at security. Don’t just get blinded by performance make sure you can protect your data warehouse because you don’t want data leaking out to anyone and everyone. It is quite surprising the number of times we talk about security to data warehouse customers and the response comes back “we are not looking at security at the moment, this is just a POC”. That is not a smart move in my opinion because you do not want to be saddled with a data warehouse platform that just leaks data everywhere. Fortunately, Oracle Database Machine runs Oracle Database and comes ready to implement Oracle Maximum Security so you can be sure your data warehouse platform is both safe and secure.
More to follow…