A task flow transfer and permission verification method based on a distributed soft bus

Abstract

The present application relates to the technical field of soft bus, and particularly relates to a task flow transfer and permission verification method based on a distributed soft bus, which comprises the following steps: a sending end extracts structured elements from a confidential task and assigns a secret level label, and then sends the task to a soft bus system; the sending end is subjected to pre-checking, and after the checking is passed, a flow transfer operation is initiated; a corresponding receiving end is selected according to the secret level label, and two-level checking is performed on the receiving end, and after the checking is passed, the confidential task is sent to the receiving end. In view of the fact that the distributed soft bus system in the prior art does not have corresponding authentication and control links when processing confidential tasks, by introducing pre-checking of the sending end and reading the corresponding secret level label, authentication and verification of the sending side and the confirmation process of the receiving end are realized, and by performing two-level checking on the receiving end and establishing a point-to-point encryption channel, the problem that the original distributed soft bus system is difficult to control the sending range is avoided, and good security effect is achieved.

Description

Technical Field

[0001] This invention relates to the field of soft bus technology, and specifically to a method for task flow and permission verification based on a distributed soft bus. Background Technology

[0002] With the explosive growth of the Internet of Things (IoT) and multimodal smart terminals, the traditional computing paradigm based on a single physical entity is rapidly evolving towards a distributed environment with multi-device collaboration. Distributed soft bus, as a core underlying technology for communication between heterogeneous devices, aims to break down physical hardware boundaries and achieve seamless, efficient, and secure interconnection between multiple devices. By shielding the complexity of the underlying physical network, distributed soft bus provides a unified and transparent communication foundation for upper-layer distributed applications. Its main features include: simplified discovery and self-organizing networking capabilities, dynamic multi-path routing, timing synchronization, and transmission optimization. Because it can achieve self-organizing networking and intelligent transmission processes for heterogeneous devices, it is widely used in various heterogeneous device communications.

[0003] For example, patent application CN201310706996.3 discloses a cross-platform soft bus communication device and soft bus. The device includes: a communication thread unit for maintaining two different connections on the same service port of two networks; a thread pool container for managing the communication thread unit; a data queue buffer unit for buffering received and transmitted data queues; a connection processor for preprocessing the data queues; and a service adapter for classifying the two different connections on the same service port of the two networks and assisting in network switching when one network segment is abnormal. Through the communication thread unit, thread pool container, data queue buffer unit, connection processor, and service adapter, a unified communication method is achieved, making maintenance easier.

[0004] For example, patent application CN202511270981.6 discloses a communication soft bus and a UAV communication system. The communication soft bus includes a transmission layer, a distribution layer, a link management module, an endpoint management module, a data forwarding module, an address management module, a routing module, a data transmission module, and an API layer. Among them, the routing module and the data forwarding module realize seamless forwarding between protocols, simplifying the communication implementation between different computing units, especially in complex scenarios involving forwarding. The API layer provides a unified data communication interface, shielding the differences between different underlying communication protocols, making application software development simpler, reducing development complexity, and improving development efficiency. This communication soft bus can also automatically identify and configure the network topology, enabling application software to be flexibly deployed on different devices and locations without the need for manual configuration of communication protocols, improving deployment flexibility and software code reusability.

[0005] However, in actual implementation, the inventors found that such technical solutions are usually designed around civilian open scenarios, and their message transmission process is usually broadcast-style, without separating civilian open interconnection functions and lacking functions such as access control for classified equipment. Summary of the Invention

[0006] To address the aforementioned problems in existing technologies, a task flow and permission verification method based on a distributed soft bus is provided.

[0007] The specific technical solution is as follows: A method for task flow and permission verification based on a distributed soft bus includes: Step S1: When a classified task is created, the sending end extracts the structured elements of the classified task and assigns a classification level label, and then sends it to the soft bus system; Step S2: The soft bus system performs a pre-verification on the transmitting end. After the verification is passed, it initiates a transfer operation and proceeds to step S3. Step S3: The soft bus system selects the corresponding receiving end according to the security level label, and performs two-level verification on the receiving end. After the verification is passed, the classified task is sent to the receiving end.

[0008] On the other hand, step S1 includes: Step S11: Obtain the classified task and parse it to obtain the corresponding structured elements; Step S12: Extract classified data from the structured elements, and perform semantic matching based on the classified data to obtain the text security level; Step S13: Match the corresponding security level tag according to the security level of the text and then send it to the soft bus system.

