Security policy
A security policy controls which principals are granted privileged access to one or more resources. As a security admin, you create a policy, assign principals to the policy, and add one or more rules.
When creating a rule, you can establish specific conditions that users must meet to access a resource that's safeguarded by Okta Privileged Access. These rules can be customized for different resources by stacking or adding them until they cover all the privileged access needed for the set of principals. By doing this, you can set different controls over different resources to ensure that only authorized users can access them.
You can assign security administration to groups assigned as delegated security administrators. The delegated security admins can create policies that apply to resource groups for which they're the security owners. Security policies written by delegated security administrators will only apply to the resource group they selected when crafting the policy. See Add a delegated security admin.
Security policy configuration options
When creating a security policy the following access control features can be configured:
| Features | Description |
|---|---|
| Principal | Users and groups that are associated with the policy and are granted access to the matched resources. See Components for more information. |
| Rules |
A rule is used to define the scope of resources and how privileged access is granted to the resources. Each security policy contains a rule that defines the resources and privileges available to each principal. Security admins and delegated security admins can create the following rules:
|
| Session type | This is how users access resources. Session type can be SSH or RDP. |
| Resources |
Privileged access to resources are based on the policy created by the security admin or delegated security admin. You can configure the scope of access to resources using the following methods.
Root SSH login is disabled by default on most Linux installations. |
|
Labels |
You can apply labels to individual servers. These labels allow Okta Privileged Access teams to categorize and sort server access. There are two types of labels:
Labels are stored in a key:value pair format to allow more flexibility for teams. For example, a server might have two labels, env:prod and env:test. Labels can originate from within the system or through the sftd configuration file. Okta Privileged Access automatically adds a prefix to identify the source of the label. If the env:prodlabel originated from Okta Privileged Access, the system prefix looks like the following: system.env:prod. Likewise, if the env:test label originated from the sftd configuration file, the sftd prefix look like the following: sftd.env:test. This avoids conflicts if the same label is added from multiple sources, which can happen if a label is specified by both the system and the server agent configuration file. |
| Session recording | See Session recording. |
| Approval request | See Okta Privileged Access with Access Requests |
| Multifactor authentication | See Multifactor authentication. |
Prerequisites
- Ensure that you're signed in to Okta Privileged Access.
- You must have the Okta Privileged Access security admin role or a delegated security admin role.
Create or update a security policy
To create a policy, you need to add a policy name, assign principals, and create rules that apply to the principals. After a policy is created, it must be published. A policy doesn't have any effect until it's published.
- Go to .
- Click Create Policy.
- Enter a policy name and description.
-
Configure the resource group information.
Setting Action All resource groups Select this option to apply the following to all resource groups.
Delegated security admins can't select this option.
Specify a resource group
Select this option to apply the policy to a specific resource group.
- Click .
- Select one or more groups that you want to add or modify, and then click Save.
- Add rule to define the scope of resources and how to grant privileged access to these resources.
You can configure the following rules: Server rule and Secret rule.
- To add a server rule, select .
Setting Action Rule name Enter a rule name Choose a session type Use the dropdown menu and choose a session type. Select the resources that you want to protect with this rule You can select resources by label or by name. Based on your selection, you need to perform other configuration.
Select resources by label
- Toggle the button.
- In the Add resources field, search for and select a resource label. You can select multiple resource labels. See Security policy configuration options to learn more about labels.
Select either one or both options on How you want principals to access the resources.
Access resources by individual account
Access resources by vaulted account
Adding a local account, for example, #pamadmin, means that the #pamadmin account will be available on every server selected based on the labels.
Select resources by name
- Toggle the button to enable it.
- Select one or more accounts individually.
Optional. Enable session recording Okta resource admins must enroll and install a gateway before enabling session recording.
- Select Enable traffic forwarding through gateways.
- Select Record session through gateways.
Optional. Configure approval requests You must create a Request Type in Access Requests first for the access request workflow to be visible in the security policy. See Okta Privileged Access with Access Requests. - Select a workflow from the dropdown menu.
- Choose how long you want the approval to last.
- Optional. Select the setting to rotate the password after the approval duration ends.
For Okta to take control of managing local account passwords on Windows servers, users must disable any password age restrictions that might prevent Okta from changing or rotating the password.
Optional. Enable MFA Enable MFA to add a granular level of authentication and control within a policy.
Toggle Enable MFA.
Select Any two factor types.
Select one of the following re-authentication frequencies:
Every SSH or RDP connection attempt
You can choose to enforce MFA for each attempt to access the resource.
After the specified duration
By default, the specified duration is set to 30 minutes. You can specify a time duration ranging from 5 minutes to 12 hours.
After the policy is implemented, when a user tries to connect with a resource, they'll need to complete the necessary MFA steps.
To add a secret rule, select .
Setting Action Rule name Enter a rule name. Select the secret folder or secret you want to protect with this rule
Click Select secret folder or secret.
Select a secret folder or a secret
Click Save.
Select Permissions
Select the permissions. You must select at least one permission. See Secret permissions for details.
Approval requests
You must create a Request Type in Access Requests first for the access request workflow to be visible in the security policy. See Okta Privileged Access with Access Requests.
Select the approval Request Type.
Choose how long you want the approval to last.
- To add a server rule, select .
- Click Save policy.You can now publish this policy.
Publish a policy
After a policy is created it must be published.
When a published policy is changed, the changes are applied immediately without the need to publish the policy again.
- Go to
- On the policy you want to publish, click Actions.
- Click Publish to grant access to the policy.
Clone a policy
Security admins can clone an existing policy instead of creating an entirely new policy from scratch.
- Go to
- On the policy you want to clone, click Actions.
- Select Clone.
- Click Save Policy.