Security, Security, Secuirty =tg= Thomas Grohser, NTT Data SQL Server MVP SQL Server Performance Engineering SQL Saturday #506 BI Edition April 30 th 2016,

Slides:



Advertisements
Similar presentations
Chapter 9 Security. Endpoints  A SQL Server endpoint is the point of entering into SQL Server.  It is implemented as a database object that defines.
Advertisements

Logins, Roles and Credentials Lesson 14. Skills Matrix.
Chapter 9 Chapter 9: Managing Groups, Folders, Files, and Object Security.
Anil Desai SQL Saturday #35 (Dallas, TX).  Anil Desai ◦ Independent consultant (Austin, TX) ◦ Author of several SQL Server books ◦ Instructor, “Implementing.
Database Security and Auditing: Protecting Data Integrity and Accessibility Chapter 4 Profiles, Password Policies, Privileges, and Roles.
Brian Alderman | MCT, CEO / Founder of MicroTechPoint Pete Harris | Microsoft Senior Content Publisher.
Chapter 8 Chapter 8: Managing the Server Through Accounts and Groups.
Chapter 10 Overview  Implement Microsoft Windows Authentication Mode and Mixed Mode  Assign login accounts to database user accounts and roles  Assign.
Esri UC2013. Technical Workshop. Technical Workshop 2013 Esri International User Conference July 8–12, 2013 | San Diego, California Administering Your.
Mike Fal - SQL SERVER SECURITY GRANTING, CONTROLLING, AND AUDITING DATABASE ACCESS March 17, 2011.
Database Security and Auditing: Protecting Data Integrity and Accessibility Chapter 3 Administration of Users.
1 Group Account Administration Introduction to Groups Planning a Group Strategy Creating Groups Understanding Default Groups Groups for Administrators.
Today’s Objectives Chapters 10 and 11 Security in SQL Server –Manage server logins and database users. –Manage server-level, database-level, and application.
Chapter 7: WORKING WITH GROUPS
Sofia, Bulgaria | 9-10 October SQL Server 2005 High Availability for developers Vladimir Tchalkov Crossroad Ltd. Vladimir Tchalkov Crossroad Ltd.
IOS110 Introduction to Operating Systems using Windows Session 8 1.
Database Security and Auditing: Protecting Data Integrity and Accessibility Chapter 4 Profiles, Password Policies, Privileges, and Roles.
Chapter 6 : Designing SQL Server Service-Level Security MCITP Administrator: Microsoft SQL Server 2005 Database Server Infrastructure Design Study Guide.
Chapter 13 Users, Groups Profiles and Policies. Learning Objectives Understand Windows XP Professional user accounts Understand the different types of.
MICROSOFT SQL SERVER 2005 SECURITY  Special Purpose Logins and Users  SQL Server 2005 Authentication Modes  Permissions  Roles  Managing Server Logins.
Module 4: Managing Security. Overview Implementing an Authentication Mode Assigning Login Accounts to Users and Roles Assigning Permissions to Users and.
Module 14 Configuring Security for SQL Server Agent.
Copyright © 2013 Curt Hill Database Security An Overview with some SQL.
Module 10 Assigning Server and Database Roles. Module Overview Working with Server Roles Working with Fixed Database Roles Creating User-defined Database.
Securing SQL Server 2005 Anil Desai. Speaker Information Anil Desai –Independent consultant (Austin, TX) –Author of several SQL Server books –Instructor,
Permissions Lesson 13. Skills Matrix Security Modes Maintaining data integrity involves creating users, controlling their access and limiting their ability.
Database Security. Multi-user database systems like Oracle include security to control how the database is accessed and used for example security Mechanisms:
1 Chapter Overview Managing Object and Container Permissions Locating and Moving Active Directory Objects Delegating Control Troubleshooting Active Directory.
INTRO TO SQL SERVER SECURITY By Robert Biddle
Esri UC 2014 | Technical Workshop | Administering Your Microsoft SQL Server Geodatabase Shannon Shields Chet Dobbins.
SQL Server 2005 Implementation and Maintenance Chapter 6: Security and SQL Server 2005.
SQL Server Security Basics Starting with a good foundation Kenneth Fisher
Log Shipping, Mirroring, Replication and Clustering Which should I use? That depends on a few questions we must ask the user. We will go over these questions.
Introduction to SQL Server for Windows Administrators Presented to WiNSUG 02/05/09 Bret Stateham Owner, Net Connex Blogs.netconnex.com.
SQL Server Security The Low Hanging Fruit. Lindsay Clark Database Administrator at American Credit Acceptance
Optimizing SQL Server and Databases for large Fact Tables =tg= Thomas Grohser, NTT Data SQL Server MVP SQL Server Performance Engineering SQL Saturday.
Processing Temporal Telemetry Data -aka- Storing BigData in a Small Space =tg= Thomas H. Grohser, SQL Server MVP, Senior Director - Technical Solutions.
WELCOME! SQL Server Security. Scott Gleason This is my 9 th Jacksonville SQL Saturday Over ten years DBA experience Director of Database Operations
19 Copyright © 2008, Oracle. All rights reserved. Security.
SQL Database Management
SQL Implementation & Administration
Security, Security, Secuirty
Administrating a Database
Securing and Administering the Data
Microsoft SQL Server 2014 for Oracle DBAs Module 8
Securing Data with SQL Server 2016
Outsourcing Database Administration
Get to know SQL Manager SQL Server administration done right 
Access, Users, Permissions
SQL Server Security For Everyone
Optimizing SQL Server and Databases for large Fact Tables
Contained DB? Did it do something wrong?
Designing Database Solutions for SQL Server
Advanced Security Protecting Data from the DBA
Code-Less Securing of SQL Server
DevOps Database Administration
Auditing in SQL Server 2008 DBA-364-M
Security, Security, Secuirty
DevOps Database Administration
5 WAYS TO BYPASS *OR ENSURE* SQL SERVER SECURITY MATT MARTIN
SQL Server Security from the ground up
SQL Server Security 101 How did you get in here, and
SQL Server Security For Everyone
Intermediate Security Topics in SQL SERver
Outsourcing Database Administration
Copyright © 2013 – 2018 by Curt Hill
SQL Server Security 101 How did you get in here, and
Administrating a Database
SQL Server Security from the ground up
We Need To Talk Security
Presentation transcript:

