SQL Server Basic Guide

Published on May 2016 | Categories: Documents | Downloads: 82 | Comments: 0 | Views: 662
of 40
Download PDF   Embed   Report

Comments

Content

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

SQL Server Security
IN THIS CHAPTER
Authentication Schema Database Security Roles Authorization Views and Data Access Stored Procedures and Data Access

12

CHAPTER

325

ch12.indd 325

10/24/05 10:37:24 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

326

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

S
 

QL Server security protects data in the database against unauthorized access. This important feature of every database system (see Chapter 1) requires the evaluation of two primary questions:

Which user has been granted legitimate access to the SQL Server system (authentication)? Which access privileges are valid for a particular user (authorization)?

The following sections discuss these two issues and describe the Transact-SQL statements that grant and limit access to users. Later in the chapter, views and stored procedures are shown, which can also be used to protect data in databases and restrict the access to data by unauthorized users.

Authentication
Authentication prevents unauthorized users from using a system by checking their identity through:
  

Something a user is acquainted with (usually passwords) Something the user owns, such as magnetic cards or badges Physical characteristics of the user, such as signature or fingerprints

SQL Server has two kinds of authentication:
 

Windows authentication SQL Server authentication

Windows authentication defines a user account that exists at the operating system level. SQL Server authentication defines a login that is created within SQL Server and is associated with a password. (Some SQL Server logins are identical to the existing Windows user accounts.)

NOTE
In addition to Windows user accounts and SQL Server logins, there are also Windows groups and SQL Server roles. A Windows group is a collection of Windows user accounts. Assigning a user account membership to a group gives the user all the permissions granted to the group. Similarly, a SQL Server role is a collection of SQL Server logins. (Roles are discussed in detail later in this chapter.)

ch12.indd 326

10/24/05 10:37:24 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

327

SQL Server security includes two different security subsystems:
 

Windows security SQL Server security

Windows security specifies security at the operating system level—that is, the method by which users connect to Windows using their Windows user accounts. SQL Server security specifies the additional security necessary at the SQL Server system level—that is, how users who have already logged on to the operating system can subsequently connect to SQL Server. Based on these two security subsystems, SQL Server can operate in one of these two authentication modes:
 

Windows mode Mixed mode

Windows mode exclusively uses Windows user accounts to log in to the SQL Server system. SQL Server accepts the user account, assuming it has already been validated at the operating system level. This kind of connection to a database system is called a trusted connection, because SQL Server trusts that the operating system already validated the account and the corresponding password. Mixed mode allows users to connect to SQL Server using Windows authentication or SQL Server authentication. This means some user accounts can be set up to use Windows security subsystem, while others can use SQL Server security subsystem additionally to Windows security subsystem.

NOTE
SQL Server Authentication is provided for backward compatibility only. For this reason, use Windows Authentication instead. Before we discuss how you can set SQL Server security, we have to describe the SQL Server encryption policy and mechanisms.

SQL Server Encryption Policy and Mechanisms
SQL Server secures data with hierarchical encryption layers and a key management infrastructure. Each layer secures the layer beneath it, using a combination of certificates, asymmetric keys, and symmetric keys. There are two layers (see Figure 12-1):
 

Service Master Key Database Master Key

ch12.indd 327

10/24/05 10:37:24 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

328

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e
Windows level SQL Server level Asymmetric keys Service Master Key encrypted with DPAPI Service Master Key Database Master Key Database level Symmetric keys Data

Certificates

Data

Symmetric keys Symmetric keys

Data

Figure 12-1 SQL Server security: the hierarchical encryption layers

The top layer, Service Master Key, is encrypted using the Windows data protection API. As you can see from Figure 12-1, Database Master Key depends on the encryption mechanisms, such as certificates and keys, which will be explained next.

Certificates
A public key certificate, usually just called a certificate, is a digitally signed statement that binds the value of a public key to the identity of the person, device, or service that holds the corresponding private key. Certificates are issued and signed by a certification authority (CA). The entity that receives a certificate from a CA is the subject of that certificate. Certificates contain the following information, among others:
   

The subject’s public key value The subject’s identifier information Issuer identifier information The digital signature of the issuer

A primary benefit of certificates is that they relieve hosts of the need to maintain a set of passwords for individual subjects. When a host, such as a secure web server, designates an issuer as a trusted authority, the host implicitly trusts that the issuer has verified the identity of the certificate subject.

ch12.indd 328

10/24/05 10:37:25 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

329

Symmetric and Asymmetric Keys
A symmetric key is an encryption system in which the sender and receiver of a message share a common key that is used to encrypt and decrypt the message. Thus, this single key is used for encryption as well as decryption. Encryption and decryption with a symmetric key is fast and suitable for routine use with sensitive data in the database. An asymmetric key consists of a private key and the corresponding public key. Each key can decrypt data encrypted by the other key. Asymmetric encryption is used, because it provides a higher level of security than symmetric encryption. An asymmetric key can be used to encrypt a symmetric key for storage in a database.

Setting Up SQL Server Security Using DDL
SQL Server security can be set up using either data definition language (DDL) statements or SQL Server system procedures. In this section we discuss data definition statements, while the next section describes all system procedures concerning security. The first statement to be considered is CREATE LOGIN. This statement creates a new SQL Server login. The syntax of the CREATE LOGIN statement is as follows: CREATE LOGIN login_name { WITH option_list1 | FROM {WINDOWS [ WITH option_list2 [,...] ] | CERTIFICATE certname | ASYMMETRIC KEY key_name }} login_name specifies the name of the SQL Server login that is being created. As you can see from the syntax of the statement, you can use the WITH clause to specify one or more options for the login or use the FROM clause to define certificate, asymmetric key, or Windows login associated with the corresponding SQL Server login. options_list1 contains several options. The most important one is the PASSWORD option. Using this option you specify the password of the login (see Example 12.1). (Among the other possible options are: DEFAULT_DATABASE, DEFAULT_ LANGUAGE and CHECK_EXPIRATION.) The FROM clause comprises three different options:
  

CERTIFICATE WINDOWS ASYMMETRIC KEY

The CERTIFICATE option specifies the name of the certificate to be associated with this login (see Example 12.2). The WINDOWS clause specifies that the login

ch12.indd 329

10/24/05 10:37:25 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

330

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

