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.
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.
The Alternative to SSH Bastion Server
Securing cloud access with a zero-trust architecture requires the following capabilities
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.