Preventing an application from accessing a database - oracle

Question

We have a terminal server that has two copies of our application: a live version, and a test version.
These are 2 icons on the users desktop. Now when you launch the application, you type in the name of the oracle database that the application connects to.
We want to prevent users accessing the production database when they use the TEST icon, and prevent users accessing the TEST environments when they use the PROD icon.
Unfortunately we can't do this through the application, and we do not want to go down the route of getting the application modified by the vendor. The application uses a single tnsnames.ora file to connect to the database for both the test version and the prod version, so we can't change this (unless there is a way to use multiples?).
I was thinking we could have a local firewall that would prevent the test application from accessing the live server (just block the connection), but at the moment, they are both on the same server!
So, can anyone think of a way to prevent a certain application accessing an Oracle database? The application EXE has the same name, but it is run from a different path depending if it is a test version or the prod version.

Answer 1

Since you have control of the environment on the terminal server, one fairly simple option is to wrap the application in a batch file that forces it to use a restricted tnsnames.ora.
Create two directories, e.g. test_tns_admin and live_tns_admin. Put a copy of your tnsnames.ora in each directory, but edit them so each only has the TNS alias for one target database.
Create two batch files, e.g. live.bat and test.bat. In each, set the TNS_ADMIN admin variable to point to the appropriate directory, and then launch the real application. So test.bat might look like:
::Batch wrapper for the TEST application
#set TNS_ADMIN="\path\to\test_tns_admin"
#"\path\to\real\application.exe"
... and live.bat is the same but pointing to the other directory. You can put shortcuts to the batch files on the desktop instead of the real applications. When one of those is run and the the application launches, the TNS_ADMIN will mean it picks up the cut-down tns_names.ora, so only the TEST TNS alias will be recognised. Nothing else on the terminal server or database is affected.
You don't even really need two new tnsnames.ora files; you could remove the TEST alias from the existing system-wide one and leave the live application alone, only replacing the test launcher with a batch file - that might be preferable since live isn't touched, but depends how you want to manage it, and whether it will be clearer to have them both working the same way.

Answer 2

There is a view called v$session
and the query bellow shows any session information
select username,program
from v$session
You may have a table for listing restricted(or allowed) program names
CREATE TABLE RESTRICTED_PROGRAMS(
PROGRAM_NAME VARCHAR2(64))
INSERT INTO RESTRICTED_PROGRAMS VALUES ('TEST.exe');
COMMIT;
you can use the script bellow to create a AFTER LOGON ON TRIGGER
CREATE OR REPLACE TRIGGER logon_audit
AFTER LOGON ON database
DECLARE
v_program VARCHAR2(100);
BEGIN
SELECT program into v_program;
FROM v$session
WHERE audsid = userenv('sessionid');
for x in (SELECT * FROM RESTRICTED_PROGRAMS) loop
IF upper(v_program) == upper(x.PROGRAM_NAME) THEN
RAISE_APPLICATION_ERROR(-20001,
'You are not allowed to login using ' ||
v_program);
end if;
end loop;
END;
If a user can connect to you database using application X.exe, then if they rename Y.exe to X then they're still in.