Risk management methods and target components, project system front-end, cloud system

Abstract

This specification provides a risk handling method, a target component, a project system front-end, and a computing device. The risk handling method is applied to the target component of the project system front-end. The target component records a user's identity identifier, which is generated by the project system front-end calling the target component to collect user information from various project platforms. The risk handling method includes: receiving project operations from a target user, wherein the project operation carries operation attributes and the target user's target user information; determining the target user's target identity identifier based on the target user information; identifying whether the project operation is a risky operation based on the operation attributes and the target identity identifier; and performing risk handling on the project operation if it is a risky operation. This achieves unified authentication and management of user identities across different project platforms and handles risky user operations, ensuring the security and reliability of the management systems for each project platform.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a risk management method, target components, project system front-end, and cloud system. Background Technology

[0002] With the development of science and technology, the widespread adoption of enterprise information and digital application platforms has made cross-platform user behavior management an important requirement.

[0003] Currently, user behavior management technology primarily relies on independently configured authentication and access control systems within each project platform. Users log in to multiple project platforms, and each platform system logs only the user's actions within that specific platform, providing basic risk management functions through its own complex permission rules. To enhance security, multi-factor authentication is used to verify user identity when logging into the project platform.

[0004] However, while these technologies offer some assurance of security and compliance, they still have limitations in practical applications. Each project platform has its own unique control system, which is complex to configure and maintain, requiring specialized technical personnel. Furthermore, poor interoperability between different platforms leads to severe information silos, impacting overall management efficiency. Therefore, a more flexible, efficient, and easily integrated cross-platform risk management method is urgently needed. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a risk management method. One or more embodiments of this specification simultaneously relate to a target component, a project system front-end, a computing device, a computer-readable storage medium, and a computer program product, to address technical deficiencies in the prior art.

[0006] This specification provides a risk management method in one embodiment, applied to a target component of a project system front-end. The target component records user identity identifiers, which are generated by the project system front-end calling the target component to collect user information from various project platforms. The method includes:

[0007] Receive project operations from the target user, where the project operations carry operation attributes and target user information;

[0008] Determine the target user's target identity identifier based on the target user information;

[0009] Based on the operation attributes and target identity, identify whether a project operation is a risky operation;

[0010] When a project operation is considered a risky operation, risk management measures should be implemented for that operation.

[0011] By recording user identity identifiers through target components on the front end of the project system, and determining the target identity identifier based on the carried operation attributes and target user information when receiving project operations from target users, unified authentication and management of user identities across different project platforms is achieved. The system identifies whether a project operation is a risky operation based on operation attributes and target identity identifiers, and performs targeted risk handling for confirmed risky operations. This ensures effective recording and management of cross-platform user behavior, accurately handles risky user operations, and takes timely measures when risky project operations are detected, thereby guaranteeing the security and reliability of the management systems for each project platform. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the system architecture of a project system front-end provided in one embodiment of this specification;

[0013] Figure 2 This is a flowchart illustrating a risk management method provided in one embodiment of this specification;

[0014] Figure 3 This is a schematic diagram of the button configuration rules for operation exemption permissions in a risk handling method provided in one embodiment of this specification;

[0015] Figure 4 This is a schematic diagram of the structure of a technical support plug-in provided in one embodiment of this specification;

[0016] Figure 5 This is a schematic diagram illustrating the initialization process of the technical safeguard plug-in in a risk management method provided in one embodiment of this specification;

[0017] Figure 6 This is a flowchart illustrating the processing procedure of a risk management method provided in one embodiment of this specification;

[0018] Figure 7 This is a schematic diagram of the structure of a target component provided in one embodiment of this specification;

[0019] Figure 8 This is a schematic diagram of the structure of a project front-end system provided in one embodiment of this specification;

[0020] Figure 9 This is a schematic diagram of the structure of a target component and a target sub-component in a project front-end system according to one embodiment of this specification;

[0021] Figure 10 This is a schematic diagram of the structure of a cloud system provided in one embodiment of this specification;

[0022] Figure 11 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0023] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0024] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0025] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0026] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0027] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0028] Extensible Markup Language (XML): Extensible Markup Language (XML) is a simple, platform-independent text format used to store and transmit data, allowing users to define their own tags to describe the structure and meaning of data.

[0029] Hypertext Markup Language (HTML) is a standard markup language used to create web pages, define their structure and content, and is often used in conjunction with JavaScript to build interactive internet pages.

[0030] XML Path Language (XPath) is a language used to locate and select nodes in XML or HTML documents, using path expressions to select specific elements, attributes, or text.

[0031] Document Object Model (DOM): The Document Object Model (DOM) is a programming interface used to represent and manipulate the structure of HTML and XML documents. It represents the document as a tree of nodes, allowing developers to dynamically access and modify the document content through programming languages.

[0032] Markov Chain Model: The Markov chain model is a stochastic process model in which the state of the system at any given time depends only on the previous state and is independent of earlier states. It is often used to predict the behavior of sequential data.

[0033] Hash Algorithm: A hash algorithm is an algorithm that maps data of arbitrary length to a fixed-length value (hash value). It is widely used in data indexing, cryptography, and data integrity checking.

[0034] With the development of science and technology and the widespread adoption of enterprise information and digital application platforms, cross-platform user behavior management has become a crucial requirement. Currently, user behavior management technology primarily relies on independently configured identity verification and access control systems within each project platform. Users log in to multiple project platforms, and each platform system only logs the user's actions on that specific platform, providing basic risk management functions through its own complex permission rules. Simultaneously, to enhance security, multi-factor authentication is used to verify user identity when logging into project platforms.

[0035] However, while these technologies ensure security and compliance to a certain extent, they still have some limitations in practical applications. Each project platform has its own unique management system, which is complex to configure and maintain, requiring specialized technical personnel. Furthermore, poor interoperability between different platforms leads to severe information silos, impacting overall management efficiency.

[0036] In practical applications, when users log in to various project platforms through the project system frontend, they need to use different user information for each platform. In this case, basic risk management relies solely on the complex permission rules configured on each platform. Once a user switches platforms or performs cross-platform operations, monitoring and risk management of user actions are lost. To address this issue, this specification proposes an architecture that sets up target components in the project system frontend. See [link to documentation]. Figure 1 , Figure 1 This specification illustrates a schematic diagram of a project system front-end architecture according to one embodiment. Figure 1 As shown: By setting a target component in the front end of the project system, when users log in to various project platforms and perform project operations through the front end of the project system, the target component can be used to acquire and handle the risks of users' project operations. Since the target component is set in the front end of the project system, it will not affect the original functions or architecture of each project platform, nor will it be subject to the limitation of configuration incompatibility between project platforms. This realizes the acquisition and risk handling of users' cross-platform operations, ensuring the security and reliability of the project system.

[0037] Corresponding to the architecture of the aforementioned project system, particularly the target component, this specification provides a risk management method. One or more embodiments of this specification simultaneously relate to a target component, a project system front-end, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0038] See Figure 2 , Figure 2 A flowchart of a risk handling method according to an embodiment of this specification is shown. The method is applied to a target component at the front end of a project system. The target component records a user's identity identifier, which is generated by the project system front end calling the target component to collect user information from various project platforms. The method specifically includes the following steps.

[0039] Step 202: Receive the project operation from the target user, wherein the project operation carries operation attributes and target user information.

[0040] The project system front-end is the part of the project system that allows direct interaction with users or administrators, including software or websites. For example, the project system front-end can be a browser, application, or app, and can be used on personal computers, servers, mobile devices, etc. For instance, in a cloud computing environment, the project system front-end can be an internet application interface deployed in the cloud.

[0041] A target component is a small module or plugin applied to the front end of a project system to implement a specific function or perform a specific task. A target component can be a standalone functional unit or a part integrated into a larger system. For example, a target component can be an extension plugin for a webpage, such as an ad-blocking plugin, a data collection plugin, or a security protection plugin. For instance, in a cloud computing environment, a target component can be a cloud security plugin used to protect the security of internet applications in the cloud, or a database plugin in a cloud development platform used to provide different types of data.

[0042] A project platform refers to different project systems or service platforms within a project system. Each project platform can run independent applications or run different ports of the same application. All project platforms are managed by the project system and collectively serve the project system. For example, in a cloud computing environment, a project platform can be different service platforms within a cloud service that are independent yet interconnected, such as a cloud storage platform or a cloud development platform.

[0043] User information refers to a user's information across various project platforms, including registration information, login accounts, usernames, etc. User information is platform-specific; the same user may have the same or different information across different project platforms. Identity identifiers are unique information or codes generated by the project system frontend when it calls target components to collect user information across various project platforms within the project system. These identifiers are used to identify and distinguish different users. Identity identifiers can take various forms in different system and technology environments, depending on the system's security requirements, technical implementation, and application scenarios. Generating user identity identifiers based on user information across platforms ensures that each user's project operations across all project platforms within the project system frontend can be accurately identified and recorded, achieving consistent authentication across project platforms or multi-device environments.

[0044] Project operations are specific behaviors or actions performed by the target user on various project platforms within the project system's front end. Project operations can be any type of interactive activity, such as clicking a button, submitting a form, entering text, or uploading a file. Each project operation carries the operation's attributes and the target user's information. Operation attributes are a set of parameters or metadata passed along with the project operation, describing its specific details. Operation attributes may include the specific type of project operation, its timestamp, and the object of the operation, among other data.

[0045] Receiving project operations from target users can be performed by target components on the front end of the project system. For example, in a cloud computing environment, a risk identification component installed on the browser of a cloud service application can be used to receive project operations (such as data upload operations) performed by users on various project platforms (such as cloud server platforms) of the cloud service application.

[0046] This step enables the precise capture and recording of project operations by target users, ensuring that every project operation in the project system front-end can be accurately identified and associated with the target user. This provides a data foundation for subsequent target identity determination, project operation analysis, audit tracking, and risk anomaly detection.

[0047] Step 204: Determine the target user's target identity identifier based on the target user information.

[0048] After receiving the target user information carrying the operation attributes and the target user, the target user's target identity identifier can be determined based on the target user information.

[0049] Specifically, the target component can compare the collected target user information with the user information collected by the target component from various project platforms, and determine the target identity identifier of the target user information from the generated identity identifier.

[0050] This step ensures accurate identification and unified management of target user identities. Even if a target user operates on multiple project platforms within the project system, consistent authentication can be maintained, enhancing system security, preventing unauthorized access, and providing a data foundation for subsequent risk identification and handling.

[0051] Step 206: Identify whether a project operation is a risky operation based on the operation attributes and target identity.

[0052] Risky operations are those that may negatively impact system security, data integrity, or project workflow continuity. They typically involve the handling of sensitive information, modification or deletion of critical resources, and carry a high potential risk.

[0053] Risky operations may include, but are not limited to: the target user performing operations beyond their authorized permissions, such as a target user without data modification permissions attempting to modify data uploaded to the platform, or a target user without privacy information viewing permissions attempting to view privacy information; the target user performing operations that do not conform to standard operation attributes, such as modifying data before downloading it in a standard operation that directly downloads data, or proceeding directly to a subsequent process in a standard operation that requires data submission; and the target user performing operations that exceed the thresholds specified by standard operation attributes, such as exceeding a preset risk amount threshold in a payment or fund transfer operation, or repeatedly performing operations exceeding a preset risk frequency threshold, such as repeatedly logging in or repeatedly submitting data.

[0054] Based on the operation attributes and the target identity, the system identifies whether a project operation is a risky operation. Specifically, if the target identity has the corresponding operation permissions, the system compares the data included in the operation attributes with preset standard operation attributes to determine if the operation attribute is outside the preset standard operation attributes, thereby identifying whether the project operation is a risky operation. Alternatively, if the operation attributes belong to preset standard operation attributes, the system determines whether the project operation is a project operation specified in the operation permissions based on the operation permissions corresponding to the target identity, thereby identifying whether the project operation is a risky operation. Furthermore, the system can combine the operation attributes and the target identity, based on preset risk identification rules or standards, to identify whether the project operation is a risky operation. This specification does not specifically limit the embodiments described herein.

[0055] In this step, by identifying whether the target user's project operations are high-risk behaviors that exceed their authority, do not conform to standard procedures, or exceed preset thresholds, corresponding risk handling can be carried out for risky operations. This protects system security, maintains data integrity, and ensures project process continuity, thereby enhancing system security and providing a solid foundation for compliance management and auditing.

[0056] Step 208: If the project operation is a risky operation, perform risk management for the project operation.

[0057] Risk management refers to the series of measures taken to mitigate or eliminate the potential negative impacts of a project operation once it has been identified as a risky operation. Risk management can protect system security, data integrity, and project process continuity, ensuring the normal operation of the system or preventing actual losses to users' rights and interests. Risk management methods can be flexibly configured according to different project platforms and different risk types.

[0058] Optionally, risk handling can be as follows: blocking the project operation, i.e., directly blocking the currently performing project operation to prevent it from continuing; issuing a warning for the project operation, i.e. generating a warning message for the currently performing project operation and displaying the warning message to the target user or the project system administrator and requesting confirmation; or both blocking the currently performing project operation and generating a warning message to display to the target user or the project system administrator, allowing the target user to request permission or authorization from the project system administrator based on the warning message, and to continue performing the project operation after authorization by the project system administrator or to close the project operation if the project system administrator does not authorize it. This specification does not make specific limitations on this.

[0059] In this embodiment, the target component at the front end of the project system records the user's identity identifier. When receiving project operations from the target user, the target identity identifier is determined based on the carried operation attributes and target user information, thus achieving unified authentication and management of user identities across different project platforms. The system identifies whether a project operation is a risky operation based on the operation attributes and target identity identifier, and performs targeted risk handling for confirmed risky operations. This ensures effective recording and management of cross-platform user behavior, accurately handles risky user operations, and takes timely measures when risky project operations are detected, thereby guaranteeing the security and reliability of the management systems for each project platform.

[0060] In an optional embodiment of this specification, the risk handling method further includes:

[0061] In response to the initialization request, when the project system frontend is logged into each project platform, the system identifies the runtime environment of the project system frontend, obtains the user information and project platform identifier of each project platform, determines the correspondence between the user information and the project platform identifier of each project platform, and generates the identity identifier of each user in each project platform based on the user information, project platform identifier and correspondence of each project platform.

[0062] An initialization request is a request sent to the project system when a target component is first installed or activated in the project system frontend. It performs initialization operations on the target component to ensure it is correctly configured and begins normal operation. In this embodiment, in addition to the usual steps of requesting user consent and authorization for installation to establish a secure connection and service functions, the initialization request also includes requests to identify the runtime environment of the project system frontend and to collect user information from the various project platforms logged into the project system frontend. The runtime environment refers to the environment in which the project system frontend runs, including but not limited to the operating system type, browser or application version, and the identifier of the logged-in project platform. Identifying the runtime environment helps ensure the compatibility of the target plugin on the project system frontend and the integrity and accuracy of the generated identity identifier.

[0063] The mapping relationship refers to the correspondence between user information on each project platform and the platform identifier. Specifically, it refers to how each user's account information on different project platforms is associated with a specific platform identifier. Establishing this mapping relationship allows for management and tracking within a unified framework, even if the same user possesses different forms of identity information on multiple project platforms.

