Column Level Encryption

Column Level Encryption, formerly Encryption Support, permits and denies access to encrypted data based on user role. Column Level Encryption has been enhanced to include basic key management using encryption modules at no additional charge.

About Column Level Encryption

Note:

Previously configured encryption contexts are automatically converted to encryption modules. Column Level Encryption is a free security enhancement of encryption support. To learn about the encryption options, see Encryption and Key Management subscription bundle.

Implementation of field-level encryption begins with defining one or more encryption modules in your instances of the ServiceNow AI Platform. This process includes selecting an encryption algorithm and providing an appropriate secret key. Access to data later encrypted using the feature is role-based, with modules being associated with roles. Users without the correct role don’t see the field at all. Figure 1 illustrates how role-based encryption functions.

Figure 1. Figure 1 – Role-based encryption example

Here are the results of the relationships in Figure 1:

• User 1 is a member of Role 1, which provides access to encryption module 1. User 1 can see the contents of Field A and Field B.
• User 2 and User 3 are members of Group 1. Group 1 is a member of Role 1, which enables everyone in Group 1 access to encryption module 1 and enables User 2 and User 3 to see the contents of Field A and Field B.
• User 4 isn't a member of any group or role and has no access to encryption module 1. Not only does User 4 not have access to Field A or Field B, but User 4 doesn't even see these fields on a form. On a list view, the values would be empty.

You can implement considerably more complex role-based encryption, as well.

Role-based access also must be implemented appropriately for that field to be accessible to users who are assigned the encryption module via a role.

All customer encryption keys for use with field-level encryption are stored in the same unique instance database where the data encrypted by them is stored. As a further security measure, they're re-encrypted with a secondary key unique for that instance, which mitigates direct access to the encryption key for any encryption module, either by an instance administrator or ServiceNow.

Field-level encrypted data can't be filtered.

Column Level Encryption:

• Access to encrypted data is determined by the user role.
• You can choose the strength of the encryption algorithm: AES-128 or AES-256.
• You can encrypt String text, Date and Date/Time fields, attachments, and URLs.
• Encryption modules provide Equality Preserving encryption.

Column Level Encryption Enterprise supports the following additional features:

• Customer supplied keys.
• Key access allows user sessions with access to both the module and the key to access other back-end or system user processes.
• Script, Resource Exchange, and app access
• Advanced attachment support.
• Application programming interface (API) access is available.
• Order Preserving encryption or standard, non-deterministic encryption isn’t supported.

Standard and Enterprise editions

Column Level Encryption is available in standard and enterprise versions. Column Level Encryption Enterprise is a paid plugin that provides additional features as well as a greater number of modules and module access policies.

Table 1. Column Level Encryption features by version

Column Level Encryption

Column Level Encryption Enterprise

Access to encrypted data is determined by user role Support for up to 5 modules and module access policies (MAP)s AES-128 and AES-256 encryption algorithms Encryption for String text, Date and Date/Time fields, attachments, and URLs. Encryption modules provide Equality Preserving encryption. Updated getDisplayValue() and setDisplayValue() APIs that can return cleartext values and insert encrypted data for encrypted fields

In addition to the features listed to the left, Column Level Encryption Enterprise supports these additional features. Support for greater than 5 modules and module access policies (MAP)s Encryption for additional field types, such as journal, HTML, and translated fields. Configurable automatic key rotation. Customer supplied keys. Manage the full key life cycle of your data encryption keys. Optionally, you can securely exchange data encryption keys generated within your environment. Ephemeral cryptographic keys Updated getValue() and setValue() APIs.

For more information on the enterprise version of this product, see Column Level Encryption Enterprise

Encryption methods

Fields that use Column Level Encryption may include:

• New or existing Encrypted Text fields.
• String, Date, Date/Time, or URL fields included in encrypted the field configuration records.

The Encrypted Field Configurations table [sys_platform_encryption_configuration] contains a record for each field encrypted with Column Level Encryption. This table enables a Security Admin to monitor all fields in the instance that uses Column Level Encryption.

Note:

On upgrade, encrypted field configuration records are created for all existing encrypted text fields. When a new encrypted text field is added, an encrypted field configuration record is created by default.

Encrypted field configurations can encrypt fields using one of the following methods.

Method	Description
Single encryption module	The field is encrypted with the encryption method defined in the encryption module field. Users who don’t have the encrypted module access can't view or update field values.
Multiple encryption modules	The field is encrypted with the encryption module of the first user to enter data into that field. If the user has two or more encryption modules, the module defined in the encryption module selector is used. Because the encryption module is set on a per record basis, fields in a list can have different encryption modules. However, within a single record, the field can be encrypted by only one module. When an Encrypted Text field is created, an encrypted field configuration is created with the multiple encryption modules method. Encrypted Text fields and fields encrypted with the multiple encryption modules method behave the same. Note: Mass encryption isn't available when using the multiple encryption modules method.

Access to encrypted data

An encryption module determines access to encrypted data. Admin users can give an encryption module access policy to a user by giving the user an associated role.

To monitor the assignment of roles, the customer or professional services can set up security measures. For example, an email can be sent to an appointed encryption manager whenever a role associated with an encryption module is granted to a user.

Note:

Impersonation doesn't change the encryption module available to a user. Even while impersonating, you have only the encryption modules available to you originally. This functionality is introduced in Vancouver.

