DBA Permissions on LOCAL SERVER containing SQL SERVER BACKGROUND: Infrastructure team has revoked local admin where SQL Servers resides to everyone including DBAs. Finally, they agreed to let us RDP to the SQL Servers (which they had taken out), but any of the tasks we need elevated permissions are being done via a webex where the individual with rights logs into the server and gives me control to do what I have to do. (I still have to wait for that person to be available to do this for me).

I am Database Administrator III, MCSE, MCSA, and I can't even support my servers. My coworker and I provide support to over 140+ SQL servers from 2008-2014.  95% are virtual servers (Hypervisor). I am trying to get opinions from the SQL Server experts in the industry so I can document the answers for management, and would really appreciate your comments.  

QUESTION: * What is an appropriate workaround? *

These new security policies implemented (and without letting us know when they were going into effect) against all the staff in IT, and have prevented my fellow DBA and I from doing the very basic DBA tasks (which I have already documented for my manager and explained locations affected, registry keys, etc..):


Install SQL server
Install Upgrades, Hotfixes, or apply patches to SQL server
Upgrade or install features/components to SQL server
Create databases
Create data or log files and or move them to different devices
Manage files or file groups for space utilization, cleanup, and TROUBLESHOOT
Backup and Restores
Install Microsoft Assessment and planning tool.  Had to install under someone else’s login now I can’t run it or access the database in (localdb)\maptoolkit
Reboot the server after installs or to clear up an issue.- I’m ok with infrastructure doing this
Start and stop services for SQL components.- I’m ok with infrastructure doing this
Implement:


replication
high availability 
SQL Server cluster 
another business continuity strategy

Implement auditing
Import/export data
Start the instance of SQL Server in single-user mode 
Connect to SQL Server When System Administrators Are Locked Out
Server Configuration Manager
Create jobs in the OS scheduler if needed - I’m ok with infrastructure doing this if needed, and we can provide scripts


What is an appropriate workaround?
There are a number of US government regulations that, depending on how your company interprets them, require this separation of duties.  Sarbanes–Oxley (SOX) is the big one for publicly traded companies.  HIPAA  for healthcare organizations, etc.

The first question I have is, of those tasks you outlined, how many are you doing directly from the server?  Arguably many of those tasks don't require local server access, but I understand this would be frustrating if you are used to performing this work locally on the server.

Regarding workarounds, my suggestion is to be an adopter of this policy.  Do this by making sure that your security team is properly locking down user accounts, but creates clearly defined policies for service accounts and that those accounts are setup appropriately.  I would even encourage you to look at Group Managed Service Accounts as this makes everyone's life easier if you can make them work in your environment.  Follow this up with moving whatever processes you can off of the servers.  There are real security concerns with users actively logging into servers regularly, and I would say you should avoid doing this unless absolutely necessary.  Argenis Fernandez, during one of the most entertaining PASS sessions I've attended, even showed that anyone with access to a local admin account on a server can get elevated access to the SQL Server regardless how "locked down" it is.  Honestly, you could even go so far as to request all of the servers get configured to run as Windows Server Core, which is about as secure a Windows server as you can have. Finally, document those processes that cannot be moved off or need to have exceptions created for them.  This will likely be your biggest headache in the short term, but proper documentation should allow your organization to bend the rules to fit the business needs.

Look at it this way.  If anything goes bad, such as a breach of information, and it's traced back to unauthorized access to a server, this policy may save your behind without you knowing.  I've worked for years in the healthcare and insurance industries and as much as a headache as this sort of policy may seem to be, it's really a good policy to adopt.

This process will be frustrating... at least it has been the number of times I walked a similar path, but don't make it a we vs. them issue, instead approach road blocks with the following statement "this needs to happen so the business can run, how do we accomplish that within these restrictions?"  With this approach, it's not about you or your job, it's about your company staying in business which makes it a we vs. the policy issue.