The distinction between internal portal and extranet in a university hospital (CHU) is not just a matter of network scope. It involves architectural choices that determine the attack surface, the granularity of permissions, and the ability to trace abnormal usage. We observe that most institutions still treat this issue as a simple technical arbitration, whereas it primarily pertains to risk management applied to health data.
Access segmentation for CHU agents by risk level
An internal portal (intranet) and an extranet do not protect the same resources with the same intensity. The real criterion for choice is not the geographical location of the agent, but the sensitivity of the resource they are accessing.
On a traditional intranet, the agent connected to the wired network or the CHU’s professional Wi-Fi benefits from a first level of trust related to the physical infrastructure. Critical applications (patient files, prescriptions, identity vigilance) remain confined to this perimeter. The extranet opens a second channel, intended for off-site connections, but this channel requires compensatory controls that many institutions underestimate.
We recommend mapping each application of the health information system (SIH) according to three levels: restricted access to the internal network only, remote access with enhanced authentication, and open access on a standard web portal. This mapping conditions the choice of architecture much more than the budget or the brand of the chosen solution. A detailed article on CHU agent access on Tranquilité Santé precisely describes the functional differences between these two modes.
Multifactor authentication and federated SSO: what changes for hospital extranet
Multifactor authentication is a prerequisite, not an option. On an internal portal, the network itself constitutes an implicit factor of trust. On an extranet, this factor disappears. The agent connecting from home, a remote workstation, or a mobile terminal must prove their identity by at least two independent means.
A common pitfall concerns MFA enrollment. In several CHUs, the association between the agent’s account and the authentication application (such as Microsoft Authenticator) must be done from the internal network. Attempting the operation from an external network blocks the procedure without an explicit error message. This technical point, rarely documented in user guides, generates a significant volume of tickets to IT support.
The federated SSO architecture simplifies the agent’s experience by unifying authentication across all applications (email, HR portal, work time management, document intranet). However, it multiplies the entry points. Each connection path must be covered by the same security policy, whether it is the web portal, mobile application, or heavy VPN client.
VPN or reverse proxy: two philosophies of remote access
The VPN creates an encrypted tunnel that virtually connects the remote terminal to the internal network. The reverse proxy only exposes the published applications, without extending the network perimeter. The choice depends on the usage profile:
- The VPN is suitable for agents who use heavy applications requiring a full network connection (imaging, local databases).
- The reverse proxy is sufficient for web uses (email, schedule consultation, HR portal) and reduces the attack surface by only publishing strictly necessary services.
- A hybrid model, where the VPN is reserved for technical profiles and the reverse proxy for functional agents, is the most common compromise in mid-sized CHUs.
Permissions for external stakeholders: the weak link in the SIH
The CHU agent access guides focus on permanent staff. External stakeholders (private doctors, temporary staff, biomedical maintenance providers, research partners) represent a specific risk that neither the internal portal nor the standard extranet addresses correctly without dedicated configuration.
A generic account shared among multiple external stakeholders is a security breach. Current recommendations impose individual accounts, rapid revocation of permissions at the end of the mission, and strict application of the need-to-know principle. A temporary staff member working three days a month in cardiology has no reason to access the psychiatry prescription module.
The extranet offers a structural advantage over the internal portal here: it allows for the creation of compartmentalized access areas, with configurable validity periods and complete traceability of connections. The internal portal, designed for permanent agents, has more difficulty managing these variable profiles.
Logging and detection of abnormal usage on the agent portal
An initial access control, no matter how robust, does not protect against account compromise. The difference between a well-designed portal and a vulnerable portal lies in what happens after authentication.
The portal must log each connection and identify atypical behaviors: unusual extraction volumes, connections at times inconsistent with the agent’s schedule, simultaneous access from two distinct geographical locations. These weak signals are the first indicators of a compromised account.
On an intranet, logging often relies on the logs of the domain controller and application servers. On an extranet, it must be centralized at the portal itself, as connections transit through heterogeneous paths. We observe that institutions that have experienced security incidents generally had partial logging, covering authentication but not post-connection actions.
- Ensure that the portal tracks access to individual patient files, not just application connections.
- Set up automatic alerts for massive data extractions (CSV exports, bulk printing).
- Conduct a quarterly review of active accounts to disable obsolete permissions, particularly for external stakeholders.
The choice between internal portal and extranet is not just about network architecture. It engages the CHU’s ability to apply differentiated security policies based on profile, connection location, and the sensitivity of the data accessed. A well-configured extranet protects better than a poorly supervised intranet. The pertinent question is not which portal to deploy, but what level of control the institution is willing to maintain over time.
