Device access methods, communication systems, electronic devices, storage media and software products

Abstract

This application provides a device access method, communication system, electronic device, storage medium, and program product, relating to the field of communication technology. This solution enables communication between intranet security devices and the cloud through a relay device, and can achieve cloud access for intranet security devices based on the MQTT protocol. The communication data between them follows the relevant specifications of the MQTT protocol to ensure the security and stability of data communication. Furthermore, when the intranet security device accesses the cloud, the relay device can send the access verification code and device information of the intranet security device to the cloud for verification. Only after successful verification will a communication channel be established between the cloud and the intranet security device. This allows for security verification of the intranet security device, ensuring the security of subsequent communication.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a device access method, a communication system, an electronic device, a storage medium, and a program product. Background Technology

[0002] As businesses increasingly demand digital transformation, cloud services, with their advantages of flexibility, scalability, and cost-effectiveness, meet their needs for efficient and convenient services.

[0003] However, due to the unique nature of the security industry, internal network isolation is common, preventing business areas from directly communicating with external cloud servers. Pure cloud solutions are limited by network conditions, making relay methods crucial for solving the problem of internal network access to the cloud. However, this approach allows internal network security devices to connect directly to the cloud via relays, compromising the security of cloud services accessed by these devices. Summary of the Invention

[0004] The purpose of this application is to provide a device access method, communication system, electronic device, storage medium, and program product to improve the problem that existing methods cannot guarantee the security of intranet security devices enjoying cloud services.

[0005] In a first aspect, embodiments of this application provide a device access method applied to a relay device, the method comprising:

[0006] Obtain a first access request from an intranet security device, the access request including a first access verification code and first device information of the intranet security device;

[0007] When the relay device is in cloud service mode, it sends the first access request to the cloud to request the cloud to verify the first access verification code and the first device information, and after the verification is successful, it creates a communication channel between the intranet security device and the cloud.

[0008] In the above implementation process, when the intranet security device connects to the cloud, the relay device can send the access verification code and device information of the intranet security device to the cloud for verification. Only after the verification is successful will a communication channel be established between the cloud and the intranet security device. This can perform security verification on the intranet security device to ensure the security of subsequent communication.

[0009] Optionally, before sending the access request to the cloud, the method further includes:

[0010] Determine whether the relay device is connected to the cloud;

[0011] If not, a second access request is sent to the cloud. The second access request includes a second access verification code and the second device information of the relay device, in order to request the cloud to verify the second access verification code and the second device information. After the verification is successful, a communication channel is created between the relay device and the cloud.

[0012] In the above implementation process, security verification is also performed when the relay device connects to the cloud, thus ensuring the security of communication between the relay device and the cloud.

[0013] Optionally, after sending the first access request to the cloud, the method further includes:

[0014] The system receives a target verification code sent from the cloud, the target verification code being generated based at least on the first device information, and the target verification code being used as an access verification code when the internal network security device subsequently accesses the cloud.

[0015] In the above implementation process, after the intranet security device connects to the cloud, the cloud can resend a new target verification code to the intranet security device for use when the intranet security device connects to the cloud in the future. This can avoid security problems caused by the leakage of the initial access verification code.

[0016] Optionally, the first access verification code and the second access verification code are generated by the cloud, and the first access verification code and the second access verification code are configured with a validity period. The first access verification code and the second access verification code are valid within the validity period, and the cloud is used to verify the validity of the first access verification code and the second access verification code.

[0017] In the above implementation process, a corresponding validity period is configured for the access verification code, so that the access verification code is valid within the validity period and expires after the validity period. This can ensure the security of intranet security device access and avoid the problem of access verification code being leaked and used illegally.

[0018] Optionally, the communication channel is built based on the MQTT protocol, and data transmission between the intranet security device and the cloud follows the MQTT protocol. Since the MQTT protocol supports TLS / SSL encryption, this ensures the security of communication data between the cloud and the intranet security device, preventing data tampering or theft.

[0019] Optionally, after obtaining the first access request from the intranet security device, the method further includes:

[0020] When the relay device is in offline mode, the first access verification code and the first device information are verified.

[0021] After successful verification, a communication channel is created between the intranet security device and the relay device.

[0022] In the above implementation process, when the relay device is in offline mode, the relay device verifies the access to the intranet, thereby ensuring the security of intranet communication.

[0023] Secondly, this application provides a communication system, which includes an intranet security device, a relay device, and a cloud. The communication channels between the intranet security device and the relay device, and between the relay device and the cloud, follow the relevant specifications of the MQTT protocol. The communication channel between the intranet security device and the cloud is constructed after accessing the network through the device access method described above.

[0024] The relay device, the intranet security device, and the cloud are used to verify the standardization of the received communication data.

