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

Start with one low-risk environment. Enable SSM Agent, attach the least-privilege IAM role, and send session logs to an encrypted S3 bucket. Then close inbound SSH for that environment and measure whether engineers can still complete normal support tasks.

After that, move production in phases: break-glass access first, then routine access, then remove the bastion host entirely. AWS documents the model in Session Manager, but the important part is policy. Every session should have identity, approval path, timestamp, command history, and expiry.

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.

The biggest pushback is usually habit. Engineers are used to SSH. Auditors, however, care about identity, authorization, and evidence. Session Manager gives you all three without exposing an internet-facing jump box.

Closing thought

Bastion hosts feel safe because they are familiar. They are not safe — they are a permanent inbound door with a long history of CVEs and weak hygiene. Session Manager replaces the door with an identity-gated, fully-logged session, and the security posture improves on every axis at once.

Migration pitfalls to plan for

• IAM permissions for ssm:StartSession scoped per role, not per user
• VPC endpoints for SSM, SSMMessages, EC2Messages — otherwise sessions silently fail
• CloudWatch + S3 destination for session logs, with KMS encryption
• Break-glass plan that does not reintroduce the bastion