Replacing standing administrative access with brokered sessions

A standing SSH key or a local administrator account is access that exists whether or not anyone is working. It survives staff changes, it usually bypasses the tooling that would log it, and it is the first thing an attacker looks for after landing on a host. Removing it is less about buying a product than about deciding which path an administrator will take instead.

What a broker changes

A session broker sits between the person and the target. The user authenticates once to the broker, the broker decides from policy whether this person may reach this host with this role, and then it opens the connection. The credential that reaches the host is issued for that session and expires shortly afterwards. Depending on design, the broker may inject the credential, hold it in an agent, or terminate the protocol and pass keystrokes and files onward.

Decisions that matter more than the vendor

• Where the session is recorded, and whether the recording sits somewhere the administrator cannot delete it.
• Whether the break-glass path exists, who can invoke it, and what alert fires when they do.
• Whether the tool sits in the data path or only in the approval path. Approval-only designs leave the old key valid.
• Whether hosts accept direct connections in addition to brokered ones. If they do, the broker is a convenience rather than a control.
• How the broker itself is administered. It accumulates high privilege and needs its own separation of duties.

Honest limits

NIST SP 800-207 describes zero trust as a set of decisions about each request, and it is explicit that the architecture depends on the identity provider and the policy engine being trustworthy and available. A broker that is down becomes an outage for every administrator at once, so a tested and logged emergency path belongs in the design rather than in the list of exceptions. Session recording also raises data protection questions, because recordings contain whatever was on the screen, which may include customer data.

A rollout that tends to work

Start with one environment and one class of host. Measure how often the broker denies something the old path allowed, because those denials are the policy being written. Keep the old path enabled for a defined period, log its use, and confirm it falls to zero before switching it off. Then check the hosts from the outside: a direct connection from an unmanaged network to the SSH port should fail rather than prompt.

References

• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-53 Revision 5, Access Control and Identification and Authentication families
• CISA Zero Trust Maturity Model