Exploring Field Encryption
Summarize
Summary of Exploring Field Encryption
Field Encryption in ServiceNow provides robust encryption capabilities to protect sensitive data in fields and attachments. It includes two editions: Field Encryption Starter and Field Encryption Enterprise, each offering different levels of encryption features and key management. The encryption system uses an access control mechanism called Module Access Policies (MAPs) to regulate who or what can access encrypted data, supplementing traditional Access Control Lists (ACLs).
Show less
Key Features
- Encryption Access Control: By default, encrypted data is inaccessible to all users, scripts, and system processes. Access is granted selectively through MAPs that define authorized accessors and rules for specific encrypted fields. Multiple MAPs can apply different access rules to different fields, enabling fine-grained control.
- Field Encryption Starter vs. Enterprise:
- Starter: Supports up to 5 encrypted fields, no attachment encryption, and requires ServiceNow Support for key rotation.
- Enterprise: Supports unlimited encrypted fields and attachments, with in-instance key management allowing customers to manage keys without ServiceNow Support involvement.
- User Roles: Roles such as KMF Admin, Cryptographic Manager, and Cryptographic Operator enable configuration of encryption modules, keys, policies, and monitoring tools like Access Observer logs.
- Limitations: Encryption is not supported for system tables (tables starting with sys). Changes to encrypted fields are not tracked in record history or activity streams.
- Cloning Considerations: When cloning instances with encrypted fields, the encrypted data is copied but cannot be decrypted on the target instance until a key exchange process is completed between source and target instances.
Practical Implications for ServiceNow Customers
Customers can use Field Encryption to secure sensitive data at the field level while maintaining strict control over data access through MAPs. Choosing between Starter and Enterprise editions depends on encryption scope needs and key management preferences. Understanding roles and key management processes is essential for proper setup and ongoing maintenance. Awareness of limitations, such as lack of system table encryption and cloning behavior, helps avoid issues in encryption deployment and instance management.
Learn the details of Field Encryption Starter and Field Encryption Enterprise
Encryption-backed access control
By default, Field Encryption blocks all users, scripts, and system processes from accessing encrypted data. However, Field Encryption has an access control feature that is used in combination with, but also separate from, Access Control Lists (ACLs) to ensure only the correct users, scripts, or system processes can access encrypted data.
You can configure the access control feature of Field Encryption through a combination of Field Encryption Modules, Encrypted Field Configurations, and Module Access Policies. The next image shows how these three components work together.
By default, encrypted data is locked down from all access. A MAP defines which accessor (users, scripts, and system processes) can be authorized to access the data.
You can configure multiple MAPs to apply different access rules to different encrypted fields. In this diagram, Module Access Policy A covers columns A, B, C, and D, and Module Access Policy B covers column E — each with its own rules per accessor.
Access rules can differ between two policies for each accessor type. The following table reflects the access rules defined for Module Access Policy A, applied to columns A, B, C, and D, and Module Access Policy B, applied to column E.
| Accessor | MAP A Columns A, B, C, D |
MAP B Column E |
|---|---|---|
| Role A | Allow | Block |
| Role B | Allow | Block |
| Role C | Block | Allow |
| Script A | Allow | Block |
| Script B | Block | Block |
| Script C | Block | Allow |
| System Context Processes | Block | Allow |
Differences between Field Encryption Starter and Field Encryption Enterprise
The feature-set is different between Field Encryption Starter and Field Encryption Enterprise.
| Feature | Field Encryption Starter | Field Encryption Enterprise |
|---|---|---|
| Number of encrypted fields | Up to 5 encrypted fields Note: Field Encryption Starter limits the number of encrypted fields, not encryption modules or contexts. Field Encryption replaces the deprecated Column Level Encryption product, which used a module and context-based limit. |
No restriction on number of encrypted fields |
| Attachment encryption | No | Yes |
| Key management | None (Contact ServiceNow Support for key rotation) | Manage keys from your instance with no involvement from ServiceNow Support |
| Supported data types | All supported data types | All supported data types |
| Number of Field Encryption Modules | No restriction | No restriction |
| Number of Module Access Policies | No restriction | No restriction |
Field Encryption users
| User | Description |
|---|---|
| Key Management Framework (KMF)Admin or KMF Cryptographic Manager | These roles are used to configure elements of Field Encryption.
|
| KMF Cryptographic Operator | Configures properties for customer supplied keys |
Field Encryption and record history
Changes to fields encrypted with Field Encryption are not tracked in the activity stream for the record or in the record history [sys_history_set] table.
Encryption on system tables
Field Encryption currently doesn't support the encryption of fields and attachments of system tables (tables that begin with sys_).
Cloning considerations
When you clone an instance that uses Field Encryption, the encrypted field data and encryption modules are copied to the target instance. Because encryption keys are re-encrypted with a secondary key that is unique to the source instance, the target instance can't decrypt the field data after cloning.
Until a key exchange is performed, encrypted fields on the cloned instance appear empty or unreadable. This is expected behavior and does not indicate data corruption or loss.
To restore access to encrypted fields on the target instance, complete a key exchange from the source instance. See Configure Key Exchange.