Skip to content
Standing Access

Contents  ·  Operations

Availability of the Control Path

A PAM system that is down stops all administrative work, including the work of fixing it. Designing for that, and for the workarounds it otherwise produces.

Analysis

Introducing a broker between administrators and systems creates a dependency with an availability requirement higher than almost anything else you run.

What an outage means

Administrators cannot work, including on the incident that may have caused the outage.

Change freezes in practice, whether or not one is declared.

Workarounds are created under pressure, by competent people, and they persist.

Confidence in the programme drops sharply and does not recover quickly.

One serious outage during a major incident can end a deployment, which is a political outcome as much as a technical one.

The availability target

Higher than the systems it protects, because it is a dependency of all of them.

Including out of hours, which is when incidents happen.

Including during a site failure, which is when administrative access matters most.

Stated explicitly and designed for, rather than inherited from whatever the platform defaults to.

Designing for it

Clustering or active-active deployment, across failure domains.

Tested failover, not assumed. Quarterly at minimum.

Independent dependencies. The broker should not depend on a system whose recovery requires the broker.

Local caching where the product supports it, so a network partition does not remove access entirely.

Monitored as a tier zero system, with alerting to people who can act.

The circular dependency

The design error that causes the worst outcomes.

The vault authenticates against the directory.

The directory's administrative credentials are in the vault.

The directory fails.

Now nobody can obtain the credentials to fix it.

Break the circle deliberately: local break-glass accounts on the directory, offline credential storage, or an independent authentication path for recovery.

Draw the dependency graph and look for cycles. Most organisations have at least one and have never checked.

Degraded mode

Define what administrators do when the broker is unavailable.

Break-glass accounts on critical systems, documented and tested.

A stated time limit on degraded operation before escalation.

Recording still required where possible — target-side logs shipped centrally continue to work when the broker does not.

Rotation afterwards of everything used.

A review of what was done during the period.

Without a defined degraded mode, the mode is whatever the person on call invents, and it will not be recorded.

Change management for the broker

Treat changes to it as high risk, because they are.

Test in a non-production environment that actually resembles production.

Change windows outside peak administrative activity.

A rollback plan tested rather than assumed.

Never change it during a change freeze for something else, which concentrates risk.

The measure

Availability, measured from the administrator's perspective rather than from the component's uptime.

Time to failover, measured in tests.

Number of break-glass uses attributable to broker unavailability, which is the honest measure of whether it is reliable enough.

Administrator-reported friction, which predicts workarounds better than any uptime figure.

Testing failover properly

An untested failover is a hypothesis, and the failure mode is discovering that during an incident.

Fail over deliberately, in production, on a schedule.

Have an administrator perform real work during the failed-over state.

Measure how long the transition took and what was disrupted.

Test the failback, which is frequently less reliable than the failover.

Test with a dependency removed — the directory, the network path — rather than only with a clean component failure.

Quarterly, and after any change to the broker or its dependencies.

Measuring friction, not uptime

Component uptime and administrator experience diverge, and only the second predicts bypassing.

Time from intent to session established, measured end to end.

Failed attempts and their causes.

Break-glass uses attributable to broker problems.

Support tickets mentioning the broker.

Ask administrators directly, quarterly, whether the path is workable.

A system with high uptime and high friction will be routed around, and the uptime figure will show nothing wrong right up until the coverage measurement does.