Microsoft SQL Server 2008 R2 Unleashed- P36 docx

NOTE Keep in mind that when a login is assigned to certain fixed server roles, they have implied permissions that cascade to the database level.. Similarly, if a login is added to the se

NOTE

Keep in mind that when a login is assigned to certain fixed server roles, they have

implied permissions that cascade to the database level For example, if a login is

assigned to the sysadmin role, that login can perform any activity on the server, and it

can also perform any action on any database on that server Similarly, if a login is

added to the securityadmin role, the login can change permissions at the database

level as well as the server level

All the fixed server roles are listed in the SQL Server Management Studio (SSMS) Object

Explorer Figure 11.2 shows the Object Explorer with the Server Roles node expanded

You can right-click any of the roles and select Properties to display the logins that are

currently members of the role

Fixed Database Roles

SQL Server provides fixed roles that define a common set of permissions at the database

level These fixed database roles are assigned to database users The permissions defined

for the fixed database roles cannot be changed Table 11.3 shows the fixed database roles

and their permissions

FIGURE 11.2 Fixed server roles in Object Explorer

TABLE 11.3 Fixed Database Roles

db_accessadmin Allowed to add or remove database access for logins

db_backupoperator Allowed to back up the database

db_datareader Allowed to read all user table data

db_datawriter Allowed to change the data in all user tables

db_ddladmin Allowed to run any Data Definition Language (DDL) command against the

database This includes commands to create, alter, and drop database objects

db_denydatareader Denied the right to read all user table data

db_denydatawriter Denied the right to change the data in any of the user tables

db_owner Allowed to perform any action on the database Members of the

sysadmin fixed server role are mapped to this database role

db_securityadmin Allowed to manage permissions for database users, including

member-ship in roles

dbm_monitor Allowed to view the most recent status in the Database Mirroring

Monitor

NOTE

You can find a more granular breakdown of permissions associated with fixed database

roles in the SQL Server Books Online documentation Look for the subject

“Permissions of Fixed Database Roles.” The extensive table in this documentation

defines the specific permissions for each role For example, the table shows that the

db_backupoperator role is granted the BACKUP DATABASE, BACKUP LOG, and

CHECKPOINT permissions This gives you more insight into what the members of this

role can do Some fixed database roles have a large number of permission defined for

them, such as db_ddladmin, which has more than 30 individual permissions The

types of permissions and improved granularity available with SQL Server 2008 are

dis-cussed in the “Managing Permissions” section, later in this chapter

You can also find a list of fixed database roles in the Object Explorer Figure 11.3 shows

the fixed database roles for the AdventureWorks2008 database The roles are found under

the Security node within each database You can right-click a fixed database role and

select Properties to view the member users

FIGURE 11.3 The fixed database roles in Object Explorer

Fixed database roles and schemas are related Figure 11.3 shows the expanded Schemas

node for the AdventureWorks2008 database You can see that there is a corresponding

schema for each of the fixed database roles These schemas are automatically created, and

each is owned by the related database role

The public Role

The public role is a special database role that is like a fixed database role except that its

permissions are not fixed The permissions for this role can be altered Every user in a

database is automatically made a member of the public role and in turn receives any

permissions that have been granted to the public role Database users cannot be removed

from the public role

The public role is similar in function to the guest user that is installed by default in each

database The difference is that the permissions granted to the guest user are used by any

login that does not have a user account in the database In this case, the login is allowed

to enter the database via the guest account In the case of the public role, the login has

been added as a user of the database and in turn picks up any permissions that have been

granted to the public role

To view the permissions associated with the public role, you can use a SELECT statement

like the following:

SELECT top 5 g.name,

object_name(major_id) as ‘Object’,

permission_name

from sys.database_permissions p

join sys.database_principals g

on p.grantee_principal_id = g.principal_id

and g.name = ‘public’

order by 1,2

/*Results from the previous select

name Object permission_name

- -

-public all_columns SELECT

public all_objects SELECT

public all_parameters SELECT

public all_sql_modules SELECT

public all_views SELECT

*/

This SELECT utilizes two catalog views that contain security information The SELECT

returns only the first five permissions for the public role, but the TOP clause can be

removed to return all the permissions

User-Defined Roles

SQL Server enables you to create your own custom database roles Like the fixed roles,

user-defined roles can be used to provide a common set of permissions to a group of users

The key benefit behind using user-defined roles is that you can define your own set of

custom permissions that fit your needs User-defined roles can have a broad range of

permissions, including the more granular set of permissions made available with SQL

Server 2008

To demonstrate the power of a user-defined database role, let’s look at a simple example

Let’s say that you have a group of users who need to read all the tables in a database but

should be granted access to update only one table If you look to the fixed database roles,

you have the db_datareader and db_datawriter roles, which give you a partial solution

You can use the db_datareader role to allow the read capability you need, but the

db_datawriter role gives write permission to all the tables—not just one

One possible solution would be to give every user in the group membership to the

db_datareader group and assign the specific UPDATE permission to each user as well If the

group contains hundreds of users, you can see that this would be rather tedious Another

