Equipment redirection method and device, electronic equipment and storage medium

By obtaining multi-factor information of USB devices for verification, the problem of precise control in traditional USB device management is solved, enabling precise authorization and secure access of USB devices in a cloud computing environment, and reducing the risks posed by unauthorized devices.

CN121664467APending Publication Date: 2026-03-13CHINA TELECOM CLOUD TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-18
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

In cloud computing and virtual desktop infrastructure, traditional USB device management methods are difficult to achieve precise control and flexible management, and unauthorized USB device access may lead to risks of data leakage and malicious attacks.

Method used

By obtaining the unique identification information of the USB device, including VID, PID, descriptor length and serial number, multi-factor authentication is performed to determine whether the device is an authorized device. If the device is authorized, redirection to the cloud desktop is allowed; otherwise, access is denied to unauthorized devices.

Benefits of technology

It enables precise authorization control over USB devices, reduces the risk of data leakage and malicious attacks, and meets the management needs of high-security environments.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121664467A_ABST
    Figure CN121664467A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides an equipment redirection method and device, electronic equipment and a storage medium. The method comprises the steps that when it is detected that target equipment is accessed, target equipment information, used for indicating the unique identity of the target equipment, of the target equipment is acquired; determining whether the target device is an authorized device according to the target device information; under the condition that the target equipment is determined to be authorized equipment, redirecting the target equipment to a cloud desktop; and refusing to redirect the target device to the cloud desktop under the condition that the target device is determined to be the unauthorized device. According to the embodiment of the invention, the authorized device can be ensured to access the cloud, the unauthorized device is prevented from accessing the cloud, the risk of data leakage and hostile attack is reduced, and the requirement of a high-security environment for peripheral management is met.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a device redirection method, apparatus, electronic device, and storage medium. Background Technology

[0002] In modern enterprise environments where cloud computing and Virtual Desktop Infrastructure (VDI) are widely used, cloud PCs (also known as virtual desktops or desktop-as-a-service) provide users with flexible computing and data processing capabilities. Users can access cloud desktops and process business data through various terminal devices (such as desktops, laptops, tablets, and mobile phones). However, with the expansion of cloud desktop applications, the security and management issues of USB (Universal Serial Bus) peripherals connected to virtual desktops have become increasingly prominent, especially in enterprises or data-sensitive industries. Unauthorized access to USB devices may lead to security risks such as data leaks and the spread of malware.

[0003] Traditional USB device management methods often have the following limitations: Simple Device Identification: Traditional solutions primarily rely on the device's VID (Vendor ID) and PID (Product ID) for identification and authorization. This method can only identify the device type or manufacturer brand, making it difficult to manage specific devices. For example, multiple USB storage devices of the same model may share the same VID and PID. If one device is allowed to connect, other devices of the same type can also connect, increasing the risk of unauthorized devices accessing the network.

[0004] Lack of fine-grained control: Existing solutions often employ uniform device access policies (such as disabling or allowing all USB storage devices), making it difficult to achieve precise device-level control. For example, some organizations may want to allow specific USB storage devices to access cloud computers but not other devices of the same type, a requirement that is difficult to meet under the current technological framework.

[0005] Inflexible device management: In complex application scenarios (such as finance and healthcare industries), management needs change frequently. Traditional USB device control methods, such as whitelist mechanisms, are rigid and struggle to adapt to rapidly changing business requirements, resulting in low control efficiency and increased system management burden.

[0006] Security risks of peripheral devices in cloud PCs: In a cloud PC environment, the device redirection function allows local USB devices to connect to the cloud, but unauthorized devices may pose risks such as data leaks and malicious attacks. To improve security, cloud PCs need to implement dynamic, fine-grained management of peripheral access permissions to prevent unauthorized USB devices from connecting to the cloud. Summary of the Invention

[0007] The technical problem to be solved by the embodiments of this application is to provide a device redirection method, apparatus, electronic device and storage medium to effectively ensure that authorized devices access the cloud and prevent unauthorized devices from accessing the cloud, reduce the risk of data leakage and malicious attacks, and meet the needs of peripheral device management in a high-security environment.

[0008] In a first aspect, embodiments of this application provide a device redirection method applied to a cloud server, the method comprising: Upon detecting that a target device has accessed the network, target device information is obtained that indicates the unique identity of the target device. Based on the target device information, determine whether the target device is an authorized device; If the target device is determined to be an authorized device, the target device will be redirected to a cloud desktop; If the target device is determined to be an unauthorized device, the redirection of the target device to the cloud desktop will be refused.

[0009] Secondly, embodiments of this application provide a device redirection apparatus applied to a cloud server, the apparatus comprising: The information acquisition module is used to acquire target device information that indicates the unique identity of the target device when the target device is detected to be connected. The device determination module is used to determine whether the target device is an authorized device based on the target device information; The redirection module is used to redirect the target device to a cloud desktop when it is determined that the target device is an authorized device; The rejection module is used to refuse to redirect the target device to the cloud desktop if it is determined that the target device is an unauthorized device.

