Re: Block connection from SQL developer

On the other hand you have the very trendy and fashionable DEV-OPS and even DEV-SEC-OPS. How much of that is about the brave new future or is it more likely a cost-saving measure?

On Sun, Mar 13, 2022 at 7:05 PM Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> On 3/13/22 11:42, Dave Morgan wrote:
>
> The only practical way to control connection level access is with a logon
> trigger supported with automated auditing and monitoring. Limitations based
> on hostname and/or IP address can also be set in sqlnet.ora.
>
> Agreed
>
>
> In my environment the issue is developers who "have to" connect to
> production to "do their job".
> So, I do not return any errors I use a sleep(6000) call in the trigger. It
> is hard to complain about a problem when you should not be there
>
> There is no reason whatsoever for developer to connect to production. In
> the good old times of my youth (think Perl 4 and "oraperl") there was a
> saying cautioning people to not trust programmers carrying screwdrivers.
> The times of programmers with screwdrivers and pliers are long gone but the
> same saying is applicable to the production databases: developers have no
> business connecting to the production database of, for that matter,
> production application server(s). Developers should document their products
> so that they can be installed by the maintenance engineers. Any developer
> caught trying to connect to the higher environments (QA, UAT, PROD) should
> be terminated on the spot. One of the foremost security measures is the
> separation of duties and the physical separation of the environments.
>
> The infamous "Solar Winds" case was caused by an intern in charge of the
> software upload site and the weal password (SolarWinds123). I hope that the
> intern has now been promoted to the managerial position of PHB. The vast
> majority of break-ins is caused by the human error. Developer with access
> to the higher environments is pretty typical. If things are supposed to be
> confidential, then confide in very few people and make sure that nobody
> else has the confidential information. It's elementary, my dear Dave.
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217https://dbwhisperer.wordpress.com
>
> -- http://www.freelists.org/webpage/oracle-l

-- 
+353-86-0695383

--
http://www.freelists.org/webpage/oracle-l