will be mapped to an existing Windows user account (see Example 12.3). This clause can be specified with other suboptions, such as DEFAULT_DATABASE and DEFAULT_LANGUAGE. Finally, the ASYMMETRIC KEY option specifies the name of the asymmetric key to be associated with this login. The certificate as well as the asymmetric key must already exist in the master database. EXAMPLE 12.1 USE sample CREATE CREDENTIAL DbLabor with identity = ‘dusan’ CREATE LOGIN dusan WITH PASSWORD = ‘you1know4it9’, CREDENTIAL= DbLabor In Example 12.1 we specify the SQL Server login called dusan, with the password you1know4it9 and credential called DbLabor. Before the CREATE LOGIN statement is executed, the credential used with it must be created (using the CREATE CREDENTIAL statement). EXAMPLE 12.2 USE sample CREATE CERTIFICATE cert02 WITH SUBJECT = ‘SQL Server 2005’, ENCRYPTION_PASSWORD = ‘pGFD4bb925DGvbd2439587y’; GO CREATE LOGIN claudia FROM CERTIFICATE cert02; Example 12.2 first creates the new certificate called cert02, and then it creates the new login claudia using the certificate cert02. EXAMPLE 12.3 USE sample CREATE LOGIN [NTB11901\pete] FROM WINDOWS; In Example 12.3 we specify the SQL Server login called pete, which will be mapped to a Windows user account with the same name. SQL Server also supports the ALTER LOGIN statement. This statement changes the properties of a SQL Server login. Using the ALTER LOGIN statement, you can change the current password and its expiration properties, credentials, default database, and default language. You can also enable or disable the specified login.

ch12.indd 330

10/24/05 10:37:25 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

331

The DROP LOGIN statement drops an existing SQL Server login. A login cannot be dropped if it owns any objects.

Setting Up SQL Server Security Using System Procedures
The following system procedures are used to set up SQL Server security:
     

sp_addlogin sp_droplogin sp_password sp_grantlogin sp_revokelogin sp_denylogin

The first three procedures, which concern SQL Server logins, will be explained in the following section, while the last three, which concern Windows user accounts and groups, will be discussed in the subsequent section.

System Procedures Concerning Logins
The sp_addlogin system procedure has the same effect as the CREATE LOGIN statement. This means that it creates a new SQL Server login, which can subsequently be used by the user to log in to the SQL Server system using SQL Server Authentication. Example 12.4 shows the use of the sp_addlogin system procedure. EXAMPLE 12.4 USE sample sp_addlogin ‘peter’, ‘xxyyzz’, ‘sample’ GO sp_addlogin ‘mary’, ‘zzyyxx’, ‘sample’ GO sp_addlogin ‘paul’, ‘xyz123’, ‘sample’ The sp_addlogin system procedure in Example 12.4 creates three new SQL Server logins: peter, paul, and mary. The default database for all three logins is sample.

ch12.indd 331

10/24/05 10:37:25 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

332

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

NOTE
The sp_addlogin system procedure will be removed in a future version of SQL Server. Use the CREATE LOGIN statement instead. The sp_droplogin system procedure drops an existing SQL Server login. It is not possible to remove a SQL Server login that still has access to any database of the SQL Server system. The user must first be removed using the DROP USER statement (discussed a bit later in the chapter).

NOTE
The sp_droplogin system procedure will be removed in a future version of SQL Server. Use the DROP LOGIN statement instead. The sp_password system procedure adds a new password to a SQL Server login or replaces the existing one. Users can change their own password at any time by using this system procedure. The system administrator can change any password by using sp_password and specifying NULL as the parameter for the old password.

System Procedures Concerning Windows Users
There are also three system procedures concerning Windows users and groups: sp_grantlogin, sp_revokelogin, and sp_denylogin. The system procedure sp_grantlogin allows a Windows user or group to connect to SQL Server or resets previous sp_denylogin restrictions for users within the group. The system procedure sp_revokelogin removes the login entries for a Windows user or group from SQL Server. The system procedure sp_denylogin prevents a Windows user or group from connecting to SQL Server (even if a group that contains this user or group is granted access). Only the system or security administrators can execute these three system procedures.

Schema
We described schema already in Chapter 4, where we introduced the CREATE SCHEMA statement as one of the DDL statements of Transact-SQL language. The notion of schema has very big impact in SQL Server 2005, because SQL Server uses schema in its security model to simplify the relationship between users and objects. The following sections are dedicated to this feature and its role in SQL Server security. First we describe the relationship between schemas and users; then we discuss all three Transact SQL statements concerning schema creation and modification.

ch12.indd 332

10/24/05 10:37:26 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

333

User-Schema Separation
Schema is a collection of database objects that are owned by a single person and form a single namespace. (Two tables in the same schema cannot have the same name.)

NOTE
SQL Server 2000 does not separate users and schemas, because it supports only unnamed schemas and the AUTHORIZATION clause specifies the owner (see Example 4.12). In SQL Server 2000, database users and schemas are implicitly connected. Also, this connection is fixed and cannot be modified. For that reason, every database user is the owner of a schema that has the same name as the user. SQL Server 2005 breaks the tight relationship between users and schemas, which existed in the previous version. Now, SQL Server 2005 supports named schemas using the notion of principal. A principal is an entity that can access objects. A principal can be
 

Indivisible principal Group principal

An indivisible principal represents a single user, such as a SQL Server login or Windows user account. A group principal can be a group of users, such as a SQL Server role or Windows group. Principals are ownerships of schemas, but the ownership of a schema can be transferred easily to another principal and without changing the schema name. The separation of database users from schemas provides significant benefits, such as:
 

One principal can own several schemas Several indivisible principals can own a single schema via membership in SQL Server roles or Windows groups Droppping a database user does not require the renaming of objects contained by that user’s schema



SQL Server 2005 introduces the notion of default schema, which is used to resolve the names of objects that are referred to without their fully qualified names. The default schema specifies the first schema that will be searched by the server when it resolves the names of objects. The default schema can be set and changed using the DEFAULT_SCHEMA option of the CREATE USER or ALTER USER statement.

ch12.indd 333

10/24/05 10:37:26 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

334

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

If the DEFAULT_SCHEMA option is left undefined, the database user will have dbo as its default schema. (All default schemas will be described in detail in the section “Default Database Schemas” later in this chapter.)

DDL Statements Concerning Schema
Because SQL Server 2005 separates users from schemas, we will discuss the Transact SQL statements concerning schemas first and then discuss those concerning users. There are three statements concerning schemas:
  

CREATE SCHEMA ALTER SCHEMA DROP SCHEMA

We will use the slightly modified example from Chapter 4 (Example 4.12) to explain how SQL Server 2005 uses schemas to control security of databases. EXAMPLE 12.5 USE sample GO CREATE SCHEMA my_schema AUTHORIZATION peter CREATE TABLE product (product_no CHAR(10) NOT NULL UNIQUE, product_name CHAR(20) NULL, price MONEY NULL) CREATE VIEW product_info AS SELECT product_no, product_name FROM product GRANT SELECT TO mary DENY UPDATE TO mary

NOTE
Before you start Example 12.5, you have to create database users peter and mary. For this reason, first execute the Transact-SQL statements in Example 12.8. In Example 12.5 we create the schema called my_schema, which comprises the product table and a view (product_info). The user called peter is the database-level principal that owns the schema. You use the AUTHORIZATION option to define the

ch12.indd 334

10/24/05 10:37:26 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

335

principal of a schema. (The principal may own other schemas and may not use the current schema as his default schema.) Also, there are two other statements concerning permissions of database objects, and they are called GRANT and DENY. The first one grants the SELECT permissions for all objects created in the schema, while the second one denies the UPDATE permissions for all objects of the schema. (The GRANT and DENY statements are discussed in detail at the end of this chapter.) The CREATE SCHEMA statement can create a schema, the tables and views it contains, and grant, revoke, or deny permissions on a securable in a single statement. (Securables are resources to which the SQL Server authorization system regulates access. There are three securable scopes, server, database, and schema, which contain other securables, such us SQL Server login, database users, tables, and stored procedures.) The CREATE SCHEMA is atomic. In other words, if any error occurs during the execution of a CREATE SCHEMA statement, none of the Transact-SQL statements specified in the schema will be executed. Database objects that are created in a CREATE SCHEMA statement can be specified in any order, with one exception: A view that references another view must be specified after the referenced view. A database-level principal could be either database user, role, or application role. (Roles and application roles will be discussed in a moment.) The principal that is specified in the AUTHORIZATION clause of the CREATE SCHEMA statement is the owner of all objects created within a schema. Ownership of schema-contained objects can be transferred to any other database-level principal using the ALTER AUTHORIZATION statement (see Example 12.7). The user needs the CREATE SCHEMA permission on the database to execute the CREATE SCHEMA statement. Also, to create the objects specified within the CREATE SCHEMA statement, the user needs the corresponding CREATE permissions. The ALTER SCHEMA statement transfers an object between different schemas of the same database. The syntax of the ALTER SCHEMA statement is as follows: ALTER SCHEMA schema_name TRANSFER object_name The following example shows the use of the ALTER SCHEMA statement. EXAMPLE 12.6 USE AdventureWorks ALTER SCHEMA humanresources TRANSFER person.address In Example 12.6 we alter the schema called humanresources of the AdventureWorks database by transferring into it the address table from the person schema of the same database.

ch12.indd 335

10/24/05 10:37:26 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

336

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

The ALTER SCHEMA statement can only be used to transfer objects between different schemas in the same database. (Single objects within a schema can be altered using the ALTER TABLE statement, i.e., ALTER VIEW statement, as described in Chapter 4.) The DROP SCHEMA statement removes a schema from the database. You can successfully execute the DROP SCHEMA statement for a schema, only if the schema does not contain any objects. Otherwise, the DROP SCHEMA statement will be rejected by the system. As we already stated, SQL Server 2005 allows you to change the ownership of a schema. You can do this using the ALTER AUTHORIZATION statement. The ALTER AUTHORIZATION statement modifies the ownership of an entity.

NOTE
SQL Server does not support CREATE AUTHORIZATION or DROP AUTHORIZATION statements. You specify the ownership of an entity using the CREATE SCHEMA statement. Example 12.7 shows the use of the CREATE AUTHORIZATION statement to change the ownership of the schema called my_schema (Example 12.5). EXAMPLE 12.7 USE sample ALTER AUTHORIZATION ON SCHEMA ::my_schema TO mary;

Database Security
A Windows user account or a SQL Server login allows a user to log in to the SQL Server system. A user who subsequently wants to access a particular database of the system also needs a database user account to work in the database. Therefore, users must have a database user account for each database they want to use. The database user account can be mapped from the existing Windows user accounts, Windows groups (of which the user is a member), SQL Server logins, or roles.

Setting Up Database User Accounts with DDL
Database security permissions can be set up using either Transact-SQL statements or system procedures. In this section we will explain how to set up user accounts with Transact-SQL statements.

ch12.indd 336

10/24/05 10:37:26 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

337

The CREATE USER statement adds a user to the current database. The syntax of this statement is CREATE USER user_name [FOR {LOGIN login_name | CERTIFICATE cert_name | ASYMMETRIC KEY key_name}] [ WITH DEFAULT_SCHEMA = schema_name ] user_name is the name that is used to identify the user inside the database. login_name specifies the SQL Server login for which the user is being created. cert_name and key_ name specify the corresponding certificate and asymmetric key, respectively. Finally, the WITH DEFAULT SCHEMA option specifies the first schema that will be searched by the server when it resolves the names of objects for this database user. Example 12.8 demonstrates the use of the CREATE USER statement. EXAMPLE 12.8 USE sample CREATE USER peter FOR LOGIN [NTB11901\pete] CREATE USER mary FOR LOGIN mary WITH DEFAULT_SCHEMA = my_schema;

NOTE
To execute the first statement successfully, create the Windows account named pete and change the server name NTB11901. The first CREATE USER statement creates the database user called peter for the Windows login with the name pete (see Example 12.3). The database user peter will use dbo as its default schema, because the DEFAULT SCHEMA option is omitted. (All default schemas will be described later in this chapter.) The second statement creates a new database user with the name mary. This user has my_schema as her default schema. (The DEFAULT_SCHEMA option can be set to a schema that does not currently exist in the database.)

NOTE
Each database of the SQL Server system has its own specific users. Therefore, the CREATE USER statement must be executed once for each database where a user account should exist for a database login. Also, a SQL Server login can have only a single database user for a given database.

ch12.indd 337

10/24/05 10:37:27 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

338

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

The ALTER USER statement either modifies a database user name or changes its default schema. Similar to the CREATE USER statement, it is possible to assign a default schema to a user before the creation of the schema. The DROP USER statement removes a user from the current database. Users that own securables, i.e., database objects, cannot be dropped from the database.

Setting Up Database User Accounts Using System Procedures
The following system procedures can also be used to establish database security permissions:
   

sp_grantdbaccess sp_revokedbaccess sp_helpuser sp_changedbowner

NOTE
Generally, you should not use the system procedures sp_grantdbaccess and sp_revokedbaccess to set up database user accounts. These system procedures will be removed in a future version of SQL Server. Use CREATE USER and DROP USER instead. The sp_grantdbaccess system procedure adds a new database user to the current database and associates it with an existing security account (login). The login can be a Windows user, Windows group, or SQL Server login. Example 12.9 shows the use of the sp_grantdbaccess system procedure. (Before the execution of Example 12.9, you have to drop the existing database users peter and mary using the DROP USER statement.) EXAMPLE 12.9 USE sample GO sp_grantdbaccess ‘peter’, ‘peter’ GO sp_grantdbaccess ‘mary’, ‘mary’ GO sp_grantdbaccess ‘paul’, ‘paul’

ch12.indd 338

10/24/05 10:37:27 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

339