[0010] Thirdly, embodiments of this application provide an electronic device, including: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the device redirection method described in any of the preceding claims.

[0011] Fourthly, embodiments of this application provide a computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform any of the device redirection methods described above.

[0012] Compared with the prior art, the embodiments of this application have the following advantages: In this embodiment, when a target device is detected to be accessing the cloud, target device information, which serves as a unique identifier for the target device, is obtained. Based on this information, it is determined whether the target device is an authorized device. If the target device is determined to be authorized, it is redirected to a cloud desktop. If the target device is determined to be unauthorized, redirection to the cloud desktop is refused. This embodiment, by performing authorization verification on the target device based on its information upon access, ensures that authorized devices can access the cloud and prevents unauthorized devices from accessing it, thereby reducing the risk of data leakage and malicious attacks and meeting the requirements of high-security environments for peripheral device management.

[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0014] Figure 1 A flowchart illustrating the steps of a device redirection method provided in this application embodiment; Figure 2 A structural diagram of a system module provided in an embodiment of this application; Figure 3 A schematic diagram of a system judgment process provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a device redirection device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0017] Reference Figure 1This document illustrates a flowchart of a device redirection method provided in an embodiment of this application. This device redirection method can be applied to cloud servers. Figure 1 As shown, the device redirection method may include steps 101, 102, 103, and 104.

[0018] Step 101: When the target device is detected to be connected, obtain the target device information used to indicate the unique identity of the target device.

[0019] In this embodiment, the cloud server refers to the core computing device deployed in the cloud data center that provides virtual desktop (cloud computer) services. It is responsible for the creation, management, peripheral access control and redirection scheduling of virtual desktops and is the execution subject of this embodiment.

[0020] The target device refers to a USB (Universal Serial Bus) type external device that the user attempts to connect to the cloud computer (indirectly accessed through a local terminal), including but not limited to: USB storage devices, USB keys, USB printers, etc.

[0021] Target device information refers to the set of core features used to uniquely identify the target device, specifically including: VID (Vendor ID), PID (Product ID), descriptor length, and serial number.

[0022] The descriptor length refers to the byte length of the device descriptor in a USB device. It is a standard field specified by the USB protocol (1 byte, with a value range of 0x08~0xFF) used to identify the total number of bytes in the device descriptor itself, ensuring that the host (or cloud server through a terminal agent) can correctly parse the basic information of the device.

[0023] A unique serial number is a unique identifier string preset and burned into the device firmware (or dedicated storage chip) by the USB device manufacturer. It is used to distinguish different physical devices (with the same model and the same VID / PID) and is a core field for achieving fine-grained control at the device level. USB devices of the same model manufactured by the same manufacturer have absolutely unique serial numbers (assigned by the manufacturer through the production line traceability system to avoid duplication).

[0024] When a target device is detected to be connected, target device information that indicates the unique identity of the target device can be obtained.

[0025] In one specific implementation of this application, when a target device is detected to be accessing the network, multi-factor feature information of the target device can be obtained. This multi-factor feature information may include: target manufacturer identifier, target product identifier, target descriptor length, and target unique serial number. This multi-factor feature information is then used as target device information.

[0026] In practical applications, cloud servers complete device access detection and feature collection through terminal agent programs or USB redirection clients deployed on user local terminals (such as desktops and laptops). The specific process may include: 1. Access Detection Trigger: When the user inserts the target USB device into the USB port of the local terminal, the USB controller of the local terminal recognizes the device access and sends a device access notification to the cloud server through a preset communication channel (such as TCP (Transmission Control Protocol) / IP (Internet Protocol), or the remote connection protocol channel between the terminal and the cloud server), informing the cloud server that there is a new device waiting to be connected to the cloud desktop.

[0027] 2. Device Information Collection Command Issuance: After receiving the notification, the cloud server issues a device feature collection command to the agent program on the local terminal, explicitly requiring the collection of four core information types of the target device: VID, PID, descriptor length, and serial number.

[0028] 3. Feature Data Collection and Upload: The local terminal agent program calls the operating system's USB device driver interface (such as Windows' Win32 API or Linux's libusb library) to read the target device's configuration descriptor, device descriptor, and serial number fields. It parses the VID (2-byte field), PID (2-byte field), and descriptor length (1-byte field) from the device descriptor. It reads the serial number (a unique string, preset by the device manufacturer to ensure uniqueness for devices of the same model) from the device's string descriptor or dedicated storage area. The agent program then packages and encrypts the collected four types of feature data before uploading it to the cloud server.

