Mid-sized companies are being targeted these days by plenty of ads for “IT security in business”. Focus is on securing data and protecting the IT infrastructure against external attack. Daily headlines about hacker attacks are drawing attention to the vulnerability of one’s business at a fundamental level.
For an internal ERP system, however, the data security concept ought to give equal importance to how its user permissions are set up. Because of its complexity this issue is often neglected, although it holds a great potential for harm. Even disregarding any criminal intent of employees who might want to steal or manipulate sensitive data, it should be clear that sensible, role-based granting or limitation of access for individual users is a critically important administrative task.
Defining user rights helps, after all, to avoid errors and to increase data quality, since only entitled (= competent) users can perform certain transactions.
The ERP system Microsoft Dynamics NAV, for example, allows you to adapt which features will be available to a user depending on that user’s permission settings. This greatly improves usability, because each role in a company will only use a fraction of the functions of a typical ERP system. Therefore, many companies have adopted high compliance standards for data access, which have to be guaranteed by a sophisticated access concept.
A number of important updates in this vein have made their way into the NAV standard with the release of NAV Version 2016. Some of these solutions had already existed in partner solutions. Microsoft has now consolidated these into a new release. Unfortunately, they did little to announce these functions, and most of us have had to stumble upon these “hidden features” by accident.
To summarize the most important changes:
It is possible to define specific permission roles. These roles can be assigned to permission sets that precisely control access to a system object (table, table data, report etc.). This administrative level makes configuring new users much more efficient, by having preconfigured roles to choose from.
Matrix views show quickly and clearly which users have been assigned to which groups.
The creation of permission sets has also been simplified. A “recording” mode now lets the authorization administrator select the necessary system objects by simply running a session and working with the system the way a given user will work with it in future. Thus, the system objects are logged and summarized in a permission set. A user assigned to that permission set will then have exactly those permissions (read, write, execute, delete) that the administrator accessed while recording the model use of the application.
