Jimbo1 wrote:
> Hello there,
>
> I'm currently working for a company developing applications for a
> seperate live site, who do not run batch jobs within the database
> because they see it as a "Security Risk".
>
> I've recently completed some work that I personally believe would be
> better off being run via the DBMS_JOB package rather than an OS batch
> job. I have never encountered this "Security Risk" argument before.
>
> Their argument is that the DBA's on the live system often connect using
> OS-authenticated logons. The argument goes that if a hacker managed to
> penetrate the network, they would be able to connect to the database
> directly as they'd already be authenticated on the network.
>
> Now this to me sounds like a huge security risk, so if they are
> prepared to do this, I can't understand what they have against running
> DBMS_JOB. Their argument against it is that once the hacker is on the
> database, they could then set up 'trojan horse' style batch jobs to
> run.
>
> Now, my argument against this is:
>
> 1. If they reach the database, they could do a lot of damage anyway,
> and what is to stop them using DBMS_JOB as things currently stand? They
> can only execute it under the privs of the user they connect as. If
> this is the SYS user, then why are we allowing automatic authentication
> anyway?!
>
> 2. When the DBA's can routinely monitor which jobs are running via the
> DBA_JOBS dictionary view, they could easily see if somebody has created
> an erroneous job.
>
> 3. What is to currently stop somebody creating a 'trojan horse' batch
> job in the OS, and then by being able to get this job to automatically
> connect to the Oracle database, wreak havock in this way. Surely for an
> active DBA, this would be harder to spot than an entry in the DBA_JOBS
> dictionary view!
>
>>From what I've heard about the DBA team on site ( who I've not actually
> met to be fair to them), they seem to be, ahem, 'reluctant' when it
> comes to anything that might disturph their daily routine of minimal
> hassle, so I want to be prepared when the politics of my change come up
> for discussion.
>
> If anybody reading this feels they can contribute anything else to
> support my arguments (or the site DBA's), please feel free to
> contribute.
>
> Cheers.
>
> James
DBMS_JOBS and now in 10g DBMS_SCHEDULER are substantially lower risk
than what they are currently doing.
--
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)
Received on Mon Dec 19 2005 - 16:05:04 CST
