Contents Now Platform Administration Previous Topic Next Topic ServiceNow access control ... SAVE AS PDF Selected Topic Topic & Subtopics All Topics in Contents Other Share ServiceNow access control This SNC Access Control plugin (com.snc.snc_access_control) enables customers to control which ServiceNow employees may access their instance, and when. When the plugin is first activated, ServiceNow employees cannot log into the customer's instance. Any currently logged-in ServiceNow employees remain logged in. The customer creates records in the SNC Access Control table that grant access to specific SNC employees or all employees. Login security Security for authorized ServiceNow employee logins to customer instances employs encrypted tokens generated by a secure server. Only properly authenticated ServiceNow employees are granted access to a customer instances. 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 our customers to determine precisely which ServiceNow 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 our customer's instances: Security server: The security server is a locked-down, Linux host that can only be accessed by ServiceNow security personnel. 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 the HI instance is compromised by an attacker. Synthetic users: The facility on customer instances that enables authorized ServiceNow 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 ServiceNow employee logon. This user exists only in memory and provides no ongoing privileges. ServiceNow can deauthorize any ServiceNow employee at any time, and if the SNC Access Control plugin is enabled, our customers can also deauthorize any ServiceNow employee at any time. Tokens: The security tokens are specific to a customer instance and a particular ServiceNow employee. In addition, the mechanism that generates the tokens only works with actual ServiceNow employee logins to HI, not impersonated users. Once a security token is generated, it may only be used by a specific ServiceNow employee to log into a particular customer instance. Time limit: Security tokens expire four hours after they are generated. This limits the utility of hijacked tokens, which can only be used during this short window. Logging: Logins by ServiceNow employees to customer instances are recorded as a login event, and every action taken by the logged-in ServiceNow employee is added to both the transaction log (in the database) and the instance log (on the file system, which is inaccessible to most ServiceNow employees). ServiceNow employee logins and actions are readily identifiable, since the user names all end in @snc (like frodo.baggins@snc). This provides our customers with easy-to-use, robust, and reliable security logging for non-employee access. When a ServiceNow employee wants to log into a customer instance, the security processing flow is as follows: A ServiceNow Support technician requests a login for the customer's instance through hi.service-now.com. HI checks that the technician has the proper role authorizing access to customer 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 HI's 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 on the customer instance, 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 customers instance, using the special user name ending with @snc. The customer's 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 customer 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 Audit logging The following logging tracks logins and activity by ServiceNow employees: Event logs: The event logs show all ServiceNow logins to a customer instance. Transaction logs: The transaction logs show all activity on the instance, including any efforts to delete logs. On this page Send Feedback Previous Topic Next Topic
ServiceNow access control This SNC Access Control plugin (com.snc.snc_access_control) enables customers to control which ServiceNow employees may access their instance, and when. When the plugin is first activated, ServiceNow employees cannot log into the customer's instance. Any currently logged-in ServiceNow employees remain logged in. The customer creates records in the SNC Access Control table that grant access to specific SNC employees or all employees. Login security Security for authorized ServiceNow employee logins to customer instances employs encrypted tokens generated by a secure server. Only properly authenticated ServiceNow employees are granted access to a customer instances. 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 our customers to determine precisely which ServiceNow 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 our customer's instances: Security server: The security server is a locked-down, Linux host that can only be accessed by ServiceNow security personnel. 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 the HI instance is compromised by an attacker. Synthetic users: The facility on customer instances that enables authorized ServiceNow 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 ServiceNow employee logon. This user exists only in memory and provides no ongoing privileges. ServiceNow can deauthorize any ServiceNow employee at any time, and if the SNC Access Control plugin is enabled, our customers can also deauthorize any ServiceNow employee at any time. Tokens: The security tokens are specific to a customer instance and a particular ServiceNow employee. In addition, the mechanism that generates the tokens only works with actual ServiceNow employee logins to HI, not impersonated users. Once a security token is generated, it may only be used by a specific ServiceNow employee to log into a particular customer instance. Time limit: Security tokens expire four hours after they are generated. This limits the utility of hijacked tokens, which can only be used during this short window. Logging: Logins by ServiceNow employees to customer instances are recorded as a login event, and every action taken by the logged-in ServiceNow employee is added to both the transaction log (in the database) and the instance log (on the file system, which is inaccessible to most ServiceNow employees). ServiceNow employee logins and actions are readily identifiable, since the user names all end in @snc (like frodo.baggins@snc). This provides our customers with easy-to-use, robust, and reliable security logging for non-employee access. When a ServiceNow employee wants to log into a customer instance, the security processing flow is as follows: A ServiceNow Support technician requests a login for the customer's instance through hi.service-now.com. HI checks that the technician has the proper role authorizing access to customer 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 HI's 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 on the customer instance, 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 customers instance, using the special user name ending with @snc. The customer's 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 customer 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 Audit logging The following logging tracks logins and activity by ServiceNow employees: Event logs: The event logs show all ServiceNow logins to a customer instance. Transaction logs: The transaction logs show all activity on the instance, including any efforts to delete logs.
ServiceNow access control This SNC Access Control plugin (com.snc.snc_access_control) enables customers to control which ServiceNow employees may access their instance, and when. When the plugin is first activated, ServiceNow employees cannot log into the customer's instance. Any currently logged-in ServiceNow employees remain logged in. The customer creates records in the SNC Access Control table that grant access to specific SNC employees or all employees. Login security Security for authorized ServiceNow employee logins to customer instances employs encrypted tokens generated by a secure server. Only properly authenticated ServiceNow employees are granted access to a customer instances. 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 our customers to determine precisely which ServiceNow 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 our customer's instances: Security server: The security server is a locked-down, Linux host that can only be accessed by ServiceNow security personnel. 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 the HI instance is compromised by an attacker. Synthetic users: The facility on customer instances that enables authorized ServiceNow 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 ServiceNow employee logon. This user exists only in memory and provides no ongoing privileges. ServiceNow can deauthorize any ServiceNow employee at any time, and if the SNC Access Control plugin is enabled, our customers can also deauthorize any ServiceNow employee at any time. Tokens: The security tokens are specific to a customer instance and a particular ServiceNow employee. In addition, the mechanism that generates the tokens only works with actual ServiceNow employee logins to HI, not impersonated users. Once a security token is generated, it may only be used by a specific ServiceNow employee to log into a particular customer instance. Time limit: Security tokens expire four hours after they are generated. This limits the utility of hijacked tokens, which can only be used during this short window. Logging: Logins by ServiceNow employees to customer instances are recorded as a login event, and every action taken by the logged-in ServiceNow employee is added to both the transaction log (in the database) and the instance log (on the file system, which is inaccessible to most ServiceNow employees). ServiceNow employee logins and actions are readily identifiable, since the user names all end in @snc (like frodo.baggins@snc). This provides our customers with easy-to-use, robust, and reliable security logging for non-employee access. When a ServiceNow employee wants to log into a customer instance, the security processing flow is as follows: A ServiceNow Support technician requests a login for the customer's instance through hi.service-now.com. HI checks that the technician has the proper role authorizing access to customer 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 HI's 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 on the customer instance, 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 customers instance, using the special user name ending with @snc. The customer's 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 customer 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 Audit logging The following logging tracks logins and activity by ServiceNow employees: Event logs: The event logs show all ServiceNow logins to a customer instance. Transaction logs: The transaction logs show all activity on the instance, including any efforts to delete logs.
