We all appreciate that a Zero Standing Privileges model is the best approach when it comes to privileged access – if a compromised account doesn’t have standing privileges, then the attacker is limited in what they can do. But the reality for many organisations is that there are still shared accounts with elevated privileges that have to be used in some situations – can you really operate a Linux server without using the root account?
This article looks at how you can provide for both zero standing privileges for individuals, plus shared accounts, with the appropriate controls to minimise risk using Okta Privileged Access.
User Access Methods in Okta Privileged Access
When it comes to Okta Privileged Access (OktaPA) allowing connections to servers, there are three user access methods that can be applied: JIT individual accounts, JIT elevated individual accounts, vaulted password accounts.
Just-in-Time (JIT) Individual Accounts
Policies can be defined to allow a user to connect to a server with their individual account. For example, david.edwards@company.com in Okta, would access a server as david.edwards after authenticating to Okta.
By default this account is provisioned to the server just as the user needs it (JIT or just in time), i.e. when making the SSH/RDP connection from their client. When the session ends, the account is removed from the server. (Note that there is an option to make the accounts persistent).
These are ordinary users without any elevated privileges. This approach is very useful when you want to implement a passwordless access to servers for ordinary users – the SSH/RDP connections use ephemeral credentials that the user never sees.
JIT Elevated Individual Accounts
Users, via policy, can be flagged with admin-level access. This is the same as the JIT individual accounts, but on a Linux server they can perform any sudo command and on a Windows server they are added to the Windows local administrators group.
These are effectively system administrators, but with JIT – they only have the elevated privileges whilst they are connected to the server. This approach means that the need to use shared privileged accounts is reduced.
Vaulted Password Accounts
The third category is the shared accounts, such as root, System Administrator, DBA accounts etc. Often they are provided by the OS or service and are needed for specific functions.
OktaPA can discover all local accounts on a managed server and an administrator can flag them to be managed in the vault. This means OktaPA takes over the password for these accounts, rotates them so no-one else knows it and will use them to access the servers.
No-one see’s the passwords for these vaulted password accounts – they are injected into the SSH/RDP connection by the client. There is no check-out/check-in mechanism for them.
Controls in Okta Privileged Access
There are a number of controls that can reduce the attack surface and thus risk for server access Some are always applied and some optionally applied through policy.
Ephemeral Credentials or Rotated Passwords
Where the individual account is used to connect to servers a passwordless mechanism is used. OktaPA mints short-lived certificates for the SSH/RDP connections. Use of ephemeral certificates is a lower-risk approach than traditional passwords or ssh-keys that can be shared and don’t have a time limit. Other security controls are layered over the use of certificates that won’t be discussed here.
Where vaulted password accounts are used, we still rely on password-based connections. However OktaPA is the owner of the password – no-one else knows the password and you need to use the OktaPA client to get and use the password. You cannot “check-out” the password and see it. The password is periodically rotated. OktaPA is also continually checking the password is still valid and if it detects an out-of-band change, it will rotate it again and write an event to the Okta System Log.
Entitlement Through Groups, Roles and Policies
At a course-grained level, for a user to be able to connect to a server, they need to be in a group that is assigned to a policy in OktaPA. The mechanism for this is to use Okta Groups pushed from Okta Workforce Identity Cloud (WIC) to OktaPA and assigned to policies. These groups and their membership can then be managed using the normal controls in Okta WIC, which may include using Okta Identity Governance to provide access requests, access certification and reporting of users in the OktaPA groups.
The administrative model in OktaPA is very flexible and supports a delegated administration model and flexible policy assignment, so you can limit access to polices and to resources to the minimum needed users.
Network Routing and Session Recording
There is a policy flag to route all server connection traffic through a gateway. This network proxying capability means that network firewall rules can be implemented to only allow traffic to servers via the gateways. Also, the RDP connection is running through an OktaPA-initiated SSH tunnel and RDP sessions are not initiated from the client, so external RDP access could be restricted (you may need to retain it for break-glass scenarios).
The gateway can also perform session recording for SSH and RDP sessions. This is another policy option.
Per-connection MFA
User access to anything in OktaPA is controlled by the Okta (WIC) Authentication Policies applied to the Okta Privileged Access application in Okta (the same as any other SaaS app in Okta). This can include requiring multi-factor authentication to establish the session with OktaPA.
But there is also a policy setting to allow MFA on specific resources. You can require either any two factor types or a phishing resistant factor (like Okta Verify). And you can require it for every connection or only after a specified duration.
Many security standard call for “per-connection” or “per-server” MFA.
Access Requests for Server Access
Another control that can be applied (in policy) to server access is to require approval prior to being able to access the server. This leverages Okta Access Requests (in a restricted-use form of the component shipped with Okta Identity Governance).
A request flow (called a Request Type) is built in Okta Access Requests to get approval before OktaPA will allow access to a server. For example it may require the users manager or the service owners approval before proceeding. The OktaPA client raises the request for the user and the user retries the connection when the request is approved.
These controls can be added to policies to support different levels of risk, which we will look at in an example in the next section.
Example Implementation with Different Access Methods and Controls
Lets say a company wants to implement server access controls to their Linux server farm.
They want to allow ordinary users to access some servers with their own personal (no elevated privileges) account, but do so in a passwordless way and leverage normal Okta authentication as they do for SaaS apps.
They also want to minimise the use of shared accounts (like root) by providing JIT elevation to a root level of access rather than sharing the password around for the root account. They want passwordless access with elevated privileges, but due to the risk they want MFA applied to the user access and session recording applied.
Finally, there are times where the root account is needed, so they want a way to use the root account without worrying about passwords. But again due to the risk, they want the user’s manager to approve the request and session recording enabled.
What Does the User See?
In OktaPA we have implemented these requirements through policy assigned to the Linux servers. When they use the OktaPA client to connect to a server they are presented with the following options:
There are three options matching the requirements:
- The user can connect via SSH using their individual account (larry.linuxadmin). This is a low-risk access, so there are no additional controls other than requiring the access to be routed via a Gateway (for network security)
- The user can connect via SSH using their individual account but elevated to admin level. As this is a riskier activity, the session is routed via a gateway, has session recording enabled and requires MFA.
- The user can connect as the root account via SSH, which will use the root password stored in the vault. As this is also a riskier activity, the connection requires approval and is also routed through the gateway with session recording enabled.
If the user selects option 2, they are prompted for MFA (in this case a push notification to Okta Verify running on a phone) and then is connected to the server as themselves. They can then run any sudo command without requiring a password (the user doesn’t have a password for the account provisioned by the OktaPA agent).
This is because they are in the sft-admin group (a special group managed by the OktaPA agent) which has a sudoers.d rule assigned to allow any command without a password. On a windows server, a similar elevated access policy adds the user to the local Windows Administrators group.
If the user selects option 3, they get notification that an access request is raised and the command ends.
Their manager (or whomever is defined in the access request approval step) will get an email notification (or Slack/Teams notification if that’s integrated) telling them that there’s an access request for them to review.
They can see the details of the request.
They can approve (or deny) the request.
Once approved, the user can retry their server connection.
The Approval condition is now met and they can connect.
Again they do not see the password. But they are logged directly in as root.
How is this Implemented in Okta Privileged Access?
Like everything in OktaPA, these requirements are implemented as resource groups and policies. From a Resource Group perspective, the root user is flagged as managed for the servers.
There is a single policy for the server access with three different rules to define the three user access methods.
- The SSH with root rule is granting access to the shared/managed root account with the conditionals of Access Request and Gateway with Session Recording.
- The SSH with Elevated Principal rule is granting access to the principal (individual) account but elevating access. It has the conditions of MFA and Gateway with Session Recording.
- The SSH with Principal rule is granting access to the principal (individual) account with no elevation, It only requires routing via the gateway.
When a user attempts to access a server, the client gets the OktaPA service to evaluate all policies that apply to that user and that server and presents the user access methods.
The individual policy settings for Gateway/Session Recording, pre-connection MFA and Access Request were shown in the earlier sections describing the controls.
These policy rules are in the one policy, thus applying to the same principals. But you could have them across different policies so that different groups of users see different options based on their needs.
Conclusion
With General Availability of Okta Privileged Access there are different access methods to allow users to access servers. They can access with a just-in-time provisioned individual account, with user-level or admin-level privileges. Or they can use vaulted and managed, shared accounts. Okta Privileged Access offers a number of policy settings to control how a user accesses a server, including requiring additional MFA, session recording and access approval via Access Requests.
The combinations of these give organisations the means to implement the appropriate mix of Zero Standing Privilege access and access to servers via shared accounts to suit their risk posture. All in a framework that means users never see or know passwords.