Why are bastion servers used?

Bastion servers are used for two primary reasons:

• Security. First, by exposing only the bastion on the internet for access, you can focus security monitoring, logging and hardening on a single asset to monitor activity and potential threats. Second, a bastion provides a single source host address to whitelist for ingress to a private network or servers.
• Simplifying access management. Because authorized users must connect through the bastion server to gain access to private resources, the bastion serves as a single access management point to control access. Simply disabling a user’s access to the bastion prevents access to private resources.

How Twingate can improve security and management

Despite the above benefits, there are still some drawbacks to using a bastion server:

• The bastion is still vulnerable to attack. Because the bastion must be made available for direct connections from users, it remains vulnerable to attack from the internet. Despite taking security hardening measures on the host, new vulnerabilities and exploits are common. When they occur, security updates may come after a breach has already happened.
• Access authorization still needs to be coupled to corporate access. Access to the bastion host, typically implemented via SSH key management, can often be difficult to couple to Active Directory or an Identity Provider. This means that authorization to connect to the bastion can fall out of step with the most up to date employee directory information.
• Implementing 2FA is challenging. In contrast to most SaaS applications, which natively support 2FA, usually via an Identity Provider, enforcing 2FA on SSH access is still difficult. Using a bastion server does not solve this authentication blind spot.

Twingate addresses the following downsides:

• Any resource protected by Twingate is completely invisible to and inaccessible from the internet. There is no need for any resource or the Twingate Connector to be globally accessible via the internet. Any traffic Twingate forwards to a private resource is encrypted in-transit from the user’s device to the destination Connector.
• Twingate synchronizes in real-time with your Identity Provider. If an employee does not have an active corporate account, they will not be able to access any resources via Twingate. This guarantees that only active employees can access internal resources regardless of their permission to access the Resource.
• Twingate can apply any SSO policy, including 2FA, to any type of resource. Twingate both acts to authorize network connections for users (OSI Layer 4) and it integrates with your Identity Provider. This allows you to specify which Identity Provider authentication policy should apply when users connect to specific resources without requiring any client or server configuration changes.