[0029] 4. Data Verification: After receiving the data, the cloud server verifies the data integrity (e.g., through CRC (Cyclic Redundancy Check)) and the format validity (e.g., VID / PID is in hexadecimal format and the serial number is not empty). If the data is abnormal, a collection failure message is returned, and the process is terminated.

[0030] This application proposes a more granular management method for USB device access control in cloud computing environments. Compared to traditional broad-category device management modes (such as controlling only USB storage devices), it supports authorized control of individual specific devices. Through a multi-factor authentication mechanism, device control is refined to the specific device level, thereby achieving fine-grained control down to the device level and improving system security.

[0031] After obtaining the target device information, proceed to step 102.

[0032] Step 102: Determine whether the target device is an authorized device based on the target device information.

[0033] After obtaining the target device information, it can be determined whether the target device is an authorized device based on the target device information.

[0034] In one specific implementation of this application, the manufacturer identifier, product identifier, descriptor length, and unique serial number of devices pre-stored in the whitelist can be obtained. The target manufacturer identifier, target product identifier, target descriptor length, and target unique serial number are then compared one by one with the manufacturer identifier, product identifier, descriptor length, and unique serial number pre-stored in the whitelist to obtain comparison results. Based on the comparison results, it is determined whether the target device is an authorized device.

[0035] If the target device is determined to be an authorized device, proceed to step 103. If the target device is determined to be an unauthorized device, proceed to step 104.

[0036] Step 103: If the target device is determined to be an authorized device, redirect the target device to the cloud desktop.

[0037] Cloud desktop refers to a virtual computing environment (i.e., cloud PC / desktop as a service) generated by cloud server virtualization, which users can remotely access and process business data through local terminals (desktops, laptops, etc.).

[0038] Authorized devices refer to USB devices whose target device information (VID, PID, descriptor length, serial number) all match the pre-stored rules in the whitelist library, have legitimate permissions to access the cloud computer, and can interact with the cloud desktop through the redirection function.

[0039] Target device redirection refers to the technology of mapping the functionality of a user's locally connected USB device (target device) to the cloud desktop through a specific protocol (such as USB redirection protocol, RDP (Remote Desktop Protocol) / ICA (Independent Computing Architecture) protocol), so that the cloud desktop can recognize and use the device.

[0040] The process of determining that a target device is an authorized device may include: when the comparison results indicate that the target manufacturer identifier, target product identifier, target descriptor length, and target unique serial number match the manufacturer identifier, product identifier, descriptor length, and unique serial number respectively, the target device is determined to be an authorized device.

[0041] Once the target device is determined to be an authorized device, it can be redirected to a cloud desktop. The specific process may include: 1. Redirect channel initialization: The cloud server sends a redirect permission command to the local terminal agent program and notifies the cloud desktop (the virtual desktop process of the corresponding user) to prepare to receive the USB device redirection request.

[0042] 2. Protocol Negotiation and Connection Establishment: The local terminal agent and the cloud desktop negotiate using standardized USB redirection protocols (such as USB over IP, Microsoft RDP USB Redirection, and Citrix USB Redirection) to determine the data transmission encoding format and bandwidth control strategy. An encrypted logical data channel is established to ensure the security of device data transmission between the local terminal and the cloud desktop.

[0043] 3. Device Enumeration and Driver Loading: The cloud desktop receives the target device's characteristic information through a redirection channel, simulates the local USB device access process, and triggers the enumeration operation of the virtual USB controller. The cloud desktop loads the corresponding device type driver (e.g., loads the USB flash drive driver for USB storage devices, and the dongle driver for USB keys), completing device initialization.

[0044] 4. Redirection Status Feedback: After the cloud desktop is initialized, a redirection success notification is returned to the cloud server. The cloud server simultaneously sends a prompt message to the user's local terminal that the device has been connected to the cloud desktop. The user can use the device normally in the cloud desktop (such as reading USB flash drive data and signing with USB key).

[0045] In one specific implementation of this application, for certain scenarios, when the target device is an authorized device, the target device can be re-verified, and device redirection can be performed only after successful verification. This implementation process can be described in detail below in conjunction with the specific implementation method.

[0046] In one specific implementation of this application, step 103 may include: Sub-step S1: If the target device is determined to be an authorized device, a verification request corresponding to the target device is generated based on the target device information.

[0047] In this embodiment, the verification request refers to the request data generated by the cloud server after confirming that the target device is an authorized device, based on the unique characteristics of the target device (such as the serial number), for secondary verification of the device / user's legitimacy. It includes information such as the verification method identifier, request validity period, and device association identifier. This is the trigger for secondary verification, and the verification method can be dynamically configured according to the enterprise security policy.

