4 ms·
My experience as a manager has been frustratingly similar. For the same security and least-access reasons, I don’t have a view into the systems permissions tab
by mattcwilson 5y ago
My experience as a manager has been frustratingly similar.
For the same security and least-access reasons, I don’t have a view into the systems permissions tables for all of the tools that my team uses. I also don’t have a “definitely complete” list of what those tools even are, or what roles my current team members have in them.
So when it comes to presenting IT with a new hire access request, often the best I can do is to say “please copy the access that person Y (another member of my team) has in system Z to a new account for person X”
Because of audit regulations, I have to do this on a one-request-per-person-per-system basis. Bulk changes for a group of users, systems, or both are verboten.
IMO, it feels like this is another area where no one is incentivized to own a holistic and efficient outcome. It’s not quite laziness, but it is a mountain of tedious and error prone tape cutting, compounded by information changing rapidly underneath in a way opaque to the people closest to the issue.
I suspect that this could be a lot better in a world where “default roles and system permissions for those roles” is a centralized and crowd-sourced document. Like a terraform config. And then any time access needs change in a non-one-off way, you could tf apply the new roles table out to all the systems. Such is my dream, anyway
- bpicolo 5y agoTheoretically the goal of SSO systems, just hard in practice with inconsistent implementation and the SSO tax [0] [0]: https://sso.tax/ https://sso.tax/
- mattcwilson 5y agoMaybe? I am not sure how much "role assignment" is handled as part of SSO vs. how often SSO is purely authentication and there's another app-tier layer that's doing authorization. "Role definition" is certainly app-tier, by ... uh... definition. I'm thinking of something more like a literal terraform config that treats roles as resource templates to be instantiated against human accounts. { template: "New SE", roles: [ { system: AWS-Live, role: ReadOnly }, { system: SonatypeNexus, role: ReadOnly } ... ] } And then you just do the equivalent of "tf apply 'New SE' joe@example.com" and a bunch of UX or backend automation updates permissions for Joe in all the things. And then you publish the role templates, and let your EMs, Sr. SEs, and other opinion-havers about roles start tuning/tweaking/extending/adding. With review and approval from Sec and IT. And then if there's some role definition change, you just roll it out like you would a single user.