Security policy concepts

When creating a security policy, you can configure the following access control features:

Feature Description
Principal Users and groups that are associated with the policy and are granted access to the matched resources. See Okta Privileged Access for more information.
Policy A policy refers to a set of rules or guidelines that dictate how privileged access is managed within an organization. These actions could include accessing sensitive data, making critical configuration changes, or installing software.
Rules Rules within a policy define specific conditions, actions, or restrictions related to the management and usage of privileged accounts. These rules are designed to enforce security best practices, adhere to compliance requirements, and mitigate risks associated with privileged access. 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 accesses 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.

  • Resources using labels

    Select which labels to use and include the servers that match the label when creating a rule. After defining the scope of the servers using labels, you can configure how principals access resources. Principals can access resources by signing in to servers with either an on-demand individual account, a vaulted local account, or both.

  • Resources by name

    Apply the policy to a specific resource; for example, apiserver-prod / pamadmin.

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:

  • System-generated labels: When you add a server to Okta Privileged Access, several system-generated labels are automatically created based on characteristics such as hostname, server type, operating system, AWS, Azure, or Google Cloud Platform account ID.

  • Custom labels: You can configure labels directly in the server agent configuration file (sftd.yaml), which then appears in the Okta Privileged Access console for selection. To add custom labels to the server agent configuration file, see Custom Labels.

    Custom labels may impact server accessibility. Okta recommends using custom labels with caution.

Labels are stored in a key:value pair format to allow more flexibility for teams. 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. For example, a server might have two labels, env:prod and env:test. 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 prefixes 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.

Related topics

Security policy