With the Oracle 10g Oracle had given the power to the users the option to to connect to the database without discolosing the password. To me it poses a great level of security threat. Earlier, you had the OS authenticated accounts. In these cases you had the ability to control where these executions can be carried from, i.e from the server or form the remote OS. Hence it was a peace of mind from the prespective that as long as the server that you manage is secured. With the advent of Oracle wallet on 10g, the client had been given the ablitiy to setup a wallet and have the connection established to the database without the username or password. This would work great for those who run the batch scripts. But this also posess a great threat, that if that client's system were to be compromised, this would allow the connection to the database be established without even having to know what the username and password to the database. Adding to this fear, is that to know that not all those clients desktops are secured. Hence any one who knows to read the sqlnet.ora file can start probing the database and may eventually gain access legitimately.
So, my main interest is that is there a way one could have some control on these kind of access, like the ones we have for OPS$.
With the advent of Oracle wallet, the client has the ablitiy to setup a wallet and have the connection established to the database without the username or password.
As a matter of fact only the admins and the authorised person should have this previlege.
Private and public keys are shared between the parties and secure distribution of the key to each other is the problem. Worried about windows
Wallets stored in the registry of secure user profiles may be safe?
Strong Wallet encryption should solve the security threat.
As a matter of fact only the admins and the authorised person should have this previlege
You have no control on this to my knowledge. Any one who has access to your database and has an oracle client can do this.
Any one who has an oracle client, the tnsnames.ora file and knows how to configure the wallet_location in the sqlnet.ora, can create their own wallet and put in their legitimate user credentials and the service name to connect.
Just to make the point you have no control on who can do this, unless you control the oracle client installations on all the desktops and servers that access your database.
From that point they can connect to the database without having to use the password or username. Hence this poses that thread if/when that desktop were to be compromised, the hacker does not have to know the user's database username and password, instead all he may have to do is to go through a tnsnames.ora file and issue connect /@servicename and he/sh will establish the connection to the database. Hence if you start doing some analysis form the database for any kind of hacking, you could easily be miss lead thinking that access to be legitimate. But in reality your db had been compromised smoothly.