[0048] If the target device is determined to be an authorized device, a verification request corresponding to the target device can be generated based on the target device information. Specifically, based on the unique characteristics of the authorized device and combined with the enterprise security policy, a targeted secondary verification request can be dynamically generated. The specific process may include: 1. Verification method matching: The cloud server determines the method of this secondary verification based on the target device type (such as USB key, ordinary USB flash drive) or the preset enterprise security policy (such as mandatory hardware binding verification in the financial industry, and dynamic passwords in ordinary office scenarios). The verification method is as follows: USB key binding hardware code verification, dynamic password verification associated with user account, temporary authorization code verification by administrator, etc.

[0049] 2. Verification Request Generation: Using the target device's unique serial number as the core identifier, generate verification request data containing: device serial number, verification method, request ID, validity period (e.g., 5 minutes), and encrypted signature. For dynamic password verification: The cloud server, in conjunction with the bound dynamic password system, pre-generates the corresponding verification baseline value (or synchronizes the password generation seed). For hardware binding code verification: The cloud server calls the local terminal agent program to read the hardware binding code (such as a manufacturer-preset unique verification code) pre-stored in the target device firmware and uses it as the implicit verification baseline for the verification request.

[0050] 3. Verification Request Issuance: The cloud server pushes the verification request to the agent program on the user's local terminal through an encrypted communication channel (consistent with the device feature collection channel, such as a TCP / IP channel encrypted with TLS (Transport Layer Security)). The agent program then informs the user via pop-up windows, SMS, APP notifications, etc. (or directly reads the device hardware code without user operation).

[0051] Sub-step S2: Upon receiving the information to be verified in response to the verification request, verify the information to be verified to obtain the verification result.

[0052] Verification information refers to data returned by the user or target device in response to the verification request to prove its legitimacy, including but not limited to dynamic passwords (TOTP / HOTP), device hardware binding codes, user biometrics (fingerprint / face), administrator authorization codes, etc.

[0053] The verification result refers to the conclusion reached by the cloud server after verifying the received information to be verified. It includes only two types of results: verification success and verification failure (with reasons for failure, such as information expiration or data mismatch).

[0054] After generating the verification request, it can be sent to the target device. Simultaneously, it can receive verification data from the user / target device, ensuring legitimacy through multi-dimensional validation. The specific process includes: 1. Information to be verified: For user interaction-based verification (such as dynamic passwords or administrator authorization codes): the user enters the information to be verified through a pop-up window on their local terminal, and the agent program encrypts it and uploads it to the cloud server.

[0055] If it is automatic device verification (such as hardware binding code): the local terminal agent program directly reads the hardware binding code in the target device firmware, without user operation, and automatically uploads it after encryption.

[0056] For biometric verification: The local terminal collects the user's fingerprint / face information (such as a laptop camera or fingerprint module), and uploads it to the cloud server after de-identification processing.

[0057] 2. Information preprocessing and verification: After receiving the information to be verified, the cloud server first verifies the data integrity (CRC check), the signature validity (verifies whether it was uploaded by a legitimate terminal), and the request validity period (determines whether it is within the preset time).

[0058] If there are incomplete information, invalid signatures, or expired information, the verification will be deemed a failure, and the reason for the failure will be returned.

[0059] 3. Execution of core verification logic: Dynamic password verification: The information to be verified is compared with the baseline value pre-stored on the cloud server (or the baseline value calculated in real time through the seed). If they are completely consistent, the verification is successful.

[0060] Hardware binding code verification: The information to be verified (device hardware code) is compared with the hardware code associated with the device serial number in the cloud server whitelist database. If they match, the verification is successful.

[0061] Biometric verification: The de-identified biometric data is compared with the biometric template bound to the user account. If the similarity reaches a threshold (such as 95%), the verification is successful.

[0062] 4. Generate verification results: Based on the comparison results of the core verification logic, generate a clear conclusion of verification success or failure, and synchronously record the verification log (including device information, verification method, verification time, and results).

[0063] Sub-step S3: When the verification result is successful, redirect the target device to the cloud desktop.

[0064] If the verification result is successful, the target device can be redirected to the cloud desktop.

[0065] This application's embodiments effectively prevent security risks caused by theft or misuse of authorized devices by adding secondary verification on top of whitelisted device authorization (such as employees taking away authorized USB drives after leaving the company). Fine-grained security control: It supports configuring differentiated verification methods according to device type and industry scenario, adapting to diverse needs from general office work to high-security levels in finance / medical fields. Balancing security and user experience: It supports automatic device verification (such as hardware binding codes), reducing additional operational costs for users and balancing security with ease of use.

[0066] Step 104: If it is determined that the target device is an unauthorized device, refuse to redirect the target device to the cloud desktop.

[0067] An unauthorized device is a USB device whose characteristics (VID, PID, descriptor length, serial number) do not match the whitelist rules, posing a security risk and thus being prohibited from accessing the cloud desktop.