[0025] In the above implementation process, communication between intranet security devices and the cloud is realized through relay devices, and intranet security devices can be made available to the cloud based on the MQTT protocol. The communication data between them follows the relevant specifications of the MQTT protocol to ensure the security and stability of data communication.

[0026] Optionally, the relevant specifications include at least one of the following: device access specifications, device file transfer specifications, log file transfer specifications, custom data transfer specifications, command issuance specifications, device basic information reporting specifications, device authorization information specifications, rule base upgrade specifications, and inter-device communication specifications. By defining these specifications, communication between intranet security devices, relay devices, and the cloud is constrained, thereby improving communication security.

[0027] Optionally, the number of relay devices can be multiple, and these relay devices can be cascaded to enable communication between the intranet security device and the cloud. This can address the situation where intranet devices are deployed to the cloud in more complex network environments.

[0028] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the steps of the method provided in the first or second aspect above are performed.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the methods provided in the first or second aspect above.

[0030] Fifthly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the steps in the methods provided in the first or second aspects above.

[0031] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0034] Figure 2 A flowchart illustrating a device access method provided in an embodiment of this application;

[0035] Figure 3 A flowchart of an intranet relay subprocess is provided for an embodiment of this application;

[0036] Figure 4 A flowchart illustrating cloud access provided in this application embodiment;

[0037] Figure 5 A schematic diagram illustrating a cascading mode of a relay device provided in an embodiment of this application;

[0038] Figure 6 A flowchart illustrating a device communication method provided in an embodiment of this application;

[0039] Figure 7 A structural block diagram of a device access apparatus provided in an embodiment of this application;

[0040] Figure 8 A structural block diagram of a device communication apparatus provided in an embodiment of this application;

[0041] Figure 9 This is a schematic diagram of the structure of an electronic device for performing a device access method or a device communication method, provided as an embodiment of this application. Detailed Implementation

[0042] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0043] It should be noted that the terms "system" and "network" in the embodiments of this invention can be used interchangeably. "Multiple" refers to two or more; therefore, in the embodiments of this invention, "multiple" can also be understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0044] It should also be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0045] This application provides a device access method applied to a relay device. The method obtains an access request from an intranet security device and then sends the access request to the cloud in a cloud service mode. This allows the cloud to verify the access request and the device information of the intranet security device. After successful verification, the cloud can establish a communication channel with the intranet security device. This allows for security verification of the intranet security device, ensuring the security of subsequent communication.

[0046] The following can be combined Figure 1 This section explains the device connection method. Figure 1 This is a schematic diagram of the structure of a communication system 10 provided in an embodiment of this application. The communication system 10 includes an intranet security device 11, a relay device 12, and a cloud 13. The communication channels between the intranet security device 11 and the relay device 12, and between the relay device 12 and the cloud 13, follow the relevant specifications of the Message Queuing Telemetry Transport (MQTT) protocol. The communication channel between the intranet security device 11 and the cloud 13 is constructed after accessing the device using the device access method of this solution.

[0047] The relay device 12, the intranet security device 11, and the cloud 13 are used to verify the standardization of the received communication data.

[0048] MQTT is a lightweight messaging protocol based on the publish / subscribe paradigm, built on top of TCP / IP. It provides specifications for secure device access, describing data transmission formats, MQTT Topic specifications, and more.

[0049] The MQTT protocol uses TLS / SSL security encryption to protect network communication from eavesdropping and tampering, ensuring the security of data transmission. Therefore, the data interaction between the intranet security device 11 and the cloud 13 follows the MQTT protocol specifications for security.

[0050] In addition, in the MQTT protocol, the intranet security device 11 and the cloud 13 can also use certificates for two-way authentication to ensure the trustworthiness of the intranet security device 11. Both parties have a pair of public and private keys. When establishing a connection, the two parties exchange certificates and verify each other's certificates to ensure that both parties in the communication are certified and trusted entities.

[0051] The MQTT protocol uses QoS2 for data transmission quality, ensuring reliable data transmission.

[0052] Data transmitted via the MQTT-based communication channel can use the Protocol Buffers (v3) data format, which effectively reduces the amount of data transmitted (saving 90% of the space compared to JSON and binary after serialization), and its structure is platform-independent and applicable.

[0053] Understandably, the communication channels between relay device 12 and cloud 13, and between relay device and intranet security device, can all be built using the MQTT protocol, and the communication specifications should remain consistent.

[0054] The relevant specifications of the MQTT protocol include at least one of the following: device access specifications, device file transfer specifications, log file transfer specifications, custom data transfer specifications, command issuance specifications, device basic information reporting specifications, device authorization information specifications, rule base upgrade specifications, and inter-device communication specifications. These specifications are defined to constrain communication between intranet security devices, relay devices, and the cloud, thereby improving communication security.

[0055] (1) Device access specifications, involving MQTT Topic naming, structure data sent during device registration, and structure data indicating successful or failed access.