[0009] On the other hand, the structured elements include core service instructions, classified datasets, associated resource permissions, execution environment requirements, lifecycle duration, permitted terminal range, and permitted user range.

[0010] On the other hand, step S2 includes: Step S21: Perform user-level verification on the user operating the sending end to determine whether the user has the corresponding permissions; If so, proceed to step S22; If not, suspend the transfer process; Step S22: Perform device-level verification on the device information of the sending end to determine whether the sending end has the corresponding permissions; If so, proceed to step S23; If not, suspend the transfer process; Step S23: Perform task-level verification on the classified task to determine whether the classified task has the corresponding permissions; If so, proceed to step S3; If not, the transfer process will be suspended.

[0011] On the other hand, the user-level verification includes verifying the confidentiality level, identity certificate validity, and operation permissions of the operating user; The device-level verification includes verifying the confidentiality compliance status, trusted authentication status, whether it is within the allowed network access range, and whether the disabled function is enabled at the sending end. The task-level verification includes verifying the legality of the task's security level, the validity period of its lifecycle, and the integrity of its hash.

[0012] On the other hand, step S3 includes: Step S31: Select the corresponding receiving end according to the security classification label and the range of allowed transfer terminals in the classified task, and establish a point-to-point encrypted channel; Step S32: Send a transfer request to the receiving end and perform a security level matching verification. When the security level matching verification passes, proceed to step S33. Step S33: Verify the receiving user's permission for the operation of the receiving end. If the receiving user's permission verification is successful, proceed to step S34. Step S34: Transmit the classified task via the point-to-point encrypted channel, and destroy the point-to-point encrypted channel and local data after the transmission is completed.

[0013] On the other hand, in step S32, the security level matching verification includes verifying the security level of the receiving end, whether it is in a trusted and compliant state, and whether it is included in the blacklist. In step S33, the receiving user permission verification includes verifying the user's confidentiality level, task receiving and execution permissions, operation event authorization scope, and no record of illegal operation.

[0014] On the other hand, the point-to-point encrypted channel is encrypted using the national cryptographic algorithm.

[0015] On the other hand, during the execution of step S3, the soft bus system also monitors for abnormal situations and cuts off the transmission process when such abnormal situations occur.

[0016] On the other hand, during the execution of steps S1 to S4, the soft bus system collects and stores audit log records.

[0017] The above technical solution has the following advantages or beneficial effects: To address the lack of authentication and control mechanisms in existing distributed soft bus systems when handling classified tasks, this paper introduces pre-verification of the sending end and reading of the corresponding security level tag to achieve authentication and verification of the sending side and confirmation of the receiving end. Furthermore, by performing two-level verification on the receiving end and establishing a point-to-point encrypted channel, the problem of the original distributed soft bus system's inability to control the transmission range is avoided, thus achieving a better level of confidentiality. Attached Figure Description

[0018] Embodiments of the invention will be described more fully with reference to the accompanying drawings. However, the drawings are for illustration and explanation only and do not constitute a limitation on the scope of the invention.

[0019] Figure 1 This is an overall schematic diagram of an embodiment of the present invention; Figure 2 This is a schematic diagram of step S1 in an embodiment of the present invention; Figure 3 This is a schematic diagram of step S2 in an embodiment of the present invention; Figure 4 This is a schematic diagram of step S3 in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0022] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the scope of the invention.

[0023] This invention includes: A method for task flow and permission verification based on a distributed soft bus, such as Figure 1 As shown, it includes: Step S1: When a classified task is created, the sending end extracts the structured elements of the classified task and assigns a classification label, and then sends it to the soft bus system. Step S2: The soft bus system performs a pre-verification on the transmitting end. After the verification is passed, it initiates a transfer operation and proceeds to step S3. Step S3: The soft bus system selects the corresponding receiving end according to the security classification label and performs two-level verification on the receiving end. After the verification is passed, the classified task is sent to the receiving end.

[0024] Specifically, addressing the lack of authentication and control mechanisms in existing distributed soft bus systems when handling classified tasks, this paper introduces pre-verification of the sending end and reading of the corresponding security level tag to achieve authentication and verification of the sending side and confirmation of the receiving end. Furthermore, by performing two-level verification on the receiving end and establishing a point-to-point encrypted channel, the problem of the original distributed soft bus system's inability to control the transmission range is avoided, thus achieving a better level of confidentiality.

