August 26, 2026 at 12:00 am
Comments posted to this topic are about the item Admin Rights for Everyone
August 26, 2026 at 9:50 am
The longer elevated privileges are allowed the harder it becomes to remove them.
Apps get written on the assumption of elevated privileges and any initiative to reduce privileges turns into a systems archeology piece.
Apart from the technical tasks go decrease privileges there is the politics of doing so.
1. Getting the work assigned as a priority when the decision makers are focussed (bonussed) on revenue generating work.
2. Change management hurdles because change is risk.
3. Service interruptions are deeply unpopular and are ammunition for the nay sayer.
August 26, 2026 at 10:59 am
I may have a lot of gripes about some of my workplaces' policies, but at least one of them isn't "everyone has admin." Now, do I feel the developers have rather too much privilege to production? Yes, I'd love to gut their permissions in prod all the way down to just db_datareader, but that's not happening soon.
Sure, pipelines and a working CI/CD process might get us there, but they (and the Ops team that I'm on) have been talking about such things for a couple years now, inertia has kept it from moving at more than a snails pace. Maybe by the time I'm ready to retire.
Now, the app accounts, that logins used by the front end code to talk to the database(s,) those are another that I'd like to trim back the permissions, but as David.Poole said, "The longer elevated privileges are allowed the harder it becomes to remove them." It's been like this since WELL before I started here, and I suspect it's going to be here for a long time after I'm gone.
At least I do know everyone and every service account that has sysadmin in SQL and THAT is kept locked up tight.
Now, my previous employer? Local Administrator in the OS for everyone, from the newest hire all the way to the owner of the company, and I don't think that's changed since I left.
August 26, 2026 at 5:02 pm
The longer elevated privileges are allowed the harder it becomes to remove them. Apps get written on the assumption of elevated privileges and any initiative to reduce privileges turns into a systems archeology piece. Apart from the technical tasks go decrease privileges there is the politics of doing so. 1. Getting the work assigned as a priority when the decision makers are focussed (bonussed) on revenue generating work. 2. Change management hurdles because change is risk. 3. Service interruptions are deeply unpopular and are ammunition for the nay sayer.
I realized this early on. I used to elevate privileges for people and forget. Now, I've given them to devs, but I have a job to disable the account. I tend to want a separate account for elevated privileges rather than just adding them.
August 26, 2026 at 5:04 pm
I may ...
have been talking about such things for a couple years now, inertia has kept it from moving at more than a snails pace. Maybe by the time I'm ready to retire.
...
Inertia is hard. As I work with customers, I'm constantly trying to scale back the PoCs and amount of change because I know fighting inertia is hard. Small tweaks, not large changes have the best chance of success.
August 26, 2026 at 5:11 pm
implement changes slowly - and sometimes hidden. for example for majority of cases db_owner can be replaced with ddl_admin - subtle change that in most cases goes unnoticed, and when found we can say "you had this change for x number of month and your work was not affected"
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply