Hướng dẫn học Microsoft SQL Server 2008 part 122 pdf

SQL Server users don’t need access to the database directories or data files on a Windows level because the SQL Server process, not the user, performs the actual file access.. SQL Server

Windows Security

Because SQL Server exists within a Windows environment, one aspect of the security strategy must be

securing the Windows server

Using Windows Security

SQL Server databases frequently support websites, so Internet Information Server (IIS) security and

firewalls must be considered within the security plan

Windows security is an entire topic in itself, and therefore outside the scope of this book If, as a DBA,

you are not well supported by qualified network staff, then you should make the effort to become

profi-cient in Windows Server technologies, especially security

SQL Server login

Don’t confuse user access to SQL Server with SQL Server’s Windows accounts The two logins are

completely different

SQL Server users don’t need access to the database directories or data files on a Windows level because

the SQL Server process, not the user, performs the actual file access However, the SQL Server process

needs permission to access the files, so it needs a Windows account Three types are available:

■ Local user account: If network access is not required, this is a viable option Local user accounts cannot be used outside the server

■ Local system account: SQL Server can use the local system account of the operating system for permission to the machine This option is adequate for single-server installations, but fails

to provide the network security required for distributed processing The local system account has more rights than even a member of the Administrators account because the local system account has implicit privileges in the operating system and Active Directory that go beyond membership in the Administrators group

■ Domain user account (recommended): SQL Server can use a Windows user account created specifically for it The SQL Server domain user account can be granted administrator rights for the server and can access the network through the server to talk to other servers

The SQL Server accounts were initially configured when the server was installed Installa-tion is discussed in Chapter 4, ‘‘Installing SQL Server 2008.’’

Server Security

SQL Server uses a two-phase security-authentication scheme The user is first authenticated to the server

Once the user is ‘‘in’’ the server, access can be granted to the individual databases

SQL Server stores all login information within themasterdatabase

SQL Server authentication mode

When SQL Server was installed, one of the decisions made was which of the following authentication

methods to use:

■ Windows Authentication mode: Windows authentication only

■ Mixed mode: Both Windows authentication and SQL Server user authentication

This option can be changed after installation in Management Studio, in the Security page of the SQL

Server Properties dialog, as shown in Figure 49-2

FIGURE 49-2

Server-level security is managed in the Security tab of the SQL Server Properties dialog

From code, the authentication mode can be checked by means of thexp_loginconfigsystem stored

procedure, as follows:

EXEC xp_loginconfig ‘login mode’

Result:

- -login mode Mixed

Notice that the system stored procedure to report the authentication mode is an extended stored

proce-dure That’s because the authentication mode is stored in the registry in the following entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\

MicrosoftSQLServer\<instance_name>\MSSQLServer\LoginMode

ALoginModevalue of1is for Windows authentication;0is for mixed mode The only ways to set the

authentication mode are to use either Management Studio or RegEdit

Windows Authentication

Windows Authentication mode is superior to mixed mode because users don’t need to learn yet another

password and because it leverages the security design of the network

Using Windows Authentication means that users must exist as Windows users in order to be recognized

by SQL Server The Windows SID (security identifier) is passed from Windows to SQL Server

Windows Authentication is very robust in that it will authenticate not only Windows users, but also

users within Windows user groups

When a Windows user group is accepted as a SQL Server login, any Windows user who is a member

of the group can be authenticated by SQL Server Access, roles, and permissions can be assigned for the

Windows user group, and they will apply to any Windows user in the group

Best Practice

If the Windows users are already organized into groups by function and security level, using those groups

as SQL Server users provides consistency and reduces administrative overhead

SQL Server also knows the actual Windows username, so the application can gather audit information at

both the user level and the group level

Adding a new Windows login

Windows users are created and managed in various places in the different Windows versions In

Windows Vista, local users can be managed by selecting Control Panel➪ Administrative Tools ➪

Computer Management, as shown in Figure 49-3 Domain users are managed with tools such as the

Active Directory Users and Computers snap-in

Once the users exist in the Windows user list or the Windows domain, SQL Server can recognize them.

To add a new login to SQL Server using Object Explorer, follow these steps:

1 Open the Security➪ Logins node under the server and use the context menu to select New

Login

2 In the General page of the Login-New dialog (see Figure 49-4), use the Search button to locate

the Windows user

3 You may enter a username or group name or use the Advanced button to search for a user.

FIGURE 49-3

Windows users are managed and assigned to Windows groups by means of the Computer Management

tool

The user may be assigned a default database and language at the bottom of the SQL Server Login

Prop-erties dialog Note that assigning a default database does not automatically grant access to that database

