Killing the Bastion Host: Zero-Trust Access for Fintech

The bastion host is the worst kind of legacy: everyone knows it's a bad pattern, no one has time to remove it, and it sits there as your highest-blast-radius CVE target.

Here's the replacement that takes a sprint, not a quarter.

What's wrong with bastions

• SSH keys live forever. Rotation is theoretical.
• One compromised laptop = lateral movement to every host the bastion can reach.
• The audit trail is last and wtmp — tamperable, easy to overlook.
• You have to patch it. Forever.

SSM Session Manager in one diagram

Engineer ─► AWS Console / aws cli ─► IAM auth (SSO + MFA)
              │
              └─► SSM Document ─► Target instance (no SSH port open)
                                   │
                                   └─► Session log to S3 + CloudWatch

Properties that fall out:

• No inbound 22. Anywhere.
• Per-session IAM authorisation with SSO + MFA on the engineer.
• Full keystroke log to S3, encrypted with a KMS key the security team owns.
• Time-bound access via SCPs or session policies.

The migration play

1. Tag every instance with SSM:Enabled = true.
2. Attach the SSM managed instance role.
3. Remove inbound 22 from the security group on a per-instance basis.
4. Decommission the bastion ASG.
5. Update the runbook. Tell the auditor.

Three days of work to delete one of the largest items on your risk register.