3. Fixed Database Roles
There are two kinds of database roles: fixed
and flexible. Fixed roles cannot be deleted and are provided within
every database. Table 1 lists fixed database roles.
Note The msdb
database contains additional fixed roles that are not found in any
other database. These roles support the SQL Server Agent and SQL Server
Integration Services features.
In addition to using the UI in SSMS, numerous
stored procedures and functions help DBAs work with database roles.
These fixed roles serve to define a general permission within the database. For example, the following script grants DevUser the db_datareader permission using the sp_addrolemember system stored procedure:
USE [Accounting]
GO
EXEC sp_addrolemember N'db_datareader', N'DevUser'
GO
In this example, DevUser would be able to read any table within the database regardless of whether they had SELECT permission defined.
Note There is an exception to this global grant behavior. If the DBA issued a DENY statement against DevUser on a specific object, that object would no longer be accessible by DevUser.
The global behavior of fixed database roles
addresses some scenarios; however, to reduce the surface area for
attack, it’s better for you to grant specific permissions on objects to
your users.
4. Database Permissions
If you are a database user in a database and are not a sysadmin or a member of the db_owner or db_datareader group, you will not be able to read any data within the database. To read data, an administrator needs to grant the user the SELECT permission. Similarly, if the user wants to add data to a table, they would need the INSERT permission. If the user wants to delete data, they would need the DELETE
permission. There are many granular database permissions that you as an
administrator can define for a given database user or role.
Also, there exists a
permissions hierarchy within SQL Server. Some server-level permissions
convey the rights of other permissions by implication. For example, if
a database user is mapped to a login that was granted ALTER ANY SERVER AUDIT permission, this database user has the ALTER ANY DATABASE AUDIT
permission even though that user might not have been explicitly given
that permission. This implication also works within the scope of the
database. For example, if a database user was granted ALTER ANY ASSEMBLY, the database user also has the CREATE ASSEMBLY permission, even without being explicitly given that permission. In both cases, ALTER ANY SERVER AUDIT and ALTER ANY ASSEMBLY are known as covering permissions.
With SQL Server, you can grant permission to a
user, revoke an existing permission from a user, or deny permission
from a user. To grant permission, you use the GRANT statement. An example of granting SELECT on the Customers table is as follows:
GRANT SELECT ON Customers TO BusinessAnalysts
If you wanted to remove this permission, you would use the REVOKE statement as follows:
REVOKE SELECT ON Customers TO BusinessAnalysts
What if you had a user Bob who was part of the BusinessAnalysts group and you did not want him to have the SELECT permission? You could use the DENY statement as follows:
DENY SELECT ON Customers to Bob
Bob would still have all the permissions defined for business analysts, but he would be denied from reading data from the Customers table.
