{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":41175,"path":"platform-security/exploring-fe.md","title":"Exploring Field Encryption","bundle":null,"doc_type":null,"release":"australia","body":"\n# Exploring Field Encryption\n\nLearn the details of Field Encryption Starter and Field Encryption Enterprise\n\n## Encryption-backed access control\n\n\\[Omitted video\\] Description: This video provides an overview of Field Encryption, including how it protects sensitive data at rest by encrypting individual fields and attachments, and how its key components work together.\n\nBy 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.\n\nYou 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.\n\n\\[Omitted image \"fe\\_field\\_encryption\\_components\\_diagram.svg\"\\] Alt text: Field encryption and supporting components\n\nBy 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.\n\n\\[Omitted image \"fe\\_map\\_diagram.svg\"\\] Alt text: Module access policy flow\n\nYou 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.\n\n\\[Omitted image \"fe\\_map\\_example\\_diagram.svg\"\\] Alt text: Multiple module access policy example\n\nAccess 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.\n\n<table><thead><tr><th>\n\nAccessor\n\n</th><th>\n\nMAP A Columns A, B, C, D\n\n</th><th>\n\nMAP B Column E\n\n</th></tr></thead><tbody><tr><td>\n\nRole A\n\n</td><td>\n\nAllow\n\n</td><td>\n\nBlock\n\n</td></tr><tr><td>\n\nRole B\n\n</td><td>\n\nAllow\n\n</td><td>\n\nBlock\n\n</td></tr><tr><td>\n\nRole C\n\n</td><td>\n\nBlock\n\n</td><td>\n\nAllow\n\n</td></tr><tr><td>\n\nScript A\n\n</td><td>\n\nAllow\n\n</td><td>\n\nBlock\n\n</td></tr><tr><td>\n\nScript B\n\n</td><td>\n\nBlock\n\n</td><td>\n\nBlock\n\n</td></tr><tr><td>\n\nScript C\n\n</td><td>\n\nBlock\n\n</td><td>\n\nAllow\n\n</td></tr><tr><td>\n\nSystem Context Processes\n\n</td><td>\n\nBlock\n\n</td><td>\n\nAllow\n\n</td></tr></tbody>\n</table>## Differences between Field Encryption Starter and Field Encryption Enterprise\n\nThe feature-set is different between Field Encryption Starter and Field Encryption Enterprise.\n\n<table id=\"table_uk2_b3n_b2c\"><thead><tr><th>\n\nFeature\n\n</th><th>\n\nField Encryption Starter\n\n</th><th>\n\nField Encryption Enterprise\n\n</th></tr></thead><tbody><tr><td>\n\nNumber of encrypted fields\n\n</td><td>\n\nUp 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.\n\n</td><td>\n\nNo restriction on number of encrypted fields\n\n</td></tr><tr><td>\n\nAttachment encryption\n\n</td><td>\n\nNo\n\n</td><td>\n\nYes\n\n</td></tr><tr><td>\n\nKey management\n\n</td><td>\n\nNone \\(Contact ServiceNow Support for key rotation\\)\n\n</td><td>\n\nManage keys from your instance with no involvement from ServiceNow Support\n\n</td></tr><tr><td>\n\nSupported data types\n\n</td><td>\n\nAll supported data types\n\n</td><td>\n\nAll supported data types\n\n</td></tr><tr><td>\n\nNumber of Field Encryption Modules\n\n</td><td>\n\nNo restriction\n\n</td><td>\n\nNo restriction\n\n</td></tr><tr><td>\n\nNumber of Module Access Policies\n\n</td><td>\n\nNo restriction\n\n</td><td>\n\nNo restriction\n\n</td></tr><tr><td>\n\nCustomer-Supplied Key \\(BYOK\\)\n\n</td><td>\n\nNo\n\n</td><td>\n\nYes\n\n</td></tr><tr><td>\n\nExternal Key Management Service \\(HYOK\\)\n\n</td><td>\n\nNo\n\n</td><td>\n\nYes\n\n</td></tr></tbody>\n</table>## Field Encryption users\n\n<table id=\"table_k3r_dhn_b2c\"><thead><tr><th>\n\nUser\n\n</th><th>\n\nDescription\n\n</th></tr></thead><tbody><tr><td>\n\nKey Management Framework \\(KMF\\)Admin or KMF Cryptographic Manager\n\n</td><td>\n\nThese roles are used to configure elements of Field Encryption.-   Field Encryption modules and module keys\n-   Cryptographic Specifications\n-   Module life-cycle policies\n-   Encrypted field configurations for fields and attachments\n-   Module Access Policies \\(MAPs\\)\n-   Configures, wraps, and uploads customer supplied keys \\(for Field Encryption Enterprise\\)\n-   Configures Access Observer and review Access Observer logs.\n-   Schedule mass encryption, decryption, or re-keying\n\n</td></tr><tr><td>\n\nKMF Cryptographic Operator\n\n</td><td>\n\nConfigures properties for customer supplied keys\n\n</td></tr></tbody>\n</table>## Field Encryption and record history\n\nChanges 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.\n\n## Encryption on system tables\n\nField Encryption currently doesn’t support the encryption of fields and attachments of system tables \\(system tables whose names begin with `sys_`\\).\n\n## Cloning considerations\n\nDuring cloning, encrypted field data and encryption modules are copied to the target instance. Encryption keys are re-encrypted with a secondary key unique to the source instance, so the target instance cannot decrypt the copied field data until key exchange completes.\n\nUntil 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.\n\nTo restore access to encrypted fields on the target instance, complete a key exchange from the source instance. See [Configure Key Exchange](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/platform-encryption/configure-key-exchange.md).\n\n## What to explore next\n\nTo learn more about configuring and using Field Encryption, see:\n\n-   [Configuring Field Encryption](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/configuring-column-level-encryption.md)\n-   [Using Field Encryption](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/using-column-level-encryption.md)\n\n-   **[Field Encryption Enterprise](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/now-platform-encryption.md)**  \nField Encryption Enterprise uses the Key Management Framework \\(KMF\\) to enable you to customize and manage how fields and attachments are encrypted and decrypted on your instance. A subscription is required to use Field Encryption Enterprise.\n\n**Parent Topic:**[Field Encryption](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/field-encryption.md)\n\n"}}