Access level	Data access to a field using the single encryption module method	Data access to a field using the multiple encryption modules method
User with no encryption modules	The form hides the encrypted field. In list view, the field appears empty and can't be edited, even if the data in the field is decrypted.	The form hides the encrypted field. In list view, the field appears empty and can't be edited, even if the data in the field is decrypted.
User with one encryption module	To use the field, the user must have access to the encryption modules defined in the encrypted field configuration. If the user doesn't have access to the encryption modules, the form hides the field. In list view, the field appears empty and can't be edited. If there's no data in the field: If the user has access to the encryption module, the form shows the field (assuming UI policy doesn't prevent it). Users with access to the encryption module can view and update the empty field. Data entered in the field is encrypted with the encryption module defined in the encrypted field configuration. If there's data in the field: If the user has access to the encryption module, the user can view and edit data in the field.	The user automatically uses their encryption modules with the encrypted field. If there's no data in the field: The form shows the field (assuming that it isn’t prevented by a UI policy). Users with any encryption module can view and update the empty field. Entering data in the field causes the field to use the currently selected encryption module to encrypt the data. If there's data in the field: If the user has access to the encryption module used to encrypt the field, the user can view and edit the field.
User with two or more encryption modules	To use the field, the user must have access to the encryption module defined in the encrypted field configuration. If the user doesn't have access to the encryption module, the form hides the field. In list view, the field appears empty and can't be edited. If there's no data in the field: If the user has access to the encryption module, the form shows the field (assuming UI policy doesn't prevent it). Users with access to the encryption module can view and update the empty field. Data entered in the field is encrypted with the encryption module defined in the encrypted field configuration. If there's data in the field: If the user has access to the encryption module, the user can view and edit the field. The field always uses the original encryption module to encrypt changes to the field. This behavior helps to prevent users with two or more encryption modules from changing the encryption module of a field.	The user can select an encryption module from the encryption module selector in the welcome bar. If there's no data in the field: The form shows the field (assuming UI policy doesn't prevent it). Users with any encryption module can view and update the empty field. Entering data in the field causes the field to use the currently selected encryption module to encrypt the data. The field always uses the original encryption module to encrypt changes to the field. This behavior helps to prevent users with two or more encryption modules from changing the encryption module of a field. If there's data in the field: If the user has access to the encryption module used to encrypt the field, the user can view and edit the field. The field uses the original encryption module to encrypt changes to the field. This behavior helps to prevent users with multiple encryption modules from changing the encryption module of a field.

Important:

Changes to fields encrypted with Column Level Encryption are not tracked in the activity stream for the record or in the record history [sys_history_set] table.

Supported configuration information

• The following field types can be encrypted:
  • Attachments
  • Date
  • Date/Time
  • String text
  • URL
  Note:

  More field types are available in Enterprise. See Column Level Encryption Enterprise for details.
• Because modules are tied to roles and roles are tied to users, you don’t have access to keys from non-user sessions. Anything running as a system user or a scheduled job that doesn't have a user session can't access the key to encrypt or decrypt data.
• You may access the "value" or the "display value":
  • When you choose "value," ciphertext is returned.
  • When you choose "display value," provided you have the right role, cleartext is returned.

  Many scripts in the application layers are scripted in such a way that they ignore this distinction and use value. If you don't change the scripts to use the display value, the data isn't encrypted or decrypted.

Attachment Encryption

Attachment encryption by default

Customers using Column Level Encryption have attachments encrypted by default in tables that have an active Encrypted Field Configuration (EFC) type of Attachment.

This default encryption defined by the EFC configuration means that admins don’t need to declare that an attachment should be encrypted on upload for these tables manually.

Opt out of default encryption

If you don’t want attachments encrypted by default based on EFC configuration, you can opt out of this option by contacting support.

To opt out of this feature, create a support case with support, and include this statement in a comment on the case record:

"I [customer name], understand that I am asking to turn off a recommended security best practice for attachments, and that [customer company] assumes any additional risk related to their configuration and use of unencrypted attachments in the application."

Filtering and searching encrypted fields

When an Encrypted Text field or a field with an encrypted field configuration applied is selected as the left operand in a filter, the following operators are available:

• is
• is not
• is empty
• is not empty

For Date fields, use the date picker to specify the date:

For Date/Time fields, use the date and time picker to specify the date and time:

If a user with an encryption module filters for equality, or searches for a value in a list:

• Only values encrypted with an encryption module available to the user are returned.
• The operators is empty and is not empty return all matching records. Fields encrypted with an encryption module not available to the current user appear empty.

If a user doesn't have any encryption modules, no records are returned.

The Show Matching and Filter Out options are supported in lists. Only exact matches are returned or filtered out.

Note:

Adding encrypted fields in condition filters is supported in scripts such as UI policies and business rules.

Exporting data from encrypted fields

When exporting encrypted fields in a list or form to a file format, only fields encrypted by an encryption module appear in the exported document. The encryption module used must be available to the current user.

To disable exports of encrypted data from a list view, add the glide.encryption.export_encrypted_data.allowed system property and set the value to false.

Encryption on system tables

Column Level Encryption currently doesn’t support the encryption of fields and attachments of system tables (tables that begin with sys_).