One of the challenges for remote access technology is providing role-based access to groups and individuals outside of your organization. Their assets are essentially untrusted, and their accounts often fall outside of your control. They are essentially foreign entities that need validation and authentication before any connection or remote session can occur. This typically occurs for vendors and contractors that need remote access into your environment, but there is no directory service or authoritative store that can be established using a connector to manage a user’s identity and associated accounts.

If an organization attempts to provide authentication based on an unmanaged account alone, the risk is typically unacceptable to the business. Organizations customarily create domain accounts for these identities so they can authenticate against the domain, and their account is placed under management. This creates an interesting dilemma. The identity of the user has accounts and credentials that are managed by the organization, but they are not employees of the organization. Your relationship with them is not trusted, and the assets being used by both may not be under your management control for cybersecurity hygiene best practices. Perhaps you have a split management model and only control the account itself. This warrants abstracting technologies like remote access to a higher level using the user’s identity and not just a proxy account in your domain. The question is how to accomplish this goal?

Regardless of how you carve it up, the end user will still need an account to initiate connectivity. Whether you create the account in your domain or not may be a matter of your own security policy rather than the risk itself. The risk manifests itself in the access control, source of the connection, and connection and network connectivity required by the account. For example, does the remote access connection require

In each of these scenarios, the account may be trusted, but the asset (host) may not be trusted unless the device is issued by the organization. For someone like a contractor, remote employee, or vendor, odds are that the device is managed by someone else and validation of threats for the supply chain is an exercise in policy rather than technology. Therefore, the first step is to consider the account used for authentication. It should be under the control of the Identity Governance system and should have a real employee as the owner. Then make sure an account exists to manage a connected device as a potentially high-risk asset. Mitigation should start at the identity level and propagate down to all related accounts and entitlements. An example of an indicator of compromise here might be the ability to measure when more than one account is used by the same identity at the same time.

Remote access technologies can be deployed via the cloud and on premise or built on top of existing tools like VPN and RDP. In order to mitigate identity attack vectors , based on the three-pillar model, organizations should mitigate the risks from the asset and provide connectivity strictly by an account and with a least privilege model.

To accomplish this goal, a remote access solution must be compatible with the roles and privileges in your Identity Governance implementation. This assigns the appropriate account the entitlements to start a remote session only for the appropriate targets. Next, the remote session tool must abstract usage of a resource to the lowest common dominator for risk. This typically is a web browser, and, if a remote access technology can make any and all sessions available through a web browser, then an identity can be abstracted since there is only one connection type available.

This approach to identity-based remote access is only found in vendors that integrate remote access and Identity Governance as a single solution. The goal is to link access from the “external” account to the identity for the user accessing resources. If you are looking for the simplest explanation for this approach, remote access, whether on premise, cloud, or external, should use a governance-based approach for management and control of access in order to mitigate the risks of the connecting asset. There is no way to know what resources have access to that account, especially if the asset connecting is not under your control. It could be a threat actor, trusted individual, untrusted computing device, and other combinations. If you take a governance-based approach, the user is managed by their identity, at a layer above the account, and access is granted by the Identity Governance system and remote access solution working together. A PAM solution can provide an additional layer of control by restricting access to these privileges. In the end, you can always provide an access review for who should have access and can always determine if the activity was appropriate, regardless of source, using a session monitoring tool.