[0068] The process of determining that a target device is an unauthorized device may include: based on the comparison results, determining whether there are at least one inconsistency among the target vendor identifier, target product identifier, target descriptor length, and target unique serial number. If at least one inconsistency exists, the target device is determined to be an unauthorized device.

[0069] When a target device is determined to be unauthorized, redirection to the cloud desktop can be refused. This means blocking the connection between the target device and the cloud desktop and implementing security control measures. Specifically, the cloud server can send a redirection denial command to the local terminal agent program, prohibiting the agent program from establishing any redirection channel with the cloud desktop. Simultaneously, the cloud desktop is notified to ignore the device's access request and not perform driver loading or enumeration operations.

[0070] When the target device is determined to be an unauthorized device, an alarm message can be generated, and the corresponding access log of the target device can be recorded. This implementation process can be described in detail below.

[0071] In another specific implementation of this application, step 104 above may include: Sub-step M1: If the target device is determined to be an unauthorized device, refuse to redirect the target to the cloud desktop.

[0072] In this embodiment, when it is determined that the target device is an unauthorized device, the redirection of the target device to the cloud desktop can be refused.

[0073] Sub-step M2: Generate alarm information corresponding to the target device and record access log information corresponding to the target device.

[0074] The log content for accessing the system can include: alarm ID, complete characteristics of the target device (not anonymized, for internal auditing), detailed information about the local terminal (IP, MAC address, login location), user account and department, access time, reason for denial, blocking method, log generation time, etc. Logs are stored in an encrypted format (such as AES encryption) in a secure log library on the cloud server, supporting retrieval by device characteristics, time range, user account, etc. Log retention time meets industry compliance requirements (e.g., at least 6 months) and is tamper-proof (integrity is ensured through blockchain or log signature mechanisms).

[0075] It can generate alarm information corresponding to the target device and record the corresponding access log information. Specifically, the cloud server can extract the core characteristics of the target device (VID, PID, descriptor length, serial number, where sensitive information such as the serial number is anonymized, such as retaining only the last 4 digits), access time (accurate to the second), local terminal information (IP address, device name, operating system version), user account (account used to log in to the cloud computer), and rejection reason (such as "serial number does not match the whitelist" or "VID / PID combination is not in the authorized list"). It then generates structured alarm information according to a preset template, including the alarm level (default medium risk, configurable by device type, such as setting USB storage devices to high risk) and alarm ID (unique identifier for easy log association). The alarm information can then be pushed through preset channels such as the enterprise security management platform, administrator email, SMS, and office collaboration tools. It supports configuring push priority according to alarm level; high-risk alarms can trigger real-time pop-up reminders from administrators to ensure timely handling of emergency risks.

[0076] This application embodiment achieves closed-loop control by instantly blocking unauthorized device redirection, generating accurate alarms, and retaining complete access logs. It not only prevents data leakage, malicious attacks, and other security risks caused by unauthorized USB devices accessing the cloud desktop from the source, but also provides administrators with clear evidence for tracing abnormal access, making it easy to quickly locate the source of risk (such as unauthorized devices or abnormal terminals) and deal with it. At the same time, it meets the security compliance requirements of sensitive industries such as finance and healthcare, and reduces the risk investigation and control burden of administrators.

[0077] The device redirection method provided in this application obtains target device information, which is used to uniquely identify the target device, when a target device is detected to be accessing the cloud. Based on the target device information, it determines whether the target device is an authorized device. If the target device is determined to be an authorized device, it is redirected to a cloud desktop. If the target device is determined to be an unauthorized device, redirection to the cloud desktop is refused. This application embodiment, by performing authorization verification on the target device based on its information upon access, only allows the device to access the cloud if it is authorized, thereby ensuring authorized device access to the cloud and preventing unauthorized devices from accessing the cloud. This reduces the risk of data leakage and malicious attacks, meeting the needs of high-security environments for peripheral device management.

[0078] Next, combined Figure 2 and Figure 3 A detailed description of the fine-grained cloud computer peripheral management process based on multiple factors is provided.

[0079] This application can be used in cloud computing and virtual desktop infrastructure (VDI) environments, especially in data-sensitive industries (such as finance, healthcare, and government), for fine-grained management of USB peripherals. The main application scenario includes USB device access control in cloud computing environments, aiming to achieve precise authorization of specific USB devices through a multi-factor authentication mechanism.

[0080] Figure 2 A structural diagram of a system module provided in an embodiment of this application is shown. For example... Figure 2 As shown, the system modules may include: The whitelist configuration system is a management system for administrators to configure whitelist rules for authorized devices (including features such as device VID, PID, descriptor length, and serial number). It distributes the configured whitelist policies to subsequent processing units and serves as the management entry point for the pre-configured whitelist library in the corresponding technical solution.

[0081] Device 1 / 2 / 3: These are the target devices (such as USB storage devices, USB keys, etc.) that the user attempts to connect to the cloud computer, corresponding to the target devices in the technical solution.

