These are a set of best practices to secure Okta admin access. Securing administrator access is critical given their elevated access to manage user identities, credentials and application access. Okta recommends organizations augment built-in measures by aligning to the best practices outlined here.
- Okta Admins
Okta recommends organizations augment built-in security measures by aligning with these best practices:
Enforce MFA - We strongly recommend that, at a minimum, all Okta customers employ MFA, especially for all Okta administrators and access to the Okta Admin Console, but also for any other high-risk user groups, such as IT or otherwise defined by the customer. MFA for admin access is enabled by default. Here is how to verify or enable MFA for admin access in Okta Classic or Okta Identity Engine (OIE). You can also verify per-user MFA enrollment with the MFA Enrollment by User report. Consider using Okta’s access testing tool to simulate real-world user requests to access applications, including the Okta Admin Console.
Enforce phishing resistant MFA like Okta FastPass - Phishing resistant authentication provides added security against lost/stolen credentials, Adversary-in-the-middle phishing attacks, and other forms of identity-based attacks. Learn more about how to implement phishing resistant authentication with WebAuthn (FIDO2) and FastPass here. Additionally, Okta recommends that the Okta Admin Console authentication policy require users to be on a registered device by enabling FastPass.
Bind admin sessions to Autonomous System Number (ASN) to block compromised tokens - Enable Admin session binding, which challenges admins to reauthenticate if their session is reused from an IP address with a different ASN.
Minimize admin session lifetime - Admin access should require re-authentication after a brief idle time, and session length should not exceed 12 hours. Learn more about how to configure admin session lifetime and idle time here. Note: NIST AAL Phase 3 recommends admins have a maximum session lifetime of 12 hours and a maximum idle time of 15 minutes before requiring re-authentication. Okta caps these values at 24 hours and 2 hours to ensure no long-lived admin sessions can be used if compromised.
Adopt least-privilege with custom admin roles - Minimize the number of admins and super admins in your tenant, and use custom admin roles to minimally scope the permissions required by admin users to accomplish their privileged tasks. Audit the admins in your org using the Admin role assignment report.
Secure service accounts - Okta does not recommend creating user accounts for the purpose of integrating services to Okta. Use API service integrations when possible and practice frequent client secret rotation. This blog articulates the difference between the two and why OAuth 2.0 client credentials are preferred. For a comprehensive list of API Security best practices, see here.
If a user account must be used for an integration, follow the best practices outlined here. Once a service account is configured, add the account to a group with a Global Session Policy that denies interactive access.
Configure Catch-All Deny Rules - Configure the catch-all (final) rule in any policy to be an explicit deny. All rules are evaluated until a request meets a specific condition. A catch-all deny rule ensures that users cannot fall back to a lower assurance method of sign-in if they do not meet conditions set in policy.
Self-Service password reset - If using passwords for admin or privileged user accounts and the self-service password reset feature, make sure to require additional verification factors (OIE). A more detailed description of how to set up Self-Service password reset can be found here. Alternatively, disable self-service password reset and require an Okta Admin to perform resets following an internal procedure with identity verification.
MFA enrollment policies - Configure enrollment policies to require strong factors, not optional. Consider restricting additional factor enrollment, especially in cases where Okta user dashboard access policy has an assurance level lower than other sensitive apps.
Regularly review logins to the Okta Admin Console - Look for unusual access and login context for access to the admin console, such as access at unusual times or new IP addresses outside of expected ranges. Use the following System Log query to identify anomalous logins to the Admin Console: eventType eq "user.session.access_admin_app". See this article for more detections.
Enable ThreatInsight - Okta ThreatInsight evaluates Okta sign-in attempts for potentially suspicious and malicious activity. Depending on the configured ThreatInsight settings, these sign-ins can be logged or logged and blocked. More information about Okta ThreatInsight can be found in the product documentation here.
Block traffic from non-standard locations - Okta Dynamic Zones can be used to block traffic originating from networks that are not typically used by Okta end users or admins. For example, threat actors heavily use Residential Proxies and anonymizing services like TOR, but these kinds of services are not typically needed by your employees or consumers. More information regarding Okta Dynamic Zones can be found in the documentation here.
For additional details, review the following video:
