The only advice that many IT specialist emphasised on is do not open this port and/or allow these calls to point at your SQL server, i.e. if your IIS/ Epicor App server installed on the same SQL server as per Epicor recommendation for company below 50 users, then install an extra one in different location (server) and mount it to the SQL server, i.e. the servers you open port 443 to, should be away from your DB server and preferably on a server away from your day to day activities.
We have two app servers already and each has their own VM server separate from the one that hosts SQL Server. I’m open-minded about a third app server, having noted the Epicor hint, but I can’t see it would achieve very much in our case - adding external-facing duties to the secondary one already in place would do much the same job.
Thinking rationally about the security issues, there is no way to open access to the ERP without external systems being able to affect our internal ones, because that’s the point of doing so, and putting extra pieces in the chain between external and internal doesn’t in itself change that.
So my cautious conclusion is that it’s wise to let the Epicor system handle the “clever” parts of the security rather than try to re-invent that part of the wheel, and try to stop it having to deal with crude problems by means of some relatively dumb device in a bouncer role. I’m interested to note that the replies above are along those lines. But I’m keen to hear anyone else’s experience having actually implemented any of this stuff.
we will implement it soon, but as i explained as long as your SQL server is protected, then i agree with what you saying, and this layer of security designed as a part of general IT risk and recovery plan to avoid any possible hacking to the SQL database, beside in my environment i am allowing REST reading calls only i.e. ONLY GET command, all other commands only work from internal domain.
You probably know what I’m going to propose but because our ERP10 is in Azure, it would make sense put the public portion of the interface you want to expose in Azure or SharePoint Online and let Microsoft handle the front-end issues for you. You can use Azure Active Directory to create accounts separate from your local AD. You would then create a gateway in Azure to your on-prem server and now your ERP system can listen on that one IP in Azure filtering out undesirable traffic.
This would also give you the added benefit of encapsulating your business logic from Epicor so if you were to buy a new company, upgrade versions, or switch even ERP vendors, you would just have to rewrite the code behind the interface to your customers/suppliers.
Interesting thoughts, and I have been looking, slightly naively at this point, at something along those lines. It’s a steep learning curve, but probably close to the definitive solution for the future. We are actively looking more at Azure, even though we have already concluded it isn’t the answer we need for Epicor directly at least for the next year or two, so hybrid solutions are looking increasingly attractive.
We’re still exploring right now, though, and the immediate need is only to expose dev to the outside world. So I think we’ll be able to be a bit simpler than this at first.
So the way we chose to do it was to expose a middle-ware service which tightly restricts which data / service endpoints are accessible and how.
Granted,this was before Access Scope was available, we also chose to ONLY expose the BAQ/UBAQ and (now available) Functions End Point.
The regular BO endpoint we chose to keep private. (IMO Too much RISK)
This way we can tightly regulate exactly what is available on the DMZ and to whom. We white list the BAQ’s we want available and match them up with assigned Keys for each vendor/resource (ALA Access Scope)
Again using regular access scope will probably solve most of these issues, but we really didn’t want to expose the BO’s at all (A bit paraniod perhaps).
This is re-inventing the wheel and I’m not saying my wheel is better than Epicor’s but we wanted to be able to tightly restrict the data access and in the event of someone being suuuper determined we didn’t want to expose our app server directly in the DMZ.
With exposing this facade even via brute forcing they shouldn’t be able to access anything beyond the very limited white listed BAQs/UBAQs we expose.
Eventually we will be doing this too via this middleware api. Trying to figure out the function libraries in 10.2.500 but it seems like a good fit for this roadmap
Yeah @Aaron_Moreng we added Functions into the middle-ware once 500 came out, we are not live in 500 yet but once we are it will support BAQs/UBAQs and Functions.
That’s useful, thanks. I thought I’d seen something like that post somewhere but couldn’t find it when I went looking.
In general terms I’d always want to go through BAQs and uBAQs. It’s saved us a lot of headaches working that way within the domain and I wouldn’t want to change for external access. I’m not sure how feasible it is for us to mirror what you’ve done, though it would be nice to. Best of all worlds would be that same functionality but off-premise before the calls ever reach our server, but we’re nowhere close to that yet.
We are on the GOVT Cloud. Epicor 10.2.700.12
I am hoping someone reading this can identify with our predicament and empathize.
We have discovered there are some personnel accessing the Epicor database to mine Engineering data (BOMs, primarily) I MUST put a stop to this, and I am getting little assistance from Epicor.
They do not have any Two Factor Authentication available, and I am not so sure that would solve the issue.
I also started pursing the “Access Scope” feature in User Account Maintenance and find little regarding that.
I want to prevent the access via API to the software.
Any recommendations? Please note, I know just enough to be dangerous in some areas in this regard.
Any kind attention is appreciated.
Yes, basically. The access is attained via a generic VPN with nothing more than an Epicor ID and PW. Would Access Scope be a constructive avenue? I have experimented a bit and I am quite concerned regarding the crashing of the active home page…
How do they have VPN access? Your vpn should have 2 factor first
Second access scope can help but only for v2 unfortunately v1 of the api is still there and enabled by default
It is also used by kinetic home page so you can’t easily disable it
You can turn up your Epicor password complexity (and should)
Do these personnel have access to the BOM via engineering workbench or other screens? If they aren’t taking security seriously than they will have additional opportunities to cause problems and they will need to be trained to take security / secrecy seriously.
If they have no legitimate reason to be working with BOM’s than it seems like termination and perhaps involving law enforcement might be required depending on what your company works on.
Are you running Microsoft 365? Or do you have Azure AD enabled? If so, you can have multi-factor authentication on your Epicor logins as Epicor supports Azure AD authentication (hopefully more OAUTH in the future.)
Passwords are the weakest link and the industry is moving away from them. Microsoft can do authentication without passwords and now Cisco’s DUO can too.
If you are asking about Service security, it is possibility to restrict access to specific service or method.
It is located in System Setup\Security Maintenance\Service Security Maintenance.
There you can select service, and who can have access to it.
