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

Abstract

The invention provides a zero-trust security authentication system and method for hospital heterogeneous equipment access, and belongs to the technical field of security authentication and virtualization. The method comprises the following steps: after the heterogeneous equipment passes identity authentication, establishing communication pre-connection, so that a hospital information system unidirectionally acquires an operating system type and application program data of the heterogeneous equipment; the method comprises the following steps: creating a virtual network partition on a data center server of a hospital information system based on an operating system type and application program data of heterogeneous equipment; after each virtual network partition is used for receiving application program data of the heterogeneous equipment, calling a security container mirror image to create a target container, wherein the security container mirror image corresponds to an operating system type of the heterogeneous equipment; sending environment authentication information to the heterogeneous device through the target container; and when the environment authentication information is passed, establishing data interaction connection between the heterogeneous equipment and the virtual network partition of the hospital information system, so that the heterogeneous equipment accesses the hospital information system through the target container.

Description

Technical Field

[0001] The present invention belongs to the technical field of security authentication and virtualization technology, and in particular relates to a zero-trust security authentication method and system for access of heterogeneous devices in a hospital. Background Art

[0002] Different from the traditional network boundary security architecture, the zero-trust security model requires identity authentication before each authorized operation, so as to differentially control user permissions and achieve the effect of controlling the internal network. In the zero-trust system, whether the access comes from inside or outside the enterprise, whether it is employees, partners, or devices and applications, before obtaining resource access rights, they must undergo strict and continuous identity authentication, authorization review and security status assessment. This means that even if the user has passed the initial login authentication, when accessing different resources or performing key operations, the system will still dynamically adjust the access rights based on the real-time risk situation and require re-verification. Relevant technologies include the terminal trust enhancement method and system based on virtualization technology proposed by the invention patent CN105354493B, and the model framework of the smart IoT zero-trust network based on the property management platform based on intrinsic security proposed by the Chinese invention disclosure text CN119853939A.

[0003] However, existing technologies lack comprehensive consideration of key information such as the device's operating system type and application data when handling communications between heterogeneous devices and hospital information systems. Before establishing a connection, the device's operating environment cannot be fully understood, making it impossible for the system to formulate targeted security policies. For example, the use of the same communication rules for devices running different operating system versions fails to consider that lower-version operating systems may contain more security vulnerabilities, making them vulnerable to attacks and increasing the risk of data leakage and tampering during communication. Traditional technologies are unable to effectively restrict the operating permissions of heterogeneous devices when building a zero-trust adaptive environment. Once a device is connected to the system, it is difficult to ensure that it operates in a state of minimum privilege. Devices can freely connect to external accessories, such as unauthorized storage devices via USB ports. This greatly increases the risk of data leakage. For example, malware could spread through external devices to the hospital information system, destroying data or stealing sensitive information. Furthermore, most traditional security certification systems have serious shortcomings in device environment certification. The system fails to fully consider and effectively collect detailed information about device hardware (such as MAC addresses and CPU serial numbers) and software (such as operating system versions and patch status values) when it comes to device fingerprints, making it difficult to accurately identify device uniqueness and security. It also lacks a real-time monitoring and analysis mechanism for device access locations and network status. This allows malicious devices to access hospital information systems undetected, using insecure networks or fake locations, posing a serious threat to system security. Summary of the Invention

[0004] In response to the above technical problems, the present invention proposes a zero-trust security authentication method and system for heterogeneous device access in hospitals.

[0005] In a first aspect of the present invention, a zero-trust security authentication method for access of heterogeneous devices in a hospital is proposed, wherein the method is implemented based on desktop virtualization technology; The method comprises: After the heterogeneous device passes identity authentication, a communication pre-connection is established between the heterogeneous device and the hospital information system, wherein the communication pre-connection enables the hospital information system to unidirectionally obtain the operating system type and application data of the heterogeneous device; Based on the operating system type and application data of the heterogeneous devices, creating virtual network partitions on the data center server of the hospital information system, each virtual network partition corresponding to an operating system type; After each virtual network partition receives the application data of the heterogeneous device, calling the secure container image to create a target container, the secure container image corresponds to the operating system type of the heterogeneous device; Sending environmental authentication information to the heterogeneous device through the target container; When the environment authentication information is passed, a data interaction connection is established between the heterogeneous device and the virtual network partition of the hospital information system, and the data interaction connection enables the heterogeneous device to access the hospital information system through the target container.

[0006] The environmental authentication information includes device fingerprint information, access location information, and network status information; The device fingerprint information is generated by the device hardware information and software information collected by the target container; The device hardware information includes the MAC address and CPU serial number; the software information includes the operating system version and patch status value.

[0007] After establishing a data interactive connection between the heterogeneous device and the virtual network partition of the hospital information system, the method further includes: Continuously obtain security logs for each virtual network partition; When abnormal behavior of a heterogeneous device is detected, the target container corresponding to the heterogeneous device is paused.

[0008] 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.

[0009] 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; When both identity authentication and environment authentication are passed, the target container is restored; otherwise, the target container is destroyed.

[0010] In a second aspect of the present invention, a zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization is proposed, the system comprising: A 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 obtain the operating system type and application data of the heterogeneous device; a virtual network partition creation module, configured to create virtual network partitions on the data center server based on the operating system type and application data, each partition corresponding to a specific operating system type; A 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 to create a target container for running the application; An environment authentication module, configured to send environment authentication information to the heterogeneous device through the target container to verify the security of the device's operating environment; A data interaction module is used 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 can access the hospital information system resources through the target container; The initial identity authentication is used to verify the identity information of the heterogeneous device, and the identity information includes username / password, biometrics, and digital certificate; The environmental authentication information includes device fingerprint information, access location information, and network status information.

[0011] The virtual network partition creation module includes: SDN controller: Dynamically creates and manages virtual network partitions based on software-defined networking technology; VLAN allocation unit: allocates independent VLANs (virtual local area networks) to devices of different operating system types; Access Control List (ACL) configuration unit: Sets the initial security policy for each virtual network partition.

[0012] The secure container deployment module includes: Container image library: stores secure container images corresponding to various operating system types, including basic OS environment images and medical application runtime images; Container orchestration engine: Based on Kubernetes or Docker Swarm technology, it deploys and manages target containers within a virtual network partition.

