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.
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. 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. |