TL;DR
In order to restrict the DEVs from doing anything "wrong" you have to at least remove the sysadmin
SQL Server role.
Let's start
You could assign your DEVs the db_owner
database role for each individual database. However that role will permit a user to perform a BACKUP DATABASE ...
or BACKUP LOG ...
which you mentioned you don't want them to be able to perform.
Solutions
Beginning with SQL Server 2014 you can then restrict a SQL Server Login with the db_owner
role further removing individual privileges/permissions. One example is to remove the backup privilege on the database and transaction log level by issuing the following commands on the database:
USE <database_name>
GO
DENY BACKUP DATABASE TO <database_principal>
GO
DENY BACKUP LOG TO <database_principal>
Reference: DENY Database Permissions (Transact-SQL) (Microsoft Docs)
There are three levels of permissions.
GRANT : You are granted/granting a specific permission
REVOKE : A previously granted/denied permission is revoked (removed) again
DENY : You are denied/denying a specific permission
Alternative
Now because DENY
has precedence over GRANT
you could use the alternative solution of creating a new database role and adding the <database_principals>
to that role:
USE <database_name>
GO
CREATE ROLE [deny_backup]
GO
DENY BACKUP DATABASE TO [deny_backup]
GO
DENY BACKUP LOG TO [deny_backup]
GO
EXEC sp_addrolemember N'deny_backup', N'<database_principal>'
GO
Reference: Restrict Backup permission to user (Social MSDN)
Step by Step Guide
Because some people are sceptical about statements I have made in this post, I am adding the individual steps to show you how you can indeed DENY permissions from a SQL Login even though that login has the db_owner
role.
Creating and Mapping SQL Login
Let's create a SQL Login and assign it the db_owner
database role:
Deny Backup Database permissions
Now we switch to a higher privileged account like sa
or a Windows Login (which would be you, the DBA asking this question) that has the sysadmin
SQL Server role and DENY
the right to backup database
from the database principal hot2use
:
In a perfect world you would also need to submit a DENY BACKUP LOG TO hot2use
too.
Log in to server with hot2use and back up database
Seeing as hot2use
has the db_owner
database role for the Test
database, we log in with hot2use
...
...and try to back up the database:
Well that doesn't work and is what we expected. This is because the SQL Server login hot2use
no longer has the privilege to back up the database even though the login still has the database role db_owner
:
SQL Login wants to hack permissions
Seeing as the SQL Server login has the db_owner
role and according to some people he can assign himself the permissions back, let's try that out:
(The test was conducted in a fresh database SQL Server Query window)
Summary
If you DENY
permissions with a higher privileged account, then these privileges can not be GRANT
ed back from the lesser privileged account, even thought the SQL Login (e.g. hot2use
) should have these privileges from the database role db_owner
. This is something that changed in SQL Server 2014 (yes, the tests were conducted on a SQL Server 2014 instance).
Additional ressources
You can further restrict permissions according to the official overview which can be found here:
Permissions (Database Engine)
Further recommended reading:
Getting Started with Database Engine Permissions
Wait, restores...
Oh yes, we only denied the BACKUP DATABASE
privilege didn't we? That has nothing to do with RESTORE DATABASE
, or does it? Let's find out. I'll create a database backup with a higher privileged account/login:
Seems to work. Let's switch back to the hot2use
SQL Server Query window and restore the backup:
As you can see, it isn't going to work, because the BACKUP DATABASE
privilege also restricts the restore capability of that SQL Server login.
No backup privilege = No restore privilege.
How about DENY BACKUP DATABASE FROM SYSADMIN
?
Well, since you asked. Let's try it out. I'll leave out the screen shots that show how I revoked the database role.
I assigned the SQL Login the sysadmin
SQL Server role with:
ALTER SERVER ROLE [sysadmin] ADD MEMBER [hot2use]
GO
...and then removed the permission to backup the database with the above mentioned DENY BACKUP DATABASE..
commands and then performed a database backup with:
backup database Test to disk = 'C:\temp\Test_Full_Backup_20171121.bak'
... which resulted in:
So you can't DENY
permissions from a SQL Login with the sysadmin
Server role, but you can DENY
permissions if the SQL Login does not have the 'sysadmin' database role.
Minimal permissions required to backup / restore a database
If I assign the SQL Server login absolutely no SQL Server roles and assign only the db_backupoperator
database role on a given database, then I can backup and restore the database. This is something that others believe the SQL login is unable to perform. The higher privileged account created the backup, so the lower privileged account (non-sysadmin) shouldn't be able to do a backup/restore.
After resetting all permissions of the SQL Server login hot2use
to public
on the server and db_backupoperator
on the database level, I am presented with the following enumerated permissions:
According to others I shouldn't be able to perform a backup because I am missing a SQL Server role.
So I can in fact backup a database if I have the db_backupoperator
role.
And again, if I DENY BACKUP DATABASE
to the SQL Server login (on a SQL Server 2014 instance or greater), then I am no longer capable of backing up my database, even though I still have the db_backupoperator
role on the database level:
If the SQL Login hot2use
tries to REVOKE the previously denied permission then that will fail, with a similar message that I previously showed above.
Summary
Determing which permissions/privileges/roles you want to assign to your DEVs is going to be a tiring fight/issue, because they won't want to give up the sysadmin
SQL Server role. You will have to find out which SQL Server Roles and which Database Roles they will exactly require to do their job. The worst-case is that everything will stay the same. The best case is that you will be able to restrict the DEVs in their permissions/privileges.
You will at least have to remove the sysadmin
SQL Server role from your DEVs in order to further restrict them from being able to do everything they want. But once that SQL Server role has been removed, you can assign them for example the db_owner
role and DENY BACKUP DATABASE ...
to disallow them from backing up the database or restoring it.
The developers can still do anything they want inside the database (includig a DROP DATABASE
), but they cannot perform a backup or a restore. See the following enumerated permissions for the SQL Server login hot2use
with the database role db_owner
but having both DENY BACKUP DATABASE ...
and DENY BACKUP LOG ...
:
SQL Server Login with db_owner role but without backup permissions
Best Answer
Given a brutal super user command or
DROP TABLE
/DROP DATABASE
as likely to be the SQL injection commands for the malicious hacker, you may as well defend yourself against those. No point invoking a data recovery procedure pre-emptively.