[0025] In practice, the above-mentioned task flow and permission verification methods are mainly applied to distributed soft bus systems to enable the flow of confidential tasks among communication devices in heterogeneous networks, such as in government departments, medical, and power industries.

[0026] The distributed soft bus system achieves its security through kernel-level modifications to the standard distributed soft bus. This includes disabling non-classified functions such as civilian device discovery, public network access, and third-party application calls, granting access only to user terminals on the classified whitelist. A decentralized, point-to-point, LAN-closed dedicated classified soft bus network is constructed. All terminals entering the network must complete classified compliance testing, hardware trusted authentication, and identity information registration in advance. Terminals that fail authentication cannot be discovered by the bus or access the communication link, thus blocking unauthorized access risks from the ground up. Subsequently, tiered registration and permission baseline configuration are implemented for terminals and user accounts. This includes classifying classified terminals and operating users into four levels—Top Secret, Confidential, Secret, and Internal—according to the classified information system's hierarchical protection requirements. The system simultaneously binds the terminal's unique hardware identifier, user identity certificate, operating permission baseline, access area range, and permission validity period. The tiered permission baseline is synchronized to the local trusted cache of all soft bus nodes, enabling real-time local permission verification without relying on a central server, thus adapting to classified offline networking scenarios.

[0027] Based on this, the distributed soft bus system itself maintains the original heterogeneous network access and automatic discovery features to enable the transfer of classified tasks.

[0028] Before communication begins, the sending end in the soft bus system first creates a corresponding classified task and encapsulates it in a structured manner. This includes breaking down the task into core instructions, classified datasets, associated resource permissions, execution environment requirements, lifecycle duration, allowed terminal range, and allowed user range. Scattered and unlabeled classified data is prohibited from entering the soft bus to ensure the controllability of task flow. Then, the content of the classified dataset is matched locally to determine the actual classification level before initiating the corresponding classified task flow process to the soft bus system.

[0029] Subsequently, the soft bus system performs three levels of verification on the sending end to verify whether the device, the operating user, and the task meet the relevant permissions for the transfer of classified tasks. Only after passing the verification is the corresponding user device selected as the receiving end according to the scope of allowed operating users included in the classified task. The receiving end is then verified at two levels. After the verification is passed, a point-to-point encrypted channel is established to transfer the classified task. After the transmission is completed, the encrypted channel is closed and the data in the cache is destroyed.

[0030] During the above process, the soft bus system establishes irreversible audit log records for the entire operation process, including all stages and nodes of task initiation, flow verification, data transmission, terminal switching, execution, and termination destruction. All of these operations automatically generate unalterable and undeletable audit logs, synchronously recording core information such as operator, terminal identifier, operation time, task security level, operation content, and verification results. The logs are synchronously backed up to the classified audit server, with a local copy retained, to meet the audit traceability requirements of classified information systems.

[0031] Meanwhile, during the task flow, if any abnormal situation occurs, such as invalid permissions, mismatched security level, offline terminal, abnormal link, illegal tampering, or unauthorized operation, the soft bus kernel will immediately force interrupt the transmission, destroy the cached data in the transmission, lock the task permissions, and trigger an alarm. No manual intervention is required throughout the process, eliminating the risk of partial leakage of classified data.

[0032] After the task lifecycle ends, the system automatically reclaims all associated permissions of all terminals, destroys all temporary cached data of all terminals, and archives the task's entire process log, completely removing all cross-terminal call permissions related to the task, realizing closed-loop management of the entire task lifecycle and eliminating the risk of leakage afterward.

[0033] In one embodiment, such as Figure 2 As shown, step S1 includes: Step S11: Obtain the classified task and parse it to get the corresponding structured elements; Step S12: Extract classified data from structured features, and perform semantic matching based on the classified data to obtain the text classification level; Step S13: Match the corresponding security level tag according to the text security level and then send it to the soft bus system.

[0034] Specifically, in order to achieve a better classification process, in this embodiment, the corresponding user account of the user device is first divided into four levels: top secret, confidential, secret, and internal. The unique identifier of the terminal hardware, user identity certificate, operation permission baseline, access area range, and permission validity period are bound simultaneously. Then, the classified tasks that need to be transferred are received from the user account and uploaded to the sending end.

[0035] For classified tasks, the first step is to analyze and break them down to obtain the corresponding structured elements.

[0036] The structured elements include core mission instructions, classified datasets, associated resource permissions, execution environment requirements, lifecycle duration, permitted terminal range, and permitted user range.

