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/en-us/library/dn765131.aspx http://www.databasejournal.com/features/mssql/exploring-sql-server-2016-always-encrypted-part-3-differences-between-deterministic-or-randomize-encryption-page-3.html Dynamic Data Masking: https://msdn.microsoft.com/en-us/library/mt130841.aspx Always Encrypted: https://msdn.microsoft.com/en-us/library/mt147923.aspx Encrypting connections: https://technet.microsoft.com/en-us/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 Silver Raffle Sponsors Bronze 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