Database Reference
In-Depth Information
C H A P T E R 11
Enhancing Security
Every year, the president of my company gives us a pep talk. Generally, he talks about the good things
we've done throughout the year as a company, and shares an itemized list of our failures or less-than-
stellar moments. At the end of the talk, the president recognizes the skills and commitment of the
employees and encourages us not only to continue doing what we're doing, but to do even more, taking
on every new challenge.
We need to have this is the same pep talk regarding computer security. We are doing well and
succeeding, but there are always new challenges and areas where we can do even more.
We have one specific area to address, which I've mentioned in earlier chapters. It has been a
weakness in all our Oracle applications: we have embedded passwords. And this problem is not going
away. We have removed all passwords from the code except the one for the application verification user,
appver
. Now we need to take additional steps to protect that password.
An additional weakness we have is risk of privileged user attack. Currently, if a rogue DBA (or hacker
with DBA privileges) wants, he can read all our passwords in the
t_app_conn_registry
table. Granted, he
would have to know some Java to reconstitute the
HashMap
. Anyone with access to the backup tapes or
archives might also be able to pull out the table and get access to all our application passwords. What we
need is data encryption at rest; that is, data encryption in the Oracle table and on disk.
In the previous chapter, we produced code that will store application connection strings from any
application running as any local user. This was convenient, but we need to formalize that process and
delegate it to an application verification administrator. We will introduce the
appver_admin
role for that
purpose and discuss the process of managing our application connection strings.
If an attacker succeeds in getting the
appver
password, we want to severely limit what he can do and
see in the database. We already have our login trigger, and
appver
only has access to a few procedures
and limited data for our application security process. But we will see that every user in Oracle database
has access to
PUBLIC
data that we would prefer to not expose, so we will attempt to tighten our general
Oracle application security.
Hide the APPVER Connection String
We are not going to solve the embedded password problem, and you might be wondering why. In a
nutshell, this is a “chicken or egg” problem. Perhaps we could hide our passwords in Oracle database,
but we would need an Oracle password to request them from the database.
You cannot talk to Oracle database without a user/password, so the question arises of where to store
the password. We have solved that issue for all our application passwords except for the gatekeeper
account,
appver
. So let's look at some of the prospective solutions for hiding that password.