[0056] (2) Device file transfer specifications, including MQTT Topic naming, file fragmentation specifications, and specifications for initiating file uploads or downloads, etc.

[0057] (3) Log file transmission specifications, including MQTT Topic naming, log compression and upload specifications, log single-line specifications, log structure following Syslog, etc.

[0058] (4) Custom data transmission specifications, involving MQTT Topic naming, are divided into asynchronous data transmission structure specifications and synchronous request and response data structure specifications.

[0059] (5) Command issuance specifications, which involve MQTT Topic naming, command data structure specifications, and command execution response data structure.

[0060] (6) Equipment basic information reporting specifications, including MQTT Topic naming, basic information data structure specifications, heartbeat data structure specifications, etc.

[0061] (7) Device authorization information specifications, including MQTT Topic naming, basic authorization information reporting specifications, and authorization file download specifications.

[0062] (8) Rule base upgrade specifications, which involve specifications for MQTT Topic naming, checking whether the rule base is being upgraded, and rule base file download.

[0063] (9) Inter-device communication specifications, including MQTT Topic naming, inter-device request structure (including synchronous and asynchronous transmission methods), device discovery, and other specifications.

[0064] The specific implementation of the above specifications can be flexibly set according to the actual situation. After these relevant specifications are formulated, the MQTT protocol can be deployed for data communication. In this way, there is no need to make additional settings for the relevant requirements of data communication. You only need to communicate in accordance with the relevant specifications of the MQTT protocol.

[0065] The intranet security device 11, relay device 12, and cloud device 13 can all verify the standardization of the received communication data. The verification method is to check whether the received data meets the above-mentioned standardization requirements. If it does, the received data is considered accurate and subsequent responses can continue. If it does not, the received data is considered incorrect and corresponding error messages can be returned, thereby ensuring the security of data transmission.

[0066] In the above implementation process, communication between intranet security devices and the cloud is realized through relay devices, and intranet security devices can be made available to the cloud based on the MQTT protocol. The communication data between them follows the relevant specifications of the MQTT protocol to ensure the security and stability of data communication.

[0067] In some implementations, in order to cope with complex network environments, there can be multiple relay devices. Multiple relay devices can form a cascaded mode to realize communication between intranet security devices and the cloud. For example, a security device in an intranet needs to cross multiple relay devices to communicate with the cloud. Cascading devices in a multi-layered network environment can realize the interconnection of devices at different levels and access to the cloud.

[0068] Please refer to Figure 2 , Figure 2A flowchart of a device access method provided in this application embodiment, the method including the following steps:

[0069] Step S110: Obtain the first access request from the intranet security device.

[0070] Intranet security devices refer to security devices that cannot directly connect to the internet to enable cloud service integration, but have an urgent need for network security capabilities. Deployed in an isolated intranet environment, these devices can be any single device within the intranet that requires cloud service integration. Intranet security devices can perform functions such as internet access management, vulnerability scanning, log auditing, database auditing, and bastion host functionality.

[0071] To ensure the security of the internal network, this solution uses relay devices to bridge cloud services. In this way, the relay devices not only ensure the security of the internal network, but also enable seamless interaction with the cloud.

[0072] When an intranet security device needs to access the cloud, it will initiate an access request, namely the first access request. This first access request will first reach the relay device. The first access request includes the first access verification code and the first device information of the intranet security device.

[0073] The first access verification code is used for access verification. The first access verification code can be applied for by the user from the cloud. When the user applies for the verification code, the cloud can generate an access verification code for the user. When the intranet security device needs to access the cloud, the user will upload the access verification code obtained from the cloud to the intranet security device, so that the intranet security device can use the access verification code to access.

[0074] Understandably, the access verification code requested by a user can be used by multiple intranet security devices, or it can be used only by one content device. For example, when a user requests an access verification code in the cloud, they enter the device information of the intranet security device that needs to access the cloud. In this way, the cloud can generate an access verification code based on the device information of the intranet security device. The access verification code can be a random code or a hash value generated based on the device information, etc.

[0075] The device information of intranet security devices may include the IP address, MAC address, device identifier, and other information of the intranet security devices.

[0076] Step S120: When the relay device is in cloud service mode, send a first access request to the cloud to request the cloud to verify the first access verification code and the first device information, and after the verification is successful, create a communication channel between the intranet security device and the cloud.

[0077] Relay devices can operate in multiple service modes, including cloud service mode, offline mode, and cascading mode. In cloud service mode, relay devices quickly establish a network channel between cloud services and the intranet. Business systems can communicate with the relay devices only within the isolated area of ​​the external network, with the relay devices forwarding data to the cloud and ensuring security within the business area. In offline mode, intranet security devices connected to the relay devices can be managed independently, enabling interconnection of devices across networks, but cloud-provided services cannot be used. In cascading mode, multiple relay devices can be cascaded, applicable to complex intranet environments. Cascading devices within a multi-layered network environment enables interconnection of devices at different levels and cloud access.

