Exploring Field Encryption
Summarize
Summary of Exploring Field Encryption
Field Encryption in ServiceNow provides robust data protection by encrypting sensitive fields and attachments, ensuring only authorized users, scripts, or system processes can access encrypted data. It uses an encryption-backed access control mechanism that complements standard Access Control Lists (ACLs) to tightly secure data access. This feature is configurable via Field Encryption Modules, Encrypted Field Configurations, and Module Access Policies (MAPs), which collectively define who can access specific encrypted fields and under what conditions.
Show less
Key Features
- Access Control: By default, encrypted data is inaccessible. MAPs specify access permissions for different users, scripts, and system processes. Multiple MAPs can be used to apply diverse access rules across different fields.
- Field Encryption Editions:
- Field Encryption Starter: Supports up to 5 encrypted fields, no attachment encryption, and requires ServiceNow Support for key rotation.
- Field Encryption Enterprise: No limit on encrypted fields or modules, supports attachment encryption, and allows customer-managed keys through the Key Management Framework (KMF).
- Key Management Framework (KMF) Roles: Roles such as KMF Admin, Cryptographic Manager, and Cryptographic Operator enable configuring encryption modules, managing keys, and monitoring access.
- Data and System Table Considerations: Encryption changes do not appear in record history or activity streams. Fields on system tables (starting with sys) are not supported for encryption.
- Cloning Behavior: When cloning instances with Field Encryption, encrypted data is copied but initially unreadable on the target instance until a key exchange is performed to restore decryption capability.
What This Enables for ServiceNow Customers
ServiceNow customers can protect sensitive field data with flexible, granular encryption controls tailored by user, script, or process. The two editions allow choice based on encryption scale and key management needs. Enterprise customers gain full control of encryption keys and attachment protection, enhancing security compliance. Understanding cloning behavior and exclusions (system tables) helps maintain data integrity during instance management. Overall, Field Encryption empowers customers to secure critical data while maintaining controlled accessibility according to organizational policies.
Next Steps
To implement Field Encryption effectively, customers should review configuration guidance specific to their edition and explore features such as setting up encryption modules, defining MAPs, managing keys via KMF, and performing key exchanges after cloning. Subscription to Field Encryption Enterprise is required for advanced capabilities and key 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 works in combination with Access Control Lists (ACLs). This feature is also separate from ACLs and ensures only the correct users, scripts, or system processes can access encrypted data.
You can configure Field Encryption access control feature through a combination of Field Encryption Modules, Encrypted Field Configurations, and Module Access Policies (MAPs). 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. Module Access Policy B covers column E. Each policy has 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 and Module Access Policy B. Module Access Policy A applies to columns A, B, C, and D. Module Access Policy B applies 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.