[0064] After receiving the initialization request, you need to be logged into the project platform in the project system front end before you can continue to execute the subsequent steps. If you are not logged into the project platform in the project system front end, you will not be able to collect user information and project platform identifiers from the project platform.

[0065] Once it is determined that the project system front-end logs into each project platform, the project platform identifier and user information of each project platform can be obtained by identifying the operating environment of the project system front-end, and the corresponding relationship can be determined based on this. Optionally, user information can be collected automatically by target component identification; alternatively, user information can be collected by displaying information collection prompts and input windows to guide users to input user information. This specification does not specifically limit this embodiment.

[0066] Once the correspondence is established, an identity identifier for each user on each project platform can be generated based on the user information, project platform identifier, and correspondence. Specifically, the method for generating the identity identifier can be chosen based on the actual application scenario or requirements. One possible method is generation via a hash algorithm. A hash algorithm uses a cryptographic hash function (such as SHA-256 (Secure Hash Algorithm 256-bit)) to process user information (username, email address, timestamp, etc.) and project platform identifiers to generate a fixed-length string as the identity identifier. Another possible method is generation via Globally Unique Identifier (GUID) technology. GUID technology is a 128-bit unique identifier technology that ensures uniqueness globally, without relying on a central server for allocation. It generates a fixed 128-bit identifier based on user information and project platform identifiers to serve as the identity identifier.

[0067] In the embodiments described in this specification, by generating a unique identity identifier, the unified collection, authentication and management of user information across platforms is realized, which enhances the security and integrity verification of the identity identifier, prevents the tampering and forgery of collected user information and other data, thereby improving the overall security, reliability and compliance of the system, and ensuring the secure transmission and storage of user identity identifiers.

[0068] In an optional embodiment of this specification, after generating the identity identifier for each user on each project platform based on user information, project platform identifiers, and corresponding relationships on each project platform, the method further includes:

[0069] The identity identifier is encrypted to generate a digital signature; correspondingly, after determining the target identity identifier of the target user based on the target user information, the method also includes: verifying whether the digital signature of the target identity identifier is consistent with the digital signature of the identity identifier corresponding to the target user information in the target component.

[0070] After generating an identity identifier for each user on each project platform, encrypting it and generating a digital signature further enhances security and integrity verification. Specifically, encryption can be performed by the project system's management system, and can be achieved by combining public / private key pairing technology and hash algorithms. This proves that the file or message has not been tampered with and was indeed signed by the claimed sender. That is, after obtaining the identity identifier through a hash algorithm, the identity identifier is sent to the project system's management system. The management system uses its public key to encrypt the identity identifier, obtaining the encrypted identity identifier, i.e., the digital signature, and returns it to the target component. After determining the target identity identifier based on the target user information, the target component can decrypt the digital signature corresponding to the target identity identifier using the corresponding private key and match it with the identity identifier calculated based on the target user information to verify whether the determined target identity identifier is correct, i.e., whether the identity identifier has not been tampered with and indeed comes from a legitimate source.

[0071] For example, the project system front-end includes project platforms identified as Project Platform A and Project Platform B. The user information of target user x in Project Platform A is username 001 and password XXX, and the user information in Project Platform B is 002 and password YYY. Then, the correspondence determined by the target component is A-001-XXX, B-002-YYY. The identity identifier of target user x is generated as X. In the target component, X represents username 001 in Project Platform A and username YYY in Project Platform B. So, regardless of whether target user x performs project operations in Project Platform A with username 001 or in Project Platform B with username 002, the target component can use identity identifier X to represent target user x.

[0072] In the embodiments described in this specification, by encrypting the identity identifier and generating a digital signature, the reliability of user authentication and the security of cross-platform operation are improved, the authenticity and traceability of user behavior are ensured, and the risks of identity impersonation and data tampering are effectively prevented, thereby improving the overall security, reliability and compliance of the system.

[0073] In one optional embodiment of this specification, identifying whether a project operation is a risky operation based on operation attributes and target identity includes:

[0074] Based on operation attributes and target identity, identify whether the target user has the operation permission for the project; if not, determine the project operation as a risky operation.

[0075] Operation permissions refer to the rights or authorizations of a target user to perform certain operations on the project platform. Operation permissions can be configured by the project system administrator based on different identity identifiers to ensure that only authorized users can perform sensitive or critical operations. Operation permissions can be further subdivided into several types, such as data read / write permissions, data modification permissions, and command execution permissions. Data read / write permissions can include permissions regarding whether data can be read and written, the method of data read / write, and the number of times data can be read / written; data modification permissions include permissions regarding whether data can be modified, the number of times data can be modified, and the range of data to be modified; command execution permissions include permissions regarding whether a specific command can be executed.

[0076] Specifically, identifying whether a target user has the necessary permissions to perform operations on a project based on operation attributes and target identity can be achieved through the following methods:

[0077] The operation attributes are obtained from the project operations. These attributes include data such as the specific type of the project operation, the timestamp of the project operation, and the object of the project operation. Optionally, the operation attributes can be divided at different granularities. For example, the target user performed a certain type of project operation (such as submitting data), the target user performed a certain step in a certain type of project operation (such as the "upload data to be submitted" step in the data submission project operation), or the target user performed a certain step in a certain type of project operation by manipulating a specific element (such as the "upload data to be submitted" step in the data submission project operation by clicking the "submit" button).

[0078] Determining the target identity identifier, as described in the above embodiments, involves determining the target identity identifier based on the target user information carried in the project operation. The specific implementation method has been described in the above embodiments and will not be repeated here.

[0079] Identification is performed based on preset permission rules. These preset permission rules are pre-configured rules upon which permission identification is based. They can be configured by the project system administrator or automatically generated by the project system based on historical data. The preset permission rules define the scope of permissions for different user identities regarding project operations. Based on the target identity, the corresponding permission scope within the preset permission rules can be determined. Then, it is determined whether the operation attribute falls within the scope of those permissions, thus identifying whether the target user has the necessary permissions to perform operations on the project.

[0080] After identifying whether the target user has the necessary permissions to perform the project operation, the system can determine whether the project operation is a risky operation based on the identification results. Specifically, if the target user's target identity does not have the permissions corresponding to the operation attribute of the project operation within its permission scope, the project operation can be judged as a risky operation.

[0081] For example, if target user x performs a "data write operation" project, and the operation attribute of this project is "uploading the data to be written in the data write operation by clicking the 'upload data' button", then based on the preset permission rules, the target identity X of target user x has the operation permission for the "data write operation" and it is found that "target identity X does not have the permission to perform the data write operation", then the "data write operation" is determined to be a risky operation.

[0082] In the embodiments described in this specification, by accurately identifying user operation permissions, it is ensured that only target users with operation permissions for project operations can perform sensitive operations, effectively preventing security risks caused by unauthorized project operations, enhancing the overall security, data integrity, and flexibility of permission management of the system, while supporting permission configuration requirements for different application scenarios and improving the flexibility of risk identification for project operations.

[0083] In one optional embodiment of this specification, identifying whether a target user has operation permissions for project operations based on operation attributes and target identity includes:

[0084] Based on the operation attributes, determine the predicted operation attributes of the target user's predicted project operation at the target time; if the target identity, operation attributes, and predicted operation attributes all match the permissions, determine that the target user has the operation permissions for the project operation.

[0085] The target time is the predicted time point for the target component, which can be a few seconds, a few minutes, or other time intervals in the future. The specific choice of the target time depends on the specific requirements of the application scenario.

