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.