Exploring ServiceNow access control

  • Release version: Yokohama
  • Updated January 30, 2025
  • 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 ServiceNow Access Control

    The SNC Access Control plugin (com.snc.sncaccesscontrol) allows ServiceNow customers to precisely manage which Customer Service and Support employees can access their instance and under what conditions. Upon activation, access is denied to all Customer Service and Support personnel until explicit permissions are granted via records in the SNC Access Control table. This plugin enhances security by ensuring only authorized personnel can log in, while still allowing ServiceNow Operations staff to perform necessary administrative tasks on the infrastructure. It is important to note that enabling this plugin may impact support service levels and the Availability SLA, as these are measured from the time support personnel gain access.

    Show full answer Show less

    Key Features

    • Secure Login Mechanism: Access is controlled through encrypted tokens generated by a secure, locked-down security server accessible only to ServiceNow security personnel.
    • Synthetic User Accounts: Authorized Customer Service and Support employees log in using synthetic users created only in memory with no persisted credentials, minimizing security risks.
    • Access Control Records: Customers create and manage access records specifying which employees can access the instance and during what time windows.
    • Token-Based Authentication: Tokens are instance- and user-specific, valid for only four hours, and cannot be used by impersonated users, reducing the risk of unauthorized use.
    • Comprehensive Logging: All login events and subsequent actions by Customer Service and Support employees are logged in both transaction logs and event logs, providing robust audit trails.

    Security Processing Flow

    The access process involves:

    • Customer Service and Support technicians request login via hi.service-now.com.
    • Requests are validated based on user roles and IP addresses by the Security Server.
    • Upon approval, the Security Server generates and encrypts a token containing user, instance, and time data.
    • The token is passed back to the technician's browser, which uses it to log into the instance as a synthetic user.
    • The instance verifies token validity, user authorization (including active status and current time window), then grants access for up to four hours.

    Practical Implications for ServiceNow Customers

    By enabling the SNC Access Control plugin, customers gain granular control over non-employee access, enhancing security and compliance. Customers can revoke access at any time and have clear visibility into support personnel activities through comprehensive logging. However, customers should be aware that restricting access may affect support response times and SLA measurements. This plugin is a critical component for customers aiming to harden instance security and precisely manage support access without compromising operational support requirements.

    The SNC Access Control plugin (com.snc.snc_access_control) enables you to control which Customer Service and Support employees can access your instance, and when.

    When you first activate the plugin, Customer Service and Support employees cannot log into the instance. Any currently logged-in Customer Service and Support employees remain logged in. You create records in the SNC Access Control table that grant access to specific SNC employees or all employees.

    The plugin prevents Customer Service and Support personnel from accessing the instances without your express permission. However, other authorized ServiceNow Operations personnel must perform administrative actions on the underlying infrastructure as part of their responsibilities. This includes supporting and managing the product,responding to security events, and verifying usage. This infrastructure includes servers and databases, among other infrastructure components that make up the SaaS solution. This access method is fully auditable and tracked.

    This plugin enables you to restrict access to your instance without your express permission, so it may affect support service levels and the Availability SLA. Availability SLA is then measured from the time that Support staff personnel are granted access to your instance.

    Login security

    Security for authorized Customer Service and Support employee logins to instances employs encrypted tokens generated by a secure server. Only properly authenticated Customer Service and Support employees are granted access to an instance. Without the SNC Access Control plugin, the security server ensures that access rights are enforced on hi.service-now.com. When the plugin is enabled, the encrypted login tokens must match names in the plugin-provided access list, using the criteria defined in those records. This method of authentication enables you to determine precisely which Customer Service and Support employees may access their instances, and when these employees may do so.

    The architecture chosen for this system has several features designed to enhance security for your instances:
    Security server
    The security server is a locked-down, Linux host that only ServiceNow security personnel can access. This server is the only system that has access to the critical private encryption key necessary to produce the login tokens. By using this compartmentalization (a standard security practice), the private key is protected, even in the unlikely event that an attacker compromises the HI instance.
    Synthetic user
    The facility on instances that enables authorized Customer Service and Support employees to log into their instance does not require an account to be provisioned on that instance. There is no user record provisioned, and no permanent or persisted credentials. Instead, a synthetic user is created for each Customer Service and Support employee logon. This user exists only in memory and provides no ongoing privileges. If the SNC Access Control plugin is enabled, you can deauthorize any Customer Service and Support employee at any time.
    Tokens
    The security tokens are specific to an instance and a particular Customer Service and Support employee. In addition, the mechanism that generates the tokens only works with actual Customer Service and Support employee logins to HI, not impersonated users. Once a security token is generated, only a specific Customer Service and Support employee can use it to log into an instance.
    Time limit
    Security tokens expire four hours after they are generated. This expiration limits the utility of hijacked tokens, which can only be used during this short window.
    Logging
    Logins by Customer Service and Support employees to instances are recorded as a login event.
    • Every action taken by the logged-in Customer Service and Support employee is added to the transaction log in the database.
    • It is also added to the instance log on the file system, which is inaccessible to most ServiceNow employees.
    • Customer Service and Support employee logins and actions are readily identifiable, since the user names all end in @snc (like frodo.baggins@snc).

    These actions provide you with easy-to-use, robust, and reliable security logging for non-employee access.

    Security processing flow

    When a Customer Service and Support employee wants to log into an instance, the security processing flow is as follows:

    1. A Customer Service and Support technician requests a login for the instance through hi.service-now.com.
    2. HI checks that the technician has the proper role authorizing access to instances.
    3. If the user has the proper role, HI sends the request for access to the Security Server.
    4. The Security Server verifies that the request came from the HI IP address, and evaluates the request (user, role, and IP address of the requester). If the request is valid, the Security Server approves it and constructs a token. This token contains the user name, roles, the instance ID, and the time (the start of the 4-hour token life span). Finally, the Security Server encrypts the token with the private encryption key.
    5. The Security Server sends the encrypted token to HI.
    6. Hi sends the token to the Support technician's browser.
    7. The Support technician's browser initiates a login into the instance, using the special user name ending with @snc.
    8. The instance uses the public key to decrypt the token. To verify the token, the instance matches it to the user name supplied in the previous step, the instance ID, and the authorized time window. If the SNC Access Control plugin is enabled, the instance verifies that the user is:
      • Listed
      • Active
      • Configured to access the instance in the current time window
    9. If the user is authenticated, the instance creates a synthetic user in memory with the given roles. This user does not persist after the time limit expires, the user logs off, or the instance is restarted.
    Figure 1. ServiceNow security access process flow
    ServiceNow security access process flow

    Audit logging

    The following logging tracks logins and activity by Customer Service and Support employees:
    • Event logs: The event logs show all Customer Service and Support logins to an instance.
    • Transaction logs: The transaction logs show all activity on the instance, including any efforts to delete logs.
    Note:
    To learn more about this plugin, see ServiceNow access control in Instance Security Hardening Settings.