It seems that security manager can do whatever they like and go wherever they like in Epicor.
Further it seems that you need to be security manager to edit menus, or to setup new users. As a result HR or IT type folks can go whereever they want?
I thought I could create a group, make a security manager a member of that and only that group, then set deny access to that group on certain menu securities. But “security manager” rights hold sway and still can go anywhere, do anything.
(Yes i know a security manager can change their own security groups etc and eventually go anywhere as a result, but that at least could be audited…)
Of course, this isn’t just a problem with our ERP systems, but all of our systems. We can block access at the application layer, but if a database administrator has a copy of the database…
The current line of thinking is having no admins per se but have people who could be admins for a given period of time and log all activity during that time span to immutable storage. In the Zero Trust world, this is described as just enough access for just enough time. Microsoft calls it Privileged Identity Management.
SaaS users have an extra level of security, because there is a Global Security Manager that is higher than the Security Manager. The attack surface is reduced unless you have @klincecum as an employee. This means a local admin would have a potentially more difficult task to do something suspicious without being caught by an audit trail.
TBH, reports are REALLY hard to protect. It wouldn’t take much to write a Directive that emails a copy of a report when it’s run (or bcc a copy) or use Advanced Print Routing to do the same. The raw data is in the SSRS report tables if you’re on-prem. Finally, the bytes for the report are stored (at least for a little while) in Ice.SysRptLst.RptData, and if you know the report ID, you can download with a PowerShell script.
Like @CSmith and @Hally suggested, audit logging and alerting are your best friend. BPMs can limit Security Managers, but they can disable them too.
Back in the 00’s, there was no admin access to Production where I worked. If you needed it, you had to request it and they gave you a password that would expire to the standard account that everyone had to use.
Someone will always have the all keys to the castle, the trick is how to make sure those people are trustworthy and will follow procedure. If you worry about the people you give security manager access to you have a bigger problem.
I was MIS manager back when it was called MIS and I could have looked at everyone’s salaries but I knew not to. Early on accounting/finance typically was the IT department and so they had the keys and could control who had access to the books. Now that IT is separate from most departments they have the keys to everything. Good procedures can cover most of it, the rest you can implement audit trails and the like. If you could make it bullet proof you will likely get a system that no one wants to use or is wildly inefficient.
Thanks all, I’m not looking for a system that’s bullet proof, just one that makes it slightly difficult to do something you shouldn’t, even accidentally (eg without going and changing security settings). Having users presented with menu items they hopefully know they shouldn’t use seems a bad idea. Like Microsoft providing bookmarks to pornhub in their default Edge installs…
I considered not giving anyone sec mgr but having them log into a dedicated sec mgr account when they need to, but then you lose all audit on who did what.
For everyday users they should only get the access they need. But someone needs to have the keys to the castle, those people need to be trustworthy. For me they should only do things under their own account so an audit can track them without extra effort such as keeping a log of who had access when.. If we give them access only as long as they need it that still means someone has to be giving that access so we are back to someone has the keys to the castle.
And any programer that you have working on the system by default has to have access to the entire system they log into, if they didn’t they wouldn’t be able to get much done. For that, someone should be auditing their code and a programer/developer should not have access to production/live. The catch 22 is many small companies don’t have enough people to enforce that strict of safeguards. The developer is frequently a security manager/administrator of all systems. As a consultant I do my best not to have access to Production but even there with small clients they do sometimes ask me to do some administrative work such as releasing code.
