User's Guide: Key Metadata Policy

1.0 Introduction

Fortanix Data Security Manager(DSM) supports Key metadata policies that can be set on groups that allow users to configure certain restrictions on "metadata" associated with security objects. Here "metadata" refers to elements of security objects that are not covered by cryptographic policies, for example, custom metadata, description, expiry, and so on. The policy should be able to specify that certain metadata "must be present", "must not be present", or "must be present and have certain value".

2.0 Create/Edit Key Metadata Policy

2.1 Create a Group Level Key Metadata Policy

A group-level Key metadata policy allows you to configure certain restrictions on the "metadata" associated with security objects such as key description, activation, deactivation dates, custom attributes, and so on.

To add a Key metadata policy at the group level:

  1. Go to the detailed view of a group, and in the INFO tab, in the Key metadata policy section, click the ADD POLICY button. Add_key_metadata_policy.png
    Figure 1: Add Key metadata policy for group
  2. Select the following metadata that you want to allow for this group:
    1. Key description: Set the Key description rule as either optional or required by selecting the Optional or Required radio button.
    2. Activation date: Set the Activation date rule as either optional or required by selecting the Optional or Required radio button.
      • If you select the Required radio button, you can set the activation date to a time between ‘x’ (seconds/minutes/hours/days) and ‘y’ (seconds/minutes/hours/days) within the creation of the security object by selecting the optional check box User must specify an activation date within ‘0’ (seconds/minutes/hours/days) and ‘0’ (seconds/minutes/hours/days) of security object’s creation time.Setting_Key_Metadata_Policy.png
        Figure 2: Setting Key metadata policy 
        NOTE

        “x” is the minimum time and “y” is the maximum time within which the security object will be activated. The value of “x” should always be less than “y’.

        For example, the user can specify an activation date between 20 minutes and 10 hours of a security object’s creation time.Activation_date.png
        Figure 3: Activation date
    3. Deactivation date: Set the Deactivation date rule to optional, required, or forbid by selecting the Optional, Required, or Forbid radio button. 
      • If you select the Required radio button, you can set the deactivation date to a time between ‘x’ (seconds/minutes/hours/days) and ‘y’ (seconds/minutes/hours/days) within the creation of the security object by selecting the optional check box User must specify a deactivation date within ‘0’ (seconds/minutes/hours/days) and ‘0’ (seconds/minutes/hours/days) of security object’s creation time.
        NOTE

        “x” is the minimum time and “y” is the maximum time within which the security object will be deactivated. The value of “x” should always be less than “y’.

        For example, the user can specify a deactivation date between 10 hours and 1 day of a security object’s creation time.deactivation_date.png
        Figure 5: Deactivation date
      • If you select the Forbid radio button, you are forbidden from deactivating the key.
    4. Custom Attribute: These are user-defined security object attributes that can be added to the security object’s metadata. The attributes can be configured to be required or you can forbid the user from adding them.Custom_Attribute-Optional_Checkboxes.png
      Figure 6: Custom attribute
      1. Add the attribute name and configure it either as Required or Forbid. For example, consider the attribute name: Country.
        • If you selected the Required radio button, you can optionally select the following options:
          • The value cannot only contain whitespace: If this option is selected, the user must enter attribute values that are not just whitespaces.
          • Restrict value to one of the following values: Selecting this option will restrict the allowed attributes values of the security objects to the ones specified in the field.
            Enter comma-separated values. For example: India, Australia, China,  US, and so on.
      2. Click ADD ATTRIBUTE to configure multiple custom attributes. 

  3. Click SAVE POLICY in the KEY METADATA POLICY window, to save the Key metadata policy.

    save_key_metadata_policy.png
    Figure 8: Save Key metadata policy

2.2 Overriding Key Metadata Policy for Selected Key Types

By default, all types of keys are selected for Key metadata policy: AES, DES3, HMAC, OPAQUE, RSA, DSA, DES, EC, SECRET, CERTIFICATE, and SEED. To override default Key metadata policy for selected key types:

  1. Click the OVERRIDE FOR KEY TYPES button.override_for_keytypes.png
    Figure 9: Override for key types
  2. Select the key types from the drop down menu that should be overridden by the default Key metadata policy. saving_key_data_types.png
    Figure 10: Select key types Select_key_types-2.png
    Figure 11: Overriding Key metadata policy for select key types
  3. To configure the metadata of security objects such as key description, activation date, deactivation date, and custom attribute applicable to the selected key types, refer to Section 2.1.

2.3 Handling Existing Non-Compliant Keys

  • All new keys will be allowed/denied based on the Key metadata policy rules.
  • Any existing keys that are not compliant with the policy will still exist in the group. However, these keys will be marked separately as policy-violating keys. For more information on the conditions applicable to policy-violating keys refer to policy enforcement. Handling_existing_non_compliant_keys.png
    Figure 12: Handling existing non-compliant keys

    When a key metadata policy is created at a group level, there are 3 options provided to handle non-compliant keys.  These options are detailed in the following section:

    1. Accept: Accept non-compliant objects even though they violate the current policy. If this option is selected, you may continue to use existing non-compliant keys, but you may not generate or import new non-compliant objects.
    2. Forbid to use: Forbid any use of non-compliant objects. If this option is selected, you are forbidden from using the non-compliant keys for any operation.
    3. Limit usage: Restrict non-compliant objects so that they may only be used for “process operations” (DECRYPT, UNWRAPKEY, VERIFY, and MACVERIFY) on existing objects which violate these restrictions, but forbid “protect operations” (ENCRYPT, SIGN, WRAPKEY, DERIVEKEY, and MACGENERATE).

3.0 Delete A Group Level Key Metadata Policy

To edit or delete a group level key metadata policy:

  1. Go to the detailed view of a group.
  2. In the INFO tab, under the Key metadata policy section, click the EDIT POLICY button.Edit_Key_Metadata_Policy.png
    Figure 13: Edit group Key metadata policy
  3. Click the DELETE POLICY button, to delete the Key metadata policy.Delete_Key_metadata_policy.png
    Figure 14: Delete group Key metadata policy

Comments

Please sign in to leave a comment.

Was this article helpful?
0 out of 0 found this helpful