Access control answers two questions for every request: who is this person, which is authentication, and what may they do, which is authorization. A settlement can run for a long time on local accounts, one group per role, SSH keys for administrators and file permissions, and should add a central directory only when changing a password or removing a person means editing many servers. Give each person the least access their work needs, one account each and never shared, and remove an account the day its owner leaves.
Part of Networking
Accounts, groups, permissions and keys for a settlement network: designing access by role, handling joiners and leavers, and when to centralise.
Roles Decide Access, And Groups Carry The Roles
Shared Resources sets out the working parts: an access control list says which users or groups may do what to a resource; groups beat individual entries because moving a person between roles changes their permissions automatically; and the principle of least privilege says each user and program gets only what it needs, because a compromised account with broad access does more damage. Resource Sharing adds that a central authentication server (LDAP, or a Windows domain) gives users one login for all services, instead of every server keeping its own list. The carrier Internet Infrastructure gives the practical rule for administration: SSH keys, strong passwords and sudo for administrative access.
Authentication proves who you are with something you know (a password), something you hold (a key file), or something you are. The settlement’s weak points are shared passwords, passwords written on the wall of a room anyone can enter, and accounts left alive after people go. A technical control cannot fix those; a habit and a checklist can.
What You Need
- A list of roles — who needs what to do their job
- A list of resources — the shared folders, mailboxes, the clinic records
- A group per role and an account per person
- A written joiners-and-leavers routine
Method: Build Access By Role
Step 1: Draw the matrix of roles against resources Rows for roles, columns for resources, and in each cell none, read, or read and write. This is the design; the software only enforces it.
Step 2: Make one group per role and give each resource to its groups Use the folder layout in File Sharing.
Step 3: Give each person their own account and put them in their groups No shared logins: a shared login cannot say who deleted what, and cannot be withdrawn from one person.
Step 4: Keep administration separate Administrators log in as themselves and use elevated rights only for the task (sudo, as the carrier says). Use SSH keys rather than passwords for remote administration (Encryption Basics covers protecting the keys).
Step 5: Run the leavers routine on the day Disable the account, remove it from the groups, retire any key they held, and change any password they knew that others share.
Step 6: Review a few times a year List accounts and group members against the actual people.
Step 7: Centralise only when you must When there are many servers and changing one person’s access means visiting each, a central directory pays; with one or two servers it adds a new thing that can fail.
Do not rely on hardware addresses to decide who may connect. A machine’s hardware address can be set by whoever controls the machine, so a filter on it is a convenience for tidiness, not a lock (general knowledge, not from the other articles).
Worked Example: A Clinic’s Access Matrix
The clinic in Communication Need has reception, examination rooms, a pharmacy and administration. Its stated flows: patient records reach reception and the examination rooms; prescriptions go from examination to pharmacy; billing information goes from examination to administration; appointments are visible everywhere. The design below follows those flows. R is read, W is write, - is none.
| Resource | Reception | Clinicians | Pharmacy | Administration |
|---|---|---|---|---|
| Patient records | R | R and W | R | - |
| Prescriptions | - | W | R | - |
| Billing | - | W | - | R and W |
| Appointments | R and W | R | R | R |
There are 4 x 4 = 16 role and resource pairs, and 3 + 2 + 2 + 4 = 11 of them carry any access; 5 are empty, and each empty cell is a deliberate refusal. Reception cannot read prescriptions or billing, and the pharmacy cannot change a record; that is least privilege. On the server, each resource is a folder owned by the group that writes it, with the other roles’ read access added by an entry for their group (Shared Resources describes extra named groups as POSIX ACLs). The matrix is a design example, not a clinical standard.
Common Mistakes
- One account shared by a whole room — no record of who, and no way to remove one person
- Giving everyone administrator rights “for convenience” — one mistake or one thief gets everything
- Forgetting leavers — an old account is a door nobody watches
- Granting access to a person where a group would do — access then drifts and nobody can say why someone has it
- Treating a hardware-address list as a lock
What’s Next
- Learn next: Intrusion Detection — noticing when access is used in ways it should not be
- Combine with: Firewalls — controlling access at the network, not the account