Islands of Security -- Scripts with Too Much Access

Have you noticed that many devops and/or ops scripts end up running with unnecessariliy high privileges?  

Here is what happens... for the first part, the script needs to grab data from XYZ so it needs privilege A.  Then, it updates ZYX so it needs privilege B.  And so on and so on.  The script needs to run with the aggregate of all these privileges -- Yikes!

This leads to:

1. The script can do things that it should not do either on purpose or by accidentally.  Early in my career one of my guys ended up blowing away a shared directory that all our trading apps used.  Ironically, it was supposed to back-up that same data.  One small script error; Two weeks of meetings.
2. User accounts/service accounts have to have too much access.  A script can only run as one user.  So the user it runs as must have all the privileges the scrip needs.  Almost every company I know has that one service account that does far too much.
3. Whoever can run the script has access to the "uber" account.  Somebody needs to be able to run this thing.  So they need to be able to login as the "uber" account.  I will admit that at 2:00 AM, I have absolutely end-run security to fix a problem.  And, no I should not do that.  During the day and when my head is about me, I'd never set things up so I could do that in the first place.
4. Compliance Problems and Best Practices.  Talk to the security experts.  Select any security standard from among the three and four letter acronyms.  Lumping too much into one bucket violates it. 

Separating Access

One of the things that we do in our product is allow different tasks within a workflow to run as different users.

By using a grouping-like structure, not only are different tasks within a workflow running as different users, but it's visually very clear.  The flow goes into the box, the flow comes out of the box -- simple.

Approval and Delegation

With the script translated into a workflow and islands of security isolated to minimize the access each account has, the workflow can go through the approval process to grant the workflow access to the users/privileges in a process that is aligned with your change control.

Now your can give users/developers/operators the ability to run the workflow without giving them direct access to any of the accounts the workflow runs as.