Create module access policies to decide which users and scripts can access data encrypted by a cryptographic module.

Before you begin

Role required: sn_kmf.cryptographic_manager or sn_kmf.admin

About this task

Field Encryption supports role-based module access policies and additional configuration options become available with (CLE_Ent) functionality.
  • Configure the specific cryptographic operation in module access policies for cryptographic modules that support symmetric operations. For instance, a user can be enabled to encrypt data but not decrypt data.
  • Set a default module access policy value or according to a cryptographic module.
  • Associate script versions where changes to the script are tracked and invalidate the script policy providing better security for script-type module access policies.
CLE_Ent functionality is available with a paid subscription. Refer to for supported features and options available with each offering. For more information, see Field Encryption Enterprise.
Note: The default behavior of the module access policies (MAPs) is Reject to help prevent any unauthorized access, unless explicitly declared in MAP records.

Procedure

  1. Navigate to All > Key Management > Module Access Policies > All.
    If you don't create a cryptographic module configured for Symmetric Data Encryption/Decryption, an auto-generated module access policy is created and listed in the table.
  2. Select New.
    • Select Specify purpose to choose a Crypto spec and set the Granular operation.When selecting the Specify purpose check box, Cryptographic spec fields are available.
    • With cryptographic specifications for symmetric data encryption/decryption and symmetric wrapping/unwrapping, the Granular operation field is available if you select the Specify purpose check box.

      Granular operation list.

  3. Complete the form.
    Module Access Policies fields
    FieldDescription
    Policy name Enter a name for the policy.
    Crypto module Select the search icon (Search icon.) to select a module.
    Crypto spec Select or create cryptographic specification while generating the module access policy. This field becomes available when the Specify purpose check box is selected.
    Granular operation Select the cryptographic purpose for the cryptographic specification. The values available depend upon the type of cryptographic specification that is selected.

    See for details on crypto purposes.
    Type
    • Scope: Controls access by the application scope.
    • System user: Allows access for system users to crypto modules.
    • Script: Control access by script. See for more information
    • Role: Controls access by user role.
    • Resource Exchange: Control access using the Resource Exchange. See for more information.
    Note: Only Role type is supported with Field Encryption. All other types are available with Field Encryption Enterprise.
    Target Scope Field is visible as an identifier for the Scope type. Refers to the functionality for the policy. Select the applications from the search menu.
    Note: Target scope isn't supported and can only be set with Field Encryption Enterprise
    Target Role Field is visible as an identifier for the Role type. Role to which this policy applies.
    Script Table

    Target Script

    These fields appear when you select Script as the type.

    Field is visible as an identifier for the Script Type. Select a table to which this policy applies. Document to which this policy applies. Select the Table name and then the related document for the policy.

    The first time a script calls a cryptographic module, access to the module is denied, and the developer receives an error. This error gives the module owner the ability to grant or refuse access to the module.

    Resource Exchange:

    • Crypto spec
    • Approval type
    • Target instance host

    These options appear when you select as the type.

    Resource Exchange is supported by both KMF and by when the parent module is column_level_encryption.

    Select the crypto specification, One-time or Recurring, and the URL of the target instance. See for more information.
    Impersonation In role-based module access policies, users can access encrypted data using an impersonation session. When users, such as admins, impersonate other users, such impersonation-enabled module access policies are applied.
    Specify purpose Select to toggle the Cryptographic specification field as an available field for the policy.
    Active Select to activate the policy.
    Result Select one of the following:
    • StrictReject rejects access under all circumstances.
    • Reject rejects users with the Target Role or Target Scope from accessing this cryptographic module unless another policy grants them access.
    • Track to permit access and monitor use of the module.
  4. Select Submit.
    Warning:
    For legacy encryption support users:
    If you're using the non-enterprise version of Field Encryption, you're limited to five modules. If you have exceeded this limit, you receive the following warning:
    This insertion exceeds the number of published modules allowed for Field Encryption entitled with the subscription product. The Enterprise subscription for Field Encryption is required for additional modules. Please reach out to your Account team.
  5. Select the policy name associated with the cryptographic module that you want to examine.
    Using Script type module access policy:

    A module access policy is auto-generated based on the default access setting when the script is run. The module name is preceded with AutoGen-. For example, the Module-TestPolicy module is listed as AutoGen-Module-TestPolicy in the Policy name column.

    The Cryptographic Caller Policy form lists the caller policy that you selected. The Target Scope field specifies the scope of the script attempting to use the module. See for additional information.

    Note: A maximum of five module access policies are permitted with Field Encryption. See for configuration options.