What good are databases if you cannot use them

Question

Hello;
My company has the same model for access to database no matter if its Production, Test or Dev.
I believe the one size fits all model is incorrect and would like some feedback Pro and Con why access should be the same or different.
Pete

Answer 1

rp0428 wrote:
OP wrote:
>
Version has nothing to do with the question.
I'm looking for feedback on what security differances there should be between different types of databases.
>
The only reason version has nothing to do with the question is because you are now clarifying your question to state that you want version ignored. Mark was correct since different versions have different functionality, e.g. compression and encryption support. You can't expect the same policy for a DEV database that doesn't support encryption as you have for a PROD database that does. Same with RAC - many shops don't use RAC for dev.
Also you never responded to Mark's other comment:
>
You provide no description of exactly what restrictions your employer has in place that you have difficulty with
>
Would you support these policies for all of your environments?
>
1. The schema owner can delete data from any table they choose whenever they want.
2. The schema owner can grant all privileges to their objects to whomever they want.
>
I sure hope that isn't what you mean.
The point being that there are many restrictions that should be different between different environments in order to maintain the degree of control over those environments that is needed by the business.
The data in the PROD environment is usually more sensitive and can have legal requirements as to who is allowed access to that data and what they are allowed to do with the data. Those requirements can be vastly different than what are needed for a DEV environment.
So provide some specifics about what restrictions your employer has that you think cause a problem. Or provide an example of what you need to do in a particular environment and how you can get it done given the restrictions that are in place.
The only argument that I have ever found effective with management is to document the COST associated with a policy or rule that they have in place. The cost can be in resources, time. An example of this might be the overhead (resources, time) involved with having to log a service request, get a DBA or Weblogic person involved just to make a simple table change in DEV or see what errors might have been generated in a Weblogic log file.
If they realize that the turnaround for that is several days to do something you could have done in a few minutes if you had the proper access then sometimes (not often I agree) you can get some things changed.
But you have to make a convincing argument that the change is needed and that it won't compromise any of their other concerns.
Which gets us back to what Mark was trying to find out. What are the concerns that caused management to implement their current policy, whatever that policy is?But to counter that ... how often have we seen code go to production and fail, because it relied on the less restrictive environment in dev? With proper QA and code promotion management in place, this shouldn't happen, but I've too often seen that to not be the case. Certainly we've seen that situation with commercial software that "requires" the application to run with DBA authority - simply because the developers were too lazy to figure out what was really required.