We are using DB project to track Db changes and a standard XML file to publish the changes locally, to test server, Production etc. At the moment we are just copy pasting code like below to Grant permissions to new tables we create.
GRANT SELECT
ON [dbo].[OrganisationSite] TO [Company_FullAccess]
AS [dbo];
GO
GRANT UPDATE
ON [dbo].[OrganisationSite] TO [Company_FullAccess]
AS [dbo];
GO
GRANT INSERT
ON [dbo].[OrganisationSite] TO [Company_FullAccess]
AS [dbo];
GO
GRANT DELETE
ON [dbo].[OrganisationSite] TO [Company_FullAccess]
AS [dbo];
GO
This is prone to error as we could forget to grant a specific permission.
Is there any way to create a SQL query, to view the permissions granted for each table in the database? So we can check to see what permissions have been granted.
Also, any advice on making this more robust would be appreciated.
The best idea in this case is to use ROLE, and add members as needed.
From the documentation:
Roles are database-level securables. After you create a role, configure the database-level permissions of the role by using GRANT, DENY, and REVOKE
That will make it easy after you create ROLES as needed, you can just add members on it, no need to check every member permissions.
Related
We are currently running an Elastic Pool within azure to host all our databases.
We need to back up these to on-premise as well in case of an emergency, and for it we are trying to use sqlpackage.
Now initially i tried running it with a user which only has the db_backupoperator role, however view definition was also required. However i would not like to give the backup user complete db_securityadmin permissions.
So i've tried giving the backup user only VIEW DEFINITION access by using the following command
GRANT VIEW DEFINITION ON SCHEMA::dbo TO [user]
However i am still getting the error that i do not have View Definition permissions.
I've also tried adding a custom role, however that is not supported within AzureSQL
NOTE: Full rollout to grant access:
CREATE USER backupuser
FOR LOGIN backupuser
WITH DEFAULT_SCHEMA = dbo;
ALTER ROLE db_datareader ADD MEMBER backupuser;
ALTER ROLE db_datawriter ADD MEMBER backupuser;
GRANT VIEW DEFINITION ON SCHEMA::dbo TO backupuser
Would every user who uses my database have a role? Is it more administrators who will have roles, people who need access to all the tables?
Also, I am unable to offer table-level privileges to a role and offer that to a user.. it just won't work. I have to offer the privileges directly onto the user for them to work. Is that normal? Should I be able to offer table-level privileges to a role or do I have to manually offer each of my users the table level privileges?
Would every user who uses my database have a role?
That depends on how you (or, should I rather say, DBA) set it up.
Quite a long time ago, say until Oracle 8i, there were 2 very popular roles: connect and resource so when DBA created a new user, they simply ran
grant connect, resource to new_user;
and the new_user was ready to go as those roles provided most needed privileges such as create session, create table or create view (check documentation for more info about those predefined roles).
However, it turned out that not everyone should be granted e.g. create cluster (which is one of connect's privileges) so nowadays you should create your own roles, if you want - then grant certain privileges to those roles and, finally, grant roles to your users.
Another option is to keep .sql scripts for each of your users. That script should contain list of privileges granted to those users, separately, which means that you shouldn't granted anyone privilege they don't really need.
I am unable to offer table-level privileges to a role and offer that to a user. it just won't work. I have to offer the privileges directly onto the user for them to work. Is that normal?
It works, but not everywhere. Those privileges (the ones granted via roles) won't work in named PL/SQL procedures (i.e. stored procedures, functions, packages). If you have to use those tables in them, yes - you have to grant privileges directly to each of those users.
As opposed to named PL/SQL procedures, privileges granted via roles will work in anonymous PL/SQL blocks or at SQL level.
If you're wondering why would you use roles at all, then, the answer is my first sentence: it depends.
I am granting permission on some objects to my user in a database, Is there any way to grant permission to user without using database role?
I can easily do it by creating database role, but I do not want to use role.
I assigned some objects to my user by Database User, in Securables tab, it didn't work!
create user [user_test] for login [login_test]
create role role_test authorization user_test
exec sp_addrolemember 'role_test', 'user_test'
grant select on object::dbUser.tbl_05 to role_test
I expected I could grant permission to my user and not to use Database Role.
You have (at least) 2 options here, you can assign the permission straight to your DB user (as mentioned in the comment) or you can grant permission on a certificate, which might give you better control in a production environment.
Our SQL administrator is currently ill and in the hospital however we have an upcoming security audit from the SQL cluster. Therefore we would like to grant the security auditor now read only access so that he can see all settings (primary which DB has which settings and which users are created). But the auditor shouldn´t have any rights to access DB content. Could that be performed? If yes how?
As Per my understanding you are looking for this solution where you want only definition access to user not the data reader operation access.
If this is the case then You can do it using GRANT Schema Permissions (Transact-SQL)
The VIEW DEFINITION permission lets a user see the metadata of the securable on which the permission is granted. However, VIEW DEFINITION permission does not confer access to the securable itself. For example, a user that is granted only VIEW DEFINITION permission on a table can see metadata related to the table in the sys.objects catalog view. However, without additional permissions such as SELECT or CONTROL, the user cannot read data from the table.
For more details go through the link
For grant access to different functionality of SQL Server you can go through the following link
GRANT PERMISSION
I often read that one purpose of a VIEW is security: to allow some users access to the underlying table, and other users to a derived view only. With that in mind I designed several views that supply restricted datasets to external users.
All very fine, but in practice this doesn't work. After I grant SELECT permission on a view, the users can't access it unless I grant SELECT on all underlying objects too. Same story for stored procedures. The net result is non-functional, for I end up still granting access to sensitive data to the wrong users, as well as annoying, for it is easy to forget one object and the users come back to complain that the view "doesn't work".
Is there a way to grant SELECT permissions on a view or stored procedure without having to expose the underlying objects too?
Does the same user who owns the view also own the underlying tables? If not, the owner of the tables needs to grant the view owner permission WITH GRANT OPTION. If the same user owns both the tables and the view, then granting permission on the view should be sufficient.
You might find the information in this forum helpful.
The last post has the details of what was run to grant permissions to a view but not the underlying tables:
CREATE USER [Reports] FOR LOGIN [Reports] WITH DEFAULT_SCHEMA = Reports
CREATE SCHEMA Reports AUTHORIZATION Reports --Auth as Reports was the key piece of information that I had missed.
GO
CREATE ROLE Reporting AUTHORIZATION db_securityadmin
GO
exec sp_addrolemember #rolename = 'Reporting', #membername = 'Reports'
GO
GRANT CREATE VIEW TO Reporting
GRANT CREATE TABLE TO Reporting
GRANT SELECT, VIEW DEFINITION ON [dbo].[zName] TO Reporting;
FYI - For stored procedures, you should be granting EXEC to the procedure.
If you have your views in a different schema than the table, you must either grant the user access to the base table, "AUTHORIZE" the owner of the tables to the view like this:
ALTER AUTHORIZATION ON reporting.MyViewName TO dbo
In the example above dbo is the user owning the tables the reporting.MyViewName is accessing