In Example 12.9, the sp_grantdbaccess system procedure creates the database users, which are identical to the corresponding logins created in Example 12.4. The sp_revokedbaccess system procedure removes an existing database user from the current database. (The database user can be a Windows user account, Windows group, or Microsoft SQL Server login.) The sp_helpuser system procedure displays information about one or more database users in the current database. If the user is omitted, sp_helpuser displays the information about all existing database users and roles in the current database. The sp_changedbowner system procedure changes the owner of the current database. After the execution of the procedure, the specified login is the new database owner (dbo) of the current database. All members of the sysadmin fixed server role and the owner of the current database can execute this system procedure.

Default Database Schemas
Each database within the SQL Server 2005 system contains the following default database schemas:
   

guest dbo INFORMATION_SCHEMA sys

The SQL Server system allows users without user accounts to access database objects belonging to the guest schema. (After creation, each database contains this schema.) You can apply permissions to the guest schema in the same way as to any other schema. Also, you can drop and add the guest schema from any database except the master and tempdb system databases. Each database object belongs to one and only one schema, which is default schema for that object. The default schema can be defined explicitly or implicitly. If the default schema isn’t defined explicitly during the creation of an object, that object has the dbo schema as its default schema. The INFORMATION_SCHEMA schema contains all information schema views (see Chapter 11). The sys schema, as you may have already guessed, contains system objects, such as catalog views.

ch12.indd 339

10/24/05 10:37:27 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

340

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

Roles
When several users need to perform similar activities in a particular database (and there is no corresponding Windows group), it is possible to add a role in this database. A database role specifies a group of database users that can access the same objects of the database. Members of a database role can be any of the following:
  

Windows groups and user accounts SQL Server logins Other roles

The security architecture in SQL Server includes several roles that have special implicit permissions. There are two types of predefined roles in addition to roles that can be created by the database owner. These roles are classified as follows:
  

Fixed server Fixed database User-defined

Fixed Server Roles
Fixed server roles are defined at the server level and therefore exist outside of databases belonging to the database server. Table 12-1 lists all existing fixed server roles.

Fixed Server Role
sysadmin serveradmin setupadmin securityadmin processadmin dbcreator diskadmin

Description
Performs any activity in SQL Server Configures server settings Installs replication and manages extended procedures Manages logins and CREATE DATABASE permissions and reads audits Manages SQL Server processes Creates and modifies databases Manages disk files

Table 12-1 Fixed Server Roles

ch12.indd 340

10/24/05 10:37:27 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

341

The following two system procedures are used to add or delete members to a fixed server role:
 

sp_addsrvrolemember sp_dropsrvrolemember

NOTE
You cannot add, modify, or remove fixed server roles. Additionally, only the members of fixed server roles can execute both system procedures to add or remove login accounts to/from the role.

The sa Login
The sa login is the login of the system administrator. In previous versions, where roles did not exist, the sa login was granted all possible permissions concerning system administration tasks. In SQL Server 2005, the sa login is included for backward compatibility. The sa login is always a member of the sysadmin fixed server role and cannot be dropped from the role.

NOTE
Use the sa login only when there is not another way to log in to the SQL Server system.

Fixed Server Roles and Their Permissions
Each fixed server role has its implicit permissions within a SQL Server system. You can view the permissions for each fixed server role using the sp_srvrolepermission system procedure. The syntax of this procedure is sp_srvrolepermission [[@srvrolename =] ‘role’] If you do not specify the value for role, the permissions for all fixed server roles are displayed. The following sections discuss permissions of each fixed server role.

sysadmin
Members of the sysadmin fixed server role are granted all possible permissions for the SQL Server system. For example, only someone with this role (or a user who has been granted the CREATE DATABASE permission from a member of this role) can create databases. This fixed server role has special relationships with the sa login. The sa login is always a member of this role and cannot be dropped from the role.

ch12.indd 341

10/24/05 10:37:28 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

342

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

serveradmin
Members of the serveradmin fixed server role can perform the following activities:
   

Add other logins to this server role Run the dbcc pintable command (to pin a table in the main memory) Run the sp_configure system procedure (to display or change system options) Run the reconfigure option (to update all modifications made with the sp_configure system procedure) Shut down the database server using the shutdown command Run the sp_tableoption system procedure to set option values for a userdefined table

 

setupadmin
Members of the setupadmin fixed server role can perform the following activities:
  

Add other logins to this server role Add, drop, or configure linked servers Execute some system stored procedures, such as sp_serveroption

securityadmin
Members of the securityadmin fixed server role perform all activities in relation to server access and its security. They may perform the following system activities:
  

Add other logins to this server role Read the SQL Server error log Run the following system procedures: sp_addlinkedsrvlogin, sp_addlogin, sp_defaultdb, sp_defaultlanguage, sp_denylogin, sp_droplinkedsrvlogin, sp_droplogin, sp_grantlogin, sp_helplogins, sp_remoteoption, and sp_ revokelogin. (All these system procedures are related to the system security.)

processadmin
Members of the processadmin fixed server role manage SQL Server processes, such as aborting the user’s runaway queries. They can perform the following activities:
 

Add other logins to this server role Execute the KILL command (to kill user processes)

ch12.indd 342

10/24/05 10:37:28 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

343

dbcreator
Members of the dbcreator fixed server role manage all activities concerning the creation and modification of a database. They can perform the following activities:
  

Add other logins to this server role Run the CREATE DATABASE and ALTER DATABASE statements Modify the name of a database using the sp_renamedb system procedure

diskadmin
Members of the diskadmin fixed server role can perform the following activities concerning files and file groups that are used to store database objects:
  

Add other logins to this server role Run the following system procedures: sp_addumpdevice and sp_dropdevice Run the DISK INIT statement

Fixed Database Roles
Fixed database roles are defined at the database level and therefore exist in each database belonging to the database server. Table 12-2 lists all of the fixed database roles.

Fixed Database Role
db_owner db_accessadmin db_datareader db_datawriter db_ddladmin db_securityadmin db_backupoperator db_denydatareader db_denydatawriter Table 12-2

Description
Users who can perform almost all activities in the database Users who can add or remove users Users who can see data from all user tables in the database Users who can add, modify, or delete data in all user tables in the database Users who can perform all DDL operations in the database Users who can manage all activities concerning security permissions in the database Users who can back up the database (and issue DBCC and CHECKPOINT statements, which are often performed before a backup) Users who cannot see any data in the database Users who cannot change any data in the database

Fixed Database Roles

ch12.indd 343

10/24/05 10:37:28 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

344

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

Besides the fixed database roles listed in Table 12-2, there is a special fixed database role called public, which will be explained first.

public Role
The public role is a special fixed database role to which every legitimate user of a database belongs. It captures all default permissions for users in a database. This provides a mechanism for giving all users without appropriate permissions a set of (usually limited) permissions. The public role maintains all default permissions for users in a database and cannot be dropped. This role cannot have users, groups, or roles assigned to it because they belong to the role by default. (Example 12.21 shows the use of the public role.) By default, the public role allows users to do the following:


View system tables and display information from the master database using certain system procedures Execute statements that do not require permissions—for example, PRINT