Security, Security, Secuirty =tg= Thomas Grohser, NTT Data SQL Server MVP SQL Server Performance Engineering SQL Saturday #506 BI Edition April 30 th 2016, Baltimore, Maryland

select * from =tg= where topic = =tg= Thomas Grohser, NTT DATA Senior Director Technical Solutions Architecture / Focus on SQL Server Security, Performance Engineering, Infrastructure and Architecture New Papers coming 2016 Close Relationship with SQLCAT (SQL Server Customer Advisory Team) SCAN (SQL Server Customer Advisory Network) TAP (Technology Adoption Program) Product Teams in Redmond Active PASS member and PASS Summit Speaker 21 Years with SQL Server

And one more thing … All I know about BI is how to not install it

NTT DATA Overview 20,000 professionals – Optimizing balanced global delivery $1.6B – Annual revenues with history of above-market growth Long-term relationships – >1,000 clients; mid-market to large enterprise Delivery excellence – Enabled by process maturity, tools and accelerators Flexible engagement – Spans consulting, staffing, managed services, outsourcing, and cloud Industry expertise – Driving depth in select industry verticals Why NTT DATA for MS Services: NTT DATA is a Microsoft Gold Certified Partner. We cover the entire MS Stack, from applications to infrastructure to the cloud Proven track record with 500+ MS solutions delivered in the past 20 years Why NTT DATA for MS Services: NTT DATA is a Microsoft Gold Certified Partner. We cover the entire MS Stack, from applications to infrastructure to the cloud Proven track record with 500+ MS solutions delivered in the past 20 years

Drawing at the end of the session  Drop your business card or fill out provided blank card and drop in the cup  Must be present at the time of drawing at the end of the session to win:

Agenda  Make you aware what security means and know how to build a secure environment.

