SQL Server - Bài5

Securing Databases &
T-SQL for Data Control
Vu Tuyet Trinh

Hanoi University of Technology
1
MicrosoftMicrosoft
Outline

Understanding SQL Server Security Model

Managing logins, users and roles

Managing Permissions

Data Control Language (DCL) and Security Issues

Implementing Security through Database Objects

Other Security Options

Column Level Encryption

Proxy Accounts

Credentials
MicrosoftMicrosoft
SQL Server Security Model
MicrosoftMicrosoft
SQL Server Security Overview


Layered Security Model:

Windows Level

SQL Server Level

Database

Schemas (for database objects)

Terminology:

Principals

Securables

Permissions

Scopes and Inheritance
MicrosoftMicrosoft
Principals
Securable
Permissions
MicrosoftMicrosoft
Principals, Securable and Permissions

Principal

Individuals, groups, and processes that can request SQL Server
resources.


Logins, Users, Roles, etc

Securable

A Securable is a resource that can be secured

Tables, Views, Endpoints, etc

Permission

Permissions grant principals access to securables

Grant a user Execute rights to a Stored Procedure, etc

SQL 2005 introduces new permissions like Control, Alter Any and
Impersonate

Permissions work in hierarchies
MicrosoftMicrosoft
Security Architecture in SQL Server
2000

Authentication

First stage of security

Identifies users based on login information they provide

Only verifies that users can connect to a SQL Server 2000 instance


Does not provide access to databases and their objects

Authorization

Second stage of security

Occurs when database permissions are checked to determine which
actions a particular user can perform within a database
MicrosoftMicrosoft
Outline
√
Understanding the security architecture of SQL Server

Managing logins, users and roles

Managing permissions

Controlling access with database objects and ownership
chains

Auditing SQL Server
MicrosoftMicrosoft
SQL Server Service Accounts

Local Service Account

Permissions of “Users” group (limited)

No network authentication


Network Service Account

Permissions of Users group

Network authentication with Computer account

Domain User Accounts

Adds network access for cross-server functionality
MicrosoftMicrosoft
Creating Logins

Transact-SQL

CREATE LOGIN statement

Replaces sp_AddLogin and sp_GrantLogin

SQL Server Logins

Windows Logins

SQL Server Management Studio

Setting server authentication options

Login Auditing

Managing Logins

MicrosoftMicrosoft
Managing Logins

Windows Logins

Authentication/Policy managed by Windows

SQL Server Logins

Managed by SQL Server

Based on Windows policies

Password Policy Options:

HASHED (pw is already hashed)

MUST_CHANGE

CHECK_EXPIRATION

CHECK_POLICY
MicrosoftMicrosoft
Database Users and Roles

Database Users

Logins map to database users

Database Roles


Users can belong to multiple roles

Guest (does not require a user account)

dbo (Server sysadmin users)

Application Roles

Used to support application code
MicrosoftMicrosoft
Creating Database Users and Roles

CREATE USER

Replaces sp_AddUser and sp_GrantDBAccess

Can specify a default schema

Managed with ALTER USER and DROP USER

CREATE ROLE

Default owner is creator of the role

SQL Server Management Studio

Working with Users and Roles
MicrosoftMicrosoft
Built-In Server / Database Roles

MicrosoftMicrosoft
Configuring Permissions

Scopes of Securables

Server

Database

Schema

Objects

Permission Settings:

GRANT

REVOKE

DENY

Options

WITH GRANT OPTION

AS (Sets permissions using another user or role)
MicrosoftMicrosoft
Managing Execution Permissions

Transact-SQL Code can run under a specific execution context


By default, will execute as the caller

EXECUTE AS clause:

Defined when creating an object or procedure

Options:

CALLER (Default)

SELF: Object creator

Specified database username
MicrosoftMicrosoft
Data Control Language

GRANT

Used to grant access on an object or a statement to a user.

REVOKE

Used to revoke permissions on a database object

DENY
Used to explicitly deny any permission on any object or statement
MicrosoftMicrosoft
GRANT Syntax


GRANT <permission> [ ,...n ] ON [ OBJECT :: ]
[ schema_name ]. object_name [ ( column [
,...n ] ) ] TO <database_principal> [ ,...n ]
[ WITH GRANT OPTION ] [ AS <database_principal> ]
<permission> ::= ALL [ PRIVILEGES ] | permission [
( column [ ,...n ] ) ] <database_principal> ::=
Database_user | Database_role | Application_role |
Database_user_mapped_to_Windows_User |
Database_user_mapped_to_Windows_Group |
Database_user_mapped_to_certificate |
Database_user_mapped_to_asymmetric_key |
Database_user_with_no_login
MicrosoftMicrosoft
REVOKE Syntax

REVOKE [ GRANT OPTION FOR ] <permission> [ ,...n ]
ON [ OBJECT :: ][ schema_name ]. object_name
[ ( column [ ,...n ] ) ] { FROM | TO }
<database_principal> [ ,...n ] [ CASCADE ] [ AS
<database_principal> ] <permission> ::= ALL
[ PRIVILEGES ] | permission [ ( column [ ,...n ] )
] <database_principal> ::= Database_user |
Database_role | Application_role |
Database_user_mapped_to_Windows_User |
Database_user_mapped_to_Windows_Group |
Database_user_mapped_to_certificate |
Database_user_mapped_to_asymmetric_key |
Database_user_with_no_login
MicrosoftMicrosoft
DENY Syntax

MicrosoftMicrosoft
Example
MicrosoftMicrosoft
Implementing Security through
Database Objects

Securing data with views

Views can be defined to provide either a filtered set of table
columns or a limited set of data rows from underlying tables

A common use of a view is to create a special representation of
a table that does not contain certain sensitive information
MicrosoftMicrosoft
Implementing Security through
Database Objects

Securing data with stored procedures and user-defined
functions

Stored procedures and user-defined functions allow sets of T-
SQL statements to be stored and executed as a single unit

They are typically used to enforce business rules or
perform logic
MicrosoftMicrosoft
Implementing Security through
Database Objects

Controlling access with triggers


Triggers are similar to stored procedures in that they contain
saved groups of T-SQL statements

However, triggers are not called directly, so
permissions cannot be granted directly to use them

They are controlled by insert, update and delete
permissions on the table with which they are
defined
MicrosoftMicrosoft
Understanding Ownership Chains

Ownership chains

Hierarchy of
dependent
objects
Figure 8-12: Ownership chain