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 core platform use cases such as editing a field from the list edit form, updating a record from the record form, managing direct web services, and processing data from the REST API. Applications created using standard forms and lists should work without custom encryption rules.

If you develop scripted processors, scripted web services, scripted REST APIs, UIs, or Ajax scripts that contain data that should be encrypted, you must write encryption rules to find and map the data to Glide table-field names.

Format of an encryption rule

Except for attachment requests, when an HTTP request hits 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 very 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.

1. 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 you are 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 per sys_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.
2. 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 if blocks with an array lookup, and replace all blocks in the array lookup with just one if block.
   • Combine if blocks whenever it is possible to group them.

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 allows encryption rules to be network performant. However, fetching and parsing content from the body multiple times could lead to unexpected results. To account for this, requests should be processed by the action in a single pass.

When creating encryption rules, you cannot 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 cannot use APIs from the white list manager or scoped applications.

Error handling

If an encryption rule condition or action throws an exception, check the proxy log for troubleshooting information.