Chapter 5 — Privileged access on servers
Lesson map
Lesson 05 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Admin accounts"]
N2["5.2 MFA"]
N3["5.3 Linux sudo"]
N4["5.4 Standing privilege"]
N5["Break-glass access"]
N6["Logging admin activity and service accounts"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Admin accounts"]
N2["5.2 MFA"]
N3["5.3 Linux sudo"]
N4["5.4 Standing privilege"]
N5["Break-glass access"]
N6["Logging admin activity and service accounts"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[Learning outcomes]
|
v
[5.1 Admin accounts]
|
v
[5.2 MFA]
|
v
[5.3 Linux sudo]
|
v
[5.4 Standing privilege]
|
v
[Break-glass access]
|
v
[Logging admin activity and service accounts]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) require MFA for admin access; (2) separate admin accounts; (3) limit standing privilege.
5.1 Admin accounts
Server administrators use separate named admin accounts, never their everyday accounts. Seun removes three generic admin accounts used by several people, replacing them with named ones. Generic accounts make it impossible to know who made a change, and their passwords are often shared and rarely changed. Named admin accounts give each administrator their own credentials and their own record in the logs. Seun works with the infrastructure team to find what each generic account was used for before disabling it, so no scheduled job or service breaks. The three accounts are disabled first, then deleted after a month without problems.
5.2 MFA
Admin sign-in to servers goes through a jump host that requires MFA. Direct remote access to servers from laptops is blocked by firewall rules, so all admin paths pass through the controlled point. A single jump host gives Marlowe one place to apply MFA, record sessions and review access, instead of trying to protect each server's remote access separately. Blocking direct paths matters as much as adding MFA, because an unblocked route would let an attacker bypass the jump host. Seun tests the firewall rules from an ordinary laptop to confirm that direct connections fail. The jump host itself follows the standard's server appendix.
5.3 Linux sudo
On Linux, admins sign in with SSH keys to their own accounts and use sudo, with logging. Root sign-in over SSH is disabled, following the CIS Benchmark. Individual accounts and sudo logging mean every privileged command can be traced to a named administrator, which shared root access cannot provide. SSH keys replace passwords for sign-in, and keys belonging to staff who leave are removed as part of leaving. The infrastructure team applies these settings through the Linux appendix of the standard, so they are measured with the rest of the baseline each month.
5.4 Standing privilege
Some admin rights are only needed occasionally. Seun introduces time-limited elevation for domain admin rights, granted for a few hours with approval. Domain admin rights are powerful enough to change any account or device, so holding them permanently increases risk if an admin account is compromised. With time-limited elevation, an administrator asks for the rights, a second person approves, and the rights expire after a few hours. Each grant is logged with the reason. Seun reviews the grants monthly to check that they match real tasks, and the record goes into the evidence pack.
Break-glass access
If the jump host or MFA service fails during an emergency, admins still need a way in. Seun creates two break-glass accounts with long random passwords stored in a sealed envelope in the safe and in the password manager's emergency vault. Using one triggers an alert to the operations director, and the password is changed afterwards.
The accounts are tested twice a year so they work when needed.
After each test, the passwords are changed and the envelope resealed, and the test is noted in the change log.
Logging admin activity and service accounts
All admin sessions through the jump host are logged with the user, time and target server, and the logs go to the central log service. A monthly review, following the log management approach in NIST SP 800-92, looks for unexpected targets or unusual hours. Service accounts used by applications get the same scrutiny as people: each has a named owner, the least rights its application needs and a long random password stored in the vault. Seun finds that the backup service account is a domain administrator; the infrastructure team reduces it to the backup operator rights it actually requires.
Worked example
After two months, all server admin sessions pass through the MFA jump host, and the three generic accounts are disabled.
Synthetic case. Events are synthetic.
Errors and limits
Blocking direct admin access before the jump host works would stop urgent fixes.
Exercises
- EX021 — Generic accounts. Why replace generic admin accounts? Rubric: 3 = accountability and revocation;; 2 = accountability;; 1 = vague;; 0 = none.
- EX022 — Jump host. What does the jump host achieve? Rubric: 3 = single controlled MFA path;; 2 = MFA;; 1 = vague;; 0 = none.
- EX023 — Root login. Why disable root SSH sign-in? Rubric: 3 = forces named accounts and sudo logging;; 2 = security;; 1 = vague;; 0 = none.
- EX024 — Time-limited rights. Explain time-limited elevation. Rubric: 3 = granted temporarily with approval;; 2 = temporary;; 1 = vague;; 0 = none.
- EX025 — Order of change. Why build the jump host before blocking direct access? Rubric: 3 = avoid locking out admins;; 2 = order;; 1 = vague;; 0 = none.
Synthesis
Named accounts, MFA and limited standing privilege protect the most powerful access.
Continue studying — chapter 05 of 12
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →