Device access method, communication system, electronic device, storage medium and program product

Abstract

The invention provides a device access method, a communication system, an electronic device, a storage medium and a program product, and relates to the technical field of communication. According to the scheme, communication between the intranet security equipment and the cloud end is realized through the relay equipment, clouding of the intranet security equipment can be realized on the basis of the MQTT protocol, and communication data between the intranet security equipment follows related specifications of the MQTT protocol, so that the security and stability of data communication are ensured. Moreover, when the intranet security device accesses the cloud, the relay device can send the access verification code and the device information of the intranet security device to the cloud for verification, and after the verification is passed, a communication channel between the cloud and the intranet security device is constructed, so that security verification can be performed on the intranet security device to ensure the security of subsequent communication.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a device access method, a communication system, an electronic device, a storage medium, and a program product. Background Art

[0002] As enterprises' demand for digital transformation continues to grow, cloud services, with their advantages such as flexibility, scalability and cost-effectiveness, meet the needs of enterprises for efficient and convenient services.

[0003] However, due to the particularity of the security industry, there is often an isolated intranet environment, and the business area cannot directly communicate with the external cloud service end. The pure cloud solution is limited by the network environment, so the relay method becomes the key to solving the intranet cloud. However, in this way, the intranet security equipment can be directly connected to the cloud through the relay, which cannot guarantee the security of the intranet security equipment enjoying the cloud service. Summary of the invention

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

[0005] In a first aspect, an embodiment of the present application provides a device access method, which is applied to a relay device, and the method includes:

[0006] Obtaining 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, 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 passed, a communication channel is created between the intranet security device and the cloud.

[0008] In the above implementation process, when the intranet security device is connected 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 passed, a communication channel between the cloud and the intranet security device will be established. In this way, the intranet security device can be securely verified to ensure the security of subsequent communications.

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

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

[0011] If not, a second access request is sent to the cloud, wherein the second access request includes a second access verification code and 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, and after the verification is passed, 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 is connected to the cloud, so as to ensure 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] Receive a target verification code sent by the cloud, where the target verification code is generated based on at least the first device information, and the target verification code is used as an access verification code when the intranet security device subsequently accesses the cloud.

[0015] In the above implementation process, after the intranet security device is connected to the cloud, the cloud can resend a new target verification code to the intranet security device for use when the intranet security device subsequently connects to the cloud, thereby avoiding security issues 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 valid period, and the first access verification code and the second access verification code are valid within the valid 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, the corresponding validity period is configured for the access verification code, so that the access verification code is valid within the validity period and becomes invalid after the validity period. This can ensure the security of access to the intranet security device and avoid the problem of access verification code leakage and illegal use.

[0018] Optionally, the communication channel is constructed based on the MQTT protocol, and the data transmission between the intranet security device and the cloud follows the MQTT protocol. Since the MQTT protocol supports TLS / SSL encryption, the security of the communication data between the cloud and the intranet security device can be guaranteed to prevent the data from being tampered with or stolen.

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

[0020] When the relay device is in an offline mode, verifying the first access verification code and the first device information;

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

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

[0023] In a second aspect, an embodiment of the present application provides a communication system, the communication system comprising 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 comply with relevant specifications of the MQTT protocol, and the communication channel between the intranet security device and the cloud is constructed after access through the above-mentioned device access method;

[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, the communication between the intranet security device and the cloud is realized through the relay device, and the intranet security device can be put on 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 device access specifications, device file transfer specifications, log file transfer specifications, custom data transfer specifications, instruction issuance specifications, device basic information reporting specifications, device authorization information specifications, rule base upgrade specifications, and inter-device communication specifications. By defining these specifications, the communication between the intranet security device, relay device, and cloud is constrained, thereby improving the security of communication.

[0027] Optionally, there are multiple relay devices, and the multiple relay devices form a cascade mode to achieve communication between the intranet security device and the cloud. This can cope with the situation where the intranet device is on the cloud in a more complex network environment.

[0028] In a third aspect, an embodiment of the present application provides an electronic device, comprising 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 in the method provided in the first aspect or the second aspect are performed.

[0029] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps in the method provided in the first aspect or the second aspect are performed.

[0030] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising computer program instructions, which, when read and executed by a processor, execute the steps in the method provided in the first aspect or the second aspect above.

[0031] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the embodiments of the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0033] Figure 1 A schematic diagram of the structure of a communication system provided in an embodiment of the present application;