[0086] Determining the predicted operation attributes of the target user's predicted item operations at the target time, based on operation attributes, involves analyzing the operation attributes of currently received user item operations and predicting the predicted operation attributes of the target user's predicted item operations at the target time based on the analysis results. The analysis of the operation attributes of already received user item operations can be conducted using various methods, such as Markov chain models, deep learning neural networks, and time series analysis models.

[0087] The predicted operation attributes of the predicted project operation are the same as the operation attributes of the received project operation, including data such as the specific type of the predicted project operation, the timestamp of the predicted project operation, and the object of the predicted project operation.

[0088] The system determines whether permissions match based on the target identity, operation attributes, and predicted operation attributes. Specifically, it uses preset permission rules to check whether the acquired operation attributes of the project operation and the predicted operation attributes of the project operation at the target time belong to the operation permissions corresponding to the target identity at the current time and the operation permissions corresponding to the target time. If so, it determines that the target user has the operation permissions for the project operation.

[0089] For example, target user x performed a "data write operation" at 11:20 AM. The operation attribute of this operation is "uploading the data to be written by clicking the 'upload data' button". Using the state transition matrix in the Markov chain model, the predicted operation attribute of "clicking the 'upload data' button" is "clicking the 'submit data' button", with a click interval of 1 minute. Therefore, it can be predicted that target user x's predicted operation attribute at the target time 11:21 is "clicking the 'submit data' button". Based on the preset permission rules, it is determined that target user x's target identity X has the operation permission to "click the 'upload data' button in the data write operation" at the current time 11:20 AM and the operation permission to "click the 'submit data' button in the data write operation" at the target time 11:21 AM. Therefore, it is determined that target user x has the operation permission for the data write operation, and this data write operation is not a risky operation.

[0090] In the embodiments described in this specification, real-time and forward-looking assessment of user operation permissions is implemented. It can predict and identify further operations of target users in advance, determine whether there is any risk, and thus carry out corresponding risk handling. This ensures that only authorized operations are executed, enhances the security and data integrity of the project system, and effectively prevents the occurrence of unauthorized or high-risk behaviors.

[0091] In an optional embodiment of this specification, before identifying whether the target user has operation permissions for the project operation based on operation attributes and target identity, the method further includes: identifying whether the project operation has exemption permissions; identifying whether the target user has operation permissions for the project operation based on operation attributes and target identity includes: in the case that the project operation does not have exemption permissions, identifying whether the target user has operation permissions for the project operation based on operation attributes and target identity.

[0092] Exempted permissions refer to specific operations or behaviors that are pre-configured by the system to be executed without regular permission verification. This is typically because these operations are considered low-risk, frequently occurring, or have minimal impact on system security and data integrity. In this example, operations with exempted permissions will not be subject to permission checks by the target component.

[0093] Exemption permissions can be set according to the operational attributes and actual needs of different project operations. Optionally, they can be set for low-risk or risk-free operational attributes, such as clicking buttons for general operations like expanding or returning, or viewing page descriptions and navigation. They can also be set for repetitive operational attributes, such as repeated page refreshes required to obtain certain information in real time. Alternatively, they can be set manually, for example, by the project system administrator configuring exemption permissions for certain specific project operations. This specification does not impose specific limitations on these settings in the embodiments.

[0094] Before identifying the operation permissions of a target user's project operation, the target component will first identify whether the project operation has exempt permissions. If the project operation has exempt permissions, the target component will not perform subsequent operation permission judgments for the project operation. That is, it will not identify risks for project operations with exempt permissions.

[0095] For example, when target user x performs the "View page navigation" operation with the operation attribute "Click the 'View' button", it is recognized that the "View page navigation" operation has exempted permissions, so no further operation permission recognition is performed for this operation.

[0096] In the embodiments described in this specification, by introducing exemption permissions and determining whether a project operation has exemption permissions, the permission management process is simplified, and system efficiency and user experience are improved.

[0097] In one optional embodiment of this specification, the exemption permission includes identity exemption permission; identifying whether a project operation has exemption permission includes: identifying whether a target user has identity exemption permission based on the target identity identifier.

[0098] Exemption permissions can include identity exemption permissions. Identity exemption permissions refer to exemption permissions based on a user's identity identifier. This means that certain users or user groups are pre-configured by the target component to perform certain operations without undergoing regular operation permission verification. Identity exemption permissions allow users with specific identities to bypass standard operation permission check processes and directly execute project operations. Identity exemption permissions can be set for users with sufficient trust levels, users whose operations have minimal impact on system security and data integrity, or they can be manually configured.

[0099] Identifying whether a target user's project operations have exemption permissions can be done by identifying whether the target user has identity exemption permissions. Specifically, after obtaining the target user's target identity identifier, it can be determined whether the target identity identifier has identity exemption permissions, for example, by using a preset list of identity exemption permissions or by judging based on the category of the target identity identifier.

[0100] For example, when target user y performs a "data modification operation", before the target component performs operation permission identification for the "data modification operation", it identifies that the target identity Y of target user y belongs to the "administrator identity" category. Therefore, the identity of this category has identity exemption permission, so the target user y can directly perform the "data modification operation" without further operation permission judgment for the target user y's "data modification operation".

[0101] In the embodiments described in this specification, by introducing an identity exemption permission mechanism, the permission management process is simplified, resource utilization and operation response speed are optimized, and system efficiency and user experience are improved.

[0102] In an optional embodiment of this specification, the exemption authority further includes operational exemption authority; the risk handling method further includes:

[0103] If the target user does not have identity exemption permissions, the system identifies whether the project operation has operation exemption permissions based on the operation attributes.

[0104] Exemption permissions can also include operation exemption permissions. Operation exemption permissions refer to operation attributes based on specific project operations, which are pre-set in the target component to allow the corresponding project operations to be executed without operation permission verification. Operation exemption permissions allow certain types of low-risk or risk-free project operations to bypass the operation permission check process and be executed directly. Operation exemption permissions can be set according to the type of operation attribute, or they can be set manually.

[0105] Optionally, operation exemption permissions can be set based on the finest granularity of the operation attributes. The finest granularity of the operation attributes is the button clicked on the front end of the project system. The target component can collect and configure all buttons on the front end of the project system, and then the project system administrator can flexibly configure operation exemption permissions with different judgment criteria based on different project scenarios, project types, etc., based on the buttons that have been collected and configured.

[0106] The target component collects and configures all buttons on the front end of the project system in various ways, such as using XPath or CSS selectors (Cascading Style Sheets Selectors). This specification does not make specific limitations on these methods in the embodiments.

[0107] Taking XPath as an example, XPath is a language used to locate elements in XML or HTML documents, and can select nodes or sets of nodes through path expressions.

[0108] Specifically, by using the DOM recognition module included in the target component and detecting buttons on the project's front end using MutationObserver, all DOM nodes to which buttons are attached can be obtained. The Document Object Model (DOM) is used to represent and manipulate the structure of HTML and XML documents, representing the document as a node tree. MutationObserver is a JavaScript interface used to listen for changes in the DOM node tree and trigger callback functions when any button is added, deleted, or has its attributes changed, dynamically configuring and loading these buttons.

[0109] Configure all buttons using XPath (such as button name (id), class name (class), or tag). For example, select buttons using fields such as ".next-btn", ".ant-btn", ".tri-btn", and "a". ".next-btn", ".ant-btn", and ".tri-btn" represent buttons whose class names are selected as "Next Button", "Any Button", and "Third-Level Button", respectively, while "a" represents buttons whose tag is "a".

[0110] Using XPath to configure buttons, you can automatically collect buttons in the front end of the project system through the target component, or you can collect them manually by clicking the mouse on the front end of the project system.