[0013] The data interaction module includes: Secure tunnel establishment unit: establishes an encrypted communication tunnel between heterogeneous devices and the target container through TLS1.3 or IPsec protocol; Traffic monitoring unit: monitors data exchange traffic in real time, detects and intercepts abnormal data packets.

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

[0015] Compared with the existing technology, the zero-trust security authentication method for hospital heterogeneous device access based on desktop virtualization technology proposed in this invention has the following significant advantages: This invention introduces a communication pre-connection mechanism for the first time in the authentication process. Existing technologies often rely on one-time static authentication, making it difficult to fully capture device information. However, this invention establishes a communication pre-connection after the device passes identity authentication, enabling the hospital information system to unidirectionally obtain the device's operating system type and application data. This provides richer information support for subsequent authentication processes, significantly improving authentication accuracy and security. At the security protection level, the present invention creates virtual network partitions based on the device operating system type, and calls the corresponding secure container image to create the target container, thereby building a more sophisticated and isolated security environment. Traditional technologies lack targeted protection for devices with different operating system types, which is prone to security vulnerabilities. The present invention isolates different types of devices in their own virtual network partitions and uses the zero-trust adaptation environment provided by the secure container image to enable the device to run in a minimum authority state, prohibit the connection of peripheral accessory devices, and reduce the risk of data leakage in many aspects, greatly improving the overall security of the system. Dynamic monitoring and response capabilities are also one of the outstanding advantages of the present invention. The existing technology does not monitor the behavior of the device after access, and it is difficult to detect anomalies in time. The present invention continuously obtains virtual network partition security logs. 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 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. For environmental authentication, this invention collects multiple dimensions of information, including device fingerprint information (including hardware 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, for authentication. Compared to the shortcomings of existing technologies in environmental authentication, this invention can more comprehensively and accurately identify device uniqueness and security, preventing malicious devices from accessing through insecure networks or false locations, significantly improving the reliability and effectiveness of environmental authentication.

[0016] Further specific advantages and implementation principles of the present invention will be further embodied in detail in the specific embodiments section in conjunction with the drawings of the specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] 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; Figure 2 yes Figure 1 A schematic diagram of a further preferred embodiment of the zero-trust security authentication method for heterogeneous device access in a hospital; Figure 3 This is a schematic diagram of the hardware unit composition of a zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization according to an embodiment of the present invention; Figure 4 yes Figure 3 Schematic diagram of a preferred embodiment of the zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization. DETAILED DESCRIPTION

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

[0020] This section describes 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, resolving one or more technical problems mentioned in the background art and achieving one or more significant benefits.

[0021] However, it is understandable that not every embodiment is required to solve all technical problems mentioned in the background art or achieve all 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, possesses outstanding substantive features or represents significant progress, the technical solution constituted by the individual embodiment should possess novelty and inventiveness within the meaning of patent law.

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

[0023] For the convenience of description, Figure 1 The steps of the embodiment are expanded and numbered as S1-S5 (step numbers are omitted in the drawings): 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; 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, each virtual network partition corresponding to an operating system type; S3: After each virtual network partition receives the application data of the heterogeneous device, calling the secure container image to create a target container, the secure container image corresponds to the operating system type of the heterogeneous device; S4: Sending environmental authentication information to the heterogeneous device through the target container; S5: When the environment authentication information is passed, a data interaction connection is established between the heterogeneous device and the virtual network partition of the hospital information system, and 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.

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

[0025] The following sections will further illustrate the above steps with reference to specific scenario examples. It should be understood that these scenario examples are merely enumerations and not exhaustive, and the technical solutions of the present invention may also be applied to other examples. The relevant examples do not constitute a limitation on the scope of protection of the present invention.

[0026] In addition, in order to make the scenario examples richer, 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 partial and limited examples, even in the same embodiment, the scenario examples mentioned in different steps may not have a literal connection (but the content actually belongs to the same category).

[0027] First is 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.

[0028] Step S1 is the initial secure access phase for heterogeneous devices to the hospital information system (HIS). Its core goal is to establish a temporary, low-privilege communication channel based on trusted identity verification, enabling the HIS to securely collect basic device information. 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.

[0029] Preferably, when implementing step S1, the following aspects are specifically included: Authentication targets: Covering the three dimensions of "device, user, and application." This not only verifies the physical identity of the device (e.g., the device's unique hardware identifier, MAC address, or IMEI), but also the identity of the medical professional using the device (e.g., employee ID, role permissions), and the legitimacy of the medical-related applications running on the device (e.g., application signature, access whitelist). Authentication method adaptation: Select an adaptation solution based on the characteristics of heterogeneous devices. For doctor 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), superimposing dynamic tokens (such as RSASecurID) or biometrics (fingerprint / face, integrated through Windows Hello or macOS TouchID). For mobile terminals (nurse Android / iOS tablets): through device certificate authentication, the device is pre-installed with an X.509 digital certificate issued by the hospital when it leaves the factory. When accessing, it passes the certificate chain verification in the TLS handshake phase (the root certificate is stored on the HIS authentication server), and at the same time, the role permission verification associated with the nurse's work number is performed. For IoT medical devices (such as ECG monitors and infusion pumps): lightweight authentication is used. Due to limited device resources, a hash check of a preset static key and the device's unique identifier (such as a SN code) is used to avoid complex calculations. The key is written to the device's security chip (such as a SE chip) through offline burning. Authentication process: A unified authentication portal is implemented 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 based on Keycloak). After the server verifies the request, it returns a temporary authentication token with an expiration date (such as a JWT token, containing metadata such as device identification and user role) as a credential for subsequent pre-connection. After identity authentication is passed, a temporary, low-privilege communication pre-connection needs to be established, which is reflected in "lightweight connection + one-way permission control": Connection type: This establishes a basic transmission channel based on the TCP protocol. To ensure security, it uses TLS 1.3 for encryption and encapsulation to prevent eavesdropping and tampering during data transmission. Pre-connection does not rely on complex session management and only maintains minimal communication links (for example, limiting ports to non-core service ports such as TCP 8088). Unidirectional protection: Network access control lists (ACLs) and firewall rules restrict data flow. Only heterogeneous devices are allowed to send data to the HIS (hospital information system). The HIS only opens data receiving ports, prohibiting devices from actively requesting HIS core resources (such as electronic medical record databases and pharmacy management systems). For example, the HIS access layer firewall can be configured with the rule "allow inbound devices to access HIS data collection services, and deny outbound HIS-device unnecessary responses." Connection lifecycle: Pre-connection is a temporary state, valid only during the information collection phase (usually lasting 30-60 seconds). It automatically disconnects after the collection is complete, avoiding security risks brought by long-term connections. The hospital information system obtains the "operating system type" and "application data" through pre-connection in a one-way manner. The core technology relies on the combination of active reporting by the device and passive analysis by the HIS. Get the operating system type: For general terminals (PCs / tablets): The request header sent by the device through the HTTP / HTTPS protocol carries the User-Agent field. The HIS data collection service parses this field to extract OS information.

