Guide: SQL Server Security

SQL Server Roles: A Practical Guide

What are SQL Server Roles?

SQL Server roles lets you group user logins together and manage server-level permissions. They play a central part in SQL Server security. SQL Server has two types of roles:

  • Fixed server roles, which are built into SQL Server, and do not allow you to modify permissions or user-defined roles. We cover the main fixed server roles below.
  • User-defined roles, which you can customize for your organization’s security requirements.

When managing a SQL Server database, it is important to maintain the least privileges rule, which ensures that users gain access only to the data they need. The goal is to enable users to access data needed for normal operations but nothing beyond that. You can restrict and control user access by setting up server roles.

In this article, you will learn:

  • SQL Server Role Types
    • Server-Level Roles
    • Database-Level Roles
    • Application Roles
  • Creating a Server Role Using SQL Server Management Studio
  • SQL Server Roles with Satori

SQL Server Role Types

SQL Server provides three types of roles you can use to restrict access to data in your database: server-level roles, database-level roles, and application-level roles.

Server-Level Roles

Server-level roles help manage permissions for the entire SQL Server instance. SQL Server provides several built in server roles, but you should add your own specific roles if possible. Fixed server roles cannot be changed.

You can also assign server-level principals (Windows groups and accounts, and SQL server logins) to these roles. Fixed server roles allow members to add other users to the same role, but this is not so for user-defined server roles.

SQL Server provides the following fixed server roles, starting with least privileged roles:

  • public—default role for server principals who do not have specific securable object permissions. Only assign public permissions to objects that can be made available to all users. You cannot revoke public permission from any server role.
  • dbcreator—can alter, create, drop, or restore databases.
  • diskadmin—can manage disk files.
  • bulkadmin—can execute BULK INSERT
  • setupadmin—can add/remove linked servers and run Transact-SQL
  • processadmin—can end running processes in the SQL server instance.
  • securityadmin—can administer logins, can reset SQL server login passwords, and grant, deny or revoke server-level permissions or database-level permissions
  • serveradmin—can alter server configuration and shut it down
  • sysadmin—can perform all server activities.

Database-Level Roles

SQL server defines roles that enable management of database-wide permissions. You can use the ALTER ROLE  statement to add and remove users to database roles.

Like server-level roles, there are fixed database-level roles built into SQL Server, and you can create additional roles, customizing them using the GRANT, DENY, and REVOKE statements.

Fixed roles exist independently for each database within your SQL Server instance. The db-owner server role is allowed to manage membership of fixed database roles.

Microsoft SQL Server provides the following fixed database roles:

  • db_owner—allowed to perform all maintenance and configuration activities on the database, as well as dropping the database
  • db_securityadmin—can modify custom role memberships and manage permissions. Monitor this role closely as it has the ability to escalate privileges.
  • db_accessadmin—can add/remove database access for Windows groups and logins, as well as SQL Server logins
  • db_backupoperator—can perform database backups
  • db_ddladmin—can run data definition language (DDL) commands
  • db_datawriter—can add, change, or delete any user table data.
  • db_datareader—limited to reading data from user tables
  • db_denydatawriter—are not allowed to add, modify or delete user table data
  • db_denydatareader—cannot read any of the data in a user table

In addition to database-level roles, SQL Server also enables defining permissions at the row level.

Read our guide to SQL Server row level security (coming soon)

Application Roles

Application roles facilitate applications to run with dedicated user-like permissions. This allows all users, connected through a pre-specified application, to access specific data in a database. To distinguish them from regular database roles, they are inactive by default and have no members.

You can activate application roles by using the password-protected sp_setapprole command. Since these roles constitute a database-level principal, they require guest– level permissions to access other databases. If guest is disabled in a database, the database will be inaccessible to application roles from other databases.

Since they are not associated with a server-level principal, application roles are denied access by default to server-level metadata in SQL server (it is possible to remove this restriction if necessary).

This is the process an application should follow to grant access to the database for an application user:

  1. User logs into the application, and the application connects to SQL Server, identifying itself as the user
  2. The application executes the sp_setapprole  stored procedure using the application-specific password
  3. If role name and password are valid, the application role is enabled
  4. From this point onwards, the database grants application role permissions to the user. Permissions remain valid until the connection is closed.

Creating a Server Role Using Management Studio

The below walkthrough shows how to create a server role in SQL Server using Management Studio.

Step 1:
In the Object Explorer, choose a SQL Server instance, find the Security folder and expand it. Right-click Server Roles > New Server Role.

Step 2:
In the New Server Role screen, go to the General page. Next, find the -server_role_name  dialog box and type a name for the role.

Step 3:
Under Owner, select a server principal to attach to the new role.

Step 4:
Under Securables, you will find a list of server-level securables. Select one or more; you can grant or deny permissions to each securable for your server role.

Step 5:
In the Permissions: Explicit box, choose the check box to “grant, grant with grant, or deny permission” to this server role for the selected securables. In some cases it will not be possible to set permission for all selected securables, and you will see a partial selection.

Step 6:
In the Members page, click Add to add logins (groups or individuals) to your new server role.

Step 7:
In the Memberships page, you can also select the appropriate checkbox to add a user-defined server role as a member of another server role.

Click OK, and you have successfully defined a new server role for your SQL Server instance.

SQL Server Access Control with Satori

Satori allows SQL Server admins to automate and streamline users access to data. With Satori’s Users Directory you can organize users into groups based on project or scope and with Satori’s Datasets you can organize SQL Server entities such as tables into logical datasets. Then you can provide groups and users entitlement to specific datasets as well as manage manual or automated data access approval workflows.

 

Learn more:

Last updated on

May 11, 2021

The information provided in this article and elsewhere on this website is meant purely for educational discussion and contains only general information about legal, commercial and other matters. It is not legal advice and should not be treated as such. Information on this website may not constitute the most up-to-date legal or other information. The information in this article is provided “as is” without any representations or warranties, express or implied. We make no representations or warranties in relation to the information in this article and all liability with respect to actions taken or not taken based on the contents of this article are hereby expressly disclaimed. You must not rely on the information in this article as an alternative to legal advice from your attorney or other professional legal services provider. If you have any specific questions about any legal matter you should consult your attorney or other professional legal services provider. This article may contain links to other third-party websites. Such links are only for the convenience of the reader, user or browser; we do not recommend or endorse the contents of any third-party sites.