Hướng dẫn học Microsoft SQL Server 2008 part 123 pot

Database Security Once a user has gained access to the server, access may be granted to the individual user databases.. Granting access using T-SQL code Of course, a stored procedure is

To view the assigned roles using code, query the sysserver_principals catalog view to select the members, joined with the sysserver_role_members , and joined again to the sysserver_principals to select the roles.

Database Security

Once a user has gained access to the server, access may be granted to the individual user databases

Database security is potentially complex

Users are initially granted access to databases by adding them to the database

Guest logins

Any user who wishes to access a database but has not been declared a user within the database will

automatically be granted the user privileges of the guest database user if the guest user account exists

(refer to Figure 49-1)

The guest user is not automatically created when a database is created It must be specifically added in

code or as a database user The guest login does not need to be predefined as a server login:

EXEC sp_adduser ‘Guest’

Be very careful with the guest user While it may be useful to enable a user to access the database without setting him or her up, the permissions granted to the guest user apply to everyone without access to the database.

The guest user must be removed from a database when guests are no longer welcome

Granting access to the database

Users must be explicitly granted access to any user database Because this is a many-to-many

relation-ship between logins and database, you can manage database access from either the login side or the

database side

When a login is granted access to the database, the login is also assigned a database username, which

may be the same as the login name or some other name by which the login will be known within

the database

To grant access to a database from the login side using Object Explorer, use the User Mapping page of

the Login Properties form (shown in Figure 49-6)

Many security settings involve multiple objects such as users and databases or roles and object permissions These settings can be made from either the Login Permissions form or the role’s or object’s Properties page.

To grant access from the database point of view, use the New User Context Menu command under the

Database➪ Security ➪ Users node to open the Database User-New form, shown in Figure 49-7 Enter

the login to be added in the Login Name field To search for a login, use the ellipses ( .) button You

must enter a name by which the user will be known within the database in the User Name field

You can use the Login Properties form to grant a login access to any database and to assign database

roles

Granting access using T-SQL code

Of course, a stored procedure is available to grant database access to a user:CREATE USER The stored

procedure must be issued from within the database to which the user is to be granted access The first

parameter is the server login, and the second is the optional database username:

USE Family

CREATE USER ‘XPS\Lauren’, ‘LRN’

Lauren now appears in the list of database users as ‘‘LRN.’’

To remove Lauren’s database access, the system stored procedureDROP USERrequires her database

username, not her server login name:

FIGURE 49-7

The Login dialog box can be used to add a new user to the database or to manage the current user

To query a database user using T-SQL, select from the sys database_principals catalog view.

Fixed database roles

SQL Server includes a few standard, or fixed, database roles Like the server fixed roles, these primarily

organize administrative tasks A user may belong to multiple roles The fixed database roles include the

following:

■ db_accessadmin: Can authorize a user to access the database, but not manage database-level security

restores (only server sysadmins can perform restores)

■ db_datareader: Can read all the data in the database This role is the equivalent of a grant on

all objects, and it can be overridden by a deny permission

■ db_datawriter: Can write to all the data in the database This role is the equivalent of a grant

on all objects, and it can be overridden by a deny permission

■ db_ddladmin: Can issue DDL commands (create, alter, drop)

■ db_denydatareader: Can read from any table in the database This deny will override any

object-level grant

■ db_denydatawriter: Blocks modifying data in any table in the database This deny will override

any object-level grant

■ db_owner: A special role that has all permissions in the database This role includes all the

capabilities of the other roles It is different from the dbo user role This is not the

database-level equivalent of the server sysadmin role; an object-database-level deny will override membership in

this role

■ db_securityadmin: Can manage database-level security — roles and permissions

Assigning fixed database roles with Management Studio

The fixed database roles can be assigned with Management Studio with either of the following two

procedures:

■ Adding the role to the user in the user’s Database User Properties form (see Figure 49-7),

either as the user is being created or after the user exists

■ Adding the user to the role in the Database Role Properties dialog Select Roles under

the database’s Security node, and use the context menu to open the Properties form (see

Figure 49-8)

Assigning fixed database roles with T-SQL

From code, you can add a user to a fixed database role with thesp_addrolesystem stored procedure

To examine the assigned roles in T-SQL, query the sysdatabase_role_members catalog