[0030] For IoT devices: Reports are made through device-specific protocols. For example, an embedded Linux device sends a message through the MQTT protocol that carries the field OS:Linux-5.10.0-embedded. The HIS directly extracts this metadata. For medical applications (such as electronic medical record clients and mobile ward rounds apps): the device actively reports the application identifier (such as AppID:EMR_Client_v2.5.3), the application signature hash value (used to verify that the application has not been tampered with), and the operating status (such as whether it is running in the background and whether the encryption module is enabled) through the API interface. For common office applications (such as browsers and document tools): HIS uses port scanning (only in the pre-connection phase, which allows security scanning) to identify the application processes corresponding to the device's open ports. For example, if it detects that the process corresponding to port 8080 is Chrome.exe (browser), it can verify that the process is used to access the HIS web portal based on the User-Agent. In combination with the above principle introduction, the following two common schematic terminal access scenarios can specifically describe the implementation process of step S1.

[0031] Scenario 1: A cardiologist uses a laptop running macOS Ventura to access the HIS Identity authentication: The doctor enters his / her work ID "DR-202305" and password in the HIS client on his / her laptop. The client uses macOS's TouchID to complete the second biometric verification. The authentication request is verified through the SAML2.0 protocol of the hospital's IAM platform and returns a JWT token valid for 5 minutes. Communication pre-connection establishment: The client uses the token to establish a TCP connection with the HIS data collection service (deployed on the back end of the access gateway) through a TLS1.3 encrypted channel. The firewall restricts the connection to allow only the client to send data. One-way data acquisition: The HIS parses the User-Agent (Mozilla / 5.0 (Macintosh; Intel Mac OS X 13_4) Apple Web Kit / 605.1.15 (KHTML, like Gecko) Version / 16.5 Safari / 605.1.15) sent by the client and determines that the operating system is macOS Ventura 13.4. At the same time, the client actively reports the running application data: App ID: Cardio_EMR_v3.2 (cardiology electronic medical record client) and the application signature hash value, and the HIS completes the information collection. Scenario 2: Pediatric nurse accesses HIS using an Android 14 tablet Identity authentication: The tablet has a built-in device certificate issued by the hospital. The validity of the certificate is verified through a TLS handshake during access. At the same time, the nurse completes a facial comparison on the tablet app (associated with employee number "NR-202312") and the authentication is passed. Communication pre-connection establishment: The tablet establishes a temporary connection with the HIS through the HTTPS protocol. The access layer firewall configuration only allows the tablet to send data to the HIS port 8088. One-way data acquisition: The HIS parses the User-Agent to obtain Android 14 system information; the tablet reports the running Pediatric_Nursing_v1.8 (pediatric nursing app) version and process status, and the HIS completes basic information collection.

[0032] Next, proceed to step S2.

[0033] Step S2 is the core step in achieving network isolation and refined management and control within the hospital information system (HIS). Based on the "operating system type" and "application data" of heterogeneous devices acquired in S1, virtual network partitions are dynamically created on the data center servers, specifically for the operating system. Its core goal is to achieve logical isolation of different types of devices through network virtualization technology, reducing cross-platform security risks and laying the foundation for subsequent containerized operations and data exchange.

[0034] The specific implementation of step S2 includes the following aspects: VLAN (Virtual Local Area Network) or VXLAN (Virtual Extended Local Area Network) technology is used to divide logical isolation domains. For small-scale hospital scenarios, VLAN tags (such as VLAN ID 100-200) are used to assign independent broadcast domains to different operating systems, limiting direct communication across VLANs. For large-scale heterogeneous device access (such as a tertiary hospital with dozens of terminal types), VXLAN's 24-bit VNI (Virtual Network Identifier) ​​is used to achieve more fine-grained isolation, supporting virtual partition expansion across physical servers. Tunnel encapsulation uses the UDP protocol (port 4789) to ensure independence from the underlying physical network. Virtual network partitions must be deeply integrated with the hospital's desktop virtualization platform (such as Citrix Virtual Apps or Huawei FusionAccess). The platform APIs are used to obtain the operating system metadata of the virtual desktop / terminal to ensure that the partitions are consistent with the actual terminal operating environment. For example, when a new macOS device is detected, the virtualization platform automatically triggers the partition creation command without manual intervention. The creation of virtual network partitions is based on the operating system type, supplemented by application data. Core rules include partition mapping relationships, differentiated configuration, and security policy binding: Mapping relationship between partitions and operating systems: Establish a "one-to-one" basic mapping rule, that is, each operating system type corresponds to a unique virtual network partition. Common mapping examples are as follows: Windows (including Windows 10 / 11 and Windows Server terminals) → VLAN 100 (or VXLAN VNI 1000) macOS (including macOS Ventura / Sonoma) → VLAN 101 (or VXLAN VNI 1001) Android (including Android 13 / 14 mobile terminals) → VLAN 102 (or VXLAN VNI 1002) iOS (including iOS 16 / 17 tablets / phones) → VLAN 103 (or VXLAN VNI 1003) Embedded Linux (medical IoT devices) → VLAN 104 (or VXLAN VNI 1004) Application data is used to verify the authenticity of the operating system type to prevent devices from forging OS information to bypass isolation. For example, if the operating system type obtained by S1 is "Android 14", but the application data shows that it is running EMR_Client_v3.2 (electronic medical record client) which only supports Windows, the abnormal verification mechanism will be triggered, the partition creation will be rejected, and the device will be marked as "pending review"; Configure dedicated network parameters based on the characteristics of different operating systems: Protocol support: Windows partitions open SMB protocol ports (for file sharing), while Android / iOS partitions only open HTTPS (port 443) and MQTT (port 8883, for IoT data transmission); Security group rules: The embedded Linux medical device partition is restricted to communicating only with the HIS device management server (fixed IP address 192.168.10.10) and is prohibited from accessing the Internet. Data buffer: Configure a larger network buffer (such as 1MB) for high-concurrency Windows doctor workstation partitions to reduce data transmission latency. The partition control server in the HIS data center receives device data uploaded by S1 and uses a parsing engine to extract key information: operating system type (such as "macOS Ventura 13.4") and application validity verification results (such as "AppID: Cardio_EMR_v3.2 signature valid"). The parsing engine uses a rules engine (such as Drools) to match a preset OS-partition mapping table to determine the target partition type. The partition control server uses the SDN controller API (such as the OpenFlow protocol) to issue creation instructions to data center network devices. These instructions include parameters such as the partition identifier (VLAN ID / VNI), resource quota, and security policy ID. For example, for macOS devices, the instruction issued might be "Create VLAN 101, bind security policy ID 002, and allocate 1 vCPU, 2 GB of memory, and 50 Mbps of bandwidth." The SDN controller collaborates with the virtual switch and hypervisor to create zones: The virtual switch creates an independent port group and binds the target VLAN / VNI tag; The hypervisor allocates computing resources and creates virtual network interfaces (vNICs); The firewall automatically loads the access control list (ACL) of the corresponding partition, such as "allow VLAN 101 to access the HIS database server 192.168.20.5 and prohibit access to other VLANs." After the partition is created, the control server verifies the partition availability through ICMP ping and port scanning. After confirming that the virtual switch flow table rules are effective and resource allocation is correct, it marks the partition status as "available" and records the binding relationship between the device and the partition (stored in the device_partition_mapping table in the MySQL database). In combination with the above principle introduction, the following two common schematic terminal access scenarios can specifically describe the implementation process of step S2.