[0037] Subsequently, classified dataset fields are extracted from structured elements for text matching. This process follows a pre-maintained hot word dictionary, where matching results are obtained by searching for corresponding hot words, and the actual security level of the file is determined as the text security level based on the high-frequency words.

[0038] After obtaining the text security level, the system automatically matches the corresponding security level based on the level of classified data and the sensitivity of the task, generates an unalterable and encrypted task security level label, and hash-binds the label to the task body. Any unauthorized modification to the task content or security level label will cause the hash verification to fail, and the failed task will be automatically destroyed by the soft bus kernel. At the same time, the system locks the task with the minimum authorized permissions, retaining only the operation permissions necessary for the task to execute, and eliminating the risk of leakage caused by excessive permission configuration.

[0039] In one embodiment, such as Figure 3 As shown, step S2 includes: Step S21: Perform user-level verification on the sending end user to determine whether the user has the corresponding permissions; If so, proceed to step S22; If not, suspend the transfer process; Step S22: Perform device-level verification on the device information of the sending end to determine whether the sending end has the corresponding permissions; If so, proceed to step S23; If not, suspend the transfer process; Step S23: Perform task-level verification on classified tasks to determine whether the classified tasks have the corresponding permissions; If so, proceed to step S3; If not, the transfer process will be suspended.

[0040] User-level verification includes verifying the confidentiality level of the user, the validity of their identity certificate, and their operating permissions; Device-level verification includes verifying the confidentiality compliance status, trusted authentication status, whether it is within the allowed network access range, and whether the disabled function is enabled at the sending end; Task-level verification includes verifying the legality of the task classification level, the lifecycle validity period, and the hash integrity of classified tasks.

[0041] Specifically, in order to achieve effective verification of the sending end and avoid lateral penetration through the bus system, this embodiment adopts a three-level verification mechanism to perform pre-access permission verification and legality verification on the sending end. If the verification fails, the data is directly blocked to prevent it from entering the network.

[0042] The three-level verification mechanism includes user-level verification, device-level verification, and task-level verification. Each level of verification must pass before the data can proceed to the next level. If a level fails, the data is blocked.

[0043] User-level verification includes verifying the confidentiality level, identity certificate validity, and operation permissions of the user, thereby determining whether the user account currently logged in on the sending end has the authority to initiate and transfer the confidential task. Device-level verification includes verifying the confidentiality compliance status, trusted authentication status, whether it is within the allowed network access range, and whether the disabled function is enabled, thereby determining whether the device status of the sending end is satisfactory. Task-level verification includes verifying the legality of the task classification level, the lifecycle validity period, and the hash integrity of classified tasks, thereby determining that the task has not been tampered with or expired.

[0044] After completing the above three-level verification, the pre-verification of the sending end is completed, and the corresponding receiving end can be further filtered.

[0045] In one embodiment, such as Figure 4 As shown, step S3 includes: Step S31: Select the corresponding receiving end and establish a point-to-point encrypted channel based on the security classification label and the range of allowed transfer terminals in the classified task; Step S32: Send a transfer request to the receiving end and perform a security level matching verification. If the security level matching verification passes, proceed to step S33. Step S33: Verify the receiving user's permission for the operation at the receiving end. If the receiving user's permission verification is successful, proceed to step S34. Step S34: Transmit the classified task via a point-to-point encrypted channel, and destroy the point-to-point encrypted channel and local data after the transmission is completed.

[0046] Specifically, after completing the pre-verification process, the soft bus kernel automatically selects compliant receiving terminals based on the task's security level, the allowed transfer range, and the security level of the receiving terminal.

[0047] The screening process includes several criteria, including that the user account's security level is higher than the task's security level in the security level label, the receiving device has completed registration and network access, the receiving device is in a trusted state, and it is within the range of allowed transfer terminals for this classified task.

[0048] Subsequently, a point-to-point encrypted channel is established for the selected user equipment as the receiving end. During this process, low-security terminals cannot receive any signals from high-security tasks, achieving security isolation at the routing layer. At the same time, by establishing a dedicated point-to-point encrypted communication channel and using national cryptographic algorithms for end-to-end encryption, broadcast transmission and intermediate node forwarding are prohibited, ensuring that data is transmitted end-to-end only between the initiating and receiving ends.

[0049] Once a point-to-point encrypted channel is established, the receiving end receives the transfer request sent by the soft bus system and performs security level matching and verification locally.

[0050] The security classification matching verification includes verifying the security classification level of the receiving end, whether it is in a trusted and compliant state, and whether it is on a blacklist. The receiving end itself has a corresponding security classification level, and the receiving end uses relevant monitoring software to detect the device's external security and running processes to determine whether the device is in a trusted and compliant state. Furthermore, the soft bus system also records corresponding blacklist information, and determines whether it is on the blacklist by comparing the receiving end's MAC address. Only when all checks pass is the request allowed to proceed to the next verification step; otherwise, the transfer request is discarded without returning any response information to avoid leaking information related to classified tasks.

[0051] In step S33, the receiving user permission verification includes verifying the user's confidentiality level, task receiving and execution permissions, operation event authorization scope, and no record of illegal operation.

[0052] This process mainly verifies the user's confidentiality level by reading the user account permissions of the operating user, and determines whether the user account has the authority to receive and execute tasks by comparing the scope of allowed users in the confidential task with the user account, and determines whether the user is within the authorized scope of the operation event based on the pre-maintained user account operation events, and compares it with the corresponding violation operation records of the user account to determine whether the user has violated the rules.

[0053] The relevant transfer process will only proceed after the above verification is passed.

[0054] This step employs a dynamic verification mechanism. Once user permissions are changed, levels are downgraded, or accounts are locked, the verification rules take effect immediately without requiring a terminal restart or synchronized configuration, ensuring real-time access control.

[0055] In one embodiment, the point-to-point encrypted channel is encrypted using the national cryptographic algorithm.

[0056] In one embodiment, during the execution of step S3, the soft bus system also monitors for abnormal situations and cuts off the transmission process when an abnormal situation occurs.

[0057] Specifically, after both levels of verification pass, the soft bus transmits the classified task, supporting data, and access lock to the receiving end through a dedicated encrypted channel with a latency of less than 10ms. After the transmission is completed, the local task data at the initiating end is automatically encrypted and stored or completely destroyed, without retaining any cache or being stored on the ground. At the same time, it completes a seamless switching of the task execution environment across terminals, and the receiving end directly continues the task execution status without the need to log in again, reload, or repeat the configuration, thus realizing real-time seamless handover of classified tasks.

[0058] In one embodiment, during the execution of steps S1-S4, the soft bus system collects and stores audit log records.

[0059] Specifically, in the above process, the soft bus system establishes irreversible audit log records for the entire operation process, including all stages and nodes of task initiation, flow verification, data transmission, terminal switching, execution, and termination destruction. All of these operations automatically generate unalterable and undeletable audit logs, synchronously recording core information such as the operator, terminal identifier, operation time, task security level, operation content, and verification results. The logs are synchronously backed up to the classified audit server, with a local copy retained, to meet the audit traceability requirements of classified information systems.

[0060] Meanwhile, during the task flow, if any abnormal situation occurs, such as invalid permissions, mismatched security level, offline terminal, abnormal link, illegal tampering, or unauthorized operation, the soft bus kernel will immediately force interrupt the transmission, destroy the cached data in the transmission, lock the task permissions, and trigger an alarm. No manual intervention is required throughout the process, eliminating the risk of partial leakage of classified data.

[0061] After the task lifecycle ends, the system automatically reclaims all associated permissions of all terminals, destroys all temporary cached data of all terminals, and archives the task's entire process log, completely removing all cross-terminal call permissions related to the task, realizing closed-loop management of the entire task lifecycle and eliminating the risk of leakage afterward.

[0062] Those skilled in the art will understand that various aspects, or possible implementations of various aspects, of the present invention can be embodied as systems, methods, or computer program products. Therefore, various aspects, or possible implementations of various aspects, of the present invention can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, etc.), or embodiments combining software and hardware aspects, all collectively referred to herein as "circuit," "module," or "system." Furthermore, various aspects, or possible implementations of various aspects, of the present invention can take the form of computer program products, which are computer instructions stored in memory.

[0063] The memory can be a computer-readable signal medium or a computer-readable storage medium. Computer-readable storage media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any suitable combination thereof, such as random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, and portable read-only memory (CD-ROM).

[0064] A processor in a computer reads computer instructions stored in memory, enabling the processor to execute the functional actions specified in each step or combination of steps in a flowchart; and to generate means for implementing the functional actions specified in each block or combination of blocks in a flowchart.