[0111] After obtaining all the buttons on the project's front end using XPath, you can configure corresponding operation exemption permissions for these buttons. For details, see... Figure 3 , Figure 3 This diagram illustrates a button configuration rule for operation exemption permissions in a risk handling method according to an embodiment of this specification, as shown below. Figure 3 As shown, buttons with operation exemption permissions can include the following categories:

[0112] Category 1: Configuring via DOM selectors, such as menus and table pagination module buttons. The configured DOM selectors can be ".teamix-pro-pagination-wrapper.next-btn" and ".next-menu-btn.next-btn", etc.

[0113] Category 2: By configuring whitelist text, for example, if the button ID includes corresponding keywords, such as "details, collapse, expand, return, reset, cancel" etc.

[0114] Category 3: Text regular expression matching exemption, for example, clickable resource data displayed on some view pages (such as ECS data in the ASCM-ECS page).

[0115] Category 4: Manually configured by the administrator, which refers to buttons that require human judgment and are not easily configured or described by the methods mentioned above. Examples include the instance name button on the list page (such as the jump to details button), the remote connection and management button in the operation bar of the ASCM-ECS list, etc.

[0116] For example, when target user x performs a "data modification operation," before the target component identifies the target user x's target identity X as not belonging to a category with identity exemption permissions, the "data modification operation" does not have identity exemption permissions. Therefore, it is necessary to further identify whether the "data modification operation" has operation exemption permissions based on the operation attributes. If the operation attribute corresponding to the "data modification operation" is "click the 'expand' button in the data modification section to expand the data table to be modified," then it is determined that the button 'expand' corresponding to the operation attribute has operation exemption permissions. Thus, target user x can directly execute the "data modification operation" with the operation attribute "click the 'expand' button" without further operation permission checks.

[0117] In the embodiments described in this specification, by introducing an operation exemption permission mechanism, the permission management process is simplified, resource utilization and operation response speed are optimized, and system efficiency and user experience are improved.

[0118] In an optional embodiment of this specification, when a project operation is considered a risky operation, risk management is performed on the project operation, including:

[0119] When a project operation is classified as a risky operation, determine the risk level of the project operation; and take appropriate risk management measures based on the risk level.

[0120] Risk level refers to the classification and assessment of project operations based on factors such as their potential impact, complexity, and possible security threats. Risk levels are typically categorized by risk severity (low, medium, high) or risk type (warning, blocking, etc.), with different risk levels corresponding to different risk management strategies.

[0121] Risk levels can be determined in various ways. For example, a series of risk level identification rules can be pre-defined in the target component, and risk scores can be performed on different dimensions based on the operational attributes of the project operation to determine the risk level of the project operation. Alternatively, historical data can be analyzed to determine the risk level of the current project operation by analyzing the risk level records of project operations that are the same or similar to the project operation in historical data. It can also be defined manually, i.e., for some complex project operations or those whose risk levels may differ in different scenarios, the risk level can be manually configured by the administrator or security technician. This specification does not impose specific limitations on these methods in the embodiments.

[0122] Once a project operation is determined to be a risky operation, it is necessary to determine the risk level of the project operation and then take appropriate risk management measures based on the risk level.

[0123] Specifically, different risk handling methods can be adopted for different risk levels. For example, for low-risk project operations, only low-risk information needs to be recorded before execution; for medium-risk project operations, a warning message needs to be displayed and secondary confirmation or verification is required; for high-risk project operations, the project operation will be directly intercepted and authorization of higher-level project operation permissions will be requested.

[0124] For example, if target user x performs a "data write operation" project, and the operation attribute of this project is "uploading the data to be written by clicking the 'upload data' button", then based on the preset permission rules, the target identity X of target user x is found to have no permission for the "data write operation". Therefore, the "data write operation" is determined to be a risky operation. The risk level of the "data write operation" is then determined. According to the preset risk level identification rules, the risk level of project operations without corresponding operation permissions is determined to be high risk level. Therefore, the "data write operation" is directly intercepted, and a request for higher operation permission authorization is made to target user x.

[0125] In the embodiments described in this specification, by introducing a risk handling mechanism, not only can targeted risk handling be carried out for risky operations of different risk levels, improving the flexibility and compatibility of the project system, but also the overall security of the project system is improved, ensuring that high-risk operations are strictly controlled, optimizing the operation process, and enhancing the traceability and transparency of the system, thereby effectively improving security and user experience.

[0126] In one optional embodiment of this specification, the risk levels include warning level and blocking level; based on the risk level, corresponding risk handling is performed on the project operation, including:

[0127] When the risk level is warning, a warning message for the project operation is displayed; when the risk level is blocking, the project operation is blocked, and a blocking message for the project operation is displayed.

[0128] A warning-level risk level indicates that the operation carries some risk, but not enough to immediately stop its execution. These operations typically require user attention and additional confirmation or verification. For example, clicking the "pay" button is not inherently risky, but if the payment amount exceeds a preset safety threshold (i.e., exceeds the normal payment limit), a warning message will be displayed to the user, and the payment operation will continue only after user confirmation.

[0129] A "Blocked" risk level indicates that the operation carries a high risk and may seriously impact system security, data integrity, or project workflow. Therefore, the system will directly block the operation and display a blocking message to the user. This message may include the blocked operation, the reason for the block, and whether higher-level permissions are requested.

[0130] For example, when performing a data deletion operation, clicking the "Data Deletion" button is a risky operation at the blocking level, which means that the data deletion operation will be blocked, and the blocking information will be displayed: "Blocking 'Data Deletion Operation'. The reason for the blocking is 'Insufficient operation permissions of the target user.' Do you want to request authorization for the 'Data Deletion Operation'?"

[0131] Optionally, blocking of block-level event operations can be achieved using `event.stopPropagation()` and `event.preventDefault()`. `event.stopPropagation()` and `event.preventDefault()` are JavaScript methods. `event.stopPropagation()` prevents event bubbling, i.e., prevents the current event from propagating further in the DOM tree; `event.preventDefault()` prevents default behavior, i.e., prevents the originally scheduled event from performing its default action, such as the behavior originally intended for clicking a button. Specifically, the target component sets listeners for collected and configured buttons using `button.addEventListener`. `button.addEventListener` is also a JavaScript method, and its advantage is that it allows adding multiple event listeners without overriding existing event handlers. In practical applications, when a user clicks a button while performing an event operation, the listener event configured by the target component is triggered first. If `event.stopPropagation()` and `event.preventDefault()` are executed, the default event originally defined for the button clicked in that event operation will be blocked.

[0132] Optionally, after the administrator of the project system receives the operation permission request information included in the blocking information, they can authorize the request through the authorization module. Upon receiving the corresponding authorization information, the target component can then allow the target user to continue executing the project operation. The operation permission authorization request can be implemented using symmetric encryption. The authorization module is essentially a codec; the administrator encrypts the authorized content (such as operation permissions) and authorization validity period, while the target component decrypts the encrypted information to obtain the corresponding authorization information, thus allowing the project operation to proceed. The administrator is responsible for keeping the encryption algorithm confidential, thereby ensuring the authenticity and validity of the authorization information.

[0133] For example, when target user x performs a "data write operation" in a project, if target identity X does not have the permission to perform the "data write operation," the "data write operation" is determined to be a risky operation. Further, according to preset risk level identification rules, the "data write operation" without the corresponding permission is determined to be at the blocking risk level. Therefore, the "data write operation" is blocked, and the target user x is shown the blocking message: "Blocked 'data write operation', blocking reason: 'Insufficient operation permission for target user,' do you want to request permission authorization for the 'data write operation'?" After target user x confirms and sends the request, the project system administrator authorizes the corresponding operation permission based on the request. Upon receiving the authorization information, the target component allows target user x to execute the "data write operation."

