Context-Based Policy

Last modified on June 4, 2024

Overview

Context-based policy is a framework that leverages the Cedar policy language to allow StrongDM admins to define policy statements that control user access to resources.

Access grants let you control who can access resources through StrongDM. Policies augment that basic access and allow you to use known information about the user, such as their device, the action they’re attempting, and the resource they’re attempting it on, in order to forbid certain actions, ask for justification, or even provide further authentication steps.

Policies can specify everything that StrongDM users are permitted or forbidden to do, including who is allowed or denied access, what resources may be accessed, what actions may be performed on resources, when access is permitted or denied (for example, when the user is in a specified geographic location), and whether MFA is required.

Context-based policy is especially useful if you would like to tighten security controls regarding actions taken on production resources, stop potentially compromised devices from accessing resources, and so forth. It can also be of use to prevent particular types of actions, such as dropped tables, while still allowing access otherwise, or if you would like to enhance your audit trail with insights for why a particular action was taken.

Policy

A policy is a collection of one or more policy statements that enforce fine-grained access control for the users of an organization. Written in the Cedar policy language, policy statements declare what is forbidden or permitted for users to do with particular resources.

All policies are built around what is permitted or forbidden for principals, actions, and resources. A principal is a user in the organization or a role configured in the organization. Actions are the actions that the user may perform on a resource. Resources are the configured clusters, databases, servers, clouds, and so forth that are configured for the organization.

Global Access Policy

Some organizations that predate the introduction of policies have a default policy called Global Access that can be modified or removed as desired. This policy allows access grants defined in StrongDM (such as through roles or temporary grants) to continue to function as they did prior to the introduction of policies. Any further policies written add fine-grained access controls to those grants. Additionally, some of these organizations have a toggle to be able to turn policies off entirely.

New trials or enterprise organizations need to either configure policies for their organization as desired or else add a global access policy, so that the lack of policy definition does not stop access grants from working. The default for policies is to deny access if not explicitly granted, so role-based grants do not work if no policies are defined.

A global access policy is a policy in which all principals are allowed to execute all actions against all resources that they have been granted access to. Any further policy you add restricts and constrains that global access. Without a global access policy, the reverse is true; access must be granted explicitly for groups of users to access resources, even when they already have access grants for those resources.

Policy Library

Policies are added and managed in the Admin UI in Access > Policies. The Policy Library is where you can add policies to your organization. It contains a listing and brief description of each policy that has been created in your organization, along with the Settings tab and Policy Editor tab.

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

Clicking either the name or the Details button of any policy in the library opens the details view for that policy in the Policy Editor tab.

From the details view, 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 based upon criteria defined in the policy.

If there are ever policies or policy statements in your library that apply to the same action, they are all assessed together. If there are any forbid statements that evaluate to true for the action, it is forbidden.

Policy Editor

The Policy Editor allows you to create and edit policy statements, and save them to a policy. Each policy can have multiple statements within it. To edit a policy, click on a policy in the Policy Library and then click the Policy Editor tab.

The Policy Editor consists of an editing area for writing policy statements manually and a set of controls for generating policy statements based on your selections. Both areas may be used to build policy statements. You may type policy statements in Cedar syntax directly into the editing area.

You may also use the builder controls for assistance constructing a custom policy statement in the Cedar language. These controls make it easy to designate the policy statement type (either Forbid or Permit); specify principals, resources, and actions; and add more context and requirements for a policy to enforce. After setting context, you may then inject the generated policy statement into the policy.

When policy statements are saved to a policy, the policy enforces them immediately.

Please see Policy Editor to learn how to create policy statements.

Policy Evaluation

A policy is triggered and evaluated any time the specified principals attempt to act on the specified resources under the specified conditions. The following diagram provides a general overview of how policies are evaluated based on the user’s actions.

flowchart LR A(User attempts connection to resource) --> B{<b>Grants Check</b> Access granted by roles? Access granted by temporary grants?} B -->|If yes| C(((<b>Policy Evaluation</b> Check context for Device Trust, IP address, location))) C -->|Deny access| D>Log out or notify user as dictated by policy] style D stroke:red,stroke-width:4px C --> |Allow access| E[Prompt for MFA challenge Prompt for justification as dictated by policy] E --> |If MFA and/or justification conducted and failed| F[Fail] E --> |If MFA and/or justification completed| G([Success]) E --> |If no MFA and/or justification conducted| G[Success] style H stroke:red,stroke-width:4px style I stroke:green,stroke-width:4px F --> H>Deny] G --> I>Allow]

After a user successfully authenticates to their client, they are shown a list of resources that have been made available to them through their roles, or through temporary grants.

When the user connects to a resource and attempts to perform actions on that resource, a policy evaluation occurs:

  • Permission is forbidden for all users, all actions, and all resources by default, which means that policies will need to actively permit user actions on resources.
  • If your organization has a global access policy in place (granting all users the ability to perform all actions on all resources that they have access to) the opposite will be true. Your policies will need to forbid actions that you wish to forbid.
  • If any statement in any policy forbids the user’s action, the action is forbidden, even if there are statements allowing it.
  • If a policy requires a fresh MFA challenge, the user is prompted and then must retry their action within the next five minutes. It will be evaluated again, but it will not trigger another MFA prompt.
  • Policy evaluation may trigger multiple outcomes, including the following:
    • The user is challenged for MFA and must retry.
    • The user justifies their action (to be logged) and the action is completed.
    • The action fails with an error.
    • The user is logged out and the action fails.
    • The action is completed.