[0082] Device Information Acquisition Module: Corresponds to the device feature acquisition module in the technical solution, which is responsible for automatically collecting target device information such as VID, PID, descriptor length, and serial number of the accessed devices.

[0083] Whitelist comparison module: Receives device information collected by the device information acquisition module, compares it with the whitelist policy issued by the whitelist configuration system, and determines whether the device is an authorized device.

[0084] Cloud computer virtual machine: This is the cloud desktop carrier that users actually use (i.e., the cloud desktop in the technical solution), which establishes a connection with the authorized device through a redirection channel.

[0085] Inter-device communication relationships: User terminal devices communicate with cloud servers through a virtual desktop protocol to enable remote connection between user terminals and cloud desktops.

[0086] The USB device management system monitors the USB device access status on the cloud server in real time and performs feature collection, comparison, and control.

[0087] Additionally, the USB device management system may include: a control policy management module that supports dynamic configuration of whitelist rules, allowing administrators to update the rules.

[0088] Log and alarm module: Records unauthorized device access attempts and provides alarm prompts to enhance system security and traceability.

[0089] Figure 3A schematic diagram of a system judgment process provided in an embodiment of this application is shown. Figure 3 As shown, the process may include: 1. Start: This is the starting point for triggering the entire management logic, which initiates the process of connecting and redirecting USB devices to the cloud computer.

[0090] 2. Log in to the cloud computer: Users enter their account and password credentials through their local terminal (such as a desktop or laptop) to complete the access authorization for the cloud computer (virtual desktop). This is a prerequisite for device access - only after successfully logging into the cloud computer will subsequent device access operations enter the management process.

[0091] 3. Device Access: The user inserts the target USB device (such as a USB storage device, USB key, etc.) into the USB port of the local terminal, triggering the device access detection of the local terminal, which corresponds to the device detection step in the technical solution.

[0092] 4. Obtain Device Information: The device information acquisition module automatically collects the core feature information of the access device (including VID, PID, descriptor length, and serial number), corresponding to the device feature collection steps in the technical solution, to provide data basis for subsequent whitelist verification.

[0093] 5. Whitelist Verification: This is the core judgment step. The whitelist comparison module will compare the collected device information with the whitelist rules (a combination of features of authorized devices) pre-issued by the whitelist configuration system in all dimensions (VID, PID, descriptor length, and serial number must all match) to determine whether the device is an authorized device.

[0094] 6. Failure → Redirection Not Allowed, Log Recording: If the whitelist verification fails (any device characteristic does not match), the control logic for unauthorized devices will be executed: the device will be refused redirection to the cloud desktop, and the access log of the device will be recorded (including device information, access time, terminal information, etc.), corresponding to the unauthorized device redirection control + log recording link in the technical solution.

[0095] 7. Redirect to cloud desktop: If the whitelist verification is successful (the device is an authorized device), a redirection channel is established to map the device's functions to the cloud computer virtual machine. Users can then use the device normally on the cloud desktop, which corresponds to the redirection control step for authorized devices in the technical solution.

[0096] 8. End: The entire process of device access and redirection is now complete and the process terminates.

[0097] The above process is described below using financial and medical scenarios.

[0098] Scenario: In a financial institution's cloud computing environment, the administrator wants to allow specific USB storage devices to access the cloud desktop and restrict other devices.

[0099] Technical implementation process: (1) Device detection and feature acquisition: When a user attempts to connect a USB device to a cloud computer, the device feature acquisition module automatically collects the device's VID, PID, descriptor length and serial number information.

[0100] (2) Whitelist comparison: The collected device features are transmitted to the whitelist comparison module and compared with the configured whitelist rules.

[0101] If the VID, PID, descriptor length, and serial number all match the whitelist rules, then it is determined to be an authorized device.

[0102] If any feature information does not match, the device is determined to be unauthorized.

[0103] (3) Device redirection control: If the device is determined to be authorized, it is allowed to redirect to the cloud desktop; otherwise, redirection is rejected.

[0104] (4) Log recording and alarm: If the device fails the verification, the system generates alarm information and records the log for subsequent review.

[0105] This embodiment achieves fine-grained management of USB devices through multi-factor authentication, allowing only devices that comply with security policies to access the network, thereby enhancing the security of peripheral devices in the cloud computing environment.

[0106] II. Scenario: Using cloud computers in medical institutions, allowing specific medical devices (such as imaging or monitoring devices with USB interfaces) to connect, while restricting the access of other non-medical devices.

[0107] Technical implementation process: (1) Device detection and feature acquisition: When a medical device is connected via a USB interface, the system acquires its VID, PID, descriptor length and serial number, and generates a unique device feature.

[0108] (3) Multi-factor validation of equipment: The system automatically compares device feature information with whitelist rules. If all information matches the whitelist rules, the device is allowed to access.

