A zero-trust security authentication method and system for hospital heterogeneous device access

Abstract

The application provides a zero-trust security authentication system and method for hospital heterogeneous device access, and belongs to the technical field of security authentication and virtualization. The method comprises the following steps: after the heterogeneous device is authenticated by identity, a communication pre-connection is established, so that the hospital information system unidirectionally acquires the operating system type and application program data of the heterogeneous device; based on the operating system type and the application program data of the heterogeneous device, a virtual network partition is created on a data center server of the hospital information system; after each virtual network partition is used to receive the application program data of the heterogeneous device, a target container is created by calling a security container image, the security container image corresponds to the operating system type of the heterogeneous device; environment authentication information is sent to the heterogeneous device through the target container; when the environment authentication information is passed, a data interaction connection between the heterogeneous device and the virtual network partition of the hospital information system is established, so that the heterogeneous device accesses the hospital information system through the target container.

Description

Technical Field

[0001] This invention belongs to the field of security authentication and virtualization technology, and in particular relates to a zero-trust security authentication method and system for accessing heterogeneous devices in a hospital. Background Technology

[0002] Unlike traditional network perimeter security architectures, the zero-trust security model requires authentication before each authorized operation, thereby differentially controlling user permissions and achieving control over the internal network. In a zero-trust system, regardless of whether access originates from within or outside the enterprise, whether it's from employees, partners, devices, or applications, all access to resources must undergo rigorous and continuous identity verification, authorization review, and security status assessment before being granted access. This means that even if a user has passed initial login authentication, the system will dynamically adjust access permissions based on real-time risk conditions when accessing different resources or performing critical operations, requiring re-authentication. Related technologies include the terminal trust enhancement method and system based on virtualization technology proposed in invention patent CN105354493B, and the model framework of a smart IoT zero-trust network implemented based on an intrinsically secure property management platform proposed in Chinese invention publication CN119853939A.

[0003] However, existing technologies lack comprehensive consideration of critical information such as device operating system type and application data when handling communication connections between heterogeneous devices and hospital information systems. Before establishing a connection, the inability to fully understand the device's operating environment prevents the system from developing targeted security strategies. For example, using the same communication rules for devices running different operating system versions fails to account for the potential for vulnerabilities in lower-version operating systems, making them easy targets for attacks and increasing the risk of data leakage and tampering during communication. In building zero-trust adaptation environments, traditional technologies cannot effectively restrict the operating permissions of heterogeneous devices. After devices are connected to the system, it is difficult to ensure they operate under minimal privileges; devices can freely connect to peripheral accessories, such as unauthorized storage devices via USB interfaces. This significantly increases the risk of data leakage; for example, malware may spread into the hospital information system through external devices, damaging data or stealing sensitive information. Furthermore, most traditional security authentication systems have serious deficiencies in device environment authentication. Regarding device fingerprint information, the system fails to adequately consider and effectively collect detailed information on device hardware (such as MAC address and CPU serial number) and software (operating system version and patch status values), making it difficult to accurately identify the uniqueness and security of devices. Furthermore, it lacks real-time monitoring and analysis mechanisms for device access location information and network status information. This allows malicious devices to access the hospital information system undetected via insecure networks or false locations, posing a serious threat to system security. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a zero-trust security authentication method and system for accessing heterogeneous devices in hospitals.

[0005] In a first aspect of the present invention, a zero-trust security authentication method for accessing heterogeneous devices in a hospital is proposed, the method being implemented based on desktop virtualization technology;

[0006] The method includes:

[0007] After the heterogeneous device passes identity authentication, a communication pre-connection is established between the heterogeneous device and the hospital information system. The communication pre-connection enables the hospital information system to unidirectionally obtain the operating system type and application data of the heterogeneous device.

[0008] Based on the operating system type and application data of the heterogeneous devices, virtual network partitions are created on the data center server of the hospital information system, with each virtual network partition corresponding to an operating system type.

[0009] After receiving application data from the heterogeneous device in each virtual network partition, a secure container image is invoked to create a target container, wherein the secure container image corresponds to the operating system type of the heterogeneous device.

[0010] The target container sends environmental certification information to the heterogeneous device.

[0011] When the environmental authentication information is passed, a data interaction connection is established between the heterogeneous device and the virtual network partition of the hospital information system. The data interaction connection enables the heterogeneous device to access the hospital information system through the target container.

[0012] The environmental authentication information includes device fingerprint information, access location information, and network status information;

[0013] The device fingerprint information is generated from the device hardware and software information collected by the target container;

[0014] The device hardware information includes the MAC address and CPU serial number; the software information includes the operating system version and patch status value.

[0015] After establishing the data interaction connection between the heterogeneous devices and the virtual network partition of the hospital information system, the method further includes:

[0016] Continuously acquire security logs for each virtual network partition;

[0017] When abnormal behavior of a heterogeneous device is detected, the target container corresponding to the heterogeneous device is suspended.

[0018] The secure container image provides a zero-trust adaptation environment, which enables the heterogeneous device to run in a minimum privilege state, and the minimum privilege state prohibits the heterogeneous device from connecting to peripheral accessory devices.

[0019] When abnormal behavior of a heterogeneous device is detected, the target container corresponding to the heterogeneous device is suspended, and the heterogeneous device is required to re-authenticate its identity and environment.

[0020] If both identity authentication and environment authentication are successful, the target container is restored; otherwise, the target container is destroyed.

[0021] In a second aspect of the invention, a zero-trust security authentication system for heterogeneous hospital devices based on desktop virtualization is proposed, the system comprising:

[0022] The pre-connection establishment module is used to establish a one-way communication pre-connection with the hospital information system after the heterogeneous device passes the initial identity authentication, and to obtain the operating system type and application data of the heterogeneous device.

[0023] The virtual network partition creation module is used to create virtual network partitions on the data center server based on the operating system type and application data, with each partition corresponding to a specific operating system type;

[0024] The secure container deployment module is used to call the corresponding secure container image according to the operating system type of the heterogeneous device in each virtual network partition and create a target container for running the application.

[0025] The environmental authentication module is used to send environmental authentication information to heterogeneous devices through the target container to verify the security of the device's operating environment;

[0026] The data interaction module is used to establish a data interaction connection between heterogeneous devices and corresponding virtual network partitions when the environment authentication is successful, so that the devices can access hospital information system resources through the target container;

[0027] The initial identity authentication is used to verify the identity information of heterogeneous devices, and the identity information includes username / password, biometric features, and digital certificate.

[0028] The environmental authentication information includes device fingerprint information, access location information, and network status information.

[0029] The virtual network partition creation module includes:

[0030] SDN controller: Based on software-defined networking technology, dynamically creates and manages virtual network partitions;

[0031] VLAN allocation unit: Assigns independent VLANs (Virtual Local Area Networks) to devices with different operating system types.

[0032] Access Control List (ACL) Hive: Sets the initial security policy for each virtual network partition.

[0033] The secure container deployment module includes:

[0034] Container image repository: Stores secure container images corresponding to various operating system types, including basic OS environment images and medical application runtime images;

[0035] Container orchestration engine: Based on Kubernetes or DockerSwarm technology, it deploys and manages target containers within virtual network partitions.

[0036] The data interaction module includes:

[0037] Secure tunnel establishment unit: Establishes an encrypted communication tunnel between heterogeneous devices and the target container via TLS 1.3 or IPsec protocol;

[0038] Traffic monitoring unit: Monitors data exchange traffic in real time, detects and intercepts abnormal data packets.

[0039] The virtual network partition supports nested subdivision, creating sub-partitions based on device functionality or data sensitivity, and configuring independent access control policies for each sub-partition.

