What is identity-as-a-service and why should you care?

This is the first in a three-part series on identity-as-a-service, Zero Trust, and security-in-depth.  

The cloud is no longer novel, and thanks to COVID-19 neither is a remote workforce. Therefore, the on-premises world has had to adapt to a distributed workforce in which the cloud generally plays a big role. But this hasn’t happened overnight — it’s been an evolution.

Organizations have typically leveraged either virtual private networks (VPN) or remote desktop sharing (RDS) to connect remote users. They’re quite different, and both have varying limitations in security. Essentially, VPNs allow users to access secure networks, whereas RDS grants remote access to a specific computer. Useful and encrypted, yes — but also open-ended and inherently unsecure.

VPN grants an authenticated user access to a secure network, but that is where security ends. Key features are lacking:  VPNs have limited access controls, no credential management, and no session monitoring. Most VPNs also don’t provide any type of status verification, for example, employment verification.  So, while a VPN can establish access, it does so with considerable risk. Credential protection simply isn’t built into VPNs — meaning password protection is a separate exercise. Nor do VPNs monitor activity across the network, which is particularly problematic if there is any kind of incident.

RDS, on the other hand, is a different way to remotely access a desktop computer.  There are remote desktop solutions that use a variety of protocols, such as independent computing architecture (ICA) or virtual network computing (VNC), but RDS is the most common.

RDS uses remote desktop protocol, or RDP, to establish the connection between the user and the remote desktop. RDP provides an encrypted tunnel — much like a VPN — and what occurs is the “takeover” by the remote user of the target desktop. Therein lies the risk, and it’s really no different than the risk in VPN: no access control (once you’re in, you’re in), no identity management, and minimal session monitoring.

These risks aren’t new, and identify and access management (IAM) is the means by which organizations authenticate that users are who they claim to be and that they have the right to access specific applications, resources, and services. IAM and directory services work hand-in-hand:  While a directory is a place where you store information about users, IAM is how you populate and manage that directory.

<>How DaaS/IDaaS can help minimize risk

So, you will typically front-end your RDS or VPN with some form of IAM. In some cases, this IAM comes with a particular workload or application — the best example being Azure Active Directory (AAD). While IT administrators can manage Office users on-premises, AAD makes this process more streamlined and automated. This is how IAM and directory services are essentially blended into a software-as-a-service, known as directory-as-a-service (DaaS) or more commonly identity-as-a-service (IDaaS).

Using IDaaS, organizations would have their users sign in to a web-based identity and access management service with their corporate credentials and then be able to access SaaS apps such as Zoom or Microsoft 365 over the internet. Since virtually all organizations live in a hybrid world, remote access to on-premises applications would still require either VPN, RDS, or similar access. By using a proxy, the IDaaS solution could provide security to those connection requests as well.

With both SaaS and non-SaaS applications needing access, the notion of leveraging proxies became a unifying option. Solutions like Symantec Secure Access Cloud grant the user access to only the proxy-published application instead of the broad network access granted by a VPN. Because traffic is routed through Symantec’s IAM service, the session can have sophisticated access controls such as device integrity, session risk, or type of client app used.

Yet there was still a chasm — and the proliferation of remote workers demonstrated that unification would be a significant solution. We’ll look at this issue in our next blog and how a new strategy called Zero Trust could provide a better alternative.

In the meantime, look at Barracuda’s CloudGen Access solution. This is an example of simplified, streamlined Zero Trust as a more secure approach to the challenges of remote access.

This is the first in a three-part weekly series on security-in-depth.