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 Components 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: Server rule Secret rule
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`. Note: 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. CAUTION: 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:prod`label 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 Request.
Multifactor authentication	See Multifactor authentication.