The user may be granted access to databases in the Database Access tab (Database access is discussed

in the next section.)

To use T-SQL code to add a Windows user or group, run theCREATE LOGINcommand Be sure to use

the full Windows username, including the domain name, as follows:

CREATE LOGIN ‘XPS\Joe’

To view Windows logins using code, query the sysserver_principals catalog view.

FIGURE 49-4

Use the General page of the Login-New dialog to create and edit user logins at the server level

The Login-New dialog is also used to manage existing users To open the Login Permission version

of the dialog for an existing user, select the user under the Security➪ Logins node and use the context

menu’s Properties command or double-click the user

Removing a Windows login

Removing a windows login from SQL Server is simple enough with Management Studio Select the login

in Object Browser and use the context menu to delete the user Of course, this doesn’t delete the user

from Windows; it only removes the user from SQL Server

To remove a Windows user or group from SQL Server, use theDROP LOGINcommand The Windows

user or group will exist in Windows; it just won’t be recognized by SQL Server:

DROP LOGIN ‘XPS\Joe’

Denying a Windows login

Using the paradigm of grant, revoke, and deny, a user may be blocked for access usingALTER LOGIN

for Windows users andDENY CONNECTfor Windows groups This can prevent users or groups from

accessing SQL Server even if they could otherwise gain entry from another method

For example, suppose the Accounting group is granted normal login access, while the Probation group

is denied access Joe is a member of both the Accounting group and the Probation group The Probation

group’s denied access blocks Joe from the SQL Server even though he is granted access as a member of

the Accounting group, because deny overrides grant

To deny a Windows user or group, use theDENY CONNECTcommand If the user or group being

denied access doesn’t exist in SQL Server, thenDENY CONNECTadds and then denies him, her, or it:

DENY CONNECT ‘XPS\Joe’

To restore the login after denying access, you must first grant access with thesp_grantloginsystem

stored procedure

You can deny the ability to log in using T-SQL

Setting the default database

The default database is set in the Login Properties form in the General page The default database can be

set from code by means of theALTER LOGINcommand:

ALTER LOGIN ‘Sam’, ‘OBXKites’

Orphaned Windows users

When a Windows user is added to SQL Server and then removed from the Windows domain, the user

still exists in SQL Server but is considered orphaned Being an orphaned user means that although SQL

Server still has the Windows account listed within SQL Server, it doesn’t exist any longer in the domain;

therefore, no access is provided as a result Even if the Windows account is recreated, it will have a new

SID and GUID, and therefore won’t match up

Thesp_validateloginssystem stored procedure locates all orphaned users and returns their

Windows NT security identifiers and login names In the following code example, Joe was granted

access to SQL Server and then removed from Windows:

EXEC sp_validatelogins

Result (formatted):

-

-0x010500000000000515000000FCE31531A931 XPS\Joe

This is not a security hole Without a Windows login with a matching SID, the user can’t log into SQL

Server

To resolve the orphaned user:

1 Remove the user from any database access usingDROP LOGIN

2 Revoke the user’s server access usingsp_revokelogin

Security delegation

In an enterprise network with multiple servers and IIS, logins can become a problem because a user

may be logging into one server that is accessing another server This problem arises because each server

must have a trust relationship with the others For internal company servers, this may not be an issue,

but when one of those servers sits in a DMZ on the Internet, you may not want to establish that trust,

as it presents a security hole

Security delegation is a Windows feature that uses Kerberos to pass security information among trusted

servers For example, a user can access IIS, which can access a SQL Server, and the SQL Server will see

the user as the username even though the connection came from IIS

A few conditions must be met in order for Kerberos to work:

■ All servers must be running Windows 2000 or later, running Active Directory in the same domain or within the same trust tree

■ The ‘‘Account is sensitive and cannot be delegated’’ option must not be selected for the user account

■ The ‘‘Account is trusted for delegation’’ option must be selected for the SQL Server service account

■ The ‘‘Computer is trusted for delegation’’ option must be selected for the server running SQL Server

■ SQL Server must have a Service Principal Name (SPN), created bysetspn.exe, available in the Windows 2000 Resource Kit

Security delegation is difficult to set up and may require the assistance of your network domain

adminis-trator However, the ability to recognize users going through IIS is a powerful security feature Executing

SETSPN to add or delete an SPN does require domain admin rights

SPN is a powerful security feature, but it does weaken security because the user is being impersonated

Therefore, its use should generally be restricted to those cases where it’s absolutely necessary

Uncon-strained delegation should be avoided at all costs

SQL Server logins

The optional SQL Server logins are useful when Windows authentication is inappropriate or

