Context-Based Policy

Last modified on April 8, 2024

What is Context-Based Policy?

With StrongDM, you can control which groups of users have access to which resources, what credentials are being used, and log actions that occur. Policies take this binary “yes or no” access grant much further by allowing you to inject specific conditions into these interactions. With policies, the user’s contextual elements, such as location or device trust, are evaluated in order to make dynamic access decisions. The audit trail of particular actions can also be enhanced by requiring a user to justify an action taken on a resource.

Policy Library

The Policy Library contains a listing and brief description of each policy that has been created in your organization. Clicking the name of any policy, or the Details button, opens the details view for that policy in the Policy Editor tab.

You can define policies to enforce fine-grained access control over pre-assigned grants. To gain access to a resource, a user must be a member of a role that grants that access, or have temporary access via an access request. The policy statements take this further, by conditionally allowing or forbidding that access given certain options.

All organizations have a default policy called Global Access that cannot be modified. The Global Access policy allows access grants defined in StrongDM (such as through roles or temporary grants) to continue to function. Any further policies written add fine-grained access controls to those grants, and allow more fine-grained context to be applied. This context can include items such as the location of the user, device trust status, and others. These signals give the ability to consider more context when allowing resource interactions beyond whether the user has been granted access or not.

Policy Editor

In the Policy Editor tab, you can create policy statements. Each policy can have multiple statements within it. Policy statements either permit or forbid actions based on contextual controls configured in the policy editor. Each policy statement requires the selection of a Who value, which is a specific user or role that is the subject of the statement (or “Any User”). The What value is the specific resource that is the subject of the statement (or “Any Resource”). When the specified user or role attempts to act on the specified resource, the policy is triggered and evaluated.

Permit statements

Permit statements allow user actions to be completed if all of the following are true:

  1. The user’s username or role matches the one set in the Who field of the policy statement.
  2. The resource the user is interacting with matches the one set in the What field.
  3. Any contextual elements set in the When section match the context of the user.
  4. The user completes any further requirements that are configured in the Requires users to section. At least one of these requirements must be set for the permit statement to be valid.
User location

If the Location box is checked, a Country selector appears. Select a country from the list. This policy statement evaluates to true if, in addition to the other options, the user’s location matches the one selected here. The location of a user is based on the public-facing IP address of their client’s authenticated connection to the StrongDM control plane.

This location may be inaccurate if the user’s public internet traffic is being routed through a VPN or proxy. In rare circumstances it may not be possible to determine a client’s geographical location. In that case it will be treated as unknown.

User device trust

This option uses StrongDM’s Device Trust feature, which allows you to integrate device trust scores from an endpoint management software provider (such as CrowdStrike or SentinelOne) into your authentication flow for StrongDM. This feature must be set up and working for this policy option to work.

If the Device trust box is checked, a Status selector appears. Select a device trust status from the list: Low Trust, Exempt, or Unknown. This policy statement evaluates to true if, in addition to the other options, the user’s device trust score matches the one selected here.

Require MFA authentication

This option uses StrongDM’s MFA Authentication feature, which allows you to add Duo or one-time passcodes as a second factor into your authentication flow for StrongDM. This feature must be set up and working for this policy option to work.

When the Authenticate via MFA box is checked, this policy statement evaluates to true if, in addition to the other options, the user successfully completes the MFA prompt that is generated upon their action. The MFA prompt remains valid for five minutes before timing out and denying access, if the user’s client (such as their terminal or database access client) does not time out sooner. Users attempting actions that match this policy are prompted again for MFA if one minute or more has elapsed since their last action against the resource.

Require justification

If the Provide justification box is checked, an optional Prompt text field appears. This policy statement evaluates to true if, in addition to the other options, the user records a text justification for their action here. The Prompt value is shown to the user to provide context for what you wish them to record here, why, or other contextual information that you wish to provide. The value they provide is not assessed in any way, but is logged for later review.

Require approval

This option uses StrongDM’s Approval Workflows feature. Approval workflows provide notification for selected approvers to approve access or actions. You must have an approval workflow set up and working for this policy option to work.

If the Request Approval box is checked, a Workflow selector appears. This policy statement evaluates to true if, in addition to the other options, the user’s action is approved via the selected approval workflow. This is the only item that may occur asynchronously, depending on the approval workflow in question. The approval, once granted, is valid for a pre-set amount of time which defaults to four hours and can be changed in the Admin UI under Settings > Workflows > Policy Requests. During this period of time when the approval is valid, the user may retry the actions they were attempting to take on the resource.

Forbid statements

