Learning outcomes
- Separate access-path identity from host and operating-system permission.
- Limit administrative access by person, host, protocol, action, device, and time.
- Close direct network and shared-credential bypass paths.
- Design evidence, revocation, emergency access, and recovery tests.
Protection need
Administrative protocols can change system state, access secrets, create persistence, and disable evidence. The design must protect the named host or service, the native operating-system account, privileged actions, credentials, session, file or clipboard transfer, forwarding, and emergency recovery.
Security objectives and requirements
Use named principals and strong authentication. Grant only approved hosts and protocols. Keep the host unreachable outside intended access paths. At the host, map to a narrow account or role and enforce native permission. Restrict SSH forwarding, agent forwarding, file transfer, RDP drive or clipboard redirection, and local administrator functions when they are not required.
Use time-bound grants for privileged work. Define idle and absolute limits, reauthentication, session termination, command or action evidence, and a tested break-glass path.
Security invariants and evidence
- A shared network location does not substitute for a named administrator.
- Route access does not grant unrestricted host privilege.
- Direct SSH, RDP, console, and management paths receive explicit policy.
- Credential or certificate expiry and revocation meet a stated target.
- Evidence connects the person, device, route, native account, host, time, and actions available.
Failure cases
- A private subnet or VPN makes every host reachable.
- Operators share an account or private key.
- SSH agent forwarding exposes reusable credentials on the host.
- RDP redirection moves sensitive data outside the protected boundary.
- A long session continues after access removal.
- Cloud console, serial console, or management network bypasses the main route.
- Session recording exists but privileged actions occur through an unrecorded path.
Design tradeoffs and residual risk
Native certificates and named accounts improve attribution but need lifecycle and trust management. Session recording adds evidence but creates sensitive data and cannot prove intent. Strict transfer and forwarding limits reduce attack paths but can impede valid maintenance. Emergency paths improve recoverability but carry high custody risk.
Use independent evidence and periodic path tests for the highest-impact systems.
Pomerium boundary
Pomerium can provide documented native SSH or client-assisted TCP access and can enforce policy for the named route. The SSH or RDP server owns native accounts, host keys, operating-system permissions, session features, and actions. Operators must protect console and direct network paths separately.
Exercise
Design access to one Linux host and one Windows host. Map person, device, route, certificate or client tunnel, host identity, native account, privilege elevation, transfers, forwarding, session lifetime, evidence, revocation, and emergency access.
Test shared credentials, direct network access, stale session, disabled user, forwarding, console bypass, and loss of the normal identity provider.
Evaluation checklist
- Can every administrative action be tied to a named person and native account?
- Are route access, host authentication, and operating-system permission separate?
- Are direct, console, management, forwarding, and transfer paths controlled?
- Do expiry and revocation stop existing and future access within the target time?
- Can emergency access work and produce evidence when normal dependencies fail?
Next learning unit
Clientless Zero Trust Access
Distinguish browser or native-client access from broad network tunnels and state which protocols still require a local connector.