[0078] In the cascading mode, since it is formed by cascading multiple relay devices, these relay devices can be in offline mode or cloud service mode, depending on the configuration of each relay device.

[0079] In some implementations, the mode of the relay device can be configured manually according to needs, or it can be selected by the relay device itself. For example, the first access request of the intranet security device also carries a destination address. If the destination address is a cloud address, the relay device can know that the intranet security device wants to access the cloud after receiving the first access request. Then it can switch the mode to cloud service mode and realize cloud access. If the first access request carries the address of other intranet security devices or the address of the relay device, the relay device can determine that it does not want to access the cloud and can switch the mode to offline mode and realize intranet access.

[0080] In some implementations, when verifying the first access verification code and the first device information, the cloud can verify the accuracy of the first access verification code. For example, if the first access verification code was requested by the user from the cloud, the cloud can verify its accuracy; if it is correct, the verification passes. The cloud can also verify the accuracy of the first device information, such as whether its IP address, MAC address, etc., are valid address information. If valid, the verification passes. Alternatively, if the first access verification code was requested by the user from the cloud, and the cloud generates it based on the device information of the intranet security device, then during verification, the cloud can first generate an access verification code based on the first device information and compare it with the first access verification code. If they match, the verification is considered successful. This avoids the problem of access verification codes being leaked and illegally used by other devices.

[0081] After the cloud verifies the first access verification code and the first device information, it can create a communication channel between the intranet security device and the cloud. This communication channel is essentially a communication channel between the cloud and the relay device, and between the relay device and the intranet security device. However, the intranet security device is unaware of the relay device and perceives it as communicating directly with the cloud. This integrated cloud service model not only enhances the security of the intranet security device but also improves its operational efficiency and reliability.

[0082] In this way, intranet security devices can communicate with the cloud through the established communication channels, and the cloud can perform security empowerment and other operations on the intranet security devices.

[0083] For example, the cloud can provide real-time security updates and maintenance for intranet security devices, including rule base (intelligence database, virus database, etc.) updates, security business hosting services (leveraging cloud advantages to achieve security situation analysis and risk blocking), and expert services (the cloud provides expert judgment and analysis capabilities), etc. It can also provide customized security strategies and optimization measures according to the specific needs of intranet security devices, thus bringing a different cloud service experience while ensuring the security of customers' intranets.

[0084] In the above implementation process, when an intranet security device connects to the cloud, the relay device can send the intranet security device's access verification code and device information to the cloud for verification. Only after successful verification will a communication channel be established between the cloud and the intranet security device. This allows for secure verification of the intranet security device, ensuring the security of subsequent communication. In this way, even when the intranet security device cannot directly access the external network, it can still securely communicate and exchange data with the cloud.

[0085] Based on the above embodiments, before the relay device sends an access request to the cloud, the relay device can first determine whether it is connected to the cloud. If not, it sends a second access request to the cloud. The second access request includes a second access verification code and the second device information of the relay device, so as to request the cloud to verify the second access verification code and the second device information. After the verification is successful, a communication channel is created between the relay device and the cloud.

[0086] In this method, after receiving the first access request, the relay device can first determine whether it has already established communication with the cloud. If not, it still needs to connect to the cloud. If it has, it does not need to connect to the cloud and can directly send the first access request to the cloud.

[0087] The method for obtaining the second access verification code is similar to that of the first access verification code; both are applied for by the user in the cloud and uploaded to the relay device. If the second access verification code is randomly generated by the cloud, the accuracy of the second access verification code and the second device information can be verified during verification, and the verification method is similar to that of the first access verification code and the first device information. If the second access verification code is generated by the cloud based on the second device information of the relay device, the cloud can obtain the second device information from the second access request, generate a verification code based on the second device information, and compare it with the second access verification code for verification. The verification method is also similar to that of the first access verification code, and will not be elaborated further here.

[0088] After the cloud verifies the second access verification code and the second device information, it creates a communication channel between the cloud and the relay device. Once the relay device and the cloud establish a communication channel, the relay device can send the first access request sent by the intranet security device to the cloud for verification.

[0089] In the above implementation process, security verification is also performed when the relay device connects to the cloud, thus ensuring the security of communication between the relay device and the cloud.

[0090] Based on the above embodiments, when a user applies for the first and second access verification codes in the cloud, it is generally difficult for the user to obtain the device information of the intranet security device or relay device to upload to the cloud so that the cloud can generate access verification codes based on the device information. Therefore, in order to quickly achieve access, the first and second access verification codes are generally randomly generated by the cloud. In this case, the security of the two access verification codes is not high. Therefore, after the intranet security device or relay device connects to the cloud, the cloud can regenerate an access verification code. Specifically, after the relay device sends the first access request to the cloud, it can receive the target verification code sent by the cloud. The target verification code is generated based at least on the first device information and is used as the access verification code when the intranet security device connects to the cloud subsequently.

