Module 7 · 7.1

English

Nederlands English Deutsch

Permissions and minimal management

Module 7: Access, suppliers and cloud · Reading time: 10 minutes

Learning objective: After this lesson you'll be able to set up permissions according to the "as little as possible" principle: everyone has their own account, admin rights are kept separate, external parties get temporary and limited access, and you have a fixed approach for when someone joins, changes role or leaves.
Key concepts: least privilege, personal account, shared account, admin account, separation of duties, joiners, movers and leavers, access overview

The principle: as little as possible

Least privilege means everyone gets exactly the access needed for their work, and no more. NIST describes it as a principle whereby users are granted only the access rights needed to perform their official duties.

Why does this matter? Because every account can be taken over sooner or later: through phishing (module 3), a leaked password (lesson 1.4) or an infected laptop. What an attacker can then do depends entirely on that account's permissions. The account of an intern who only does social media gives little away. The account of someone who's "for convenience" an administrator everywhere gives away everything: email, payments, the website, the backups.

Minimal permissions don't reduce the chance of a break-in, but they do reduce the damage. It's the same idea as keys to a building: the cleaner has a key to the front door, not to the safe.

Everyone their own account

A shared account is an account that several people log in to with the same password: "we all use info@example.com to log in to the accounting package". It feels practical, but it has four major drawbacks:

You don't know who did what. The log only shows "info". If a payment is changed, you can't trace who did it.
You can't disable just one person. If someone leaves, you have to change the password for everyone, and in practice that often doesn't happen.
Two-factor authentication (2FA) works poorly. The code arrives on one phone, so 2FA gets switched off or the code gets passed around.
The password gets passed around via WhatsApp, notes and email, and is therefore no longer secret.

A personal account solves all of that: your own login, your own 2FA, your own log, and it can be disabled individually. Almost every business service supports multiple users with their own permissions. A shared mailbox such as info@ can perfectly well continue to exist as an address; just give the people who read it access through their own account, if your mail system supports that.

Keep admin rights separate

An admin account can create users, change permissions, alter settings and often also delete data. Precisely for that reason, you use it as little as possible.

Work daily with a normal account and only log in as administrator when you need to manage something. This also applies to your laptop (lesson 5.2).
Make sure you have at least two people with admin rights on the most important services, or a well-kept emergency account. If the only administrator is ill or gone, you'll be stuck.
But also no more than necessary. Five administrators in a company of eight people is four too many.
Turn on two-factor authentication on every admin account, preferably phishing-resistant (lesson 2.4).

Separation of duties goes a step further: one person should not be able to carry out a sensitive action from start to finish on their own. You saw the best-known example in lesson 1.2: whoever enters a supplier's new IBAN doesn't also approve the payment themselves. In a small company this can be simple: one person prepares the payment, another approves it in the banking app.

External parties: temporary and limited

Web developers, accountants, IT companies and freelancers often need access. The classic mistake is to give them your own password. Then they can do everything you can, and afterwards you no longer know who can still get in.

Better:

Give them an own account with only the permissions needed. An accountant has enough with invoices; a web developer with the files of one website.
Give access with an end date if it's a one-off job. Many systems can let an account or key expire automatically.
Where possible, restrict from which network someone may log in.
Record who has which external access, and why.

Joiners, movers and leavers

Permissions grow by themselves. Someone starts in sales, helps out in administration for a few months and then moves to production. If nobody pays attention, after two years that person has the permissions of all three roles. That's why you arrange permissions at three moments:

Moment	What you do
Joining (new employee)	Create own accounts with the permissions of the role, set up 2FA straight away, explain where things are
Moving (different role)	Add new permissions and remove old ones
Leaving (departure)	On the last working day disable accounts, revoke sessions on devices, change shared passwords, transfer files

When someone leaves, the order matters. First transfer, then disable, only delete later. If you delete an account immediately, with many services the person's files, calendars and email disappear too. With some cloud services that becomes permanent after a short period: according to its own documentation, Microsoft 365 keeps a deleted user's OneDrive for 30 days by default. Disabling keeps the data and closes off access.

When someone leaves, also don't forget: forwarding rules the person has set up (lesson 2.5), app passwords, access to the banking app, social media and your domain's registrar, and keys or passes to the building.

The access overview

An access overview is a simple table: for each service, who has access, with which permissions, and whether it's a personal or an external account. Go through that list at least twice a year, and always after someone leaves. For every line, ask one question: does this person still need this today?

In practice: what it looks like

In the example environment My WebOké, you invite a colleague, accountant or web developer as a user. They log in with their own details, and you tick per permission what they're allowed to do, for example only Invoices for the accountant. Only the account owner can invite users and change permissions, and with one click you can revoke access again. In DirectAdmin you can give a web developer their own FTP account for a single folder, or a login key with an expiry date, restricted commands and access only from certain IP addresses.

In Nextcloud, when a colleague leaves, you first choose Disable: they can no longer log in, but the files remain stored. The documentation is clear: only delete the user once everything has been taken over, because a deleted user is permanently gone, along with all their files. Other systems work in a similar way, but the names and time periods differ; look it up before someone leaves.

Summary

Minimal permissions limit the damage if an account is taken over.
Everyone their own account: then you know who did what and can disable someone individually.
Use admin rights only when necessary, for a small number of people, with strong 2FA.
External parties get their own, limited and, where possible, temporary account, never your password.
Arrange permissions for joiners, movers and leavers; when someone leaves: transfer, disable, delete later.

Quiz

Exercise

Exercise A7.1: Who gets which access? You're given a series of situations from a small company (a new accountant, a web developer for a job, a departing colleague, an intern). For each situation, choose the best way to grant or close off access. The program checks your choices and explains why.

Exercise D7.1: Your access overview. Create an access overview of your five most important services: who has access, with which permissions, personal or shared account, internal or external. Remove at least one unnecessary permission or shared account and write your leaver checklist for the next time someone leaves.

Exercise D7.1: Your access overview

Here's how: (1) Choose your five most important services (for example mail, accounting, bank, hosting control panel, cloud storage, your domain's registrar). (2) Create an overview per service: who has access (role, no names needed), which permissions, personal or shared account, internal or external, two-factor authentication on, date of last login if the service shows this. (3) Look up the list of users in each service and compare it with your overview. Note the differences. (4) Remove at least one unnecessary permission, one old account or one shared account, or replace a shared account with personal accounts. (5) Check how many admins each service has; aim for two. (6) Write your offboarding list: what you do on someone's last working day (disable accounts, revoke sessions, check forwarding rules and app passwords, change shared passwords, transfer files, bank, social media, registrar, keys and passes). (7) Set up a recurring appointment (twice a year) to review the overview.

For five services it's known who has access and with which permissions.
At least one unnecessary permission or account has been removed.
No service has more admins than needed, and none has only one without emergency access.
External parties have their own account, not your login.
The offboarding checklist is ready.
The next review is in the calendar.

Which access did you find that you didn't (still) expect?

Which shared account is hardest to split up, and why?

If your own account is taken over tomorrow: what could the attacker do?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing