The scenario : an Oracle 11g database containing some sensitive user data that could result legal liabilities if disclosed to the wrong party.
The desired effect : only a certain user, connecting from a certain IP, can see the column that contains this sensitive user data
I am not sure that hidden columns or virtual columns are the right ways to do this. It seems that Fine-Grained Access Control could help. I am not sure of what is the best solution. The restriction by IP is probably done at the listener level?
The question :
How can we restrict the visibility of a column so it is only available only to a specific user? All the other users would never see the column, not even when doing a "DESC TABLE_WITH_SENSITIVE_DATA"
Thanks for any tips.
Simplest way to do this is to create a view on the table that does not contain all of the columns. Don't grant select on the table, but only on the view.
The "proper" way to do this is with Fine-Grained Access Control (Virtual Private Database), which can replace the contents of columns with a NULL if certain conditions are not met.
See the example here: http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#autoId17
You can probably build this sort of functionality yourself if you're feeling both impoverished and skilled.
Do you the ability to modify roles and create views? Perhaps you could create two separate views and grant access to two different roles for that table. All users that are restricted from seeing the sensitive data would belong to a "restricted" role and the others would have access to the "unrestricted" role. You would need to grant privileges on each view to the appropriate role.
It is important to note that there are restrictions on updating the underlying data associated with a view. As explained here, views that contain set operators, aggregates and GROUP BY DISTINCT and joins and not modifiable.
Related
I'm the QuickBase Admin for my QuickBase app. In the app, there's a dashboard report that's used by individuals with viewer access; that way, they can see their students' data, but can't edit the app, tables, structures, etc.
My app's users want to be able to edit one field with notes on that row's data (each row is a student's data, so they'd want to use that field to add notes on that individual), but viewers don't have editing/data entry access tn any column. Is there a way for users to have editing/data entry access to one field, but not the others?
I know with Tableau and other BI software, this isn't possible, but I wanted to ask since my users asked.
Thank you for reading.
Sure you can.
Actually there are more ways to implement this needs.
My opinion better if you create a new table and make a relationship between the student data and a (new) Notes table and you will be able to setup edit rights eg by record owner.
An other way, you can allow the edit right for your users and you can make a restriction on field level. In this case you have to go through on each field and at the Advanced section you will find Permission - Restrict access by role.
Hopefully you do not have a lot of fields :)
I have created a custom entity in common data services(CDS) that streams in data from a survey.
I'll however need to give access to the data to various people. In my dataset, I have a column called community, which should represent which people have access to what data based on the community they've entered the column.
How exactly can I filter the data, after it has streamed in to ensure I only give access to people of a particular community. And yes every community is exclusive, no two people can be in two different communities.
I want to filter by the community, such that those in community A see only A and not B or C.
There’s no straight one step OOB configuration to achieve this. Because the row level security depends on the column value ie. community field value of each record.
One way is to create owner teams and add the users to right teams, then the custom entity record has to be owned by respective team - owner team of each custom entity record can be filled/assigned automatically based on the community field value on create using plugin/workflow/Flow.
Most important, in security role for that custom entity - read privilege has to be given only for user level. Assign the security role to Teams.
For the accounts entity I have different account types.
However I need to make some of these records read only only based on the account type, as these records will be slaved in CRM.
However the user should still have ability to create other types of accounts that will be mastered in CRM.
I was thinking to do this via security role however when giving create or edit permission on the account entity user can still create accounts of any type or edit existing slaved data.
What would be the best way to make slaved data read only?
Use business rules to lock all fields based on the type?
Like you said, this cannot be achieved with security role, since the requirement is based on a field value.
Disabling all the form fields in bulk - You can do this in javascript quickly, or may be with Business rules one by one. Verify the field value on form load for your certain slaved value account type, then disable the controls by iterating each one of them.
Still subgrid, webresource, iframes will be editable.
How to create a column in parse.com such that I can associate each row with a particular user? Also how to protect each row with the user so that others can not perform data modification on that particular row?
For most purposes, you want a Pointer column to the user.
For securing your data to that particular user, you'll want to look at object-level access control. You should be able to find most of what you need in the guide: https://parse.com/docs/ios/guide#security-object-level-access-control
(There are also similar guides for JS and Android)
Per this link: https://parse.com/questions/data-unique-to-user on the parse site, add a column that is a User to the table you want associate. Then use Parse.user.currentUser() to set that value.
Like the title says, I've been asked to come up with an estimate for retrofitting an existing asp application.
The current security mechanism controls access to different parts of the application (page-level restrictions), but has no mechanism for flagging individual records as restricted. Assigning rights to a user (using the existing, custom access management code) is no problem, but enforcing the rights is a different matter - each asp page has embedded sql - there's no use of stored procs, objects, etc.
Is the only solution to modify each table and query, or is there a better way? Any pointers, suggestions or prayers would be welcome.
This is classic asp, running on IIS6, against an oracle database.
Update: Here's a user scenario.
We have users, managers, directors, and VPs. The managers can see data created by users who report to them, but not users who report to other managers. Users can't see data created by any managers. Same thing with directors - they can see down, but their reports can't see up.
This sounds like an ideal time to implement row-level security. Oracle has a package DBMS_RLS that allows you to define arbitrary access policies that can be applied to one or more tables that limit what rows a particular user is allowed to see. Conceptually, when a user issues a query with no filters on a protected table, i.e.
SELECT *
FROM my_table
Oracle automatically and transparently inserts a WHERE clause defined by your security policy that limits the result set. You shouldn't need to make any changes to the SQL your application is executing.
Assuming you need maximum granularity, the ability to "grant" each and any row to any of very many users, then you have a many-to-many relation, yes?
So apply the following pattern:
Add a tables of users.
Then, for each restricted table, so the following:
Rename it tablename + "_base".
create a many-to-many table that
associates that table's id with a
user id, called tablename +
"allowed_user".
create a view with the name table
name that joins tablename_base to
table_name_allowed_user, with a
select* from tablename_base and
user_id from tablename_allowed_user.
This view should meet Oracle's
requirements rto be "inherently
updatable."
Now comes the hard part. You need to add "and user_id = $user_id" to every query. Find the various functions you're using to make queries. Wrap those function(s) in ones that gets the user id from the session and add that predicate.
One passable way to do this is to read select string, find the all "where"s (for subqueries there may be more that one), and replace it with "where (user = $user) and ". For queries that don't have a where, you'll need to insert this before any "group by" or "order by". This is fragile, so obviously you'll test that this works for all pages (you have an automated test for all pages, right?), and add hacks to cover special cases.
"update" statements won't have to change; "inserts" will presumably insert both to the view and then do a separate insert to the table's "allow_user" table with the id of the inserting user, to automatically grant teh inserting user acces to what he inserted.
If your number of users is more limited, or you're restricting types of users, you can go with a strategy of multiple views named for the user or type; then you'd replace tables names in the queries with the appropriate views.