Fixed Database Roles and Their Permissions
Each fixed database role has its specific permissions within a database. This means that permissions of a member of a fixed database role are limited to a specific database. You can view the permissions for each fixed database role using the sp_dbfixedrolepermission system procedure. The syntax of this procedure is sp_dbfixedrolepermission [[@rolename =] ‘role’] If you do not specify the value for role, the permissions for all fixed database roles are displayed. In the following sections, permissions of each fixed database role are discussed.

db_owner
Members of the db_owner fixed database role may perform the following activities in the specific database:
   

Add members to or remove members from any other fixed database role Run all DDL statements Run BACKUP DATABASE and BACKUP LOG statements Explicitly start the checkpoint process using the CHECKPOINT statement

ch12.indd 344

10/24/05 10:37:28 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

345



Run the following dbcc commands: dbcc checkalloc, dbcc checkcatalog, dbcc checkdb, dbcc updateusage Grant, revoke, or deny the following permissions on every database object: SELECT, INSERT, UPDATE, DELETE, and REFERENCES Add users or roles to a database with the following system procedures: sp_addapprole, sp_addrole, sp_addrolemember, sp_approlepassword, sp_changeobjectowner, sp_dropapprole, sp_droprole, sp_droprolemember, sp_dropuser, sp_grantdbaccess Rename any database object using the sp_rename system procedure







db_accessadmin
Members of the db_accessadmin fixed database role perform all activities in relation to database access. They may perform the following activities in the specific database:


Run the following system procedures: sp_addalias, sp_dropalias, sp_dropuser, sp_grantdbaccess, sp_revokedbaccess Add or remove access for Windows user accounts, Windows groups, and SQL Server logins



db_datareader
Members of the db_datareader fixed database role have SELECT permissions on any database object (table or view) in a database. However, they cannot grant this permission to any other user or role. (The same is true for the REVOKE statement.)

db_datawriter
Members of the db_datawriter fixed database role have INSERT, UPDATE, and DELETE permissions on any database object (table or view) in a database. However, they cannot grant the permission to any other user or role. (The same is true for the REVOKE statement.)

db_ddladmin
Members of the db_ddladmin fixed database role can perform the following activities:
 

Run all DDL statements Grant the REFERENCES permission on any table

ch12.indd 345

10/24/05 10:37:28 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

346

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e


Modify the structure of any stored procedures with the sp_procoption and sp_recompile system procedures Rename any database object using the sp_rename system procedure Modify table options and the owner of any database object using the system procedures sp_tableoption and sp_changeobjectowner, respectively

 

db_securityadmin
Members of the db_securityadmin fixed database role manage security in the database. They can perform the following activities:


Run all Transact-SQL statements concerning security (GRANT, DENY, and REVOKE) Run the following system procedures: sp_addapprole, sp_addrole, sp_addrolemember, sp_approlepassword, sp_changeobjectowner, sp_dropapprole, sp_droprole, sp_droprolemember



db_backupoperator
Members of the db_backupoperator fixed database role manage the process of backing up a database. They can perform the following activities:
  

Run BACKUP DATABASE and BACKUP LOG statements Explicitly start the checkpoint process using the CHECKPOINT statement Run the following dbcc commands: dbcc checkalloc, dbcc checkcatalog, dbcc checkdb, dbcc updateusage

db_denydatareader and db_denydatawriter
As the name states, members of the db_denydatareader fixed database role do not have the SELECT permission on any database object (table or view) in the database. You should use this role if your database contains sensitive data that should not be read by some users. Members of the db_denydatawriter fixed database role do not have the INSERT, UPDATE, and DELETE permissions on any database object (table or view) in the database.

Application Roles
Application roles allow you to enforce security for a particular application. In other words, they allow the application itself to accept the responsibility of user authentication,

ch12.indd 346

10/24/05 10:37:28 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

347

instead of SQL Server. For instance, if clerks in your company change an employee’s data only using an existing application (and not Transact-SQL statements or any other tool), you can create an application role for it. Application roles differ significantly from all other role types. First, application roles have no members, because they use the application only and therefore do not need to grant permissions directly to users. Second, you need a password to activate an application role. When an application role is activated for a session by the application, the session loses all permissions applied to logins, user accounts, or roles in all databases for the duration of the session.

Creating Application Roles
You can create application roles using:
 

CREATE APPLICATION ROLE statement sp_addapprole system procedure

The CREATE APPLICATION ROLE statement creates an application role to the current database. This statement has two options: one concerning the specification of the password and one for the definition of the default schema, i.e., first schema that will be searched by the server, when it resolves the names of objects for this role. Example 12.10 shows the creation of an application role. EXAMPLE 12.10 USE sample CREATE APPLICATION ROLE weekly_reports WITH PASSWORD =‘x1y2z3w4’, DEFAULT_SCHEMA =my_schema Example 12.10 adds a new application role called weekly_reports to the current database. The second way to create a new application role is by using the sp_addapprole system procedure. Using the sp_addapprole system procedure, you can create application roles and assign permissions to them. This procedure has the following syntax: sp_addapprole [@rolename =] ‘role’, [@passwd_name =] ‘password’

ch12.indd 347

10/24/05 10:37:28 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

348

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

role specifies the name of the application role, while password is the corresponding password. (The value for password is required to activate the role.)

NOTE
The sp_addapprole system procedure will be removed in a future version of SQL Server. Avoid using this feature. Use the CREATE APPLICATION ROLE statement instead.

Activating Application Roles
After a connection is started, it must execute the sp_setapprole system procedure to activate the permissions that are associated with an application role. This procedure has the following syntax: sp_setapprole [@rolename =] ‘role’ , [@password =] ‘password’ [,[@encrypt =] ‘encrypt_style’] role is the name of the application role defined in the current database. password specifies the corresponding password, while encrypt_style defines the encryption style specified for the password. When you activate an application role using the sp_setapprole system procedure, you have to know the following:


After the activation of an application role, you cannot deactivate it in the current database until the session is disconnected from SQL Server. An application role is always database bound—that is, its scope is the current database. If you change the current database within a session, you are allowed to perform (other) activities based on the permissions in that database.



NOTE
Any user can execute the sp_setapprole system procedure by providing the correct password for the application role.

Modifying Application Roles
You can modify application roles using the following Transact SQL statements:
 

ALTER APPLICATION ROLE DROP APPLICATION ROLE

ch12.indd 348

10/24/05 10:37:29 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

349

The ALTER APPLICATION ROLE statement changes the name, password, or default schema of an existing application role. The syntax of this statement is similar to the syntax of the CREATE APPLICATION ROLE statement. To execute the ALTER APPLICATION ROLE statement, you need the ALTER permission on the role. The DROP APPLICATION ROLE statement removes the application role from the current database. If the application role owns any objects (securables), it cannot be dropped.

