Overview of Security Administration

All security implementations work with essentially two types of entities. One type, the trustee, represents the users of the data as well as the applications that these users run. The other type, the database object, represents the data in the data source object. Database objects encapsulate objects, tables, views, and so on.

A trustee can be a user account, group account, or role, and are defined as follows:

User accounts include accounts that either human users or programs, such as Win32® services, use to log on to a workstation. A user account usually represents a single person, although it is possible for more than one person to use the same user account. Individual users can be members of any number of groups or roles.
Group accounts contain user accounts and other group accounts. They cannot be used to log on to a workstation but are useful when allowing or denying access rights to several user accounts at once.
Roles, like groups, also contain user and group accounts. However, while groups are hierarchical in design, roles can describe common functions either across or within hierarchical organizations. Therefore, roles are useful for specifying access rights across organizational boundaries.

Database objects are discrete entities that contain and expose data within the data store. Database objects can include tables, views, columns, stored procedures, forms, modules, queries, reports, object containers, schemas, and so on. Some providers might have the option of working with database object types rather than with specific objects. For example, the data source object might allow a provider to set access control properties for tables in general rather than requiring identification of a particular table.

Administering the security of the data source object consists of the following parts:

Authorization control permits or denies trustees access to specific database objects within the data source object.
Authentication verifies that a trustee is the actual trustee that the security administrator expects.
Privacy prevents unauthorized users from seeing communications between an authorized user and the data source object.

The three parts are independent of one another, but as a group, they determine the overall security of the data in the data source object. Each part can be implemented at a different security level than the others. For example, you could choose a strong implementation of authentication and a weak implementation of privacy. Such an approach would prevent unauthorized users from initializing the data source object, but it might allow sensitive data to be sent openly across a network, viewable by anyone with the right tools. Therefore, for the best security, you should choose implementations of each part that match the strength of the other parts. The security of the whole data source object is only as strong as the weakest of the security parts.

There are several ways to implement each of these areas of security administration. The following sections examine some of the available options for each part: