DevOps Database Administration Repeatable, Automated, and Safe Framework SQL Saturday 714 Philadelphia

About Stephen.Mokszycki@outlook.com DBA and IT Professional for ~10 years. Currently I am a Senior DBA and .Net Developer 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/ Currently building a system that generates over 45 million rows an hour Make a joke about Joining the Dark side.

Overview: DEVOPS! 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 DEVOPS APproach? The little things are interruptive to the DBA(s). Empower the Devs safely, reducing time for both parties. DEVOPS! DBAs have more time for the hard problems. Reduce administrative errors. The two main keys are eliminating interruptions for all parties, and REDUCING ERRORS. Don’t, repeat yourself - DRY principle. AND LESS WORK!

The normal Request cycle Dev Needs Something Dev Submits a ticket Dev pings DBA DBA pauses, reviews request DBA request more info Dev sends more details DBA reviews again DBA executes DBA follows up with user confirms DBA Does Everything

Outsourcing the work: DEVOPS 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.

Demo TIME! EXECUTE AS DEMO STEP 6.

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

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 Devs 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. Start the EXEC as Demo

Your DBO user matters! What happens if my DBO is now SA? Can he do SA things? Give the demo of the SA User Not doing anything

Privilege Escalation: Execute AS OWNER In Combination with Trustworthy we can take advantage of our DBO User We can Break the outside of our database! Running as another account! What does this mean? What happens when the database owner is SA, the Database is Trustworthy, and We are executing things as Owner? Lets Find out!

The Two Options to Self Service Give the people direct access aka SA Give Devs 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

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! Make a WebAPI that the Devs can hit and access