[0134] In the embodiments of this specification, by introducing risk level classifications of warning level and blocking level, when the target component identifies a project operation as a risky operation, it takes different handling measures according to the degree of risk. This not only enables corresponding risk handling for different risk levels, improving the flexibility and compatibility of the project system, but also enhances the security of the project system, preventing high-risk operations from affecting system security, data integrity, and project processes. In this way, it ensures the safe execution of critical operations and enhances user experience and operational transparency.

[0135] In an optional embodiment of this specification, when the project operation is a risky operation, after risk handling of the project operation, the method further includes:

[0136] Collect context information about project operations and the operation status of target components; based on the context information and operation status, generate the operation results of the project operations.

[0137] Contextual information for project operations refers to the environmental and background data related to those operations, providing detailed information about them. This information helps in comprehensively understanding the context in which the operations are conducted, supporting subsequent analysis and decision-making. For example, contextual information may include: identification information, operation timestamps, operation runtime environment, and the objects being operated on.

[0138] The operational status of a target component refers to the status information of the target component during project operations. The operational status reflects whether the target component is functioning correctly and its resource usage. Operational status can include: target component running status, target component resource utilization, etc.

[0139] The operational status of the target component can be detected by the status detection module. Specifically, the status detection module can detect the operational status of the target component through heartbeat mechanisms, exception listening (such as the target component being closed or uninstalled), etc., to avoid bypassing the target component and directly performing project operations on various project platforms on the front end of the project system.

[0140] Specifically, contextual information about project operations can be collected through the following methods:

[0141] 1. When the target user performs an operation on the project, each click on the button will be regarded as an operation event and captured by the target component;

[0142] 2. Whenever an operation event is generated, the relevant information of the operation event (such as timestamp, operation type, keywords, runtime environment information, and whether it is risk information) will be packaged into a message and cached through the message queue inside the target component;

[0143] 3. Record the status of the operation event, such as whether it was completed if the project operation was not a risky operation, and how the risk was handled if the project operation was a risky operation. Collect the button click operation events of this project operation into the data storage area of ​​the target component.

[0144] 4. Once the target user has completed all project operations, the target component can connect the user's project operations based on the timestamps, i.e., the order in which the user clicked the buttons, to form a complete user operation path. This completes the collection of contextual information about the project operations.

[0145] After collecting the context information of the project operation, the operation result of the project operation can be generated by combining the operation state of the target component.

[0146] The operation results may include an indicator of whether the operation was successful, detailed information about the operation, an impact assessment of the operation, recommended measures for the operation, and log information from the system during the operation.

[0147] For example, if target user x performs a "data write operation," and target identity X does not have the necessary permissions for this operation, the "data write operation" is determined to be a risky operation. Further, based on preset risk level identification rules, the "data write operation" without corresponding permissions is classified as a blocking risk level. Therefore, the "data write operation" is blocked, and target user x is shown the blocking message: "Blocked 'data write operation,' blocking reason: 'Insufficient target user permissions.' Do you wish to request permission for the 'data write operation'?" If target user x cancels the request for permission, the operation is considered complete. The corresponding context information for the operation is: "Target identity X, operation timestamp: **** year ** month ** day 11:21 AM, operation environment information: project platform A, operation type: data write operation, operation result: operation failed...", and the target component's operation status is: "Operation status: normal, resource utilization: high...".

[0148] In the embodiments of this specification, the target component collects detailed contextual information of the project operation and the operation status of the target component, and generates operation results. This not only improves the transparency and traceability of the system and ensures that the background and execution of each operation are fully recorded, but also provides a data foundation for subsequent analysis, auditing and improvement.

[0149] In an optional embodiment of this specification, after generating the operation result of the project operation based on context information and operation status, the method further includes:

[0150] Receive operation permission adjustment information, which is determined by the administrator of the project system front end based on the operation result; adjust the operation permissions according to the operation permission adjustment information.

[0151] Operation permission adjustment information refers to the instructions issued by the administrator at the project system front end to change operation permissions based on the operation results (such as whether the operation was successful or not, impact assessment, etc.). Operation permission adjustment information may include adding, reducing, or modifying the operation permissions of certain project operations corresponding to certain identity identifiers, as well as adding, reducing, or modifying the risk level of certain project operations.

[0152] The permission adjustment information is determined by the administrator of the project system front-end based on the operation result. Optionally, after the target component receives the operation result, the result can be presented to the administrator through the target component's visualization module. Specifically, the following can be displayed based on the operation result:

[0153] 1. Based on the target dimension of the project operation, provide information from different dimensions of the context of the project operation, such as the activity level, operation frequency, and interception ratio of the project operation, and the target component can clean and organize the context information according to the specified dimensions.

[0154] 2. Transform the contextual information of project operations into easily understandable visual forms, such as bar charts, pie charts, line charts, etc.

[0155] 3. Integrate the operation results into a visual report, along with corresponding explanations and confirmation information regarding whether the report was copied to the manager via email, fax, or other means.

[0156] Administrators can review the displayed operation results through the visualization module of the target component, assess the risk level of the risky operation based on the potential security risks or compliance issues included in the operation results, and take corresponding management actions, such as inputting operation permission adjustment information into the target component and adjusting the operation permissions in the target component.

[0157] In the embodiments described in this specification, operation permissions are dynamically adjusted based on operation permission adjustment information, which enhances the flexibility and response speed of permission management, improves the security and compliance of the system, increases the efficiency of operation permission adjustment, ensures that the operation permission settings match the project operations, enhances the security and reliability of project operations, and maintains the traceability and transparency of the project system.

[0158] The following is in conjunction with the appendix Figure 4 To be continued Figure 6 This document uses the application of the risk handling methods provided in this specification to a technical assurance plugin on a browser page of a multi-project platform as an example to further illustrate the risk handling methods. Figure 4 This diagram illustrates the structure of a technical assurance plug-in according to one embodiment of this specification. Figure 5 This diagram illustrates the process of initializing a technical safeguard plugin in a risk management method according to an embodiment of this specification. Figure 6 A flowchart illustrating the processing procedure of a risk management method provided in one embodiment of this specification is shown.

[0159] like Figure 4 As shown: The technical support plugin includes a presentation layer, a functional layer, a data layer, and various project platforms that receive plugin management. The presentation layer includes a visualization module, user interface, and open interface model; the functional layer includes an abnormal behavior monitoring module, decision support module, identity identification module, authorization module, DOM recognition module, and runtime environment recognition module; the data layer includes a permission configuration module, environment information module, and operation context module.

[0160] like Figure 5 As shown, during the initialization process of this technical assurance plugin, initialization begins first. The plugin identifies the operating environment and guides the user to collect user information from various project platforms, which the user then submits. The plugin then generates a user identity identifier based on the submitted information. This identifier is then sent to the management system, which encrypts it, obtains a digital signature, and returns it. Subsequently, when the plugin interacts with external project platforms, the platform requests authentication from the plugin. The plugin adds a digital signature to the information exchanged with the platform, which then verifies the signature and returns the result.

[0161] like Figure 6 As shown: This risk handling method is applied to a technical assurance plugin in a browser. In response to an initialization request, when logged into various project platforms on a browser page, the technical assurance plugin identifies the browser page's operating environment and determines the correspondence between user information and project platform identifiers on each project platform. Based on the user information, project platform identifiers, and correspondences on each project platform, it generates an identity identifier for each user on each project platform. The method specifically includes the following steps.

[0162] Step 602: Receive the project operation from the target user, wherein the project operation carries operation attributes and the target user information of the target user.

[0163] Step 604: Determine the target user's target identity identifier based on the target user information; based on the target identity identifier, identify whether the target user has identity exemption privileges.

