Data Import Process - ServiceNow

Data Import Process

Data is not imported directly from a Data Source into the target table. The steps are:

1. Load Data into a staging table
2. Create Transform Map
3. Run Transform to move data from the staging table to the target table
4. Check data integrity

Use Studio to create Data Sources. All other data import operations are done in the main ServiceNow browser window and are not captured as part of a scoped application.

Securing Application Access Summary

Securing Applications Against Unauthorized Applications Module Recap

Core concepts:

• Runtime Access Tracking manages script access to resources from other applications
  • Table
  • Script Include
  • Scriptable
• Runtime Access settings are:
  • None
  • Tracking
  • Enforcing
• Application Access controls which scope(s) can perform database operations against application tables:
  • This application scope only
  • All application scopes
• Application Access restricts database operations:
  • Can read
  • Can write
  • Can update
  • Can delete
• Can disable table access by web services
• Restrict whether out-of-scope applications can create application files:
  • Business Rules
  • New fields
  • Client Scripts
  • UI Actions

Securing Applications in ServiceNow

Securing Applications against Unauthorized Users Module Recap

Core concepts:

• Scoped applications can be secured at the application, application menu, and module levels
• Groups are a set of users with a common purpose
• Assign roles and users to groups
• Groups and user records are not part of an application
• Access Controls grant access to records and record fields
  • Create
  • Read
  • Update
  • Delete
• Debug Access Controls with the Debug Security Rules module
• Impersonate users to test security
• Access Control roles are evaluated first, then conditions, then scripts
• Roles, conditions, and scripts must all return true for an Access Control to grant access
• Do not attempt to protect sensitive data with client-side scripted security

Scripting Security - Usefull APIs related to check the users roles and security

Scripting Security

Both the client-side and server-side APIs have methods for scripting security.

The client-side GlideUser (g_user) API has these methods:

• hasRole()
• hasRoleExactly()
• hasRoleFromList()
• hasRoles()

The client-side API methods can be used in any client-side script such as Client Scripts and UI Policy scripts. Client-side security is the easiest security to break. Do not depend on client-side scripts to secure sensitive data.

The server-side GlideSystem (gs) API has these methods:

• getUser()
• getUserID()
• getUserName()
• hasRole()
• isLoggedIn()
• isInteractive()
• getSession()

The server-side GlideElement API has methods to check whether a user’s role allows them to access the associated GlideRecord(s):

• canCreate()
• canRead()
• canWrite()

The server-side methods can be used in any server-side script such as Business Rules or Script Includes. Server-side scripted security is more secure than client-side scripted security. Any user with access to scripting fields can see the scripts and see what the security checks are.

Neither client-side nor server-side scripts are part of the Debug Security Rules module. When security is scripted outside of Access Controls, it must be debugged independently of the Access Controls.

For the highest level of security, use Access Controls to protect sensitive data.

Debugging Access Controls servicenow

Debugging Access Controls

To enable Access Control debugging, use the Application Navigator in the main ServiceNow browser window (not Studio) to open System Security > Debugging > Debug Security Rules. The Debug Security Rules module runs a script that enables writing all Access Control debugging information to the bottom of each page in the content frame.

Only admin users have access to the Debug Security Rules module. In most cases, Access Controls need to be debugged for users other than the admin user. After enabling Debug Security Rules as an admin user, impersonate a user to test their access.

In this example, Beth Anglin is denied access to Field 3 on Table in the Generic application:

The first row states the overall evaluation of the Access Control: Grant or Deny. The Access Control is a read Access Control for Field 3.

The second row shows the evaluation of the table-level Access Control followed by the field-level Access Control. In this case both the table-level and field-level Access Controls are shown to make it clear which Access Control denied access.

The debugging information is shown in order of evaluation:

It is important to examine both the color code and the symbols.

• Green: Access granted
• Red: Access denied
• Blue: The rule did not have to be re-evaluated because the result is already in the cache
• Gray: Not evaluated, typically because part of the rule has already denied access
• Check mark: Passed
• X: Failed

The system-level access check is not part of an Access Control. It runs before Access Controls are evaluated and looks for system/runtime reasons why a user should or should not be granted access. For example, Delegated Development grants developers permission to create only certain types of application files. Fred might be able to create Business Rules but Beth cannot. Permission to create application files in a Delegated Development environment is not controlled by Access Controls and is determined at runtime by a system-level access check.

Look again at the Field 3 Access Control for Beth. Her access to Field 3 was denied by the role on the field-level Access Control even though the table-level Access Control granted access. The condition and script on the field-level Access Control were not evaluated because the role denied access.

