IT basics

Stop making everyone an administrator: least privilege in a small team

The smaller the company, the more tempting it is to give everybody full rights. That decision sets how far the damage travels when something goes wrong. Here is what least privilege means in practice, and how to split roles between admin, standard user, read-only, finance and HR.

6 min read

What you will learn
  • Why everyone-as-admin widens the damage
  • To whom, how far and until when
  • How to split access into roles
  • Access steps for joining, moving and leaving

The short answer

Stop handing administrator rights to everyone. Not because you distrust your colleagues, but because when one account or one laptop has a bad day, whatever that account could reach is what the incident now covers.

Least privilege means giving each person the access their job actually requires. The operational version is simple: define four or five roles, put each new person into one of them, and change it when their job changes.

What full rights actually cost you

An administrator account can install software, change settings, read other people's data and delete it. That convenience is available to anything running as that account, not only to the person sitting in front of it.

If something malicious runs under a standard account, it reaches the files that person can touch. Under an administrator account, it reaches the whole shared drive and the configuration of other machines. Same event, completely different clean-up.

Ordinary accidents multiply too. The more people who can change settings, the less anyone knows who changed what. One morning the printer stops working, and the person who changed the setting genuinely does not remember doing it. This is routine in small offices.

It shows up again at resignation. When an administrator leaves, so does the knowledge behind their settings, the shared accounts only they used, and the automated jobs running under their rights. The narrower the access, the lighter the handover.

The principle itself

Give the necessary access, to the necessary extent, for the necessary time. Three parts:

  • To whom: decided by what someone actually does, not by seniority
  • How far: separate looking at something from changing it, and changing it from deleting it
  • Until when: if the work has an end date, the access has one too

The third part is what keeps the system from silting up. "Access to the accounting data during the year-end close" and "membership of this folder until the project ships" mean permissions expire on their own instead of accumulating forever.

Worth knowing
Least privilege is not a statement about trust. It is the same reasoning as not cutting forty copies of the office key: an administrative habit that keeps the consequences of a loss small.

Splitting the roles

Start with four or five roles. For a company of around ten people, this is usually enough.

RoleCan doCannot do
AdministratorCreate and delete accounts, change permissions, change system-wide settings(Kept to a few people; not used for daily work)
Standard userRead, create and edit data for their own workOther departments' data, system-wide settings
Read-onlyView and export an agreed set of dataEdit, delete, or add new people to a share
FinanceAll accounting, invoicing and payment dataAppraisals, recruitment records
HRAll personnel, payroll and appraisal dataCustomer-level sales and margin detail, system-wide settings

Finance and HR are separated because the material is different in kind. Payroll belongs to both, but nobody in finance needs to read performance reviews or health-related records, and nobody in HR needs the margin on each customer.

Read-only is more useful than it first looks. It fits part-time staff, short-term cover, outside parties such as auditors and accountants, and every occasion when someone says it would be handy to be able to see it. Far more situations than expected are satisfied by seeing.

How to hold administrator rights

Keep the number small, and then follow two rules.

  1. Do not use the administrator account for daily work. Read email and browse as a standard user; become an administrator only to change something
  2. Have at least two administrators. With one, nothing can be done on the day they are ill, and nobody can get in on the day they leave

The second rule only looks like a contradiction. Limiting how much access a role carries and limiting how many people hold it are different decisions. Concentrating everything in one person is how a company ends up locked out of itself.

Make multi-factor authentication a condition of holding an administrator account. Keep a written list of who holds them and read it every six months.

What this looks like in practice

A company of five

Everyone does several jobs, so three roles will do: two administrators, standard users, and read-only. On top of that, name specific people for exactly two things, the accounting data and the payroll data.

If any system is used through a shared password, start there and give people individual accounts. While the account is shared, nothing records who did what, and every resignation means changing a password everybody uses.

A company of twenty

Now the standard-user scope splits by department. Sales gets customers and orders, production gets drawings and stock, administration gets invoicing and expenses. Shared folder permissions follow the same lines.

At this size, exceptions appear: a salesperson who also checks expenses, an administrator who prints drawings. Exceptions are normal, but write them into the same list rather than agreeing them verbally. One sheet of paper is the difference between being able to explain the setup in six months and not.

Attendance and personnel data

Attendance records need to be visible to the individual, their approving manager, and whoever compiles the totals. A configuration where everybody can see everyone else's arrival times buys awkwardness rather than convenience. When an attendance system is introduced, decide the visibility before the rollout, not after the first complaint.

Joining, moving, leaving

Permission failures cluster around changes. Write the procedure down.

  1. Joining: pick one role and grant only that role. Do not create a "give them everything for now" account
  2. Moving: remove the old access before adding the new. Adding gets remembered; removing does not
  3. Leaving: disable the account on the agreed day, and change any shared passwords they knew
  4. Contractors and temporary cover: agree the end date before granting, and remove on that date

For point three, set the day access ends as a date; not a vague "their last day in the office" or "around the leaving date". An account left alive because someone is not coming back anyway is an account nobody is watching.

Careful
Do not keep using a leaver's account to finish their work. Once two people have used one account, the records no longer show who did what, and you cannot reconstruct it later. Move the data to the new owner's account instead.

Where it goes wrong

Restrict too far and work stops. If people routinely cannot proceed and the standing answer is "ask the administrator", the administrator's day fills up and nothing is safer. Every quarter, ask the people doing the work what access they are missing.

There is also the permission split that is not really a split: the folder is locked down, but a copy of its contents sits in a place everyone can read. Permissions have to be thought about together with where files end up.

Finally, look at anywhere a single person is the only approver. When they are away, work stops, and somebody widens access "just for today" to get through it. Access widened just for today is almost never narrowed again.

In short

Four or five roles, and each new person goes into one of them. Few administrators, not used for daily work, protected with multi-factor authentication, and never only one. Keep finance and HR apart, because the material differs. Use read-only more than you think you should. And remember that removing access matters more than granting it, so write the moving and leaving procedures first.

At APOUL

Making everyday paperwork and information a little simpler.

APOUL builds software to take some of this work off your hands. Everything is in preparation for release; the price, the distribution method and the supported systems will be announced on each product page once decided.