If the user has access to the database,
permission to the individual database objects may be granted.
Permission may be granted either directly to the user or to a
user-defined role and the user assigned to the role. Users may be
assigned to multiple roles, so multiple security paths from a user to
an object may exist.
1. User-Defined Database Roles
User-defined database roles, sometimes
called user-defined roles, can be created by any user in the server
sysadmin, database db_owner, or database security admin role. These
roles are similar to those in user groups in Windows. Permissions, and
other role memberships, can be assigned to a user-defined database
role, and users can then be assigned to the role.
Best Practice
The cleanest SQL Server security plan
is to assign object permissions to user-defined database roles and then
to assign users to the roles.
2. Object Permissions
Several specific types of permissions exist:
- Select: The right to select data. Select permission can be applied to specific columns.
- Insert: The right to insert data.
- Update: The right to modify existing data. Update rights for which a WHERE clause is used require select rights as well. Update permission can be set on specific columns.
- Delete: The right to delete existing data.
- DRI (References): The right to create foreign keys with DRI.
- Execute: The right to execute stored procedures or user-defined functions.
Object permissions are assigned with the SQL DCL commands GRANT, REVOKE, and DENY.
The permissions in SQL Server work like they do in the operating
system. SQL Server aggregates all the permissions a given user might
have whether directly assigned against the user or through the roles.
Then SQL Server gives the MAXIMUM of what has been granted. DENY is an exception. DENY functions as a trump. If anywhere a DENY has been issued, then just like in Windows, the user is blocked. For instance, if a user can SELECT against a table directly assigned but a role the user is a member of has a DENY for SELECT, the user is blocked from issuing a SELECT against the table. Whether security is managed from Management Studio or from code, you must understand these three commands.
Granting object permission interacts with the
server and database roles. Here's the overall hierarchy of roles and
grants, with 1 overriding 2, and so on:
1. The
sysadmin server role. (A Windows login that owns a database will be
mapped to dbo; because it maps to dbo, it ignores all security on the
database.)
2. Deny object permission, the db_denydatareader database role, or the db_denydatawriter database role.
3. Grant object permission or object ownership, the db_datareader database role, or the db_datewriter database role.
Best Practice
An easy way to test security is to
configure the server for Mixed mode and create a SQL Server Login test
user. Using Management Studio, it's easy to create additional
connections as different users — much easier than it is to change the
server registration and log in to Management Studio as someone else.
Since SQL Server 2005, it has been possible to create a database principal that does not map to a server principal using the CREATE USER command and specifying WITHOUT LOGIN. Then, using EXECUTE AS USER = ‘<USERNAME>’ to switch security contexts, the security can be tested. REVERT, of course, switches the context back.
If your environment prohibits Mixed-mode
security, the easiest way to check security is to right-click
Management Studio or Query Analyzer and use the Run As
command to run as a different user. But this entails creating dummy
users in the Windows domain. Generally speaking, in a “production”
Windows domain, most auditors would flag dummy users as an audit point.
Because workstations belonging to DBAs tend to belong in production
domains, this recommendation wouldn't work where the auditors are
diligent.
3. Granting Object Permissions with Code
Setting an object's permission is the only security command that can be executed without a system stored procedure being called:
GRANT [Permission] ON [Securable]
TO [User|Role] [WITH GRANT OPTION]
The permission options available for each securable are listed in Table 1.
Table 1 Permission Options by Securable
| Database |
BACKUP DATABASE
BACKUP LOG
CREATE DATABASE
CREATE DEFAULT
CREATE FUNCTION
CREATE PROCEDURE
CREATE RULE
CREATE TABLE
CREATE VIEW |
| Scalar Function |
EXECUTE
REFERENCES |
Table
Table-Valued Function
View |
SELECT
INSERT
DELETE
UPDATE
REFERENCES |
| Stored Procedure |
EXECUTE |
The ALL permission option has been deprecated but is still available for backward compatibility reasons.
The User or Role refers to the database username,
any user-defined public role, or the public role. For example, the
following code grants SELECT permissions to Jose for the Person.Person table of the AdventureWorks2012 database:
USE AdventureWorks2012;
GO
GRANT SELECT ON Person.Person TO [AgileBay\Jose];
GO
The next example grants UPDATE permissions to the public role for the SalesOrderHeader table:
USE AdventureWorks2012;
GO
GRANT UPDATE ON Sales.SalesHeader TO Data_Analyst;
GO
Multiple users or roles, and multiple
permissions, may be listed in the command. The following code grants
select and update permission to the Developer user and to the DBATeam
Windows Group:
GRANT SELECT, UPDATE ON Sales.SalesHeader to Developer, Data_Analyst;
The WITH GRANT
option provides the ability to grant permissions to others for the
object specified. For example, the following command grants Jose the
permission to select from the SalesHeader table and grants select
permission to others:
GRANT SELECT ON Sales.SalesHeader TO [AgileBay\Jose] WITH GRANT OPTION;
