How to Configure Bastion Hosts and Jump Servers to Route Remote Access for NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - AC.L2-3.1.14

Routing all remote administrative access through a controlled gateway (bastion host or jump server) is a core requirement of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control AC.L2-3.1.14—this post shows how to design, configure, and operate bastion hosts in a way small businesses can implement quickly while meeting compliance objectives for access control, logging, and least privilege.

Why a bastion or jump server matters for Compliance Framework objectives

AC.L2-3.1.14 requires routing remote access via managed access control points so that access is centrally controlled, monitored, and auditable. A properly configured bastion host provides a single choke point to enforce MFA, session recording, strict authentication (e.g., SSH keys or certificates), network restrictions, and centralized logging—reducing attack surface and enabling detection of misuse. For small businesses with limited staff and budgets, using a single hardened gateway reduces the number of nodes that require intense monitoring and simplifies access reviews during assessments.

Core design principles (actionable)

Implement the bastion with these principles: isolate the bastion in its own subnet (no sensitive data stored on it), restrict inbound management access to trusted source IP ranges, enforce multifactor authentication, use strong key or certificate-based auth, capture and forward audit logs to an immutable store, and apply the principle of least privilege so users can only jump to hosts they are authorized to reach. Regularly rotate keys/credentials and conduct periodic access reviews tied to HR changes and project lifecycles.

Technical implementation: examples and concrete configs

Small-business example (cloud-first): deploy a single bastion in a public management subnet with a security group allowing SSH (TCP/22) only from the corporate office fixed IPs and developer home static IPs. Better yet, avoid open SSH and use cloud session tools: AWS Systems Manager Session Manager or Azure Bastion—these remove the need for inbound ports and integrate with CloudTrail and Azure Activity logs for auditing. For traditional SSH bastions, enable SSH certificate-based auth with an internal CA or HashiCorp Vault to issue short-lived certificates (e.g., 1 hour) rather than long-lived keys.

OpenSSH hardening snippet (place in /etc/ssh/sshd_config on the bastion):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no
AuthorizedKeysCommand /usr/local/bin/ssh-ca-verify
LogLevel VERBOSE

Use AuthorizedKeysCommand or a certificates flow to validate ephemeral credentials. On downstream targets, restrict AcceptEnv and set AllowUsers/AllowGroups to only those SSH principals that have come through the bastion (can use network-based rules to only accept connections from the bastion IPs).

Session control, MFA, and auditing

Integrate MFA at the gateway. For SSH, use a PAM module (Duo, YubiKey via pam_u2f, or Google Authenticator) or require U2F-backed SSH certificates. For RDP, use an RD Gateway or Apache Guacamole with MFA in front. Capture session data with tools like auditd, tlog, or commercial bastion solutions that provide keystroke recording and session replay (Teleport, BastionZero, or AWS Session Manager with CloudWatch Logs). Forward syslog/audit logs to a centralized SIEM or cloud log service (CloudWatch Logs, Azure Monitor, or a managed ELK) with TLS encryption and write-once retention to meet forensic requirements.

Network and host-level controls to enforce routing

Enforce routing by network controls: downstream hosts should only accept management connections from the bastion subnet (security groups, firewall rules, host-based firewall like iptables/ufw). On-premise, use VLANs and access control lists; in cloud, implement security groups or NACLs. Disable direct inbound management ports on assets (no public SSH/RDP). Example AWS security group: allow inbound SSH to targets only from bastion security group (source: sg-bastion) and restrict bastion inbound to admin IPs. This ensures compliance with the “route remote access” objective because all remote admin flows traverse the controlled bastion.

Real-world small-business scenario

Acme Contracting (15 employees) hosts CUI-processing apps in AWS. They deploy one t3.small bastion in a management VPC, enable AWS Systems Manager Session Manager so engineers connect from the console without exposing ports, require AWS SSO (backed by the company's Azure AD) with MFA for console access, and send CloudTrail + CloudWatch logs to an S3 bucket with MFA-delete and 1-year retention. For their occasional on-prem servers, they run a hardened Linux jump server that uses OpenSSH with certificate auth from Vault and forwards audit logs to the same S3/SIEM. During a contractor audit, Acme can show controlled access, session logs, and access review records, satisfying AC.L2-3.1.14.

Risks of not implementing AC.L2-3.1.14

Failure to route remote access through managed gateways increases attack surface and risk of lateral movement, credential theft, and untracked privileged activity. Without centralized access points you lose coherent logging and session context, making forensic analysis difficult. Noncompliance risks include failed CMMC assessments, loss of DoD contracts, and material business impact from breaches—especially for organizations handling CUI where compliance is contractually mandatory.

Compliance tips and best practices

Document the bastion architecture in your System Security Plan (SSP) and include procedures in your Configuration Management and Access Control policies. Automate build and hardening with IaC (Terraform, CloudFormation) and Immutable images (Packer) so the bastion is reproducible. Enforce periodic access reviews (quarterly), rotate certificates/keys automatically, and configure alerting on anomalous gateway behavior (multiple failed logins, atypical session times). Maintain retention for access logs per organizational policy and be prepared to present logs and change history during assessments.

In summary, meeting AC.L2-3.1.14 is achievable for small businesses by centralizing remote access through hardened bastion hosts or managed cloud bastion services, enforcing MFA and certificate-based authentication, restricting network paths so management traffic must pass through the gateway, and shipping comprehensive logs to a centralized, tamper-resistant store. These actions create a defensible, auditable control point that both reduces risk and satisfies Compliance Framework expectations—documented, automated, and reviewed on a schedule to demonstrate continuous compliance.