Forbid statements stop user actions if all of the following are true:

  1. The user’s username or role matches the one set in the Who field of the policy statement.
  2. The resource the user is interacting with matches the one set in the What field.
  3. Any contextual elements set in the When section match the context of the user.
User location

If the Location box is checked, a Country selector appears. You may select a country from the list. This policy statement evaluates to false if the user’s location matches the one selected here. The location of a user is based on the public-facing IP address of their client’s authenticated connection to the StrongDM control plane.

This location may be inaccurate if the user’s public internet traffic is being routed through a VPN or proxy. In rare circumstances it may not be possible to determine a client’s geographical location. In that case it will be treated as unknown.

User device trust

This option uses StrongDM’s Device Trust feature, which allows you to integrate device trust scores from Crowdstrike or Sentinel One into your authentication flow for StrongDM. This feature must be set up and working for this policy option to work.

If the Device trust box is checked, a Status selector appears. You may sekect a device trust status from the list: Low Trust, Exempt, or Unknown. This policy statement evaluates to false if the user’s device trust score matches the one selected here.

Force logout

If the Logout box in the Enforce users to section is checked, an optional Reason text field appears. You may enter a reason to display to the user here. When this option is enabled, if the policy evaluates to false and the action is forbidden, the user is also logged out, with the reason that you define here provided to them.

Use Case Examples

The amount of use cases solvable by policies is large and continually expanding. The policies that are useful to your organization are specific to your situation. Here are a few use case examples that are possible with the current policy options:

Justify and MFA

In this scenario, we would like users in a particular role (Developers) to have access to a production server (ssh-prod-4), but only if they justify their reasoning (why they are performing these actions against a production resource). This justification leaves a log trail that we can use when auditing interactions with these resources at a later date. We would also like them to reauthenticate with MFA, just for us to be certain that it is only an authenticated user performing these actions.

To do this, we would create a policy statement with the following options selected:

  1. Set the Permit/Forbid toggle to Permit.
  2. Select the role we have in mind (Developers) from the Who selector.
  3. Select the resource we have in mind (ssh-prod-4) from the What selector.
  4. Enable Require MFA authentication.
  5. Enable Provide justification, and set the prompt to Why are you performing this action?.
  6. Click Save to save your changes.
Require approval

In this scenario, we would like the user Alice Glick, who is an engineer at our company, to have access to a specific production resource (ssh-prod-4), but only after she requests approval from an engineering manager via one of our approval workflows (Require management approval).

To do this, we would create a policy statement with the following options selected:

  1. Set the Permit/Forbid toggle to Permit.
  2. Select the user “Alice Glick” from the Who selector.
  3. Select the resource we have in mind (ssh-prod-4) from the What selector.
  4. Enable Require approval and choose the relevant workflow (Require management approval) from the selector.
  5. Click Save to save your changes.
Forbid unknown or low trust access

In this scenario, we would like to forbid actions conducted by any user against any resource if their device trust score is too low or if their location is unknown, and force any such user to log out.

  1. Set the Permit/Forbid toggle to Forbid.
  2. Select “Any user” from the Who selector.
  3. Select “Any resource” from the What selector.
  4. Enable the Device Trust option and choose the Status Low Trust.
  5. Enable the Location option and choose Unknown.
  6. Enable the Logout option in the Enforce users to section.
  7. Click Save to save your changes.
Allow low trust access with MFA

In this scenario, we would like to permit access for any user to any resource whose device trust score is low if they proceed to authenticate via MFA and provide justification for their action.

  1. Set the Permit/Forbid toggle to Permit.
  2. Select “Any user” from the Who selector.
  3. Select “Any resource” from the What selector.
  4. Enable the Device Trust option and choose the Status Low Trust.
  5. Enable Require MFA authentication and write in the Action Low device trust detected.
  6. Enable Provide justification, and set the prompt to Why are you performing this action from a device with a low trust score?.

Settings

In the Settings tab, you can alter the name and description of the policy.

Policy Monitor

Each action that is evaluated by policies is logged in the Policy Monitor list that can be found in the Admin UI at Policy > Monitor. Each entry has the following fields:

  • Result: Either allow or deny; the result of the policy assessment for the action(s)
  • Target: Entity targeted by the action
  • Actions: Specific action the user attempted to perform
  • User: Name and email of the StrongDM user who performed the action
  • Timestamp: Time that the policy was triggered for the action

You can click on any item in the list to open the detail view for that item.

Monitor Details

The details view includes the same detail as the list view row, but with some additions. Additional items include:

  • A list of all actions that were evaluated by the policy
  • Information about any requirements met by the user during evaluation, such as providing a justification for their action
  • The user’s IP and location

The details view also includes a Policies tab that lists the policies that affected this interaction.