view joined with sysdatabase_principal

Application roles

An application role is a database-specific role intended to allow an application to gain access regardless

of the user For example, if a specific Visual Basic program is used to search theCustomertable and it

doesn’t handle user identification, the VB program can access SQL Server using a hard-coded application

role Anyone using the application gains access to the database

Because using an application role forfeits the identity of the user, I strongly advise against

using application roles The user can regain identity context using sp_unsetapprole

FIGURE 49-8

The Database Role Properties dialog lists all users assigned to the current role To add or remove users

from the role, use the Add and Remove buttons, respectively

Summary

In this era of cybercrime, data security is more important than ever Security is integral to the

Informa-tion Architecture Principle While it’s possible to set all the users to sysadmin and ignore security, with

a little effort SQL Server security is functional and flexible enough to meet the needs presented by a

variety of situations

Authorizing Securables

IN THIS CHAPTER

Object ownership Securables permissions Object security Views and security

This chapter adds another important piece to the SQL Server security

puzzle — securables These are objects (for example, tables, views,

stored procedures, columns) that can be secured in order to prevent

unauthorized access

Object Ownership

A very important aspect of SQL Server’s security model involves object ownership

Every object is contained by a schema The default schema is dbo — not to be

confused with the dbo role

Ownership becomes critical when permission is being granted to a user to run a

stored procedure when the user doesn’t have permission to the underlying tables

If the ownership chain from the tables to the stored procedure is consistent, then

the user can access the stored procedure, and the stored procedure can access the

tables as its owner However, if the ownership chain is broken, meaning there’s a

different owner somewhere between the stored procedure and the table, then the

user must have rights to the stored procedure, the underlying tables, and every

other object in between

There is a fine point in the details A schema is owned; and because a schema is

owned, anything that is contained by it has the same owner

Most security management can be performed in Management Studio With code,

security is managed by means of theGRANT,REVOKE, andDENYData Control

Language (DCL) commands and several system stored procedures

Object Security

If a user has access to the database, then permission to the individual database objects may be granted

Permission may be granted either directly to the user or to a standard 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

Standard database roles

Standard database roles, sometimes called user-defined roles, can be created by any user in the server

sysadmin, databasedb_owner, or database security admin role These roles are similar to those in user

groups in Windows Permissions, and other role memberships, can be assigned to a standard database

role, and users can then be assigned to the role

Best Practice

The cleanest SQL Server security plan is to assign object permissions and fixed roles to standard database

roles, and then to assign users to the roles

Object permissions

Several specific types of permissions exist:

■ Select: The right to select data Select permission can be applied to specific columns

■ Insert: The right to insert data

■ Update: The right to modify existing data Update rights for which aWHEREclause is used require select rights as well Update permission can be set on specific columns

■ Delete: The right to delete existing data

■ DRI (References): The right to create foreign keys with DRI

■ Execute: The right to execute stored procedures or user-defined functions Object permissions are assigned with the SQL DCL commands,GRANT,REVOKE, andDENY The

permissions in SQL Server work like they do in the operating system SQL Server aggregates all

the permissions a given user might have, whether directly assigned against the user or through the roles

Then SQL Server gives theMAXIMUMof what has been granted.DENYis an exception.DENYfunctions

as a trump If anywhere aDENYhas been issued, then just like in Windows, the user is blocked For

instance, if a user canSELECTagainst a table directly assigned, but a role the user is a member of

has aDENYforSELECT, then the user is blocked from issuing aSELECTagainst the table Whether

security is being managed from Management Studio or from code, it’s important to understand these

three commands

Granting object permission interacts with the server and database roles Here’s the overall hierarchy of

roles and grants, with 1 overriding 2, and so on:

because it maps to dbo, it ignores all security on the database.

2 Deny object permission or the db_denydatareader database role or the db_denydatawriter

database role

3 Grant object permission or object ownership or the db_datareader database role or the

db_datawriter database role

Best Practice

An easy way to test security is to configure the server for mixed mode and create a SQL Server Login test

user Using Management Studio, it’s easy to create additional connections as different users — much

easier than it is to change the server registration and log into Management Studio as someone else

Since SQL Server 2005 it has been possible to create a database principal that does not map to a server

principal using the CREATE USER command and specifying WITHOUT LOGIN Then, using EXECUTE AS

