Security Features User's Guide

Home

Security Features User's Guide

Chapter 1: Introduction to Security in SQL Server

Chapter 1

Introduction to Security in SQL Server

SQL Server and Security

SQL Server uses a number of security features that enable you to protect sensitive data from inappropriate access and unauthorized disclosure. SQL Server is targeted for security evaluation at the Class C2 level. The requirements for the C2 criteria are given by the Department of Defense in DOD 52.00.28-STD, Department of Defense Trusted Computer System Evaluation Criteria (TCSEC), also known as the "Orange Book."

SQL Server achieves security through a collection of protection mechanisms that enforce a security policy. The administrators of your system determine the local application of the security policy. Your role as a user is to be aware of the security mechanisms that are available to you and to make use of them. The purpose of this manual is to describe these security mechanisms and tell you how to use them effectively. The following sections provide an overview of the major security features provided by SQL Server.

User Identification and Authentication

Every user in SQL Server is given a login account with a unique ID. When you log into SQL Server, you must identify yourself and enter the correct password before you are permitted to access the server. This process is called identification and authentication. All of your activity on the server can be attributed to your server user ID, and your activities can be audited.

Your SQL Server password must be six bytes or longer. It is stored in the master..syslogins table in encrypted form. In addition, when you log into SQL Server from a client, you can choose client-side password encryption to encrypt your password before sending it over the network. Chapter 2, "Logging into SQL Server," describes your SQL Server login account, password management, and how to log into SQL Server.

Discretionary Access Controls

Discretionary access controls are controls that are used at the discretion of object owners. They are "discretionary" because an object owner can choose to allow you to access an object or can disallow such access.

The SQL commands grant and revoke control SQL Server's discretionary access control system. You can give various kinds of permissions to users, groups, and roles with the grant command and rescind them with the revoke command. grant and revoke are used to give users permission to create objects within a database, to create databases, and to access specified tables, views, and columns.

Some commands can be used at any time by any user with no permission required. Others can be used only by users of certain status (for example, only by a System Administrator) and are not transferable.

The ability to assign permissions for the commands that can be granted and revoked is determined by each user's status (as System Administrator, Database Owner, or database object owner) and by whether or not a particular user has been granted a permission with the option to grant that permission to other users.

Discretionary access controls are discussed in Chapter 4, "Granting Permissions on Objects and Commands."

Division of Roles

An important feature in SQL Server is the division of roles. Various security-related, administrative, and operational tasks are grouped into these roles:

System Security Officer, who manages security in SQL Server.
System Administrator, who manages disk storage, server configuration, some aspects of login accounts, backup and recovery of databases, and so forth.
Operator, who can back up and load databases on a server-wide basis.

These roles provide individual accountability for users performing administrative tasks. Their actions can be audited and attributed to them.

SQL Server roles are discussed in Chapter 3, "Roles in SQL Server."

Auditing

A principal element of a secure system is accountability. One means of ensuring this accountability is by auditing events on the system. Many events that occur in SQL Server can be recorded in an audit record. Each audit record can log the nature of the event, the date and time, the user responsible for it, and the success or failure of the event. Among the events that can be audited are logins and logouts, server boots, use of data access commands, attempts to access particular objects, and a particular user's actions. The audit trail, or log of audit records, allows the System Security Officer to reconstruct events that have occurred on the system and evaluate their impact.

Auditing is managed by the System Security Officer, and is discussed in Chapter 8, "Auditing," in the Security Administration Guide.


	Expand Search