Key management for Edge Encryption

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Key management for Edge Encryption

    As a ServiceNow customer using Edge Encryption, you are responsible for managing the encryption keys that protect your sensitive data. This includes selecting encryption algorithms, choosing key storage methods, rotating keys appropriately, and ensuring secure handling of keys during key lifecycle operations.

    Show full answer Show less

    This guidance specifically addresses key management for the Edge Encryption product, distinct from the Key Management Framework used with Column Level Encryption.

    Key Features

    • Encryption Algorithms: You must define a default AES 128-bit encryption key even if AES 256-bit is used. Deciding between AES 128-bit and AES 256-bit depends on your security requirements.
    • Key Storage Options: Edge Encryption supports three keystore types:
      • File Store: Keys are stored as files in the filesystem accessible by the Edge Encryption proxy. These files are not encrypted, so you must ensure their protection.
      • Java KeyStore (JCEKS): Offers password protection and can store multiple keys with unique aliases, improving key management security and organization.
      • Enterprise Key Management (EKM): Integrates with systems like SafeNet KeySecure or Unbound Technology for advanced key storage and retrieval.
    • ServiceNow Public Key: The Edge Encryption proxy includes a Java JCEKS keystore file (keystore.jceks) containing the ServiceNow public key, which validates encryption rule signatures. If you use a different keystore, you must import this public key with alias servicenow.
    • Digital Signatures and Certificates: The Java JCEKS keystore also stores RSA key pairs for digitally signing encryption configurations and rules, as well as certificates used to secure connections between the proxy and clients.
    • Key Rotation and Mass Encryption: Key rotation requires careful planning. Before removing any key, decrypt all data encrypted with it, which may involve adding a new key and scheduling a mass key rotation job to re-encrypt data.
    • SafeNet Key Versioning: This feature simplifies key management by allowing a single alias to be maintained while incrementing key versions, avoiding the need to create new aliases for each new key.

    Practical Considerations

    • Always define a default AES 128-bit key, even if you use AES 256-bit, to ensure compatibility and fallback.
    • Choose the keystore type that aligns with your security policies and operational capabilities: file store for simplicity, Java KeyStore for enhanced security, or EKM for enterprise-grade key management.
    • Protect keystore files and passwords rigorously to prevent unauthorized access to encryption keys.
    • Before key removal, ensure all data encrypted with that key is decrypted or re-encrypted with a new key to prevent data loss.
    • If integrating with EKM or using alternative keystores, import the ServiceNow public key to maintain encryption rule validation capability.

    You are responsible for providing and managing the encryption keys used by Edge Encryption.

    This topic refers to keys for the Edge Encryption product. If you are looking for information on the Key Management Framework, which can be used with Column Level Encryption, see Key Management Framework.

    When obtaining and creating encryption keys to support the encryption types used by Edge Encryption, consider the following:
    • Whether to use AES 128-bit or AES 256-bit. You must define a default AES 128-bit encryption key, even if it is not used.
    • Whether to use file system, Java KeyStore, or Enterprise Key Management (EKM).
    • When to rotate encryption keys.
    • When and if to use a mass encryption job to re-encrypt data using the new key.

    Before removing a key from the proxy configuration files and the keystore, it is critical that you decrypt all data on the instance that uses the key. You can do this by adding a new encryption key and scheduling a mass key rotation job.

    Keystores

    Edge Encryption supports the following types of key storage.
    File store
    Keys are stored in a file in a file system that is accessible by the Edge Encryption proxy. Encryption keys stored in a file are not encrypted, so it is your responsibility to protect these files.
    Java KeyStore
    Keys are stored in Java's JCEKS KeyStore. A Java KeyStore is protected by a password, so it is more secure than storing keys in a file in the file store. A single Java KeyStore can store multiple keys, and the keys are identified by a key alias, making it easier to manage multiple keys.
    Enterprise Key Management (EKM)
    Keys are stored and retrieved with the SafeNet KeySecure or Unbound Technology key management systems.

    The Edge Encryption proxy ships with the Java JCEKS KeyStore file named keystore.jceks in the keystore directory. This keystore file contains the ServiceNow public key used to validate encryption rules signed by ServiceNow.

    Note:
    If using a keystore other than the base system Java JCEKS KeyStore, you must import the ServiceNow public key into your keystore. The public key alias is servicenow.

    In addition to the encryption keys, the Java JCEKS KeyStore is used to store the RSA key pair for digitally signing the encryption configuration and encryption rules that are stored in the instance, and the digital certificate that the Edge Encryption proxy uses to establish a secure connection with the browsers and any other clients.