[0109] If the device partially matches the rule, further verification is performed according to the organization's security policy (such as sending additional verification requests).

[0110] (3) Dynamic whitelist update: If an organization needs to add new equipment, the administrator can add the new equipment to the whitelist through the control policy management module without interrupting the existing services.

[0111] (4) Abnormal device alarms and logs: The system generates alarms and logs all access attempts that fail to pass verification for review by the system administrator.

[0112] This embodiment allows users to dynamically update the whitelist according to actual conditions, making the system more flexible and adaptable to device update needs, thus ensuring the efficiency and security of peripheral device management in data-sensitive environments.

[0113] This application employs a multi-factor authentication mechanism, collecting and comparing various characteristic information of USB devices, including VID (Vendor ID), PID (Product ID), device descriptor length, and serial number, to achieve unique verification of a specific device. All characteristic information must be matched against a whitelist rule to ensure that only devices that fully match the criteria are authorized for access. Traditional technologies typically rely solely on VID and PID for device identification, failing to distinguish between specific devices of the same model. The multi-factor mechanism provides higher-precision device verification, effectively reducing the risk of unauthorized device access and enhancing the security of the cloud computing environment.

[0114] A whitelist strategy is used to manage access permissions for USB devices, allowing users to configure multi-factor rules for each device according to their actual needs, resulting in precise device access control. The control strategy is flexible and enables granular management at the single-device level. Traditional whitelists typically only apply to broad categories of devices (such as USB storage devices from the same brand), lacking fine-grained control. The multi-factor whitelist management mechanism allows for precise authorization configuration for each device, effectively improving the flexibility of device access management and meeting the refined management needs of data-sensitive industries.

[0115] The whitelist management module supports dynamic updates, allowing the addition or removal of device authorization information without interrupting system services. This enables the system to adapt to device changes promptly and meet real-time management needs. Compared to the static configuration of whitelists in traditional technologies, the dynamic update function supports real-time device management and is suitable for scenarios requiring efficient updates to device permissions (such as finance and healthcare). This feature reduces management complexity and improves system maintenance efficiency.

[0116] Reference Figure 4 The diagram illustrates a structural schematic of a device redirection apparatus provided in an embodiment of this application, which can be applied to cloud servers. Figure 4 As shown, the device redirection device 400 may include the following modules: The information acquisition module 410 is used to acquire target device information that indicates the unique identity of the target device when the target device is detected to be connected. The device determination module 420 is used to determine whether the target device is an authorized device based on the target device information; The redirection module 430 is used to redirect the target device to a cloud desktop when it is determined that the target device is an authorized device; The rejection module 440 is used to refuse to redirect the target device to the cloud desktop if it is determined that the target device is an unauthorized device.

[0117] Optionally, the information acquisition module includes: The feature information acquisition unit is used to acquire multi-factor feature information of the target device, wherein the multi-factor feature information includes: target manufacturer identifier, target product identifier, target descriptor length, and target unique serial number; An information acquisition unit is used to use the multi-factor feature information as the target device information.

[0118] Optionally, the device determination module includes: The device information acquisition unit is used to acquire the manufacturer identifier, product identifier, descriptor length, and unique serial number of the devices pre-stored in the whitelist database; The comparison result acquisition unit is used to compare the target manufacturer identifier, the target product identifier, the target descriptor length, and the target unique serial number with the manufacturer identifier, product identifier, descriptor length, and unique serial number one by one to obtain the comparison result; The target device determination unit is used to determine whether the target device is an authorized device based on the comparison result.

[0119] Optionally, the redirection module includes: The authorized device determination unit is configured to determine that the target device is an authorized device when the comparison result indicates that the target manufacturer identifier, the target product identifier, the target descriptor length, and the target unique serial number match the manufacturer identifier, the product identifier, the descriptor length, and the unique serial number one by one, respectively.

[0120] Optionally, the redirection module includes: The verification request generation unit is used to generate a verification request corresponding to the target device based on the target device information when the target device is determined to be an authorized device. The verification result acquisition unit is used to verify the information to be verified when it receives the information to be verified in response to the verification request, and obtain the verification result. The redirection unit is used to redirect the target device to the cloud desktop when the verification result is a successful verification result.

[0121] Optionally, the rejection module includes: The determining unit is configured to determine, based on the comparison results, whether there is at least one inconsistency among the target manufacturer identifier and the manufacturer identifier, the target product identifier and the product identifier, the target descriptor length and the descriptor length, and the target unique serial number and the unique serial number; An unauthorized determination unit is used to determine that the target device is an unauthorized device when there is at least one set of inconsistencies.

[0122] Optionally, the rejection module includes: The rejection unit is used to refuse to redirect the target to the cloud desktop if it is determined that the target device is an unauthorized device; An alarm generation unit is used to generate alarm information corresponding to the target device and record access log information corresponding to the target device.