unavail-able It’s provided for backward compatibility and for legacy applications that are hard-coded to a SQL

Server login

Best Practice

Implementing SQL Server logins (mixed mode) will automatically create an sa user, who will be a member

of the sysadmin fixed server role and have all rights to the server An sa user without a password is very

common and the first attack every hacker tries when detecting a SQL Server Therefore, the best practice is

to disable the sa user and assign different users, or roles, to the sysadmin fixed server role instead

To manage SQL Server users in Management Studio, use the same Login-New dialog used when adding

Windows users, but select SQL Server Authentication

In T-SQL code, use theCREATE LOGINcommand Because this requires setting up a user, rather than

just selecting one that already exists, it’s more complex than adding asp_grantlogin Only the login

name is required:

CREATE LOGIN ‘login’, ‘password’, ‘defaultdatabase’,

‘defaultlanguage’, ‘sid’, ‘encryption_option’

For example, the following code adds Joe as a SQL Server user and sets his default database to the

OBXKitessample database:

EXEC sp_addlogin ‘Sam’, ‘myoldpassword’, ‘OBXKites’

The encryption option (skip_encryption) directs SQL Server to store the password without any

encryption in thesysxlgnssystem table This option tells SQL Server that the value being passed is

already encrypted, so the password won’t work Avoid this option

The server user ID, or SID, is an 85-bit binary value that SQL Server uses to identify the user If the

user is being set up on two servers as the same user, then the SIDs need to be specified for the second

server Query thesys.server_principalscatalog view to find the user’s SID:

SELECT Name, SID

FROM sys.server_principals

WHERE Name = ‘Sam’

Result:

-

-Sam 0x1EFDC478DEB52045B52D241B33B2CD7E

Updating a password

The password can be modified by means of theALTER LOGINcommand:

ALTER LOGIN ‘myoldpassword’, ‘mynewpassword’, ‘Joe’

If the password is empty, use the keywordNULLinstead of empty quotes (‘ ’)

Removing a login

To remove a SQL Server login, use theDROP LOGINcommand:

DROP LOGIN ‘Joe’

Removing a login also removes all the login security settings

Setting the default database

The default database is set in the Login Properties form in the General page, just as it is for Windows

users The default database can be set from code by means of theALTER LOGINcommand:

ALTER LOGIN ‘Sam’, ‘OBXKites’

Server roles

SQL Server includes only fixed, predefined server roles Primarily, these roles grant permission to

perform certain server-related administrative tasks A user may belong to multiple roles

The following roles are best used to delegate certain server administrative tasks:

■ Bulkadmin: Can perform bulk insert operations

■ Dbcreator: Can create, alter, drop, and restore databases

■ Diskadmin: Can create, alter, and drop disk files

■ Processadmin: Can kill a running SQL Server process

■ Securityadmin: Can manage the logins for the server

■ Serveradmin: Can configure the serverwide settings, including setting up full-text searches and shutting down the server

■ Setupadmin: Can configure linked servers, extended stored procedures, and the startup stored procedure

■ Sysadmin: Can perform any activity in the SQL Server installation, regardless of any other permission setting The sysadmin role even overrides denied permissions on an object

SQL Server automatically creates a user, BUILTINS/Administrators, that includes all Windows users in

the Windows Admins group and allows a choice of what groups or users are added during setup The

BUILTINS/Administrators user can be deleted or modified if desired

If the SQL Server is configured for mixed-mode security, it also configures the sa account to be disabled

The sa user is there for backward compatibility

Best Practice

Disable or rename the sa user, or at least assign it a password, but don’t use it as a developer and DBA

sign-on In addition, delete the BUILTINS/Administrators user Instead, use Windows authentication

and assign the DBAs and database developers to the sysadmin role

A user must reconnect for the full capabilities of the sysadmin role to take effect

The server roles are set in Management Studio in the Server Roles page of the Login Properties dialog

(see Figure 49-5)

FIGURE 49-5

The Server Roles page is used to assign server administrative rights to users Here, the Windows

Admin group is granted the sysadmin role

In code, a user is assigned to a server role by means of a system stored procedure:

sp_addsrvrolemember

[ @loginame = ] ‘login’,

[ @rolename = ] ‘role’

For example, the following code adds the login ‘‘XPS\Lauren’’ to the sysadmin role:

EXEC sp_addsrvrolemember ‘XPS\Lauren’, ‘sysadmin’

The counterpart ofsp_addsrvrolemember,sp_dropsrvrolemember, removes a login from a

server fixed role:

EXEC sp_dropsrvrolemember ‘XPS\Lauren’, ‘sysadmin’