[0091] After an intranet security device connects to the cloud, a target verification code is sent to it. Similarly, after a relay device connects to the cloud, the cloud can generate a target verification code based on at least the relay device's device information and send it to the relay device. The target verification code is generated based on at least the first device information; that is, it is a unique access verification code for a single intranet security device. This means that if the intranet security device subsequently disconnects and needs to reconnect to the network, the user does not need to request another access verification code; instead, the target verification code can be used for reconnection.

[0092] In some implementations, the target verification code can also be generated based on the first device information and the first access verification code, which can be distinguished from the first access verification code, since the first access verification code is also generated based on the first device information in some methods. This allows different verification codes to distinguish between the verification of the first access and subsequent access.

[0093] In the above implementation process, after the intranet security device connects to the cloud, the cloud can resend a new target verification code to the intranet security device for use when the intranet security device connects to the cloud in the future. This can avoid security problems caused by the leakage of the initial access verification code.

[0094] Based on the above embodiments, in order to ensure security, the first access verification code and the second access verification code are generated in the cloud. The first access verification code and the second access verification code are configured with a validity period. The first access verification code and the second access verification code are valid within the validity period. The cloud is used to verify the validity of the first access verification code and the second access verification code.

[0095] Understandably, in addition to verifying the accuracy of the first and second access verification codes as described in the above embodiments, the cloud can also verify the validity of the two access verification codes.

[0096] For example, after obtaining the first access verification code from the first access request or the second access verification code from the second access request, the cloud can first verify the accuracy of the first and second access verification codes. If the verification passes, then the validity is verified. When a user applies for the first and second access verification codes from the cloud, the cloud can record the validity period of the two verification codes after generating them. The validity period can be a specific duration, such as 24 hours, or an expiration time, such as a specific timestamp. Then, during access, the cloud compares the time of the access verification codes obtained from the two access requests with the validity period to see if they are still within the validity period. If not, the verification fails; if they are, the verification passes.

[0097] In this scenario, if the first access verification code expires after its validity period, and the cloud fails the validity verification, it can return a corresponding prompt message to the relay device. The relay device then forwards the prompt message to the intranet security device. Upon receiving the prompt message, the intranet security device knows that the access verification code has expired, and the user needs to apply for a new access verification code from the cloud. The intranet security device can then use the new access verification code to access the network again. Similarly, when the relay device accesses the network, if the second access verification code expires, the cloud returns a prompt message. After receiving this prompt message, the user can apply for a new access verification code from the cloud again, and the relay device will then use the new access verification code to initiate another access request.

[0098] Furthermore, since access verification codes have a time limit, after an intranet security device connects, the cloud can generate a new target verification code for the intranet security device. As mentioned in the above embodiments, the target verification code can be generated based at least on the device information of the intranet security device. The target verification code can be a long-term valid verification code, or its validity period can be longer than that of the initial access verification code. Similarly, for the second access verification code, after the relay device connects to the cloud, the cloud can also regenerate a new target verification code for the relay device, which is generated based on the relay device's device information.

[0099] In some other implementations, the cloud can also configure a corresponding number of valid attempts for the first access verification code and the second access verification code. That is, each time access is made, the number of valid attempts is reduced by 1. When the number of valid attempts is 0, the access verification code becomes invalid.

[0100] In the above implementation process, a corresponding validity period is configured for the access verification code, so that the access verification code is valid within the validity period and expires after the validity period. This can ensure the security of intranet security device access and avoid the problem of access verification code being leaked and used illegally.

[0101] Based on the above embodiments, the communication channel is constructed using the MQTT protocol. Data transmission between the intranet security device and the cloud follows the MQTT protocol. For relevant requirements of the MQTT protocol, please refer to the relevant descriptions in the above embodiments, which will not be elaborated further here.

[0102] Based on the above embodiments, after the relay device obtains the first access request from the intranet security device, and the relay device is in offline mode, the first access verification code and the first device information are verified. After the verification is successful, a communication channel is created between the intranet security device and the relay device.

[0103] Understandably, in offline mode, intranet security devices cannot access the cloud. Therefore, intranet security devices can only communicate between intranet devices, and communication between intranet security devices is achieved through relay devices.

[0104] In this case, the first access verification code can be applied for by the user for the intranet security device on the relay device. Therefore, the relay device can verify the first access verification code and the first device information. The verification method is similar to the cloud verification scheme mentioned above, and will not be repeated here.