NOTE
You can also use the sp_dropapprole system procedure to drop an application role, but this procedure will be removed in a future version of SQL Server.

User-Defined Database Roles
Generally, user-defined database roles are applied when a group of database users need to perform a common set of activities within a database and no applicable Windows group exists. These roles are managed using the Transact-SQL statements or SQL Server system procedures. Next we will discuss Transact-SQL statements and then the corresponding system procedures.

Roles and Transact-SQL
The CREATE ROLE statement creates a new database role in the current database. The syntax of this statement is CREATE ROLE role_name [AUTHORIZATION owner_name] role_name is the name of the user-defined role to be created. owner_name specifies the database user or role that will own the new role. (If no user is specified, the role will be owned by the user that executes the CREATE ROLE statement.) The ALTER ROLE statement changes the name of a user-defined database role. Similarly, the DROP ROLE statement drops a role from the database. Roles that own database objects (securables) cannot be dropped from the database. To drop such a role, you must first transfer ownership of those objects. The syntax of the DROP ROLE statement is as follows: DROP ROLE role_name

ch12.indd 349

10/24/05 10:37:29 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

350

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

Roles and System Procedures
The alternative way to create or modify user-defined roles is to use SQL Server system procedures. The following system procedures are used to set up and display the user-defined database roles:
    

sp_addrole sp_addrolemember sp_droprolemember sp_droprole sp_helprole

The sp_addrole system procedure creates a new role in the current database. Only members of the db_securityadmin or db_owner database roles can execute this system procedure.

NOTE
The sp_addrole system procedure is included in SQL Server 2005 only for backward compatibility and may not be supported in a future release. Use the CREATE ROLE statement instead. After adding a role to the current database, you can use the system procedure sp_addrolemember to add members of the role. The member of the role can be any valid SQL Server user, Windows group or user, or another SQL Server role. Only members of the db_owner database role can execute this system procedure. Additionally, role owners can execute sp_addrolemember to add a member to any role that they own. The sp_droprolemember system procedure removes an existing member from the role. (It is not possible to use this system procedure to remove an existing Windows user from a Windows group.) Only members of the db_owner or db_securityadmin database roles can execute this system procedure. After removing all members from the role using the system procedure sp_droprolemember, you can use the sp_droprole system procedure to remove a role from the current database. (A role with existing members cannot be dropped.) Only members of the db_owner or db_securityadmin database roles can execute this system procedure.

ch12.indd 350

10/24/05 10:37:29 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

351

NOTE
The sp_droprole system procedure is included in SQL Server 2005 only for backward compatibility and may not be supported in a future release. Use the DROP ROLE statement instead. The sp_helprole system procedure displays information (role name and role ID number) about a particular role or all roles in the current database if no role name is provided. Only the members of the db_owner or db_securityadmin roles can execute this system procedure.

Authorization
Only authorized users are able to execute statements or perform operations on a securable. Otherwise, the execution of the Transact-SQL statement or the operation on the database object will be rejected. SQL Server supports three Transact-SQL statements concerning authorization:
  

GRANT DENY REVOKE

Before we describe these three statements, we will state one of the most important properties of SQL Server 2005 concerning security: SQL Server 2005 introduces multiple scopes and permissions to help database administrators handle permissions. The new authorization model separates the world into principals and securables. Every SQL Server securable has associated permissions that can be granted to a principal. Principals, such as individuals, groups, or applications can access securables. Securables are the resources to which the SQL Server authorization system regulates access. As we already stated, there are three securable scopes: server, database, and schema, which contain other securables, such as SQL Server login, database users, tables, and stored procedures.

GRANT Statement
The GRANT statement grants permissions to SQL Server securables. The syntax of the GRANT statement is GRANT permission_list [ON scope] TO principal_list [WITH GRANT OPTION] [ AS {windows_group | sqlserver_login | db_user |db_role | appl_role } ]

ch12.indd 351

10/24/05 10:37:29 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

352

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

permission_list specifies either statements or objects (separated by commas) for which the permissions are granted. scope specifies either a securable class or a securable name for which permission will be granted. principal_list lists all accounts (separated by commas) to which permissions are granted. The components of principal_list can be a Windows user account, SQL Server login, login or user account mapped to certificate, login mapped to asymmetric key, database user, database role, or application role.

NOTE
SQL Server 2000 divides all permissions into two permission groups: statement permissions and object permissions, which use slightly different syntax of the GRANT statement to grant permissions to Transact-SQL statements and database objects. SQL Server 2005 has a uniform syntax of the GRANT statement for both permission groups. Table 12-3 shows all permissions with their description, as well as the list of the corresponding securables that you can apply to them.

NOTE
Table 12-3 shows only the most important permissions. SQL Server 2005 security model is hierarchical. Hence, there are many granular permissions that are not listed in the table. You can find the description of these permissions in Books Online. Next we will demonstrate the use of the GRANT statement with several examples. EXAMPLE 12.11 USE sample GRANT CREATE TABLE, CREATE PROCEDURE TO peter, paul, mary Example 12.11 demonstrates the use of the CREATE permission. In this example, the users peter, paul, and mary can execute the Transact-SQL statements CREATE TABLE and CREATE PROCEDURE. (As you can see from this example, the GRANT statement with the CREATE permission does not include the ON option.) Example 12.12 allows the user mary to create user-defined functions in the sample database.

ch12.indd 352

10/24/05 10:37:30 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

353

Permission
SELECT

Applies to
Tables + columns, synonyms, views + columns, table-valued functions

Description
Provides the ability to select (read) rows. You can restrict this permission to one or more columns by listing them. (If the list is omitted, all columns of the table can be selected.) Provides the ability to insert rows. Provides the ability to modify column values. You can restrict this permission to one or more columns by listing them. (If the list is omitted, all columns of the table can be modified.) Provides the ability to delete rows.

INSERT UPDATE

Tables + columns, synonyms, views + columns Tables + columns, synonyms, views + columns

DELETE REFERENCES

Tables + columns, synonyms, views + columns

User-defined functions (SQL and CLR), Provides the ability to reference columns of the tables + columns, synonyms, views + foreign key in the referenced table when the columns user has no SELECT permission for the referenced table. Stored procedures (SQL and CLR), Provides the ability to execute the specified user-defined functions (SQL and CLR), stored procedure or user-defined functions. synonyms Stored procedures (SQL and CLR), This permission grants ownership-like capabilities user-defined functions (SQL and CLR), on the grantee; the grantee effectively has all synonyms defined permissions on the securable. A principal that has been granted CONTROL also has the ability to grant permissions on the securable. CONTROL at a particular scope implicitly includes CONTROL on all the securables under that scope (see Example 12.17). Stored procedures (SQL and CLR), The ALTER permissions grant the ability to alter user-defined functions (SQL and CLR), the properties (except ownership) of a particular tables, views securable. When granted on a scope, it also bestows the ability to ALTER, CREATE, or DROP any securable contained within that scope. Stored procedures (SQL and CLR), The TAKE OWNERSHIP permission allows the user-defined functions (SQL and CLR), grantee to take ownership of the securable on tables, views, synonyms which it is granted.

