Database Security

CT069-3-3-DBS (VE1.0)

Topic 4
Permission Management – Part 1
 Learning
Outcomes

At the end of this topic, you should be able to:

• Explain what is permission managements and its

importance
• Identify the roles and permission management
requirements
• Perform user access control configurations according
to security requirements in a DBMS

Module Code & Module Title Slide Title SLIDE 2

 Permission Management

• Permission management refers to the process of granting or

revoking privileges to users or roles to perform specific actions
on database objects.
• Refer to methods and mechanisms used to restrict access to a
database system and its data.
• It ensures that only authorized users can access, modify, or
manipulate data within the database, thereby maintaining data
integrity and security.
• Also known as access control or user management

Module Code & Module Title Slide Title SLIDE 3

 Importance of permission management in database security

• Prevent unauthorized access: By assigning appropriate permissions, organizations

can prevent unauthorized users from accessing sensitive data, reducing the risk of
data breaches.
• Ensuring data integrity: Limiting access to certain operations ensures that only
authorized individuals can modify or delete data, preserving its integrity.
• Compliance to regulatory requirements: Many regulatory standards such as GDPR,
HIPAA, and PCI DSS mandate strict access control measures. Effective permission
management helps organizations comply with these requirements.
• Accountability: By assigning permissions based on roles and responsibilities,
organizations can track and audit user activities, holding individuals accountable for
their actions.

Module Code & Module Title Slide Title SLIDE 4

 Types of DB Users
Naïve
Users

Interacts through custom

developed applications
Sophisticated
users
Interacts thru DBMS
UI and query (DML)
Interacts thru DBMS UI
Database
and query (DDL, DCL,
DBAs DML), PowerShell

Interacts thru DBMS

UI and query, API

Developers

Module Code & Module Title Slide Title SLIDE 5

 Security Methods

People
• Individuals who have been granted privileges and permissions to
access applications, networks, servers, databases, data files and
data.
How to Secure
• Establishment of security policies/procedures
• Physical limits on access to HW and documents
• Training on the importance of security and how to protect
information assets
• Authentication & Authorization of Users

Module Code & Module Title Slide Title SLIDE 6

 Authentication vs Authorization

• Authentication: A mechanism (typically login) that

determines whether a user is who he or she claims
to be.

• Authorization: The granting of a right or privilege

that enables a user to have legitimate access to a
system or a system’s object.

Module Code & Module Title Slide Title SLIDE 7

 Authentication vs Authorization

Authentication Authorization

Determines whether users are who they claim to be. If Determines which objects users can and cannot
account exists, the user is allowed to connect. access and manipulate. 4 levels of access – View,
Add, Update and Delete.
Implemented using several types/techniques – single Implemented through policies and rules - by
factor (password) , 2FA, SSO, MFA - Challenges the configuring id, object that the id can access and
user to validate credentials (for example, through actions that the id can perform on the action
passwords, answers to security questions, or facial
recognition)

Usually done before authorization Usually done after successful authentication

Example: We need to log into APSpace and Moodle to Example: After successful login into APSpace or
access the services and resources provided through Moodle, we are shown the pages or resources based
these applications on our role either as a student, lecturer or
administrator etc.

Module Code & Module Title Slide Title SLIDE 8

 SQL Server Login: Authentication

• To allow a user to authenticate and connect to SQL

server, we need to create a SQL Login for that person
• SQL Login is at server level, so it is sufficient to create
only one SQL login for each user

Create Login <login name>

With Password = 'QwErTy12345!@#$%'

Module Code & Module Title Slide Title SLIDE 9

 SQL DB User : Authorization

• To enable a SQL Login to access a specific database (in other

words to grant authorization to a SQL login), we need to
– Create a SQL User in that database for that SQL Login
– And perform some additional statements to grant access
accordingly

Use <database name>

Create User <user name> For Login <login name>
Go

Module Code & Module Title Slide Title SLIDE 10

 Create SQL User Without Login

Besides the common way of creating SQL Login and then SQL user,
we can also cut short the steps by creating only the SQL user without
creating the SQL Login. This is usually done for testing purposes.

DB User Without Login

Use <database name>

Create User <user name> Without Login
Go

Module Code & Module Title Slide Title SLIDE 11

 Roles Based Access Control (RBAC)
• Typically, users are be grouped together based on their roles in an organization
• Role-based access control (RBAC) is a method of managing permission by way of
restricting database access based on the roles of individual users within an
organization.
• RBAC supports security principles: Least Privilege and Separation of Duty and
Privilege.
• Similar to user accounts, roles must also be created and granted permission.
However, you cannot login using a Role. It is a just a grouping name.

Module Code & Module Title Slide Title SLIDE 12

 RBAC Benefits

• Simplicity: RBAC simplifies access control management by organizing