[0105] The communication channel established between the relay device and the intranet security device can also be a secure data channel, built on the MQTT protocol, and its data transmission specifications also meet the requirements of the aforementioned MQTT protocol. The cloud service communication specifications defined based on the MQTT protocol involve corresponding specifications for device access, data transmission, and file transfer. Intranet security devices accessing relay devices, and relay devices accessing cloud services, must strictly adhere to the access specifications. The access specifications for relay devices are consistent with the cloud access specifications; that is, intranet security devices that connect to relay devices can also directly connect to the cloud.

[0106] The MQTT-based communication channel uses encryption mechanisms such as TLS / SSL to ensure secure communication between the lightweight access point and the cloud. Encryption protection during data transmission prevents threats such as data leakage, tampering, and man-in-the-middle attacks.

[0107] In the above implementation process, when the relay device is in offline mode, the relay device verifies the access to the intranet, thereby ensuring the security of intranet communication.

[0108] like Figure 3 As shown, Figure 3 This application provides a flowchart of an intranet relay subprocess, which details the processing procedure of the relay device when the intranet security device connects to the cloud.

[0109] When an intranet security device initiates an access request, since the cloud and relay devices use the same protocol, the destination address of the access request can be either the cloud or the relay device. If the access request is initiated directly to the cloud, it means that the intranet security device is directly connected to the cloud, and the relay device does not participate in the processing. If the access request is initiated to the relay device, the relay device will process it in three modes.

[0110] One model is the cloud service model. First, the relay device needs to connect to the cloud to ensure its trustworthiness. After successful connection, the relay device will forward all requests to it (including intranet security device access, file transfer, log reporting, custom data transmission, and communication with designated devices). After the cloud successfully authenticates the intranet security device's access, it will open channels for file transfer, log reporting, custom data transmission, and inter-device communication. Through the relay device, bidirectional communication between intranet security devices and the cloud, as well as between intranet security devices themselves, can be achieved, enabling security services.

[0111] One mode is offline mode. In offline mode, the relay device does not interact with the cloud. It primarily uses local authentication to verify the access of intranet security devices, such as the access verification code method mentioned above, or a whitelist mechanism. This allows multiple intranet security devices to connect to the relay device. This mode focuses on enabling local cross-network intranet security device collaboration. Cross-network intranet security devices discover other intranet security devices through the relay device and conduct bidirectional communication. In this mode, the relay device lightweights some cloud functions to local operation, such as authentication and device management. It is primarily used in areas completely isolated from the internet to enable cross-network communication of security devices.

[0112] Another type is the cascading mode. Since the network protocols and specifications of the cloud and the relay are consistent, the relay device can be connected to the cloud or other relay devices to realize the series connection of multiple relay devices. Finally, the terminal relay device chooses whether to use the offline mode or the cloud service mode. This mode is more suitable for complex network environments, such as when the intranet needs to go through multiple layers of hops to communicate with the external cloud.

[0113] Security devices accessed via cloud services establish a network channel (MQTT channel) between the cloud and intranet security devices. This allows cloud computing power to be leveraged to empower intranet security devices, such as rule base updates (intelligence database, virus database), security business hosting (utilizing cloud advantages to achieve security situation analysis and risk blocking), expert services (cloud-based expert judgment and analysis capabilities), etc. This delivers a unique cloud service experience while ensuring the security of the customer's intranet.

[0114] The three modes of relay devices (cloud service mode, offline mode, and cascade mode) address different scenarios and have different levels of complexity. The cloud service mode mainly solves the problem of internal network isolated devices going to the cloud and enables cloud empowerment. The offline mode is mainly a solution for local devices to communicate across internal networks. The cascade mode is the most complex of the three modes and mainly solves the problem of devices going to the cloud in more complex network environments.

[0115] For detailed instructions on cloud access, please refer to [link / reference]. Figure 4 As shown, Figure 4 The access code or access information mentioned above refers to the access verification code in the above embodiments. Cloud access (only for the cloud service mode described above) mainly follows the MQTT protocol specification. The device carries the access verification code applied for by the cloud to complete the security access of the intranet security device or relay device. The cloud opens the subscription and publishing permissions of the relevant topics for the MQTT channel, realizing bidirectional communication between the device and the cloud while ensuring channel security. For relay devices in offline and cascaded modes, the main principle is to fully comply with the MQTT protocol specification to maintain consistency with the cloud, and to lightweight the cloud access authentication and device management functions, enabling it to operate independently.

[0116] After the intranet security devices and relay devices are successfully connected to the cloud, heartbeat signals can be sent to the cloud periodically to ensure that the devices are online. If the cloud does not receive heartbeat signals for a long period of time, the devices are considered offline. This maintains a list of continuously online devices, which facilitates device discovery, communication between devices, and online monitoring of devices.