EXECUTE

CONTROL

ALTER

TAKE OWNERSHIP

Table 12-3 Permissions with Corresponding Securables

ch12.indd 353

10/24/05 10:37:30 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

354

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

Permission
VIEW DEFINITION

Applies to

Description

Stored procedures (SQL and CLR), The VIEW DEFINITION permission controls the user-defined functions (SQL and CLR), ability for the grantee to see the metadata of the tables, views, synonyms securable (see Example. 12.16). Transfers to the grantee the ability to create the server securable. Transfers to the grantee the ability to create the database securable.

CREATE (Server securable) n/a CREATE (DB securable) Table 12-3 n/a

Permissions with Corresponding Securables (continued)

EXAMPLE 12.12 USE sample GRANT CREATE FUNCTION TO mary The following example shows the use of the ALL clause. This clause indicates that all permissions applicable to the specified securable will be granted to the specified principal. EXAMPLE 12.13 USE sample GRANT ALL TO mary In Example 12.13, the user mary can use all allowed Transact-SQL statements in the sample database. The following example shows the use of the SELECT permission within the GRANT statement. EXAMPLE 12.14 USE sample GRANT SELECT ON employee TO peter, mary In Example 12.14, the users peter and mary can read rows from the employee table.

ch12.indd 354

10/24/05 10:37:30 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

355

NOTE
When a permission is granted to a Windows user account or a database user account, this account is the only account affected by the permission. On the other hand, if a permission is granted to a group or role, the permission affects all users belonging to the group (role). By default, if user A grants a permission to user B, then user B can only use the permission to execute the Transact-SQL statement listed in the GRANT statement. The WITH GRANT OPTION gives user B the additional capability of granting the privilege to other users (see Example 12.18). The following example shows the use of the UPDATE permission within the GRANT statement. EXAMPLE 12.15 USE sample GRANT UPDATE ON works_on (emp_no, enter_date) TO paul In Example 12.15, the user paul can modify two columns of the works_on table: emp_no and enter_date. The following example shows the use of the VIEW DEFINITION permission. EXAMPLE 12.16 USE sample GRANT VIEW DEFINITION ON OBJECT::employee TO peter GRANT VIEW DEFINITION ON SCHEMA::dbo to peter Example 12.16 shows two GRANT statements concerning the VIEW DEFINITION permission. The first one allows the user peter to see metadata concerning the employee table of the sample database. (The OBJECT securable is one of the base securables, and you can use this securable to give permissions for specific objects, such as tables, views, and stored procedures.) Because of the hierarchical structure of securables, you can use a “higher” securable to extend the VIEW DEFINITION (or any other base) permission. The second statement in Example 12.16 gives the user peter access to metadata of all the objects of the dbo schema of the sample database.

ch12.indd 355

10/24/05 10:37:30 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

356

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

NOTE
In previous versions of SQL Server, it is possible to query information on all database objects, even if these objects are owned by another user. The VIEW DEFINITION permission now allows you to grant or deny access to different pieces of your metadata and hence to decide which part of metadata is visible for other users. The following example shows the use of the CONTROL permission. EXAMPLE 12.17 USE sample GRANT CONTROL ON DATABASE::sample TO peter In Example 12.17 the user peter effectively has all defined permissions on the securable (in this case, the sample database.). A principal that has been granted CONTROL also implicitly has the ability to grant permissions on the securable, i.e., the CONTROL permission includes the WITH GRANT OPTION clause (see the following example). The CONTROL permission is the highest permission in relation to several base securables. For this reason, CONTROL at a particular scope implicitly includes CONTROL on all the securables under that scope. Therefore, peter’s CONTROL permission on the sample database implies all permissions on this database, all permissions on all assemblies in the database, all permissions on all schemas in the sample database, and all permissions on objects within the sample database. The following example shows the use of the WITH GRANT OPTION clause of the GRANT statement. EXAMPLE 12.18 USE sample GRANT SELECT ON works_on TO mary WITH GRANT OPTION In Example 12.18, the user mary can use the SELECT statement to retrieve rows from the works_on table and also may grant this privilege to other users of the current database.

ch12.indd 356

10/24/05 10:37:30 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

357

DENY Statement
The DENY statement prevents users from performing actions. This means that it removes existing permissions from user accounts or prevents users from gaining permissions through their group/role membership that might be granted in the future. This statement has the following syntax form: DENY permission_list [ON scope] TO principal_list [CASCADE] [ AS {windows_group | sqlserver_login | db_user |db_role | appl_role } ] All options of the DENY statement have the same logical meaning that the options with the same name in the GRANT statement. The only difference is the CASCADE option. This option specifies that permissions will be denied to user A and any other users to whom user A passed this permission. (If the CASCADE option is not specified in the DENY statement and the corresponding object permission was granted with the WITH GRANT OPTION, an error is returned.) The DENY statement prevents the user, group, or role from gaining access to the permission granted through their group or role membership. This means that if a user belongs to a group (or role) and the granted permission for the group is denied to him or her, this user will be the only one of the group who cannot use this permission. On the other hand, if a permission is denied for a whole group, all members of the group will be denied the permission.

NOTE
You can think of the GRANT statement as a “positive” and the DENY statement as a “negative” user authorization. Usually, the DENY statement is used to deny already-existing permissions for groups (roles) to a few members of the group. EXAMPLE 12.19 USE sample DENY CREATE TABLE, CREATE PROCEDURE TO peter, paul The DENY statement in Example 12.19 denies two already-granted statement permissions (Example 12.12) to the users peter and paul.

ch12.indd 357

10/24/05 10:37:30 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

358

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

EXAMPLE 12.20 USE sample GRANT SELECT ON project TO PUBLIC DENY SELECT ON project TO peter, mary Example 12.20 shows the negative authorization of some users of the current database. First, the retrieval of all rows of the project table is granted to all users of the sample database. After that, this permission is denied to two users: peter and mary.

REVOKE Statement
The REVOKE statement removes one or more already-granted (or denied) permissions. This statement has the following syntax: REVOKE [GRANT OPTION FOR] permission_list [ON scope] FROM principal_list [CASCADE] [ AS {windows_group | sqlserver_login | db_user |db_role | appl_role } ] The only new option in the REVOKE statement is GRANT OPTION FOR. (All other options have the same logical meaning as the options with the same names in the GRANT or DENY statement.) GRANT OPTION FOR is used to remove the effects of the WITH GRANT OPTION in the corresponding GRANT statement. This means that the user will still have the previously granted permissions but will no longer be able to grant the permission to other users.

