Link Search Menu Expand Document
calendar_month 23-May-24

Remote Employee Access

This chapter describes how to provide access to remote employees using existing corporate assets.

Table of contents

ZTNA vs. Traditional VPN

Thirty years ago, VPNs emerged to connect a few remote employees to applications located on-premises. Trust was assumed, scalability was not an issue, and the threat landscape was relatively small. Now, the threat landscape has become one of the greatest challenges of the IT industry.

While there are still benefits to VPNs, the need to enhance systems to maintain business resilience, network security, and corporate and customer data integrity are essential. Today, VPNs extend network-level privileges to remote users working from home, coffee shops, airports, and other unsecured Wi-Fi locations. Many technologies (NAC, ACLs, VDI, PAM, jump boxes, etc.) have been developed to enhance security, but productivity is impacted due to management overhead, configuration and deployment complexity, and user experience issues that can result in productivity losses and a lowered security profile.

For the modern enterprise, ZTNA (Zero Trust Network Access) has introduced a streamlined and frictionless cloud-secure remote access solution to connect employees, contractors, and third parties to the specific applications and resources they need to be productive while delivering unmatched security, resilience, and scalability.

This section highlights the differences between HPE Aruba Networking ZTNA approach and traditional VPN solutions. It describes benefits of using HPE Aruba Networking SSE to help businesses prosper.

Traditional VPNs

VPNs pose significant security risks by exposing IP addresses, essentially acting as beacons that can be easily detected by potential attackers, thereby creating an exploitable attack surface. Moreover, VPNs extend network access to unknown users and devices, further increasing the attack surface and heightening the risk of unauthorized access. This extension of network access can lead to serious consequences, because it allows users to move laterally within the network, potentially facilitating the spread of malware or unauthorized access to sensitive data. Additionally, VPNs often grant overprivileged access to users, enabling cybercriminals to cause significant damage if a breach occurs due to the lack of segmentation and the unrestricted movement within the network. As described above Traditional VPNs do not implement many of the key principle of Zero Trust.

The following image illustrates the complexity of a traditional VPN.

Legacy VPN

ZTNA

With HPE Aruba Networking SSE the concept of the invisible network is brought to life through inside-out connections, ensuring that applications remain entirely concealed and inaccessible from the internet. This approach shields critical applications from potential cyber threats, rendering them effectively invisible to external attackers. Furthermore, this model emphasizes application access over network access, allowing remote users to interact with authorized applications without requiring their devices or user identities to be placed within the corporate network. By implementing granular, least-privilege access controls, this system ensures that users gain access only to the specific applications they need, minimizing the risk of unauthorized access or data breaches. The use of app-to-user connections introduces inherent application segmentation, eliminating the need for complex network segmentation strategies. This one-to-one connection framework effectively prevents lateral movement within the network by unauthorized users, enhancing overall security posture and safeguarding against potential threats.

The following image shows the reduced complexity, eliminating much of the on-premise DMZ stack, with HPE Aruba Networking SSE.

ZTNA Overview

Posture Checks

The agent can use OSQuery to perform device posturing and collect the data at the endpoint. The posture check can verify that certificates are installed, if the disk is encrypted, the MDM installation status, and more. See Client Device Posture for a full list of supported posture checks.

Posture checks are commonly used in the ZTNA policy for applications that have stricter access requirements, to identity that the device is a corporate asset and meets the security requirements of the organization.

Server-Initiated Flows

Server-initiated flows (SIFs) allow servers and services to initiate sessions to devices that have the Atmos Agent installed. This is useful for privately hosted applications that require server-to-client initiated communication, such as on-premise VoIP applications (receiving a call), patch distribution, and active FTP (sending a file from a server to a client machine). It also allows communication between Atmos Agents for VoIP calls, file shares, or screen share applications.

SIFs assign a static IP to each Atmos Agent from a connector-managed IP pool, which enables the server to reach the client using the IP address.

With this approach, the servers communicate only with the Connector, and the Atmos Agent users communicate only with the cloud as shown in the following SIFs diagram.

SIF Example

HPE Aruba Networking SSE isolates the user from the enterprise network entirely by brokering access to applications. It creates an encrypted connection from the user to the HPE Aruba Networking SSE Cloud and from the HPE Aruba Networking SSE Cloud to the application server. In this way, the user never directly connects to the network, providing more secure access. Axis Cloud assigns these IP addresses only to the client that is policy-authorized to access the application.

SIFs assign a unique IP address to each Atmos Agent in the private network to allow servers to initiate sessions to users with the Atmos Agent and agents to communicate with each other

Key Considerations

  • Users can access as many server-initiated flow applications as needed, but they must use the same connector zone.
  • If a large SIF use case is needed, consider deploying a separate connector for SIFs.
  • Each Connector in the same zone requires a unique IP pool that does not overlap. For example, two connectors in the zone cannot both use 10.50.50.0/24 IP pools.

Active Directory and DNS Application

ZTNA deployments use the DNS application and the Active Directory application. With the DNS application, the real IP address can be returned to a user. Many network administrators enable the DNS application for remote support to allow them to see the real IP address, while the IP is obfuscated for all other users. The Active Directory application allows users to authenticate with Active Directory and access its services. Consider using both of these applications as you develop ZTNA policies.


Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.