[0164] Step 606: If the target user does not have identity exemption permissions, identify whether the project operation has operation exemption permissions based on the operation attributes.

[0165] Step 608: If the project operation does not have exemption permissions, determine the predicted operation attribute of the predicted project operation of the target user at the target time based on the operation attribute.

[0166] Step 610: If the target identity and operation attributes, as well as the predicted operation attributes, all match the permissions, determine whether the target user has the operation permission for the project operation; if not, determine that the project operation is a risky operation.

[0167] Step 612: If the project operation is a risky operation, determine the risk level of the project operation, which includes warning level and blocking level.

[0168] Step 614: If the risk level is warning, display the warning message for the project operation; if the risk level is blocking, block the project operation and display the blocking message for the project operation.

[0169] Step 616: Collect the context information of the project operation and the operation status of the technical support plugin; based on the context information and operation status, generate the operation result of the project operation.

[0170] In one optional embodiment of this specification, a target component is also provided. Figure 7 A schematic diagram of the structure of a target component provided in one embodiment of this specification is shown. For example... Figure 7 As shown, the target component is installed on the front end of the project system. The target component records the user's identity identifier, which is generated by the project system front end calling the target component to collect user information from various project platforms. The target component includes:

[0171] Interface module 702 is configured to receive project operations from a target user, wherein the project operations carry the operation attributes of the target project and the target user information of the target user;

[0172] The identity identification module 704 is configured to determine the target identity of the target user based on the target user information;

[0173] The abnormal behavior monitoring module 706 is configured to identify whether a project operation is a risky operation based on the operation attributes and target identity.

[0174] Processing module 708 is configured to perform risk processing on project operations when the project operation is a risky operation.

[0175] Optionally, the target component further includes: in response to an initialization request, upon logging into each project platform on the project system front end, identifying the runtime environment of the project system front end, obtaining user information and project platform identifiers for each project platform; determining the correspondence between user information and project platform identifiers for each project platform; and generating an identity identifier for each user on each project platform based on the user information, project platform identifiers, and correspondence.

[0176] Optionally, the target component is further configured to: encrypt the identity identifier and generate a digital signature; verify whether the digital signature of the target identity identifier is consistent with the digital signature of the identity identifier corresponding to the target user information in the target component.

[0177] Optionally, the abnormal behavior monitoring module 706 is further configured to: identify whether the target user has the operation permission for the project operation based on the operation attribute and the target identity identifier; if not, determine that the project operation is a risky operation.

[0178] Optionally, the abnormal behavior monitoring module 706 is further configured to: determine the predicted operation attribute of the target user's predicted project operation at the target time based on the operation attribute; and determine that the target user has the operation permission for the project operation if the target identity, operation attribute, and predicted operation attribute all match the permissions.

[0179] Optionally, the target component also includes a permission configuration module, configured to: identify whether the project operation has exemption permissions; the abnormal behavior monitoring module 706 is further configured to: identify whether the target user has operation permissions for the project operation based on the operation attributes and the target identity when the project operation does not have exemption permissions.

[0180] Optionally, the exemption permissions include identity exemption permissions; the permission configuration module is further configured to: identify whether the target user has identity exemption permissions based on the target identity identifier.

[0181] Optionally, the exemption permissions also include operation exemption permissions; the permission configuration module is further configured to: identify whether the project operation has operation exemption permissions based on the operation attributes when the target user does not have identity exemption permissions.

[0182] Optionally, the processing module 708 is further configured to: determine the risk level of the project operation when the project operation is a risky operation; and perform corresponding risk handling on the project operation according to the risk level.

[0183] Optionally, the risk levels include warning level and blocking level; the processing module 708 is further configured to: display warning information for the project operation when the risk level is warning level; and block the project operation and display blocking information for the project operation when the risk level is blocking level.

[0184] Optionally, the target component also includes an audit module, configured to: collect context information of project operations and the operation status of the target component; and generate operation results of project operations based on the context information and operation status.

[0185] The above is an illustrative scheme of a target component in this embodiment. It should be noted that the technical solution of this target component and the technical solution of the risk handling method described above belong to the same concept. For details not described in detail in the technical solution of the target component, please refer to the description of the technical solution of the risk handling method described above.

[0186] In one optional embodiment of this specification, a project system front-end is also provided, see [link to documentation]. Figure 8 , Figure 8 A schematic diagram of the structure of a project front-end system provided in one embodiment of this specification is shown. For example... Figure 8 As shown, the target components mentioned above are installed on the front end of the project system.

[0187] In an optional embodiment of this specification, the front end of the project system further includes a target sub-component having the same function as the target component; the target sub-component is configured to monitor the operational status of the target component; the target component is configured to monitor the operational status of the target sub-component. See also Figure 9 , Figure 9 This specification illustrates a schematic diagram of the structure of a target component and a target sub-component in a project front-end system according to an embodiment of this specification, as shown below. Figure 9 As shown:

[0188] Since the target component can no longer detect its own operational status after it is closed, the target sub-component can also be included in the front end of the project system.

[0189] The target sub-component has the same functionality as the target component, and is configured to monitor the operational status of the target component. Simultaneously, the target component can also monitor the operational status of the target sub-component. Through this "dual-active" monitoring mechanism, even if either the target component or the target sub-component experiences an anomaly (such as disconnection, pause, or inconsistent output), the other component can continue performing its normal risk handling functions while simultaneously recording the component exhibiting abnormal behavior and issuing warnings.

[0190] In the embodiments described in this specification, a "dual-active" monitoring mechanism is formed by setting a target sub-component with the same function as the target component in the front end of the project system. This ensures that even if one component malfunctions, the other component can still continue to perform risk handling, record abnormal behavior, and issue warnings. This not only improves the reliability and stability of the system and ensures the continuity of critical operations, but also enhances fault recovery capabilities and security, effectively preventing the risks caused by single points of failure.

[0191] In one optional embodiment of this specification, a cloud system is also provided. Figure 10 A schematic diagram of the structure of a cloud system provided in one embodiment of this specification is shown. Figure 10 As shown: The cloud system includes a project front-end and multiple cloud servers. The project front-end is equipped with a target component, which records the user's identity identifier. The identity identifier is generated by the project front-end calling the target component to collect user information from each cloud server.

[0192] The target component is configured to receive project operations from a target user, wherein the project operation carries operation attributes and target user information of the target user; determine the target user's target identity identifier based on the target user information; identify whether the project operation is a risky operation based on the operation attributes and the target identity identifier; and perform risk handling on the project operation if the project operation is a risky operation.

[0193] A cloud system refers to a complete network infrastructure, platform, or software service built on cloud computing technology. Cloud systems can provide on-demand computing resources and services via the internet, allowing users to flexibly access, manage, and use these resources as needed.

[0194] A cloud server refers to a server or server cluster responsible for providing specific services within a cloud system. Located in the cloud, cloud servers provide various computing resources and services to clients via the network. Cloud servers typically include computing resources (such as CPU and memory), storage resources (such as hard drives and databases), and network resources (such as bandwidth and API interfaces).

[0195] In the embodiments described in this specification, effective recording and management of user behavior on each cloud server is ensured, enabling precise handling of risky user operations and timely implementation of measures when risky project operations are detected, thereby guaranteeing the security and reliability of the cloud system.

[0196] Figure 11 A structural block diagram of a computing device 1100 according to one embodiment of this specification is shown. The components of the computing device 1100 include, but are not limited to, a memory 1110 and a processor 1120. The processor 1120 is connected to the memory 1110 via a bus 1130, and a database 1150 is used to store data.