[0035] Scenario 3: A surgeon accesses a Windows 11 workstation and creates a partition Information analysis: The HIS partition control server receives device data and parses the operating system type as "Windows1122H2". The application data shows that it is running Surgical_Planning_v4.0 (surgical planning software with a valid signature). The OS-partition mapping table is matched to determine that the target partition is "VLAN100". Instruction issuance: The VLAN 100 creation instruction is issued through the SDN controller API and bound to the security policy (allowing access to the surgical image server 192.168.30.8 and prohibiting access to the pharmacy system). Partition initialization: The virtual switch creates the port group "Win11-Surgical" and binds it to VLAN 100. The hypervisor allocates 2 vCPUs and 8 GB of memory resources. The firewall loads the ACL rule "inbound allow 192.168.30.8 → VLAN 100, outbound deny VLAN 100 → 192.168.40.0 / 24 (pharmacy network segment)." Status verification: The control server pings the VLAN 100 gateway (192.168.10.1), confirms that ports 80 and 443 are open, marks the partition as "available," and records the binding relationship "Device SN: W202306 → VLAN 100." Scenario 4: Creating a Partition for Connecting an Embedded Linux ECG Monitor Information analysis: Device data shows that the operating system is "Linux-5.10.0-embedded", the application data is ECG_Monitor_v2.1 (ECG monitoring software, only supports embedded Linux), and the matching mapping table determines that the target partition is "VLAN104". Command issuance: Issue the VLAN 104 creation command, set the resource quota to 0.5 vCPU, 1 GB memory, and 10 Mbps bandwidth, and bind the IoT-specific security policy. Partition initialization: The virtual switch creates the port group "Linux-ECG" and binds it to VLAN 104; restricts communication with the HIS monitoring data server (192.168.50.3) to the MQTT protocol (port 8883); and disables USB ports and Internet access permissions. Status verification: Verify that the MQTT connection between the partition and the monitoring data server is normal, there is no cross-segment communication behavior, and mark the partition as "available".

[0036] Next, proceed to step S3.

[0037] Step S3 is the key step in achieving secure operating environment isolation for heterogeneous devices based on virtual network partitioning. This core mechanism utilizes a "OS type matching + containerized dynamic deployment" mechanism to create a dedicated secure operating space for connected devices. This process leverages container virtualization technology to logically isolate device application data from core hospital information system (HIS) resources, while ensuring compatibility and security of the operating environment.