To disable Access Control debugging use the Application Navigator in the main ServiceNow browser window to open System Security > Debugging > Stop Debugging. If you have impersonated a user, impersonate the System Administrator to disable Access Controls.

DEVELOPER TIP: The Admin overrides option in Access Control configuration grants access to the admin user even if the admin user doesn’t meet the requirements of the Access Control. Use caution when testing Access Controls as the admin user as it may not be indicative of the Access Control’s behavior.

Debug a Single Field’s Access Controls

To debug the Access Controls for a single field rather than the entire content frame, with Debug Security Rules enabled, open the table’s form.

A Debug icon () appears next to each field. Hover over the Debug icon to see how many Access Control messages there are for the field. Click the Debug icon to see the Access Controls for that field. This strategy, obviously, cannot be used to debug fields that are hidden by Access Controls.

Creating and Editing the Access Controls in Servicenow

Creating and Editing Access Controls

Users with the admin role can view Access Control records but cannot create, delete, or update Access Controls. All Access control operations except read require elevated security privileges. Elevated security privileges are also known as the security_admin role.

Elevate security privileges in the main ServiceNow browser window (not Studio). Open the User menu in the banner and select Elevate Roles.

In the Elevate Roles dialog, select security_admin then click the OK button.

The security_admin role times out. Depending on how long you are working on Access Controls, you might have to elevate privileges several times.

Access Controls can be created for:

• Records
• Client callable Script Includes
• Processors
• REST Endpoints
• UI Pages

This module discusses Access Controls for records.

There are four sections in Access Controls:

• Table/field
• Requires Role
• Condition
• Script

In order for permission to be granted to access a table/field, the Requires Role, Condition, and Script sections must all return true. If there is no value, the section returns true.

Table/Field

Use the Name field in the Access Control configuration to specify which records and which field are secured. In the example, the Access Control grants write access to the NeedIt table’s Requested for field.

The example rule is a write rule:

Write: [NeedIt] [Requested for]

Requires Role

Use the Requires role list to specify the role(s) required to access records. Click the Insert a new row… line to add a role to the list. If there are multiple rows in the list, the user must have only one of the roles for Requires Role to return true.

To remove a role from the list, click the red X in the role’s row. Clicking the X removes the role from the Access Control but does not delete the role from the database.

Condition

Use the Condition field to create the condition(s) required to grant access. In this example, the Requested for value must be the currently logged in user.

The condition is tested dynamically and the number of matching records in the database is reported. Click the link to open a list of matching records in a new tab. Click the double arrow icon to refresh the count.

Script

Select the Advanced option to see the Script field.

Access Control scripts execute server-side. For best performance, avoid Access Control scripts that use GlideRecord queries as they can adversely impact performance.

Restrict the script logic only to security-related logic. If other logic is included, such as managing date formats or validating record data, it can be difficult to debug problems in the future as you might not think to look in Access Control scripts for those actions.

Some useful methods for Access Control scripts include:

• GlideSystem: getUser(), getUserID(), getUserName(), hasRole(), isLoggedIn(), isInteractive(), getSession()
• GlideRecord: isNewRecord()

Access Control scripts must set the answer variable to true or false.

if (!gs.hasRole("admin") && !gs.hasRole("user_admin") && gs.getSession().isInteractive()) {
 answer = true;
}
else{
 answer = false;
}

Securing Servicenow application using access control at the table level

Securing Table Records

Tables

When creating tables in scoped applications, you must assign a role to the table. Specify the User role in the Controls section of the table form. You can dynamically create a new role or assign an existing role.

For all scoped application tables, the Create access controls option is selected and is read-only. The combination of Access Controls plus roles provide the minimum amount of security to protect a table’s records against unauthorized access. In the default case, only users with the table’s role can create, read, update, and delete table records.

Access Controls

Access Controls restrict access to data by requiring users to pass a set of requirements. Access Controls define:

• What is being secured
• The operation being secured
• The permissions required to access the object

Access Controls are automatically created when tables are added to scoped applications. The four default Access Controls grant access to the table’s records. Permission is granted for these operations:

• Create
• Read
• Write
• Delete

To be granted access by the default Access Controls, a user must have the User role specified for the table.

The default Access Controls grant permissions for entire table records; there are no default restrictions for record fields.

ServiceNow is default deny unless configured otherwise. Permission must be explicitly granted by Access Controls for a user to have access to records and record fields.