We do a lot of Identity Manager deployments, and the standard operating procedure (SoP) of most of our customers seems to be to provision a second, privileged account for many IT workers. The thinking here is decades old — users should sign in with their normal, unprivileged account for day-to-day work and only use their privileged account for administrative tasks. This reduces risk, because if the user in question makes a mistake while signed in with their normal account, the amount of harm that may ensue is limited.
That’s all well and good – it made perfect sense in an environment where security rights are assigned to a user persistently, without a time domain component. These days, however, we have products such as Hitachi ID Privileged Access Manager, and doubtless others. Using software in this category, it becomes possible to temporarily grant a user membership in privileged groups (e.g., Domain Administrators and the like), for just long enough to complete a task. That means that a user’s normally unprivileged account can be made privileged for a short time period. This approach has audit benefits — we can track not only who has admin rights, but when and for what purpose.
If this approach is used, going back to the notion of two accounts per user, we should ask ourselves: do IT workers such as system administrators still need that second, privileged account?
I think the answer is “no” – temporary privilege escalation is a cleaner, more transparent and easier to manage solution.
So lets stop creating these admin IDs, and instead focus on controls around and audit records of privilege escalation.