[0038] The specific implementation of step S3 includes the following aspects: 1. Target Container Creation The creation of the target container must meet the three conditions of "partition readiness + data reception + image matching", which is the connection point between virtual network partitioning and container technology: Virtual network partition readiness status verification: Before creating a container, verify that the virtual network partition has been initialized (status: "Available") using the partition status API (e.g., / api / partition / status via the RESTful API) and obtain the partition's network configuration information (e.g., subnet mask, gateway IP, and security group rules). For example, for a Windows partition (VLAN 100), parameters such as "subnet 192.168.100.0 / 24, gateway 192.168.100.1, and ports 445 and 3389 allowed" must be returned to ensure seamless access to the container network. Integrity check of application data: After receiving application data from heterogeneous devices, the virtual network partition must verify that the data has not been tampered with through hash checks (such as SHA-256) and digital signature verification. For example, for the Pediatric_Nursing_v1.8 application data uploaded by an Android device, the file hash value must be verified to be consistent with the benchmark value stored in the HIS application library, and the signing certificate must be issued by the hospital's CA organization to prevent malicious application data from triggering container creation. Container engine environment support: Hospital data center servers must deploy a container orchestration engine (such as Kubernetes or Docker Swarm). Kubernetes uses Pod resources to manage the container lifecycle, while Docker Swarm is suitable for rapid deployment in small-scale scenarios. The engine must be pre-configured with a container runtime (such as containerd) that supports the OCI (Open Container Initiative) standard image format to ensure compatibility with secure container images. 2. Adaptation Mechanism for Secure Container Images One-to-one mapping between images and operating systems: Based on the operating system type obtained by S1, the corresponding secure container image is matched in the image repository. For example: Windows 10 / 11 devices correspond to the win10-secure-container:v2.3 image, which integrates the .NET Framework runtime and medical software dependency libraries; Android13 / 14 devices correspond to the android13-medical-container:v1.8 image, which has pre-installed AndroidSDK and medical data encryption modules; Embedded Linux devices correspond to the linux-embedded-iot-container:v3.1 image, which uses the lightweight Alpine Linux base layer and retains only MQTT communication and device driver dependencies. The hierarchical storage architecture of the image repository: Secure container images are stored in the hospital's private image repository (e.g., Harbor), using a tiered storage mechanism: the base layer includes core operating system components (e.g., Windows kernel, Linux kernel), the middle layer integrates common medical components (e.g., data encryption SDK, log auditing tools), and the application layer loads specialized application runtime environments (e.g., electronic medical record client runtime) based on device type. This tiered design reduces image redundancy and improves image pull efficiency (e.g., the base layer of a Windows image can share storage, requiring only the application layer to be updated). All secure container images must undergo automated scanning (such as using Clair or Trivy) and manual review to ensure they contain no high-risk vulnerabilities (such as container escape vulnerabilities like CVE-2023-20197). Security is also enhanced through the following mechanisms: Remove unnecessary tools (such as bash and wget) from the image and limit operation permissions within the container; Enable image signature verification (such as DockerContentTrust) to only allow loading of images signed by the hospital information department; Integrate security monitoring agents (such as Falco) to detect abnormal behavior in containers in real time (such as unauthorized file access and process privilege escalation). The specific process of creating a target container is as follows: Image pull and verification: The container engine pulls the corresponding secure container image from a private image repository based on the operating system type. The pull process is encrypted via HTTPS and the image's digital signature and integrity hash are verified. For example, when pulling the macos-medical-container:v2.1 image for a macOS device, the signature certificate chain is verified to point to the hospital's root CA to ensure that the image has not been tampered with or replaced. Container configuration dynamic injection: The engine injects environment variables and configuration files for the virtual network partition into the container, including: Network configuration: Use the --network parameter to connect the container to the target virtual network partition (for example, --networkvlan101-net to bind the macOS partition network); Resource limits: Set CPU / memory limits based on the 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). Security parameters: Enable --read-only to read-only file system, and --cap-dropALL to disable privileged capabilities, retaining only necessary network communication permissions. Resource binding and dependency mounting: The container is bound to the storage resources of the virtual network partition and uses a persistent volume (PersistentVolume) to mount the device-specific data directory (such as / data / device / {SN}) for application cache and temporary data. It also mounts the hospital's unified configuration center configuration file (such as / etc / medical / config.yaml), which contains dynamic parameters such as the HIS service address and encryption keys, to avoid hard-coding sensitive information. Container activation and status monitoring: After the container starts, it automatically executes the initialization script (such as entrypoint.sh), starts the application runtime environment, and registers it with the HIS container management platform. The platform monitors the container status through health check interfaces (such as / health). If three consecutive checks fail (such as a port not listening or a service not responding), an automatic restart or image re-pull mechanism is triggered. As a further preference, 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.

[0039] Secure container images not only provide a runtime environment that matches the operating system but also enable dynamic security management and control of heterogeneous devices through a zero-trust adaptive environment. Based on the principle of "never trust, continuously verify," the zero-trust architecture ensures that devices operate only within pre-defined security boundaries through least privilege convergence and peripheral access blocking.

[0040] The zero-trust adaptive environment is achieved through pre-configured secure container images and a dynamic verification mechanism. Core technologies include dynamic identity binding, environment baseline hardening, and real-time behavior auditing. Dynamic binding of identity and environment: The image has a built-in identity authentication agent that automatically establishes an encrypted channel with the HIS Zero Trust Management Platform upon startup. It then binds the container ID, device SN, and user ID to form a unique, trusted identity. For example, when a Windows container starts, ztna-agent.exe sends a binding request to the platform with the following information: "Container ID: c8f2e1d0-xxx; Device SN: W202306; User ID: DR-202305." The platform only grants execution permissions after successful verification, preventing identity theft. Solidification of operating environment baseline: The image pre-sets the operating system environment baseline, solidifies key configuration parameters (such as process whitelists, registry entries, and system call rules), and prohibits devices from modifying core configurations. For example, the Android secure container image uses SELinux policy to solidify the read-only attribute of the / system directory, allowing only the Pediatric_Nursing_v1.8 process to read and write in the / data / app directory. Unauthorized operations by other processes will be blocked in real time. Real-time behavior auditing and dynamic blocking: The image integrates zero-trust monitoring components (such as eBPF-based behavior tracking tools) to collect real-time behavioral data such as process calls, network connections, and file operations within the container. The rules engine then matches abnormal patterns (such as unauthorized process creation and sensitive port access). When risky behavior is detected, blocking instructions (such as terminating the process or disabling the network interface) are immediately triggered, and an alert is simultaneously sent to the HIS security management platform. The least privilege state is a core feature of a zero-trust adaptation environment. By splitting permissions granularly and dynamically converging, it ensures that heterogeneous devices have only the minimum permissions necessary to complete their business. Technical measures include: Process privilege convergence: Application processes running within the container are started with non-root / Administrator privileges, and privileged operations are restricted through the Linux capabilities mechanism or Windows User Account Control (UAC). For example, the EMR_Client_v3.2 process in the electronic medical record container is only assigned "file read / write (limited to the / data / emr directory) and network access (only HIS database port 3306)" permissions. High-risk system calls such as chmod777 and regadd are prohibited. Precise control of network access permissions: Based on a zero-trust network micro-segmentation strategy, containers are only allowed to access essential HIS service IP addresses and ports, and wildcard address access is prohibited. For example, an embedded Linux ECG monitor container uses iptables rules to restrict access to the HIS IoT platform (192.168.50.3) via TCP port 8883, prohibiting access to the internet or other unrelated network segments (such as 192.168.40.0 / 24 for the pharmacy system). File system permission isolation: The container uses a read-only root file system (--read-only). Only temporary directories essential for business operations (such as / tmp and / var / log) are writable, and access control lists (ACLs) are used to restrict read and write access. For example, the / data / nursing directory in an Android nursing container is readable and writable only by the current application process, prohibiting access by other processes (including non-associated processes within the container) to prevent cross-data leakage. The zero-trust adaptation environment uses dual blocking at both the container and host layers to prohibit heterogeneous devices from connecting to peripheral accessories (such as USB storage, Bluetooth devices, and external monitors), preventing data leakage or malicious device access. The specific mechanism is as follows: Container layer peripheral access blocking: The secure container image pre-configures peripheral disabling configurations and restricts peripheral driver loading and access through system-level policies: Linux system container: Disable USB storage devices through udev rules (SUBSYSTEM=="usb",ATTR{idProduct}=="",ATTR{idVendor}=="",MODE="0000") and uninstall peripheral driver modules such as Bluetooth and NFC (for example, rmmodbtusb). Windows system container: Integrate the Group Policy template (ADMX), disable the "Removable Storage Access" and "USB Device Enumeration" permissions, and set Start=4 (disable USB storage service) in the registry key HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR. Android system container: Disable Bluetooth, USB debugging, and external storage access through the DevicePolicyManager API, setting setUsbMassStorageEnabled(false) and setBluetoothEnabled(false). Host layer peripheral access verification: The container engine of the hospital data center server works in conjunction with the host operating system to perform a secondary interception of external device access requests: The host Linux uses cgroups to restrict the device access rights of the container. devices.allow only retains necessary virtual devices (such as / dev / null and / dev / zero) and prohibits access to physical peripheral device files (such as / dev / sdb and / dev / ttyUSB0). The host Windows uses Hyper-V isolation technology to prevent the container process from calling CreateFile to open the USB device handle, and the peripheral access event is reported to the HIS security platform in real time. Real-time alarm for abnormal access: The zero-trust monitoring component continuously detects peripheral connection attempts (such as udev events triggered by USB device insertion and Bluetooth pairing requests). Once unauthorized operations are detected, they are immediately blocked and an alarm log is generated (including device SN, time, and peripheral type), which is simultaneously pushed to the Information Department Operation and Maintenance Platform to support traceability audits. Next, we will introduce two secure container application scenarios under zero trust adaptation scenarios.

