Hardening the management portal - does this approach make sense?

Question

Question

Hello community,

in addition to HL7 V2 interfaces mediated via TCP/IP, we have been implementing more and more HS.FHIRServer.Interop.Service based services that are addressed via port 57772.
We would like to secure access to the Management Portal now and have come up with a procedure that I would like to discuss.

1. The local server firewall only allows access to port 57772 for the IPs of the administration PCs (and some few other exceptions).
2. A REST service is introduced for access to FHIR endpoints, which listens on a different (accessible) port. This service acts as a proxy and checks the URL suffix to see if a FHIR endpoint is accessed and forwards it to localhost:57772/[FHIR URL]. If not, a 403 is returned. In addition to the existing access control with user credentials this also allows us to restict access with the "Allowed IP Addresses" setting.

The description is somewhat simplified and is only intended to explain the concept. A proof of concept worked and performed quite well. Would you consider this approach to be useful and effective?

I look forward to comments and assessments.

Best regards,
Martin

Product version: IRIS 2021.1

$ZV: IRIS for UNIX (SUSE Linux Enterprise Server for x86-64) 2021.1 (Build 215U) Wed Jun 9 2021 09:48:27 EDT

Discussion (5)2

Log in or sign up to continue

score 1 · Answer 1 · 2024-04-11T11:31:55-04:00

We just went through a same dilemma. it was recommended from an IT audit perspective that we look into securing the access and hardening what access was given.

We had been using Delegated authentication that performed the necessary lookup against LDAP, but the way in which we did it was not ideal according to the Audit. So, we moved to using the internal LDAP functionality inside IRIS, and through a painful process I was able to get a TLS certificate signed by the Active Directory Services.

By knowing how to obtain a Certificate signed by the CA that is used across the Medical Center, it allowed us to configure Apache and a Local instance of the Web Gateway to encrypt the connection to the management portal instead of using HTTP with port 52773. VS Code was not affected either as we switched our VS Code connections to use https and port 443.

We also took steps in hardening access by limiting resources, and web applications by those resources as well.

That was just how we addressed it, Configuring a local firewall, or network access based on ports is painful but it can be done. As applications are moved to a segregated network we have had to start having tickets put in to allow traffic across ports. So we are updating the network as we go through new applications. Eventually we will need to do this for all ports as the Powers that be would like us to move to the Cloud evenutally.

score 0 · Answer 2 · 2024-04-12T03:27:52-04:00

Thank you for your explanations. The procedure you described sounds somewhat complex, but (as ultimately proven by your report) feasible. Together we are 5 colleagues who deal with the development and administration of interfaces in addition to other topics. We would need external help from our systems department to set up a certificate-based access procedure. I can see the day coming when the certificate has expired or something else has happened and we have locked ourselves out with no way of quickly re-establishing this access on our own. But thanks again for the suggestion, I will definitely look into whether this could be an option for us.

score 0 · Answer 3 · 2024-04-14T22:57:25-04:00

Just a bit of thought, from your post i think 57772 is the port of the private webserver previously packaged with IRIS?

If so. don't use it for production workloads, its not configured or designed for that purpose, also due to security concerns the private web server has been deprecated and is no longer included in newer IRIS versions. (ref: Discontinue Apache web server installations (aka Private Web Server (PWS)) (intersystems.com) )

score 0 · Answer 4 · 2024-04-15T05:18:40-04:00

Thanks for the hint. In the past it was the port of the packaged webserver, that is true. Meanwhile we're using the Apache server that comes with the distribution's package manager in combination with the Intersystems webgateway. We're just using the same port configuration. I hope this at least alleviates the problem described, but unfortunately does not change the problem that all web apps, including the management portal, are addressed via the same port.

score 0 · Answer 5 · 2024-04-16T02:18:39-04:00

ahh now your question is getting a bit clearer.

If you look for a better management for your API endpoints might be worth looking into ISC API manager: InterSystems API Manager | InterSystems Components and Tools

Else you can use delegated auth to validate incoming IP addresses, also you can make use of Apache's virtual server config to server different content on different ports using Apache access controls for additional filtering and redirecting, which is essentially what you suggest here.