Setting the Goal  Security defined  Authenticating users  Is the person/application really who they claim to be  Limiting access to Authenticated users  Limiting data as needed to users/applications  Protection data from getting stolen  Protecting “lost” data from being used  Protecting Intellectual Property (the code, schema, …)

Threads  Hobby hacker  Disgruntled employee  Criminals / Competitors (Professional hacker seeking money)  Disgruntled employee with skills  Professional Hacker seeking fame  Disgruntled DBA  Stupid Users  Social engineering  Government  People like me

General Problems I see  Management does not care  To many people have access to too much data  Shared passwords  Writing down of passwords  The wrong people have passwords  Security vs. Agility & Convenience  DBA’s / Developers don’t know how security exactly works (we are fixing the last right now)

Basic Security Concepts  Separation of duties  Two factor authentication  Least amount of privileges  Only grant access to data the user needs  Auditing  Security is NOT a magic command or option you can turn on  Security is a concept, commitment and a lifestyle

Physical Security  Who has physical access to your server?  How is access controlled?  Who else is in the same building/room?  Is there an alarm system?  What happens to the access control in case of a power loss  Who has physical access to your network/office?  What happens to a defect hard disk / SSD?

Network Security  Which devices can connect to the network?  Port Security  Automatic IP assignment  Is the Wi Fi accessible outside the office?  How secure is the password / encryption?  VPN  How is access controlled  RSA Token  Certificates  How often are passwords changed

Server Security  Who installed the OS?  Who configured the OS?  Is the Windows domain secure?  Who is domain admin?  Who knows the passwords of the service accounts?  How often are passwords changed?  Who can login on the server and who has local admin rights?  Where did the OS and SQL Server installation media come from?  Who installed SQL Server with which options

SQL Server Service – Service Account  Network Service  SQL Server can’t access network shares (for backup, log shipping, …)  Windows User  The DBA should not know the password  No Single person should know the password  It is possible to use a throw away password  Domain User  Required for constraint delegation  The DBA should not know the password  No Single person should know the password  It is possible to use a throw away password  Local System  Access to network shares can be configured to ServerName$ account if the server is a domain member

SQL Server logins  SQL Server logins are only available if configured during setup  Created on SQL Server  Can be created without the DBA knowing the password  Can be shared across servers (use sp_help_revlogin)  Can use Windows expiration and complexity rules  Needed for inter server communication via linked servers if domains are not trusted and for many Unix/Linux/Mac/Solaris applications  Technically deprecated since SQL 6.5 but will not go away any time soon

Special logins  sa  public  They exist even if SQL Server logins are not configured during setup but sa can’t be used to login in that case

Windows Active Directory Basics  There are Accounts and Groups  Accounts can be members of groups  Groups can be members of other groups  Each account or group has a unique ID the so called SID  Prior to SQL 2012 logins based on windows groups can’t be assigned a default schema

Mapping logins to users  In SQL Server you can create Logins that are mapped to Windows accounts or groups  The Windows account or group must exist  The mapping is done trough the SID  If the account gets renamed in AD it will continue to work in SQL Server  A user/application can login if either the Account or a group that the account is direct or indirect a member of is mapped on a SQL Server  If multiple logins exist the user is a member of the security is composed from all of them

Server Roles  Once a login is created/mapped on a SQL Server instance it can be made a member of one or more server roles  Very careful with this. Server roles assign a lot of power to the user and as a wise comic character once said. With great power comes great responsibility  sysadmin Anything  securityadmin Anything after granting yourself sysadmin  serveradmin Shutdown Server and change server settings  setupadmin Add remove linked servers  processadmin Kill Processes  diskadmin Create/Modify disk files  dbcreator Create or restore databases  bulkadmin Execute BULK INSERT  SQL 2012+: Custom server roles e.g.: CodeDebugger that can see server state and execution plans

Permissions 101 – Object Hierarchy  Instance  Database  Schema  Table, View, Procedure,… (Object)  Column  If a user gets SELECT granted on a table he/she can run a select against that table.  Granting SELECT on a schema allows the user to select data from every table in that schema

