Sql server 2005 Security Best Practices Operational and Administrative Tasks

Administrator Privileges

• 
  Members of the sysadmin server role.
  
• 
  The sa built-in login, if it is enabled.
  
• 
  Any login with CONTROL SERVER permission.
  

SQL Server automatically grants the server's Administrators group (BUILTIN\administrators) the sysadmin server role. When running SQL Server 2005 under Microsoft Windows Vista™, the operating system does not recognize membership in the BUILTIN\Administrators group unless the user has elevated themselves to a full administrator. In SP2, you can use SQL Server Surface Area Configuration to enable a principal to act as administrator by selecting Add New Administrator from the main window as shown in Figure 3.

Figure 3   Adding a new administrator in SP2 SQL Server Surface Area Configuration

Figure 4   The SQL Server 2005 User Provisioning Tool for Vista

For accountability in the database, avoid relying on the Administrators group and add only specific database administrators to the sysadmin role. Another option is to have a specific DatabaseAdministrators role at the operating system level. Minimizing the number of administrators who have sysadmin or CONTROL SERVER privilege also makes it easier to resolve problems; fewer logins with administrator privilege means fewer people to check with if things go wrong. The permission VIEW SERVER STATE is useful for allowing administrators and troubleshooters to view server information (dynamic management views) without granting full sysadmin or CONTROL SERVER permission.

Best practices for administrator privileges

• 
  Use administrator privileges only when needed.
  
• 
  Minimize the number of administrators.
  
• 
  Provision admin principals explicitly.
  
• 
  Have multiple distinct administrators if more than one is needed.
  
• 
  Avoid dependency on the builtin\administrators Windows group.
  

Database Ownership and Trust

SQL Server can be thought of as running in two distinct modes, which can be referred to as IT department mode and ISV mode. These are not database settings but simply different ways to manage SQL Server. In an IT department, the sysadmin of the instance manages all user databases. In an Internet service provider environment (say, a Web-hosting service), each customer is permitted to manage their own database and is restricted from accessing system databases or other user databases. For example, the databases of two competing companies could be hosted by the same Internet service provider (ISV) and exist in the same SQL Server instance. Dangerous code could be added to a user database when attached to its original instance, and the code would be enabled on the ISV instance when deployed. This situation makes controlling cross-database access crucial.

If each database is owned and managed by the same general entity, it is still not a good practice to establish a "trust relationship" with a database unless an application-specific feature, such as cross-database Service Broker communication, is required. A trust relationship between databases can be established by allowing cross-database ownership chaining or by marking a database as trusted by the instance by using the TRUSTWORTHY property. An example of setting the TRUSTWORTHY property follows:
ALTER DATABASE pubs SET TRUSTWORTHY ON
Best practices for database ownership and trust

• 
  Have distinct owners for databases; not all databases should be owned by sa.
  
• 
  Minimize the number of owners for each database.
  
• 
  Confer trust selectively.
  
• 
  Leave the Cross-Database Ownership Chaining setting off unless multiple databases are deployed at a single unit.
  
• 
  Migrate usage to selective trust instead of using the TRUSTWORTHY property.
  

Schemas

Schemas solve an administration problem that occurs when each database object is named after the user who creates it. In SQL Server versions prior to 2005, if a user named Bob (who is not dbo) creates a series of tables, the tables would be named after Bob. If Bob leaves the company or changes job assignments, these tables would have to be manually transferred to another user. If this transfer were not performed, a security problem could ensue. Because of this, prior to SQL Server 2005, DBAs were unlikely to allow individual users to create database objects such as tables. Each table would be created by someone acting as the special dbo user and would have a user name of dbo. Because, in SQL Server 2005, schemas can be owned by roles, special roles can be created to own schemas if needed—every database object need not be owned by dbo. Not having every object owned by dbo makes for more granular object management and makes it possible for users (or applications) that need to dynamically create tables to do so without dbo permission.

Having schemas that are role-based does not mean that it’s a good practice to have every user be a schema owner. Only users who need to create database objects should be permitted to do so. The ability to create objects does not imply schema ownership; GRANTing Bob ALTER SCHEMA permission in the payroll_app schema can be accomplished without making Bob a schema owner. In addition, granting CREATE TABLE to a user does not allow that user to create tables; the user must also have ALTER SCHEMA permission on some schema in order to have a schema in which to create the table. Objects created in a schema are owned by the schema owner by default, not by the creator of the object. This makes it possible for a user to create tables in a known schema without the administrative problems that ensue when that user leaves the company or switches job assignments.

Each user has a default schema. If an object is created or referenced in a SQL statement by using a one-part name, SQL Server first looks in the user's default schema. If the object isn't found there, SQL Server looks in the dbo schema. The user's default schema is assigned by using the CREATE USER or ALTER USER DDL statements. If the default schema is specified, the default is dbo. Using named schemas for like groups of database objects and assigning each user's default schema to dbo is a way to mandate using two-part object names in SQL statements. This is because objects that are not in the dbo schema will not be found when a one-part object name is specified. Migrating groups of user objects out of the dbo schema is also a good way to allow users to create and manage objects if needed (for example, to install an application package) without making the installing user dbo.

Best practices for using schemas

• 
  Group like objects together into the same schema.
  
• 
  Manage database object security by using ownership and permissions at the schema level.
  
• 
  Have distinct owners for schemas.
  
• 
  Not all schemas should be owned by dbo.
  
• 
  Minimize the number of owners for each schema.