Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1182 Part VII Security To view the assigned roles using code, query the sysserver_principals catalog view to select the members, joined with the sysserver_role_members, and joined again to the sysserver_principals to select the roles. Database Security Once a user has gained access to the server, access may be granted to the individual user databases. Database security is potentially complex. Users are initially granted access to databases by adding them to the database. Guest logins Any user who wishes to access a database but has not been declared a user within the database will automatically be granted the user privileges of the guest database user if the guest user account exists (refer to Figure 49-1). The guest user is not automatically created when a database is created. It must be specifically added in code or as a database user. The guest login does not need to be predefined as a server login: EXEC sp_adduser ‘Guest’ Be very careful with the guest user. While it may be useful to enable a user to access the database without setting him or her up, the permissions granted to the guest user apply to everyone without access to the database. The guest user must be removed from a database when guests are no longer welcome. Granting access to the database Users must be explicitly granted access to any user database. Because this is a many-to-many relation- ship between logins and database, you can manage database access from either the login side or the database side. When a login is granted access to the database, the login is also assigned a database username, which may be the same as the login name or some other name by which the login will be known within the database. To grant access to a database from the login side using Object Explorer, use the User Mapping page of the Login Properties form (shown in Figure 49-6). Many security settings involve multiple objects such as users and databases or roles and object permissions. These settings can be made from either the Login Permissions form or the role’s or object’s Properties page. To grant access from the database point of view, use the New User Context Menu command under the Database ➪ Security ➪ Users node to open the Database User-New form, shown in Figure 49-7. Enter the login to be added in the Login Name field. To search for a login, use the ellipses ( ) button. You must enter a name by which the user will be known within the database in the User Name field. 1182 www.getcoolebook.com Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1183 Authenticating Principals 49 FIGURE 49-6 You can use the Login Properties form to grant a login access to any database and to assign database roles. Granting access using T-SQL code Of course, a stored procedure is available to grant database access to a user: CREATE USER.Thestored procedure must be issued from within the database to which the user is to be granted access. The first parameter is the server login, and the second is the optional database username: USE Family CREATE USER ‘XPS\Lauren’, ‘LRN’ Lauren now appears in the list of database users as ‘‘LRN.’’ To remove Lauren’s database access, the system stored procedure DROP USER requires her database username, not her server login name: USE Family DROP USER ‘LRN’ 1183 www.getcoolebook.com Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1184 Part VII Security FIGURE 49-7 The Login dialog box can be used to add a new user to the database or to manage the current user. To query a database user using T-SQL, select from the sys.database_principals catalog view. Fixed database roles SQL Server includes a few standard, or fixed, database roles. Like the server fixed roles, these primarily organize administrative tasks. A user may belong to multiple roles. The fixed database roles include the following: ■ db_accessadmin: Can authorize a user to access the database, but not manage database-level security 1184 www.getcoolebook.com Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1185 Authenticating Principals 49 ■ db_backupoperator: Can perform backups, checkpoints, and DBCC commands, but not restores (only server sysadmins can perform restores) ■ db_datareader: Can read all the data in the database. This role is the equivalent of a grant on all objects, and it can be overridden by a deny permission. ■ db_datawriter: Can write to all the data in the database. This role is the equivalent of a grant on all objects, and it can be overridden by a deny permission. ■ db_ddladmin: Can issue DDL commands (create, alter, drop) ■ db_denydatareader: Can read from any table in the database. This deny will override any object-level grant. ■ db_denydatawriter: Blocks modifying data in any table in the database. This deny will override any object-level grant. ■ db_owner: A special role that has all permissions in the database. This role includes all the capabilities of the other roles. It is different from the dbo user role. This is not the database- level equivalent of the server sysadmin role; an object-level deny will override membership in this role. ■ db_securityadmin: Can manage database-level security — roles and permissions Assigning fixed database roles with Management Studio The fixed database roles can be assigned with Management Studio with either of the following two procedures: ■ Adding the role to the user in the user’s Database User Properties form (see Figure 49-7), either as the user is being created or after the user exists. ■ Adding the user to the role in the Database Role Properties dialog. Select Roles under the database’s Security node, and use the context menu to open the Properties form (see Figure 49-8). Assigning fixed database roles with T-SQL From code, you can add a user to a fixed database role with the sp_addrole system stored procedure. To examine the assigned roles in T-SQL, query the sysdatabase_role_members catalog view joined with sysdatabase_principal. Application roles An application role is a database-specific role intended to allow an application to gain access regardless of the user. For example, if a specific Visual Basic program is used to search the Customer table and it doesn’t handle user identification, the VB program can access SQL Server using a hard-coded application role. Anyone using the application gains access to the database. Because using an application role forfeits the identity of the user, I strongly advise against using application roles. The user can regain identity context using sp_unsetapprole. 1185 www.getcoolebook.com Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1186 Part VII Security FIGURE 49-8 The Database Role Properties dialog lists all users assigned to the current role. To add or remove users from the role, use the Add and Remove buttons, respectively. Summary In this era of cybercrime, data security is more important than ever. Security is integral to the Informa- tion Architecture Principle. While it’s possible to set all the users to sysadmin and ignore security, with a little effort SQL Server security is functional and flexible enough to meet the needs presented by a variety of situations. 1186 www.getcoolebook.com Nielsen c50.tex V4 - 07/21/2009 3:26pm Page 1187 Authorizing Securables IN THIS CHAPTER Object ownership Securables permissions Object security Views and security T his chapter adds another important piece to the SQL Server security puzzle — securables. These are objects (for example, tables, views, stored procedures, columns) that can be secured in order to prevent unauthorized access. Object Ownership A very important aspect of SQL Server’s security model involves object ownership. Every object is contained by a schema. The default schema is dbo — not to be confused with the dbo role. Ownership becomes critical when permission is being granted to a user to run a stored procedure when the user doesn’t have permission to the underlying tables. If the ownership chain from the tables to the stored procedure is consistent, then the user can access the stored procedure, and the stored procedure can access the tables as its owner. However, if the ownership chain is broken, meaning there’s a different owner somewhere between the stored procedure and the table, then the user must have rights to the stored procedure, the underlying tables, and every other object in between. There is a fine point in the details. A schema is owned; and because a schema is owned, anything that is contained by it has the same owner. Most security management can be performed in Management Studio. With code, security is managed by means of the GRANT, REVOKE,andDENY Data Control Language (DCL) commands and several system stored procedures. 1187 www.getcoolebook.com Nielsen c50.tex V4 - 07/21/2009 3:26pm Page 1188 Part VII Security Object Security If a user has access to the database, then permission to the individual database objects may be granted. Permission may be granted either directly to the user or to a standard role and the user assigned to the role. Users may be assigned to multiple roles, so multiple security paths from a user to an object may exist. Standard database roles Standard database roles, sometimes called user-defined roles, can be created by any user in the server sysadmin, database db_owner, or database security admin role. These roles are similar to those in user groups in Windows. Permissions, and other role memberships, can be assigned to a standard database role, and users can then be assigned to the role. Best Practice T he cleanest SQL Server security plan is to assign object permissions and fixed roles to standard database roles, and then to assign users to the roles. Object permissions Several specific types of permissions exist: ■ Select: The right to select data. Select permission can be applied to specific columns. ■ Insert: The right to insert data ■ Update: The right to modify existing data. Update rights for which a WHERE clause is used require select rights as well. Update permission can be set on specific columns. ■ Delete: The right to delete existing data ■ DRI (References): The right to create foreign keys with DRI ■ Execute: The right to execute stored procedures or user-defined functions Object permissions are assigned with the SQL DCL commands, GRANT, REVOKE,andDENY.The permissions in SQL Server work like they do in the operating system. SQL Server aggregates all the permissions a given user might have, whether directly assigned against the user or through the roles. Then SQL Server gives the MAXIMUM of what has been granted. DENY is an exception. DENY functions as a trump. If anywhere a DENY has been issued, then just like in Windows, the user is blocked. For instance, if a user can SELECT against a table directly assigned, but a role the user is a member of has a DENY for SELECT, then the user is blocked from issuing a SELECT against the table. Whether security is being managed from Management Studio or from code, it’s important to understand these three commands. Granting object permission interacts with the server and database roles. Here’s the overall hierarchy of roles and grants, with 1 overriding 2, and so on: 1188 www.getcoolebook.com Nielsen c50.tex V4 - 07/21/2009 3:26pm Page 1189 Authorizing Securables 50 1. The sysadmin server role. A Windows login that owns a database will be mapped to dbo, and because it maps to dbo, it ignores all security on the database. 2. Deny object permission or the db_denydatareader database role or the db_denydatawriter database role. 3. Grant object permission or object ownership or the db_datareader database role or the db_datawriter database role. Best Practice A n easy way to test security is to configure the server for mixed mode and create a SQL Server Login test user. Using Management Studio, it’s easy to create additional connections as different users — much easier than it is to change the server registration and log into Management Studio as someone else. Since SQL Server 2005 it has been possible to create a database principal that does not map to a server principal using the CREATE USER command a nd specifying WITHOUT LOGIN. Then, using EXECUTE AS USER = ‘<username>’ to switch security contexts, the security can be tested. REVERT, of course, switches the context back. If your environment prohibits mixed-mode security, then the easiest way to check security is to right- click Management Studio or Query Analyzer and use the RUN AS command to run as a different user, but this entails creating dummy users in the Windows domain. Generally speaking, in a ‘‘production’’ Windows domain, most auditors would flag dummy users as an audit point. Since workstations belonging to DBAs tend to belong in production domains, this recommendation wouldn’t work where the auditors are being diligent. Granting object permissions with code Setting an object’s permission is the only security command that can be executed without a system stored procedure being called: GRANT Permission, Permission ON Object TO User/role, User/role WITH GRANT OPTION The permissions may be ALL, SELECT, INSERT, DELETE, REFERENCES, UPDATE,orEXECUTE.The role or username refers to the database username, any user-defined public role, or the public role. For example, the following code grants select permission to Joe for the Person table: GRANT Select ON Person TO Joe The next example grants all permissions to the public role for the Marriage table: GRANT All ON Marriage TO dbcreator 1189 www.getcoolebook.com Nielsen c50.tex V4 - 07/21/2009 3:26pm Page 1190 Part VII Security Multiple users or roles, and multiple permissions, may be listed in the command. The following code grants select and update permission to the guest user and to LRN: GRANT Select, Update ON Person to Developer, LRN The WITH GRANT option provides the ability to grant permission for the object. For example, the following command grants Joe the permission to select from the Person table and grant select permission to others: GRANT Select ON Person TO Joe WITH GRANT OPTION Revoking and denying object permission with code Revoking and denying object permissions uses essentially the same syntax as granting permission. The following statement revokes select permissions from Joe on the Marriage table: REVOKE All ON Marriage TO Joe If the permission included the WITH GRANT OPTION, then the permission must be revoked or denied with the CASCADE option so that the WITH GRANT OPTION will be removed. The following command denies select permissions to Joe on the Person table: DENY Select ON Person TO Joe CASCADE Because using CASCADE will revoke not only the WITH GRANT OPTION permission, the DBA can get rid of the ability to GRANT but must first get rid of the permission, including WITH GRANT OPTION,and then re- GRANT the original permission, but this time without specifying WITH GRANT OPTION. The public role The public role is a fixed role, but it can have object permissions like a standard role. Every user is automatically a member of the public role and cannot be removed, so the public role serves as a baseline or minimum permission level. Be careful when applying permissions to the public role because it will affect everyone except members of the sysadmin role. Granting access will affect everyone; more impor- tant, denying access will block all users except members of the sysadmin role, even object owners, from accessing data. Managing roles with code Creating standard roles with code involves using the sp_addrole system stored procedure. The name can be up to 128 characters and cannot include a backslash, be null, or be an empty string. By default, the roles will be owned by the dbo user. However, you can assign the role an owner by adding a second parameter. The following code creates the manager role: CREATE ROLE ‘Manager’ 1190 www.getcoolebook.com Nielsen c50.tex V4 - 07/21/2009 3:26pm Page 1191 Authorizing Securables 50 Result: New role added. The counterpart of creating a role is removing it. A role may not be dropped if any users are currently assigned to it. The sp_droprole system stored procedure will remove the role from the database: DROP ROLE ‘Manager’ Result: Role dropped. Once a role has been created, users may be assigned to the role by means of the sp_addrolemember system stored procedure. The following code sample assigns Joe to the manager role: EXEC sp_addrolemember ‘Manager’, Joe Result: ’Joe’ added to role ‘Manager’. Not surprisingly, the system stored procedure sp_droprolemember removes a user from an assigned role. This code frees Joe from the drudgery of management: EXEC sp_dropRoleMember ‘Manager’, Joe Result: ’Joe’ dropped from role ‘Manager’. Hierarchical role structures If the security structure is complex, then a powerful permission-organization technique is to design a hierarchical structure of standard database roles. In other words, you can nest user-defined database roles. ■ The worker role may have limited access. ■ The manager role may have all worker rights plus additional rights to look up tables. ■ The administrator role may have all manager rights plus the right to perform other database administration tasks. To accomplish this type of design, follow these steps: 1. Create the worker role and set its permissions. 2. Create the manager role and set its permissions. Add the manager role as a user to the worker role. 3. Create the admin role. Add the admin role as a user to the manager role. The advantage of this type of security organization is that a change in the lower level affects all upper levels. As a result, administration is required in only one location, rather than dozens of locations. 1191 www.getcoolebook.com . functions Object permissions are assigned with the SQL DCL commands, GRANT, REVOKE,andDENY.The permissions in SQL Server work like they do in the operating system. SQL Server aggregates all the permissions. database user using T -SQL, select from the sys.database_principals catalog view. Fixed database roles SQL Server includes a few standard, or fixed, database roles. Like the server fixed roles, these. the server for mixed mode and create a SQL Server Login test user. Using Management Studio, it’s easy to create additional connections as different users — much easier than it is to change the server