I'd like to authorize the user/application combination, not only the user.
The scenario is that we've built an app that guides the user to safe updates of some data.
If the same user installs PL/SQL Dev, Toad, or any other Oracle management tool, she can edit the data in ways that the app prohibits.
Vincent's answer is good (and he also makes a good point in his comment about spoofing the executable).
For a more programmatic method (no mid tier), see my answer to a similar question. It basically involves coding an ALTER SESSION into your application that enables a role.
You can use a proxy user to restrict access to the database. Your users would only be able to connect (authentication) and activate a role (authorization) through the middle-tier account. They would not need to know their DB password. They can be authenticated externally (with AD for example).
See this thread on AskTom and the documentation for further reading.
The v$session view contains a column 'program'. This contains the name of the connected application. You may be able to use this information.
To determine the sessions ID use this:
select
sys_context('USERENV','SID')
from dual;
Related
In the Oracle documentation, it is repeatedly mentioned that it is preferable for all users of an application to be database users instead of just records in some kind of 'user' table for numerous reasons. For example, at docs.oracle.com/cd/B28359_01/network.111/b28531/… -- "Where possible, you should build applications in which application users are database users. In this way, you can leverage the intrinsic security mechanisms of the database."
I am reasonably familiar with what they call the One Big Application User pattern, but I have been suitably convinced that this is not the best way. However, it seems that creating a database user for every web user is not particularly possible either, so my question is, what are some best practices for keeping the security definition of your data separate from the application that accesses it?
Some ideas:
A secure interface in between the database and the application. Application never knows about the database.
Create views that utilize application context to automatically filter out rows that the application user cannot read, and only grant the application user access to the view.
Similarly create procedures that utilize application context to only allow authorized data access/manipulation.
I am currently using Oracle 11g XE, and I'd like to avoid solutions that involve additional Oracle products like their Internet Directory or Middleware.
Here is what we have :
An Oracle database driven software which requires users authentication to start the application.
An Active-Directory controller with which users authenticate to log on a session
Oracle 10, Windows Server 2008, Windows 7 WS, C# (2010), DevExpress, old VB6 Framework
Here is what we'd like to do:
Use the MS credentials to authenticate users skipping login in our application
Map users' authentication informations (with A-D) to an Oracle privileges table
Remove the login box unless the user has not enough privileges to use the app
Any clue, book reference, tutorial, guide, howto, sample, documentation will be MUCH appreciated!
Reading your Question, I was delighted to see you were in the same box as I was.
We, have an Oracle 9i driven application. I read with much interest that of Oracle 10g having AD functionalities, but regrettably we could not have our hands on it, but nevertheless be happy of what we have.
In this context, there is nothing but designing your own solution. For that, we have converted our Oracle username to AD equivalent username. Our idea was for each user session, the application checks whether the user is already authenticated with AD, if then we will create a session by applying a new application generated password to the AD authenticated user and then to connect to the Oracle DB using it. The Password generated is not known to the user or neither anybody planning that it will be in encrypted form. For each session, the password is generated and applied to the user.
There were drawbacks like overhead of changing password regularly but we could not find a better solution, If you have pls. share with us for the benefit of the community.
In Symfony 2.0, I need to change the DB for a particular user until he logs out, but the code is same.
Is that possible?
It's possible, but should not be done the way you described it.
You'll always need connection that will not change: the database that will handle authentication.
Then for each user, you might have a specific database. After login, you should have the account details (database details) you need to connect to the user's database.
Once you have it, use one of the methods described in
Take a look: Symfony 2 : multiple and dynamic database connection
It should be pretty straightforward.
PS: Instead of a permanent connection, you could also have the users authenticated by another server in an SSO (single sign on) environment - that's advanced topic. The connection details of the user's database should then come from that server.
Check out Symfony2, Dynamic DB Connection/Early override of Doctrine Service
It's a slight duplication of the other one, but was specific to using request params, and the answer provides more details in it's wiring of services. Not sure if it's helpful over the other answer, but check it out anyway.
My team will develop an internal (known users) application that has an architecture based on Java as front-end and PL/SQL as back-end. So, currently we are thinking in a better solution to manage the user/permissions, and we have two options:
Each user has their own database account, granted with the permissions. Currently the legacy system use this approach and I don't like it because it manages permissions based on database objects' granularity. So, I believe it is a bad choice to have a database connection per user. Can you see more cons here?
Build some tables at database to store the users and theirs permissions/profiles and build a PL/SQL procedure to do the login, generating a token and include a parameter to all others PL/SQL to verify this token and then authorize (or not) the execution.
So, you can ask me: why not just manage your permissions in your web-application? Answer: Those PL/SQL are already done and are used by all legacy systems, and this web-application should behave according it (ie. User permissions should be managed by the PL/SQL and its granularity based in please.)
How do you proceed in this case?
I think using the database's built-in mechanism is always to be preferred over rolling our own. And that applies to logging in users as much as anything else.
The biggest single advantage of dedicated user accounts is that we can link a given session with a named user. Well, yes, duh. But the point is, doing thinks like auditing user activity or tracing a performance issue in some process is way more difficult in web applications with generic accounts.
To address your main objection, we don't have to manage database privileges at the user level. That's why we have roles. For normal users, a role will provide sufficient privileges.
So:
define a set of roles which match the various business jobs your application serves.
grant system and object permissions to those roles; remember that roles can be additive (i.e. we can grant privileges on a role to another role).
grant roles to the users.
Find out more.
oracle experts.
My client of mine wants to deploy an application that has to hold credit card numbers in a database. The client is obviously concerned with security.
We are particularly concerend with one painful issue. How can we make sure that only authorized users with a 'business need to know' are allowed to access the data? How can we protect the data from the DBA?
One obvious solution is to encrypt at the application level. We don't want to do that.
An oracle product that came up as a possible solution is Orace TDE (Transparent Data Encryption). It seems to cover the on-disk encryption case well. However, there have been disputing claims if it can be used to hide data from someone with DBA privileges.
I want to be very specific about the use case we're dealing with. We have an up and running application, 24/7/365, that is doing data access constantly. That means that the Oracle wallet is open and data is being decrypted by the database. AT THE SAME TIME a DBA should still be unable to access the data.
I know that Oracle is marketing Oracle Database Vault for this very issue. Given that all I want to do is block DBA access from just one particular table, do I really need the Vault or can I use TDE?
Assistance would be much appreciated,
Or
My guess is that you need Oracle Vault. TDE makes it impossible to read the datafiles but a simple select will still retrieve the data unencrypted.
But ask the dudes or dudettes who made the claim that TDE is sufficient, to explain how to do it without Oracle Vault.
Edit: Two threads on this issue:
http://forums.oracle.com/forums/thread.jspa?messageID=3249532�
http://forums.oracle.com/forums/thread.jspa?messageID=3261345�
"there have been disputing claims if it can be used to hide data from someone with DBA privileges."
Probably because there can be conflicting ideas about what constitutes DBA privileges. There is a DBA database role, a SYSDBA privilege and someone who can login as oracle (or Administrator) to the server at the operating system level, each with higher privileges
Privileges can be revoked from the DBA role, so that is even more vague.
VPD can ensure that, for example, the credit-card column is only visible to users logged in from a specific IP (eg the application server), as a certain user or with a certain role.
While a user with DBA role would be able to change the VPD privileges, or grant themselves the appropriate role or impersonate the relevant user, this would show up in the audit log.
i came across a similiar problem with one of our customers. During the evaluation process i have found a possible solution from a german security company. It seems they have developed a system that should prevent the DBA to access any sensitive data. Take a look at their website. It didn´t take a deeper look yet, so i cannot give you further information about this solution.
There are certain alternative companies with DB encryption and access control solutions that implement a strict separation of duties between DBA and Security Admin.
You may want to take a look into D'Amo from a Korean company, Penta Security Systems.
Disclaimer: I have worked as a DB consultant and deployed the solution to many of my customers.