Define a custom encryption rule
Summarize
Summary of Define a custom encryption rule
Custom encryption rules enable ServiceNow customers to identify and encrypt sensitive information in HTTP requests before they reach their instance. These rules run on the Edge Encryption proxy server, mapping request fields to table-field names on the instance, and specifying how to encrypt the data in custom payloads. This is essential when handling scripted data or custom integrations that include sensitive information not covered by default encryption rules.
Show less
When to Use Custom Encryption Rules
The Edge Encryption plugin includes default rules for common platform use cases such as list edits, record updates, and REST API calls. Custom encryption rules are necessary when you develop scripts or integrations—like scripted processors, scripted web services, scripted REST APIs, UIs, or Ajax scripts—that contain sensitive data requiring encryption.
Structure and Execution of Encryption Rules
- Condition: Specifies the type of HTTP request to which the rule applies.
- Action: Maps and encrypts fields in the request based on encryption configurations.
- Order: Defines rule priority; the Edge Encryption proxy evaluates rules from lowest to highest order and runs only the first matching rule.
Rules must be specific to avoid misprocessing requests. Generic conditions should have higher order values to ensure more specific rules are evaluated first. Only one rule executes per request.
Guidelines for Creating Effective Encryption Rules
- Keep rules focused on specific use cases instead of broad scenarios.
- Split large or complex rules into multiple smaller rules targeting discrete tables or record producers.
- Minimize script blocks, using array lookups and consolidated condition checks to optimize performance.
- Balance the trade-off between maintainability and validation efficiency when deciding the number of rules.
Encryption Rule APIs and Restrictions
Encryption rules are scripted in JavaScript using Edge Encryption APIs, which allow navigation and encryption of JSON and XML content streams. These APIs operate on streaming data for network efficiency and require processing requests in a single pass to avoid parsing issues.
While creating rules, you cannot use Glide APIs, script includes, business rules, global parameters, or APIs from allow list managers or scoped applications. The global request object is available for handling HTTP data.
Error Handling and Preparation
If an encryption rule throws exceptions, troubleshooting details can be found in the proxy log. Prior to rule creation, inspect the client request format entering the Edge Encryption proxy server to accurately define conditions and actions.
Practical Application
By defining custom encryption rules, ServiceNow customers can ensure sensitive data transmitted via HTTP requests—especially from custom scripts or integrations—is encrypted appropriately before reaching the instance. This enhances data security in complex or customized environments beyond the out-of-the-box encryption capabilities.
It may be necessary to identify and encrypt sensitive information in HTTP requests on the way to your instance. You can write encryption rules to identify, interpret, and encrypt data in such requests, mapping fields in the request to table-field names on your instance.
What is an encryption rule
When to use custom rules
A set of encryption rules is included as part of the Edge Encryption plugin. These rules handle many core platform use cases, such as:
- Editing a field from the list edit form
- Updating a record from the record form
- Managing direct web service
- Processing data from the REST Application Program Interface (API)
Applications created using standard forms and lists should work without custom encryption rules.
If you develop scripts that contain data that should be encrypted, create encryption rules to find and map that data to Glide table-field names. For example:
- Scripted processors
- Scripted web services
- Scripted REST APIs, UIs, or Ajax scripts
Format of an encryption rule
- Condition: Identifies the type of request.
- Action: Maps fields in the request to fields in a table, encrypting values that map to fields with encryption configurations defined.
- Order: Priority of the rule. The lowest priority rule with a satisfied condition is the only rule that runs. Like business rules, rules run from lowest to highest.
Except for attachment requests, HTTP requests are evaluated by the Edge Encryption proxy server. The Edge Encryption proxy server evaluates all encryption rule conditions in priority order until either all conditions return false, or one condition returns true. When a condition returns true, the action is executed on the request, and the result is forwarded to the instance. No other conditions are evaluated. As a result, encryption rule conditions should be as specific as possible. A generic rule might evaluate as true for a request meant to be processed by another rule, causing the request to be processed by the wrong action. If a generic condition is unavoidable, the rule should be marked with a high-order value so that more specific rules are evaluated first.
Guidelines for creating encryption rules
Creating efficient, optimized encryption rules can reduce processing time for script validation.
Overall guideline: When rules get long, do your best to minimize the number of blocks and break the rules apart whenever possible. Ideally, custom rules should apply to specific use cases, rather than
encompassing several cases, with ifs or switch statements in the action script.
- Split rules whenever possible. For example,
- Create different rules for different tables and ensure that each rule runs only on its respective table.
- Create different rules for each record producer that you’re targeting, or at least for each subset of record producers. Instead of one rule targeting dozens of
sys_ids, you could create several different rules targeting smaller subsets of record producers, or even create one rule persys_id.Note:Creating multiple rules requires more maintenance. The trade-off is that multiple, simpler rules can be validated more efficiently than longer, more complex rules.
- Minimize the number of blocks. Because the processing engine scans each block while
evaluating scripts, a large number of blocks causes delays in validation. For example,
- Replace all
ifblocks with an array lookup, and replace all blocks in the array lookup with just oneifblock. - Combine
ifblocks whenever it’s possible to group them.
- Replace all
Encryption rule APIs
Encryption rules are written in JavaScript and utilize Edge Encryption APIs to locate and encrypt sensitive information in the body of a request. The API uses expressions similar to xPath to navigate through both JSON and XML content.
Edge Encryption APIs process the request off the stream as it is being written to the output stream. Stream parsing enables encryption rules to be network performant. However, fetching and parsing content from the body multiple times could lead to unexpected results. To void this potential problem, requests should be processed by the action in a single pass.
When creating encryption rules, you can’t use Glide APIs, script includes, business rules, or any global parameters such as current. Because the rules are created for HTTP objects, a global request object is available.
When creating encryption rules, you can’t use APIs from the allow list manager or scoped applications.
Error handling
If an encryption rule condition or action throws an exception, check the proxy log for troubleshooting information.