Policy Statements

Policy statements either permit or forbid actions. As such, the two kinds of policy statements are Permit statements and Forbid statements.

Permit statements allow specific principals (which are users or roles) to perform specific actions on resources. In contrast, Forbid statements stop principals from performing specific actions on specific resources.

Permit statements

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

  • The user’s username or role matches the principal set in the policy statement.
  • The resource the user is interacting with matches the resource set in the policy statement.
  • Any contextual elements set in the policy statement match the context of the user.
  • The user completes any further requirements that are configured in the policy statement.

Forbid statements

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

  • The user’s username or role matches the principal set in the policy statement.
  • The resource the user is interacting with matches the resource set in the policy statement.
  • Any contextual elements set in the policy statement match the context of the user.

Policy Statement Structure

Every policy statement follows the same general structure, where the policy statement:

  • Begins with the “access” type (permit or forbid)
  • Includes principal for defining “who” is permitted or denied access
  • Includes action for specifying “what” user actions may or may not be performed in StrongDM or on a resource
  • Includes resource for specifying “what” resources the user may or may not access
  • Ends with a semicolon (;)

A Permit statement, for example, looks like this:

permit (
  principal,
  action,
  resource
);

A Forbid statement, for example, looks like this:

forbid (
  principal,
  action,
  resource
);

Within every policy statement are fields for declaring what is permitted or forbidden for principals, actions, and resources.

Principal

The principal field of a policy statement indicates specifically who is permitted or forbidden access. The principal may be a user (person or service account) or a role in the organization, and the principal is set as either the user ID or role ID.

Example:

// user as principal
permit (
  principal == StrongDM::Account::"a-70254fee63ea6fbe",
  action,
  resource
);

// role as principal
permit (
  principal in StrongDM::Role::"r-1caa595464152e78",
  action,
  resource
);

When no principal is specified, the policy statement applies to all principals.

Action

The action field of a policy statement indicates the specific action that a user is permitted or forbidden to perform on the specified resource(s).

In the policy statement, actions are specified by name. For example, the StrongDM action of connecting to a resource is set as StrongDM::Action::"connect", while the action of altering a PostgreSQL database is set as SQL::Action::"alterDatabase".

In the following example, the user is forbidden from altering databases for the specified PostgreSQL resource.

forbid (
  principal == StrongDM::Account::"a-3c931809650c7041",
  action == SQL::Action::"alterDatabase",
  resource == StrongDM::Resource::"rs-521d183862e19e48"
);

When no action is specified, the policy statement applies to all actions.

See Policy Editor for more information and usage examples.

Resource

The resource field of a policy statement indicates the specific resource that a user is permitted or forbidden to access. In a policy statement, a resource is set as the resource ID.

Example:

permit (
  principal,
  action,
  resource == StrongDM::Resource::"rs-28acd881623b7f19"
);

When no resource is specified, the policy statement applies to all resources.

Context

Location context

Policies can forbid or permit access based on the geographical location (country) of a user or resource that the user is attempting to access. Location is specified as an ISO 3166-1 alpha-2 code.

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.

For a Permit statement, if the location is set, the policy statement evaluates to true if, in addition to the other options, the user’s location matches the one specified.

In the example shown, the user is permitted to access the specified resource only when doing so in the United States.

permit (
  principal == StrongDM::Account::"a-12354fee63ea6fbe",
  action,
  resource == StrongDM::Resource::"rs-12324fdc60b00166"
) when {
  context has location && context.location in Location::Country::"US"
};

For a Forbid statement, if the location is set, the policy statement evaluates to false if the user’s location matches the specified country.

For example, the following Forbid statement stops all user access when the user is located in Sweden.

forbid (
  principal,
  action,
  resource
) when {
  context has location && context.location in Location::Country::"SE"
};

If no location context is set, then the policy always permits or denies access, no matter what the user’s location is.

Device Trust context

Policies can be used to require a certain device trust score to either permit or forbid user actions.

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.

When Device Trust context is added to a policy statement and a status value (Low Trust, Exempt, or Unknown) is set, the policy statement evaluates to true if, in addition to the other options, the user’s device trust score matches the one specified.

For example, the following Forbid statement stops user access when the user’s device trust score matches the “Low Trust” status.

forbid (
  principal,
  action,
  resource
) when {
  context.trust.status == "bad"
};

If no Device Trust context is set, then the policy always permits or denies access, no matter what the user’s Device Trust status is.

IP range context

Policies can be used to forbid or permit access based on the IP address of a user’s machine. This IP address is the IP address used to authenticate.

For example, the following Forbid statement denies access when the user’s IP address doesn’t match the specified IP range.

forbid (
  principal,
  action,
  resource
) when {
  !context.network.clientIp.isInRange(ip("1.2.3.0/24"))
};

