RE: FLASHBACK ANY TABLE
Date: Wed, 18 Mar 2015 12:15:31 -0400
Message-ID: <048301d06196$c2cda4b0$4868ee10$_at_rsiz.com>
When you say “ebusiness” are you talking about Oracle’s off the shelf applications?
IF so, it is highly unlikely you can routinely flashback a table other than, perhaps some “interface” and “import” tables without compromising the overall relational integrity of the system.
Unless explicitly defined OUT, I would take it was a routine assumption that a “DBA” or the “DBA team” is responsible for the overall recovery thread and relational integrity of production systems in their charge. A management structure that prevents you from executing this responsibility needs to be known and documented to the officer level, not as “cover my ass” but to establish the parameters of the risk created to be judged by those with fiduciary responsibility.
A likely memo starts something like: “I (We) can and will do [this], but we need to be sure you are aware of the fundamental risks this practice creates before we allow this as a practice on production systems. For isolated emergency incidents if it is not approved as a routine practice, we would like the DBA team to be involved in ensuring we can restore all point in time threads that may be needed before [this] takes place.
(Notice I wrote “production” in there somewhere.)
If these folks need experimental playgrounds, you probably need something like Delphix. If we’re talking about production databases and the responsibilities of a DBA, I personally think that is an issue to push the edge on politely but firmly to the point of an officer sign-off or resignation.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of MARK BRINSMEAD
Sent: Wednesday, March 18, 2015 11:30 AM
To: Kumar Madduri
Cc: coloradodba_at_gmail.com; oracle Freelists
Subject: Re: FLASHBACK ANY TABLE
*sigh*.
Yeah. I know that feeling, too. All too well.
On the plus side, if the directors have approved this -- over your objections -- it will be (somewhat) more difficult for them to blame you for the disasters that eventually arise from it.
Good luck!
On Wed, Mar 18, 2015 at 10:56 AM, Kumar Madduri <ksmadduri_at_gmail.com> wrote:
Thanks Mark. I have raised those points as well with my manager.
The problem is the developers get approvals from 'directors' who think they are technical and don't like to be questioned by the DBAs. I still do and get in to bad books :)
On Wed, Mar 18, 2015 at 7:21 AM, MARK BRINSMEAD <mark.brinsmead_at_gmail.com> wrote:
Security considerations aside (and they are completely valid considerations), you should probably talk to the developers and find out exactly what they are thinking, and WHY they think the need to be able to flashback tables.
Is this a feature that they plan to rely on in their code? Do they understand that it is not guaranteed to work? (It will fail if you don't have enough UNDO on hand to reach the requested SCN.) Do they have a plan for dealing with it when it does fail? Have they considered how this might affect concurrency?
Your developers may be rock-solid and know exactly what they are doing and why they are doing it. In my own experience, though, I have rarely (but sometimes!) found that to be the case. :-)
On Wed, Mar 18, 2015 at 8:09 AM, Brent Day <coloradodba_at_gmail.com> wrote:
Kumar,
You are right - this is a security risk and my recommendation would be to never grant any "ANY" system privileges. There have been many easily exploitable privilege escalations bugs around the "ANY" grants. While many of these have been fixed provided you keep up with CPU/PSU patching. The flashback any privilege in the past had problems - see CVE-2012-1751. While this has been fixed you just never know when some patch or upgrade may break this again.
As a general rule we do not allow any user or application account to have any of the ANY system privileges.
If I was in your position I would get with the developers and find out what they are trying to accomplish and maybe find an alternative method to meet the requirements without granting flashback any.
Hope that helps.
Brent
On Wed, Mar 18, 2015 at 5:50 AM, Kumar Madduri <ksmadduri_at_gmail.com> wrote:
Hello:
Our developers have requested flashback any table to be given to apps (in an ebusiness environment). They would not have the apps password in production. I think they are using it to build some feature in a custom app.
Regardless of their motivation, I think this is a security risk because why would a developer want this privilege in a production environment.
I cant think like a hacker but it does not sound right to me.
Want to confirm with the list if I am missing something ?
Thank you
Kumar
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Mar 18 2015 - 17:15:31 CET