Context-Based Policy

Overview #

A policy is a collection of one or more statements that enforce fine-grained access control for the users of an organization. Written in the Cedar policy language, policy statements at StrongDM can be written by admins to use user context and actions to determine whether they can perform the actions they’re trying to perform, and insert additional requirements as needed.

Access granted through roles or requests allow you to control who can access resources through StrongDM, but those grants are either allowed or disallowed with no further granularity. Policies augment that basic access and allow you to set up conditions for access or for the use of particular commands on a resource, based on known contextual information about the user, such as their device trust status, their location, the specific action they’re attempting, or the resource they’re attempting it on. You can trigger a policy with this information, and then forbid access or particular actions, ask for justification for the action to be logged, or even require 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
• What contextual situations may cause approval or denial of access
• Whether MFA is required

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.

Use cases #

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.

Core concepts #

All policies are built around what is permitted or forbidden for principals, actions, and resources.

• A principal represents a user in the organization or a role configured in the organization.
• An action represents a specific action the user may perform on a resource.
• A resource represents a configured cluster, database, server, cloud, or other resource that is configured to be accessed via StrongDM by users of the organization.

Allow or Forbid Access by Default #

A key decision to make early on in the configuration of policies for your organization is whether you wish to allow or forbid access by default.

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.

A global access policy is one that allows all users to perform all available actions on any resource to which they have been granted access. A global access policy looks like this:

permit (
  principal,
  action,
  resource
);

Any further policies written add fine-grained access controls to those grants, but by default, the Global Access policy allows all actions against all resources by anyone who has an access grant via a role or request for that resource. Additionally, some of these organizations have a toggle to be able to turn policies off entirely.

New trials organizations and organizations migrating to or setting up an Enterprise organization must 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.

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, go to Policies in the Admin UI, click on the policy in the list, and the Policy Editor tab will open.

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 Creation to learn how to create and structure policy statements.

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 an ever-growing number of specific actions on particular resource types. For example, policy can be enacted for over 180 Postgres database actions, such as Create, Read, Update, and Delete.

To use policy to control resource-specific actions, the following requirements must be met:

• The resource is configured as a resource in StrongDM.
• The resource 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.

PBAC supports combining context-based attributes (for example, users, roles, location, Device Trust, and so forth) to tailor access control to specific scenarios.

For more details on supported resource-specific actions, see the Action area of the Policy Taxonomy section.

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.

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

Get Started Creating Policies #

• To learn how to structure policy statements, see the Policy Creation section.
• To get started in the Policy Editor or try out the builder controls to help acclimate yourself to building policies with Cedar, go to the Admin UI and create a policy in the Policies page.
• To learn more about Cedar to better understand the language used to construct policies, visit the Cedar Documentation.