solution might be to create a Windows group that contains every user who needs the

permissions You can then assign a login and database user to this group and grant the

appropriate permissions The Windows group is a viable solution but can sometimes be

difficult to implement in a complex Windows domain

Another approach to this challenge is to use a user-defined database role You can create

the role in the database that contains the tables in question After you create the role,

you can include it in the db_datareader role, and you can establish the UPDATE

permis-sion to the single table Finally, you can assign the individual users or group of users to

the role Any future permission changes for this set of users can be administered through

the user-defined database role The script in Listing 11.1 steps through a process that

demonstrates and tests the addition of a database role This is similar to the example we

just walked through Parts of the script need to be run by an administrator, and other

parts should be run in a query editor window that is connected to the database with the

newly created testuser

LISTING 11.1 An Example of User-Defined Database Roles

The following statements must be run by an administrator to add

a login and database user with no explicit permissions granted

CREATE LOGIN [TestUser] WITH PASSWORD=N’pw’,

DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

GO

USE [AdventureWorks2008]

GO

CREATE USER [TestUser] FOR LOGIN [TestUser]

go

the following statement fails when executed by the TestUser

which has no explicit permissions defined in the AdventureWorks2008 database

select top 5 * from person.person

UPDATE person.person SET suffix = ‘Jr.’

WHERE FirstName = ‘Ken’

The following statement is run by an administrator to:

1)add a new TestDbRole with permission to UPDATE

2)grant UPDATE permission on the Person.person table

3)add the TestUser to the TestDbRole database role

USE [AdventureWorks2008]

GO

1)

CREATE ROLE [TestDbRole] AUTHORIZATION [dbo]

2)

GRANT UPDATE ON [Person].[Person] TO [TestDbRole]

GRANT SELECT ON [Person].[Person] TO [TestDbRole]

3)

EXEC sp_addrolemember N’TestDbRole’, N’TestUser’

the following statements now succeed when executed

by the TestUser because the role that it

was added to has SELECT and UPDATE permission

on that table

select top 5 * from person.person

UPDATE person.person SET suffix = ‘Jr.’

WHERE ContactID = 1

the following select fails because ‘testdbrole’

does not permit SELECT on any table but person.person

select * from person.ContactType

The following statement is run by an administrator

to add the TestDbRole database role to the db_datareader

fixed-database role

EXEC sp_addrolemember N’db_datareader’, N’TestDbRole’

GO

Finally, the testuser can update the Person.person table

and select from any other table in the database

select * from person.ContactType

Database roles and permissions are discussed in more detail later in this chapter, in the

sections “Managing Database Roles” and “Managing Permissions.”

Application Roles

Unlike other roles, application roles contain no database users When an application role

is created (see the section “Managing Database Roles,” later in this chapter), rather than

add a list of users who belong to the role, you specify a password To obtain the

permis-sions associated with the role, the connection must set the role and supply the password

This is done using the stored procedure sp_setapprole You set the role to the sales

application role (with the password PassW0rd) as follows:

EXEC sp_setapprole ‘sales’, ‘PassW0rd’

You can also encrypt the password:

EXEC sp_setapprole ‘sales’, {ENCRYPT N ‘ PassW0rd’}, ‘odbc’

When an application role is set, all permissions from that role apply, and all permissions

inherited from roles other than public are suspended until the session is ended

So why is it called an application role? The answer is in how it is used An application role

is used to provide permissions on objects through an application, and only through the

application Remember that you must use sp_setapprole and provide a password to

acti-vate the role; this statement and password are not given to the users; rather, they are

embedded in the application’s CONNECT string This means that the user can get the

permissions associated with the role only when running the application The application

can have checks and balances written into it to ensure that the permissions are being used

for the forces of good and not evil

Managing Securables

Securables are the entities in SQL Server on which permissions can be granted In other

words, principals (for example, users or logins) obtain permission to securables This

chapter describes many examples of securables, including tables, databases, and many

TABLE 11.4 SQL Server 2008 Securables

Databases Application role Function

Remote Service Binding Aggregate Fulltext Catalog XML Schema Collection

Certificate Asymmetric Key

Symmetric Key Contract Schema

entities that have been part of the SQL Server security model in past versions SQL Server

2008’s security model contains a granular set of securables for applying permissions

Securables are hierarchical in nature and are broken down into nested hierarchies of

named scopes Three scopes are defined: at the server, database, and schema levels Table

11.4 list the securables for each scope

As mentioned earlier, a hierarchy exists within each scope; in addition, relationships cross

scope boundaries Servers contain databases, databases contain schemas, and schemas

contain a myriad of objects that are also hierarchical When certain permissions are

granted on a securable at the server level the permissions cascade; meaning permission is

granted at the database and schema levels For example, if a login is granted control

permission at the server level, control is implicitly granted at the database and schema

levels The relationships between securables and permissions can be complicated The next

section details the different types of permissions and sheds some light on how these

permissions affect securables

Managing Permissions

Database security is mainly about managing permissions Permissions are the security

mechanisms that tie principals (for example, logins) to securables (for example, tables)

With SQL Server 2008, permissions can be applied at a granular level that provides a great