[0040] Compared with existing technologies, the zero-trust security authentication method for accessing heterogeneous hospital devices based on desktop virtualization technology proposed in this invention has the following significant advantages:

[0041] Regarding the authentication process, this invention introduces a communication pre-connection mechanism for the first time. Existing technologies mostly rely on one-time static authentication, making it difficult to comprehensively obtain device information. In contrast, this invention establishes a communication pre-connection after the device has passed identity authentication, enabling the hospital information system to unilaterally obtain the device's operating system type and application data. This provides richer information support for subsequent authentication processes, greatly improving authentication accuracy and security.

[0042] At the security protection level, this invention creates a more refined and highly isolated security environment by establishing virtual network partitions based on the device's operating system type and calling corresponding secure container images to create target containers. Traditional technologies lack targeted protection for devices with different operating system types, making them prone to security vulnerabilities. This invention isolates different types of devices in their respective virtual network partitions and utilizes the zero-trust adaptation environment provided by secure container images, allowing devices to run in a state of minimum privileges and prohibiting connections to peripheral accessories. This reduces the risk of data leakage from multiple aspects and greatly improves the overall system security. Dynamic monitoring and response capabilities are also a prominent advantage of this invention. Existing technologies are insufficient in monitoring device behavior after connection, making it difficult to detect anomalies in a timely manner. This invention continuously acquires security logs from the virtual network partition. Once abnormal device behavior is detected, it can quickly suspend the corresponding target container, require the device to re-authenticate its identity and environment, and flexibly restore or destroy the container based on the authentication result. This real-time monitoring and dynamic response mechanism effectively curbs the spread of potential security threats and ensures the stable operation of the hospital information system.

[0043] In terms of environmental authentication, this invention collects multi-dimensional information for authentication, including device fingerprint information (such as MAC address and CPU serial number, and software information such as operating system version and patch status), access location information, and network status information. Compared with the shortcomings of existing technologies in environmental authentication, this invention can more comprehensively and accurately identify the uniqueness and security of devices, preventing malicious devices from accessing through insecure networks or false locations, and significantly improving the reliability and effectiveness of environmental authentication.

[0044] Further specific advantages and implementation principles of the present invention will be further detailed in the specific embodiments section in conjunction with the accompanying drawings. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a schematic diagram of the main execution flow of a zero-trust security authentication method for accessing heterogeneous devices in a hospital, according to an embodiment of the present invention.

[0047] Figure 2 yes Figure 1 A further preferred embodiment of the zero-trust security authentication method for accessing heterogeneous devices in a hospital is illustrated in the diagram.

[0048] Figure 3This is a schematic diagram of the hardware unit composition of a zero-trust security authentication system for heterogeneous hospital devices based on desktop virtualization, according to an embodiment of the present invention.

[0049] Figure 4 yes Figure 3 A schematic diagram of a preferred embodiment of the zero-trust security authentication system for heterogeneous hospital devices based on desktop virtualization. Detailed Implementation

[0050] In the specific embodiments of this application, if the embodiments of the relevant technical solutions involve user-related data, then when the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0051] In this section, the present invention provides several method or product embodiments. Each method or product embodiment constitutes an independent technical solution and makes at least one contribution to the prior art, capable of solving one or more technical problems mentioned in the background art, and having one or more outstanding effects.

[0052] However, it is understood that not every embodiment is required to solve all the technical problems mentioned in the background or achieve all the technical effects. For each individual embodiment, as long as it makes at least one contribution to the prior art and achieves an improved technical effect, and has outstanding substantive features or significant progress, the technical solution constituted by that individual embodiment should possess novelty and inventiveness in the sense of patent law.

[0053] First see Figure 1 , Figure 1 This is a schematic diagram of the main execution flow of a zero-trust security authentication method for accessing heterogeneous devices in a hospital, according to an embodiment of the present invention.

[0054] For ease of description, Figure 1 The steps of the embodiment are extended and numbered S1-S5 (step numbers are omitted in the figures):

[0055] S1: After the heterogeneous device passes the identity authentication, a communication pre-connection is established between the heterogeneous device and the hospital information system. The communication pre-connection enables the hospital information system to unidirectionally obtain the operating system type and application data of the heterogeneous device.

[0056] S2: Based on the operating system type and application data of the heterogeneous devices, create virtual network partitions on the data center server of the hospital information system, with each virtual network partition corresponding to an operating system type;

[0057] S3: After receiving the application data of the heterogeneous device in each virtual network partition, call the secure container image to create the target container, wherein the secure container image corresponds to the operating system type of the heterogeneous device;

[0058] S4: Send environmental authentication information to the heterogeneous device through the target container;

[0059] S5: When the environmental authentication information is passed, a data interaction connection is established between the heterogeneous device and the virtual network partition of the hospital information system. The data interaction connection enables the heterogeneous device to access the hospital information system through the target container; otherwise, the data interaction connection is not established.

[0060] Figure 1 The method is based on desktop virtualization technology.

[0061] The following sections will elaborate on the above steps with specific scenario examples. It should be understood that some of the scenario examples are merely listings and not exhaustive; the technical solution of this invention can also be applied to other examples. These examples do not constitute a limitation on the scope of protection of this invention.

[0062] Furthermore, to enrich the scenario examples, different scenario examples may be used in different embodiments, and different scenario examples may be expanded in different steps of the same embodiment. Different scenario examples may have contextual relationships; however, since the examples are only a limited list, even in the same embodiment, the scenario examples mentioned in different steps may not be related literally (but the content actually belongs to the same category).

[0063] First, step S1: After the heterogeneous device passes identity authentication, a communication pre-connection is established between the heterogeneous device and the hospital information system. The communication pre-connection enables the hospital information system to unidirectionally obtain the operating system type and application data of the heterogeneous device.

[0064] Step S1 is the initial security access step for heterogeneous devices to access the Hospital Information System (HIS). The core objective is to establish a low-privilege temporary communication channel based on trusted identity verification, enabling the hospital information system to securely collect basic information about the devices. This process must balance the diversity of heterogeneous devices (such as differences in terminal type and operating system) with the high security requirements of medical data.

[0065] Preferably, step S1 includes the following aspects:

