Transcript Powerpoint
Securing Data with SQL Server 2016
By
G.R. Prithiviraj Kulasingham
Principal DBA, Pearson Lanka
Introduction
Data is the new Oil – Information is money
One side is to make use of data
Other side is securing the data
Over 480 million data records are stolen in
2015
57% of crimes conducted by outsiders
It means 43% by insiders
Mobile phone is identified as the weakest link
What Attackers Do?
Intruders try to login using commonly used passwords,
defaults
They gather related information from Linked-In, Facebook etc.
SQL Server uses the machine name and port 1433 on default
installation
They may look for backup files as they are less secured
generally
Gather useful information like Passwords, Personal Data,
Financial Data etc.
Sell to competitors, Impersonate, or publish
Disrupt operations by removing logins, altering schema or
dropping tables
SQL injection
Some send “heavy requests” or loads of requests to lead to
Denial of Service(DOS)
Identify the Attackers
Hackers including Criminals
They scan the internet/ open networks
Local users
Legitimate users but go beyond their limit
People Have access for one purpose but use
for different purpose
Can a windows admin check a database?
Can a database Admin check the benefits of the
CEO?
SQL Server Security Overview
How many have used SQL Server 2000 or
before?
Initially it allowed blank password for “sa”
Following an attack, sp3 prevented it
SQL Server added many features in SQL Server
2005
User/Schema separation
Passwords to follow security policy, expiration –
prevents Intruders
Encryption of sensitive data
Surface area configuration
Granular Permissions
SQL Server Security Overview
SQL Server 2008 came with added feature set
Policy Based Management
Transparent Data Encryption, Protected by
Database Master Key & Service Master Key
Extended Protection Support
Secure Connection
Kerberos Authentication
SQL Server Security Overview
Database Audit – captures who did what
Adding automatic accounts is stopped
Encryption algorithms improved
Securing from Intruders
Security is not just DBAs job – Can’t rely just on
application/Network security
What protocol to use?
Simple Applications & SQL Server on same machine: Can use
shared memory
MDAC 2.8 or earlier cannot use shared memory protocol
Named pipes work well over LAN
Complex applications with queues, or over internet should use
TCP/IP
Are you using default named pipes or default ports?
Keep the SQL Server Browser service disabled
Make sure database users have strong password and
expiration policy
Including application users…
Securing from Intruders
Log and Monitor failed logins– Or email to
admins
Monitor long running queries –
They not only consume resources and lead to
deny many other requests (DOS) but also trying
to gather all the information you have
Use security best practices during database
design too
Securing from Internal Users
Use secure connection
It has performance issues: Connection takes
another roundtrip; Each packet goes through an
encryption and decryption process
Highly recommended for databases managing
credit cards, banking, stocks and other sensitive
data
Secure connection is made at server level not
database level
database design security best practices
Limit direct access to sensitive information
Either separate sensitive information or
define views and access only through views
Stored Procedures provide better security
than ad-hoc queries
Actual code and Tables are hidden to network
SQL Injection threat is minimized
Application user should run with minimum
privileges (Use granular permissions)
database design security best practices
Don’t keep sensitive data in unencrypted
form
EncryptByKey
EncryptByPassPhrase
EncryptByKey provides better security than
EncryptByPassPhrase
Both needs code changes
Subject to exposure to admins
database design security best practices
SQL Server 2016 introduces Always encrypted
Data is stored always in encrypted form in the
database
No need to change the client application except
change of driver
Driver is responsible for encryption and decryption
Either deterministic or randomized algorithm could
be used
Always Encrypted keeps the data encrypted and
protect even from DBAs
It allows the Business users to have control over the
data
How Always Encrypted differ with TDE?
TDE encrypts the data “in rest”
Decrypted at Read; Encrypted at Write
Travels in the network in unencrypted form unless SSL is used
DBAs can read the data by simply accessing
It prevents only from illegal copying, or stealing the backups
Database level setting
Always Encrypted keeps the data encrypted until the client
application reads
Encryption/Decryption happens at client side
Unless the same key/certificate is used, data cannot be
decrypted
Only selected columns are encrypted
Dynamic Data Masking
Dynamic Data Masking Allows users to read
only part of the data
Not for Admins; But for people with lesser
access
Need UNMASK permission to read the data
Row Level Security
Now you can grant permission at granular
level
Based on a property of data security could
be defined.
FILTER PREDICATE controls the rows selected
BLOCK PREDICATE controls data changes
References
Row Level Security: https://msdn.microsoft.com/enus/library/dn765131.aspx
http://www.databasejournal.com/features/mssql/exploringsql-server-2016-always-encrypted-part-3-differencesbetween-deterministic-or-randomize-encryption-page3.html
Dynamic Data Masking: https://msdn.microsoft.com/enus/library/mt130841.aspx
Always Encrypted: https://msdn.microsoft.com/enus/library/mt147923.aspx
Encrypting connections: https://technet.microsoft.com/enus/library/ms189067(v=sql.105).aspx
Questions
“Judge a man by his questions rather than by
his answers.”
― Voltaire
“He who knows all the answers has not been
asked all the questions.”
― Confucius
Sponsors
Platinum Sponsors
Platinum Raffle Sponsors
Gold Sponsors
Gold Raffle Sponsors
Bronze Sponsors
Silver Raffle Sponsors
Bronze Raffle Sponsors
Crystal Raffle Sponsors
Thank you
Please evaluate this session:
sqlsaturday.com/535/sessions/SessionEvaluation.aspx
Please evaluate the event at the end of SQLSaturday:
sqlsaturday.com/535/EventEval.aspx