USER = ‘<username>’to switch security contexts, the security can be tested REVERT, of course, switches

the context back

If your environment prohibits mixed-mode security, then the easiest way to check security is to

right-click Management Studio or Query Analyzer and use theRUN AScommand to run as a different user,

but this entails creating dummy users in the Windows domain Generally speaking, in a ‘‘production’’

Windows domain, most auditors would flag dummy users as an audit point Since workstations

belonging to DBAs tend to belong in production domains, this recommendation wouldn’t work where

the auditors are being diligent

Granting object permissions with code

Setting an object’s permission is the only security command that can be executed without a system

stored procedure being called:

GRANT Permission, Permission

ON Object

TO User/role, User/role

WITH GRANT OPTION

The permissions may beALL,SELECT,INSERT,DELETE,REFERENCES,UPDATE, orEXECUTE The

role or username refers to the database username, any user-defined public role, or the public role For

example, the following code grants select permission to Joe for thePersontable:

GRANT Select ON Person TO Joe

The next example grants all permissions to the public role for theMarriagetable:

GRANT All ON Marriage TO dbcreator

Multiple users or roles, and multiple permissions, may be listed in the command The following code

grants select and update permission to the guest user and to LRN:

GRANT Select, Update ON Person to Developer, LRN TheWITH GRANToption provides the ability to grant permission for the object For example, the

following command grants Joe the permission to select from thePersontable and grant select

permission to others:

GRANT Select ON Person TO Joe WITH GRANT OPTION

Revoking and denying object permission with code

Revoking and denying object permissions uses essentially the same syntax as granting permission The

following statement revokes select permissions from Joe on theMarriagetable:

REVOKE All ON Marriage TO Joe

If the permission included theWITH GRANT OPTION, then the permission must be revoked or denied

with theCASCADEoption so that theWITH GRANT OPTIONwill be removed The following command

denies select permissions to Joe on thePersontable:

DENY Select ON Person TO Joe CASCADE Because usingCASCADEwill revoke not only theWITH GRANT OPTIONpermission, the DBA can get rid

of the ability toGRANTbut must first get rid of the permission, includingWITH GRANT OPTION, and

then re-GRANTthe original permission, but this time without specifyingWITH GRANT OPTION

The public role

The public role is a fixed role, but it can have object permissions like a standard role Every user

is automatically a member of the public role and cannot be removed, so the public role serves as a

baseline or minimum permission level

Be careful when applying permissions to the public role because it will affect everyone except members of the sysadmin role Granting access will affect everyone; more impor-tant, denying access will block all users except members of the sysadmin role, even object owners, from

accessing data.

Managing roles with code

Creating standard roles with code involves using thesp_addrolesystem stored procedure The name

can be up to 128 characters and cannot include a backslash, be null, or be an empty string By default,

the roles will be owned by the dbo user However, you can assign the role an owner by adding a second

parameter The following code creates the manager role:

CREATE ROLE ‘Manager’

New role added.

The counterpart of creating a role is removing it A role may not be dropped if any users are currently

assigned to it Thesp_droprolesystem stored procedure will remove the role from the database:

DROP ROLE ‘Manager’

Result:

Role dropped

Once a role has been created, users may be assigned to the role by means of thesp_addrolemember

system stored procedure The following code sample assigns Joe to the manager role:

EXEC sp_addrolemember ‘Manager’, Joe

Result:

’Joe’ added to role ‘Manager’

Not surprisingly, the system stored proceduresp_droprolememberremoves a user from an assigned

role This code frees Joe from the drudgery of management:

EXEC sp_dropRoleMember ‘Manager’, Joe

Result:

’Joe’ dropped from role ‘Manager’

Hierarchical role structures

If the security structure is complex, then a powerful permission-organization technique is to design a

hierarchical structure of standard database roles In other words, you can nest user-defined database

roles

■ The worker role may have limited access

■ The manager role may have all worker rights plus additional rights to look up tables

■ The administrator role may have all manager rights plus the right to perform other database

administration tasks

To accomplish this type of design, follow these steps:

1 Create the worker role and set its permissions.

2 Create the manager role and set its permissions Add the manager role as a user to the worker

role

3 Create the admin role Add the admin role as a user to the manager role.

The advantage of this type of security organization is that a change in the lower level affects all upper