Reduce Risk through Governance for Okta Administrators

In this article we explore the different patterns for associating users with administrative roles and how we can reduce the risk around these using governance. There are multiple articles listing the controls that should be applied to the administrative access in Okta, but this article will focus on the governance controls.

Introduction

Okta administration is based around administrators and administrative roles. There are three patterns we see for allowing users (administrators) to perform administrative functions in Okta.

These are:

1. Individual Assignment – where an Okta user is directly assigned to one or more administrative roles,
2. Group Assignment – where an Okta user is assigned to one or more administrative roles through one or more groups, and
3. Shared Users – where an Okta user is created to be shared by users, and assigned to one or more administrative roles (possibly via groups, but this doesn’t affect the governance approaches).

There are many articles available covering the different controls you should apply to reducing the risk associated with Okta administration, including:

• Seven Ways to Reduce Super Admins in Okta
• Protecting Administrative Sessions in Okta
• Best Practices for Securing Okta Workforce Identity Cloud Admin Accounts

Understandably, there are common controls in all of these articles, including some governance controls we will discuss in the following sections and how they can be applied to the different patterns.

Individual Assignment to Admin Roles

The first approach to having administrators is to assign Okta users directly to administrative roles.

Traditionally in identity management this has been considered a bad practice. You can easily get sprawl leading to over permissioning (“just give me the same access as Joe has”) and may lead to high-privileged orphan accounts if an organisation doesn’t have a solid de-provisioning and access review mechanism.

Okta has a number of mechanisms to reduce the risk of individual assigment:

1. The Administrators UI shows the roles assigned to each user and could be periodically checked to ensure that individual assignment is kept to a minimum and is appropriate,
2. An Admin Roles Report can be run (downloaded as CSV) and reviewed, so could be used as part of a periodic review, and
3. The Govern Admin Roles feature can be used to control the individual assignments

The latter, Govern Admin Roles, is a new feature which allows moving from static to dynamic assignment of users to admin roles. Specific admin roles can be requested, approved and assigned for a limited period of time and then automatically removed. This feature also includes an access certification capability to periodically review assignment to administrative roles. Use of this feature can significantly reduce the standing privileges in an Okta instance. For more information see the following articles:

• A Look at the new Govern Okta Admin Roles feature
• Govern Okta Admin Roles (free version of Okta Identity Governance*)

Use of this feature significantly reduces the risks associated with individual assignment of users to admin roles, and is highly recommended.

Group Assignment to Admin Roles

The second pattern is to use groups, where the groups represent job roles or business roles and are assigned to one or more admin roles. Assigning/unassigning users to/from the groups will grant/revoke administrative access.

This is simpler to administer than individual assignments, but still runs the risk of standing privileges if the group memberships are not effectively managed.

As for the individual assignments you can use the UI and Admin Roles Report to periodically check what groups have access.

The group membership could be managed by Okta Identity Governance (separate license). The Access Requests capability can allow users to request specific group membership with an approval flow and automatic removal after a set time. The Access Certifications capability can be used to periodically review the members of specific groups. This can ensure only the right people get access by following an approval and audited process, for a limited time, and there’s a process to revalidate those that have long-term access.

Shared Users and Admin Roles

A more unique pattern is to have Okta users created for specific administrative functions and potentially shared amongst multiple users. This may be where a specific scoped API token is required, or due to business reasons a shared account needs to be used by all members of a team. These are not ordinary Okta users with access to admin roles, but rather separate Okta users created for specific admin purposes.

These shared users represent a higher risk because they rely on shared credentials – in the worst case they involve sharing a password around a team and that password may not be updated regularly for fear of someone not being able to access it.

To address this concern, a new feature has been added to Okta Privileged Access to manage SaaS service accounts (where service accounts refers to any non-federated account that users access via a username and password). This includes management of Okta shared accounts.

This feature will flag shared accounts, store them in the Okta Privileged Access vault and rotate the password (so only Okta Privileged Access knows the password and this new password is applied to the account in Okta). Policy and rules are then used to determine who can checkout the password for the shared account and under what conditions (such as requiring MFA or a manager approval). When the account is checked back in, the password is again rotated. For more details see Managing and Using Okta Shared Accounts with Okta Privileged Access.

Using this feature can significantly reduce the risk of shared accounts with standing privileges using passwords.

Conclusion

In this article we have looked at the three basic patterns for users getting administrative access in Okta: an individual user assignment to one or more admin roles, an individual user assigned to a group which is assigned to one or more admin roles, and use of a shared account (user) which is assigned to one or more admin roles.

There are multiple articles (linked above) on the controls that should be applied to any administrative access. In addition you can use some governance controls to reduce risk:

1. Periodically review admin role assignment through the Administrator UI and the Admin Roles Report.
2. Use the Govern Okta admin roles feature to move to a dynamically assigned role approach (rather than standing privileges),
3. Use Okta Identity Governance Access Requests and Access Certification to control admin group membership, and/or
4. Use the Okta Service Accounts feature in Okta Privileged Access to vault and regularly rotate the password for shared accounts, with controls around who can access them and how.

Use of these features can reduce the risks associated with administrative access into Okta.