The Omedian Technical Architecture - Red Gate Software

Page 8 of 90Chapter 1: SQL Server Security Crib Sheetdb_datawriterdb_ddladmindb_securityadmindb_backupoperatordb_denydatareaderdb_denydatawriterallows the user to add, change, or delete data from all user tables in the database.allows the user to make any data definition language commands in the database.allows the user to manage statement and object permissions in the database.allows the user to back up (but not restore) the database.will deny permission to select data in the database.will deny permission to change data in the database.To allow a user to add users to the database and manage roles and permissions, the user should be a member ofboth the db_accessadmin role and the db_securityadmin role.Some of these Roles are of a rather specialist nature. Of these Database Roles, possibly the most useful are thedb_denydatareader and db_denydatawriter role If the application interface consists entirely of views and storedprocedures, while maintaining ownership chains and completely avoiding dynamic SQL, then it is possible toassign the db_denydatareader and db_denydatawriter Role for regular users, to prevent their access to the basetables.Public Database RoleA Public Database Role is created when a database is created. Every database user belongs to the Public Role.The Public Role contains the default access permissions for any user who can access the database. This DatabaseRole cannot be droppedApplication RolesApplication Roles are the SQL Server Roles created to support the security needs of an application. They allow auser to relinquish his user permissions and take on an Application Role. However, they are not easy to use inconjunction with connection pooling.Authorisation: The Permissions SystemThe database user has no inherent rights or permissions other than those given to the Public Role. All rights mustbe explicitly granted or assigned to the user, the user's Roles, or the Public Role. The Permission Systemdetermines which Roles or users can access or alter data or database objects. It determines what every Role oruser can do within the database. The SA bypasses the permission system, and so has unrestricted access.Most commonly, permissions are given to use a database object such as a table, or procedure. Such objectpermissions allow a user, Role, or Windows NT user or group to perform actions against a particular object in adatabase. These permissions apply only to the specific object named when granting the permission, not to all theother objects contained in the database. Object permissions enable users to give individual user accounts therights to run specific Transact-SQL statements on an object.Permissions can be given or revoked for users and Roles. Permissions given directly to users take precedenceover permissions assigned to Roles to which the user belongs. When creating a permission system, it is often bestto set up the more general permissions first. Start with the Public Role first and then set up the other Roles,finally doing the overrides for individual users where necessary.The permission system has a hierarchy of users for which permissions are automatically given.Page 8Chapter 1: SQL Server Security Crib Sheet