Scribd
Upload
18 views3 pages

Authorizing Users To Access Resources

The document outlines the process of authorizing users to access resources in SQL Server, detailing commands like GRANT, REVOKE, and DENY for managing permissions on securables. It explains the concepts of principals, securables, and ownership chains, as well as the benefits of user-schema separation for improved security and simplified permission management. Additionally, it covers column-level security and the importance of object name resolution in SQL queries.

Uploaded by

ekwebanoon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
18 views3 pages

Authorizing Users To Access Resources

The document outlines the process of authorizing users to access resources in SQL Server, detailing commands like GRANT, REVOKE, and DENY for managing permissions on securables. It explains the concepts of principals, securables, and ownership chains, as well as the benefits of user-schema separation for improved security and simplified permission management. Additionally, it covers column-level security and the importance of object name resolution in SQL queries.

Uploaded by

ekwebanoon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Module 03 - Authorizing Users to Access Resources

runas /user:adventureworks\anthonyfrizzell /noprofile sqlcmd


USE InternetSales;
GO

GRANT INSERT, UPDATE ON SCHEMA::Sales TO InternetSales_Managers;


GRANT SELECT ON Schema::Sales TO InternetSales_Managers;
GRANT SELECT ON Schema::Sales TO InternetSales_Users;
GO

DENY SELECT ON Customers.Customer TO Database_Managers;


GO

REVOKE SELECT ON Customers.Customer TO Database_Managers;


GO

SELECT HAS_PERMS_BY_NAME varying the parameters for the 6 combinations: 2 Sales


tables, 3 Permission types.

What Are Principals?


Principals are entities that can request SQL Server resources. They represent
users, groups, or processes that can be granted access to SQL Server resources.
Principals can be categorized into several types:

SQL Server Logins: These are used to authenticate users to SQL Server.

Windows Logins: Integrated security with Windows.


SQL Server Logins: SQL Server authentication.
Database Users: Mapped to logins and represent users within a specific database.
Application Roles: Allow applications to run with their own, user-independent
permissions.
Server Roles: Predefined roles at the server level with specific permissions (e.g.,
sysadmin, serveradmin).
Database Roles: Predefined or custom roles at the database level (e.g., db_owner,
db_datareader).
=============================================

What Are Securables?


Securables are the resources within SQL Server to which the SQL Server Database
Engine regulates access. These resources can include:

Servers: The entire SQL Server instance.


Databases: Individual databases within a server instance.
Objects: Specific objects within databases like tables, views, stored procedures,
etc.
==============================================

GRANT, REVOKE, DENY


These are the primary commands used to control permissions on securables for
principals.

GRANT: Allows a principal to perform a specific action on a securable.


REVOKE: Removes a previously granted or denied permission from a principal.
DENY: Prevents a principal from performing a specific action on a securable,
overriding any granted permissions.

==============================================
Securing Tables and Views
You can control access to tables and views by using the GRANT, REVOKE, and DENY
statements.

Rows ------------------ Columns |||||

Column-Level Security
Column-level security allows you to control access to specific columns within a
table.

WITH GRANT Option


The WITH GRANT option allows a principal to grant a specified permission to other
principals.
Example:
GRANT SELECT ON dbo.YourTable TO YourUser WITH GRANT OPTION;
===============================================
**********
The REVOKE statement can be used to remove granted permissions, and the DENY
statement can be used to prevent a principal from gaining a specific permission
through a GRANT.

Granting a permission removes DENY or REVOKE of that permission on the specified


securable. If the same permission is denied at a higher scope that contains the
securable, the DENY takes precedence. However, revoking the granted permission at a
higher scope does not take precedence.

Caution ******

A table-level DENY does not take precedence over a column-level GRANT. This
inconsistency in the permissions hierarchy has been preserved for backward
compatibility. It will be removed in a future release.
=============================================
Securing Managed Code
Managed code in SQL Server, such as CLR (Common Language Runtime) assemblies, also
needs to be secured.

==========================================
Stored procedures are a fundamental component of SQL Server and many other
relational database management systems (RDBMS). They are a set of SQL statements
that are stored and executed on the database server. Stored procedures offer
several benefits, such as performance improvements, code reuse, and enhanced
security.

==========================================
Managing Ownership Chains
Ownership chains affect the way permissions are checked during the execution of SQL
Server objects that reference other objects.

Ownership Chain Basics


Unbroken Ownership Chain: If all referenced objects have the same owner, SQL Server
checks permissions only on the first object in the chain.
Broken Ownership Chain: If any referenced object has a different owner, SQL Server
checks permissions on each object in the chain.
========================================
Overview of User-Schema Separation
User-Schema Separation in SQL Server is a feature that allows database objects to
be owned by schemas rather than individual users. This provides several benefits,
including improved security, simplified permission management, and better
organization of database objects.
Key Concepts

User: Represents a database principal that can own and access database objects.
Schema: A container that holds database objects such as tables, views, procedures,
and functions. Schemas provide a way to group and manage objects independently of
the users who own them.
Object: An entity within a database, such as a table, view, procedure, or function.

Benefits
Improved Security: Schemas allow for more granular control over permissions,
enabling administrators to manage access to groups of objects rather than
individual objects.

Simplified Permission Management: Permissions can be granted at the schema level,


reducing the need to manage permissions on individual objects.

Organizational Clarity: Schemas help organize database objects logically, making it


easier to manage large databases.

Object Name Resolution


Object name resolution is the process SQL Server uses to find and reference
database objects when their names are specified in SQL queries. The process
involves several steps:

Qualified Object Names: When an object is referenced with a fully qualified name
(e.g., Database.Schema.Object), SQL Server directly resolves the object.
Default Schema: If the object name is not fully qualified, SQL Server first looks
for the object in the default schema of the user executing the query.
dbo Schema: If the object is not found in the user’s default schema, SQL Server
looks for the object in the dbo schema.

Example of Name Resolution


Assuming a user john with a default schema Sales and the following objects:

Sales.Orders (a table in the Sales schema)


dbo.Orders (a table in the dbo schema)

When john executes SELECT * FROM Orders, SQL Server will:

Look for Sales.Orders (since Sales is john's default schema).


If Sales.Orders does not exist, look for dbo.Orders.

Granting Permissions at Schema Level


Granting permissions at the schema level allows you to apply permissions to all
objects within a schema, simplifying permission management.

You might also like