Policies

CipherTrust Manager authorizes operations using an Attribute-Based Access Control (ABAC) model. In ABAC, access control policies are defined by the attributes of the components involved in a request. These components typically include the user, the target resource (such as a cryptographic key), and the request's environment (which encompasses attributes like time of day, source IP address, geographic region, and incoming port).

CipherTrust Manager ABAC system is inspired by XACML and Amazon AWS policies.

An ABAC policy can use the attributes of any of these components to decide if the policy applies to a given request. For example, an ABAC policy could state: "Allow reading Key XYZ, but only at night, if the Key is 'enabled', the user belongs to the 'hr' department and is an admin, and the request originates from the internal port."

ABAC is advantageous as it encompasses other commonly used access control systems, such as Role-Based Access Control (RBAC). RBAC can be implemented using ABAC policies defined in terms of a user's "role" attribute.

CipherTrust Manager ABAC policies are expressed in terms of two resources: Policies and Policy Attachments.

Policy composition

A Policy is composed of:

• a set of actions (i.e. operations)

• a set of targets

• a rule, either "allow" or "deny"

• a set of conditions (optional)

  Conditions can further refine this policy. For example, the policy allow read and write to key ABC and key XYZ could be made more specific with the following cumulative conditions:

  • The key is intended for document signing.

  • The user belongs to the "Signers" group.

  • The request originates from an internal IP address.

Policy attachments

Policies are not enforced on their own; they must be attached to a set of users. This is achieved by creating Policy Attachments.

A Policy Attachment links a single policy to a set of users. This set of users is defined by a matching rule (similar to policy conditions) that is tested against the user information in the API token. For example, policy attachments can match a single user, all users in a specific group, users who have a particular flag in their metadata, or all users. If the principalSelector field in the policy attachment JSON is an empty object ({}), the policy applies to all users.

For example, if the policy described earlier is named "Internal HR Key Usage," it could be enforced by attaching it to users in the HR department. The Policy Attachment would specify:

• Policy: Internal HR Key Usage

• Attached To: Users in the HR department

This might seem confusing because a policy's conditions can also refer to user attributes. For instance, the "Signers" group condition could be moved from the policy to the policy attachment with the same outcome. This overlap is intentional, providing flexibility in how policies are expressed and applied.

Default policies

On launch, CipherTrust Manager is pre-installed with a set of Policies and Policy Attachments, which define a default set of group based access controls. However, admins can add to, revise, or replace these Policies with their own, to implement almost any kind of access control regime.

The default policies enforce the following access control rules:

• The admin user has unrestricted access.

• Members of the admin group have unrestricted access.

• All users can create keys

• Users can perform any operation on keys they created (that is, they "own" the keys).

• Key owners can grant group permissions to their keys.

• Users in the global group can perform most operations on keys that have the global flag set.

Taken together, these policies implement an authorization model that mimics SafeNet KeySecure Classic:

• All Users can create keys, which they "own"

• Users have admin privileges to the keys they own

• Key owners can grant user groups limited usage privileges to their keys

Usage

Policies are powerful primitives. Misconfiguration can lead to locking out all access to CipherTrust Manager. Future enhancements may include pre-defined policy sets for common access control models (like RBAC) and safeguards against irreversible admin lockouts.

Managing login authentication for local users using policies

CipherTrust Manager allows you to create policies to manage local user authentication based on interfaces and client applications. Policies are not enforced automatically; they must be assigned to users or groups via policy attachment.

Interfaces

To create a policy based on interface attributes, use one of the following options for conditions:

• Interface name - specify the path as context.environment.interface.name and specify the required values in the values parameter, for example, "values": ["nae_all_123"].

• Interface port - specify the path as context.environment.interface.port and specify the required values in the values parameter, for example, "values": [1234].

• Interface type - specify the path as context.environment.interface.type and specify the required values in the values parameter, for example, "values": ["nae"]

  CipherTrust Manager supports the following values for Interface type:

  • nae for NAE interface

  • kmip for KMIP interface

  • web for any interface other than NAE and KMIP (for example, UI, API playground, ksctl, direct API requests).

Example - Block users in a group from logging in to Web interface using policies

The web interface type covers login requests from the UI, API playground, ksctl, and direct API requests from external clients. To block a group of users from logging in via the web interface, follow these steps:

Create a policy

First, create a policy. In this example, the policy is named Blocked Web Users.

{
    "name": "Blocked Web Users",
    "effect": "deny",
    "resources": [],
    "actions": [
        "IssueJWT"
    ],
    "conditions": [
        {
            "op": "equals",
            "path": "context.environment.interface.type",
            "values": [
                "web"
            ]
        }
    ]
}

Create a policy attachment

Then, create a policy attachment to apply this policy to users in the "Blocked Web Users" group.

{
  "policy": "id-of-the-policy-from-previous-api",
  "principalSelector": {
        "cust": {
            "groups": ["Blocked Web Users"]
        }
    }
}

Client applications

For policies based on client applications, use the path as context.environment.principal.client_app. Specify the application types in the values parameter (for example, "values": ["nae"]).

• nae

• kmip

Example - Login to nae and kmip interfaces using policies

To allow login to nae and kmip interfaces irrespective of the authentication methods set for the user, perform the following steps:

Create a policy

{
    "name": "Allow Login to NAE/KMIP",
    "effect": "allow",
    "resources": [],
    "actions": [
        "IssueJWT"
    ],
    "conditions": [
        {
            "op": "equals",
            "path": "context.environment.principal.client_app",
            "values": [
                "nae",
                "kmip"
            ]
        }
    ]
}

Create a policy attachment

{
    "policy": "id-of-the-policy-from-previous-api",
    "principalSelector": {}
}