Database Reference
In-Depth Information
Success! We are now able to connect. From here, we can switch to PDB from CDB without having to use a
password. For example:
SYS@orcl3>alter session set container = pdborcl;
Session altered.
SYS@orcl3>select sys_context('userenv', 'con_name') from dual;
SYS_CONTEXT('USERENV','CON_NAME')
--------------------------------------------------------------------------------
PDBORCL
So it is still possible to enter the PDBs from your cron jobs without a password. Hurrah! This is good for security
purposes. It makes controlling the database from Unix cron jobs convenient.
If you wish to use multi-threading, remember you can't log on as
"/ as SYSDBA"
from Unix, which means you
will need to put the SYS password in your scripts or use the autologin feature of Oracle wallet, which is less secure, as
you are allowing
"oracle"
to secure itself. Note that killing multi-threaded sessions must be done from the DB using
ALTER KILL
(not from the OS command line).
But what if you want to use multi-threading? There is a potential third option, which is to set up your server-side
wallet from a separate Unix account other than
"oracle"
. Colleagues at Oracle Consulting Services inform me they
have done this and it is already common practice for client wallet connections. Some guidance on how to set up
wallets from a non-Oracle account is given at this URL, but please note that I have not tested this procedure for
server-side installation, and have up until this point been able to keep to my preferred option of running passwordless
scripts from Unix cron (
http://www.ora-solutions.net/web/2012/03/08/no-more-cleartext-passwords-in-
My view is that we already have the Unix method of access anyway, so why add another method of access
through the wallet? Two doors are harder to secure than one. So for the time being I will prioritize Unix cron access
over wallets.
To summarize:
1.
Splitting of high privilege
into sub privileges is not a 100% effective control due to
privilege escalation.
2.
Time-based
alternatives such as break-glass are also not 100% effective due to rootkitted
installation to extend the time window.
So in terms of risk we can draw a simple X/Y graph to show how these two methods (1 and 2) relate, as seen in
Figure
14-1
.
