Multi-factor Authentication

StrongDM supports multi-factor authentication (MFA) to enhance security for the users who log in to your StrongDM organization. Additionally, you may create policies that require users to perform MFA challenges when accessing particular resources.

MFA at StrongDM #

You can integrate a supported MFA provider or use StrongDM’s Time-based One-Time Password (TOTP) implementation to allow users to authenticate to StrongDM with a second authentication factor. This allows you to require users to complete MFA challenges after using their credentials to log in, providing another layer of security beyond just remembering (or storing) credentials. MFA challenges add the requirement that the user have some physical object that proves their identity, such as a device that generates codes on an app.

You may also want to consider implementing MFA challenges when your users access particular resources. Some resource types natively support this, and some do not. StrongDM can add this middle layer of security for any supported resource type. StrongDM can also provide the same benefit to resource types that it does not directly support, through TCP connections. TCP connections do not represent a specific type of resource, but they let you add to StrongDM any resource that can be connected to via TCP, allowing it to be accessed through StrongDM (and enabling MFA challenges to access it, via policies).

Additionally, StrongDM can use policies to prompt for MFA challenges if the user is performing actions that are potentially harmful or meet your specified contextual criteria, using Policy-Based Action Control (PBAC). PBAC is available for a limited but growing number of resource types.

Here is what the user’s authentication flow through StrongDM might look like if MFA challenges are implemented via policy:

At each indicated Potential MFA Challenge point, it is possible for you to trigger an MFA challenge for a user. MFA at login can be set up at an organizational level in the Security Settings. Policies can trigger MFA challenges either when a user attempts to connect to a resource or when actions are taken against the resource (PBAC).

When an MFA challenge occurs as a result of policy evaluation, the action is paused while the challenge occurs. If the action times out and the user must retry, it should then succeed without need for a new challenge.

When applied to the “connect” action, MFA challenges have a timeout period of five minutes (the user has five minutes to answer the prompt) unless further limited by the MFA provider. When the user is connecting to a resource, a new MFA challenge does not occur if the user has connected to the resource in the last minute, preventing excessive prompts during the connection process.

Example Use Cases #

What follows is a set of example use cases for implementing MFA with policies, with links to setup examples for each use case.

• Allow access to one role, and require MFA: You want to allow users in the oncall-dev role to access resources with particular tags, such as env=prod, but require them to complete an MFA challenge prior to access to assist with the prevention of unattended access.
• A delete or update action on Postgres triggers MFA: You want to allow users to delete or update records in a Postgres resource, and require MFA first as a security measure against destructive actions.
• Require MFA if outside of North America: You wish to require MFA if the user’s geolocation appears to be outside of North America, as all of your team members primarily operate there. This should apply to any access or action.
• MFA triggered by location or device trust: Your organization wants to allow all users to access a particular SSH server and wants to trigger MFA (and ask the user to justify their access) if their device trust is low or their location is not in the United States.

Set up Multi-Factor Authentication #

Depending on the use case that best fits your needs, you need to set up an MFA integration with StrongDM. You also may need to write policies that require MFA challenges based on the user involved, the type of resource they are acting against, or the actions they are performing.

Currently, StrongDM supports the following options for MFA providers. Please see one of these guides for the particular information that is required to integrate the provider with StrongDM.

• Duo
• Okta Verify
• Time-based One-time Passwords (TOTP)

Create Policies with MFA Requirements #

Policies can be created in the Admin UI on the Access > Policies page. See the policies documentation for details about policies, how they work, and their usage. This section includes example policy statements that solve for example use cases involving MFA.

Allow access to one role with MFA #

In this example, you want to create a policy statement that allows users in the oncall-dev role to access resources with particular tags, such as env=prod and region=us-east, but requires them to complete an MFA challenge prior to access to assist with the prevention of unattended access.

// Permit users in the specified role to perform actions 
// against resources with particular tags after an MFA prompt
@mfa("")
permit (
  principal in StrongDM::Role::"r-4eda054e645cff2e",
  action in StrongDM::Action::"connect",
  resource
) when {
  (resource.sdm.tags has "env" && resource.sdm.tags["env"] == "prod") && (resource.sdm.tags has "region" && resource.sdm.tags["region"] == "us-east")
};

Require MFA for delete or update actions #

In this example, you want to create a policy statement that allows users to delete or update records in a Postgres resource, but requires MFA first as a security measure against destructive actions.

// Allow delete/update but require MFA
@mfa("")
permit (
  principal,
  action in [SQL::Action::"delete", SQL::Action::"update"],
  resource in StrongDM::Resource::"rs-795ddebe62e00799"
);

Require MFA for location #

In this example, you want to create a policy statement that requires MFA if the user’s location appears to be outside of North America, as all of your team members primarily operate there. This should apply to any access or action, when they try to connect.

// Check location and require MFA if not North America
@mfa("")
permit (
  principal,
  action in StrongDM::Action::"connect",
  resource
) when {
   !(context has location && context.location in Location::Continent::"NA")
};

MFA triggered by device trust #

In this example, you want to create a policy statement that allows all users to access a particular SSH server but triggers MFA (and asks the user to justify their access) if their device trust is low when they try to connect.

// Allow anyone to perform any action on the specified resource as long as their device trust score is not low
permit (
  principal,
  action in StrongDM::Action::"connect",
  resource in StrongDM::Resource::"rs-795ddebe62e00799"
) when {
  context.trust.ok
};

// Allow any user with a low device trust score
// to perform any action on the specified resource 
// if they justify the action and perform an MFA challenge
@mfa("")
@justify("Explain this action; your device trust score is low.")
permit (
  principal,
  action in StrongDM::Action::"connect",
  resource in StrongDM::Resource::"rs-795ddebe62e00799"
) when {
  !context.trust.ok
};

Conclusion #

Using MFA to secure your StrongDM user accounts is a strong step toward securing your infrastructure, but policy-based enforcement takes security a step further. Using policies, you can inject MFA challenges into virtually any part of a user’s resource interaction, and cause them to be triggered by a broad range of events, from a user accessing a particular resource to the user’s contextual situation while they are doing so. With Policy-Based Action Control, the ability to further secure actions against resources becomes even more fine-grained, even to the point of requiring MFA for particular actions.