Permissions 102 – Basic Permissions  Each type of object has different permissions. Here are a few examples  Table  SELECT  INSERT  UPDATE  DELETE  Stored Procedure  EXECUTE  Schema  ALTER  EXECUTE  SELECT  INSERT  UPDATE  DELETE ……

Permissions 103 – Options for Permissions  SQL Server has three options for each permission  GRANTAllow use  DENY Don’t allow  REVOKENo setting, get GRANT/DENY from someplace else (DEFAULT = NO)  If you would permission each user on each object only GRANT and DENY would be needed. Once groups and the object hierarchy come into play REVOKE is needed too.  Granting a user SELECT on a schema and DENY SELECT on a table in that schema allows the user to select from each but this one table.  To remove that one exception you would place a REVOKE on the previously DENY.  Yes you could just GRANT SELECT it but then in case you REVOKE the SELECT from the schema the user still would have the select on the one table

Permissions 104 – The danger of DENY  If a user is DENYed access at one level this will always override a GRANT in another level.  The only exception is for members of the sysadmin role. It is impossible to REVOKE or DENY something for a sysadmin.

ROLES (Database Roles)  Since assigning lots of permissions to individual users is not effective you can assign permissions to roles and then add users (or other roles) as members. These users inherit then all permissions from the role.  If a user is member of multiples roles the permissions are combined  As before a DENY in one role will have priority over a GRANT in another.

Default Database Roles  db_owner perform all configuration and maintenance activities on the database, drop the database and take backup (you can use a trigger to prevent both)  db_securityadminmodify role membership and manage permissions/can elevate to db_owner  db_accessadmin can add or remove access to the database for Windows logins, Windows groups, and SQL Server logins.  db_backupoperator can back up the database.  db_ddladmin run any Data Definition Language (DDL) command in a database.  db_datawriter add, delete, or change data in all user tables.  db_datareader read all data from all user tables.  db_denydatawriter cannot add, modify, or delete any data in the user tables  db_denydatareader cannot read any data in the user tables

USER  Tying it all together (simplified)  Windows Account mapped to SQL Server Login (or SQL Server Login)  Mapped to a User in a database  User is member of database roles  Database roles have permissions on objects

Dangerous groups  All employees group  All service accounts  Groups that group groups  If they get there SID into a database they can access it  Granting or Denying permissions on these groups can have unexpected and unwanted side effects

Server Level Permissions  There is also a battery of more granular permissions that can be granted or denied (a few listed here)  ADMINISTER BULK OPERATIONS  ALTER ANY CREDENTIAL  ALTER ANY DATABASE  ALTER ANY LOGIN  ALTER ANY LINKED SERVER  ALTER SERVER STATE  ALTER TRACE  CREATE ANY DATABASE  IMPERSONATE  SHUTDOWN  VIEW ANY DEFINITION  VIEW ANY DATABASE  VIEW SERVER STATE

Great security tool & hole: Database Owner  Don’t confuse with member of db_owner database role or dbo schema  Use MyDatabase  EXEC = 'sa'  Default = User that creates the database or restores it (normally a member of sysadmin server role – just keep that in mind)

Stored Procedures ALTER PROC dbo.DoHarm WITH EXECUTE AS OWNER-- Powerful and dangerous!!! AS -- Evil Things can happen here; Procedures can be executed under the security context of the database owner, whatever that user can do the procedure can do in that database.

Trustworthy databases ALTER DATABASE SET TRUSTWORTY ON This widens the ability of a stored procedure to execute under the context of the database owner and run server level commands as well. Excellent feature if stored procedure deployment is controlled. Deadly feature if not. This should never be set on a DWH/BI database

Big problem with RESTORE DATABASE  To execute restore database the user must be at least DATABASE CREATOR on the server  The default owner of the database is the login that restored the database  An execute as owner stored procedure can now restore any other database (including MSDB, the newly restored MSDB could have a job defined running as SA doing whatever it wants …)  Workaround have a RestoreLogin that is only database creator, a trigger that prevents this login from restoring a database named msdb or model and execute the restore as EXEC ('RESTORE DATABASE d1 FROM DISK = ''c:\...'';') AS LOGIN = 'RestoreLogin‘

