Locking Schema Owner account in oracle

Question

Hi
One of the oracle security policy recommendations is to lock the owning schema in the database. To overcome this issue I suggested to the developer that I can create a new access account with permissions to select ,insert,delete and update data on owning schema. But the developer is insisting that instead of creating that new account, should transfer the objects of the schema owner account to a new account and unlock the schema owner account this way he does not have to make changes to the application on his side...this did not make sense to me ,can some one please shed some light on this?

Answer 1

>
sorry , I meant that when we lock the schema owner ,connecting to the database with that account is denied. What I suggested is to create an access account with SUID priviliges on owning schema data. But the developer insists that I create a new account transfer the objects/data from schema owner to this new account and then unlock the schema owner account. This way he will not have to make changes on the application side,I was not entirely sure how it will benefit him by doing so
>
You still haven't stated what the actual issue is you are trying to address.
From the first post is seemed that your question was 'How can we implement the Oracle security recommendation to lock the application account without actually locking the application account'?
And your proposed solution is to create another account with exactly the same privileges as the schema owner and use that account instead.
That doesn't implement the recommendation. That is an attempt to circumvent the recommendation.
My advice is that if you don't want to actually implement Oracle's recommendation then don't implement it.
And if you do want to implement the recommendation then do so. But none of the options you are suggesting implement it they only circumvent it.
>
One of the oracle security policy recommendations is to lock the owning schema in the database
>
What is the citation for this statement? What reason was given for the recommendation?
One primary reason for using application users (rather than schema users) is to exert positive control over the functionality and data that the application has access to.
A schema owner has access to all objects owned by the schema. Applications typically don't need all of those privileges. A schema owner can create new objects and modify existing objects; applications seldom need to be able to do that.
Within a stored procedure a schema owner still has access to all of the schemas objects but other users/applications only have access granted directly to them and do not have access to objects granted only thru roles.
To properly implement the recommendation you need to create an application user and grant that user the roles and direct grants that are needed for the functionality and data that needs to be accessed. The result is two users: one has full access to the schema objects and the other has limited access. Application code should use the limited user credentials.
What you call the users is up to you. If you want to switch roles and make your current user the limited user and create a new user for the objects and move them all to the new schema go ahead.
But that is a lot of work and validation for you to have to do. The only change a developer should have to make to use a different user is to change the connection information. That should be very simple to do and if it is not it needs to be changed to make it simple.
Based only on the information you have provided it sounds like the developer is just lazy and wants you to have to do all of the work. So the developer needs to make their case as to why they can't just change connection settings and then management can make a decision about which method should be used.
Your work should be to create a new application account that specifically is NOT simply an account superuser but is only granted, either directly or via roles, the specific privileges that the application actually needs. My guess would be that no one actually knows or has documented what privileges are really needed so they just want them all.
The best contribution you could make for security is to resist the super user approach and actuallly push for documentation of the privileges needed and then implement those.
Management and auditors must ALWAYS be able to control and determine who is actually using their data.
I would suggest that you create a new user account account