◇ OpenCyber Academy
Technical · Chapter 3 · English

Chapter 3 — Operating systems and identities

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — Operating systems and identities

Lesson map

Lesson 03 published. Map, example, EX009.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Where keys live"]
  N2["3.2 Least privilege for key files"]
  N3["3.3 Service accounts and identity"]
  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 Where keys live"]
  N2["3.2 Least privilege for key files"]
  N3["3.3 Service accounts and identity"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX009"]

[Learning outcomes]
    |
    v
[3.1 Where keys live]
    |
    v
[3.2 Least privilege for key files]
    |
    v
[3.3 Service accounts and identity]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX009]

Learning outcomes

You will (1) locate key and certificate stores on Linux and Windows hosts; (2) apply least privilege to private key files; (3) explain how service accounts use cryptographic identities.

3.1 Where keys live

On the Linux file-transfer host, Tomás finds the server certificate in /etc/ssl/certs and the private key in a directory readable only by root and the service account. On Windows laptops, certificates live in the certificate store, which the operating system protects with the user's or machine's credentials. The handhelds keep their Wi-Fi client certificate in a vendor keystore backed by hardware. Priya explains that the location matters as much as the algorithm: a strong RSA or ECDSA key in a world-readable file gives no protection, because anyone who copies the file can impersonate the server.

3.2 Least privilege for key files

Tomás checks permissions on the file-transfer host with ls -l and finds that a backup script had copied the private key into /tmp with mode 644, readable by every account. He reports it, removes the copy, and the team rotates the key because they cannot prove nobody read it. The rule he writes in his notebook is that a private key should be readable only by the process that needs it, owned by a dedicated account, and never copied into shared folders, tickets or chat. Exposure without evidence of misuse still requires rotation.

3.3 Service accounts and identity

Many Lumen services run as non-human accounts. The tracking portal runs as svc-portal, which needs to read its TLS key but nothing else; the nightly transfer job runs as svc-sftp and authenticates to partners with an SSH key. These identities are as important as staff passwords, yet they are often forgotten when people leave. Tomás adds each service account to the inventory with its key, its owner and the date the key was created, so that later chapters can plan rotation. He also confirms that none of the accounts can log in interactively.

Worked example

Tomás audits key file permissions on two synthetic hosts, finds the 644 copy in /tmp, and records the rotation ticket and the affected service account.

Synthetic case. Hostnames, paths and accounts are invented examples of common layouts.

Errors and limits

File permissions do not stop root or a compromised service. Hardware-backed stores reduce copying but not misuse through the device.

Exercises

Synthesis

Cryptographic identity is only as strong as the file permissions and account boundaries that protect each private key.

Continue studying — chapter 03 of 18

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →