Guest post originally published on the Appaegis blog by Michael Shieh

It’s a common practice to set up a bastion server to provide access to the host and then use that as the gateway for SSH connectivity. The practice is based on the need to maintain visibility into what users do and perform authentication to internal SSH servers. Using a bastion server is an improvement over exposing SSH endpoints on the public Internet. It provides additional control in a network centric model. 

However, data shows that 74% of data breach results from unauthorized access. In a world where users work from anywhere, and connect over untrusted networks to access the cloud the methodology to secure access to a ssh bastion server must be re-evaluated. Let me explain.

There are several challenges with the above approach to setup a ssh bastion host server. They are discussed below.

1. Destruction of the Zero-Trust model

Most companies do not limit network access from bastion servers. Once users login to bastion servers, they can reach any servers in the networks without restriction. SSH tunneling / port-forwarding is widely used and may be used as a backdoor to bypassing security controls. This breaks the fundamental tenets of zero-trust, only allowing users or services access to only the resources needed.

Another element of zero-trust is the ability to provide access only to authorized users, to resources needed only for the duration needed. This relies on contextual control over access to applications, servers or resources based on Identity, location, time, OS per application. Current approaches do not support context-based access.

2. Complex key-pair management

Key-pair are commonly used in SSH authentication. Key rotation every 3 months is highly recommended for best practices. The typical setup of a SSH bastion host server doubles complexity. It requires managing access between the client and the bastion server and between the bastion server and other resources.

  1. For each client/laptop to access the bastion server, a key pair needs to be issued and managed for each client, and the keys need to be rotated periodically. For each server to be accessed from a bastion server, a key pair needs to be issued for each server. The keys also need to be periodically rotated. If the account is shared between multiple users or services that key must also be shared among those users and services.
  2. In the case where each user or service has a unique account, a key pair needs to be issued for each server per user, and the keys need to be periodically rotated.
  3. In all these cases, the number of key-pairs that need to be managed can grow significantly. This also means that as users change roles or services are changed there is a greater likelihood of key proliferation. That in turn becomes a threat vector that can be exploited, creating a security gap and increasing risk.

In addition, there is the management overhead of creating, allocating and managing keys across users that include contractors and third parties.

3. Inability to control data access

Most current implementations of SSH do not provide security controls over data. They do not provide the ability to restrict or allow access to files or control operations performed, like uploading or downloading. Anyone allowed to SSH to the server could easily use secure copy protocol (SCP) to transfer files without additional control.

4. Lack of visibility and an audit trail for compliance

Most legacy approaches and the way organizations set up SSH bastion host servers eliminates the ability to record and replay the interaction between user and resources. The inability to record translates to an inability to replay the session for troubleshooting or incident response. The only option is to rely on meta-data or logs collected on a security information and event management (SIEM) systems. However, critical information can potentially get buried in the oceans of data that SIEMs consolidate.

11

The Alternative to SSH Bastion Server

Securing cloud access with a zero-trust architecture requires the following capabilities

  1. Precision network control over servers that users could access. Traditional network-based approaches have been proven to be wide open and unable to protect cloud applications.
  2. Monitor and control identities used to login into SSH and other cloud applications.
  3. Control and monitor data access, crown jewels of any enterprise.
  4. Visibility with application context based on application attributes and user context.

CTA: Appaegis provides an alternative solution to secure access to and setup a SSH bastion host server. Appaegis Access Fabric integrates cloud IAM, key vaults, and application context to better secure SSH and other cloud applications. The user simply logs into an SSH session through an existing identity provider (IdP). Learn more.