i am trying to design an ER diagram or model of a dvd rental system but i am having problems with the design i have so far i want to put an entity for an administrator so that he can see everything and i also want to modify the customer entity so that the customer can only see what what is in the shop and not everything ,the customer can only check the basics
here is my ER MODEL below
All users have to have privileges to access the database. The Privileges are dependant on the user.The basic privileges are.
SELECT | gives the right to read the table contents.
INSERT | gives the right to add new rows to the table.
DELETE | gives the right to remove rows from the table.
UPDATE | gives the right to update the contents of the table.
The customer will have SELECT maybe UPDATE to any table required for his part of the application.
The application administrator can have all the privileges above to all the tables in the application database.
The database administrator will have all the privileges in the database and will GRANT privileges to customer & application administrator
This is a very simplified version and you should research further, especially the database being used
Related
Apologies for the new question, but I am having trouble understanding the best practices for understanding the recommended role set up for my account. I am auditing what I have created to backwards engineer and correct it on a new warehouse.
So here is the situation:
I granted all permissions on all warehouses modify AND usage to the sysadmin.
When running worksheets and ./snowsql in parallel, I used the ACCOUNTADMIN for all of the sessions in snowsql.
When I use the Sysadmin to modify the tables that copied the data staged in the warehouse sometimes I have permissions and other times I don't.
I have been sifting through account history with the ACCOUNTADMIN role to view all the grants with the recommended query from the documentation below:
select *
from table(information_schema.query_history())
order by start_time;
I filtered then by the database and query_id to include grant
select *
from table(information_schema.query_history())
where database_name = 'temp_db'
and query_id like '%grant%'
order by start_time;
I did this to see if there were any differences in the grants I did between databases in the warehouse. I only set up two warehouses so it was easy to see.
Going forward, Accountadmin is used to create roles, warehouses, and databases.
To prevent the need to do an audit when switching between roles, I want to set future grants on Sysadmin to specific databases in a warehouse for modification and usage, how do I do that?
Permissions to warehouses, database, and all other objects are separate things. Granting permissions to a warehouse let's that role use or modify a warehouse, but that has nothing at all to do with creating, updating, etc. other objects like databases, schemas, tables, and views. Also, only the role that OWNS a table can drop or alter a table. So, you might want to check on the ownership of the tables between SYSADMIN and ACCOUNTADMIN. As a best practice, ACCOUNTADMIN shouldn't own anything.
It would take quite a bit more information to give you a full rundown of RBAC in Snowflake. If you are struggling with it, you might want to contact Professional Services at Snowflake and get them to come in and do an overview (QuickStart or Security package) to get you straightened out.
I want to grant read permissions for a user for a view which joins 2 tables from another database.
I don't want to:
give him permission on the database where the tables are or add him as an user there.
Make him the owner of the view/schema due to the security exploits.
I don't want to create first a table, or variations of a hack table with a truncate and a stored procedure which inserts the data on a trigger.
Can this be done somehow? Maybe there's something I missed and you guys might know.
I have read these posts but they didn't solve my problem:
Grant SELECT permission on a view, but not on underlying objects
Grant Select on a view not base table when base table is in a different database
https://msdn.microsoft.com/en-us/library/ms188676.aspx
https://dba.stackexchange.com/questions/89632/sql-server-grant-select-access-to-a-user-in-a-view-and-not-in-its-tables
Thank you
Edit:
The easiest solution I came up with, after some research, is activating the cross database ownership chainingoption on the database where I'm placing the views and granting the read permission to the users. This might be in contrast with my 2nd point of things I'm trying to avoid. Is this a good idea?
Give them a login to another database on the same server, and include only your single view, with the view pointing to your secure database. Don't give that login any access to anything but the database with the view in it, and only read access to that single view. Obviously, you'll have to fully qualify your table name (e.g., from SourceDB.dbo.SomeSecretTable).
What I ended up doing:
Create an active directory group.
Add users to the AD group.
Create a login for the AD group mapped for the source DB and target DB.
Add the user on the target DB and give him permissions only for the requested views.
(Optional) Added the group on all the databases to deny select.
Couldn't find a solution for my original question without the AD group.
I have MS Access as a front end and PostgreSQL as back end for my database. So I set up the database in PostgreSQL and linked the tables to MS Access using the ODBC drivers. Everything works great, I can update the tables in MS Access and the record will appear in Postgres database.
Since I can still see the linked tables in MS Access, I feel like it is possible for some users to go in and manually modify the tables without filling out proper forms. Is it possible to HIDE the tables or lock the tables so that Access users cannot modify the raw data at all? If not, what can I do to secure the integrity of the database.
Thanks!
I would recommend looking at Postgres privileges as a way to lock the tables down.
In short, you could have your backend run as one user that has full access permissions on the tables in question, and when the users login to the app, they would be connected to Postgres using a user whose privileges are considerably more locked down (say, read only if you just want to be able to do SELECTs to surface data).
For example, you could run the following SQL against your Postgres server:
REVOKE ALL ON accounts FROM joe;
GRANT SELECT ON accounts TO joe;
Which would first remove all privileges from the user joe for the table accounts, and then allow only SELECT priveleges for that table.
You could do something similar for all the tables you wish to lock down. You'll also need to do the same for the sequences used by those tables.
You may wish to create a special readonly user which has only read access across the board, and use those credentials to surface the Postgres data for the users to access.
When you need to alter data, your backend could specifically use a power user of sorts which has much greater access.
Here's a link which details creating a readonly Postgres user (for purposes of backups in this case, but the general concept and the SQL commands should apply (just ignore the stuff about pg_dump).
If you aren't concerned about users' ability to modify the data in those tables via the up other than in the ways that are authorized, but are only concerned about them using, say, psql to go in and update them, then you probably don't need a readonly user, but can simply lock the tables down and have the backend use that user with sufficient access.
I am building a application in silverlight which will enable users read information about their payment. Their login and password will be save in table in db.
It is possibility to improve security in my app by limiting what data a query has access to? For instance i want to prevent a user from selecting data they do not own. A limitation is that my application is using a its own table for users, so i cannot use GRANT PERMISSION :/. I am using Linq to build my sql queries.
This question is from my teacher who "suggest" me to improve security, so if it's impossible - it's no big deal ;)
Well, it is kind of a vague question you've asked, but I'll hazard a stab at it.
You must be doing some authentication on the user's identity to only be showing them their payment, as opposed to someone else's payment. So, if you can do that, you should be able to create triggers that disallow any insert, updates, or deletes on your tables from those same identities... I don't think this is a very robust or scalable solution, but it's an idea.
CREATE TRIGGER [x] ON [TABLE] FOR INSERT
/* Disallow Users to insert */
IF EXISTS( SELECT 1 1 FROM [Users] WHERE [Users].UserID = [Y])
--Rollback transaction, set error, etc
Do you have any more details? Anything else could be helpful in finding a better solution.
A fine tuned access control for database resources is a very uncommon method of securing your application. User level access control is best implanted by the application. The sql user account used by the application should be as restricted as possible. For instance it should only be able to use the database(s) it needs to function, and nothing more.
There is 1, and only 1 project that has fine grained access control for a sql database, and that project is SE-PostgreSQL.
"It can provide fine grained mandatory
access control to various database
objects such as tables, columns or
tuples and can apply consistent
authority of remote/local client
integrated with operation system
independent from database
authorization."
Create a view named 'MyPayments', on the 'Payments' table. Make sure you have a WHERE clause in the view definition, so that the view returns only the relevant data to each user. Here is what the WHERE clause of your view will look like:
WHERE PaymentOwner = SUSER_SNAME()
The SUSER_SNAME() system function returns the currently logged in user's login name. If the first user logs in with the login name 'User1' and inserts a row, his/her login name is stored along with the row. The SUSER_SNAME() function in the WHERE clause of the view definition makes sure 'User1' see only those rows that have the 'PaymentOwner' column set to 'User1'.
More here
I have always worried about users deleting lotus notes databases by accident. We had one such case last week and I want to know how we can lock the databases so that users cannot delete them.
Is there a way in Lotus Notes - either at the Db level or server level where we can set up the database so that only the administer of the db or the user with Manager access can delete the database?
A user can only delete a server-based database if the user has Manager rights to the database. Just confirm that your users do not have Manager rights (use the "Effective Access" button on the ACL dialog window to check this).
the good practice is to have separate ID for such Hardcore operations, like Deletions, users deletions and so on, so if you want to delete something, switch to another id and then delete, other time you are like regular user. without MANAGER access :)