[0117] In some implementations, the validity period of the first and second access verification codes can be associated with the device's online duration. For example, when applying for the first and second access verification codes in the cloud, it is not necessary to allocate a fixed validity period to the two access verification codes in advance. Instead, the validity of the two access verification codes is determined based on whether the device is online. For instance, during the initial access, both are considered valid during validity verification. However, if the cloud detects that the relay device or intranet security device has gone offline, the corresponding first and second access verification codes can be changed to an invalid state in the cloud. In this case, the previous access verification codes cannot be reused for subsequent access (validity verification fails), and new access verification codes need to be applied for for access.

[0118] The following is a specific example to illustrate this, such as Figure 5 As shown.

[0119] Relay device AB` is connected to the cloud using a cloud service model. Relay devices C` and D` are connected to relay device AB` via cascading. Relay devices AB`, C`, and D` all expose the same services as the cloud-based MQTT and use the same communication specifications.

[0120] Device C connects to relay device C' based on the communication standard (MQTT admission standard), device D connects to relay device D', and devices A and B connect to relay device AB'. After successful connection, users can view the corresponding connected devices in the cloud. Only relay devices can communicate between intranet A, intranet B, and intranet C; their intranet security devices cannot be directly interconnected.

[0121] If permissions permit, mutual discovery between devices A to D can be achieved based on 3 relay devices. For example, cross-network communication can be achieved between device B and device D (which needs to comply with the MQTT inter-device communication specification).

[0122] Since all devices A through D are connected to the cloud service, they can enjoy corresponding cloud services, such as rule base upgrades, expert services, and managed services, which empower the security devices of the user's intranet.

[0123] Please refer to Figure 6 , Figure 6A flowchart of a device communication method provided in this application embodiment, which is also applied to relay devices, includes the following steps:

[0124] Step S210: Receive security business data sent from the cloud.

[0125] Security business data refers to data that enables internal network security devices to access cloud services, such as rule base upgrades, security business hosting, and expert services. Security business data delivered from the cloud can first be forwarded to relay devices, which then forward it to the corresponding internal network security devices.

[0126] Step S220: Forward the security service data to the corresponding intranet security device.

[0127] The intranet security device accesses the cloud through the access method described in the above embodiments. The specific implementation process can be referred to the relevant description in the above embodiments. For the sake of brevity, it will not be repeated here.

[0128] Please refer to Figure 7 , Figure 7 This is a structural block diagram of a device access device 300 provided in an embodiment of this application. The device 300 may be a module, program segment, or code on an electronic device (such as a relay device). It should be understood that this device 300 is similar to the one described above. Figure 2 The method implementation corresponds to this and can be executed. Figure 2 The various steps involved in the method embodiment and the specific functions of the device 300 can be found in the description above. To avoid repetition, detailed descriptions are omitted here.

[0129] Optionally, the device 300 includes:

[0130] The request acquisition module 310 is used to acquire the first access request of the intranet security device, the access request including the first access verification code and the first device information of the intranet security device.

[0131] The request sending module 320 is used to send the first access request to the cloud when the relay device is in cloud service mode, so as to request the cloud to verify the first access verification code and the first device information, and after the verification is successful, to create a communication channel between the intranet security device and the cloud.

[0132] Optionally, the request sending module is further configured to determine whether the relay device is connected to the cloud; if not, a second access request is sent to the cloud, the second access request including a second access verification code and the second device information of the relay device, to request the cloud to verify the second access verification code and the second device information, and after successful verification, to create a communication channel between the relay device and the cloud.

[0133] Optionally, the first access verification code and the second access verification code are generated by the cloud, and the first access verification code and the second access verification code are configured with a validity period. The first access verification code and the second access verification code are valid within the validity period, and the cloud is used to verify the validity of the first access verification code and the second access verification code.

[0134] Optionally, the device 300 further includes:

[0135] The information receiving module is used to receive the target verification code sent by the cloud. The target verification code is generated based at least on the first device information and is used as the access verification code when the intranet security device accesses the cloud.

[0136] Optionally, the communication channel is built based on the MQTT protocol, and the data transmission between the intranet security device and the cloud follows the MQTT protocol.

[0137] Optionally, the device 300 further includes:

[0138] The verification module is used to verify the first access verification code and the first device information when the relay device is in offline mode; after the verification is successful, a communication channel is created between the intranet security device and the relay device.

[0139] Please refer to Figure 8 , Figure 8 This is a structural block diagram of a device communication apparatus 400 provided in an embodiment of this application. The apparatus 400 may be a module, program segment, or code on an electronic device (such as a relay device). It should be understood that the apparatus 400 is similar to the one described above. Figure 6 The method implementation corresponds to this and can be executed. Figure 6 The various steps involved in the method embodiment and the specific functions of the device 400 can be found in the description above. To avoid repetition, detailed descriptions are omitted here.

[0140] Optionally, the device 400 includes:

[0141] Data receiving module 410 is used to receive security business data sent from the cloud;

[0142] The data forwarding module 420 is used to forward the security service data to the corresponding intranet security device, wherein the intranet security device accesses the cloud through the device access method described above.

[0143] It should be noted that those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0144] Please refer to Figure 9 , Figure 9 This is a schematic diagram of an electronic device for executing a device access method or a device communication method, provided in an embodiment of this application. The electronic device may include: at least one processor 510, such as a CPU; at least one communication interface 520; at least one memory 530; and at least one communication bus 540. The communication bus 540 is used to implement communication between these components. In this embodiment, the communication interface 520 is used for signaling or data communication with other node devices. The memory 530 may be a high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 530 may also be at least one storage device located remotely from the aforementioned processor. The memory 530 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 510, the electronic device performs the aforementioned... Figure 2 or Figure 6 The method and process are shown.

[0145] Understandable. Figure 9 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 9 The more or fewer components shown, or having the same Figure 9 The different configurations shown. Figure 9 The components shown can be implemented using hardware, software, or a combination thereof.

[0146] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, performs the following... Figure 2 or Figure 6 The method process executed by the electronic device in the illustrated method embodiment.

[0147] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as including:

[0148] Obtain a first access request from an intranet security device, the access request including a first access verification code and first device information of the intranet security device;

[0149] When the relay device is in cloud service mode, it sends the first access request to the cloud to request the cloud to verify the first access verification code and the first device information, and after the verification is successful, it creates a communication channel between the intranet security device and the cloud.

[0150] In summary, the embodiments of this application provide a device access method, a communication system, an electronic device, a storage medium, and a program product. When an intranet security device accesses the cloud, the relay device can send the access verification code and device information of the intranet security device to the cloud for verification. Only after the verification is successful will a communication channel be established between the cloud and the intranet security device. This allows for security verification of the intranet security device to ensure the security of subsequent communication.

[0151] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0152] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0154] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0155] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A device access method, characterized in that, Applied to relay equipment, the method includes: Obtain a first access request from an intranet security device, the access request including a first access verification code and first device information of the intranet security device; When the relay device is in cloud service mode, the first access request is sent to the cloud to request the cloud to verify the first access verification code and the first device information, and after the verification is successful, a communication channel is created between the intranet security device and the cloud. After sending the first access request to the cloud, the method further includes: Receive the target verification code sent by the cloud, the target verification code is generated based at least on the first device information and the first verification code, and the target verification code is used as the access verification code when the internal network security device accesses the cloud in the future; The first access request further includes a destination address; after obtaining the first access request for the intranet security device, it also includes: The target service mode of the relay device is determined based on the destination address, and the service mode of the relay device is switched to the target service mode. The service mode includes cloud service mode, offline mode and cascading mode. If the target service mode is cloud service mode, the following steps are performed: send the first access request to the cloud.

2. The method according to claim 1, characterized in that, Before sending the access request to the cloud, the method further includes: Determine whether the relay device is connected to the cloud; If not, a second access request is sent to the cloud. The second access request includes a second access verification code and the second device information of the relay device, in order to request the cloud to verify the second access verification code and the second device information. After the verification is successful, a communication channel is created between the relay device and the cloud.

3. The method according to claim 2, characterized in that, The first access verification code and the second access verification code are generated by the cloud. The first access verification code and the second access verification code are configured with a validity period. The first access verification code and the second access verification code are valid within the validity period. The cloud is used to verify the validity of the first access verification code and the second access verification code.

4. The method according to claim 1, characterized in that, The communication channel is built on the MQTT protocol, and the data transmission between the intranet security device and the cloud follows the MQTT protocol.

5. The method according to claim 1, characterized in that, After obtaining the first access request from the intranet security device, the method further includes: When the relay device is in offline mode, the first access verification code and the first device information are verified. After successful verification, a communication channel is created between the intranet security device and the relay device.

6. A communication system, characterized in that, The communication system includes an intranet security device, a relay device, and a cloud. The communication channels between the intranet security device and the relay device, and between the relay device and the cloud, follow the relevant specifications of the MQTT protocol. The communication channel between the intranet security device and the cloud is constructed after accessing the device using any of the device access methods described in claims 1-5. The relay device, the intranet security device, and the cloud are used to verify the standardization of the received communication data.

7. The communication system according to claim 6, characterized in that, The relevant specifications include at least one of the following: device access specifications, device file transfer specifications, log file transfer specifications, custom data transfer specifications, command issuance specifications, device basic information reporting specifications, device authorization information specifications, rule base upgrade specifications, and inter-device communication specifications.

8. The communication system according to claim 6, characterized in that, The number of relay devices is multiple, and the multiple relay devices form a cascaded mode to realize communication between the intranet security device and the cloud.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, perform the method as described in any one of claims 1-5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it performs the method as described in any one of claims 1-5.

11. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-5.

Images