Long before I donned a jacket with elbow patches and professed for a living, I spent a decade as a consultant. I helped organizations implement new enterprise resource planning (ERP) applications. I focused on the HR/payroll side of the house, but throughout my years I noodled with financial and supply-chain modules as well.
When teaching classes to new or prospective clients on how to use different applications, invariably someone would ask me: What about security?
Record-level security: No shortage of options
Such an innocuous question with so many different answers.
Top-notch ERP applications such as PeopleSoft, Lawson (now part of Infor), and Oracle allowed admins to lock down their data in multiple ways. For starters, it wasn't tough to restrict users from accessing entire modules. Sorry, Jerry, you can't view any data in payroll. (No soup for you.)
Admins could also prohibit users from doing individual things. These include creating, reading, updating and deleting individual records. (This is also known as CRUD.) For instance, perhaps Kramer could view or read Elaine's employee record but not update it.
Next, consider role-based security. This isn't hard to understand. A payroll manager ought to be able to do things that a customer-service rep cannot.
Then there's security by division or department. Sometimes the head of Department X could see all financial, customer or employee data in her department but not parallel data in Department Y.
Another club in the bag was record-level security. Maybe George the payroll manager could make database changes (via the front end or application) to everyone but his manager, Tim. In fact, what if George wasn't even able to view Tim's information. In other words, it exists in the database but George doesn't get to see it.
Perhaps it looked something like this:
Note that record-level security should exist throughout the entire application. That is, if done right, there's no way around it. Let's say that George can't view Tim's rate of pay and social security number via the application. As a result, the former shouldn't be able to circumvent security by running an employee listing or another standard report.
The same holds true for creating ad hoc reports, although all database drivers would not enforce this rule. In my Lawson days, using Open Database Connectivity (ODBC) rendered Lawson's security moot. As a result, IT folks were particularly persnickety about granting access to this tool.
Simon Says
In my experience, IT departments typically took an all-or-nothing approach to security. For whatever reason, employees either had access to all financial data in a system or none of it. Those that took the time to really think about different security profiles tended to take compliance issues seriously.
Feedback
What say you?
