This is our first blog and we are going to write on an area that gets overlooked in most of the implementation – access. Companies generally implement NetSuite very early and in the hyper-care period (right after go-live till the system is fully functional without any issues) every user tend to have increased level of access. Unless a focused effort is made to reduce such level of access many users tend to have administrator or full access.

Similarly, even non-standard roles originally built with focused access restriction and segregation of duties tend to dilute over a period of time. When a user needs additional permission, the role may be changed – sometimes without consideration of whether there are other users sharing the same role.

Although these require further discussions and considerations, for this blog we want to bring nuances in access that we should be aware of as NetSuite control professionals and administrators.

Global Permissions

These are permissions that can be granted specific to a user irrespective of which role they access from. This functionality is very handy as it provides an ability to not have a custom role for every individual nuance we need to have in a truly global company.

Role level considerations

Center

NetSuite help field includes this text for Center – A role’s center type determines the way tasks are organized on tabs. Similar roles, such as sales roles, share the same center.

Leveraging a custom role creates a role that looks unique but that should not be confused as access restriction by itself – any user could change their own role to the Classic center (the basic center) by going through their own individual preference. This may expose the role to any public searches or other custom functions that have not been properly secured.

Subsidiaries – combined with Allow Cross subsidiary Record Viewing

Limiting a role to only specific subsidiary allows only restricted confidential information is shared. This is may also be considered when the approvers should be restricted to approve on objects belonging to specific subsidiary and the workflow relies on who has access to the role. It is critical to understand this restriction and leverage it. Please remember that there are certain records that are not included in this restriction such as employees.

Allow cross subsidiary record viewing allows users to see, but not edit, records for subsidiaries they do not have permission.

Employee restrictions &Do not restrict employee fields

These fields provide fine-tuned ability to provide access to only their own records or only records to their own hierarchy.

Set Department, Class and location restrictions.

Similar to the above, user role can be restricted to only specific department, class or locations.

Restricting Accounts for roles

This may be used in a true large enterprise scenario where a role should be able to access only certain accounts. Although this may create administrative challenges we recommend you evaluate it too.

Authentication related fields

Web services only role

This is a powerful and often overlooked security feature – a feature to mark a role not eligible to login through UI. This reduces the probability of this role and corresponding access being misused through User Interface.

Single Sign on only

Similar to Web services, marking this as an SSO only role disallows a user to use the role when they have not logged in using SSO. This setup further tightens the control environment.

Restrict by IP address

For example, if you have integration account that connects from a specific IP range, setting this restriction allows reduced risk due to credential compromise.

2FA

We will follow up with a detailed post on two factor authentication and the upcoming changes that will affect them. Stay tuned.

Applying role restrictions for custom records

Given the extendable nature of NetSuite, custom records provided additional data points and in many cases, data in the custom records are used for critical decisions. Also, scripts could leverage the data in the custom records to manipulate standard NetSuite objects. In that sense, access restrictions to custom records are of equal importance as standard NetSuite objects.

There are three options for Access Type and we recommend selecting ‘Require Custom record entries permissions’. This will allow the administrator to handle access through the natural set permissions screens in the role record and will allow for easy and effective administration of these records.

Permissions

Not all permissions are created equal and we feel these permissions are sensitive and should be appropriately restricted.

• Financial history
• Financial Statements
• Report customization
• Report Scheduling
• Access Token Management
• Allow Non G/L Changes
• Bulk Manage Roles
• Custom Record Types
• Custom Transaction Types
• Enable Features
• Accounting preferences
• Financial Statement Layouts
• Manage Custom Permissions
• Manage Users
• Other Custom Fields
• Override Period Restrictions
• SuiteApp Deployment
• SuiteAnalytics Connect
• SuiteBundler
• SuiteScript
• Workflow

In  NetSuite, the term ‘Permission’ is used to provides access to specific objects but ‘Restrictions’ restricts access to only specific records.

Restricting access to specific forms

Each transaction can be accessed through different forms. Each form can be configured very differently allowing only certain fields to be viewed or marking the fields read-only. These forms can also provide restricted access to selections – for example, only a few items are available to be picked in a PO form (say through a saved search) and can also be scripted to provide refined access. A role can then be restricted to only this form to allow specific access behavior.

Terminating a user

Currently, as of 2018.1, a user who is marked terminated with access can still login to the application. Hence it is critical that an alert is set up to identify such instances and access removed immediately.

Marking an employee as inactive

On termination, it may be convenient to mark the employee as Inactive. This will automatically remove user’s access to the system. But care should be given to few other considerations before marking an employee as ‘Inactive; – this includes difference in allocations, potential integration issues of say expenses of the user that are still pending approval in a different system, workflow records that are pending their approval, etc.

Users restricting access by themselves

If a user wants to see a subset of information they have access to they can do that using the preference option. This is not considered an access restriction but as an auditor, if you are performing a walkthrough and relying on access restrictions, please also confirm that this setting has not be enabled.

Custom Center Tabs and their permissions

Creating custom center tabs is a great way to group certain transactions, reports or links in one place – the most common use is creating a custom center tab so that all the reports that are used by the team is grouped properly. Care needs to be provided to make sure not all users in the company have access to these tabs. Searches that are marked public may inadvertently be exposed.

New features, add-on center tabs,and permissions

Similarly when a new feature is added to an existing module or if a suite app is installed new centers, new center tabs and permissions should be reviewed.

 

Saved Searches

• In many cases, saved searches are created with access to Public. This may create situations where excessive information is available to specific users. For example, if you have a user who has access restricted by specific location/department but if they have underlying access to a specific object (say vendor bills), marking a report as Public will allow this user to see all the information irrespective of the location restriction.
• Similarly, marking the report as ‘Run Unrestricted’ will completely ignore the underlying permissions of the users and will show the results. Consider the potential impact of excessive business data available to all users – for example, should a sales person know sales for the whole company or just for his own team?

Similarly allowing users to edit the search needs to be thought through – unfortunately system currently does not allow restrictive access to only a few users to edit and others to view reports. Clearly, SOX in-scope reports should be locked down.

Reports

In reports, care needs to be given whether the access to a custom report should be given through ‘Audience’ or ‘Access’ sub-tab. Providing it through ‘Audience’ sub-tab will make sure the report access is restricted to only those users who have access to the standard report on which the custom report is based – hence respecting the permissions set up at the role/global permissions. But giving access to through ‘Access’ sub-tab may increase the risk of incorrect access.

Groups

Creating groups is a great way to manage access to certain report and searches in a team that have frequent changes. There are static groups for which the list of users are predefined and dynamic group for which the users can be defined based on several criteria (example, users in a specific department). NetSuite provides sophisticated ways to create and manage groups. Even the most basic static group is more efficient in providing access compared to individually assigning access to users to reports and searches.