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

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

3. 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?

4. 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!

5. 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

6. 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.

7. Demo TIME!
EXECUTE AS DEMO STEP 6.

8. 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

9. 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.

10. 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

11. 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

12. 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!

13. 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

14. Demo TIME!

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

16. 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!

17. 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()

18. Demo TIME!

19. 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