permissions into roles, making it easier to assign and revoke access rights as
users' roles change.
• Scalability: RBAC scales well with large organizations, as permissions are
managed at the role level rather than the individual user level.
• Granularity: RBAC allows for fine-grained control over access permissions, as
roles can be tailored to specific job functions or responsibilities.
• Security: RBAC enhances security by reducing the risk of unauthorized access
and ensuring that users only have access to the resources they need to perform
their job duties.
• Efficiency: The chances of roles and their respective permissions changing is
much lesser than possible changes in new users coming into an organization.

Module Code & Module Title Slide Title SLIDE 13

 RBAC in MS SQL Server

• MS SQL Server support 3 types of Roles:

– Fixed Server Roles
– Fixed Database Roles
– User-Defined Roles

• Fixed Server and Database Roles are pre-defined

• User-Defined Roles can be defined by Users, then assign access

rights to portion of the database

Module Code & Module Title Slide Title SLIDE 14

 Some of the Server Roles in MS-SQL

Role name Description

sysadmin Can perform any activity in the server

securityadmin Can manage logins and their properties.
processadmin Can end processes that are running in an instance of SQL Server.
Members of the dbcreator fixed server role can create, alter, drop, and
dbcreator
restore any database.
Every SQL Server login belongs to the public server role. When a server
principal hasn't been granted or denied specific permissions on a
securable object, the user inherits the permissions granted to public on
Public
that object. Only assign public permissions on any object when you want
the object to be available to all users. You can't change membership in
public.

Module Code & Module Title Slide Title SLIDE 15

 Some of the Database Roles in MS-SQL

Role name Description

Can perform all configuration and maintenance activities on the

db_owner
database.

Members of the db_securityadmin fixed database role can modify

db_securityadmin
role membership for custom roles only and manage permissions.

Can add or remove access to the database for Windows logins,

db_accessadmin
Windows groups, and SQL Server logins.
Members of the db_ddladmin fixed database role can run any
db_ddladmin
Data Definition Language (DDL) command in a database.
db_datawriter Can add, delete, or change data in all user tables.
db_datareader Can read all data from all user tables and views.

Module Code & Module Title Slide Title SLIDE 16

 Levels of Permission / Authorization Settings

• Server
• Database
• Schema
• Table, View
• Column

Module Code & Module Title Slide Title SLIDE 17

 Authorization Matrix/Table

• Authorization in MS-SQL is done on objects – database, schema,

table, view, stored procedure, column etc
• An authorization table captures the permission control
requirements that must be fulfilled by the DBA
• It acts as a source for permission management as well as
auditing
• A good authorization matrix will provide details on what are the
valid roles, objects that can be accessed/manipulated by the role
and exact permission that is granted or denied to the roles

Module Code & Module Title Slide Title SLIDE 18

 Sample Authorization Table
Role (sample) Permission Object Privilege(s)
Type
DBSLab_Admins Grant Database: <db name> Run DDL statements like Create, Drop & Alter tables, Create,
Modify and Drop stored procedures etc.

Customers Grant Stored Procedure: <stored Execute

procedure name>

Customers Grant Table: <table name> Select, Update

Customers Grant View: <view name> Select

Managers, Clerks Grant Database: <db name> Select

Clerks Grant Table: <table name> Insert, Update, Delete

Managers, Clerks Deny Column: <table name> (<column Select, Insert, Update
names>)

Auditors Grant Database: <db name> Select – Able to see all values but <col1> and <col2> must be
masked

Ref: https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-database-permissions-transact-sql?view=sql-server-ver16
Module Code & Module Title Slide Title SLIDE 19
 Roles-Users Mapping Table

In addition to the authorization table, you will

need a Roles-Users mapping table that
specifies who are the users in each of the roles

Sample table
Roles Users
DBSLab_Admins A0001
Managers M0001
Customers U100, U200
Clerks CL001, CL002

Module Code & Module Title Slide Title SLIDE 20

 Authorization Rules

SQL Authorization Rules queries takes the below form :

GRANT <privilege> ON <object> TO <subject>

DENY <privilege> ON <object> TO <subject>
REVOKE < privilege> ON <object> FROM <subject>

1. Subject: Can be individual users or roles who perform some activity on the
database.
2. Objects: Database units that require authorization in order to manipulate, eg. DB,
Table, Columns, View
3. Privileges: Any action that are allowed to be performed on an object by the subject.
Eg. Select, Update, Insert, Delete, Create, Drop, Alter, Execute

Module Code & Module Title Slide Title SLIDE 21

 Steps to Implement Object Level Permission based on the
Authorization Matrix/Table

• Create the role(s)

CREATE ROLE <role name>

• Grant or Deny the permission to the roles starting with the high-level objects first

GRANT <privilege> ON <object> TO <role name>

DENY <privilege> ON <object> TO <role name>
REVOKE < privilege> ON <object> FROM <role name>

Module Code & Module Title Slide Title SLIDE 22

 Steps to Implement Object Level Permission based on the
