844
Part VI: Securing Your SQL Server
a login is granted such rights. As a result, this is a prime way that attackers would seek to
secure elevated access to SQL Server and attempt to keep their tracks a bit more hidden.Unless you have a compelling reason to manage the permissions on an individual-statement
level as with CREATE LOGIN or CREATE USER, it’s easier to manage the database adminis-
trative tasks using the fi xed database roles.The grant, revoke, and deny commands are detailed in the next section.Object Security
If the user has access to the database, permission to the individual database objects may be
granted. Permission may be granted either directly to the user or to a user-defi ned 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.User-Defi ned Database Roles
User-defi ned database roles, sometimes called user-defi ned 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 member-
ships, can be assigned to a user-defi ned database role, and users can then be assigned to
the role.Best Practice
The cleanest SQL Server security plan is to assign object permissions to user-defi ned database roles
and then to assign users to the roles.Object Permissions
Several specifi c types of permissions exist:■ (^) Select: The right to select data. Select permission can be applied to specifi c
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 specifi c
columns.
■ (^) Delete: The right to delete existing data.
c33.indd 844c33.indd 844 7/31/2012 10:01:24 AM7/31/2012 10:01:24 AM
http://www.it-ebooks.info