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

2. About Stephen.Mokszycki@outlook.com
DBA and IT Professional for ~10 years.
Currently I am a Senior DBA 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.

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

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

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

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

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

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

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 users 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.
What does this mean? What happens when the database owner is SA?
Lets Find out!
Start the EXEC as Demo

11. Demo TIME!

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

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

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

15. Demo TIME!

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