Simplifying Access to Servers Using Tools You Are Familiar With

Providing privileged access to servers can be challenging, given the requirements to both grant access to authorized IT staff as well as protect against malicious access by adversaries intent on stealing valuable data.

This creates the security dilemma: how to adhere to security best practices while concurrently simplifying access for staff.

These best practices require all access to go through a trusted clean source vs. direct access by the IT administrator from his/her own workstation. Once they are granted access, security needs to ensure their activities can be monitored and, in most cases, recorded to detect any suspicious behavior.

Another best practice is to grant least access and least privilege. In some rare cases, an administrator may need access with a local admin account, but in most cases, access should be granted using a unique account assigned to them with specific privileges to perform their responsibilities.

At the same time, access needs to be made easy for IT staff to get their jobs done most efficiently without trying to bypass security controls.

With Centrify Privileged Access Service 20.5, we believe we have offered a range of choices to the user that simplify access while increasing security:

• Freedom to choose a client: native or web browser
• Freedom to choose an account to log in with: their own, an admin account, or a shared account
• Freedom to choose a connectivity method: through a cloud SaaS service, or an on-premises server gateway

LOTS OF CHOICE

The client selection is often the hardest option to make everyone happy, but a browser-based portal is probably the option that will satisfy the most users. There are many situations where a browser-based interface is simply the easiest, since  it doesn’t require or need anything on the workstation, including network connectivity. This model works extremely well for remote staff or outsourced IT with temporary access.

There are other situations where the IT staff would prefer to use their native remote access client, but the networking required makes the connectivity very difficult without granting the user a VPN connection. Normally there are firewall boundaries around the machines in a data center and in many cases in order to even try to connect by server name, the user would need to do a DNS lookup for the target they’re trying to get to. If their workstation’s native client cannot perform the DNS lookup, then it won’t work even to establish the connection.

With Centrify, our Connector can act as a jump host and offer the unique ability to accept inbound connections, and then find the local systems in order to enable login as well as recording those sessions.

But what if an administrator wants to use a native client to Remote Desktop Protocol (RDP) vs. using a browser? They’re not going to get all the way to the target machine, but we do make it easy to get to the Connector. After logging in there, the user can specify the target machine and the identity they want to use, and can access via a native client.

If the administrator already knows the name of the server, they can get faster/easier/more productive access by using their native client and then to the machine, they just have to authenticate to the Centrify Connector, pass an MFA challenge, and specify the target machine.

The last bit is then to decide which identity they want to use. Do they want to log in as themselves and use their entitlements and privileges? Or do they want to use an Alternate Admin account? Or do they use a vaulted account, such as a shared account or local admin account?

OFFERING ALL CHOICES WITH EQUAL EASE

In the 20.5 release of Centrify Privileged Access Service, we want to remove any/all obstacles to privileged access and make every option available based on the preferences of the administrator so they can enforce the security they need while simplifying the access for IT staff.

Two new features, in particular, are enabling us to offer the most choice in the industry:

1. Using native client by itself in order to access a specific target without having to visit a central portal: usually there is a firewall between the native client and the target system, so we use the Centrify Connector as a jump host to broker the connection for the user to the target. We previously supported this model for SSH connections, now we have added support for RDP connections.
2. We now support Use My Account (UMA): once the user authenticates to our cloud service, they may want to use their own account to get logged into a target machine. Now they can visit the portal and use either a native client as well as their own account to get logged in, or they can use their native client to connect straight through the Centrify Connector with the keyword “me” to get logged in.

We’re also enabling single pane of glass to work really well for both Cloud PAM as well as traditional vault break-glass scenarios. For example, should an IT administrator break glass or just log on as they normally do and use privilege elevation? With permissions they can do that. They don’t need anything on their machine, they can use a browser on a laptop, workstation, or even a tablet or mobile device. And it doesn’t need connectivity to any of the target systems.

In summary, IT staff want to work on servers and other infrastructure in the ways they are used to. If organizations don’t make those privileged access tools available and easy to use, IT staff will find ways around best practices to suit their preferences. With Centrify Privileged Access Service 20.5, there is no longer an excuse for IT staff to circumvent privileged access management: pick your client, pick your network connectivity, pick your identity.

This post was first first published on Blog | Centrify website by DavidMcNeely. You can view it by clicking here