[0041] Scenario 5: Electronic Medical Record Container on a Windows Workstation in the Operating Room Zero Trust adaptation environment configuration: The secure container image win11-emr-container:v3.2 has a pre-installed zero trust agent. The identity "device SN: W202306 + employee number: DR-202305" is bound to the image at startup. The process runs with the privileges of the ordinary user "EMR_User", and is only allowed to access the / data / emr directory and the HIS database port. Minimum privilege state: Modifying the system time, installing software, accessing sensitive registry entries such as HKLM\Software, etc. are prohibited. The network is only allowed to connect to the electronic medical record server (192.168.30.8:1433). Peripheral device prohibition effect: USB storage, HDMI external display and Bluetooth are disabled through group policy. When the doctor inserts a USB flash drive, the container automatically blocks access and pops up a window prompting "Peripheral access is prohibited, please contact the Information Department", and generates an alarm log at the same time. Scenario 6: Pediatric Mobile Care Android Tablet Container Zero Trust adaptation environment configuration: Image android13-nursing-container:v1.8 solidifies the environment baseline through SELinux policy, binds the nurse employee number "NR-202312" to the tablet SN, and verifies in real time whether the network environment is the hospital intranet. Minimum privilege state: The nursing app only has basic permissions such as "camera (scan code to take medicine), location (ward positioning), and network". It is prohibited from accessing sensitive information such as contacts and text messages. Files can only be read and written in the temporary directory / data / nursing / temp. Peripheral prohibition effect: USB debugging, OTG function and Bluetooth peripherals are disabled through the 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 to ensure that nursing data is not leaked through peripherals.

[0042] Next, proceed to step S4.

[0043] Step S4 is a critical security verification step for heterogeneous devices accessing the hospital information system (HIS). This involves sending environmental authentication information to the device through the target container and receiving a response, enabling full-dimensional trusted verification of the device's "physical identity, operating environment, and access scenario." This process, based on the Zero Trust principle of "dynamic verification," establishes a security baseline for subsequent data interactions.

[0044] In specific implementation, step S4 includes four major steps: authentication information generation, secure issuance, device response, and verification feedback. Environmental authentication information is generated collaboratively by the target container and the HIS zero-trust management platform. It is an encrypted data package containing multi-dimensional verification data, including at least: 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 to ensure that the identity subject is traceable. Device fingerprint data: The target container obtains hardware information (MAC address, CPU serial number) and software information (OS version, patch status) through built-in collection tools. After concatenating the MAC+CPU_SN+OS_Version+Patch_Status format, the device fingerprint is generated using the SHA-256 algorithm and compared with the historical fingerprint database for preliminary consistency. Access location information: The SDN controller obtains the switch port (wired devices) or Wi-Fi AP BSSID (wireless devices) to which the device is connected, and associates it with the HIS physical location mapping library to generate a location description (such as "Room 5, 3rd Floor, Outpatient Building"). Network status information: The target container uses network diagnostic tools to collect information such as IP address, subnet mask, gateway latency, and encryption method (such as WPA3-Enterprise) to generate network compliance indicators. Dynamic challenge factor: The HIS zero-trust platform generates a 256-bit random number (such as Rand: 0x5f4dcc3b5aa765d61d8327deb882cf99) as the "dynamic key" for the device response. The validity period is set to 30 seconds to prevent replay attacks. Use the device's preset public key (stored in the device's security chip) to encrypt core sensitive data (device fingerprint, challenge factor) to ensure that only the target device can decrypt it; use the HIS zero-trust platform private key to sign the entire data and generate a signature value Sig (including the signature timestamp). The device can verify the data integrity through the platform's public key. Environmental authentication 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.

[0045] After the target container receives the response, it links with the HIS Zero Trust Platform to complete the final verification and generate a "pass / fail" result. The verification logic is as follows: Basic verification: verify the validity of the response signature, whether the response_time is within the expire_time, and whether the challenge_response matches the original challenge (to prevent response forgery). Detailed verification: Device fingerprints with ≤ 1 difference (e.g., only the patch version is slightly outdated but does not affect security) are considered passed. The access location must completely match the trusted list (unauthorized areas will be directly rejected). The network status must meet all health indicators (latency / packet loss rate / encryption method are all compliant); Result feedback: If the verification is passed, 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 does not match: the current AP is AP-8 in the inpatient building"), synchronized to the HIS security platform and subsequent connection requests are rejected. Step S4 uses multi-dimensional environmental authentication to upgrade the traditional "one-time identity authentication" to dynamic trusted verification of "identity + environment + scenario", effectively preventing risks such as device theft, environmental tampering, and unauthorized area access, and building a front-end security barrier for medical data interaction. It is the core implementation link of the zero-trust architecture in the access of heterogeneous devices in hospitals.

[0046] Next, we proceed to step S5. Step S5 is the final security access link 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.

