Design the break-glass procedure and test it

short · 45 min · Objective 4.2

Task

Federation creates a dependency: if the identity provider is unavailable, nobody can sign in, including the people who would fix it. Design the exception, then test it -- because an untested break-glass account is an assumption.

Steps

  1. Write lab/breakglass.md specifying: how many accounts, where their credentials live, what second factor they use, who may use them, under what circumstances, and what must be recorded afterwards.
  2. State explicitly where the credentials are stored and confirm it is OUTSIDE the environment they recover. If they live in a password manager that itself uses the federated identity, write why that fails.
  3. Configure an alert that fires on ANY use of the break-glass identity, to more than one recipient.
  4. Test it: simulate the identity provider being unavailable, sign in with the break-glass account, confirm the alert fired, and record the elapsed time in lab/breakglass-test.md.
  5. Rotate the credential afterwards and record that you did, because a tested credential is a used credential.

Verify

grep -Eci 'outside' lab/breakglass.md
grep -Eci 'alert' lab/breakglass.md lab/breakglass-test.md
grep -Eci 'rotat' lab/breakglass-test.md
grep -Ec '[0-9]+ ?(s|sec|min)' lab/breakglass-test.md

All four non-zero. The rotation record is the step people skip: after a test, the credential has been used and seen, and leaving it in place makes the test itself the weakness.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.