[0034] Figure 2 A flow chart of a device access method provided in an embodiment of the present application;

[0035] Figure 3 A flowchart of an intranet relay sub-process provided in an embodiment of the present application;

[0036] Figure 4 A flow chart of cloud access provided in an embodiment of the present application;

[0037] Figure 5 A schematic diagram of a cascade mode of a relay device provided in an embodiment of the present application;

[0038] Figure 6 A flow chart of a device communication method provided in an embodiment of the present application;

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

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

[0041] Fig. 9 A schematic diagram of the structure of an electronic device for executing a device access method or a device communication method provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0043] It should be noted that the terms "system" and "network" in the embodiments of the present invention can be used interchangeably. "Multiple" means two or more. In view of this, in the embodiments of the present invention, "multiple" can also be understood as "at least two". "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / ", unless otherwise specified, generally indicates that the previously associated objects are in an "or" relationship.

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

[0045] An embodiment of the present application provides a device access method, which is 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, so that the cloud can verify the access request and the device information of the intranet security device. After the verification is passed, the cloud can build a communication channel with the intranet security device, so that the intranet security device can be securely verified to ensure the security of subsequent communications.

[0046] The following can be combined Figure 1 To explain the device access method, Figure 1 A schematic diagram of the structure of a communication system 10 provided in an embodiment of the present 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 comply with the relevant specifications of the Message Queuing Telemetry Transport (MQTT) protocol, and the communication channel between the intranet security device 11 and the cloud 13 is constructed after access through the device access method of the present 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] The MQTT protocol is a "lightweight" messaging protocol based on the publish / subscribe paradigm, which is built on the TCP / IP protocol. Based on the MQTT protocol, the specification of secure device access can be implemented, describing the transmission data format, MQTT Topic (MQTT subscription / publishing topic) specification, etc.

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

[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 credibility of the intranet security device 11. Both parties have a pair of public keys and private keys. When establishing a connection, the two parties exchange certificates and verify each other's certificates to ensure that both parties in communication are authenticated and trusted entities.

[0051] The data transmission service quality in the MQTT protocol is QoS2, which ensures the reliability of data transmission.

[0052] The data transmitted by the communication channel based on the MQTT protocol can be transmitted in the Protocol Buffers (v3) data format, which effectively reduces the transmission volume (90% space is saved compared to JSON and binary after serialization), and the structural platform independence is applicable.

[0053] It can be understood that the communication channel between the relay device 12 and the cloud 13, and the communication channel between the relay device and the intranet security device can both be constructed using the MQTT protocol, and the communication specifications remain consistent.

[0054] Among them, 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 transmission specifications, instruction issuance specifications, device basic information reporting specifications, device authorization information specifications, rule base upgrade specifications, and inter-device communication specifications. By defining these specifications, the communication between intranet security devices, relay devices, and the cloud can be constrained to improve the security of communication.

[0055] (1) Device access specifications, including MQTT topic naming, structured data sent by device registration, and structured data indicating successful or failed access.

[0056] (2) Device file transfer specifications, including MQTT topic naming, file segmentation specifications, file upload or download specifications, etc.

[0057] (3) Log file transmission specifications, including MQTT Topic naming, log compression upload specifications, log single record specifications, log structure compliance with Syslog, etc.

[0058] (4) Customized 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) Instruction issuance specifications, including MQTT Topic naming, instruction data structure specifications, and instruction execution response data structure.

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

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

[0062] (8) Rule base upgrade specifications, including MQTT topic naming, checking whether the rule base has been upgraded, and rule base file downloading.

[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-mentioned specifications can be flexibly set according to the actual situation. After formulating these relevant specifications, 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 according to the relevant specifications of the above-mentioned MQTT protocol.

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

[0066] In the above implementation process, the communication between the intranet security device and the cloud is realized through the relay device, and the intranet security device can be put on 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 embodiments, in order to cope with complex network environments, the number of relay devices can be multiple, and multiple relay devices can form a cascade mode to achieve communication between intranet security devices and the cloud. For example, a security device in an intranet needs to span multiple relay devices to communicate with the cloud. Cascading devices in a multi-layer network environment can achieve interconnection and cloud access for devices at different levels.

[0068] Please refer to Figure 2 , Figure 2A flow chart of a device access method provided in an embodiment of the present application, the method comprising the following steps:

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

[0070] Among them, intranet security devices refer to security devices that cannot be directly connected to the Internet to achieve cloud service linkage, but there is an urgent need for network security empowerment. Intranet security devices are deployed in an isolated intranet environment. The intranet security device here can refer to any device that needs to achieve cloud service linkage. Intranet security devices can perform Internet behavior management, leak scanning, log auditing, database auditing, bastion host and other functions.

[0071] In order to ensure the security of the internal network, this solution uses a relay device to bridge the cloud service. This relay device not only ensures the security of the internal network, but also enables seamless linkage with the cloud.

[0072] When the intranet security device needs to access the cloud, it will initiate an access request, namely a first access request, which will first reach the relay device. The first access request includes a first access verification code and 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 by the user on 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 for access.

[0074] It can be understood that the access verification code applied for by the user can be used for multiple intranet security devices or only for one content device. For example, when the user applies for an access verification code in the cloud, he enters 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 the intranet security device may include the IP address, MAC address, device identification and other information of the intranet security device.

[0076] Step S120: When the relay device is in cloud service mode, a 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 passed, a communication channel is created between the intranet security device and the cloud.

[0077] Relay devices can have multiple service modes, including cloud service mode, offline mode and cascade mode. The cloud service mode uses relay devices to quickly open up the network channel between cloud service and intranet. The business system can only communicate with the relay device in the external network isolation area, and the relay device forwards the data to the cloud to ensure the security of the business area; in the offline mode, the intranet security device connected to the relay device can be managed independently to achieve interconnection between cross-network devices, but the services provided by the cloud cannot be used; in the cascade mode, multiple relay devices can be cascaded and applied to complex intranet environments. Devices can be cascaded in a multi-layer network environment to achieve interconnection between devices at different levels and cloud access.

[0078] In the cascade mode, since multiple relay devices are cascaded, these relay devices can be in offline mode or cloud service mode, depending on the configuration of each relay device.

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

[0080] In some embodiments, when the cloud verifies the first access verification code and the first device information, it can verify the accuracy of the first access verification code. For example, the first access verification code is applied for by the user from the cloud, so the cloud can verify whether it is correct. If it is correct, the verification is successful. The cloud can verify the accuracy of the first device information, for example, it can verify whether its IP address, MAC address and other information are valid address information. If valid, the verification is successful. Alternatively, if the first access verification code is applied for by the user in the cloud, and the cloud generates it based on the device information of the intranet security device, then when the cloud verifies, it can first generate an access verification code based on the first device information, and then compare it with the first access verification code. If the comparison is consistent, the verification is considered to be successful, which can avoid the problem of the access verification code 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. The communication channel is essentially a communication channel between the cloud and the relay device, and between the relay device and the intranet security device. The intranet security device is not aware of the relay device, but feels that it is communicating directly with the cloud. This integrated cloud service model not only enhances the security of the intranet security device, but also improves its operating efficiency and reliability.

[0082] In this way, the intranet security device can communicate with the cloud through the constructed communication channel, and the cloud can perform security empowerment and other operations for the intranet security device.

[0083] For example, the cloud can provide real-time security updates and maintenance for intranet security devices, including rule library (intelligence library, virus library, etc.) updates, security business hosting services (leveraging the advantages of the cloud 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 based on the specific needs of intranet security devices, thus bringing a different cloud service experience while ensuring the security of the customer's intranet.

[0084] In the above implementation process, when the intranet security device is connected 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. After the verification is passed, the communication channel between the cloud and the intranet security device will be established. In this way, the intranet security device can be securely verified to ensure the security of subsequent communications. In this way, even if the intranet security device cannot directly access the external network, the intranet security device can still communicate and exchange data securely with the cloud.

[0085] Based on the above embodiment, before the relay device sends an access request to the cloud, the relay device may also first determine whether it is connected to the cloud. If not, it sends a second access request to the cloud, and 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, and after the verification is passed, create a communication channel 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 established communication with the cloud. If not, it still needs to access the cloud. If so, it does not need to access the cloud and can directly send the first access request to the cloud.

[0087] Among them, the method for obtaining the second access verification code is similar to the method for obtaining the first access verification code. Both are applied by the user in the cloud and uploaded to the relay device. If the second access verification code is a verification code randomly generated by the cloud, the accuracy of the second access verification code and the second device information can be verified during verification. The verification method is similar to the verification method 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, and then generate a verification code based on the second device information, and compare it with the second access verification code to perform verification. The verification method is also similar to the verification method of the first access verification code mentioned above, and will not be repeated here.

[0088] After the cloud verifies the second access verification code and the second device information, a communication channel is created between the cloud and the relay device. After 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 is connected to the cloud, so as to ensure the security of communication between the relay device and the cloud.

[0090] On the basis of the above embodiments, since it is difficult for a general user to obtain the device information of the intranet security device or relay device when the user applies for the first access verification code and the second access verification code in the cloud, so as to upload the information to the cloud so that the cloud can generate the access verification code according to the device information, the first access verification code and the second access verification code are generally randomly generated by the cloud in order to quickly achieve access. In this case, the security of the two access verification codes is not high. Therefore, after the intranet security device or relay device accesses 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 on at least the first device information. The target verification code is used as the access verification code when the subsequent intranet security device accesses the cloud.

[0091] After the intranet security device is connected to the cloud, the target verification code is sent to the intranet security device. Similarly, after the relay device is connected to the cloud, the cloud can also generate a target verification code based on at least the device information of the relay device and send it to the relay device. The target verification code is generated based on at least the first device information, that is, the target verification code is an access verification code for a single intranet security device. In this way, when the intranet security device needs to reconnect to the network after being disconnected, the user does not need to apply for the access verification code again, but can use the target verification code to access.

[0092] In some implementations, the target verification code may also be generated based on the first device information and the first access verification code, so that it can be distinguished from the first access verification code, because the first access verification code is also generated based on the first device information in some ways, so different verification codes can be used to distinguish between the verification of the first access and subsequent access.

[0093] In the above implementation process, after the intranet security device is connected to the cloud, the cloud can resend a new target verification code to the intranet security device for use when the intranet security device subsequently connects to the cloud, thereby avoiding security issues caused by the leakage of the initial access verification code.

[0094] On the basis of the above embodiment, in order to ensure security, 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 valid period. The first access verification code and the second access verification code are valid within the valid period, and the cloud is used to verify the validity of the first access verification code and the second access verification code.

[0095] It can be understood that, in addition to verifying the accuracy of the first access verification code and the second access verification code as described in the above embodiment, the cloud can also verify the validity of the two access verification codes.

[0096] For example, after the cloud obtains the first access verification code from the first access request or obtains the second access verification code from the second access request, it can first verify the accuracy of the first access verification code and the second access verification code, and then verify the validity if the verification is successful. When the user applies for the first access verification code and the second access verification code from the cloud, the cloud can locally record the validity period of the two verification codes after generating the first access verification code and the second access verification code. The validity period can be a specific period, such as 24 hours, or an expiration time, such as a specific timestamp. Then, when accessing, the cloud will compare the time of the access verification code obtained from the two access requests with the validity period to see if it is still within the validity period. If not, the verification fails, and if so, the verification passes.

[0097] In this case, if the first access verification code expires after the validity period, if the cloud fails the validity verification, it can return the corresponding prompt information to the relay device, and the relay device will forward the prompt information to the intranet security device. At this time, after the intranet security device receives the prompt information, it knows that the access verification code has expired, and the user needs to apply for a new access verification code from the cloud again. The intranet security device can re-use the new access verification code for access. Similarly, when the relay device accesses, if the second access verification code expires, the cloud returns a prompt information. After the relay device receives the prompt information, the user can go to the cloud again to apply for a new access verification code, and the relay device uses the new access verification code to initiate an access request again.

[0098] In addition, since the access verification code is time-limited, after the intranet security device is connected, the cloud can generate a new target verification code for the intranet security device. As described in the above embodiment, the target verification code can be generated based on at least the device information of the intranet security device. The target verification code can be a long-term valid verification code, or its validity period is longer than the validity period of the first access verification code. Similarly, for the second access verification code, after the relay device is connected to the cloud, the cloud can also regenerate a new target verification code for the relay device. The target verification code is generated based on the device information of the relay device.

[0099] In some other implementations, the cloud may also configure corresponding valid times for the first access verification code and the second access verification code, that is, each time access is performed, the valid times are reduced by 1, and when the valid times are 0, the access verification code becomes invalid.

[0100] In the above implementation process, the corresponding validity period is configured for the access verification code, so that the access verification code is valid within the validity period and becomes invalid after the validity period. This can ensure the security of access to the intranet security device and avoid the problem of access verification code leakage and illegal use.

[0101] On the basis of the above embodiment, the communication channel is constructed by the MQTT protocol, and the data transmission between the intranet security device and the cloud follows the MQTT protocol. For the relevant requirements of the MQTT protocol, please refer to the relevant description of the above embodiment, which will not be elaborated here.

[0102] Based on the above embodiment, after the relay device obtains the first access request of the intranet security device, when the relay device is in offline mode, the first access verification code and the first device information are verified. After the verification is passed, 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, so at this time intranet security devices can only communicate between intranets, and intranet security devices communicate with each other through relay devices.

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

[0105] The communication channel between the relay device and the intranet security device can also be a secure data channel, which is built based on the MQTT protocol, and its data transmission specifications are also the specification requirements of the above-mentioned MQTT protocol. The cloud service communication specifications are defined based on the MQTT protocol, involving corresponding specifications such as device access, data transmission, and file transfer. The intranet security device access to the relay device and the relay device access to the cloud service must strictly follow the access specifications. The access specifications of the relay device are consistent with the cloud access specifications, that is, the intranet security device that can access the relay device can also directly access the cloud.

[0106] The communication channel based on the MQTT protocol ensures that the communication between the lightweight access terminal and the cloud is secure by using encryption mechanisms such as TLS / SSL. Encryption protection during data transmission can prevent threats such as data leakage, tampering, and man-in-the-middle attacks.

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

[0108] like Figure 3 As shown, Figure 3 A flowchart of an intranet relay sub-process provided in an embodiment of the present application, which details the processing process of the relay device when the intranet security device is connected to the cloud.

[0109] When the intranet security device initiates an access request, since the cloud and relay devices use the same protocol planning, the destination address of the access request can be 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 during this process. If the access request is initiated to the relay device, the relay device will be divided into three modes for processing.

[0110] One is the cloud service model. First, the relay device needs to be connected to the cloud to ensure that the relay device is trustworthy. After the relay device is successfully connected, it will forward all requests to the relay device (including intranet security device access, file transfer, log reporting, custom data transmission, specified device communication, etc.). After the cloud successfully authenticates the access to the intranet security device, it will open channels such as file transfer, log reporting, custom data transmission, and communication between devices. The relay device can be used to achieve two-way communication between the intranet security device and the cloud, and between the intranet security devices, thereby enabling security services.

[0111] One is the offline mode. In this mode, the relay device will not interact with the cloud. It mainly authenticates the access of the intranet security device through local authentication, such as the access verification code mentioned above, or it can also use the whitelist mechanism for authentication, so that multiple intranet security devices can be allowed to access the relay device. This mode has more functions such as local cross-network intranet security device linkage. The cross-network intranet security devices discover other intranet security devices through the relay device and communicate in both directions. In this mode, the relay device has lightened some of the cloud functions to the local, such as authentication, device management, etc., and is more used in areas completely isolated from the Internet to realize cross-intranet communication of security devices.

[0112] The other is the cascade 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 to other relay devices to achieve 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 for dealing with complex network environments. For example, the intranet needs to go through multiple layers of jumps to communicate with the external cloud.

[0113] Security devices accessed in cloud service mode have opened up the network channel (MQTT channel) between the cloud and intranet security devices. Therefore, the computing power of the cloud can be used to empower intranet security devices, such as rule library updates (intelligence library, virus library), security business hosting (using the advantages of the cloud to achieve security situation analysis and risk blocking), expert services (the cloud provides expert judgment and analysis capabilities), etc., bringing a different 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) deal with different scenarios and complexities. The cloud service mode is mainly used to solve the problem of intranet isolation devices going to the cloud and realize cloud empowerment. The offline mode is mainly a solution for local devices to communicate across intranets. The cascade mode is the most complex of the three modes and is mainly used to solve the problem of devices going to the cloud in more complex network environments.

[0115] The specific process of cloud access can be referred to Figure 4 As shown, Figure 4 The access code or access information mentioned in the above is the access verification code in the above embodiment. Cloud access (only for the above cloud service mode) mainly complies with the MQTT protocol specification. The device carries the access verification code applied 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 Topic related to the MQTT channel to achieve two-way communication between the device and the cloud while ensuring the security of the channel. For the relay devices in the offline and cascade modes, it mainly fully complies with the MQTT protocol specification to keep it consistent with the cloud, and lightens the functions such as cloud access authentication and device management, so that it has the ability to operate independently.

[0116] After the intranet security devices and relay devices are successfully connected to the cloud, they can periodically send heartbeat signals to the cloud to ensure whether the devices are online. If the cloud fails to receive heartbeat signals for a long time (such as a certain period of time), the device is considered offline. In this way, a list of continuously online devices is maintained to facilitate device discovery, communication between devices, and online monitoring of devices.

[0117] In some embodiments, the validity period of the first access verification code and the second access verification code can be associated with the online time of the device. For example, when applying for the first access verification code and the second access verification code in the cloud, it is not necessary to first assign a fixed validity period to the two access verification codes, but to determine whether the two access verification codes are valid based on whether the device is online. For example, at the first access, when verifying the validity, they are all considered valid, but if the cloud detects that the relay device or the intranet security device is offline, the corresponding first access verification code and the second access verification code can be changed to an invalid state in the cloud, so that the previous access verification code cannot be reused for access again (validity verification fails), and a new access verification code needs to be re-applied for access.

[0118] The following is a specific example. Figure 5 shown.

[0119] Relay device AB` is connected to the cloud using the cloud service model, and relay devices C` and D` are connected to relay device AB` in a cascaded manner. Relay devices AB`, C`, and D` all expose the same services as the cloud MQTT, and have the same communication specifications.

[0120] Device C is connected to relay device C` based on the communication specification (MQTT access specification), device D is connected to relay device D`, and devices A and B are connected to relay device AB`. After successful access, users can view the corresponding access devices in the cloud, and only relay devices can communicate between intranet A, intranet B, and intranet C, and their intranet security devices cannot be directly interconnected.

[0121] If permissions allow, devices A to D can discover each other based on three relay devices, for example, cross-network communication between device B and device D can be achieved (need to comply with the MQTT device communication specification).

[0122] Since all devices A to D have been connected to the cloud service, they can enjoy corresponding cloud services, such as rule library upgrades, expert services, hosting services, etc., to empower the security devices in the user's intranet.

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

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

[0125] Security service data can refer to data that enables security for intranet security devices, so that intranet security devices can enjoy cloud services, such as rule base upgrades, security service hosting, expert services, etc. The security service data sent from the cloud can be forwarded to the relay device first, and then forwarded by the relay device to the corresponding intranet security device.

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

[0127] The intranet security device is connected to the cloud through the access method in the above embodiment. The specific implementation process can refer to the relevant description of the above embodiment. 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 apparatus 300 provided in an embodiment of the present application. The apparatus 300 may be a module, program segment or code on an electronic device (such as a relay device). It should be understood that the apparatus 300 is similar to the above Figure 2 The method embodiment corresponds to 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 above description. To avoid repetition, the detailed description is appropriately omitted here.

[0129] Optionally, the device 300 includes:

[0130] A request acquisition module 310 is used to acquire a first access request of an intranet security device, wherein the access request includes a first access verification code and 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 passed, create a communication channel between the intranet security device and the cloud.

[0132] Optionally, the request sending module is also used to determine whether the relay device is connected to the cloud; if not, sending a second access request to the cloud, the second access request including a second access verification code and 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 the verification is passed, 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 valid period, and the first access verification code and the second access verification code are valid within the valid 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 a target verification code sent by the cloud, wherein the target verification code is generated based on at least the first device information, and the target verification code is used as an access verification code when the intranet security device subsequently accesses the cloud.

[0136] Optionally, the communication channel is constructed based on the MQTT protocol, and the data transmission between the intranet security device and the cloud complies with 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 an offline mode; after the verification is passed, a communication channel is established 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 device 400 provided in an embodiment of the present application. The device 400 may be a module, program segment or code on an electronic device (such as a relay device). It should be understood that the device 400 is similar to the above Figure 6 The method embodiment corresponds to 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 above description. To avoid repetition, the detailed description is appropriately omitted here.

[0140] Optionally, the device 400 includes:

[0141] The data receiving module 410 is used to receive the security service 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 is connected to the cloud through the above-mentioned device access method.

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

[0144] Please refer to Fig. 9 , Fig. 9 A structural diagram of an electronic device for executing a device access method or a device communication method provided in an embodiment of the present 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. Among them, the communication bus 540 is used to realize the connection communication between these components. Among them, the communication interface 520 of the device in the embodiment of the present application is used to communicate signaling or data with other node devices. The memory 530 can be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 530 can optionally also be at least one storage device located away from the aforementioned processor. Computer-readable instructions are stored in the memory 530. When the computer-readable instructions are executed by the processor 510, the electronic device executes the above-mentioned Figure 2 or Figure 6 The method process is shown.

[0145] Understandably, Fig. 9 The structure shown is for illustration only, and the electronic device may also include Fig. 9 More or fewer components as shown, or with Fig. 9 Different configurations are shown. Fig. 9 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

[0146] The present application embodiment provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the following is performed: Figure 2 or Figure 6 The method process in the method embodiment shown is executed by the electronic device.

[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. When the program instructions are executed by a computer, the computer can perform the methods provided by the above method embodiments, for example, including:

[0148] Obtaining 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, 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 passed, a communication channel is created between the intranet security device and the cloud.

[0150] To summarize, the embodiments of the present 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 passed will a communication channel be established between the cloud and the intranet security device. In this way, the intranet security device can be securely verified to ensure the security of subsequent communications.

[0151] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0152] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0154] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0155] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A device access method, characterized in that: Applied to a relay device, the method comprises: Obtaining 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 passed, a communication channel is created between the intranet security device and the cloud.