[0065] It should be understood that a processor in a computer can be understood as one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components used to execute the aforementioned computer instructions.

[0066] Computer instructions may be executed entirely on the user's local computer, partially on the user's local computer, as a separate software package, partially on the user's local computer and partially on a remote computer, or entirely on a remote computer or server. It should also be noted that in some alternative implementations, the functions indicated by the steps in the flowchart or the blocks in the block diagram may not occur in the order shown in the diagram. For example, depending on the functions involved, two consecutive steps or blocks may actually be executed approximately simultaneously, or these blocks may sometimes be executed in reverse order.

[0067] Of course, in practical applications, the various components of a computer system are coupled together through a bus system. The bus system is used to enable communication and connection between these components. In addition to the data bus, the bus system also includes a power bus, a control bus, and a status signal bus.

[0068] The above are merely preferred embodiments of the present invention and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should recognize that any equivalent substitutions and obvious changes made based on the description and illustrations of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for task flow and permission verification based on a distributed soft bus, characterized in that, include: Step S1: When a classified task is created, the sending end extracts the structured elements of the classified task and assigns a classification level label, and then sends it to the soft bus system; Step S2: The soft bus system performs a pre-verification on the transmitting end. After the verification is passed, it initiates a transfer operation and proceeds to step S3. Step S3: The soft bus system selects the corresponding receiving end according to the security level label, and performs two-level verification on the receiving end. After the verification is passed, the classified task is sent to the receiving end.

2. The task flow and permission verification method according to claim 1, characterized in that, Step S1 includes: Step S11: Obtain the classified task and parse it to obtain the corresponding structured elements; Step S12: Extract classified data from the structured elements, and perform semantic matching based on the classified data to obtain the text security level; Step S13: Match the corresponding security level tag according to the security level of the text and then send it to the soft bus system.

3. The task flow and permission verification method according to claim 1, characterized in that, The structured elements include core task instructions, classified datasets, associated resource permissions, execution environment requirements, lifecycle duration, permitted terminal range, and permitted user range.

4. The task flow and permission verification method according to claim 1, characterized in that, Step S2 includes: Step S21: Perform user-level verification on the user operating the sending end to determine whether the user has the corresponding permissions; If so, proceed to step S22; If not, suspend the transfer process; Step S22: Perform device-level verification on the device information of the sending end to determine whether the sending end has the corresponding permissions; If so, proceed to step S23; If not, suspend the transfer process; Step S23: Perform task-level verification on the classified task to determine whether the classified task has the corresponding permissions; If so, proceed to step S3; If not, the transfer process will be suspended.

5. The task flow and permission verification method according to claim 4, characterized in that, The user-level verification includes verifying the confidentiality level, identity certificate validity, and operation permissions of the operating user; The device-level verification includes verifying the confidentiality compliance status, trusted authentication status, whether it is within the allowed network access range, and whether the disabled function is enabled at the sending end. The task-level verification includes verifying the legality of the task's security level, the validity period of its lifecycle, and the integrity of its hash.

6. The task flow and permission verification method according to claim 1, characterized in that, Step S3 includes: Step S31: Select the corresponding receiving end according to the security classification label and the range of allowed transfer terminals in the classified task, and establish a point-to-point encrypted channel; Step S32: Send a transfer request to the receiving end and perform a security level matching verification. When the security level matching verification passes, proceed to step S33. Step S33: Verify the receiving user's permission for the operation of the receiving end. If the receiving user's permission verification is successful, proceed to step S34. Step S34: Transmit the classified task via the point-to-point encrypted channel, and destroy the point-to-point encrypted channel and local data after the transmission is completed.

7. The task flow and permission verification method according to claim 6, characterized in that, In step S32, the security level matching verification includes verifying the security level of the receiving end, whether it is in a trusted and compliant state, and whether it is included in the blacklist. In step S33, the receiving user permission verification includes verifying the user's confidentiality level, task receiving and execution permissions, operation event authorization scope, and no record of illegal operation.

8. The task flow and permission verification method according to claim 6, characterized in that, The point-to-point encrypted channel is encrypted using the national cryptographic algorithm.

9. The task flow and permission verification method according to claim 6, characterized in that, During the execution of step S3, the soft bus system also monitors for abnormal situations and cuts off the transmission process when such abnormal situations occur.

10. The task flow and permission verification method according to claim 1, characterized in that, During the execution of steps S1 to S4, the soft bus system collects and stores audit log records.

Images