One of the sessions that I had the Nordic Infrastructure Conference was about how to provide secure access for users in 2022, which I also wanted to go into more depth here to showcase what kind of options we have and how some of the different vendors provide this capability.
It is important to note that there are a lot of vendors that provide much of the same capabilities, but I will focus on Cloudflare, Citrix and Microsoft and their capabilities in this blog post.
NOTE: You can also view the PPT slides here, but a lot of contexts is in the demos that I showed –> 2022/Secure Access in 2022 at main · nordicinfrastructureconference/2022 (github.com)
There are many vendors such as ZScaler, Palo Alto, Checkpoint which also much of the same capabilities but I did not have time to test their products properly.
Users Groups and Capabilities
When we look at our users in our organization, we can group those into different users’ group and related to what kind of services they need to access.
- Regular End-users: Requires access to LOB applications, Office 365 or SaaS services and sometimes Windows applications delivered either trough locally installed or via some VDI service.
- Developers: Requires much of the same but they want their user experience to be as local and native integrated on the client as possible, and in addition they need access to DevOps tooling like Github, Azure DevOps and perhaps access to services such as Kubernetes.
- Administrators: Requires pretty much the same access, but also other core parts of the network, such as virtualization management, jumphosts or other means of managing the environment.
Now if we group these services together, we can see that much of the services are
- Web based services (both external and internally)
- SaaS services (Cloud based)
- Windows Applications (delivered through VDI)
- TCP/UDP Services (often needed for applications installed locally on end-user’s device
- File services for storage of data like SMB file services.
- Print services
- Jump hosts / Management
Previously much of these services (and access to these) were given using regular VPN clients which provided access to much of these services and was also often required for communication to domain controllers from Windows AD joined devices.
So, in one environment I was working in, we have this case where the customer had different logon mechanisms for cloud based and on-prem services with different MFA mechanisms (including a separate user setup for access to Github)
In addition to having multiple accounts, mfa prompts. I noticed that there were no built-in detection mechanisms to verify the overall health and context of my device that I was logging in from. This of course is a big risk that users can connect to a corporate environment without any “health” checks if you will.
This was also the case with $LAPSUS when they hacked Okta via their subcontractor which allowed them to access Okta internal services via a compromised endpoint that had VPN tunnel active. So, this is what ZTNA tries to solve. It should be noted that ZTNA is not a product or tool, but more an overall security guidelines and principles. Where much of the focus is that you should always verify context/conditions before a user is allowed to get access to service X or application Y.
This by using context such as Identity posture and device posture in combination with other conditions. The posture and attributes should always be monitored to see if there are changes. If an endpoint has been compromised and has a active session to a service, when the machine should be disconnected instantly.
Now it is impossible to provide ZTNA without some set of technologies, and as I said a lot of vendors in the market provide as they say “ZTNA services”. To ensure that they can verify a user, device, attributes, and context before they are allowed access to a service or data. One thing that ZTNA does not consider is that we always need to strive after providing a good user experience to make it as seamless as possible for the end-user.
Now if we start to look at the different vendors, Microsoft has a well-known technology stack, that can solve most of our needs but is difficult for a particular end-user to get access.
Now at the core is Azure Active Directory for Identity Posture and Intune with Defender for Device Context. These products have different anomaly detection mechanisms to verify the health of the user and the device. This information is then processed by Conditional Access which will then determine if you are allowed to access that service.
Then we have a wide range of services that can give the user access to those different services.
- Azure AD = Provides access to web applications that are integrated with Azure AD.
- Azure Application Proxy = Provides access to internal web applications that are published trough an Azure AD Application Proxy Connector. These applications are then available either through MyApps or the Office 365 User Portal.
- Azure Bastion = Bastion is a way to access jump hosts or servers using RDP or SSH. They also recently introduced “Connect to IP” and “Native Client Support” which allows us to use Bastion to connect to a machine using IP address directly and the second part is allowing us to use the native RDP client on our machine in combination with a reverse tunnel trough the Azure Bastion service instead of the web portal. This service is of course an Azure only service but hopefully later it can be also extended to support on-premises workloads.
- AVD / Windows 365 = Provides VDI services to end-users either with a 1:1 setup with Windows 10/11 or multi-session support in Azure. This service is also separate from the other services which means that more portals and clients.
- Azure VPN = Azure VPN as the name implies is an Azure native VPN service and can be used to connect on-prem to Azure, but it also supports a P2S configuration so that clients can connect to the VPN service using their Azure AD credentials. This feature however is limited to Windows. It supports Conditional Access to verify context, but it still opens a full VPN tunnel to the infrastructure.
- Azure Arc = Arc which is Microsoft’s new way of providing hybrid services and capabilities recently also introduced support so that you can connect to any device which has SSH enabled as long at the server is connected to Azure Arc. So, it sets up a reverse tunnel between the device and Arc to handle the traffic.
- Microsoft Tunnel = Tunnel is a VPN service aimed at mobile device, that is built into the Microsoft Defender app for iOS and Android. The VPN service itself runs as a Container but also supports Azure AD based authentication.
NOTE: If you are using Azure Bastion the Connect to IP feature does not work in a hub and spoke architecture yet, because of lack of support for UDR.
Now the positive side of this is that many of these services are using a reverse tunnel, meaning that they are not publicly exposing services or endpoints. (Except Azure VPN and Microsoft Tunnel). It at least reduces the risk that no one can utilize a vulnerability in a product or feature. Also, all these services support Azure AD which means that we can use Conditional Access to do context and compliance checks before someone is allowed access. Not everyone of them does it on a granular level and secondly for Azure VPN for instance, there is no mechanisms to disconnect the user if context changes or Intune finds a risk on the endpoint.
In addition, the VPN setup is a traditional full VPN tunnel, so no app-based VPN access.
However, from and end-user perspective it is cluttered and using different agent/portals. In some cases, the service does not provide SSO natively as well (looking at you AVD and Windows 365)
If you want access to let’s say Azure Arc (which now supports SSH) you can use Azure CLI to SSH into any machine that has the Azure Arc agent installed.
- az ssh arc –vm-name vmname –resource-group resourcegroup –local-user localuser
You can also now use the local RDP client to connect to the Azure Bastion Service as well, which is also available as part of the Azure CLI.
- az network bastion rdp –name “bastion01” –resource-group “resourcegroup” –target-resource-id
So from a user-experience perspective, not a good match at the moment….
And then we have Citrix, which also recently introduced a new service called Citrix Secure Private Access as part of their Citrix Cloud portfolio. As part of Citrix Cloud they also support different iDP providers such as Azure Active Directory, AD or their new Identity mechanism called Adaptive authentication can be used to verify identity posture in combination with endpoint access mechanisms. So, Citrix Cloud is not “limited” to Azure AD.
As secondly as part of Secure Private Access, Citrix can also do device posture checks using their built-in agent called the Citrix Secure Access (surprise! It is the NetScaler Gateway plugin) and for those that are familiar with it, you can do a lot of device checks using that agent, which can now be configured centrally in Citrix Cloud.
For an end-user Citrix Cloud can provide access to pretty much all services through the Workspace App in combination with the Secure Access agent. So it provides a pretty seamless user experience. To make this work you need to have some virtual machine appliances within your own infrastructure to provide connectivity between your infrastructure and Citrix Cloud.
- Citrix Cloud Connector
- Citrix Connector Appliance
These are then used to provide access to the different services internally, where configuration is done using Citrix Secure Private Access. So we can configure session policies to allow traffic to internal TCP ports for instance, as seen in the screenshot below.
So, this allows us to provide per-app based VPN without the need to have a full VPN tunnel to our infrastructure.
Citrix also has Citrix Analytics that can provide session context into what the user is doing in a VDI session, so for instance if they detect abnormal user patterns in a VDI session you can create policies that can disconnect the session.
Citrix also has Secure Browser mechanisms that allows you provide more security control mechanisms on browser sessions (which are becoming more and more difficult with the newer transport protocols)
The only downside I have with Citrix now is there that they should support ingesting security data from 3. party services such as Intune / Defender / Crowdstrike or whatever to check device context before the user is allowed to authenticate.
Lastly, we have Cloudflare, which is historically known for protecting web services and have recently moved more into the end-user ecosystem. The difference between Cloudflare and the others is that they do not have any idP or EDR services, so they are more focused on providing flexibility and integrating with 3. party providers as seen in the screenshot below.
Therefore, Cloudflare provides a lot of options in terms of flexibility. You can also have different identity providers for each application that you publish, therefore you can have one identity provider for internal users and another one for external users. As seen in the screenshot below.
Now unlike Microsoft and Citrix, Cloudflare does not have any VDI service but does provide access to internal services TCP/UDP, SSH/RDP and Web based services using Warp + Cloudflared.
From an end-user perspective you need the Warp agent that connects to Cloudflare networks. Then you need to have the Cloudflared daemon running on internal servers either running on Windows / Linux or as a Container.
The Warp client is built using Wireguard + QUIC so from an end-user perspective provides a lot higher performance compared to the other options.
Now if we look at the different vendors and do a quick summary it will look like this
- Cloudflare: Flexible, but not scalable with management with the tunnels, pretty good user experience.
- Microsoft: So many services, but not good user-experience (and more focused on infrastructure running in Cloud)
- Citrix: Best user-experience but lacking external sources for device context.
While Microsoft is focusing more on pure cloud-based customers, Citrix and Cloudflare supports the different options if you are hybrid / public or on-premises.
It should also be noted when related to external users, most of these services also supports Azure AD B2B w/guest users.
- Azure AD VPN = Supports Azure AD B2B
- Azure Bastion = Supports Azure AD B2B
- Requires local account of machine
- Azure Arc = Supports Azure AD B2B
- Requires local account on machine
- Azure Virtual Desktop = Does not support Azure AD B2B
- Azure AD App Proxy = Supports Azure AD B2B
- Citrix Cloud = Yes using SAML based authentication
- Cloudflare = Yes can use external iDP’s
So I will a bit later to a more in-depth setup on each of these different services, but hopefully this gave you and overview of the different services from these three providers.