Over the past few months, Okta has made considerable progress in our quest to deliver zero standing privileges to administrators of the Okta Platform.
As we discussed in Part 1 of this blog series, Zero Standing Privileges takes the concept of “least privilege” access to the nth degree. We aim to deliver an operating model in which no interactive (human) user account has ongoing, permanent access to highly privileged administrative roles or permissions, which are instead granted on a just-in-time, time-bound basis when required.
This model of access dramatically reduces the attack surface for an organization. In the rare circumstance that an attacker gains unauthorized access to a user or service account, their ability to abuse this access is greatly diminished.
Today, the permissions in many administrative accounts tend to exist by inertia: a role was required for a given task at some point in time, but there has been no driver (or governance) in place to pare the permissions back to what the account requires on an ongoing basis.
As we’ve previously written, the first step toward zero standing privileges is to identify the use cases your organization has for highly privileged roles. Some use cases, such as break glass accounts, require standing privileges. In other cases, a user performs an administrative task so frequently that it’s impractical to ask them to request permission every time they do it.
However, if a permission is (a) attractive to an attacker and (b) rarely required and used intermittently, that is an ideal candidate for a custom admin role that is only available on a Just-in-Time (JIT), time-bound basis via Okta’s ability to govern Okta admin roles. (NB: The ability to govern Okta admin roles is a new capability, available to all Okta Workforce customers: talk to your Account Exec if you can’t find it in the console!)
As a first step, Okta created specific permissions for several such tasks or “jobs to be done” so that they can be assigned to a role.
The use of specific permissions to create custom admin roles can dramatically reduce the number of accounts with standing access to highly privileged permissions.
The next step is to use Okta’s governance features to restrict those rarely used and highly privileged permissions to an access request flow. Using these features, an administrative user must request and be approved via dual authorization to perform tasks that require a privileged permission. Once approved, the user can only use the permission for a set period of time before their account reverts to its standing role.
In this post, we’ll cover the first step in the process: identifying permissions that help to reduce the use of the most privileged role in Okta, the Super Administrator role.
The ability to create or modify a third party identity provider fits squarely into the category of a highly-privileged and intermittent administrative task. Until recently, this task required an account with a Super Administrator or Org Administrator role.
So this task makes an ideal candidate use case for governing Okta admin roles. It’s especially prudent to lock down this permission given adversarial interest in abusing trust relationships for impersonating users in downstream applications.
We recommend creating a custom admin role scoped to the Manage Identity Providers permission (okta.identityProviders.manage) that is available on a JIT basis, subject to approval workflows, and which expires after a few hours.
Further, it’s good practice to turn on protected actions to ensure that any Identity Provider lifecycle event (adding or modifying identity providers) will first trigger a step-up authentication challenge.
After initial setup of an Okta Org, administrators should not need to create or modify new directory agents frequently. If your org has enabled auto-updates for AD agents or LDAP agents, there is limited agent maintenance required via the Okta Admin Console or Management APIs.
Creating or modifying agents has historically required an account with the Super Administrator role.
You can avoid using Super Administrator by:
Creating a custom admin role scoped to the Manage Agent permission (okta.agents.manage),
Creating an Access Request flow that provides this role on a JIT basis, subject to approval workflows, and which expires after a few hours,
Assign a group of trusted administrators to request and approve this access.
Important: if you still use Active Directory, you reduce the number of service accounts that use the Super Administrator role (by at least 1!) by simply upgrading to Version 3.18 of the AD Agent. From Version 3.18, the AD Agent uses OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) to communicate with Okta, and is no longer bound to a specific administrative user account.
Okta’s no-code automation tool, Workflows, is a powerful application and an addictive administrative experience for administrators that want to automate identity-related operations without writing code. Given the breadth of tasks an administrative user can automate with Workflows, creating and modifying a Workflow historically required the Super Administrator role.
The great news is, you don’t need the Super Admin role for this any longer!
Role-Based Access Control for Workflows (now in Early Access) provides a choice of three distinct roles scoped exclusively to the Workflows app.
Workflows Administrator is assigned within the Okta Admin Console, and provides administration capabilities within Workflows. This role can be requestable using Okta's ability to govern Okta admin roles.
Workflows Connection Manager is a permission assigned within Okta Workflows, and grants the ability to create or modify connections. This is useful for any service accounts required to authorize connections.
Workflows Auditor is a permission assigned within Okta Workflows, that grants “read only” permissions to view everything in Okta Workflows, but no ability to modify anything.
While we’re on the subject, the Authentication Policy for the Workflows app should be at least as strong as what is required for access to the Okta Admin Console.
A least privilege approach to Workflows would be to:
Create and test Workflows in your Preview or Test Org
Once the flow is ready for prime time, export it as a .flow or .folder file
Request JIT access to the Workflows Administrator role using govern Okta admin roles in the production org
Import the .flow or .folder file and configure any required connections
Ensure that your production Workflows app has only been granted the OAuth scopes that your flows require.
Okta Identity Governance provides simple, convenient tools for taking the complexity out of tasks like managing user requests to access applications and running scheduled user access reviews (access certifications) as a layer of governance over that access.
From a security perspective, the ability to create access requests flows and modify their conditions is a fairly privileged affair. Out of the box, an Okta Org has a choice of two roles that can do this:
A user with the Super Administrator role, or
A user with the Access Request Admin role and the Application Admin role for the application the flow provides access to.
Creating a Custom Admin Role for the second option gives you everything you need to create and modify access requests, without the excessive permissions of a Super Administrator.
The one exception to this is if you’re using Access Requests to govern access to Okta Admin Roles, as opposed to user roles in downstream applications. This is where things start to get a bit meta. If as an administrator I have the ability to set the conditions via which a user can request access to a role with administrative permissions, I effectively have the same level of privileges as an administrator that can grant privileges directly. So to create and modify access requests for Okta admin roles, I must be a Super Administrator.
More good news: you also no longer need Super Administrator permissions or Workflows RBAC permissions to simply invoke (run) a Workflow in Okta.
An administrator with lower permissions can invoke (run) a flow using a feature called delegated flows. Using this feature, service desk personnel can be granted permission to start a specific flow using their limited access to the Okta Admin Console, without accessing the Workflows app directly. Service desk personnel won’t be able to modify or even view a flow assigned to them, but they can interact with it under whatever constraints you design. You can probably imagine any number of other use cases for this outside the Service Desk too.
Another way to avoid the use of the Super Administrator role is to embrace API Service Integrations, especially for security use cases.
Using API Service Integrations, access doesn’t require the role of a highly privileged service account created by a user. API Service Integrations access Okta APIs in the context of an application using the OAuth 2.0 Client Credentials flow.
There are several reasons why this delivers a stronger security outcome. Each access token enables the bearer to perform specific actions on specific Okta endpoints, instead of whatever actions are available under a role.
You can generally judge a security vendor’s commitment to least privileges by whether they have an API Service Integration available. We’d like to give a big hat tip to Sysdig, Datadog, Kandji, Palo Alto, Elastic, Wiz and others that made this commitment good and early!
Given Okta’s commitment to least privilege access, an account with Super Administrator permissions is required to view or modify information about other Okta administrators.
As such, the standard Read Only Administrator role in Okta can view information on regular user accounts, but not information (such as assigned role, resource and permissions) about accounts with administrative permissions.
As we mentioned above, third party security providers should use an OAuth-powered API Service Integration, which sets permissions at the application context and does not require a service account. API Service Integrations provide numerous advantages when it comes to reducing the blast radius of a stolen API token, as this blog neatly summarizes.
However, you may have observed other third-party security tools (such as posture management or “ITDR” apps) request that Okta customers create a service account assigned with the Super Administrator role, use this account to create a static API token, and hand over the token to the third-party for ongoing access. This integration pattern often results in over-privileged accounts. And it really doesn’t need to be this way.
If the vendor hasn’t built an API Service Integration and continues to insist on the use of static bearer tokens, you can more likely give the app a custom admin role and avoid using the Super Admin role. You might consider, for example, adding the identity and access management permission (okta.iam.read) to the standard Read Only Administrator role. The IAM permission provides read-only access to roles, resource sets, and admin assignments, without adding unnecessary attack surface.
So we’ve now established that a large number of tasks no longer require the Super Administrator role.
However, we continue to need Super Admin to assign administrative permissions or to modify administrator accounts. That makes the Super Administrator role itself a prime candidate for a time-bound role, available on-demand after more than one other user in a trusted group of administrators approve the access using govern Okta admin roles.
Your next task is to think about what baseline permissions you’ll give to groups of administrators at your organization. What are the tasks they perform so frequently, that it would be impractical to have to go through some form of access request every time? Don’t forget that you can bundle standard roles, custom roles and resources together to create a baseline role best suited to your organization’s structure and risk appetite.
In our next blog on identity governance, we’ll dive deeper into creating access requests using the govern Okta admin roles feature.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。