NOTE
The REVOKE statement revokes “positive” permissions specified with the GRANT statement as well as “negative” permissions generated by the DENY statement. Therefore, its function is to neutralize the specified (positive or negative) permissions. EXAMPLE 12.21 USE sample REVOKE SELECT ON project FROM PUBLIC The REVOKE statement in Example 12.21 revokes the granted permission for the public role. At the same time, the existing “negative” permissions for the users peter

ch12.indd 358

10/24/05 10:37:31 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

359

and mary are not revoked (Example 12.20), because the explicitly granted or denied permissions are not affected by revoking permissions from roles or groups.

Views and Data Access
As already stated in Chapter 10, views can be used for the following purposes:
  

To restrict the use of particular columns and/or rows of tables To hide the details of complicated queries To restrict inserted and updated values to certain ranges

Restricting the use of particular columns and/or rows means that the view mechanism of SQL Server provides itself with the control of data access. For example, if the table with employee data also contains the salaries of each employee, then access to these salaries can be restricted using a view that accesses all columns of the table except the salary column. Subsequently, retrieval of data from the table can be granted to all users of the database using the view, while only a small number of (privileged) users will have the same permission for all data of the table. Examples 12.22, 12.23, and 12.24 show the use of views to restrict the access to data. EXAMPLE 12.22 USE sample GO CREATE VIEW v_without_budget AS SELECT project_no, project_name FROM project Using the v_without_budget view, it is possible to divide users into two groups: first, the group of privileged users who can read (write) the budget of all projects and second, the group of common users who can read all rows from the projects table, but not the data from the budget column. EXAMPLE 12.23 USE sample GO ALTER TABLE employee

ch12.indd 359

10/24/05 10:37:31 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

360

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

ADD user_name CHAR(60) DEFAULT SYSTEM_USER GO CREATE VIEW v_my_rows AS SELECT emp_no, emp_fname, emp_lname, dept_no FROM employee WHERE user_name = SYSTEM_USER

NOTE
The Transact-SQL statements in Example 12.23 must be separately executed, because the CREATE VIEW statement must be the first statement in the batch. That is why the GO statement is used (to mark the end of the first batch). The schema of the employee table is modified in Example 12.23 by adding the new column user_name. Every time a new row is inserted into the employee table, the current value of the system user name is inserted into the user_name column. After the creation of the corresponding view v_my_rows, a user can retrieve only the rows that she inserted into the table. (The same is true for the UPDATE statement.) EXAMPLE 12.24 USE sample GO CREATE VIEW v_analyst AS SELECT employee.emp_no, emp_fname, emp_lname FROM employee, works_on WHERE employee.emp_no = works_on.emp_no AND job = ‘Analyst’ The v_analyst view represents a horizontal and a vertical subset (in other words, it limits the rows and columns that can be accessed) of the employee table.

Stored Procedures and Data Access
Stored procedures can also be used to restrict data access. The restriction of data access using stored procedures is based upon the property that the permission to execute a stored procedure is independent of any permissions for database objects that are referenced by the stored procedure. More precisely, granting permission to

ch12.indd 360

10/24/05 10:37:31 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

361

execute a stored procedure suffices if the owner of the stored procedure is also the owner of all the referenced database objects. EXAMPLE 12.25 USE sample GO CREATE PROCEDURE analyst_data AS SELECT employee.emp_no, emp_fname, emp_lname FROM employee, works_on WHERE employee.emp_no = works_on.emp_no AND job = ‘Analyst’ In Example 12.25, users of the analyst_data stored procedure see a horizontal and a vertical subset of the employee table. Neither the SELECT permission for the employee table nor the same permission for the works_on table is needed to use this procedure. (The user must have only the EXECUTE permission for the analyst_data procedure.)

Conclusion
Security of a database system always concerns two topics:
 

Authentication Authorization

Authentication specifies which user has been granted legitimate access to the database system. Authorization defines which privileges are valid for a particular user. SQL Server can operate in one of two authentication modes:
 

Windows Mixed

Windows authentication mode exclusively uses Windows user accounts to log in to the SQL Server system. Mixed mode allows users to connect to SQL Server using the Windows authentication or the SQL Server authentication. SQL Server supports authorization with the following Transact-SQL statements: GRANT, DENY, and REVOKE.

ch12.indd 361

10/24/05 10:37:31 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

362

M i c r o s o f t S Q L S e r v e r 2 0 0 5 : A B e g i n n e r ’s G u i d e

SQL Server 2005 contains several new features in relation to security. The most important ones are the following:
 

Separation of schemas and users New Transact-SQL statements, such as CREATE LOGIN, CREATE USER, and CREATE ROLE. (The corresponding ALTER and DROP statements exist, too.) Encryption hierarchy, with Service Master Key and Database Master Key The new authorization model that separates the world in principals end entities. Every SQL Server entity, i.e., securable has associated permissions that can be granted to a principal. Permissions hierarchy, with new permissions such as CONTROL, ALTER, and VIEW DEFINITION.

 



SQL Server provides a mechanism called a trigger that enforces general integrity constraints. This mechanism is discussed in detail in the next chapter.

Exercises
E.12.1 What is a difference between Windows authentication mode and Mixed mode? E.12.2 What is a difference between a SQL Server login and database user account? E.12.3 Create three new SQL Server logins called ann, burt, and chuck. The corresponding passwords are abc, def, and fgh, respectively. The default database is the sample database. After creating the logins, check their existence using SQL Server catalog views. E.12.4 Using system procedures, create three new database names for the logins in E.12.3. The new names are s_ann, s_burt, and s_chuck.

ch12.indd 362

10/24/05 10:37:31 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12

Chapter 12: SQL Server Security

363

E.12.5 Create a new user-defined database role called managers and add three members (see E.12.4) to the role. After that, display the information concerning this role and its members. E.12.6 Using the GRANT statement, allow the user s_peter to create tables and the user s_mary to create stored procedures in the sample database. E.12.7 Using the GRANT statement, allow the user s_paul to update the columns lname and fname of the employee table. E.12.8 Using the GRANT statement, allow the users s_peter and s_mary to read the values from the columns emp_lname and emp_fname of the employee table. (Hint: create the corresponding view first.) E.12.9 Using the GRANT statement, allow the user-defined role managers to insert new rows in the projects table. E.12.10 Revoke the SELECT rights from the user s_peter. E.12.11 Using Transact-SQL, do not allow the user s_mary to insert the new rows in the projects table either directly or indirectly (using roles). E.12.12 Discuss the difference between the use of views and Transact-SQL statements in relation to SQL Server security. E.12.13 Display the existing information about the user s_mary in relation to the sample database. (Hint: use the system procedure sp_helpuser.)

ch12.indd 363

10/24/05 10:37:32 AM

D_Base / Microsoft SQL Server 2005: ABG / Petkovic / 226093-9 / Chapter 12 Blind folio 364

ch12.indd 364

10/24/05 10:37:32 AM

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close