deal of flexibility and control

Permissions in SQL Server 2008 revolve around three commands: GRANT, REVOKE, and DENY

These three commands were also used in SQL Server 2005 and SQL Server 2000 When

permission is granted, the user or role is given permission to perform an action, such as

creating a table The DENY statement denies permission on an object and prevents the

prin-cipal from gaining GRANT permission based on membership in a group or role The REVOKE

statement removes a permission that was previously granted or denied

When specifying permissions, you need to carefully consider the hierarchy that exists

between GRANT, REVOKE, and DENY This is particularly important when the principal (for

example, user or login) is part of a group or role and permissions have been granted on

securables at different scopes of the security model Following are some examples of the

precedence that exists between these statements:

A GRANT of a permission removes any REVOKE or DENY on a securable For example, if

a table has SELECT permission denied on it and then the SELECT permission is

granted, the DENY permission is then removed on that table

DENY and REVOKE remove any GRANT permission on a securable

REVOKE removes any GRANT or DENY permission on a securable

Permissions denied at a higher scope in the security model override grants on that

permission at a lower scope Keep in mind that the security model has the server

scope at the highest level, followed by database and schema So, if INSERT

permis-sion is denied on tables at the database level, and INSERT on a specific table in that

database is granted at the schema level, the result is that INSERT is denied on all

tables In this example, a database-level DENY overrides any GRANT at the lower

schema level

Permissions granted at a higher scope in the security model are overridden by a DENY

permission at a lower level For example, if INSERT permission is granted on all tables

at the database scope, and INSERT is denied on a specific table in the database

(schema scope), INSERT is then denied on that specific table

The assignment of a permission includes the GRANT, DENY, or REVOKE statements plus the

permission that these statements affect The number of available permissions increased in

SQL Server 2005 and has been carried forward to SQL Server 2008 Familiar permissions

such as EXECUTE, INSERT, and SELECT that were available in SQL Server 2000 are still

around, plus the new permissions that were added in SQL Server 2005 Following are some

of the new types that were added in SQL Server 2005:

CONTROL—This type confers all defined permissions on the securable This

owner-ship-like capability also cascades to any lower-level objects in the security hierarchy

ALTER—This type confers the capability to change the securable’s properties but

does not include the capability to make ownership changes If ALTER is applied on a

scope such as a database or a schema, the capability to use ALTER, CREATE, or DROP on

any object in the scope is allocated as well

IMPERSONATE—This type allows the principal to impersonate another user or login.

VIEW DEFINITION—This type allows access to SQL Server metadata This type of

data is not granted by default in SQL Server 2008; therefore, the VIEW DEFINITION

permission was added to manage access

The combination of available permissions and the securables that they can be applied to is

extensive The permissions that are applicable depend on the particular securable SQL

Server Books Online lists the permissions for specific securables You can use the index

feature at Books Online to look for “permissions [SQL Server].” There, you will find a

section named “Permissions Applicable to Specific Securables” as well as a section named

“SQL Server Permissions” that lists each securable and its related permissions

You can also view the available permissions by using system functions and catalog views

The following example uses the sys.fn_builtin_permissions function to retrieve a partial

listing of all the available permissions:

SELECT top 5 class_desc, permission_name, parent_class_desc

FROM sys.fn_builtin_permissions(default)

order by 1,2

/* Results from previous query

class_desc permission_name parent_class_desc

- -

-APPLICATION ROLE ALTER DATABASE

APPLICATION ROLE CONTROL DATABASE

APPLICATION ROLE VIEW DEFINITION DATABASE

ASSEMBLY ALTER DATABASE

ASSEMBLY CONTROL DATABASE

*/

The granularity with which permissions can be applied with SQL Server 2008 is impressive

and, to some degree, challenging When you look at all the available permissions, you will

see that some planning is needed to manage them In the past, fixed database roles were

simple to use but in many cases provided permissions that went beyond what the user

needed Microsoft has supplied the tools to facilitate the concept of “least privileges,”

which means providing only the privileges that are needed and nothing more The tools

to help you manage permissions are discussed later in this chapter, in the section

“Managing SQL Server Permissions.”

Managing SQL Server Logins

You can create and administer logins easily using SSMS You can use T-SQL as well, but the

GUI screens are often the best choice The GUI screens present the configurable properties

for a login, including the available options, databases, and securables that can be assigned

to a login The number of configurable options is extensive and can be difficult to manage

with T-SQL

Using SSMS to Manage Logins

The visual tools for managing logins in SSMS are accessible via the Object Explorer You

need to expand the Security node in Object Explorer and right-click the Logins node Then

you select the New Login option, and the new login screen, shown in Figure 11.4, appears

The default authentication mode for a new login is Windows Authentication If you want

to add a login with Windows Authentication, you need to type the name of your

Windows user or group in the Login Name text box You can also click the Search button

to search for Windows logins In either case, the login entered for Windows

Authentication should be in the form <DOMAIN>\<UserName> (for example, mydomain\Chris)

or in the form user@company.com

FIGURE 11.4 Creating a login in SSMS with Windows Authentication