[0066] Authentication targets: covering three dimensions: "device-user-application". It not only verifies the physical identity of the device (such as the device's unique hardware identifier MAC address and IMEI code), but also needs to bind the identity of the medical personnel using the device (such as employee ID and role permissions) and the legitimacy of the medical-related applications running on the device (such as application signature and access whitelist).

[0067] Authentication method adaptation: Select an adaptation scheme based on the characteristics of heterogeneous devices.

[0068] For physician workstations (Windows / macOS laptops): Use "username and password + multi-factor authentication (MFA)," such as combining LDAP protocol verification with the hospital's unified identity authentication platform (IAM), and overlaying dynamic tokens (such as RSASecurID) or biometrics (fingerprint / face, integrated via Windows Hello or macOS Touch ID).

[0069] For mobile terminals (nurses' Android / iOS tablets): Device certificate authentication is performed. The device is pre-installed with an X.509 digital certificate issued by the hospital. During access, the certificate chain is verified through the TLS handshake phase (the root certificate is stored on the HIS authentication server), and the role and permission verification of the nurse's employee number is also associated.

[0070] For IoT medical devices (such as ECG monitors and infusion pumps): Lightweight authentication is adopted. Due to limited device resources, a hash verification of a pre-set static key and a unique device identifier (such as an SN code) is used to avoid complex calculations. The key is written to the device's security chip (such as an SE chip) through offline burning.

[0071] Authentication process: A unified authentication entry point is achieved through the hospital access gateway (such as an API gateway based on F5BIG-IP or open source Kong). After the device sends an authentication request, the gateway forwards it to the HIS identity authentication server (such as one built on Keycloak). After the server verifies the request, it returns a temporary authentication token with an expiration date (such as a JWT token, which contains metadata such as device identifier and user role) as a credential for subsequent pre-connection.

[0072] After successful identity authentication, a temporary, low-privilege communication pre-connection needs to be established, which is characterized by "lightweight connection + one-way access control":

[0073] Connection type: A basic transmission channel is established based on the TCP protocol. To ensure security, TLS 1.3 is used for encryption and encapsulation to prevent eavesdropping or tampering during data transmission. Pre-connection does not rely on complex session management and only maintains a minimal communication link (e.g., port restrictions are placed on non-core business ports, such as TCP 8088).

[0074] One-way protection: Data flow is restricted through network access control lists (ACLs) and firewall rules: only heterogeneous devices are allowed to send data to the HIS (Hospital Information System), and the HIS side only opens data receiving ports, prohibiting devices from actively requesting core HIS resources (such as electronic medical record databases and pharmacy management systems). For example, the HIS access layer firewall is configured with a rule of "Inbound allowed device → HIS data collection service, outbound denied HIS → unnecessary device response".

[0075] Connection lifecycle: The pre-connection is temporary and is only valid during the information collection phase (usually lasting 30-60 seconds). It will automatically disconnect after the collection is completed to avoid the security risks associated with long-term connections.

[0076] The hospital information system obtains "operating system type" and "application data" through pre-connection one-way, relying on a technology that combines active reporting by devices with passive parsing by the HIS.

[0077] Operating System Type Retrieval:

[0078] For general-purpose terminals (PCs / tablets): The User-Agent field is carried in the request header sent by the device via HTTP / HTTPS protocol. The HIS data collection service parses this field to extract OS information.

[0079] For IoT devices: Reporting is done through device-specific protocols. For example, embedded Linux devices may carry the OS:Linux-5.10.0-embedded field in the message body sent via the MQTT protocol, and HIS can directly extract this metadata.

[0080] For medical professional applications (such as electronic medical record clients and mobile ward round apps): the device actively reports the application identifier (such as AppID:EMR_Client_v2.5.3), application signature hash value (used to verify that the application has not been tampered with) and running status (such as whether it is running in the background and whether the encryption module is enabled) through the API interface.

[0081] For general office applications (such as browsers and document tools): HIS identifies the application processes corresponding to open ports on the device through port scanning (only within the scope of security scanning allowed in the pre-connection phase). For example, if port 8080 is detected to correspond to the process Chrome.exe (browser), it is confirmed by combining the User-Agent to access the HIS Web portal.

[0082] Based on the above principles, the following two common illustrative terminal access scenarios can be used to describe the implementation process of step S1 in detail.

[0083] Scenario 1: Cardiologists accessing HIS using laptops running macOS Ventura

[0084] Identity authentication: The doctor enters the employee number "DR-202305" and password on the HIS client on the laptop. The client calls macOS Touch ID to complete the biometric secondary verification. The authentication request is verified through the hospital's IAM platform's SAML2.0 protocol and a JWT token with a validity period of 5 minutes is returned.

[0085] Communication pre-connection establishment: The client uses a token to establish a TCP connection with the HIS data acquisition service (deployed at the back end of the access gateway) through a TLS 1.3 encrypted channel. The firewall restricts this connection to only allow the client to send data.

[0086] One-way data acquisition: HIS parses the User-Agent (Mozilla / 5.0(Macintosh;IntelMacOSX13_4)AppleWebKit / 605.1.15(KHTML,likeGecko)Version / 16.5Safari / 605.1.15) sent by the client to determine that the operating system is macOS Ventura 13.4; at the same time, the client actively reports the running application data: AppID:Cardio_EMR_v3.2 (cardiology electronic medical record client) and application signature hash value, and HIS completes information collection.

[0087] Scenario 2: Pediatric nurses use Android 14 tablets to access the HIS (Hospital Information System).

[0088] Identity authentication: The tablet has a built-in hospital-issued device certificate. When accessing the device, the certificate validity is verified through a TLS handshake. At the same time, the nurse completes the face comparison on the tablet APP (associated with employee number "NR-202312"), and the authentication is successful.

[0089] Communication pre-connection establishment: The tablet establishes a temporary connection with HIS via the HTTPS protocol, and the access layer firewall is configured to only allow the tablet to send data to the HIS port 8088.

[0090] One-way data acquisition: HIS parses User-Agent to obtain Android 14 system information; the tablet reports the version and process status of the running Pediatric_Nursing_v1.8 (Pediatric Nursing APP), and HIS completes basic information collection.

[0091] Next, proceed to step S2.

[0092] Step S2 is a core component of the Hospital Information System (HIS) in achieving network isolation and refined management. Based on the "operating system type" and "application data" of heterogeneous devices obtained in S1, virtual network partitions at the operating system level are dynamically created on the data center server. Its core objective is to achieve logical isolation of different types of devices through network virtualization technology, reduce cross-platform security risks, and lay the foundation for subsequent containerized operation and data interaction.

[0093] The specific implementation of step S2 includes the following aspects:

[0094] Logical isolation domains are divided using VLAN (Virtual Local Area Network) or VXLAN (Virtual Extended Local Area Network) technologies. For small-scale hospital scenarios, independent broadcast domains are assigned to different operating systems using VLAN tags (such as VLAN ID 100-200) to restrict direct communication across VLANs. For large-scale heterogeneous device access (such as a tertiary hospital with dozens of terminal types), finer-grained isolation is achieved through the 24-bit VNI (Virtual Network Identifier) ​​of VXLAN, supporting virtual partition expansion across physical servers. Tunnel encapsulation uses the UDP protocol (port 4789) to ensure the independence of the underlying physical network.

[0095] Virtual network partitions need to be deeply integrated with the hospital's desktop virtualization platform (such as Citrix VirtualApps or Huawei FusionAccess), obtaining operating system metadata for virtual desktops / terminals through the platform's API to ensure that partitioning matches the actual terminal's operating environment. For example, when a new macOS device is detected, the virtualization platform automatically triggers a partition creation command without manual intervention.

[0096] The creation of virtual network partitions is based on "operating system type as the primary factor and application data as a secondary verification method." Core rules include partition mapping relationships, differentiated configurations, and security policy binding.

[0097] Mapping relationship between partitions and operating systems:

[0098] Establish a one-to-one basic mapping rule, meaning that each operating system type corresponds to a unique virtual network partition. Common mapping examples are as follows:

[0099] Windows (including Windows 10 / 11 and Windows Server terminals) → VLAN 100 (or VXLANVNI 1000)

[0100] macOS (including macOS Ventura / Sonoma) → VLAN 101 (or VXLANVNI1001) Android (including Android 13 / 14 mobile devices) → VLAN 102 (or VXLANVNI1002) iOS (including iOS 16 / 17 tablets / phones) → VLAN 103 (or VXLANVNI1003) Embedded Linux (medical IoT devices) → VLAN 104 (or VXLANVNI1004)

[0101] Application data is used to verify the authenticity of the operating system type, preventing devices from spoofing OS information to bypass isolation. For example, if S1 obtains the operating system type as "Android 14", but the application data shows that it is running EMR_Client_v3.2 (electronic medical record client), which only supports Windows, then the exception verification mechanism is triggered, the partition creation is refused, and the device is marked as "pending review".

[0102] Configure specific network parameters for different operating system characteristics:

[0103] Protocol support: Windows partitions open the SMB protocol port (for file sharing), while Android / iOS partitions only open HTTPS (port 443) and MQTT (port 8883, for IoT data transmission).

[0104] Security group rules: The embedded Linux medical device partition is restricted to communicating only with the HIS device management server (IP fixed at 192.168.10.10), and access to the Internet is prohibited;

[0105] Data buffer: Configure a larger network buffer (e.g., 1MB) for high-concurrency Windows Doctor workstation partitions to reduce data transmission latency.

[0106] The HIS data center's "Partition Control Server" receives device data uploaded by S1 and extracts key information through a parsing engine: operating system type (e.g., "macOS Ventura 13.4") and application validity verification result (e.g., "AppID: Cardio_EMR_v3.2 signature valid"). The parsing engine uses a rule engine (e.g., Drools) to match a preset OS-partition mapping table to determine the target partition type.

[0107] The partition control server issues creation commands to data center network devices via SDN controller APIs (such as the OpenFlow protocol), including parameters such as partition identifier (VLAN ID / VNI), resource quotas, and security policy ID. For example, for macOS devices, the command is "Create VLAN 101, bind security policy ID 002, allocate 1 vCPU / 2GB memory / 50Mbps bandwidth".

[0108] SDN controller works in conjunction with virtual switch and hypervisor to complete partition creation:

[0109] The virtual switch creates an independent port group and binds it to the target VLAN / VNI tag;

[0110] The hypervisor allocates computing resources and creates virtual network interfaces (vNICs).

[0111] The firewall automatically loads the access control list (ACL) for the corresponding partition, such as "Allow VLAN 101 to access HIS database server 192.168.20.5, and prohibit access to other VLANs".

[0112] After the partition is created, the control server verifies the partition's availability through ICMPping and port scanning. Once it confirms that the virtual switch flow table rules are effective and the resource allocation is correct, the partition status is marked as "available," and the binding relationship between the device and the partition is recorded (stored in the device_partition_mapping table of the MySQL database).

[0113] Based on the principles described above, the implementation process of step S2 can be specifically described by the following two common illustrative terminal access scenarios.

[0114] Scenario 3: Surgeon accessing and creating partitions on a Windows 11 workstation

[0115] Information Analysis: The HIS partition control server receives device data, parses it to show that the operating system type is "Windows1122H2", the application data shows that it is running Surgical_Planning_v4.0 (surgical planning software, valid signature), and matches the OS-partition mapping table to determine that the target partition is "VLAN100".

[0116] Command issuance: Issue VLAN100 creation command via SDN controller API and bind security policy (allow access to surgical imaging server 192.168.30.8, and prohibit access to pharmacy system).

[0117] Partition initialization: Create port group "Win11-Surgical" on the virtual switch and bind VLAN 100; allocate 2 vCPU / 8GB memory resources to the hypervisor; load ACL rules in the firewall: "Inbound allow 192.168.30.8→VLAN100, outbound deny VLAN100→192.168.40.0 / 24 (pharmacies network segment)".

[0118] Status verification: The control server pings the VLAN100 gateway (192.168.10.1) to confirm that ports 80 / 443 are open, marks the partition as "available", and records the binding relationship "Device SN:W202306→VLAN100".

[0119] Scenario 4: Creating a partition for connecting an embedded Linux ECG monitor

[0120] Information analysis: Device data shows the operating system as "Linux-5.10.0-embedded", the application data as ECG_Monitor_v2.1 (ECG monitoring software, only supports embedded Linux), and the target partition is determined to be "VLAN104" by matching the mapping table.

[0121] Command issuance: Issue VLAN104 creation command with resource quota of "0.5vCPU / 1GB memory / 10Mbps bandwidth" and bind IoT-specific security policy.

[0122] Partition initialization: The virtual switch creates a port group "Linux-ECG" and binds it to VLAN 104; restricts communication with the HIS monitoring data server (192.168.50.3) to only via the MQTT protocol (port 8883); disables USB port and Internet access permissions.

[0123] Status verification: Verify that the MQTT connection between the partition and the monitoring data server is normal, there is no cross-network segment communication behavior, and mark the partition as "available".

[0124] Next, proceed to step S3.

[0125] Step S3 is a crucial step in isolating heterogeneous devices for secure operation environments based on virtual network partitioning. The core mechanism utilizes "operating system type matching + containerized dynamic deployment" to create a dedicated secure operating space for each connected device. This process relies on container virtualization technology to logically isolate device application data from the core resources of the Hospital Information System (HIS), while ensuring the compatibility and security of the operating environment.

[0126] The specific implementation of step S3 includes the following aspects:

[0127] I. Target Container Creation

[0128] The creation of a target container requires meeting three conditions: "partition readiness + data reception + image matching." This is the connection point between virtual network partitioning and container technology.

[0129] Virtual network partition readiness status verification:

[0130] Before creating a container, you need to confirm that the virtual network partition has been initialized (status is "available") through a partition status interface (such as / api / partition / status based on RESTful API) and obtain the partition's network configuration information (such as subnet mask, gateway IP, and security group rules). For example, the Windows partition (VLAN100) needs to return parameters such as "subnet 192.168.100.0 / 24, gateway 192.168.100.1, allowed port 445 / 3389 communication" to ensure that the container network can seamlessly access the partition.

[0131] Application data integrity verification:

[0132] After receiving application data from heterogeneous devices, the virtual network partition needs to verify that the data has not been tampered with through hash verification (such as SHA-256) and digital signature verification. For example, for the Pediatric_Nursing_v1.8 application data uploaded by an Android device, its file hash value is verified to be consistent with the baseline value stored in the HIS application library, and the signature certificate is issued by the hospital's CA institution to prevent malicious application data from triggering container creation.

[0133] Container engine environment support:

[0134] The hospital's data center servers need to deploy a container orchestration engine (such as Kubernetes or Docker Swarm). Kubernetes manages the lifecycle of containers through Pod resources, while Docker Swarm is suitable for rapid deployment in small-scale scenarios. The engine needs to be pre-configured with a container runtime (such as containerd) and support the OCI (Open Container Initiative) standard image format to ensure the compatibility of secure container images.

[0135] II. Adaptation Mechanism of Secure Container Images

[0136] A one-to-one mapping between the image and the operating system:

[0137] Based on the operating system type obtained from S1, the corresponding security container image is matched in the image repository. For example:

[0138] Windows 10 / 11 devices use the win10-secure-container:v2.3 image, which integrates the .NET Framework runtime and medical software dependency libraries;

[0139] Android 13 / 14 devices use the android13-medical-container:v1.8 image, which comes pre-installed with the Android SDK and a medical data encryption module;

[0140] The embedded Linux device corresponds to the linux-embedded-iot-container:v3.1 image, which uses a lightweight Alpine Linux base layer and retains only MQTT communication and device driver dependencies.

[0141] The tiered storage architecture of the mirror repository:

[0142] Secure container images are stored in a hospital's private image repository (such as Harbor) using a layered storage mechanism: the base layer contains core operating system components (such as the Windows kernel and Linux kernel), the middle layer integrates general medical components (such as data encryption SDKs and log auditing tools), and the application layer loads a dedicated application runtime environment based on the device type (such as the electronic medical record client runtime). This layered design reduces image redundancy and improves pull efficiency (e.g., the base layer of a Windows image can share storage, and only the application layer needs to be updated).

[0143] All secure container images undergo automated scanning (e.g., using Clair or Trivy tools) and manual review to ensure they are free of high-risk vulnerabilities (such as container escape vulnerabilities like CVE-2023-20197). Security is further enhanced through the following mechanisms:

[0144] Remove unnecessary tools (such as bash and wget) from the image and restrict operation permissions within the container;

[0145] Enable image signature verification (such as DockerContentTrust) to allow loading only images signed by the hospital's information department;

[0146] Integrate security monitoring agents (such as Falco) to detect abnormal behavior within containers in real time (such as unauthorized file access and process privilege escalation).

[0147] The specific process for creating the target container is as follows:

[0148] Mirror fetching and verification:

[0149] The container engine pulls the corresponding secure container image from a private image repository based on the operating system type. The pull process is transmitted via HTTPS encryption and verifies the image's digital signature and integrity hash. For example, when pulling the macos-medical-container:v2.1 image for a macOS device, it verifies whether its signing certificate chain points to the hospital's root CA to ensure that the image has not been tampered with or replaced.

[0150] Container configuration dynamic injection:

[0151] The engine injects environment variables and configuration files for the virtual network partition into the container, including:

[0152] Network configuration: Connect the container to the target virtual network partition using the --network parameter (e.g., --networkvlan101-net binds the macOS partition network).

[0153] Resource limits: Set CPU / memory limits based on device type (e.g., Windows containers are limited to 2 cores and 4GB, while embedded Linux containers are limited to 0.5 cores and 1GB).

[0154] Security parameters: Enable --read-only for the file system and --cap-dropALL to disable privileged capabilities, retaining only necessary network communication permissions.

[0155] Resource binding and dependency mounting:

[0156] The container is bound to the storage resources of the virtual network partition, and a device-specific data directory (such as / data / device / {SN}) is mounted via a persistent volume to store application cache and temporary data. Simultaneously, the configuration file of the hospital's unified configuration center (such as / etc / medical / config.yaml) is mounted, containing dynamic parameters such as the HIS service address and encryption keys, avoiding the hardcoding of sensitive information.

[0157] Container activation and status monitoring:

[0158] After the container starts, it automatically executes an initialization script (such as entrypoint.sh), starts the application runtime environment, and registers with the HIS container management platform. The platform monitors the container status through a health check interface (such as / health). If three consecutive checks fail (such as port not listening or service not responding), it triggers an automatic restart or image re-pulling mechanism.

[0159] As a further preferred embodiment, the secure container image provides a zero-trust adaptation environment, which enables the heterogeneous device to operate in a minimum privilege state, which prohibits the heterogeneous device from connecting to peripheral accessory devices.

[0160] Secure container images not only provide a runtime environment compatible with the operating system, but also enable dynamic security management of heterogeneous devices through a zero-trust adaptation environment. The zero-trust architecture is based on the principle of "never trust, continuous verification," ensuring that devices can only run within preset security boundaries through least privilege convergence and peripheral access blocking.

[0161] Zero-trust adaptation environments are achieved through pre-configured and dynamic verification mechanisms of secure container images. Core technologies include dynamic identity binding, environment baseline solidification, and real-time behavior auditing.

[0162] Dynamic binding of identity to environment:

[0163] The image has a built-in identity authentication agent that automatically establishes an encrypted channel with the HIS zero-trust management platform upon startup, binding the container ID, device SN, and user ID together to form a unique and trusted identity identifier. For example, when a Windows container starts, it sends a binding request to the platform via ztna-agent.exe with the format "Container ID: c8f2e1d0-xxx; Device SN: W202306; User ID: DR-202305". The platform only grants running permissions after successful verification, preventing identity theft.

[0164] Operating environment baseline solidification:

[0165] The image pre-defines the operating system environment baseline and solidifies key configuration parameters (such as process whitelists, registry entries, and system call rules) to prevent devices from modifying core configurations. For example, the Android secure container image uses SELinux policies to solidify the read-only attribute of the / system directory, allowing only the Pediatric_Nursing_v1.8 process to read and write to the / data / app directory, while unauthorized operations by other processes will be blocked in real time.

[0166] Real-time behavior auditing and dynamic blocking:

[0167] The image integrates zero-trust monitoring components (such as eBPF-based behavior tracing tools) to collect real-time behavioral data on process calls, network connections, and file operations within the container. A rule engine matches abnormal patterns (such as unauthorized process creation or access to sensitive ports). When risky behavior is detected, blocking commands are immediately triggered (such as terminating the process or disabling the network interface), and alerts are simultaneously sent to the HIS security management platform.

[0168] The least privilege state is a core characteristic of a zero-trust adaptation environment. Through granular permission splitting and dynamic convergence, it ensures that heterogeneous devices only possess the minimum permissions necessary to complete business tasks. Technical means include:

[0169] Process permission convergence:

[0170] Application processes running within the container are started with non-root / Administrator privileges, and privileged operations are restricted through Linux's capabilities mechanism or Windows' User Account Control (UAC). For example, the EMR_Client_v3.2 process in the electronic medical record container is only granted "file read / write (limited to the / data / emr directory) and network access (only allowed on the HIS database port 3306)" permissions, and high-risk system calls such as chmod777 and regadd are prohibited.

[0171] Precise control of network access permissions:

[0172] Based on the zero-trust network micro-segmentation policy, containers are only allowed to access the HIS service IPs and ports necessary for business operations, and wildcard address access is prohibited. For example, the embedded Linux ECG monitor container restricts access to the HIS IoT platform (192.168.50.3) via iptables rules, prohibiting access to the Internet or other unrelated network segments (such as the pharmacy system 192.168.40.0 / 24).

[0173] File system permission isolation:

[0174] The container uses a read-only root file system (--read-only), making only essential temporary directories (such as / tmp and / var / log) writable, and restricting read and write access through file access control lists (ACLs). For example, the / data / nursing directory in the Android nursing container only allows the current application process to read and write, prohibiting other processes (including unrelated processes within the container) from accessing it, thus preventing data leakage.

[0175] The zero-trust adaptation environment uses both the container layer and the host layer to block heterogeneous devices from connecting to peripheral accessories (such as USB storage, Bluetooth devices, external displays, etc.), thus preventing data leakage or malicious device access. The specific mechanism is as follows:

[0176] Container layer peripheral access blocking:

[0177] The secure container image comes with a pre-configured peripheral disabling feature, restricting peripheral driver loading and access through system-level policies.

[0178] Linux system container: Disables USB storage devices via udev rules (SUBSYSTEM=="usb",ATTR{idProduct}=="",ATTR{idVendor}=="",MODE="0000"), and uninstalls peripheral driver modules such as Bluetooth and NFC (e.g., rmmodbtusb); Windows system container: Integrates Group Policy template (ADMX), disables "Removable Storage Access" and "USB Device Enumeration" permissions, and sets Start=4 (disables USB storage service) via the registry key HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR.

[0179] Android system container: Disable Bluetooth, USB debugging, and external storage access via the Device Manager API (DevicePolicyManager) by setting setUsbMassStorageEnabled(false) and setBluetoothEnabled(false).

[0180] Host-layer peripheral access verification:

[0181] The container engine of the hospital's data center server works in conjunction with the host operating system to perform secondary interception of peripheral access requests:

[0182] The host Linux restricts container device access permissions through cgroups. devices.allow only retains necessary virtual devices (such as / dev / null, / dev / zero) and prohibits access to physical peripheral device files (such as / dev / sdb, / dev / ttyUSB0).

[0183] The host Windows uses Hyper-V isolation technology to prevent the container process from calling CreateFile to open the USB device handle, and peripheral access events are reported to the HIS security platform in real time.

[0184] Real-time alerts for abnormal access:

[0185] The zero-trust monitoring component continuously detects peripheral connection attempts (such as udev events triggered by USB device insertion and Bluetooth pairing requests). Once an unauthorized operation is detected, it immediately blocks the connection and generates an alarm log (including device SN, time, and peripheral type), which is then pushed to the IT operations and maintenance platform to support source tracing and auditing.

[0186] Next, we will introduce two application scenarios for secure containers under zero-trust adaptation.

[0187] Scenario 5: Electronic medical record container on a Windows workstation in the operating room

[0188] Zero-trust adaptation environment configuration: The secure container image win11-emr-container:v3.2 comes with a pre-installed zero-trust agent, which binds to the identity "Device SN:W202306+Employee ID:DR-202305" at startup; the process runs with the "EMR_User" ordinary user privileges, and is only allowed to access the / data / emr directory and the HIS database port.

[0189] Minimum privilege status: Modifying system time, installing software, and accessing sensitive items such as HKLM\Software in the registry are prohibited. Network connection is only allowed to the electronic medical record server (192.168.30.8:1433).

[0190] External device blocking effect: By disabling USB storage, HDMI external monitor and Bluetooth through group policy, when a doctor inserts a USB flash drive, the container automatically blocks access and pops up a message "External device access is blocked, please contact the IT department", and generates an alarm log.

[0191] Scenario 6: Pediatric Mobile Nursing Android Tablet Container

[0192] Zero-trust adaptation environment configuration: The image android13-nursing-container:v1.8 solidifies the environment baseline through SELinux policy, binds the nurse's employee number "NR-202312" with the tablet's serial number, and verifies in real time whether the network environment is the hospital's intranet.

[0193] Minimum Permission Status: The nursing app only has basic permissions for "camera (for scanning medication), location (for ward positioning), and network". It is prohibited from accessing sensitive information such as contacts and SMS messages. Files can only be read and written to the temporary directory / data / nursing / temp.

[0194] Peripheral blocking effect: Disabling USB debugging, OTG function and Bluetooth peripherals via Android Device Manager API. When attempting to connect to a Bluetooth printer, the container immediately terminates the Bluetooth service and reports an "Unauthorized peripheral access" alarm, ensuring that care data is not leaked through peripherals.

[0195] Next, proceed to step S4.

[0196] Step S4 is a crucial security verification step for heterogeneous devices accessing the Hospital Information System (HIS). It involves the target container sending environmental authentication information to the device and receiving a response, achieving comprehensive and trustworthy verification of the device's "physical identity, operating environment, and access scenario." This process is based on the zero-trust "dynamic verification" principle, establishing a secure baseline for subsequent data interaction connections.

[0197] In practice, step S4 includes four main stages: authentication information generation, secure distribution, device response, and verification feedback.

[0198] The environment authentication information is generated collaboratively by the target container and the HIS zero-trust management platform. It is an encrypted data packet containing multi-dimensional verification data, including at least:

[0199] Basic identity data: The target container obtains the device SN, user ID, and business permission tag (such as "Outpatient Internal Medicine - Doctor") from the HIS device ledger database to ensure that the identity subject is traceable.

[0200] Device fingerprint data: The target container obtains hardware information (MAC address, CPU serial number) and software information (OS version, patch status) through built-in acquisition tools.

[0201] After concatenating the data in the format MAC+CPU_SN+OS_Version+Patch_Status, the device fingerprint is generated using the SHA-256 algorithm and then compared with the historical fingerprint database for preliminary consistency.

[0202] Access location information: The switch port (wired device) or the BSSID (wireless device) of the Wi-Fi AP accessed by the device is obtained through the SDN controller, and a location description (such as "Clinic Room 5, 3rd Floor, Outpatient Building") is generated by associating it with the HIS physical location mapping library.

[0203] Network status information: The target container uses network diagnostic tools to collect information such as IP address, subnet mask, gateway latency, and encryption method (e.g., WPA3-Enterprise) to generate network compliance indicators.

[0204] Dynamic challenge factor: The HIS zero-trust platform generates a 256-bit random number (e.g., Rand:0x5f4dcc3b5aa765d61d8327deb882cf99) as the "dynamic key" for the device response, with a validity period of 30 seconds to prevent replay attacks.

[0205] Encrypt core sensitive data (device fingerprint, challenge factor) using the device's pre-installed public key (stored in the device's security chip) to ensure that only the target device can decrypt it; sign the entire data using the HIS zero-trust platform's private key to generate a signature value Sig (including a signature timestamp), and the device can verify the data integrity through the platform's public key.

[0206] Environmental certification information is transmitted through an encrypted channel between the target container and the device, and the confidentiality and integrity of the transmission process must be guaranteed.

[0207] After the target container receives the response, it works in conjunction with the HIS zero-trust platform to complete the final verification and generate a "pass / fail" result. The verification logic is as follows:

[0208] Basic checks: Verify the validity of the response signature, whether `response_time` is within `expire_time`, and whether `challenge_response` matches the original `challenge` (to prevent response forgery). Detailed checks:

[0209] Device fingerprints with ≤1 difference (e.g., only slightly older patch version but not affecting security) are considered acceptable; access location must completely match the trusted list (unauthorized areas will be disqualified).

[0210] The network status must meet all health indicators (latency / packet loss rate / encryption method must be compliant);

[0211] Result feedback: If the verification passes, the target container records the "Environmental authentication passed" status and waits for step S5 to establish a data interaction connection; if it fails, a detailed report is generated (such as "Location mismatch: The current AP is inpatient building AP-8"), synchronized to the HIS security platform, and subsequent connection requests are rejected.

[0212] Step S4 upgrades the traditional "one-time identity authentication" to dynamic and trusted verification of "identity + environment + scenario" through multi-dimensional environment authentication, effectively preventing risks such as device theft, environment tampering, and unauthorized access. It builds a front-end security barrier for medical data interaction and is the core implementation link of zero-trust architecture in the access of heterogeneous devices in hospitals.

[0213] Next, we proceed to step S5. Step S5 is the final security access step for heterogeneous devices to access the Hospital Information System (HIS). Based on the environmental authentication results of step S4, it dynamically determines whether to establish a trusted data interaction connection between the device and the virtual network partition.

[0214] After the target container completes the response verification in step S4, it sends an "Environment Authentication Passed" notification to the HIS Zero Trust Management Platform, carrying metadata such as the device SN, container ID, and authentication pass timestamp. After verifying the integrity of the notification (via digital signature), the platform generates a ConnectionToken in JWT format, containing the following core fields:

[0215] device_sn: Unique identifier for the device (e.g., W202306);

[0216] partition_id: Target virtual network partition ID (e.g., VLAN100);

[0217] container_id: The unique ID of the target container (e.g., c8f2e1d0-xxx);

[0218] permissions: Device access permissions range (e.g., EMR:read, Prescription:write); exp: Token validity period (usually 8 hours, adapted to the working hours of medical staff).

[0219] Secure transmission of authorization tokens:

[0220] The zero-trust platform sends a connection authorization token to the target container through an encrypted channel between the target container and the device (reusing the TLS 1.3 session from step S4). The container stores the token locally and marks its own state as "ready to interact". At the same time, the platform sends an "allow access" command to the SDN controller of the virtual network partition, which includes the binding relationship between the device MAC address, IP address, and container IP address.

[0221] Once the data interaction connection is established, technical means must be used to ensure the confidentiality, integrity, and controllability of the interaction process. The core control measures are as follows:

[0222] Dynamic permission convergence:

[0223] The zero-trust platform dynamically adjusts access permissions based on device type and business scenario.

[0224] For example, outpatient doctors' workstations have "read and write permissions" for electronic medical records during working hours (8:00-17:30), and are automatically downgraded to "read-only permissions" outside of working hours; mobile nursing tablets only allow access to the nursing records of the currently responsible patients and prohibit cross-ward data queries (achieved through patient ID and ward area association verification).

[0225] The target container has a built-in behavior analysis agent that collects device interaction behavior characteristics (such as request frequency, data volume, and accessed resource types) in real time and compares them with a baseline model (such as "the doctor's workstation performs an average of 3 EMR queries per minute"). When abnormal behavior is detected (such as downloading medical records in batches within a short period of time or accessing resources unrelated to the current department), the agent immediately triggers a temporary block, freezing the connection for 10 minutes and reporting it to the HIS security platform. The connection will be restored or permanently disabled after manual confirmation.

[0226] At the transmission level: all data interactions are encrypted end-to-end. Sensitive fields (such as patient ID numbers) are encrypted on the device side using a security chip, and the container side decrypts and then encrypts them before forwarding them to the HIS, thus avoiding plaintext transmission.

[0227] Storage level: Temporary data cached locally on the device (such as medical record preview images) must be stored in encrypted form (using the device's hardware encryption module, such as Windows BitLocker or Android File-BasedEncryption), and the cache validity period shall not exceed 24 hours, after which it will be automatically destroyed.

[0228] When the environment authentication in step S4 fails, the connection must be completely blocked and a security response implemented through technical means. At this time, the target container is marked as "environment authentication failed", and dynamic ACL rules are issued to the virtual switch through the SDN controller to prohibit communication between the device IP and any HIS service (including ICMP, TCP, and UDP protocols). At the same time, the encrypted session channel between the container and the device is closed, and related network resources (such as ports and caches) are released.

[0229] Step S5 uses a combination of "dynamic authorization + proxy isolation + real-time monitoring" to strictly limit the access permissions of heterogeneous devices to "authenticated virtual network partitions" and "minimum necessary permissions". This not only enables normal data interaction in medical services, but also prevents risks such as data leakage and unauthorized access through layered security control. It is the "final security gate" for heterogeneous device access in hospital information systems.

[0230] exist Figure 1 Based on this, as a preferred embodiment, after establishing the data interaction connection between the heterogeneous devices and the virtual network partition of the hospital information system, the method further includes:

[0231] Continuously acquire security logs for each virtual network partition;

[0232] When abnormal behavior of a heterogeneous device is detected, the target container corresponding to the heterogeneous device is suspended.

[0233] More specifically, when abnormal behavior of a heterogeneous device is detected, the target container corresponding to the heterogeneous device is suspended, and the heterogeneous device is required to re-authenticate its identity and environment.

[0234] If both identity authentication and environment authentication are successful, the target container is restored; otherwise, the target container is destroyed.

[0235] Figure 2 Further show Figure 1 A further preferred embodiment of the zero-trust security authentication method for accessing heterogeneous devices in a hospital is illustrated in the diagram.

[0236] Figure 2 The preferred embodiment further extends the security protection of HIS from "defense at access time" to "defense during interaction" through the mechanism of "continuous monitoring-dynamic response-closed-loop handling". This not only meets the core requirement of "continuous verification" in zero trust, but also specifically addresses the pain points of dynamic changes in risks of heterogeneous devices, high requirements for business continuity, and high compliance pressure in medical scenarios. It builds a full-cycle security barrier of "prevention before the event, control during the event, and traceability after the event" for medical data interaction.

[0237] Specifically Figure 1The identity authentication and environment authentication steps (S1-S5) can be attributed to static verification during "access", while the device environment in medical scenarios may change dynamically (such as device tampering, permission abuse, abnormal switching of access environment).

[0238] Figure 2 The advantages of the technical means further included in the preferred embodiments include:

[0239] Continuously acquire security logs: Collect device interaction behavior (such as access frequency, data transmission volume, and resource access range) and container running status (such as abnormal process startup and access to sensitive files) within the virtual network partition in real time to form a dynamic behavior baseline and solve the security blind spot of "long-term trust after one-time authentication".

[0240] Anomaly-triggered secondary authentication: When abnormal behavior is detected (such as doctors downloading medical records in batches outside of working hours or mobile devices suddenly switching to unauthorized APs), the container is paused and re-authentication is required (identity + environment dual dimensions) to ensure that the device always meets the trusted standard throughout the entire interaction cycle and to prevent the risk from continuing to spread after the static authentication is breached.

[0241] In addition, the healthcare industry is subject to regulations such as the Cybersecurity Law, the Data Security Law, and the Personal Information Protection Law, and is required to retain traceable logs for the entire data interaction process. Figure 2 The embodiments can satisfy the above requirements, specifically in that:

[0242] Continuous log collection and correlation analysis: Security logs cover all data such as device behavior, container status, and authentication results. They can be linked with authentication logs and interaction logs from previous steps to form a complete audit chain of "access-interaction-anomaly-handling", meeting the compliance requirements of "data traceability and responsibility definition".

[0243] Anomaly handling is recorded: Operations such as container pause, re-authentication results, container recovery / destruction, etc., are all recorded with timestamps, operator (and trigger rule ID when the system executes automatically), and device information. This facilitates post-event auditing (such as proving the effective operation of security mechanisms during regulatory inspections) and provides data support for security incident review (such as analyzing abnormal behavior patterns and optimizing protection rules).

[0244] exist Figures 1-2 Based on the method implementation examples, Figures 3-4 The corresponding system (product) implementation examples are further provided.

[0245] First see Figure 3 , Figure 3 This is a schematic diagram of the hardware unit composition of a zero-trust security authentication system for heterogeneous hospital devices based on desktop virtualization, according to an embodiment of the present invention.

[0246] Figure 3 The system includes:

[0247] The pre-connection establishment module is used to establish a one-way communication pre-connection with the hospital information system after the heterogeneous device passes the initial identity authentication, and to obtain the operating system type and application data of the heterogeneous device.

[0248] The virtual network partition creation module is used to create virtual network partitions on the data center server based on the operating system type and application data, with each partition corresponding to a specific operating system type;

[0249] The secure container deployment module is used to call the corresponding secure container image according to the operating system type of the heterogeneous device in each virtual network partition and create a target container for running the application.

[0250] The environmental authentication module is used to send environmental authentication information to heterogeneous devices through the target container to verify the security of the device's operating environment;

[0251] The data interaction module is used to establish a data interaction connection between heterogeneous devices and corresponding virtual network partitions when the environment authentication is successful, so that the devices can access hospital information system resources through the target container;

[0252] The initial identity authentication is used to verify the identity information of heterogeneous devices, and the identity information includes username / password, biometric features, and digital certificate.

[0253] The environmental authentication information includes device fingerprint information, access location information, and network status information.

[0254] exist Figure 3 Based on this, see further Figure 4 , Figure 4 In the preferred embodiment shown, the virtual network partition creation module includes:

[0255] SDN controller: Based on software-defined networking technology, dynamically creates and manages virtual network partitions;

[0256] VLAN allocation unit: Assigns independent VLANs (Virtual Local Area Networks) to devices with different operating system types.

[0257] Access Control List (ACL) Hive: Sets the initial security policy for each virtual network partition.

[0258] The secure container deployment module includes:

[0259] Container image repository: Stores secure container images corresponding to various operating system types, including basic OS environment images and medical application runtime images;

[0260] Container orchestration engine: Based on Kubernetes or DockerSwarm technology, it deploys and manages target containers within virtual network partitions.

[0261] The data interaction module includes:

[0262] Secure tunnel establishment unit: Establishes an encrypted communication tunnel between heterogeneous devices and the target container via TLS 1.3 or IPsec protocol;

[0263] Traffic monitoring unit: Monitors data exchange traffic in real time, detects and intercepts abnormal data packets.

[0264] The virtual network partition supports nested subdivision, creating sub-partitions based on device functionality or data sensitivity, and configuring independent access control policies for each sub-partition.

[0265] Although not shown in the accompanying drawings, a preferred and further embodiment of the product may also be an electronic device comprising: a memory and one or more processors. The memory stores one or more application programs adapted to be executed by the one or more processors, as described above, a zero-trust security authentication method for accessing heterogeneous devices in a hospital.

[0266] Although not shown in the accompanying drawings, further embodiments also include a computer-readable storage medium storing a computer program that, when executed, implements the steps of the aforementioned zero-trust security authentication method for access to heterogeneous devices in a hospital.

[0267] It is understood that the system, product, equipment, and media implementation examples and method implementations correspond to each other and can be referenced by each other, as their principles are similar or the same, and therefore will not be elaborated upon again. The corresponding technical effects and principles can also be understood by comparison.

[0268] Compared with existing technologies, the zero-trust security authentication method for accessing heterogeneous hospital devices based on desktop virtualization technology proposed in this invention has the following significant advantages:

[0269] (1) After the device passes the identity authentication, a communication pre-connection is established first, so that the hospital information system can obtain the device's operating system type and application data in one direction, providing richer information support for the subsequent authentication process and greatly improving the accuracy and security of authentication.

[0270] (2) By isolating different types of devices in their respective virtual network partitions and utilizing the zero-trust adaptation environment provided by secure container images, devices operate in a state of minimum privilege, prohibiting connection to peripheral accessories, thus reducing the risk of data leakage from multiple aspects and greatly improving the overall security of the system. (3) Continuously acquiring security logs of the virtual network partitions, once abnormal device behavior is detected, the corresponding target container can be quickly suspended, requiring the device to re-authenticate its identity and environment, and the container can be flexibly restored or destroyed based on the authentication results. This real-time monitoring and dynamic response mechanism effectively curbs the spread of potential security threats and ensures the stable operation of the hospital information system.

[0271] (4) Collect device fingerprint information (including device hardware information such as MAC address, CPU serial number and software information such as operating system version, patch status value), access location information, network status information and other multi-dimensional information for authentication. Compared with the shortcomings of existing technologies in environmental authentication, this method can more comprehensively and accurately identify the uniqueness and security of devices, avoid malicious devices from accessing through insecure networks or false locations, and greatly improve the reliability and effectiveness of environmental authentication;

[0272] (5) By adopting the mechanism of “continuous monitoring-dynamic response-closed-loop handling”, the security protection of HIS is extended from “defense during access” to “defense during interaction”. This not only meets the core requirement of “continuous verification” in zero trust, but also addresses the pain points of dynamic changes in risks of heterogeneous devices, high business continuity requirements and high compliance pressure in medical scenarios. It builds a full-cycle security barrier of “prevention before the event, control during the event and traceability after the event” for medical data interaction.

[0273] Other technologies, principles, algorithms, or models not elaborated in detail in this application can be found in the prior art.

[0274] The foregoing has shown and described the method embodiments and systems of the present invention, but it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A zero-trust security authentication method for hospital heterogeneous device access, the method is implemented based on desktop virtualization technology, characterized in that, The method comprises the following steps: After the heterogeneous device is authenticated by identity, a communication pre-connection between the heterogeneous device and the hospital information system is established, and the communication pre-connection enables the hospital information system to unidirectionally acquire the operating system type and application data of the heterogeneous device; Based on the operating system type and application data of the heterogeneous device, a virtual network partition is created on a data center server of the hospital information system, and each virtual network partition corresponds to an operating system type; After the application data of the heterogeneous device is received in each virtual network partition, a security container image corresponding to the operating system type of the heterogeneous device is called to create a target container; Environment authentication information is sent to the heterogeneous device through the target container; the environment authentication information comprises device fingerprint information, access location information and network state information; The device fingerprint information is generated from device hardware information and software information collected by the target container; The device hardware information comprises a MAC address and a CPU serial number; and the software information comprises an operating system version and a patch state value; When the environment authentication information is passed, a data interaction connection between the heterogeneous device and the virtual network partition of the hospital information system is established, and the data interaction connection enables the heterogeneous device to access the hospital information system through the target container.

2. The zero-trust security authentication method for hospital heterogeneous device access according to claim 1, characterized in that: After the data interaction connection between the heterogeneous device and the virtual network partition of the hospital information system is established, the method further comprises: Continuously acquiring security logs of each virtual network partition; When an abnormal behavior of the heterogeneous device is detected, the target container corresponding to the heterogeneous device is suspended.

3. The zero-trust security authentication method for hospital heterogeneous device access according to claim 1, characterized in that: The security container image provides a zero-trust adaptation environment, and the zero-trust adaptation environment enables the heterogeneous device to run in a minimum permission state, and the minimum permission state prohibits the heterogeneous device from connecting external accessory devices.

4. The zero-trust security authentication method for hospital heterogeneous device access according to claim 2, characterized in that: When an abnormal behavior of the heterogeneous device is detected, the target container corresponding to the heterogeneous device is suspended, and the heterogeneous device is required to re-perform identity authentication and environment authentication; When the identity authentication and the environment authentication are both passed, the target container is restored; otherwise, the target container is destroyed.

5. A hospital heterogeneous device zero trust security authentication system based on desktop virtualization, characterized in that, The system comprises: A pre-connection establishment module configured to, after a heterogeneous device is authenticated by initial identity, establish a unidirectional communication pre-connection with a hospital information system, and acquire an operating system type and application data of the heterogeneous device; A virtual network partition creation module configured to, based on the operating system type and the application data, create a virtual network partition on a data center server, and each partition corresponds to a specific operating system type; A security container deployment module configured to, in each virtual network partition, call a corresponding security container image according to the operating system type of the heterogeneous device, and create a target container for running an application. An environment authentication module is configured to send environment authentication information to a heterogeneous device through the target container to verify the security of the device operating environment. A data interaction module is configured to establish a data interaction connection between the heterogeneous device and the corresponding virtual network partition when the environment authentication is passed, so that the device accesses the hospital information system resources through the target container. The initial identity authentication is configured to verify the identity information of the heterogeneous device, and the identity information includes a username / password, a biological feature, and a digital certificate. The environment authentication information includes device fingerprint information, access location information, and network state information, and the device fingerprint information is generated from device hardware information and software information collected by the target container. The device hardware information includes a MAC address and a CPU serial number, and the software information includes an operating system version and a patch state value.

6. The hospital heterogeneous device zero trust security authentication system based on desktop virtualization of claim 5, wherein, The virtual network partition creation module includes: An SDN controller is configured to dynamically create and manage virtual network partitions based on software-defined network technology. A VLAN allocation unit is configured to allocate independent VLANs (virtual local area networks) for devices of different operating system types. An access control list (ACL) configuration unit is configured to set an initial security policy for each virtual network partition.

7. The hospital heterogeneous device zero trust security authentication system based on desktop virtualization of claim 5, wherein, The security container deployment module includes: A container image library is configured to store security container images corresponding to each operating system type, including a basic OS environment image and a medical application runtime image. A container orchestration engine is configured to deploy and manage the target container within the virtual network partition based on Kubernetes or Docker Swarm technology.

8. The hospital heterogeneous device zero trust security authentication system based on desktop virtualization of claim 5, wherein, The data interaction module includes: A secure tunnel establishment unit is configured to establish an encrypted communication tunnel between the heterogeneous device and the target container through TLS 1.3 or IPsec protocol. A traffic monitoring unit is configured to monitor data interaction traffic in real time, detect and intercept abnormal data packets.

9. The hospital heterogeneous device zero trust security authentication system based on desktop virtualization of claim 5, wherein, The virtual network partition supports nested subdivision, creates sub-partitions based on device functions or data sensitivity, and configures independent access control policies for each sub-partition.

Images