Microsoft SQL Server 2008 R2 Unleashed- P36 docx

ptg 304 CHAPTER 11 Security and User Administration 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. Download from www.wowebook.com ptg 305 Managing Principals 11 TABLE 11.3 Fixed Database Roles Role Permission 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 b reakdown of perm issions associated with f ixed da tabase 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. Download from www.wowebook.com ptg 306 CHAPTER 11 Security and User Administration 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’, Download from www.wowebook.com ptg 307 Managing Principals 11 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 Download from www.wowebook.com ptg 308 CHAPTER 11 Security and User Administration 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 Download from www.wowebook.com ptg 309 Managing Securables 11 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 encr ypt 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 Download from www.wowebook.com ptg 310 CHAPTER 11 Security and User Administration TABLE 11.4 SQL Server 2008 Securables Server Database Schema Logins User Table Endpoints Role View Databases Application role Function Assembly Procedure Message Type Queue Route Type Service Synonym 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. Download from www.wowebook.com ptg 311 Managing Permissions 11 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: Download from www.wowebook.com ptg 312 CHAPTER 11 Security and User Administration . 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.” Download from www.wowebook.com ptg 313 Managing SQL Server Logins 11 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. Download from www.wowebook.com . 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. 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. in this chapter, in the section “Managing SQL Server Permissions.” Download from www.wowebook.com ptg 313 Managing SQL Server Logins 11 Managing SQL Server Logins You can create and administer