[0047] 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 the platform verifies the integrity of the notification (via digital signature), it generates a connection authorization token (ConnectionToken) in JWT format, containing the following core fields: device_sn: device unique identifier (e.g. W202306); partition_id: the ID of the target virtual network partition (e.g., VLAN100); container_id: unique ID of the target container (e.g. c8f2e1d0-xxx); permissions: device access rights (e.g., EMR: read, Prescription: write); exp: token validity period (usually 8 hours, adapted to the working hours of medical staff). Secure delivery of authorization tokens: The Zero Trust Platform sends the 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 status as "Ready for Interaction." Simultaneously, the platform sends an "Allow Access" command to the SDN controller of the virtual network partition, including the binding information for the device's MAC address, IP address, and container IP address. After 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: Dynamic permission convergence: The zero-trust platform dynamically adjusts access permissions based on device type and business scenarios. For example: the outpatient doctor workstation has "read and write permissions" to the electronic medical record during working hours (8:00-17:30), and is automatically downgraded to "read-only permissions" during non-working hours; the mobile nursing tablet only allows access to the nursing records of the current patient, and prohibits cross-ward data queries (achieved through the association verification of the patient ID and the ward area). 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 against a baseline model (e.g., "doctor workstations average three EMR queries per minute"). If abnormal behavior is detected (such as batch downloading of medical records 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. After manual confirmation, the connection will be restored or permanently disabled. Transmission layer: All data interactions are end-to-end encrypted. Sensitive fields (such as patient ID numbers) are encrypted on the device side through a security chip. The container side decrypts the encrypted data and then forwards it to the HIS, avoiding plaintext transmission. Storage level: Temporary data cached locally on the device (such as medical record preview images) must be stored encrypted (using the device hardware encryption module, such as Windows BitLocker or Android File-Based Encryption), and the cache is valid for no more than 24 hours and is automatically destroyed upon timeout. If the environment authentication in step S4 fails, technical measures must be taken to completely block the connection and implement a security response. At this point, the target container is marked as "environment authentication failed," and the SDN controller issues dynamic ACL rules to the virtual switch, prohibiting the device IP from communicating with any HIS services (including ICMP, TCP, and UDP protocols). The encrypted session between the container and the device is also closed, freeing up related network resources (such as ports and cache). Step S5 strictly limits the access rights of heterogeneous devices to the "authenticated virtual network partition" and the "minimum necessary permission range" through the technical combination of "dynamic authorization + proxy isolation + real-time monitoring". It not only realizes the normal data interaction of medical services, but also prevents risks such as data leakage and unauthorized access through layered security control. It is the "ultimate security gate" for heterogeneous device access to hospital information systems.

[0048] exist Figure 1 On the basis of this, preferably, after establishing the data interactive connection between the heterogeneous device and the virtual network partition of the hospital information system, the method further includes: Continuously obtain security logs for each virtual network partition; When abnormal behavior of a heterogeneous device is detected, the target container corresponding to the heterogeneous device is paused.

[0049] 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; When both identity authentication and environment authentication are passed, the target container is restored; otherwise, the target container is destroyed.

[0050] Figure 2 Further showing Figure 1 A schematic diagram of a further preferred embodiment of the zero-trust security authentication method for heterogeneous device access in a hospital.

[0051] Figure 2The 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 disposal", which not only meets the core requirement of "continuous verification" of zero trust, but also specifically solves the pain points of dynamic changes in risks of heterogeneous equipment in medical scenarios, high business continuity requirements, and high compliance pressure, and builds a full-cycle security barrier of "pre-prevention-in-process control-post-event tracing" for medical data interaction.

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

