I’m an on-prem site. To support the use of cloud-based modules like Automation Studio, the Kinetic App server must be exposed to the internet. This also enables browser login to Kinetic from the internet.
Since Insights, I’ve been testing implementation of Azure AD authentication and MFA as a way to better secure the browser login. MFA is working as expected, but I’ve identified a gaping security hole.
The system architecture as of 2023.2.15 requires the use of at least 1 user account configured as a security manager that uses basic authentication. So, while I can decrease the attack surface by making all my other uses utilize Azure AD logins, I will still be left with an administrative account that can login from the outside that is secured only by a password.
At Insights, an Epicor tech pointed out a check-box to Restrict IP -
We use cloudflare to block stuff like this. It gives us a higher level of control over what can and cannot access data from Epicor. I would explore having Cloudflare (or something similar) infront of your Kinetic Instance for external control.
This is a big struggle of ours these days. All these 3rd party products just expect us to open our firewalls for them… that’s a hard no for us. Big reason we always lean towards Epicor pulling or pushing data outbound instead of something pushing data to Epicor (like a webhook, etc.)… That way we can keep our firewall rules that block inbound traffic to our appserver but let outbound data out.
That said, with Automation Studio I believe there is a way around opening up inbound traffic. At least when we were looking into it and raised the issue, some Sales Engineer said there was a way. It may be some kind of agent or something on the appserver but I could be wrong.
I’m not sure how Cloudflare could be implemented to be a solution. I don’t want to block all browser logons, I just want to block any basic authentication logons. Azure AD logons will require MFA.
If you’re going to open your firewall there is the whole network to worry about, not just stuff trying to hit Epicor… Sometimes these products will give you a static IP that their traffic is coming from, and you can whitelist just that IP in an inbound traffic firewall rule. I don’t know about Automation Studio. But again, when we were talking to Epicor a while back we were told that there was some kind of solution, we never got any details on it though, we put that implementation on hold…
As others have mentioned, it’s not recommended to open ports into your internal network. IIS is not equipped to handle Denial of Service attacks for example. In addition to authentication, you’ll want rate limiting, optionally an application firewall, and even some caching to improve remote performance.
There are several solutions of various levels of price/performance:
Local Agent
The least expensive is a local agent. There are many examples of an agent running locally and maintaining a connection to a remote service:
Workato/Automation Studio
Kinetic EdgeClient
GitHub Actions Job Runner
Microsoft’s SQL Connector for PowerBI, Azure Arc Agent, etc.
All of these maintain a connection to a remote resource to perform commands and queries.
Gateways
The next level up would be gateways. Gateways accept requests on behalf of the internal system to/from the Internet. These map external URLs to internal ones, require authentication to access, perform rate-limiting, and may even do some response caching. Cloudflare and Microsoft / provide these services. Here’s John Savill on YouTube doing a deep dive on Application Gateway.
Secure Access Service Edge
The latest incarnation of remote access is the Secure Access Service Edge. Instead of using firewalls and gateways, everything is managed in an “overlay” network. All non-local traffic moves through this network no matter where the device is. Since all movement is tracked, the company has the ability to apply proper authentication, authorization, and logging. Cloudflare provides SASE as well. Here’s another video from John Savill explaining how Microsoft SASE works.
@Mark_Wonsil do you know much about MTLs certificates? It is something we’re looking at for an integration where we want to hit Epicor API from the outside but there is no local agent option and the source of the traffic does not have a static IP(s) that we could whitelist. I believe the solution we’re going with uses MTLS and the Azure Application Gateway, but I don’t know the details.
Sorry, I have not used them. Everything I’ve looked at uses Entra to authenticate to the API and the API to authorize usage based on identity. Are the remote entities users or another system?
Ecommerce platform with serverless architecture. In the API call I use an integration account and configure Access Scope to give it minimal permissions, but it’s basic Auth (been meaning to look at Entra auth…). But the big concern was just opening up inbound traffic to our appserver. We could limit traffic to port 443 but that doesn’t buy us much security.
Infrastructure team seemed happy enough with the MTLs approach. As I understand it only allows inbound traffic through if the remote client has the MTLS certificate. So I think there is still risk of someone getting their hands on the cert but at least the firewall isn’t open…
While Epicor Administration Console has configuration fields that indicate that it can work with Azure AD Authentication, when I was unable to make it work, I was told by support to use a basic authentication account. I was also told that the account must be a security manager account.
I’ve succeeded in getting the Admin Console to work with Entra (Azure AD) at both 2023.2 and 2024.1. Though I would have set everything up as basic and Entra first, made sure Entra worked fine and then switched over to purely Entra.
So I think you may have been misled slightly.