Security for HA/DR  Logins must by synchronized to second location  If you initialize Logshipping and/or AlwaysOn via GUI then the secondary nodes do not have the same owner  Unless you use the restore trick from before then in case of LogShipping, Database Mirroring and AlwaysOn the secondary databases have a different owner in case of a failover (high privilege owner)  Linked Servers must be created on each node  Certificates must be installed on each node

The Goal  For the same user have different permissions in the DWH than on the OLTP source system  Use  Always On Readable Mirrors  Database Mirroring with snapshots or  Standby Read Only Log Shipping to bring the data to the DWH server

The Problem  In all three cases the database on the DWH server is read only and permissions can not be changed

The Solution  Use AD Groups to give the same user two different identities

THANK YOU! and may the force be with you… Questions?

Encryption  Best done in application layer and then send to SQL Server as encrypted value.  Encrypted columns limit search ability  OS file system encryption (EFS)  Works  Is a pain in the a#%#%$  Slow, hard to maintain

TDE – Transparent Database Encryption  Encrypts the whole database  Great for making sure the data can’t be read from a stolen/copied disk  Great for encrypting backups  Bad for compressing backups  Excellent for whitelisting databases on instances  Only as good as the Certificate Management

Keys and Certificates for TDE  Database Master Key in master database  Used to protect all certificates in master database  Certificates in master database  Used to protect the database encryption key  Database Encryption Key  Used to encrypt the database

Key Management  Separate from DBA or Automate  I create them all on a central server and then Backup/Restore to the one I need the databases deployed. The Central server maintains a whitelist that is maintained by the security department and cannot be modified by the DBA’s even if they are logged in as sysadmin

Preventing DBAs and sysadmins from modifying data  It is impossible to DENY a member of the sysadmin server role anything  Workaround  On the table you want to prevent editing by sysadmins add a DML Trigger  Check for either specific logins (use ORIGINAL_LOGIN()) and commit else rollback or  Check for sysadmin membership and rollback, else commit  Then create individual server level triggers that prevent sysadmins from dropping, altering or disabling them (individual triggers on each event)  ALTER_TRIGGER  CREATE_TRIGGER  DROP_TRIGGER ……  Then create a global DDL trigger (DDL_EVENTS) preventing sysadmins from dropping, altering or disabling them  Make sure you have one backdoor account that can execute  You might want to exclude triggers in normal databases

master database and stuff that starts with sp_  sp_ … is not TLA (two letter acronym) for stored procedure  sp_ … is short for special  Every object created in master database that starts with sp_ appears magically in every database  Yes not just stored procedures also table for example  DEMO

Auditing  Who can read the audit logs?  What to audit?  Audit logs can become very large very quickly  How to prevent a text from going into the audit log or a Trace / X-Event SELECT CASE WHEN 42=42 THEN 'Secret Text' ELSE ENCRYPTBYPASSPHRASE('', '') END

Linked Servers  The user context must be forwarded or mapped to the other server  SQL Server Logins must be forwarded or mapped to SQL Login  Windows Logins can be forwarded or mapped to SQL Server Login  Constrained Delegation  Catch all to an account includes public / guest users on the source server. Use with caution  DEMO  No way to script existing SQL Logins.  Create process to manage

Secure Deployment  Audit code before it goes into production  Deployment account is the only account that can execute DDL  Audit all other accounts for DDL or even have a rollback trigger for DDL

Baseline Security  Have a script with your default security settings  Run it every n hours on each server

Using Trustworthy Databases for the Good  Have an Admin database on each server (stay out of master), I like to call it X  Make it owned by sa and TRUSTWORTHY  Make sure all code is vetted  Create schemas like  Run  Find  List ……  Create a Database Role DBA_F5_Role and add the DBA Users to it  Create procedures WITH EXECUTE AS OWNER like  Run.Backup …  List.LogSpace …  Find.BlockingTransactions … ……  Create a login the DBA’s can use in case an unforeseen event happens  Remove sysadmin role from the DBA user accounts