Exploring Secrets Management

  • Release version: Xanadu
  • Updated August 1, 2024
  • 4 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 Exploring Secrets Management

    ServiceNow Secrets Management enables granular control over access to passwords and digital credentials, aligning with your business security needs. It offers two versions:Secrets Management Core, available by default at no extra cost, andSecrets Management Enterprise, a paid plugin requiring a ServiceNow Vault license and activation by ServiceNow personnel. Admin roles are necessary to access Secrets Management modules and records.

    Show full answer Show less

    Key Features

    • Secrets Management Core: Provides basic functionality to create and organize secret groups with criteria on predefined non-custom tables, facilitating secure password management without additional installation.
    • Secrets Management Enterprise: Extends Core features with granular access controls allowing admins to create secret groups based on detailed criteria such as scope, table, column, and record. It supports client-accessible secrets encrypted with customer-held keys, inaccessible to ServiceNow.
    • Secret Groups: Organize secrets into groups to apply access policies. Groups can be basic (scope-wide) or criteria-based (filtered by application scope, package, table, column, or record). Groups may be instance-side (decrypted by the instance) or client-side (decrypted only by the client using public/private key pairs).
    • Granular Access Control: Unlike the platform’s password2 feature which only controls access at the application scope level, Secrets Management allows restricting access within scopes based on customizable criteria.
    • Secure Storage: Client-side secret groups use an encryption scheme where ServiceNow does not store encryption keys, enhancing security independence from ServiceNow’s infrastructure.
    • Module Access Policies: Apply policies to cryptographic modules to define instance-level controls such as key validity time frames, strengthening security posture.
    • Integration with Platform Tables: Secrets Management introduces new and modifies existing tables to support secret groups, criteria, wrapped secrets, identity groups, cryptographic keys, and access policies.

    Practical Applications

    • IT Operations Management (ITOM) Discovery: Securely manage authentication credentials required by MID Servers and agents during discovery processes, ensuring secure updates to the CMDB.
    • Integration Hub Connectivity: Safely handle the myriad of API authentication credentials needed for automated connections across systems, supporting secure integration workflows.

    What ServiceNow Customers Can Expect

    By leveraging Secrets Management, customers gain enhanced security and control over digital credentials, tailored to their organizational needs. Customers can organize secrets efficiently, implement fine-grained access policies, and benefit from highly secure client-side encryption methods that limit ServiceNow’s access to encryption keys. This results in stronger cybersecurity, compliance with internal security policies, and improved management of credentials across IT operations and integrations.

    Use ServiceNow Secrets Management for granular management of access to your passwords to fit your business needs.

    Important:
    Admins must have the role to see modules and records related to Secrets Management. For secrets management role information, see Secrets management roles.

    Select from Core and Enterprise versions of Secrets Management

    Choose from Secrets Management Core and Secrets Management Enterprise depending on your business needs.

    The Secrets Management Core plugin (com.glide.sm.core) is available by default. No installation is required on the instance for use. The Secrets Management Enterprise plugin is only available with a ServiceNow Vault v1, PROD18537 license. Contact Customer Support for assistance with the Secrets Management Enterprise plugin.

    Secrets Management Core Secrets Management Enterprise
    Secrets Management Core is available to install on your instance at no additional cost. The plugin provides the ability to use secrets groups with criteria in non-custom tables provided in the ServiceNow platform that have been created by ServiceNow application engineering teams. Secrets Management Enterprise includes additional functions to help admins create and manage secrets groups. Enterprise provides the following features in addition to the features listed in Core.
    • Use granular access controls to create secrets groups based on the any of these criteria.
      • Scope
      • Table
      • Column
      • Record
    • Create client-accessible secrets that are encrypted using your own key which ServiceNow can’t access.
    • Use the Secrets Management Dashboard to review the secret groups configured on your instance, and learn about potential security issues.
    Note:
    Secrets Management Enterprise is a paid plugin that ServiceNow personnel must activate on your production instance.

    Use secret groups to organize your secrets

    Use Secrets Management to organize your secrets into groups, and then apply access policies to those secrets at a group level.

    Basic secret group
    These groups apply to all secrets in a scope. These secrets are decrypted by a common cryptographic module and module access policies.
    Secret group with criteria
    Secret groups with criteria function the same as a basic secret group, but further refine what is included using criteria. These criteria include:
    • Application scope
    • Package
    • Table
    • Secret column
    • Filter record

    Secret groups of either type can be made instance accessible or client accessible.

    Instance side secret groups
    Instance side secret groups contain secrets that can be decrypted by your instance.
    Client-side secret groups
    Client-side secrets groups use a public and private key pair to help ensure that secrets can only be decrypted by the client. When you create a client-accessible secrets group, you upload the public key to the instance, and retain the private key on your MID Server. The instance uses the public key to encrypt your secrets, but they can only be decrypted using the private key.
    Note:
    For more information on these group types, see Understanding client side Secrets Management.

    Use secrets groups for more granular control

    While password2 is available on the ServiceNow platform, Secrets Management provides these additional features.

    Granular access controls
    Password2
    With password2, admins can control access to an application scope, but can’t restrict access to elements within the scope.
    Secrets Management
    With Secrets Management, admins can restrict access based on criteria they define. Criteria types can be based on criteria such as package, table, or column.
    Secure Storage For client-side secret groups, Secrets Management uses a new encryption scheme. In this encryption scheme, ServiceNow doesn’t save the encryption key. For this reason, the security of your data doesn’t depend on ServiceNow security.

    Apply module access policies to your groups

    After you’ve grouped your secrets into a secret group, you can apply policies that determine how you can access them at a group level. Module access policies are the access control mechanisms that you apply to cryptographic modules to define instance-level controls, such as a validity time frame for the cryptographic key. For more information on module access policies, see Module access policy overview.

    Tables installed with Secrets Management

    Secrets Management adds or modifies these tables.

    New Tables
    [sn_sm_secret_group] Stores secret groups
    [sn_sm_secret_group_criteria] Stores criteria secret groups
    [sn_sm_secret] Stores wrapped secrets
    [sn_sm_identity_group] Defines the identity group for mapping a group of identities to the public key
    [sys_kmf_wrapped_module_key] Stores the wrapped symmetric cryptographic keys
    Modified Tables
    [sys_kmf_crypto_module] Added cryptographic module type. (Identity cryptographic module or secret group cryptographic module)
    [sys_kmf_module_key]
    • Stores conceptual secret encryption key (with no key material)
    • Stores the identity public key
    [sys_kmf_crypto_caller_policy] Added new module access policy type

    Secrets Management use case examples

    Help ensure secure ITOM Discovery

    This infographic shows a simplified reference architecture of how ServiceNow IT Operations Management (ITOM) Discovery can be deployed by your organization. As shown in the infographic, multiple Windows and Linux servers connect to the Management, Instrumentation, and Discovery (MID) Server and several MID Server agents enable the discovery process to update the Configuration Management Database (CMDB). Every MID server transaction requires a secure authentication, hence managing the authentication credentials is critical from a security perspective.

    Accelerating workflow connectivity with Integration Hub securely

    Use ServiceNow's Integration Hub to connect to different systems using automated application programming interface (APIs). Each time Integration Hub connects to a system using an API, an authentication credential is required to establish connectivity. Management of a multitude of applications and APIs for connectivity requires a secrets management solution.

    Secrets Management is a key part of ensuring your organization’s cybersecurity. It covers all processes and tools related to the creation, storage, transmission, and management of digital credentials such as encryption keys, API tokens, and passwords. To manage secrets both securely and effectively, you can build a core secrets management policy that establishes standard rules and procedures for all phases of a secret’s lifecycle.