Part III

SQL Server Security Model

Objectives
 Security Hierarchy
 Implementing Instance-Level Security
o Server Roles
o Logins
o Granting Permissions
 Implementing Database-Level Security
o Schemas
o Creating and Managing Contained Users
o Implementing Object-Level Security
 Permissions Naming Conventions
 Authorization discussion
Security Hierarchy
Security hierarchy : begins at the Windows domain
level and cascades down through the local server.
Model is based on the concept of principals,
securables, and permissions.
Principals are entities to which permissions are
granted, denied, or revoked.
Securables are objects that can have permissions
granted on them.
Permissions are permissions on securable, be
granted to a principal.
Local server accounts
or domain accounts
and groups can be
mapped to a user at the
database level (without
login)

Login of SQL Server

instance, can be
mapped to local
Windows user or
group or to domain
user or group

Map logins to database

users
Implementing Instance-Level Security
All users must be authenticated at the instance
level.
Use two authentication modes :
• Windows authentication
o Login at the instance level is created and mapped
to a Windows user or group
 Records the SID (security identifier) of this principal
and stores it in the Master database
o Can also map a login to a certificate or an
asymmetric key
• mixed-mode authentication
create a SQL login (has username and password),
stored in the Master database with its own SID.
Implementing Instance-Level Security
Using mixed-mode authentication, there will be a
special user, called the SA
• System Administrator account
• Has administrative rights to the entire instance.

Rename the SA account by using the command :

ALTER LOGIN sa WITH NAME = SAAdmin ;

Server Roles
Fixed server roles is set of server roles, allowing
to assign instance-level permissions.
Server Roles
Server Roles
You can also create own server roles,grouping
users to need a common set of permissions.
Logins
Login is a security principal at scope of the SQL
Server instance.
Create a login through SSMS or through T-SQL
Granting Permissions
When assigning permissions to logins, you can use
the following actions.
GRANT : gives principal permissions on a
securable.
use WITH option with GRANT to also provide a principal
with the ability to assign the same permission to other
principals.
DENY : denies login permissions on a securable;
DENY overrules GRANT.
REVOKE : removes a permission association to a
securable
Granting Permissions
 Granting and Denying Permissions :
GRANT ALTER ANY LOGIN TO Danielle ;
GO
DENY ALTER ON LOGIN::[NT
Service\MSSQL$PROSQLADMIN] TO Danielle ;

 add or remove logins from a server role

--Add Danielle to the sysadmin Role
ALTER SERVER ROLE sysadmin ADD MEMBER Danielle ;
--Remove Danielle from the sysadmin role
ALTER SERVER ROLE sysadmin DROP MEMBER Danielle ;
Implementing Database-Level Security
Security at the level of the individual database
include database users and database roles.

Database Roles - group principals together to

assign common permissions.
• There are built-in database roles.
• It is also possible to define your own.
Implementing Database-Level Security
Implementing Database-Level Security
Create your own database roles in SQL Server
Management Studio.

Create database role is to use the T-SQL script

Schemas
Schemas - logical namespace for database objects
while at the same time abstracting an object from
its owner.
o simplifies changing the ownership of database
objects
o simplify the management of permissions
o well-designed schemas group tables by business
rules
Schemas
three schemas, which
are split by business
responsibility—Sales,
Procurement, and
Accounts.
Schemas
Schemas
Creating and Managing Contained Users
Create a database user, which does not map to a
server principal, supporting a technology called
contained databases.
• reduce a database’s dependency on the instance
by isolating aspects such as security.
• makes the database easier to move between
instances
• support technologies such as AlwaysOn
Availability Groups
Creating and Managing Contained Users
SQL Server supports the database containment
levels
NONE - default
PARTIAL
o supports contained database users
o metadata is stored inside the database using the
same collation
o database can still interact with no-contained features
Creating and Managing Contained Users
In order to use contained databases, enabling at both
instance (Server Properties) and database level (Database
Properties).
Enable at the instance level :
Creating and Managing Contained Users
Some applications may require that a user have
permissions to multiple databases.
Database user is using second tier authentication :
duplicate SID of the user from the first database.
Implementing Object-Level Security
Many permissions can be granted and not all
permissions are relevant to each object.
When granting permissions on a table, it is
possible to grant permissions to specific
columns, as opposed to the table itself.
Permissions Naming Conventions
CONTROL - ownership-like capabilities on
grantee. Grantee effectively has all defined
permissions on the securable.
ALTER - ability to change the properties, except
ownership , of a particular securable (alter, create,
or drop)
ALTER ANY - ability to create, alter, or drop
individual instances of Server or Database
Securable.
TAKE OWNERSHIP - Enables the grantee to take
ownership of the securable on which it is granted.
Permissions Naming Conventions
IMPERSONATE - Enables grantee to impersonate
login.
CREATE - ability to create Securable.
VIEW DEFINITION - Enables the grantee to access
metadata.
REFERENCES - create a FOREIGN KEY constraint
Authorization discussion