The Combined Power of Okta Privileged Access and Okta Identity Governance

This article looks at the benefits of combining Okta Privileged Access with Okta Identity Governance to reduce the risk of using privileged accounts and access.

Introduction

Both Okta Privileged Access (OPA) and Okta Identity Governance (OIG) are part of the Okta Workforce Identity Cloud platform (Okta WIC). OIG is focussed on governing identities – having controls to manage who gets access to what and being able to prove it. OPA is focussed on managing access to privileged resources. Together they can provide an effective way to reduce the risk of using privileged accounts in one platform and move to a Zero Standing Privileges model.

Both products leverage shared components in the Okta WIC platform. You can see this in the following figure showing the architecture of OPA.

In addition to the core PAM capabilities built into the OPA cloud tenant (aka “Team”) there are additional capabilities provided by other Okta WIC components through the OPA SKU:

OPA is an application within Okta WIC in the same way that any other SaaS app is. This means the app authentication policies (including MFA) can be applied; it has users assigned (individually or via groups); and groups can be pushed to OPA from the app.
Authenticators (i.e. MFA) defined in Okta WIC can be applied to access policies in OPA, so that when a user goes to access a privileged resource they are prompted for Okta-managed MFA.
All events in OPA are written to the Okta WIC system log along with all other Okta WIC events. Custom reporting can be built around those events, whether they are specific to OPA or across multiple components.
The OIG Access Requests platform has been extended for just-in-time (JIT) approval of OPA access. For example you could have a policy where accessing certain servers with specific accounts requires a manager’s approval. This can be done with OIG Access Requests.
During Oktane24 it was announced that OPA will be able to manage Okta service accounts and SaaS app service accounts (either a supported OIN integration handling automated password rotation or a BYO model for other apps).

In addition to the native capabilities list above, there are scenarios where OIG or Okta Workflows can be used to provide additional controls for Privileged Access Management (PAM). These will be explored in this article.

As a side note, there are PAM scenarios that can be addressed without needing OPA, just capabilities within Okta WIC. For example, privileged access to Amazon Web Services is driven by roles or permission sets chosen when performing single sign on to AWS (and those roles or permission sets grant privileged access). Assignment to those roles or permission sets in Okta can be controlled by group memberships and this can be incorporated into OIG access requests and access certification.

Using Okta Identity Governance to Enhance Okta Privileged Access

Lets have a look at some of the Okta Identity Governance, including lifecycle management and Okta Workflows, capabilities and how they can be used to enhance PAM use cases in OPA.

Just-in-time Access Approval

Okta Privileged Access uses a policy framework to determine who can access privileged resources and how. The “how” can be conditions (such as “traffic must be routed via a gateway”) and/or controls (such as “phishing-resistant MFA” must be used to access this server for this account).

A common control to apply in a policy rule is to require approval. You can define approval flows in the OIG Access Requests platform and initiate a flow when attempting to access a privileged resource.

For example, you may have a security policy whereby accessing production servers by one of the high-risk shared accounts (like root, system admin or DBA accounts) requires the approval of both your manager and the service owner. This flow is implemented in the Access Requests platform and linked to the relevant policy rule.

When a user attempts to access the server a request is raised and their manager notified via email. They can use the Access Requests web UI or one of the chat apps (Slack or Teams) to review the request and approve (or decline).

Thus you can apply governance controls at the time that the user needs to access a privileged resource, supporting the Zero Standing Privileges model. This is functionality included with the OPA product, it does not require additional OIG licenses.

This was explored some time ago in the article Okta Privileged Access and Okta Access Requests. Note that the direct OPA integration still uses the older Request Type mechanism in Access Requests. Migration to the newer Request Catalog (discussed later) is on the roadmap.

Access Requests for OPA Access

Okta Privileged Access has administrative roles to control who can administer OPA and policies to determine access to privileged resources. Both of these are based on groups within OPA. These groups can be pushed from Okta WIC.

This is shown in the following figure. Groups in OPA are attached to policies and roles. These groups can be pushed as Push Groups from Okta WIC like any other SaaS application defined in Okta. These groups could be assigned via Access Request flows (either the older Request Types or the newer Conditions).

Users can request access to these groups via Access Requests and have an approval flow run to allow assignment to the group.

