Policies

CipherTrust Manager uses an Attribute-Based Access Control (ABAC) model to authorize operations. ABAC essentially means that access-control policies can be expressed in terms of the attributes of the things involved in the request. The "things" involved are usually a user, a target (like a "key"), and the "environment" of the request, which includes things like the time, source IP, source geo-region, incoming port, etc.

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

An ABAC policy can use the attributes of any of these things to decide if the policy applies to the request. For example, an ABAC policy can say, "Allow reading Key XYZ, but only at night, if the Key is 'enabled', and if the user is the 'hr' department, and the user is an admin, and the request comes from the internal port".

ABAC is nice because it is a super-set of other commonly used, access control systems, such as Role-Based Access Control (RBAC). RBAC is essentially just ABAC policies defined in terms of the 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)

  The conditions are matching rules, which are tested against the request, to further refine the set of requests a Policy applies to. For example, a simple policy might be: allow read and write to key ABC and key XYZ

  Conditions can further refine this policy:

  • allow read and write to key ABC and key XYZ, under the following conditions:

    • the key is for document signing

    • the user is in the "Signers" group

  • the request is from an internal IP address

Policy attachments

Policies on their own are not enforced. Policies have to be attached to a set of users first. This is done by creating Policy Attachments.

A Policy Attachment refers to a single policy, and set of users. The set of users is expressed as matching rule (sort of like policy conditions) which is tested against the user information contained the API token. For example, policy attachments can match a single user, or all users in a group, or users contain some flag in their metadata, or can match all users.

For example, say I named the Policy above "Internal HR Key Usage". I could enforce that policy by attaching it to users in the HR department. The Policy Attachment would look like:

• Policy: Internal HR Key Usage

• Attached To: Users in the HR department

This is a bit confusing, since the policy's conditions can refer to user attributes as well. For example, I could have moved the "Signers" group condition from the policy to the policy attachment, and have the same effect. This redundancy is intentional: it allows some added flexibility with the expression and application of policies.

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 can do anything

• Members of the "admin" group can do anything

• All users can create keys

• Users may perform any operation on keys they created

• Users can grant group permissions to the keys they created

• Users in the "global" group can perform most operations to keys with 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 currently somewhat dangerous primitives; it is possible to create policies that will lock out all access to CipherTrust Manager. Plans are to provide some canned policy sets for common access control regimes (such as RBAC), and some safety measures to prevent users from applying policies that would lock out admins irreversibly.

Managing login authentication for local users using policies

The CipherTrust Manager allows you to create policies to manage local user authentication based on the parameters of interfaces and client applications. Policies cannot be automatically enforced, you must assign them to a set of users/groups using the policy attachment.

Interfaces

To create a policy, use any of the option:

• 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"]

  The 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

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

Web interface implies the login requests from UI, API playground, ksctl, and any API request from the external clients. To block a set of users from logging to Web interface, perform the following steps:

Create a policy

Let's create a policy with the group name "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

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

Client applications

For client applications, specify the path as context.environment.principal.client_app and specify the required values in the values parameter, for example "values": ["nae"]. The supported values for the values parameter are:

• 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": {}
}