SSH Bastions Break Your Zero Trust Model

 

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.

 

Appaegis Access Fabric: Zero-Trust Secure SSH Access

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). 

Appaegis Access Fabric links the key vault, IAM, applications, and SIEM together to provide a holistic solution that eliminates security bottlenecks. Appaegis Access Fabric provides granular control over what data can be accessed and what users’ can do with the data. This helps security teams more effectively manage and secure access to critical cloud infrastructure.

 

Copy of Copy of Copy of Product Update January 2022-1

 

Back to Blog

Related Articles

A New Age of Security Built on Zero Trust

Cybersecurity is undergoing an intense metamorphosis. We are in a race to meet the demands of a...

VPNs for a Zero Trust Application Centric Enterprise

VPNs have been around for a long time and were created to allow remote workers secure access to the...

Contextualizing Zero Trust for Data Security

Zero Trust is often used to codify an approach to security.  What it means for each individual...