Authorization Matrix/Table

• Create the user(s)

Create User <user name> For Login <login name>

• Add or Remove user(s) to / from the respective role(s)

ALTER ROLE <role name> ADD MEMBER <user name>

ALTER ROLE <role name> REMOVE MEMBER <user name>

Module Code & Module Title Slide Title SLIDE 23

 Checking membership of a role

SELECT roles.[name] as role_name, members.[name] as user_name

FROM sys.database_role_members
INNER JOIN sys.database_principals roles
ON database_role_members.role_principal_id = roles.principal_id
INNER JOIN sys.database_principals members
ON database_role_members.member_principal_id = members.principal_id
WHERE roles.name = <role name>

Module Code & Module Title Slide Title SLIDE 24

 Managing Roles using SQL Stored Procedures

• Create roles using SP_ADDROLE system-stored procedure

• Drop roles using SP_DROPROLE stored procedure

• Add members to a role using SP_ADDROLEMEMBER stored

procedure

• Drop members from a role using SP_DROPROLEMEMBER

stored procedure

Module Code & Module Title Slide Title SLIDE 25

 Checking The Granted Permissons

SELECT dp.NAME AS SubjectName,

dp.TYPE_DESC AS SubjectType,
o.NAME AS ObjectName,
o.type_desc as ObjectType,
p.PERMISSION_NAME as Permission,
p.STATE_DESC AS PermissionType
FROM sys.database_permissions p
LEFT OUTER JOIN sys.all_objects o
ON p.MAJOR_ID = o.OBJECT_ID
INNER JOIN sys.database_principals dp
ON p.GRANTEE_PRINCIPAL_ID = dp.PRINCIPAL_ID
and dp.is_fixed_role=0
and dp.Name NOT in ('public','dbo')

Module Code & Module Title Slide Title SLIDE 26

 Checking Permission For Your Self

SELECT * FROM fn_my_permissions (NULL, 'DATABASE');

SELECT * FROM fn_my_permissions(<table name>, 'OBJECT')

ORDER BY subentity_name, permission_name ;

SELECT * FROM fn_my_permissions(<procedure name>, 'OBJECT')

ORDER BY subentity_name, permission_name ;

Module Code & Module Title Slide Title SLIDE 27

 Discussion

• Scenario: Imagine a database that has 100 tables.

Role A should be given access to view 98 of the
tables and should not have any type of access to the
remaining 2 tables. How would you implement this
permission setting ?

Module Code & Module Title Slide Title SLIDE 28

 Discussion

• The solution is to

– Step1 : Perform Grant view permission to the Role A

at the database level (so that the users in the roles
will be ale to access all the tables.

– Step 2: Perform Deny permission to the 2 tables

Module Code & Module Title Slide Title SLIDE 29

 Requirements #1 : Sample Code for Object Level User
Management

• Req #1.1
– Let’s say we need to grant permission to a clerk named Sam to view all the contents in the
Customer table
– Code below shows how we can achieve the specific requirements

Create Login sam With Password = 'QwErTy12345!@#$%'

Create User sam For Login sam

Create Role Clerks

Grant Select ON Customer TO Clerks

Alter Role Clerks Add Member Sam

Module Code & Module Title Slide Title SLIDE 30

 Sample Code for Object Level User Management

• Req #1.2
– Let’s say sam and all the clerks should not be allowed to see the contents of the
passport and password columns
– Code below shows how we can achieve the specific requirements

Deny Select ON Customer(Passport,[Password]) TO Clerks

Module Code & Module Title Slide Title SLIDE 31

 Alternative Approach to Meet Requirements #1

• Alternatively, we don’t have give permission to the table. Instead, we create a

view with the permitted columns and grant select permission to the view.

Create View RestrictedCustomer As

Select [ID], ,[Name], [Phone] ,[Email] ,[Country] ,
[Qualification] ,[Gender]
From [SampleDB_DBS].[dbo].[Customer]

Grant Select ON RestrictedCustomer TO Clerks

Module Code & Module Title Slide Title SLIDE 32

 Requirements #2

• Req #2.1
– Let’s say we need to grant permission to a database user named John to view all
the contents in the Customer table including the ability to decrypt the password
column (assume it is encrypted with the ASYMMETRIC KEY MyAsymKey)

Create Login john With Password = 'QwErTy12345!@#$%'

Create User john For Login john

Create Role Customers

Grant Select ON Customer TO Customers
Alter Role Customers Add Member john

GRANT CONTROL ON Asymmetric Key::MyAsymKey TO Customers;

Module Code & Module Title Slide Title SLIDE 33

 Disabling/Removing
SQL Login or User

SQL Login
• Alter login <login name> disable
• Drop login <login name>

SQL User
• Deny connect to <db user name>
• Revoke connect to <db user name>
• Drop user <db user name>

Module Code & Module Title Slide Title SLIDE 34