Zero Trust Access: Replacing the VPN and Closing Down SSH

The Core Principles

Zero Trust is not a single product — it is a set of principles applied consistently: authenticate every request, authorize against least privilege, and assume breach. Access decisions consider who the user is, what device they are on, and what they are trying to reach — not merely whether they hold a VPN certificate. The goal is to shrink the blast radius of any single compromised credential or host to as close to zero as possible.

• Never trust based on network location — a request from inside the LAN is not inherently safe
• Authenticate and authorize every connection against identity and device posture
• Grant least-privilege, per-resource access rather than broad network reachability
• Log and audit every access decision for detection and forensics

Close Public SSH

An SSH daemon exposed to the internet is under constant automated attack. Rather than hardening a public port indefinitely, put SSH behind an identity-aware proxy so the port is never reachable from the open internet. Access is brokered through a tunnel that authenticates the user against your identity provider and checks device posture before any packet reaches sshd. The firewall can then deny inbound 22 entirely.

# Identity-aware policy for SSH to the bastion
policy:
  resource: ssh.bastion.internal
  require:
    - identity_provider: corp-idp
      groups: ["platform-engineers"]
    - device_posture:
        disk_encryption: required
        firewall: enabled
  session:
    max_duration: 1h
    audit: full   # record session metadata for forensics

Put Internal Apps Behind Access Policy

Dashboards, admin panels, staging environments, and internal tools rarely need to be on the public internet. Place them behind an access gateway that enforces SSO and group-based authorization, so reaching the app requires a valid, MFA-backed identity rather than just knowing the URL. This removes a large class of exposure — unauthenticated staging sites, forgotten admin endpoints — without touching the application code.

Rolling It Out Without Breaking Access

Migrate incrementally. Start with a single non-critical service and a small group of users to validate the identity provider integration, device posture checks, and audit logging. Keep the existing access path available in parallel until the new one is proven, then cut over and remove the legacy route. Always provision a documented break-glass procedure for when the identity provider itself is unavailable.