[0053] Figure 2 The advantages of the preferred embodiments of the present invention further include: Continuously obtain security logs: Real-time collection of device interaction behaviors (such as access frequency, data transmission volume, and resource access scope) and container operation status (such as abnormal process startup and sensitive file access) within the virtual network partition to form a dynamic behavior baseline and address the security blind spot of "long-term trust after one-time authentication." Abnormal triggering secondary authentication: When abnormal behavior is detected (such as a doctor's workstation downloading medical records in batches during non-working hours, or a mobile device suddenly switching to an unauthorized AP), the container is paused and re-authentication (identity + environment dual dimensions) is required to ensure that the device always meets the trust standard throughout the entire interaction cycle, avoiding the continued spread of risks after static authentication is breached.

[0054] In addition, the medical industry is subject to regulations such as the Cybersecurity Law, the Data Security Law, and the Personal Information Protection Law, and is required to keep traceable logs for the entire data interaction process. Figure 2 The embodiment can meet the above requirements, which is specifically embodied in: Continuous log collection and correlation analysis: Security logs cover all data, including 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-abnormality-handling", meeting the compliance requirements of "data traceability and defined responsibility". Abnormal handling records: Operations such as container suspension, re-authentication results, and container recovery / destruction all record timestamps, operators (the triggering rule ID is recorded when the system automatically executes), and device information. This facilitates post-audit (such as proving the effective operation of security mechanisms during inspections by regulatory authorities) and provides data support for security incident review (such as analyzing abnormal behavior patterns and optimizing protection rules).

[0055] exist Figure 1-Figure 2 Based on the method embodiment, Figure 3-Figure 4Corresponding system (product) embodiments are further given.

[0056] See first Figure 3 , Figure 3 This is a schematic diagram of the hardware unit composition of a zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization in one embodiment of the present invention.

[0057] Figure 3 The system comprises: A 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 obtain the operating system type and application data of the heterogeneous device; a virtual network partition creation module, configured to create virtual network partitions on the data center server based on the operating system type and application data, each partition corresponding to a specific operating system type; A 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 to create a target container for running the application; An environment authentication module, configured to send environment authentication information to the heterogeneous device through the target container to verify the security of the device's operating environment; A data interaction module is used 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 can access the hospital information system resources through the target container; The initial identity authentication is used to verify the identity information of the heterogeneous device, and the identity information includes username / password, biometrics, and digital certificate; The environmental authentication information includes device fingerprint information, access location information, and network status information.

[0058] exist Figure 3 Based on this, see further Figure 4 , Figure 4 In the preferred embodiment shown, the virtual network partition creation module includes: SDN controller: Dynamically creates and manages virtual network partitions based on software-defined networking technology; VLAN allocation unit: allocates independent VLANs (virtual local area networks) to devices of different operating system types; Access Control List (ACL) configuration unit: Sets the initial security policy for each virtual network partition.

[0059] The secure container deployment module includes: Container image library: stores secure container images corresponding to various operating system types, including basic OS environment images and medical application runtime images; Container orchestration engine: Based on Kubernetes or Docker Swarm technology, it deploys and manages target containers within a virtual network partition.

[0060] The data interaction module includes: Secure tunnel establishment unit: establishes an encrypted communication tunnel between heterogeneous devices and the target container through TLS1.3 or IPsec protocol; Traffic monitoring unit: monitors data exchange traffic in real time, detects and intercepts abnormal data packets.

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

[0062] Although not shown in the accompanying drawings, preferably, further product embodiments may include an electronic device comprising a memory and one or more processors. The memory stores one or more application programs, and the one or more application programs are adapted to be executed by the one or more processors in the aforementioned zero-trust security authentication method for heterogeneous device access in a hospital.

[0063] Although not shown in the accompanying drawings, more embodiments also include a computer-readable storage medium that stores a computer program. When the computer program is executed, the steps of the aforementioned zero-trust security authentication method for heterogeneous device access in a hospital are implemented.

[0064] It is understood that the system, product, device, medium embodiments and method implementations correspond to each other and can be referenced by each other. Their principles are similar or the same, so they will not be repeated. The corresponding technical effects, principles, etc. can also be understood by comparing them with each other.

[0065] Compared with the existing technology, the zero-trust security authentication method for hospital heterogeneous device access based on desktop virtualization technology proposed in this invention has the following significant advantages: (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 a one-way manner, providing richer information support for the subsequent authentication process, greatly improving the accuracy and security of authentication.

[0066] (2) By isolating different types of devices in their own virtual network partitions and utilizing the zero-trust adaptation environment provided by secure container images, devices are operated in a state of minimum privilege and the connection of peripheral accessories is prohibited, thus reducing the risk of data leakage in many aspects and greatly improving the overall security of the system. (3) Continuously obtain virtual network partition security logs. 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 flexibly restoring or destroying the container 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.

[0067] (4) Collect device fingerprint information (including device hardware information such as MAC address, CPU serial number and software information such as operating system version and 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, prevent malicious devices from accessing through unsafe networks or false locations, and greatly improve the reliability and effectiveness of environmental authentication; (5) Through the mechanism of “continuous monitoring - dynamic response - closed-loop disposal”, the security protection of HIS is extended from “defense at access time” to “defense during interaction”, which not only meets the core requirement of “continuous verification” of zero trust, but also specifically solves the pain points of dynamic changes in risks of heterogeneous equipment, high business continuity requirements and high compliance pressure in medical scenarios, and builds a full-cycle security barrier of “pre-prevention - in-process control - post-event tracing” for medical data interaction.

[0068] For other technologies, principles, algorithms or models not elaborated in detail in this application, please refer to the existing technology.

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

Claims

1. A zero-trust security authentication method for accessing heterogeneous devices in a hospital, the method being implemented based on desktop virtualization technology, characterized in that: The method comprises the following steps: After the heterogeneous device passes identity authentication, a communication pre-connection is established between the heterogeneous device and the hospital information system, wherein the communication pre-connection enables the hospital information system to unidirectionally obtain the operating system type and application data of the heterogeneous device; Based on the operating system type and application data of the heterogeneous devices, creating virtual network partitions on the data center server of the hospital information system, each virtual network partition corresponding to an operating system type; After each virtual network partition receives the application data of the heterogeneous device, calling the secure container image to create a target container, the secure container image corresponds to the operating system type of the heterogeneous device; Sending environmental authentication information to the heterogeneous device through the target container; When the environment authentication information is passed, a data interaction connection is established between the heterogeneous device and the virtual network partition of the hospital information system, and the data interaction connection enables the heterogeneous device to access the hospital information system through the target container.

2. A zero-trust security authentication method for heterogeneous device access in a hospital according to claim 1, characterized in that: The environmental authentication information includes device fingerprint information, access location information, and network status information; The device fingerprint information is generated by the device hardware information and software information collected by the target container; The device hardware information includes the MAC address and CPU serial number; the software information includes the operating system version and patch status value.

3. A zero-trust security authentication method for heterogeneous device access in a hospital according to claim 1, characterized in that: After establishing a data interactive connection between the heterogeneous device and the virtual network partition of the hospital information system, the method further includes: Continuously obtain security logs for each virtual network partition; When abnormal behavior of a heterogeneous device is detected, the target container corresponding to the heterogeneous device is paused.

4. A zero-trust security authentication method for heterogeneous device access in a hospital according to claim 1, characterized in that: 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.

5. A zero-trust security authentication method for heterogeneous device access in a hospital according to claim 3, characterized in that: 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; When both identity authentication and environment authentication are passed, the target container is restored; otherwise, the target container is destroyed.

6. A zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization, characterized in that: The system comprises: A 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 obtain the operating system type and application data of the heterogeneous device; a virtual network partition creation module, configured to create virtual network partitions on the data center server based on the operating system type and application data, each partition corresponding to a specific operating system type; A 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 to create a target container for running the application; An environment authentication module, configured to send environment authentication information to the heterogeneous device through the target container to verify the security of the device's operating environment; A data interaction module is used 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 can access the hospital information system resources through the target container; The initial identity authentication is used to verify the identity information of the heterogeneous device, and the identity information includes username / password, biometrics, and digital certificate; The environmental authentication information includes device fingerprint information, access location information, and network status information.

7. A zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization as claimed in claim 6, characterized in that: The virtual network partition creation module includes: SDN controller: Dynamically creates and manages virtual network partitions based on software-defined networking technology; VLAN allocation unit: allocates independent VLANs (virtual local area networks) to devices of different operating system types; Access Control List (ACL) configuration unit: Sets the initial security policy for each virtual network partition.

8. A zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization as claimed in claim 6, characterized in that: The secure container deployment module includes: Container image library: stores secure container images corresponding to various operating system types, including basic OS environment images and medical application runtime images; Container orchestration engine: Based on Kubernetes or Docker Swarm technology, it deploys and manages target containers within a virtual network partition.

9. A zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization as claimed in claim 6, characterized in that: The data interaction module includes: Secure tunnel establishment unit: establishes an encrypted communication tunnel between heterogeneous devices and the target container through TLS 1.3 or IPsec protocol; Traffic monitoring unit: monitors data exchange traffic in real time, detects and intercepts abnormal data packets.

10. A zero-trust security authentication system for hospital heterogeneous devices based on desktop virtualization as claimed in claim 6, characterized in that: The virtual network partition supports nested segmentation, creating sub-partitions based on device functions or data sensitivity, and configuring independent access control policies for each sub-partition.

Images