Re: Question To Test My Sanity

Yeah I've run into that on Linux before depending on the organization - where we have to use a "jump" server and can't login directly to the primary db servers.
It's a pain when people decide this.

Usually because the CISO (or someone similar) decides to lock down the primary db servers both internally and externally. Do you know if they're going through a security audit?
I think that's one of the checks in one (or more) of the security audit checklists put out by whatever organization's standards they're trying to meet.

Chris

On Thu, Apr 11, 2019 at 7:07 AM Scott Canaan <srcdco_at_rit.edu> wrote:

> This is not so much of a technical question, but more of a procedural
> question.
>
>
>
> Here’s the back story. Yesterday, we were told by the Windows Sys Admins
> that they’ve decided that we (DBAs) are no longer allowed to access
> databases running on Windows servers directly from our PCs. We now have to
> remote into another server, called dbatools, and only from there can we
> directly access databases. They’ve loaded our tools (TOAD, PL/SQL
> Developer, SQL Server Management Studio, etc.) on that server and are in
> the process of removing our IP addresses from the firewalls on the Windows
> servers, forcing us to use this one server for all of our access.
>
>
>
> When I asked why, the only answer I got was “security”. What I read into
> that is “We don’t trust you”. This is being done without any input from us
> or any discussion, it’s just happening.
>
>
>
> The question: Has anyone else run into this kind of setup? Is this a
> common configuration?
>
>
>
> Thank you,
>
>
>
> *Scott Canaan ‘88*
>
> *Sr Database Administrator *Information & Technology Services
> Finance & Administration
>
>
> *Rochester Institute of Technology *o: (585) 475-7886 | f: (585) 475-7520
>
> *srcdco_at_rit.edu <srcdco_at_rit.edu>* | c: (585) 339-8659
>
> *CONFIDENTIALITY NOTE*: The information transmitted, including
> attachments, is intended only for the person(s) or entity to which it is
> addressed and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of, or taking of any
> action in reliance upon this information by persons or entities other than
> the intended recipient is prohibited. If you received this in error, please
> contact the sender and destroy any copies of this information.
>
>
>

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