This triggers an access request in the OIG Access Request platform that the manager will review.

This assignment would flow to OPA and grant access to the roles and/or policies for the group.

Access Request flows can also apply timers. You could set flows to only grant access for a short window (like 2 hours) or for a longer period (up to a certain date). Once the timer expires, the user loses group membership and can no longer access the privileged resources.

The earlier example was for JIT approval for resource-specific access. This example provides broader controls to manage who, and when, users have access to admin roles and policies in OPA. Together you can apply a multi-layered approach to access to minimize standing access and have the appropriate risk-based controls tied to that access.

This approach requires both OPA and OIG.

A more in-depth exploration of this can be found in Managing Access in Okta Privileged Access with the new OIG Resource Catalog.

Access Certification for OPA Access

In the previous section we showed how groups in Okta can be pushed to OPA and tied to admin roles and policies to grant access, and the membership of these groups can be requested through OIG Access Requests. In many cases you would assign group membership with a timer so that the access would be automatically removed in a short time.

But how do you provide visibility and control for longer-term access? You can use OIG Access Certification to periodically review group membership that’s granting access in OPA. For example, the following image shows a number of groups assigned to (and pushed to) OPA.

An access certification campaign can be created and launched that reviews the membership of those groups.

When run, the reviewers (such as user managers) can see the groups their people are assigned to and decide whether they need to retain the access or not.

The campaign can be set to automatically remove access once the reviewer clicks the Revoke button.

Combining this with the previous example, you can use OIG to control which OPA groups a user can be assigned to and automatically revoke the access after a set period of time. For the longer term assignments, access certification campaigns can be run to periodically review access and remove them. Combining this with JIT controls (like access approval and MFA) can reduce standing privileges and reduce the risks associated with getting privileged access.

Enhancing the Information Available to Reviewers

There are many scenarios where you can leverage Okta APIs and Okta Workflows to enhance the OPA information available within Okta and OIG.

For example, the following blog articles look at collecting information on group assignments in OPA and putting the information into the group description that can be used by OIG.

You can see the outcome of these in the some of the screenshots above.

We are also working on an example of using the new Entitlement Management feature in OIG to be able to consume and show OPA Policies as entitlement bundles in both Access Requests and Access Certification. Details TBA.

Leveraging Okta Workflows

Okta Workflows is Okta’s no-code integration platform used to implement bespoke processes. It can be a standalone product but also comes as part of the Okta Identity Governance product.

Whilst Okta Workflows isn’t needed for OPA, it can help with bespoke use cases. For example:

Using the OPA Reporting API to generate audit reports on privileged access
Building a migration tool to migrate from Okta Advanced Server Access into OPA
Sending reminders to admins when secrets are due for rotation
Notification on discovery of a new shared account on a server

Okta has published a Workflows Okta Privileged Access Connector that implements many of the OPA APIs and provides a secure (OAuth) authentication mechanism for making the API calls.

See the following articles for examples of using Workflows and the new connector:

Note that Okta Workflows is not included with Okta Privileged Access.

SaaS Service Accounts and OIN Connectors

Okta recently announced support for management of SaaS app service accounts in Okta Privileged Management. It involves synchronisation between Okta WIC and OPA to bring application service accounts under management (and into the OPA Vault).

The mechanism supports two approaches:

An automatic mode where the Okta Integration Network (OIN) integration supports password rotation. When a managed account password is rotated in OPA, the new password is sent to Okta WIC and the OIN integration applies that password to the account in the SaaS app.

A manual (or BYO) mode where there is no integration supporting rotation. When a password for the service account is rotated in OPA, it must be manually updated in the SaaS app.

Where the passwords are rotated, the OIN integrations are used to provide the plumbing – there is no need for OPA-specific integrations or adapters. The number of OIN integrations enabled for password rotation will grow over time and the OIN integrations may be leveraged for other OPA functionality.

Conclusion

In this article we have explored integration patterns between Okta Privileged Access and Okta Identity Governance. Whilst OPA itself can implement many Privileged Access Management scenarios, the addition of OIG can supplement OPA to provide greater control over who gets access to what privileged resources, when and how, leaving to a Zero Standing Privileges model where users only get privileged access when they need it after passing the appropriate controls.

The Combined Power of Okta Privileged Access and Okta Identity Governance

Introduction