2. The method according to claim 1, characterized in that Before sending the access request to the cloud, the method further includes: Determining whether the relay device is connected to the cloud; If not, a second access request is sent to the cloud, wherein the second access request includes a second access verification code and 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, and after the verification is passed, 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, and the first access verification code and the second access verification code are configured with a valid time period. The first access verification code and the second access verification code are valid within the valid time period, and 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: After sending the first access request to the cloud, the method further includes: Receive a target verification code sent by the cloud, where the target verification code is generated based on at least the first device information, and the target verification code is used as an access verification code when the intranet security device subsequently accesses the cloud.

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

6. The method according to claim 1, characterized in that After obtaining the first access request of the intranet security device, the method further includes: When the relay device is in an offline mode, verifying the first access verification code and the first device information; After the verification is passed, a communication channel between the intranet security device and the relay device is created.

7. 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 comply with relevant specifications of the MQTT protocol, and the communication channel between the intranet security device and the cloud is constructed after access through the device access method described in any one of claims 1 to 6; The relay device, the intranet security device and the cloud are used to verify the standardization of the received communication data.

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

9. The communication system according to claim 7, characterized in that: There are multiple relay devices, and the multiple relay devices form a cascade mode to achieve communication between the intranet security device and the cloud.

10. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the method according to any one of claims 1 to 6 is executed.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is executed.

12. A computer program product, characterized in that The method comprises computer program instructions, and when the computer program instructions are read and executed by a processor, the method according to any one of claims 1 to 6 is executed.

Images