Explore ServiceNow access control
Summarize
Summary of Explore ServiceNow access control
The SNC Access Control plugin (com.snc.sncaccesscontrol) enables ServiceNow customers to strictly control which Customer Service and Support employees can access their instances and when. Upon activation, access for these employees is blocked until explicit permissions are granted through records in the SNC Access Control table. This control enhances security by preventing unauthorized support access while still allowing necessary administrative actions by ServiceNow Operations personnel, which are fully auditable and tracked.
Show less
Key Features
- Access Restriction: Customers define exactly which Customer Service and Support staff can log in, reducing unauthorized access risks.
- Secure Login Tokens: Access uses encrypted tokens generated by a secured Linux-based security server that holds the private encryption key, ensuring authentication integrity.
- Synthetic User Model: Support employees do not require permanent user accounts on instances; a temporary synthetic user is created in memory per login session with no persistent credentials.
- Token Specificity and Expiration: Tokens are instance- and user-specific, expire after four hours, and cannot be reused or impersonated, limiting exposure from token theft.
- Comprehensive Logging: All Support employee logins and activities are logged in event and transaction logs, with user names ending in “@snc” for clear identification and auditability.
- Access Verification: The plugin verifies users are active, authorized for the instance, and within the allowed access time window before granting access.
How It Works
When a Customer Service and Support technician requests access:
- The request is validated for proper roles on hi.service-now.com.
- The Security Server verifies the request’s origin and user details, then generates an encrypted token containing user info, roles, instance ID, and timestamp.
- This token is sent to the technician’s browser, which uses it to log into the instance as a synthetic user.
- The instance decrypts and validates the token against user and instance data and access permissions before allowing login.
Key Outcomes
- Enhanced control over who accesses your ServiceNow instances and when, improving your security posture.
- Reduced risk of unauthorized support personnel access, supporting compliance and governance needs.
- Robust audit trails of all support personnel logins and actions, aiding in security monitoring and incident investigation.
- Temporary user sessions with no persistent credentials, limiting attack surface and exposure.
- Clear impact on support service levels and Availability SLA, as access restrictions may delay support unless granted.
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, in their capacity to support and manage the product, and verify usage are required to perform administrative actions on the underlying infrastructure. 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.
- 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:
- A Customer Service and Support technician requests a login for the instance through hi.service-now.com.
- HI checks that the technician has the proper role authorizing access to instances.
- If the user has the proper role, HI sends the request for access to the Security Server.
- 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.
- The Security Server sends the encrypted token to HI.
- Hi sends the token to the Support technician's browser.
- The Support technician's browser initiates a login into the instance, using the special user name ending with @snc.
- 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
- 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.
Audit logging
- 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.