Last week we talked about Least Privilege and how it can help reduce the impact of people doing bad things on an account. We started by describing Central Management and splitting off Privileged Access. Today, we’ll continue the discussion about ways to support Least privilege through two more ideas: auto-expiring access and eliminating generic accounts.
Auto-Expiring Access
Often access is fluid – someone needs access to some file or project, so you add them. But then you forget about it, and then years of one-off access grants can stack up to yield access to too much.
One easy way to reduce this is to automatically expire adhoc access. Box.com’s settings seem the most mature and intuitive. Microsoft has made moves in this direction, but their vision is fragmented and complicated and incomplete. Neither Gsuite nor Dropbox have this feature.
All major cloud storage providers allow individual users to manually set access expiration, but this requires your staff to do extra work. Don’t be lazy and make security their job: remember, their priorities are never security, their priorities are their daily work. To scalably deliver security improvements, you have to make the secure way the default or easiest way as much as you can.
If you’re technically inclined, you could bolt this capability on some vanilla storage with APIs and integrations; this is the AWS Way. For operational access, it’s not worth your time.
Generic Accounts
A generic account is one that’s not tied to a person. It provides access to lots of people; each of them know the password.
You can see why generic accounts hurt your ability to push Least Privilege. If someone new needs access, the people with existing access provide them the password. Anytime access needs to be plumbed into another system, the password is coded into the script to make the connection.
You will never know who has access because people share the password, often adhoc. The only way to effectively remove access is by changing the password. This is difficult: you must tell it to all the people with continuing access, and potentially ferret out any scripts that use it and adjust them so they don’t break.
Identity teams often have deep resentment for their customers on this subject. Generic accounts make it difficult for the identity teams to do their job, and once entrenched, a generic account is risky to remove – you don’t know what depends on it.
Generic accounts often show up when the barrier to change access is too high: people feel like they don’t have time to do it the “right way”, so they just share a password. The best long-term fix is often to make account creation and change easier, then encourage those teams to eliminate their generic account.
Some valid uses for generic accounts exist. Chiefly, working around unneeded but built-in access control. For example, training may require computers, and the computers require a valid login. If physical access to the computers is already vetted by another process, it may not be worth setting up individual accounts for each trainee: just give them all the generic password and wipe away everything they did after the training session.