So, we want some applications we made with Perspective to be accessible from the Internet, without the use of a VPN.
All pages require the user to be at least authenticated, with our IdP (Okta)
Is there anything we should check before opening the port? Is it just a bad idea?
If there is anything also I can have to convince others from the IT would be great (if anybody got a security audit, that says it is safe)
As far as SCADA products go, Inductive Automation is really leading the pack in their security maturity. They regularly partake in Pwn2Own, they are transparent in their reporting of vulnerabilities, they are responsive in their release of updates mitigating vulnerabilities, they will share pen test reports if you contact them, they publish hardening guidance.
That said, I would never expose any SCADA product directly to the internet, unless you’re using it purely to produce web pages, and it doesn’t have any access to your industrial control systems.
Reason - all software has vulnerabilities. Expose it to the internet, and they WILL be exploited. When that means your industrial control systems stop working (or worse are controlled by an unauthorised person), the risk typically becomes far too great to justify the convenience.
Sure critical parts are behind an authentication page… but authentication bypasses are all too common. I’m not referring to Ignition specifically - just in general. Remote access by VPN is far more secure, and generally worth the slight inconvenience.
In summary - it comes down to risk vs reward… and in the SCADA world the risk is almost always too high.
Some useful references for you:
In my case, we have multiple sites handling the SCADA and HMI, we are thinking to add a global one with only perspective and the report module, and fetch historian data directly from SQL (with a read only account), so in no case, this server would have access to equipment control.
There is always a risk to open to the Internet, at least with the links I will have something to compare with the tools we already use and accept.
Consider placing a reverse proxy (nginx, haproxy, apache) in the public role, and only forward requests to the actual gateway that correspond to the one public project and the resources it needs. That keeps your gateway configuration interface from being included in the "attack surface".