When the policy statement has no context for IP range, the user’s IP address is not considered during policy evaluation, and the policy always permits or forbids, regardless of the user’s IP address.

Annotations

Annotations are optional constraints that may be added to policy statements. An annotation takes the form @annotationname("value") and is placed at the top of a policy statement, immediately before permit or forbid.

The following table lists all possible annotations. Note that some annotations only have an effect for Permit statements or Forbid statements and as such, they should be used only for those policy statement types.

AnnotationDescriptionValue formatPolicy statement type
@approve(“<WORKFLOW_ID>")Uses Approval Workflows and requires approvers to approve user access or actions; the action is forbidden until access is approvedstringPermit
@disconnect("true")Disconnects the user from the resourcetruthy valueForbid
@error("<REASON>")Overrides the default error message, that the client application may display, that is returned in the protocol response when an operation is forbiddenstringForbid
@justify("<PROMPT>")Requires users to provide justification for their action; justification is logged with the requeststringPermit
@logout("<REASON>")Forcefully logs out users when their action is forbiddenstringForbid
@maxrows("<NUMBER>")Restricts queries to returning no more than a defined number of rowsstringPermit
@mfa("<PROMPT>")Requires users to complete an MFA prompt in order to complete an actionstringPermit
@notify("<VALUE>")Provides a notification message to the user in StrongDM DesktopstringForbid or Permit

Multiple annotations may be added to the same policy statement. For example, the following Permit statement allows all users to perform all actions on the specified resource only when they complete an MFA prompt and provide justification for their action.

@mfa("")
@justify("Please provide a reason to do this.")
permit (
  principal,
  action,
  resource == StrongDM::Resource::"rs-55580513635ae326"
);

Require MFA authentication

You can use policy to require that users complete a multi-factor authentication (MFA) prompt in order to be allowed to complete their action.

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 Multi-Factor Authentication option is added to a policy statement, the 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, when connecting to the resource, one minute or more has elapsed since their last action against the resource.

Require justification

Policies can be used to prompt users to justify their actions, and then log their written explanation.

When a Permit statement includes the Justification option and an optional Prompt value, the policy statement evaluates to true if, in addition to the other options, the user records a text justification for their action. The Prompt value is shown to the user to provide context for what you wish them to record, why, or for other contextual information that you wish to provide. The value they provide is not assessed in any way, but it is logged for later review.

Require approval

Policies also may be used to require approvers to approve user access or actions.

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.

When a Permit statement includes the Workflow Approval option, the 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.

Force logout

A Forbid policy statement may be used to log out the user forcefully if their action is forbidden. An optional reason for the logout may be displayed to the user.

When the Forbid statement includes the Forced logout option with an optional Reason value, the policy evaluates to false, the action is forbidden, the user is logged out, and your defined reason (if set) is provided to the user.

Policy-Based Action Control

Policy-Based Action Control (PBAC) for database actions leverages the Cedar policy language to provide deep visibility and control over database interactions. PBAC analyzes communication protocols at a granular level, detecting and monitoring the content of database queries using defined policies. It enables fine-grained, real-time control over database actions by defining and enforcing detailed access policies.

Policies can specify constraints for over 180 database actions, such as Create, Read, Update, and Delete. PBAC supports combining context-based attributes (for example, users, roles, location, Device Trust, and so forth) to tailor access control to specific scenarios.

PostgreSQL

Postgres/SQL action contol is supported for all Postgres resource types:

  • Aurora PostgreSQL
  • Aurora PostgreSQL (IAM)
  • Azure Database for PostgreSQL
  • Azure PostgreSQL (Managed Identity)
  • Citus
  • CockroachDB
  • Greenplum
  • PostgreSQL
  • PostgreSQL (mTLS)
  • RDS PostgreSQL (IAM)
  • Redshift

To use policy to control actions for PostgreSQL resources, the following requirements must be met:

  • The PostgreSQL database is added as a resource in StrongDM.
  • The database is properly configured and accessible for policy enforcement.
  • You have basic knowledge of the Cedar policy framework, including how to define and implement policies.
  • You can learn to use Cedar syntax to effectively write policies.

Use Cases

Context-based policy provides powerful control over every aspect of user access to resources and utilization of resources.

The number 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 some common use case examples that are possible with the current policy options:

  • Use the device trust score of the user’s device to forbid access if it’s low.
  • Deepen your audit trail by requiring users to justify their actions and log their reason.
  • Allow a user’s action to be permitted only if approved by an approval workflow.
  • Require particular user actions to cause an MFA challenge.
  • Forbid or permit specific database actions for PostgreSQL resources.
  • Further restrict access to sensitive resources.
  • Forbid access based on the location of the user
  • Forbid access based on the resource the user attempts to interact with
  • Prevent any action that’s unknown.
  • Limit a user’s queries to a predefined maximum number of rows.

For more use cases with example policy statements, please see Policy Use Cases.

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 Logs > Policies. 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: Date and time that the policy was triggered for the action

You can click on any item in the list to open the details 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, with a visual map of the location pinned
  • Copy of the user’s queries

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

Top