10TH ANNUAL CONFERENCE ABOUT MODERN IT TECHNOLOGIES
Tightening SQL Server
Security
10TH ANNUAL CONFERENCE ABOUT MODERN IT TECHNOLOGIES
Thank you Sponsors #ThriveITconf
Silver
Evening event sponsor
Material
Media
1
2
Introduction
• Dejan Sarka
@DejanSarka
– Data Scientist
– MCT, Data Platform MVP
– 34 years of data modeling,
data science and data quality
• 17 books, 20+ courses and
seminars, writing more
Agenda
• Security basics
• Row-level security
• Data masking
3
4
Structure of Secure Systems
Attempt to access Resource
Authentication of caller
Authorization
Enforcement
Resource
Identity
information
Security
configuration
settingsDirect
access
blocked
Authentication and Authorization
• Authentication
– Is the verification of the identity of a principal (such as
determining who someone is)
• Authorization
– Is the assignment of permissions on a securable to a
principal (such as deciding what a person is permitted
to do)
– Can be implemented by assigning a principal to a role
that already has permissions
– Is implemented via GRANT, DENY, or REVOKE
statements for permissions on database objects
5
6
Vulnerabilities Assessment
• SQL Server 2012+,SSMS 17.4+
Principals, Securables, Permissions
7
8
Special Principals
• The sa login
• The public server role
• The public database role
• The guest database user
• System db users
– Information_schema and sys
• System logins based on certificates
GRANT, REVOKE, DENY
• GRANT is used to assign a permission
• DENY is used to explicitly deny a permission
– Used where permissions inherited through group or role
membership
– Should only be used in exceptional circumstances
• REVOKE removes either a GRANT or a DENY
9
10
Schemas
• Containers for database objects
– Created via CREATE SCHEMA
– Listed by querying sys.schemas view
• Users can have default schemas
• Built-in Schemas
– dbo
– guest
– sys
– INFORMATION_SCHEMA
Object Name Resolution
• If the schema name is omitted, rules apply to
how the name will be resolved
– Each user can be assigned a default schema
– Users with no defined default schema will have dbo
as their default schema
– First search is in the user's default schema
– If not found, the dbo schema is searched also
• Whenever referencing an object in a statement,
users should specify both the schema and the
object name
– SELECT ProductID FROM Production.Product
11
12
Row-Level Security
• Programmable objects - views, stored
procedures, scalar and table-valued user
defined functions, and triggers
– No broken ownership chains
• SQL 2016+: declarative (predicate-based) row-
level security (RLS)
Ownership Chains
• Programmable objects refer to base tables and
to each other in a kind of chain
– For example, a stored procedure can use a view that
selects from a base table.
– All the objects in SQL Server have owners
– As long as there is a single owner for all the objects in
the chain, you can manage permissions on the
highest level only
• SQL Server trusts that the owner of the
procedure knows what the procedure is doing.
– This works for any DML statement (SELECT,
INSERT, UPDATE, DELETE, and MERGE)
13
14
Predicate-Based RLS (1)
• Filter predicates silently filter the rows the
application reads
– No application change is needed
– Also filter the rows when an application updates or
deletes the rows; this is because the application again
simply does not see the filtered rows
• Block predicates explicitly block write
operations
– You can define them for after-insert and after-update
operations, when the predicates block inserts or
updates that would move a row beyond the scope of
the block predicate
Predicate-Based RLS (2)
• Block predicates
– After insert block predicates also apply to minimally
logged or bulk inserts
– You can also define block predicates for before-
update and before-delete operations, when they
serve as filter predicates for the updates and deletes
– Note that if you already use filter predicates, before-
update and before-delete predicates are not needed
• You might want to change the affected
applications to catch additional errors produced
by block predicates
15
16
RLS Predicate Function
• You define predicates through a predicate
function
– In the body of this function, you can use other tables
with the JOIN or APPLY operators
– If the function is schema-bound, no additional
permission checks are needed
– If the function is not schema-bound, users need
permissions to read the data from the joined tables
RLS Security Policy
• A security policy adds an RLS predicate to a
table using a predicate function
– The policy can be disabled - users see all of the rows
– A security policy also filters and/or blocks the rows for
the database owners (the dbo user, db_owner
database, and sysadmin server roles)
17
18
SSMS Data Classification (1)
• SQL Server 2008+,SSMS 17.5+
SSMS Data Classification (2)
• SSMS stores the classification information in the
columns' extended properties
– Sensitivity label – Public, General, Confidential –
GDPR, Confidential, Highly Confidential, Highly
Confidential – GDPR
– Information type – Banking, Contact Info, Credentials,
Credit Card, Date of Birth, Financial, Health, Name,
National ID, Networking, SSN, Other
19
20
SQL Server 2019 Data Classification
• In SQL Server 2019, you store the classification
in the additional native database metadata using
the new ADD SENSITIVITY CLASSIFICATION
DDL statement
• You can check the classification information
through the sys.sensitivity_classifications view
• The classification information is also shown
when you use SQL Server Audit to audit the
data modifications and querying
Dynamic Data Masking
• Obfuscate values of a column
– The default function implements full masking
• A string is masked by changing each character to X
• Numeric values are masked to zero
• Date and time data type values are masked to 01.01.2000
00:00:00.0000000
• Binary data is masked to a single byte of ASCII value 0
– The email function masks e-mails to [email protected]
– The random function masks numeric values to a
random value in a specified range
– The partial function uses a custom string to mask
character data
21
22
DDM Limitations
• You must give the users the UNMASK database
level permission if you want them to see
unmasked data
• Limitations
– The UNMASK permission currently works at the
database level only
– You also cannot mask columns encrypted with the
Always Encrypetd option, FILESTREAM and
COLUMN_SET (sparse) columns, and on full-text and
computed colums
– Carefuly crafted queries can bypas masking
Q & A
• SQL Saturday Slovenia 2019 (13. in 14.12., Xnet and FRI,
Ljubljana) –
https://www.sqlsaturday.com/910/EventHome.aspx
• Pre-Con seminars:• Power BI Data Visualizations & Storytelling with Prathyusha Reddy
K - https://www.kompas-xnet.si/…/koledar-tecaje…/SQL2019%20-
%202
• Cutting Edge: AI and intelligent Data Processing with Azure IoT in
the Cloud and on the Device with Kostja Klein and Marcel Tilly -
https://www.kompas-xnet.si/izobra…/koledar-tecajev-t/SQL2019
• Thank you!
23
24
THANK YOU
25
