Chapter 3 — Operating systems and identities
Lesson map
Lesson 03 published. Map, example, EX009.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Service and administrator accounts"]
N2["3.2 Protecting key files"]
N3["3.3 Regular access reviews"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX009"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Service and administrator accounts"]
N2["3.2 Protecting key files"]
N3["3.3 Regular access reviews"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX009"]
[Learning outcomes]
|
v
[3.1 Service and administrator accounts]
|
v
[3.2 Protecting key files]
|
v
[3.3 Regular access reviews]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX009]
Learning outcomes
You will (1) manage service and administrator accounts; (2) protect key files; (3) review access regularly.
3.1 Service and administrator accounts
Each server runs services under dedicated accounts with limited rights. Aiko checks that the node software runs as its own user without administrator privileges and that administrators use personal accounts rather than a shared one. Personal accounts mean every administrative action is recorded against a person. She finds one server where a shared administrator account is still enabled and recommends disabling it once everyone has personal access. Accounts are identities in the operating system, and managing them carefully is the base of all other access control on the servers.
3.2 Protecting key files
Each node has a key file used to sign blocks, and the deposit service has credentials to submit transactions. Aiko checks file permissions: node key files are readable only by the node user, and credentials are stored in the server's protected secret store rather than plain configuration files. She finds one credential in a configuration file and arranges for it to be moved and rotated. Key files are among the most sensitive data on a server, because whoever reads them can act as that node or service without anyone noticing.
3.3 Regular access reviews
Aiko sets a quarterly access review: list every account on each server, compare with the approved list, remove accounts for people who have left and confirm that rights match current roles. In the first review she finds an account for a contractor whose work ended three months earlier. It is disabled. She records the review date, findings and actions. Mr Kowal explains that access tends to accumulate over time, because adding access is easy and removing it is easy to forget, so regular reviews are the only reliable remedy.
Worked example
Aiko disables a shared administrator account and a departed contractor's account, and moves a credential from a configuration file into the secret store.
Synthetic case. The accounts and findings are synthetic.
Errors and limits
Shared administrator accounts make actions untraceable to individuals.
Exercises
- EX009 — Personal accounts benefit. Why use personal administrator accounts? Rubric: 3 = actions are recorded against a person;; 2 = traceability;; 1 = speed;; 0 = none.
- EX010 — Credential location. Where should credentials be stored? Rubric: 3 = the server's protected secret store;; 2 = secret store;; 1 = configuration file;; 0 = none.
- EX011 — Review finding. What did the first access review find? Rubric: 3 = a contractor account three months after work ended;; 2 = old contractor;; 1 = vague;; 0 = none.
- EX012 — Review frequency. How often are access reviews run? Rubric: 3 = quarterly;; 2 = every quarter;; 1 = yearly;; 0 = none.
Synthesis
Dedicated accounts, protected key files and regular reviews control server identities.
Continue studying — chapter 03 of 18
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →