Outsourcing Database Administration Repeatable, Automated, and Safe Framework SQL Saturday 661 San Diego

About Stephen.Mokszycki@outlook.com DBA and IT Professional for ~10 years. Currently I am a Senior DBA at www.wayfair.com Worked with SQL 7.0/2000/2005/2008/2012/2014/2016 I have worked in a large environment: 500+ Instances, ~6000 databases, 10s TBs of data. I have worked in a small environments: 5 instances, 60 databases, 1TB of data Automation keeps me sane. https://www.linkedin.com/in/stephen-mokszycki-272b264a/

Overview: Outsourcing Database Administration to your Users Why and How do we enable self service? How do we secure it? How do we build it?

Why would you want to use a self service option? The little things are interruptive to the DBA(s). Empower the users safely, reducing time for both parties. DEV OPS! DBAs have More time for the hard problems. Reduce administrative errors. And LESS WORK!

How it normally works DBA Does Everything User Needs Something User Submits a ticket User pings DBA DBA pauses, reviews request DBA request more info User sends more details DBA reviews again DBA executes DBA follows up with user User confirms DBA Does Everything

Outsourcing the work: Self Service In order to create a self service option we have to grant people access. There are two ways to do this, the unsafe way and the safe way. Taking advantage of privilege escalation is the key idea. Talk about TRUSTWORTHY and

How to make it SAFE Using existing tool sets: SQL and maybe powershell. Using role based permissions and schemas Using something scary: TRUSTWORTHY Database. Executing procedures as another login, or privilege escalation Passing parameters safely with QuoteName() and injection checks

The Two Options to Self Service Give the people direct access aka SA Give Helpdesk Self Service via Controls Helpdesk Has SA HD tries to Fix things, drops Login DBA has no clue Wrong Login is dropped! Business is down! DBA scrambles to figure out what happened. DBA URLT HelpDesk executes proc Tries to Fix things, tries drop login Access is blocked! Event is logged! DBA notified Business as usual DBA follows up

A Trustworthy Database Is Dangerous Trustworthy lets the dbo do anything he can normally do outside of the database. Because of this we have to be careful with what we allow our users can do. We have to leverage Stored Procs and Role based permissions. We have to have safe repeatable code, with repeatable outcomes. Remember the goal: give the users some access into the admin world without compromising the integrity of our Server.

Trustworthy and DBO From the docs: The TRUSTWORTHY database property is used to indicate whether the instance of SQL Server trusts the database and the contents within it. DBO: The dbo, or database owner, is a user account that has implied permissions to perform all activities in the database. Members of the sysadmin fixed server role are automatically mapped to dbo. What does this mean? What happens when the database owner is SA? Lets Find out! Start the EXEC as Demo

Demo TIME!

SQL INJECTION! Watch out for injection! Verify your inputs. Encapsulate your string inputs with QUOTENAME() LOG LOG LOG! You need to know what happened.

Auditing, and Verification Auditing is hard when our sprocs are executed as owner….. ORIGINAL_LOGIN() LOG EVERYTHING! All Variables used Sproc name Who did it Date and Time Logs can drive alerts!

Recap: Our SQL Tools Tools in our Framework: A database, where users can ONLY execute a limited set of objects Via roles and schemas. TRUSTWORTHY and “sa” as the owner. EXECUTE AS OWNER An audit and SQL Injection Check ORIGINAL_LOGIN() QUOTENAME()

Demo TIME!

Expanding from here Increase your injection checks Add additional safety checks Add more to the log function and log tables. Raise eventlog errors Dump the users output somewhere, incase you need it later. Don’t copy paste, make a sproc or a function! Reusable code! Never write it twice!