Advantages of Advanced Server Access gateways
This is an Early Access feature. To enable it, contact Okta Support.
You can use Advanced Server Access gateways both as standalone replacements for SSH bastion servers and in conjunction with standard SSH bastions. Advanced Server Access gateways are also used for SSH session capture. See Gateways and bastions for more information on possible combinations and Session capture for more information on SSH session capture.
Some of the advantages that Advanced Server Access gateways offer over traditional SSH bastions are high availability and improved security.
Gateways offer several mechanisms to guarantee high availability, which enables a gateway to provide the functionality of a bastion host without the drawback of a single point of failure. In addition to standard load balancing, gateways come out of the box with several other mechanisms for ensuring that access to your servers is always on, including built-in status checks and some automatic load balancing when multiple gateways are enrolled with the same labels. See High availability for gateways.
Advanced Server Access gateways are more secure than SSH bastions through their design which includes:
Standard SSH connections use some type of secret credentials (such as passwords, keys, or certificates) to connect to servers. While these credentials may be only valid for a short period of time, if a client or edge device is compromised, this can provide an attacker with the opportunity to directly access a target server.
When using Advanced Server Access gateways for your SSH connections, the client never receives any credentials that it can use on its own to directly SSH to a server. Instead, the client receives an encrypted payload that's forwarded to the gateway, which only the gateway can decrypt. The advantages of this approach include:
- A compromised client device never gives an attacker access to any credentials that can be used to directly SSH to the target server.
- Since access must pass through a gateway, it's easier to monitor access attempts using an intrusion detection system (IDS) or other monitoring tools.
Maintaining proper access control can be challenging even when using SSH bastions. In addition to having a record of user access permissions, a record of which bastions can access which servers must also be maintained. The complexity increases when different bastions have different security requirements based on the servers they can access.
Advanced Server Access gateways reduce this complexity using labels. Labels determine which gateways are used to route connections to servers on a project. You can use labels to slice gateways by cloud region, compliance certification, operating system, or any key-value pair that you choose. Provided the labels and label selectors you use on a project are accurate, you can be certain that the gateway used to access a target server will meet your requirements.
For example, consider a data locality requirement that dictates that data must never leave a particular country's borders. In a legacy bastion environment, you'd need to audit all the target servers and the bastion servers to ensure that the only possible ingress to the server goes through a bastion within the country. When you use gateways, you can label the gateways with their operating region (for example, their AWS region). Instead of needing to audit individual servers, you add the region as a gateway selector to the project whose servers require such an access restriction.
Gateways can be powerful tools that you can use to meet compliance requirements, especially when used in combination with Advanced Server Access groups to manage users.
While SSH is a fantastic protocol for securing access to servers, it was designed before the advent of federated identity providers. This resulted in its authorization scheme being centered around machine identity rather than human identity. SSH deals with users on servers, keys, and certificates, rather than organizations, company divisions, and human roles.
This leaves SSH bastions vulnerable to forms of side channel attacks. If a user with sufficient access can modify the configuration of a bastion or target server, they may be able to access target servers in a way that bypasses your identity provider. For example, imagine a scenario where a user with admin access to a server modifies its sshd configuration and installs their public key for unlogged access.
Gateways address this problem by being deeply entwined with Advanced Server Access, rather than being a generic protocol like SSH. To go through a gateway, users must have run the Advanced Server Access client and be authenticated by Okta. This guarantees that all access to your servers behind gateways is guarded by Okta.