[0197] The computing device 1100 also includes an access device 1140, which enables the computing device 1100 to communicate via one or more networks 1160. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 1140 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0198] In one embodiment of this specification, the aforementioned components of the computing device 1100 and Figure 11 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 11 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0199] The computing device 1100 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 1100 can also be a mobile or stationary server.

[0200] The processor 1120 is used to execute the following computer program / instructions, which, when executed by the processor, implement the steps of the risk handling method described above.

[0201] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the risk handling method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the risk handling method described above.

[0202] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the risk handling method described above.

[0203] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the risk handling method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the risk handling method described above.

[0204] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the risk handling method described above.

[0205] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the aforementioned risk handling method belong to the same concept. Details not described in detail in the computer program's technical solution can be found in the description of the aforementioned risk handling method's technical solution.

[0206] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0207] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0208] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0209] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0210] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A risk handling method applied to a target component of a project system front-end, wherein the target component records a user's identity identifier, the identity identifier being generated by the project system front-end calling the target component to collect user information from various project platforms; the method includes: Receive project operations from target users, wherein the project operations carry operation attributes and target user information of the target user, and the project operations are specific behaviors or actions performed by the target user on the project platforms in the front end of the project system; The target user's target identity identifier is determined based on the target user information; Based on the operation attributes and the target identity, determine whether the project operation is a risky operation. This determination includes: identifying whether the project operation has exemption permissions, whereby exemption permissions include operation exemption permissions set according to the finest granularity of the operation attributes, which includes buttons on the project system front-end; if the project operation does not have exemption permissions, determine whether the target user has operation permissions for the project operation based on the operation attributes and the target identity; if not, then determine the project operation as a risky operation. If the project operation is a risky operation, risk management shall be performed on the project operation; Collect the context information of the project operation and the operation status of the target component to avoid bypassing the target component and directly performing the project operation on the project platform on the front end of the project system. The context information is based on the order in which the target user clicks the button to connect the project operations and form the target user operation path determination. Based on the context information and the operation status, the operation result of the project operation is generated, wherein the operation result includes suggested measures for the project operation and is used to generate a visualization report; Receive operation permission adjustment information, wherein the operation permission adjustment information is determined by the administrator of the project system front end based on the operation result; Adjust the operation permissions according to the operation permission adjustment information.

2. The method according to claim 1, further comprising: In response to the initialization request, when the project system front-end logs into each project platform, the operating environment of the project system front-end is identified, and user information and project platform identifiers of each project platform are obtained. Determine the correspondence between user information in each project platform and the project platform identifier of each project platform; Based on the user information in each project platform, the project platform identifier of each project platform, and the corresponding relationship, an identity identifier for each user in each project platform is generated.

3. The method according to claim 2, after generating the identity identifier of each user in each project platform based on the user information in each project platform, the project platform identifier of each project platform, and the correspondence, further includes: The identity identifier is encrypted to generate a digital signature; After determining the target user's target identity based on the target user information, the method further includes: Verify whether the digital signature of the target identity identifier and the digital signature of the identity identifier corresponding to the target user information in the target component are consistent.

4. The method according to claim 1, wherein identifying whether the target user has operation permissions for the project based on the operation attribute and the target identity identifier includes: Based on the operation attributes, determine the predictive operation attributes of the predicted project operation of the target user at the target time; If the target identity matches the permissions of the operation attribute and the predicted operation attribute, it is determined that the target user has the operation permission for the project.

5. The method according to claim 1, wherein the exemption authority further includes identity exemption authority; The process of identifying whether the project operation has an exemption permission includes: Based on the target identity identifier, determine whether the target user has the identity exemption permission.

6. The method according to claim 5, further comprising: If the target user does not have the identity exemption permission, the system identifies whether the project operation has the operation exemption permission based on the operation attribute.

7. The method according to any one of claims 1-6, wherein when the project operation is a risky operation, risk management of the project operation includes: If the project operation is a risky operation, determine the risk level of the project operation; Based on the risk level, appropriate risk management shall be carried out for the project operation.

8. The method according to claim 7, wherein the risk level includes a warning level and a blocking level; The process of handling corresponding risks in the project operation based on the risk level includes: If the risk level is warning level, a warning message will be displayed for the project operation; If the risk level is blocked, the operation of the project will be blocked, and the blocking information of the project operation will be displayed.

9. A target component, installed on the front end of a project system, wherein the target component records a user's identity identifier, the identity identifier being generated by the project system front end calling the target component to collect user information from various project platforms; the target component comprises: The interface module is configured to receive project operations from a target user, wherein the project operation carries the operation attributes of the target project and the target user information of the target user, and the project operation is the specific behavior or action performed by the target user on each project platform in the front end of the project system; An identity identification module is configured to determine the target identity of the target user based on the target user information. The identity identification module is further configured to: identify whether the project operation has exemption permissions, the exemption permissions including operation exemption permissions set according to the finest granularity of the operation attributes, the finest granularity of the operation attributes including buttons on the project system front end; if the project operation does not have exemption permissions, identify whether the target user has operation permissions for the project operation based on the operation attributes and the target identity; if not, determine the project operation as a risky operation. The abnormal behavior monitoring module is configured to identify whether the project operation is a risky operation based on the operation attributes and the target identity identifier; The processing module is configured to perform risk processing on the project operation if the project operation is a risky operation. The audit module is configured to collect context information of the project operations and the operation status of the target components to prevent bypassing the target components and directly performing project operations on the project platforms on the project system front end. The context information is used to chain the project operations based on the order in which the target user clicks buttons, forming a target user operation path determination. Based on the context information and the operation status, the module generates operation results for the project operations, including suggested measures for the project operations, and is used to generate a visual report. It also receives operation permission adjustment information, which is determined by the administrator of the project system front end based on the operation results. Finally, it adjusts the operation permissions according to the operation permission adjustment information.

10. A project system front-end, on which the target component as described in claim 9 is installed.

11. The project system front-end according to claim 10 further includes a target sub-component having the same function as the target component; the target sub-component is configured to monitor the operation status of the target component; the target component is configured to monitor the operation status of the target sub-component.

12. A cloud system, comprising a project system front-end and multiple cloud servers, wherein the project system front-end is equipped with a target component, the target component records a user's identity identifier, and the identity identifier is generated by the project system front-end calling the target component to collect user information from each cloud server; The target component is used to receive project operations from the target user, wherein... The project operation carries operation attributes and target user information of the target user. The project operation is a specific behavior or action performed by the target user on various project platforms in the project system front-end. The target user's target identity is determined based on the target user information. Based on the operation attributes and the target identity, it is identified whether the project operation is a risky operation. The step of identifying whether the project operation is a risky operation based on the operation attributes and the target identity includes: identifying whether the project operation has exemption permissions, where exemption permissions include operation exemption permissions, which are set according to the finest granularity of the operation attributes, including buttons on the project system front-end; and, if the project operation does not have exemption permissions, identifying whether the target user has any rights to the project operation based on the operation attributes and the target identity. If the user has the necessary permissions, the operation is determined as a risky operation. If the operation is deemed risky, risk management is implemented. The context information of the operation and the operation status of the target component are collected to prevent bypassing the target component and directly performing the operation on the project platform from the project system front-end. The context information is used to chain the operation steps based on the order in which the target user clicks buttons, thus determining the target user's operation path. Based on the context information and the operation status, the operation result is generated, including suggested measures for the operation and used to generate a visual report. Operation permission adjustment information is received, determined by the administrator of the project system front-end based on the operation result. The operation permissions are adjusted according to the operation permission adjustment information.

13. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the risk handling method according to any one of claims 1 to 8.

14. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the risk handling method according to any one of claims 1 to 8.

15. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the risk handling method according to any one of claims 1 to 8.

Images