3 ms·

Honestly, it's not a bad idea even if the only reason is to just prevent accidental execution. In the company I work at, we have something similar for database

by swalsh 10y ago

Honestly, it's not a bad idea even if the only reason is to just prevent accidental execution. In the company I work at, we have something similar for database executions. In Dev you can run anything you want. However in prod, everyone only has read-only access. If you wish to execute something with higher authority, there is a web page we go to, where we can paste the code, a review board request, a ticket number (if available) a business authorizer, and a technical authorizor (other than yourself). It sounds like a lot, but it's usually pretty quick. Every command is then logged (which I believe is more for SOX reasons). It's annoying, but it's not that terrible of a system.

djrogers 10y ago
That's what it's like from your side of the glass - on the other side there are still sysadmins who either execute those commands, or have access to the API keys privileged to run those commands.
quantumhobbit 10y ago
Until the person fulfilling those requests goes on vacation. Then you're screwed. Of course a sane company wouldn't have a bus factor of one for such a process, but not all companies are sane.
marcosdumay 10y ago
It's always the same problem: Who will deploy such a system? At some point, you'll get somebody with full access to your system. You can reduce it into a very small window (at big cost), but you can't make it go away.
- PeterisP 10y ago
  Have a few people at a single computer perform the following ritual: 1. deploy the system 2. create new admin account with a long random password and/or 2FA physical token 3. print the password out, seal it in an envelope and put it in a safe not accessible to any IT person; place the 2FA token in a separate safe controlled by different person than the first safe; 4. remove all other admin accounts - with the other present technicians checking that no other account will have access 5. if needed, with proper authorisation you can retrieve the password, and implement the required changes (again, with a second person controlling what exactly is being done). If the systems require changes rarely, then this cost isn't that high.
jon-wood 10y ago
Someone, or something, has write access. How do you prevent them from doing destructive things.

by swalsh 10y ago

djrogers 10y ago

That's what it's like from your side of the glass - on the other side there are still sysadmins who either execute those commands, or have access to the API keys privileged to run those commands.

quantumhobbit 10y ago

Until the person fulfilling those requests goes on vacation. Then you're screwed. Of course a sane company wouldn't have a bus factor of one for such a process, but not all companies are sane.

marcosdumay 10y ago

It's always the same problem: Who will deploy such a system? At some point, you'll get somebody with full access to your system. You can reduce it into a very small window (at big cost), but you can't make it go away.

PeterisP 10y ago
Have a few people at a single computer perform the following ritual: 1. deploy the system 2. create new admin account with a long random password and/or 2FA physical token 3. print the password out, seal it in an envelope and put it in a safe not accessible to any IT person; place the 2FA token in a separate safe controlled by different person than the first safe; 4. remove all other admin accounts - with the other present technicians checking that no other account will have access 5. if needed, with proper authorisation you can retrieve the password, and implement the required changes (again, with a second person controlling what exactly is being done). If the systems require changes rarely, then this cost isn't that high.

jon-wood 10y ago

Someone, or something, has write access. How do you prevent them from doing destructive things.