[0123] The device redirection device provided in this application embodiment obtains target device information, which is used to indicate the unique identity of the target device, when a target device is detected to be accessing the cloud. Based on the target device information, it determines whether the target device is an authorized device. If the target device is determined to be an authorized device, it is redirected to a cloud desktop. If the target device is determined to be an unauthorized device, redirection to the cloud desktop is refused. This application embodiment, by performing authorization verification on the target device based on its information upon access, only allows the device to access the cloud when it is an authorized device. This ensures authorized devices can access the cloud and prevents unauthorized devices from accessing the cloud, reducing the risk of data leakage and malicious attacks, and meeting the needs of peripheral device management in a high-security environment.

[0124] This application also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the above-described device redirection method.

[0125] Figure 5 A schematic diagram of the structure of an electronic device 500 according to an embodiment of the present invention is shown. Figure 5As shown, the electronic device 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 502 or loaded from storage unit 508 into random access memory (RAM) 503. The RAM 503 can also store various programs and data required for the operation of the electronic device 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0126] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, microphone, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0127] The various processes and handling described above can be executed by processing unit 501. For example, the methods of any of the above embodiments can be implemented as computer software programs tangibly contained in a computer-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by CPU 501, one or more actions of the methods described above can be performed.

[0128] Additionally, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned device redirection method.

[0129] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0130] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0131] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminals (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0132] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0133] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal, causing a series of operational steps to be executed on the computer or other programmable terminal to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0134] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0135] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes said element.

[0136] The foregoing has provided a detailed description of a device redirection method, a device redirection apparatus, an electronic device, and a computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and its core ideas. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A device redirection method, characterized in that, Applied to cloud servers, the method includes: Upon detecting that a target device has accessed the network, target device information is obtained that indicates the unique identity of the target device. Based on the target device information, determine whether the target device is an authorized device; If the target device is determined to be an authorized device, the target device will be redirected to a cloud desktop; If the target device is determined to be an unauthorized device, the redirection of the target device to the cloud desktop will be refused.

2. The method according to claim 1, characterized in that, The step of obtaining target device information used to indicate the unique identity of the target device includes: Obtain multi-factor feature information of the target device, wherein the multi-factor feature information includes: target manufacturer identifier, target product identifier, target descriptor length, and target unique serial number; The multi-factor feature information is used as the target device information.

3. The method according to claim 2, characterized in that, The step of determining whether the target device is an authorized device based on the target device information includes: Retrieve the manufacturer identifier, product identifier, descriptor length, and unique serial number of the devices pre-stored in the whitelist database; The target manufacturer identifier, the target product identifier, the target descriptor length, and the target unique serial number are compared one by one with the manufacturer identifier, the product identifier, the descriptor length, and the unique serial number to obtain the comparison results; Based on the comparison results, it is determined whether the target device is an authorized device.

4. The method according to claim 3, characterized in that, The step of determining that the target device is an authorized device includes: When the comparison result indicates that the target manufacturer identifier, the target product identifier, the target descriptor length, and the target unique serial number match the manufacturer identifier, the product identifier, the descriptor length, and the unique serial number respectively, the target device is determined to be an authorized device.

5. The method according to claim 1, characterized in that, The step of redirecting the target device to a cloud desktop when it is determined that the target device is an authorized device includes: If the target device is determined to be an authorized device, a verification request corresponding to the target device is generated based on the target device information; Upon receiving the information to be verified in response to the verification request, the information to be verified is verified to obtain a verification result; When the verification result is successful, the target device is redirected to the cloud desktop.

6. The method according to claim 3, characterized in that, The determination that the target device is an unauthorized device includes: Based on the comparison results, determine whether there is at least one inconsistency among the target manufacturer identifier and the manufacturer identifier, the target product identifier and the product identifier, the target descriptor length and the descriptor length, and the target unique serial number and the unique serial number; If at least one set of inconsistencies exists, the target device is determined to be an unauthorized device.

7. The method according to claim 1, characterized in that, The step of refusing to redirect the target device to the cloud desktop when it is determined that the target device is an unauthorized device includes: If the target device is determined to be an unauthorized device, the redirection of the target to the cloud desktop will be refused. The alarm information corresponding to the target device is generated, and the access log information corresponding to the target device is recorded.

8. A device redirection apparatus, characterized in that, The device, applied to a cloud server, includes: The information acquisition module is used to acquire target device information that indicates the unique identity of the target device when the target device is detected to be connected. The device determination module is used to determine whether the target device is an authorized device based on the target device information; The redirection module is used to redirect the target device to a cloud desktop when it is determined that the target device is an authorized device; The rejection module is used to refuse to redirect the target device to the cloud desktop if it is determined that the target device is an unauthorized device.

9. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the device redirection method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the device redirection method according to any one of claims 1 to 7.