Intelligent authority management and dialogue system and method of multi-platform client integrated large model service

Abstract

The invention relates to the technical field of network security, and particularly discloses an intelligent authority management and dialogue system and method for a multi-platform client integrated large model service, and the system comprises a basic authority determination module which determines a basic authority range corresponding to user identity information; the platform and client differentiation module retrieves a preset organization cross-platform client permission differentiation table, and determines a permission difference set of the corresponding user identity information under the corresponding platform type and the corresponding client type; the permission materialization module determines a current permission range corresponding to the user identity information based on the equipment static risk analysis result of the client receiving the account information, the permission difference set and the basic permission range; the permission dynamic updating module is used for updating the current permission range in real time based on the two-dimensional drift information and giving a response to the dialogue request based on the large model accessed by the platform and the latest permission range; and the security and intelligence of large model interaction are improved.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to an intelligent rights management and dialogue system and method for a multi-platform client integrated large model service. Background Art

[0002] In the digital age, enterprises and organizations widely utilize multiple platforms and clients to conduct business. Big model services, with their powerful language processing and intelligent interaction capabilities, are increasingly being integrated into various business scenarios, providing users with more intelligent and efficient services. The integration of big model services across multiple platform clients can consolidate resources and provide users with a more convenient and comprehensive experience. In this context, intelligent permission management and dialogue systems are crucial. Appropriate permission management ensures that different users, based on their identities and roles, can securely and compliantly access and use big model services across different platforms and clients, protecting sensitive information and system security. Precise dialogue systems can provide personalized and targeted services based on user permissions, improving user satisfaction and work efficiency. With the acceleration of enterprise digital transformation and the increasing adoption of big models, this integrated intelligent permission management and dialogue system has broad application prospects across various industries, such as finance, healthcare, and government, helping to drive intelligent and refined business processes.

[0003] However, existing systems present numerous problems. For example, organizational structure information is not considered when determining permissions. Effective differentiated permission management is lacking for different platforms and client types, and the static risks of client devices are not fully considered. This makes it impossible to accurately determine the current scope of permissions based on these factors. Furthermore, dynamic permission updates fail to incorporate the dynamic risk profile of client devices and user conversation requests in real time. Ultimately, appropriate conversation responses cannot be provided based on accurate permissions and large models, impacting user experience and system security.

[0004] Therefore, the present invention proposes an intelligent rights management and dialogue system and method for multi-platform client integrated large model services. Summary of the Invention

[0005] The present invention provides an intelligent permission management and dialogue system and method for multi-platform client-side integrated big model services. The system's basic permission determination module uses account information to identify the user's organizational node and then determines the basic permission scope, laying the foundation for permission management and ensuring that the user's initial permissions are standardized and consistent with the organizational structure. The platform and client differentiation module retrieves a permission differentiation table based on platform and client type to derive a permission difference set, meeting the permission differentiation requirements of different platform and client scenarios and making permission management more tailored to actual usage environments. The permission concretization module combines the client device static risk analysis results, the permission difference set, and the basic permission scope to accurately determine the current permission scope, comprehensively considering factors such as device risk, thereby enhancing the security and rationality of permission management. The permission dynamic update module derives two-dimensional drift information based on the device dynamic risk analysis results and dialogue requests, and updates the current permission scope in real time based on the complete permission representation graph. Based on this information, the platform-accessible big model responds to dialogue requests using the platform-accessible big model. This not only enables dynamic and flexible adjustment of permissions but also provides appropriate responses to users based on real-time permissions, improving the security and intelligence of interactions, effectively protecting organizational information security, and optimizing the user interaction experience.

[0006] The present invention provides an intelligent rights management and dialogue system for multi-platform client-integrated large model services, including:

[0007] A basic authority determination module is used to determine the node to which the corresponding user identity information belongs in the organizational structure based on the account information of any platform received from any client, and to determine the basic authority scope of the corresponding user identity information based on the node;

[0008] The platform and client differentiation module is used to retrieve the preset organization cross-platform client permission differentiation table based on the platform type and client type of the received account information, and determine the permission difference set of the corresponding user identity information under the corresponding platform type and the corresponding client type;

[0009] The permission concretization module is used to determine the current permission scope of the corresponding user identity information based on the device static risk analysis results of the client that receives the account information, the permission difference set, and the basic permission scope;

[0010] The dynamic permission update module is used to analyze the two-dimensional drift information based on the dynamic risk analysis results of the client device that receives the account information and all the dialogue requests entered by the user, and to update the current permission scope in real time based on the two-dimensional drift information, and to respond to the dialogue request based on the large model accessed by the platform and the latest permission scope.

[0011] Preferably, the basic authority determination module includes:

[0012] The registration information retrieval submodule is used to retrieve the pre-registration information of all members under the organizational structure based on the account information of any platform received from any client, and obtain the corresponding user identity information;

[0013] The structure database search submodule is used to search the organizational structure database based on the corresponding user identity information to determine the corresponding department;

[0014] The architecture belonging determination submodule is used to determine the node to which the corresponding user identity information belongs in the organizational structure based on the corresponding department;

[0015] The predefined permission association submodule is used to determine the predefined permission range of the node to which it belongs, which is used as the basic permission range corresponding to the user identity information.

[0016] Preferably, the platform and client differentiation modules include:

[0017] The type determination submodule is used to determine the platform type and client type of the received account information;

[0018] The permission difference information retrieval submodule is used to retrieve the preset organization cross-platform client permission differentiation table based on platform type and client type to obtain all permission difference information;

[0019] The permission difference information aggregation submodule is used to aggregate all permission difference information as a permission difference set of corresponding user identity information under the corresponding platform type and the corresponding client type.

[0020] Preferably, the permission concretization module includes:

[0021] The static risk assessment submodule is used to obtain the client's device static risk score and all device static risk items as the client's device static risk analysis results based on the client's system configuration, application, application application permissions, firewall configuration, IP address, and open ports of the client receiving the account information;

[0022] The risk permission constraint submodule is used to determine the permission constraint factors of all device static risk items based on the client's device static risk score value. Based on the permission constraint factors of all device static risk items and all device static risk items in the device static risk analysis results, the risk item-permission range association table is retrieved and summarized to obtain the permission constraint set;

[0023] The permission update submodule is used to update the basic permission range based on the permission constraint set and the permission difference set, and obtain the current permission range corresponding to the user identity information.

[0024] Preferably, the static risk assessment submodule includes:

[0025] The system configuration risk assessment unit is used to compare the account policies, access control settings, and network service settings in the system configuration with the preset security configuration benchmark to obtain all risk items of the system configuration, and assign scores to the system configuration comparison results based on preset risk assessment rules to obtain the risk score value of the system configuration;

[0026] An application risk assessment unit is used to assign a risk value to the source of each application installed on the client based on the application source risk assessment rules, and to obtain a risk score value and all risk items for each application by combining the validity of each application's digital signature and the degree of matching with malware characteristics;

[0027] The application permission risk assessment unit is used to determine the rationality of the permissions applied for by the corresponding application based on the functional requirements of all applications installed on the client, and obtain the risk score value and all risk items of the application permissions;

[0028] The device static risk aggregation unit is used to analyze the risk score value and all risk items of the client's firewall configuration, the risk score value and all risk items of the IP address and open port, and combine the risk score value and all risk items of the system configuration, the risk score value and all risk items of all applications, and the risk score value and all risk items of application permissions to obtain the device static risk score value and all device static risk items of the client that receives the account information.

[0029] Preferably, the permission dynamic update module includes:

[0030] A first risk analysis submodule, configured to generate a first risk vector based on all security vulnerability items and a risk value of each security vulnerability item in the real-time security vulnerability screening result in the device dynamic risk analysis result of the client receiving the account information;

[0031] a second risk analysis submodule, configured to determine all unupdated security patches based on the real-time security patch update status in the device dynamic risk analysis result of the client receiving the account information, and generate a second risk vector based on pre-assigned scores of all unupdated security patches;

[0032] A third risk analysis submodule, configured to generate a third risk vector based on the matching degree between the sensitivity and encryption level of all group sensitive information transmitted in the latest period in the dynamic risk analysis result of the device of the client receiving the account information;

[0033] A drift matrix generation submodule, configured to generate a first drift matrix based on the first risk vector, the second risk vector, and the third risk vector;

[0034] A second drift analysis submodule, configured to analyze a second drift matrix based on all dialogue requests input by the user;

[0035] A drift trend marking submodule, configured to update the current authority range in real time based on the first drift matrix and the second drift matrix;

[0036] The large model response submodule is used to respond to dialogue requests based on the large model connected to the platform and the latest permission range;

[0037] The two-dimensional drift information includes a first drift matrix and a second drift matrix.

[0038] Preferably, the second drift analysis submodule includes:

[0039] A first permission line fitting unit is configured to analyze the target permission classes of all dialogue requests entered by the user and the request depth of each target permission, determine the ordinate value of each dialogue request in a preset two-dimensional coordinate system based on the request depth of the target permissions of all dialogue requests, determine the abscissa difference between each group of adjacent dialogue requests in the preset two-dimensional coordinate system based on the permission category span of the target permission classes of each group of adjacent dialogue requests, determine the corresponding coordinate point of each dialogue request in the preset two-dimensional coordinate system in combination with a preset starting abscissa value, and fit the user's total requested permission line based on the corresponding coordinate points of all dialogue requests in the preset two-dimensional coordinate system;

[0040] an over-limit conversation request screening unit, configured to screen out, from all conversation requests input by the user, all conversation requests that do not meet the authority range of the corresponding user identity information at the corresponding moment, as all over-limit conversation requests;

[0041] A second permission line fitting unit is configured to determine a vertical coordinate value of each over-limit dialogue request in a preset two-dimensional coordinate system based on the request depth of the target over-range permission of all over-limit dialogue requests, determine a horizontal coordinate difference between each group of adjacent over-limit dialogue requests in the preset two-dimensional coordinate system based on the permission category span of the target over-range permission class of each group of adjacent over-limit dialogue requests, determine a corresponding coordinate point of each over-limit dialogue request in the preset two-dimensional coordinate system in combination with a preset starting horizontal coordinate value, and fit the user's over-limit request permission line based on the corresponding coordinate points of all over-limit dialogue requests in the preset two-dimensional coordinate system;

[0042] The second drift matrix analysis unit is configured to analyze a second drift matrix based on the user's total claim authority line and the excess claim authority line.

[0043] Preferably, the second drift matrix analysis unit includes:

[0044] a first drift analysis subunit, configured to use a vector pointing from the coordinate value of each over-limit dialogue request in the total claim authority line to the coordinate value in the over-limit claim authority line as a first drift vector of each over-limit dialogue request;

[0045] a self-focusing vector calibration subunit, configured to use a vector in which the coordinate value corresponding to the immediately preceding dialogue request of each over-limit dialogue request in the total claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the total claiming authority line as a first self-focusing vector, a vector in which the coordinate value corresponding to the immediately succeeding dialogue request of each over-limit dialogue request in the total claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the total claiming authority line as a second self-focusing vector, a vector in which the coordinate value corresponding to the immediately preceding over-limit dialogue request of each over-limit dialogue request in the over-limit claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the over-limit claiming authority line as a third self-focusing vector, and a vector in which the coordinate value corresponding to the immediately succeeding over-limit dialogue request of each over-limit dialogue request in the over-limit claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the over-limit claiming authority line as a fourth self-focusing vector;

[0046] a second drift analysis subunit, configured to use the difference between the first self-aggregation vector and the third self-aggregation vector of each exceeding-limit dialogue request as the second drift vector of each exceeding-limit dialogue request;

[0047] a third drift analysis subunit, configured to use the difference between the second self-aggregation vector and the fourth self-aggregation vector of each exceeding-limit dialogue request as a third drift vector of each exceeding-limit dialogue request;

[0048] The drift matrix generating subunit is configured to generate a second drift matrix for all the exceeding-limit dialogue requests based on the first drift vector, the second drift vector, and the third drift vector of all the exceeding-limit dialogue requests.

[0049] Preferably, the drift trend marking submodule includes:

[0050] a drift trend marking unit, configured to locally link the first drift matrix and the second drift matrix with the complete authority representation graph and mark the real-time drift trend in the complete authority representation graph to obtain a real-time drift trend marking graph;

[0051] The authority range updating unit is used to update the current authority range in real time based on the real-time drift trend mark graph.

[0052] The present invention provides an intelligent rights management and dialogue method for a multi-platform client integrated large model service, including:

[0053] S1: Based on the account information of any platform received from any client, determine the node to which the corresponding user identity information belongs in the organizational structure, and determine the basic permission scope of the corresponding user identity information based on the node;

[0054] S2: Based on the platform type and client type of the received account information, a preset organization cross-platform client permission differentiation table is retrieved to determine a permission difference set for the corresponding user identity information under the corresponding platform type and the corresponding client type;

[0055] S3: Determine the current permission scope of the corresponding user identity information based on the static risk analysis results of the client device that received the account information, the permission difference set, and the basic permission scope;

[0056] S4: Analyze the two-dimensional drift information based on the dynamic risk analysis results of the client device that receives the account information and all the dialogue requests entered by the user, and update the current permission range in real time based on the two-dimensional drift information, and respond to the dialogue request based on the large model accessed by the platform and the latest permission range.

[0057] The present invention offers the following advantages over existing technologies: The basic permission determination module uses account information to identify the user's organizational node and then determines the basic permission scope, laying the foundation for permission management and ensuring that the user's initial permissions are standardized and consistent with the organizational structure. The platform and client differentiation module retrieves the permission differentiation table based on platform and client type to generate a permission difference set, meeting the permission differentiation requirements of different platform and client scenarios and making permission management more tailored to actual usage environments. The permission concretization module combines the client device static risk analysis results, the permission difference set, and the basic permission scope to accurately determine the current permission scope, comprehensively considering factors such as device risk, thereby enhancing the security and rationality of permission management. The permission dynamic update module generates two-dimensional drift information based on the device dynamic risk analysis results and conversation requests, and updates the current permission scope in real time based on the complete permission representation graph. Based on this information, the module responds to conversation requests using a large model accessed by the platform. This not only enables dynamic and flexible adjustment of permissions but also provides appropriate responses to users based on real-time permissions, improving the security and intelligence of interactions, effectively protecting organizational information security, and optimizing the user interaction experience.

[0058] Other features and advantages of the present invention will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures specifically pointed out in this application document.

[0059] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0061] Figure 1 A schematic diagram of an intelligent rights management and dialogue system for a multi-platform client integrated large model service in an embodiment of the present invention;

[0062] Figure 2 Schematic diagram of a basic authority determination module in an embodiment of the present invention;

[0063] Figure 3 Schematic diagram of the platform and client differentiation modules in an embodiment of the present invention;

[0064] Figure 4 Schematic diagram of a permission concretization module in an embodiment of the present invention;

[0065] Figure 5 Schematic diagram of a dynamic permission update module in an embodiment of the present invention. DETAILED DESCRIPTION

[0066] The preferred embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0067] Example 1:

[0068] The present invention provides an intelligent rights management and dialogue system for multi-platform client integrated large model services, referring to Figure 1 ,include:

[0069] A basic authority determination module is used to determine the node to which the corresponding user identity information belongs in the organizational structure based on the account information of any platform received from any client, and to determine the basic authority scope of the corresponding user identity information based on the node;

[0070] The platform and client differentiation module is used to retrieve the preset organization cross-platform client permission differentiation table based on the platform type and client type of the received account information, and determine the permission difference set of the corresponding user identity information under the corresponding platform type and the corresponding client type;

[0071] The permission concretization module is used to determine the current permission scope of the corresponding user identity information based on the device static risk analysis results of the client that receives the account information, the permission difference set, and the basic permission scope;

[0072] The dynamic permission update module is used to analyze the two-dimensional drift information based on the dynamic risk analysis results of the client device that receives the account information and all the dialogue requests entered by the user, and to update the current permission scope in real time based on the two-dimensional drift information, and to respond to the dialogue request based on the large model accessed by the platform and the latest permission scope.

[0073] In this embodiment, the platform type refers to the type of platform to which the user's login account belongs, such as an office platform, a social platform, etc., such as the platform on which the Netskyper client relies to carry out networking, SaaS acceleration and other services.

[0074] In this embodiment, the client type refers to the type of device used by the user to log in, such as Windows, Mac, and Linux for desktops, and iOS and Android for mobile devices. For example, an employee logs in to the system using a mobile phone (iOS) or a computer (Windows).

[0075] In this embodiment, the account information is the information used by the user to log in to any platform client, such as user name, password, mobile phone number, etc. For example, an employee uses a mobile phone number and password to log in to the Netskyper client.

[0076] In this embodiment, the user identity information is obtained by retrieving the organization member pre-registration information through account information, and is used to identify the user's identity in the organization, such as the employee's work number, name and other related information in the company.

[0077] In this embodiment, the organizational structure is a relationship structure such as the hierarchy and departmental division of members within an organization. For example, a company is divided into different departments, and each department has a hierarchical relationship.

[0078] In this embodiment, the node to which the user identity information belongs in the organizational structure refers to the specific position of the user in the organizational structure, such as a project team in the company's marketing department.

[0079] In this embodiment, the basic permission range is the initial permission determined based on the node to which the user belongs in the organizational structure. For example, ordinary employees in the marketing department can access department information but do not have the right to view financial data.

[0080] In this embodiment, the preset organization cross-platform client permission differentiation table is a pre-set table that records user permission difference information under different platforms and client types, such as stipulating that iOS clients have different permissions for certain functions than Windows clients.

[0081] In this embodiment, the permission difference set is retrieved from the above table and summarizes the permission differences for a specific user under the corresponding platform and client type. For example, when a specific user uses a platform on a mobile terminal, some operation permissions are different from those on the desktop terminal.

[0082] In this embodiment, the static risk analysis result of the client device is obtained by static risk assessment of the client device, including risk score value and risk items. For example, the weak password setting of the account policy in the system configuration is a risk item affecting the score.

[0083] In this embodiment, the current permission range is the actual user permission determined by comprehensively considering the basic permission range, permission difference set and the static risk analysis result of the device. If the device risk is high, the basic permission may be restricted and the current permission may be adjusted.

[0084] In this embodiment, the client's device dynamic risk analysis results reflect the real-time dynamic risk of the device, such as real-time security vulnerability detection, security patch update status, etc. If a high-risk security vulnerability is found, it indicates that the device dynamic risk is high.

[0085] In this embodiment, all dialogue requests input by the user refer to all questions and other information input by the user when interacting with the system, such as questions asked by the user in the dialogue window about business data, function operation methods, etc.

[0086] In this embodiment, the large model accessed by the platform is such as the DeepSeek service accessed by the Netskyper client, which provides functions such as text conversation and history record management for users to ask questions and obtain answers.

[0087] In this embodiment, a response is given to the dialogue request based on the large model accessed by the platform and the latest permission range, which means that the dialogue request is processed and responded to using the access large model according to the user's latest permission. If the user's permission is low, the large model will not provide answers to sensitive information.

[0088] Example 2:

[0089] On the basis of Example 1, the basic authority determination module, refer to Figure 2 ,include:

[0090] The registration information retrieval submodule is used to retrieve the pre-registration information of all members under the organizational structure based on the account information of any platform received from any client, and obtain the corresponding user identity information;

[0091] The structure database search submodule is used to search the organizational structure database based on the corresponding user identity information to determine the corresponding department;

[0092] The architecture belonging determination submodule is used to determine the node to which the corresponding user identity information belongs in the organizational structure based on the corresponding department;

[0093] The predefined permission association submodule is used to determine the predefined permission range of the node to which it belongs, which is used as the basic permission range corresponding to the user identity information.

[0094] In this embodiment, the pre-registration information of all members under the organizational structure refers to the relevant information pre-registered in the system by all members of the organization, including name, contact information, position, etc., which is used to identify the identity of members and associate their relevant attributes in the organization, such as the personal information and position information filled in and entered into the system by new employees when they join the company.

[0095] In this embodiment, the organizational structure database is a database that stores information related to the organizational structure, covering department settings, hierarchical relationships, job configurations, etc., providing data support for determining the user's position and authority in the organization, just like an electronic archive that records the company's departments, positions and their relationships.

[0096] In this embodiment, the department to which the user belongs is the specific department to which the user belongs in the organizational structure, such as the company's finance department, human resources department, technology research and development department, etc., which clarifies the user's business division of labor in the organization.

[0097] In this embodiment, determining the node to which the corresponding user identity information belongs in the organizational structure based on the corresponding department means further determining the user's precise position or level in the organizational structure based on the department to which the user belongs. For example, in the technical R&D department, determining that the user belongs to a specific R&D group or project team.

[0098] In this embodiment, the predefined authority scope of the node refers to the authority boundaries pre-set for a specific node in the organizational structure. For example, a member of a project team in the technical R&D department may have predefined permissions that include accessing project-related information and using specific development tools, but not having the right to modify the project budget.

[0099] The beneficial effects of the above technologies are as follows: the registration information retrieval submodule retrieves the pre-registration information based on the account information to obtain the user identity information, accurately identifies and matches the user identity, and lays a solid foundation for authority determination. The architecture database retrieval submodule retrieves the organizational architecture database based on the user identity information to determine the department to which it belongs, accurately locates the user's departmental affiliation in the organization, and closely links authority management with the organizational structure. The architecture affiliation determination submodule clarifies the node to which it belongs based on the department to which it belongs, further refines the user's position in the organizational structure, and makes authority allocation more targeted and reasonable. The predefined authority association submodule sets the predefined authority range of the node to which it belongs as the user's basic authority range, provides a clear basis and standard for authority setting, reduces human arbitrariness, and ensures consistent authority management specifications. Overall, this process improves the accuracy and efficiency of authority management, helps organizations to allocate and manage authority in an orderly manner, and ensures organizational information security and smooth business processes.

[0100] Example 3:

[0101] Based on Example 1, the platform and client differentiation modules, refer to Figure 3 ,include:

[0102] The type determination submodule is used to determine the platform type and client type of the received account information;

[0103] The permission difference information retrieval submodule is used to retrieve the preset organization cross-platform client permission differentiation table based on platform type and client type to obtain all permission difference information;

[0104] The permission difference information aggregation submodule is used to aggregate all permission difference information as a permission difference set of corresponding user identity information under the corresponding platform type and the corresponding client type.

[0105] In this embodiment, permission difference information refers to information obtained from a preset cross-platform client permission differentiation table based on platform type and client type, reflecting the differences in permissions granted to corresponding user identity information under different platforms and client environments. For example, when using a certain platform on a PC (Windows), a user can perform advanced file editing operations, but on the same platform on a mobile device (iOS), the user can only perform simple file viewing and annotation operations. This difference in operating permissions under different client types is the permission difference information.

[0106] The beneficial effects of the above technology are as follows: the type determination submodule can clearly identify the platform type and client type of the account information received, and find the right direction for the subsequent precise differentiated permission management, so that the permission settings can fit the characteristics of different platforms and clients. The permission difference information retrieval submodule obtains all permission difference information from the preset organization's cross-platform client permission differentiation table based on the platform and client type, providing detailed data support for the implementation of differentiated permission management and ensuring that permission adjustments are in accordance with regulations. The permission difference information aggregation submodule integrates all the obtained permission difference information into a permission difference set, which is convenient for unified management and application, making the permission differences of the corresponding user identity information under the corresponding platform and client clear at a glance, and facilitating the subsequent combination of other factors to further determine the user's final permission range. Through the collaborative work of this series of submodules, refined management of user permissions under different platforms and clients is achieved, the permission requirements of diverse scenarios are met, the flexibility and adaptability of system permission management are improved, and it helps organizations to more reasonably allocate user permissions according to the usage scenarios of different platforms and clients, ensuring information security and efficient business development.

[0107] Example 4:

[0108] Based on Example 1, the permission concretization module, refer to Figure 4 ,include:

[0109] The static risk assessment submodule is used to obtain the client's device static risk score and all device static risk items as the client's device static risk analysis results based on the client's system configuration, application, application application permissions, firewall configuration, IP address, and open ports of the client receiving the account information;

[0110] The risk permission constraint submodule is used to determine the permission constraint factors of all device static risk items based on the client's device static risk score value. Based on the permission constraint factors of all device static risk items and all device static risk items in the device static risk analysis results, the risk item-permission range association table is retrieved and summarized to obtain the permission constraint set;

[0111] The permission update submodule is used to update the basic permission range based on the permission constraint set and the permission difference set, and obtain the current permission range corresponding to the user identity information.

[0112] In this embodiment, the client's system configuration includes account policies, access control settings, network service settings, and other factors, which affect device security. Applications refer to various types of software installed by the client. Application permissions are the operating permissions that applications request from the client. Firewall configuration is used to set network access rules. The IP address identifies the device on the network, and open ports determine which network connections can access the device. For example, system configurations with weak account policies, applications from untrusted sources, excessive and unnecessary permissions requested by an application, vulnerabilities in the firewall configuration, IP addresses exposed to high-risk networks, and excessive open ports can all pose risks.

[0113] In this embodiment, the client device static risk score is a quantitative assessment of the static risk of the client device, with higher scores indicating a higher risk. All device static risk items refer to specific risk points discovered during the assessment of the client's system configuration, applications, and other aspects. For example, a weak password setting in the account policy in the system configuration is a risk item, which is assigned a specific risk score. The device static risk score is calculated by combining all risk items.

[0114] In this embodiment, the permission constraint factors for all static risk items of the device are determined based on the client's device static risk score. Specifically, a coefficient is set for each risk item based on the risk score (the permission constraint factor is determined based on the preset coefficient for each risk item, i.e., the product of the client's device static risk score and the preset coefficient for each risk item is used as the permission constraint factor for the corresponding risk item). This is used to measure the degree of permission restriction imposed by the risk item. For example, a risk item with a high risk score may have a larger permission constraint factor, indicating a stronger permission restriction.

[0115] In this embodiment, based on the permission constraint factors of all device static risk items and all device static risk items in the device static risk analysis results, the risk item-permission range association table is retrieved and summarized to obtain a permission constraint set. Specifically, the permission constraint factor for each risk item is combined with the specific risk item, and the corresponding permission restriction information is searched in the risk item-permission range association table. This information is then summarized to form a permission constraint set. For example, if a risk item has a permission constraint factor of 0.8, and the association table shows that this risk item corresponds to a file deletion permission that requires restriction, multiple pieces of such information are summarized to form a permission constraint set.

[0116] In this embodiment, the risk item-permission range association table is pre-set and records the corresponding permission restriction ranges for various device static risk items under different permission restriction factor ranges. For example, the table stipulates that if there is a risk item indicating that the application source is untrustworthy and its permission restriction factor is 0.6, the access rights to sensitive data related to the application will be restricted.

[0117] In this embodiment, the basic permission range is updated based on the permission constraint set and the permission difference set to obtain the current permission range corresponding to the user identity information. That is, the permission constraints caused by device risks and the permission differences caused by different platforms and client types are comprehensively considered, and the user's initial basic permission range is adjusted to ultimately determine the permission range that the user currently actually has. For example, if the basic permission includes the file deletion permission, but the permission constraint set restricts this permission, and the permission difference set stipulates that this permission does not exist under a specific client type, then the current permission range does not include the file deletion permission.

[0118] The beneficial effects of the above technology are as follows: the static risk assessment submodule comprehensively considers multiple factors such as the client's system configuration and application programs to derive the device's static risk score and all risk items, comprehensively and meticulously assessing the static risk status of the client device and providing an accurate risk basis for subsequent permission adjustments. The risk permission constraint submodule determines the permission constraint factor of each risk item based on the risk score value, and obtains a permission constraint set by combining the risk item retrieval association table, closely associating the device risk with the permission constraint, achieving scientific restrictions on permissions due to risk, and ensuring reasonable management and control of permissions due to device risks. The permission update submodule updates the basic permission range based on the permission constraint set and the permission difference set, comprehensively considering the impact of device risks and platform-client differences on permissions, accurately determining the user's current permission range, and making permission management more in line with actual conditions. This permission concretization method enhances the security and accuracy of permission management, effectively reduces security risks caused by potential device risks, while taking into account platform and client differences, ensuring information security and stable operation of the system in different environments.

[0119] Example 5:

[0120] Based on Example 4, the static risk assessment submodule includes:

[0121] The system configuration risk assessment unit is used to compare the account policies, access control settings, and network service settings in the system configuration with the preset security configuration benchmark to obtain all risk items of the system configuration, and assign scores to the system configuration comparison results based on preset risk assessment rules to obtain the risk score value of the system configuration;

[0122] An application risk assessment unit is used to assign a risk value to the source of each application installed on the client based on the application source risk assessment rules, and to obtain a risk score value and all risk items for each application by combining the validity of each application's digital signature and the degree of matching with malware characteristics;

[0123] The application permission risk assessment unit is used to determine the rationality of the permissions applied for by the corresponding application based on the functional requirements of all applications installed on the client, and obtain the risk score value and all risk items of the application permissions;

[0124] The device static risk aggregation unit is used to analyze the risk score value and all risk items of the client's firewall configuration, the risk score value and all risk items of the IP address and open port, and combine the risk score value and all risk items of the system configuration, the risk score value and all risk items of all applications, and the risk score value and all risk items of application permissions to obtain the device static risk score value and all device static risk items of the client that receives the account information.

[0125] In this embodiment, account policy refers to the client's rules regarding account creation, password setting, login verification, etc., such as whether a strong password is required, the number of logins allowed, etc.; access control settings determine which users or processes can access specific resources, such as restricting certain users' access to important files; network service settings involve parameters related to network services provided or used by the client, such as opening or closing specific network ports, setting network protocols, etc.

[0126] In this embodiment, the preset security configuration benchmark is a set of pre-established standard configurations that represent a secure system configuration state and serve as a reference for evaluating the security of the client system configuration. For example, the standard setting stipulates that passwords must contain uppercase and lowercase letters, numbers, and special characters, and must be at least 8 characters long.

[0127] In this embodiment, the account policies, access control settings, and network service settings in the system configuration are compared with the preset security configuration benchmarks to identify any non-compliance with the benchmarks. These non-compliance items represent all risk items in the system configuration. For example, if the password set in the account policy does not meet the complexity requirements of the preset benchmark, this is a risk item.

[0128] In this embodiment, the preset risk assessment rules are a set of pre-defined scoring criteria that are used to determine a score for each risk item based on the comparison results of the system configuration with the preset security configuration benchmark, thereby quantifying the risk level of the system configuration. For example, the risk item of weak password settings is assigned a risk score of 5 points according to the rules.

[0129] In this embodiment, the system configuration comparison results are scored based on preset risk assessment rules. Each risk item is assigned a corresponding score according to the rules, and these scores are then accumulated to obtain the system configuration risk score. For example, if there are three risk items after comparison, with scores of 3, 2, and 5 respectively, the system configuration risk score is 3 + 2 + 5 = 10 points.

[0130] In this embodiment, the application source risk assessment rules are criteria specifically used to determine the security of the application source, such as whether the application comes from official and formal channels, whether it has passed security certification, etc.

[0131] In this embodiment, a risk score is assigned to the source of each application installed on the client based on the application source risk assessment rules. Applications from untrusted sources may be assigned a higher risk score. For example, an application downloaded from an unofficial app store might be assigned a risk score of 8 points, while an application downloaded from an official, legitimate channel might be assigned a risk score of 2 points.

[0132] In this embodiment, the validity of the digital signature of each application refers to the validity of the digital signature of the application. A valid digital signature indicates that the application has not been tampered with and the source is reliable. For example, an application signed by an authoritative organization has a higher digital signature validity.

[0133] In this embodiment, the degree of match with malware signatures refers to the degree of similarity between the application installed on the client and known malware signatures. Using a preset model (trained by comparing the code and behavior patterns of a large number of different applications with known malware signatures), the application's code and behavior patterns are compared with the signatures in the malware signature library. The higher the match, the greater the risk that the application may be malicious.

[0134] In this embodiment, the application source risk assessment rules are combined to assign a risk value to the application source, the validity of the digital signature, and the degree of matching with malware features. A comprehensive risk score is calculated for each application (e.g., using a summation method), and all relevant risk items are determined. For example, an application downloaded from an unofficial channel (risk assignment of 8 points), with an invalid digital signature (reduced credibility), and matching some malware features, would have a comprehensive risk score of 15 points. Risk items include untrustworthy source, invalid digital signature, and suspected malware feature match.

[0135] In this embodiment, the rationality of the permissions requested by the corresponding application is judged based on the functional requirements of all applications installed on the client, and the risk score value and all risk items of the application permissions are obtained: the system will evaluate the rationality of the permissions requested by each application installed on the client based on its own functional requirements. For example, a simple weather forecast application, whose core function is to obtain weather information and display it to the user. If it applies for permissions such as access to the user's contact list, call logs, etc., which are not directly related to the function of obtaining weather information, then it is unreasonable for this application to apply for these permissions.

[0136] By making such a judgment for each application, a risk score value is assigned to each application's permission application. For the weather forecast application mentioned above that makes unreasonable permission applications, a higher risk score value may be given, such as 8 points (assuming the full score is 10 points, the higher the score, the greater the risk). At the same time, these unreasonable permission applications are recorded as risk items, such as "the weather forecast application applies for contact list access rights that are not related to its function" is a risk item. By combining the evaluation results of all applications, the risk score value of the application permissions and all risk items are obtained.

[0137] In this embodiment, the client's firewall configuration is analyzed separately to obtain its risk score and all risk items. For example, if the firewall rules are set too loosely, it will result in a high risk score and corresponding risk items. The IP address and open ports are analyzed to obtain their risk score and all risk items. For example, if the use of a public network IP or the opening of too many unnecessary ports brings risks. Then, the system configuration, all applications, and application permissions are combined with their respective risk scores and all risk items to calculate the static risk score of the client device that received the account information and all the static risk items of the device. For example, if the system configuration risk score is 10 points, the application comprehensive risk score is 20 points, the application permission risk score is 5 points, the firewall risk score is 8 points, and the IP address and open port risk score is 7 points, the client device static risk score after aggregation is 10 + 20 + 5 + 8 + 7 = 50 points. At the same time, the risk items of all individual items are aggregated to form the total static risk items of the client device.

[0138] The beneficial effects of these technologies are as follows: The system configuration risk assessment unit carefully compares key settings in the system configuration with pre-set security configuration baselines, not only comprehensively identifying all risk items but also assigning a risk score using pre-set risk assessment rules. This provides a quantitative basis for assessing the security of the system's basic configuration, allowing administrators to clearly understand the risk level at the system configuration level. The application risk assessment unit comprehensively assesses the potential risk of each application based on multiple factors, including application source, digital signature validity, and malware signature match. This determines a risk score and risk items, helping to identify potentially risky applications and safeguard the client application ecosystem. The application permission risk assessment unit determines the appropriateness of permission requests based on application functional requirements, generating a risk score and risk items for application permissions. This prevents applications from requesting excessive permissions, effectively protecting user privacy and system security. The device static risk aggregation unit integrates risk scores and risk items from various aspects, including firewall configuration, IP addresses and open ports, system configuration, applications, and application permissions, to generate a static risk score for client devices and static risk items for all devices. This provides a comprehensive picture of static risks on client devices, laying a solid foundation for subsequent targeted risk mitigation measures and comprehensively improving overall system security.

[0139] Example 6:

[0140] Based on Example 1, the permission dynamic update module, refer to Figure 5 ,include:

[0141] A first risk analysis submodule, configured to generate a first risk vector based on all security vulnerability items and a risk value of each security vulnerability item in the real-time security vulnerability screening result in the device dynamic risk analysis result of the client receiving the account information;

[0142] a second risk analysis submodule, configured to determine all unupdated security patches based on the real-time security patch update status in the device dynamic risk analysis result of the client receiving the account information, and generate a second risk vector based on pre-assigned scores of all unupdated security patches;

[0143] A third risk analysis submodule, configured to generate a third risk vector based on the matching degree between the sensitivity and encryption level of all group sensitive information transmitted in the latest period in the dynamic risk analysis result of the device of the client receiving the account information;

[0144] A drift matrix generation submodule, configured to generate a first drift matrix based on the first risk vector, the second risk vector, and the third risk vector;

[0145] A second drift analysis submodule, configured to analyze a second drift matrix based on all dialogue requests input by the user;

[0146] A drift trend marking submodule, configured to update the current authority range in real time based on the first drift matrix and the second drift matrix;

[0147] The large model response submodule is used to respond to dialogue requests based on the large model connected to the platform and the latest permission range;

[0148] The two-dimensional drift information includes a first drift matrix and a second drift matrix.

[0149] In this embodiment, a first risk vector is generated based on all security vulnerability items in the real-time security vulnerability screening results in the dynamic risk analysis results of the device of the client that receives the account information and the risk value of each security vulnerability item. This means that the various security vulnerability items existing in the client detected in real time and the risk value assessed for each vulnerability are converted into a vector form according to certain rules. For example, if three security vulnerability items are detected, and the risk values ​​are high (assuming a corresponding value of 5), medium (assuming a corresponding value of 3), and low (assuming a corresponding value of 1), the first risk vector may be expressed as [5, 3, 1], thereby quantifying the risk status of security vulnerabilities.

[0150] In this embodiment, based on the real-time security patch update status in the dynamic risk analysis results of the client device that receives the account information, all unupdated security patches are identified, and a second risk vector is generated based on the pre-assigned scores of all unupdated security patches. Specifically, by reviewing the client's real-time security patch update status, unupdated security patches are identified, and each unupdated patch is assigned a score based on pre-defined rules. These scores are then organized into a vector in a specific order. For example, if two unupdated security patches are found, and the high-risk unupdated patch is pre-assigned a score of 8 and the medium-risk unupdated patch is pre-assigned a score of 5, then the second risk vector might be [8, 5], representing the degree of risk posed by the unupdated security patches.

[0151] In this embodiment, a third risk vector is generated based on the matching degree of sensitivity and encryption degree of all groups of sensitive information transmitted in the latest cycle in the dynamic risk analysis results of the client device that receives the account information. That is, for the sensitive information transmitted by the client in the latest cycle, the matching degree between its sensitivity (such as highly sensitive, moderately sensitive, and low sensitive) and encryption degree (such as well-encrypted, partially encrypted, and unencrypted) is evaluated, and this matching degree is converted into a numerical value and formed into a vector. For example, two groups of sensitive information are transmitted, the first group is highly sensitive but well-encrypted, and the matching degree is set to 2, and the second group is moderately sensitive but insufficiently encrypted, and the matching degree is set to -1. The third risk vector may be [2, -1], reflecting the risk status of sensitive information transmission.

[0152] In this embodiment, a first drift matrix is ​​generated based on the first risk vector, the second risk vector, and the third risk vector. The three vectors representing different risk dimensions are combined according to certain matrix generation rules to form a matrix. For example, if the first risk vector is [5, 3, 1], the second risk vector is [8, 5], and the third risk vector is [2, -1], the generated first drift matrix may be:

[0153] (Here, zeros are added to form a matrix when the vector length is insufficient).

[0154] The beneficial effects of the above technology include: multiple risk analysis submodules analyze device dynamic risks from different dimensions. The first risk analysis submodule generates a first risk vector based on security vulnerability items and risk values, accurately reflecting the device's real-time vulnerability risk. The second risk analysis submodule generates a second risk vector based on unupdated security patches and their assigned scores, focusing on the potential risks posed by unupdated patches. The third risk analysis submodule generates a third risk vector based on the matching degree of sensitive information sensitivity and encryption level, ensuring data transmission security. This enables a more comprehensive and detailed device risk assessment. The drift matrix generation submodule integrates these risk vectors to generate a first drift matrix, quantifying and integrating complex risk information. The second drift analysis submodule generates a second drift matrix based on user conversation requests, taking into account the impact of user behavior on permissions. The drift trend marking submodule combines the two drift matrices to update permission ranges in real time. This allows for dynamic adjustment of permissions based on device risk and user behavior, improving system security and adaptability. The large model response submodule utilizes the platform's large model and the latest permission ranges to provide responses, ensuring both response quality and interaction security and compliance, enhancing the user experience.

[0155] Example 7:

[0156] Based on Example 6, the second drift analysis submodule includes:

[0157] A first permission line fitting unit is configured to analyze the target permission classes of all dialogue requests entered by the user and the request depth of each target permission, determine the ordinate value of each dialogue request in a preset two-dimensional coordinate system based on the request depth of the target permissions of all dialogue requests, determine the abscissa difference between each group of adjacent dialogue requests in the preset two-dimensional coordinate system based on the permission category span of the target permission classes of each group of adjacent dialogue requests, determine the corresponding coordinate point of each dialogue request in the preset two-dimensional coordinate system in combination with a preset starting abscissa value, and fit the user's total requested permission line based on the corresponding coordinate points of all dialogue requests in the preset two-dimensional coordinate system;

[0158] an over-limit conversation request screening unit, configured to screen out, from all conversation requests input by the user, all conversation requests that do not meet the authority range of the corresponding user identity information at the corresponding moment, as all over-limit conversation requests;

[0159] A second permission line fitting unit is configured to determine a vertical coordinate value of each over-limit dialogue request in a preset two-dimensional coordinate system based on the request depth of the target over-range permission of all over-limit dialogue requests, determine a horizontal coordinate difference between each group of adjacent over-limit dialogue requests in the preset two-dimensional coordinate system based on the permission category span of the target over-range permission class of each group of adjacent over-limit dialogue requests, determine a corresponding coordinate point of each over-limit dialogue request in the preset two-dimensional coordinate system in combination with a preset starting horizontal coordinate value, and fit the user's over-limit request permission line based on the corresponding coordinate points of all over-limit dialogue requests in the preset two-dimensional coordinate system;

[0160] The second drift matrix analysis unit is configured to analyze a second drift matrix based on the user's total claim authority line and the excess claim authority line.

[0161] In this embodiment, the target permission class of all dialogue requests entered by the user and the request depth of each target permission are analyzed. This means that each dialogue request entered by the user is interpreted to clarify what type of permission the user wants to obtain (target permission class) and the degree to which the user desires to obtain the permission (request depth). For example, a user asks "Can I obtain full control of financial statements?" Here, "obtaining full control of financial statements" is the target permission class. If the user's desire is high based on the tone of the question, the degree of repetition, etc., a higher request depth value can be assigned. For example:

[0162] Based on the importance of the request content: If an employee asks, "Can I see a detailed progress report on this quarter's core company project (including sensitive data)?", since this core project progress report involves important company business information and could significantly impact the employee's work decisions, this request can be considered high-depth and scored 8 out of 10. In contrast, if the employee simply asks, "Can I see a general company announcement?", which has a relatively small impact on work, the request depth might be set at 3.

[0163] Based on the frequency of requests: If an employee repeatedly asks, "How can I get access to advanced data analytics tools?" this frequency indicates a high level of desire for this access, and the depth of the request can be increased accordingly. For example, the depth of the request can be set at 5 for the first request, and then increase by 1 point for each subsequent request, reaching 7 for the third request.

[0164] The process of determining the span of permission categories is as follows:

[0165] Based on the difference in permission levels: Assume that enterprise system permissions are divided into general permissions, intermediate permissions and advanced permissions. The employee first requests "I can view general documents within the department", which is a general permission. Then he requests "I want to obtain editing permissions for cross-departmental project data", and cross-departmental project data editing permissions are advanced permissions. From general document viewing permissions to cross-departmental project data editing permissions, the permission level difference is large, and the permission category span can be set to a larger value, such as 7 points (out of 10 points). If the employee then requests "I want to view the summary report of the cross-departmental project", although it is also a cross-departmental permission, the permission level difference from editing permissions to viewing summary report permissions is relatively small, and the permission category span may be set to 4 points.

[0166] In this embodiment, the ordinate value of each dialog request in a preset two-dimensional coordinate system is determined based on the request depth of the target permission of all dialog requests. The ordinate represents the request depth; the higher the request depth, the larger the ordinate value. The abscissa difference is determined based on the permission category span of the target permission class of each group of adjacent dialog requests. For example, if two adjacent requests, one for file reading permission and the other for file editing permission, have a relatively small span between these two permission categories, the abscissa difference is also small. Combined with the preset starting abscissa value, the corresponding coordinate point of each dialog request in the preset two-dimensional coordinate system can be determined. For example, if the starting abscissa value is set to 0, the request depth of the first request is 3 (ordinate value), and there is no span with the starting point (the abscissa difference is 0), then the coordinate point is (0, 3). The permission category span of the second request is 0.4 with the first request, and the request depth of the second request is 4, then the coordinate point of the second request is (0.4, 4).

[0167] In this embodiment, the user's total request authority line is fitted based on the corresponding coordinate points of all dialogue requests in the preset two-dimensional coordinate system, and all the coordinate points are sequentially connected to form a curve through a mathematical method.

[0168] In this embodiment, all conversation requests that do not meet the permissions of the corresponding user's identity information at the corresponding time are filtered out. That is, the conversation request issued by the user is compared with the user's current permissions to identify those requests that exceed their permissions. For example, if a user's current permissions only allow viewing of ordinary documents, but they request permission to modify an encrypted document, this request is considered a conversation request that does not meet their permissions.

[0169] In this embodiment, for the filtered out-of-limit dialog requests, a ordinate value is determined based on the requested depth of the target out-of-range permissions for all out-of-limit dialog requests. This is similar to the determination of the total requested permission line previously described, but only for out-of-limit requests. A horizontal coordinate difference is determined based on the permission category span of the target out-of-range permission class for each group of adjacent out-of-limit dialog requests. Combined with a preset starting horizontal coordinate value, the corresponding coordinate point of each out-of-limit dialog request in the preset two-dimensional coordinate system is determined. For example, if the first out-of-limit request has a request depth of 4 (ordinate value) and no span with the starting point (the horizontal coordinate difference is 0), and the starting horizontal coordinate value is set to 0, the coordinate point of this out-of-limit request is (0, 4).

[0170] In this embodiment, the user's over-limit request authority line is fitted based on the corresponding coordinate points of all over-limit dialogue requests in the preset two-dimensional coordinate system, and the coordinate points of these over-limit dialogue requests are connected into a curve using the same mathematical fitting method.

[0171] The beneficial effects of the above technology are as follows: the first permission line fitting unit determines the coordinate points and fits the total permission request line by analyzing the target permission class, request depth and permission category span of the dialogue request, which can clearly present the user's overall permission request trend and facilitate understanding the trend of the user's regular permission demand. The over-limit dialogue request screening unit accurately filters out dialogue requests that do not meet the current permission range, clearly identifies abnormal permission requests, and provides the system with the possibility of timely discovering potential risks. The second permission line fitting unit also fits the over-limit request permission line based on the over-range permission class, request depth, etc. for over-limit dialogue requests, and depicts the specific trajectory of the over-limit permission request in detail, making the over-limit situation more intuitive. The second drift matrix analysis unit combines the total request permission line and the over-limit request permission line to analyze the second drift matrix, and combines the information of the two to provide strong data support for in-depth analysis of abnormal changes in user permission requests, which helps the system to adjust the permission strategy more scientifically and ensure system security and stability.

[0172] Example 8:

[0173] Based on Example 7, the second drift matrix analysis unit includes:

[0174] a first drift analysis subunit, configured to use a vector pointing from the coordinate value of each over-limit dialogue request in the total claim authority line to the coordinate value in the over-limit claim authority line as a first drift vector of each over-limit dialogue request;

[0175] a self-focusing vector calibration subunit, configured to use a vector in which the coordinate value corresponding to the immediately preceding dialogue request of each over-limit dialogue request in the total claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the total claiming authority line as a first self-focusing vector, a vector in which the coordinate value corresponding to the immediately succeeding dialogue request of each over-limit dialogue request in the total claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the total claiming authority line as a second self-focusing vector, a vector in which the coordinate value corresponding to the immediately preceding over-limit dialogue request of each over-limit dialogue request in the over-limit claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the over-limit claiming authority line as a third self-focusing vector, and a vector in which the coordinate value corresponding to the immediately succeeding over-limit dialogue request of each over-limit dialogue request in the over-limit claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the over-limit claiming authority line as a fourth self-focusing vector;

[0176] a second drift analysis subunit, configured to use the difference between the first self-aggregation vector and the third self-aggregation vector of each exceeding-limit dialogue request as the second drift vector of each exceeding-limit dialogue request;

[0177] a third drift analysis subunit, configured to use the difference between the second self-aggregation vector and the fourth self-aggregation vector of each exceeding-limit dialogue request as a third drift vector of each exceeding-limit dialogue request;

[0178] The drift matrix generating subunit is configured to generate a second drift matrix for all the exceeding-limit dialogue requests based on the first drift vector, the second drift vector, and the third drift vector of all the exceeding-limit dialogue requests.

[0179] In this embodiment, the first drift vectors, second drift vectors, and third drift vectors of all over-limit dialog requests are combined according to a certain rule to generate a second drift matrix. For example, suppose there are three over-limit dialog requests, with their first drift vectors being [1, 2], [3, -1], and [-2, 4], their second drift vectors being [0, 1], [2, -2], and [1, 3], and their third drift vectors being [2, -1], [-1, 2], and [3, 1]. Arranging these vectors in columns might yield the following second drift matrix:

[0180] The beneficial effects of the above technology are as follows: The first drift analysis subunit uses the vector pointing to the coordinate value of the over-limit request line as the first drift vector, visually displaying the direction and degree of change from normal to over-limit requests, providing basic guidance for analysis. The self-contained vector calibration subunit defines four self-contained vectors, considering the relationship between total requests and the adjacent requests before and after the over-limit request line, providing multi-dimensional data to facilitate in-depth analysis of the consistency and changing trends of permission request behavior. The second drift analysis subunit calculates the difference between the first and third self-contained vectors to obtain the second drift vector, exploring the differences in the trajectory of adjacent requests from normal to over-limit permission requests, helping the system to detect abnormal rhythmic changes. The third drift analysis subunit calculates the difference between the second and fourth self-contained vectors to generate the third drift vector, deepening the analysis of permission request changes from another adjacent relationship perspective and meticulously depicting the dynamic changes in permission usage. The drift matrix generation subunit integrates the three types of drift vectors to generate the second drift matrix, presenting comprehensive change information in matrix form, allowing the system to fully understand the over-limit situation and provide a basis for permission adjustments.

[0181] Example 9:

[0182] Based on Example 6, the drift trend marking submodule includes:

[0183] a drift trend marking unit, configured to locally link the first drift matrix and the second drift matrix with the complete authority representation graph and mark the real-time drift trend in the complete authority representation graph to obtain a real-time drift trend marking graph;

[0184] The authority range updating unit is used to update the current authority range in real time based on the real-time drift trend mark graph.

[0185] In this embodiment, the complete permission representation diagram is a graphical representation that comprehensively displays all permissions in the system and their interrelationships. Partially linking these two matrices with the complete permission representation diagram means corresponding the change information represented by the matrix to the relevant part of the complete permission representation diagram. For example, the risk change represented by an element in the first drift matrix may correspond to the risk change direction of a certain type of permission in the complete permission representation diagram, and the user permission request change reflected by the vector in the second drift matrix also corresponds to the corresponding permission area in the diagram. Mark the real-time drift trend presented by these changes in the complete permission representation diagram, such as using arrows or color changes to intuitively show which permissions are changing in what direction, and finally obtain a real-time drift trend marking diagram.

[0186] In this embodiment, the current permission range is updated in real time based on the real-time drift trend marker graph, that is, the user's current permissions are adjusted according to the permission change trend shown in the marker graph. If the marker graph shows that a certain permission area shows a drift trend that needs to be restricted due to increased device risks or abnormal user permission requests, the system will reduce the permission range in real time; conversely, if the trend indicates that certain permissions can be appropriately relaxed, the permission range will be expanded accordingly. For example, if the real-time drift trend marker graph shows that the user's access rights to a certain type of data are tightening due to the increased risk of device security vulnerabilities, the system will reduce the user's access level to this type of data in real time, thereby ensuring that the permission range is consistent with the device risk and user behavior, and ensuring the security and stable operation of the system.

[0187] The beneficial effects of the above technology are as follows: the drift trend marking unit partially links the first and second drift matrices with the complete permission representation diagram and marks the real-time drift trend, generating a real-time drift trend marking diagram, and intuitively presenting the complex matrix data in a visual form. This enables managers to quickly gain insight into the real-time changing direction and trend of permission usage without the need for in-depth data analysis, greatly improving the efficiency of information acquisition. At the same time, by combining with the complete permission representation diagram, the position of the drift trend in the overall permission system is clearly defined, making it easier to understand its impact on the permission architecture from a global perspective. The permission scope update unit updates the current permission scope in real time based on the real-time drift trend marking diagram, closely adapting to the dynamic risks of the device and changes in user behavior, and promptly responding to security threats or reasonable permission requirements to enhance system security and adaptability. Moreover, permissions are updated based on the intuitive marking diagram, making permission adjustments transparent and traceable, facilitating subsequent review and optimization of permission management strategies.

[0188] Example 10:

[0189] The present invention provides an intelligent rights management and dialogue method for a multi-platform client integrated large model service, including:

[0190] S1: Based on the account information of any platform received from any client, determine the node to which the corresponding user identity information belongs in the organizational structure, and determine the basic permission scope of the corresponding user identity information based on the node;

[0191] S2: Based on the platform type and client type of the received account information, a preset organization cross-platform client permission differentiation table is retrieved to determine a permission difference set for the corresponding user identity information under the corresponding platform type and the corresponding client type;

[0192] S3: Determine the current permission scope of the corresponding user identity information based on the static risk analysis results of the client device that received the account information, the permission difference set, and the basic permission scope;

[0193] S4: Analyze the two-dimensional drift information based on the dynamic risk analysis results of the client device that receives the account information and all the dialogue requests entered by the user, and update the current permission range in real time based on the two-dimensional drift information, and respond to the dialogue request based on the large model accessed by the platform and the latest permission range.

[0194] The beneficial effects of the above technologies are: determining the user's node in the organizational structure and basic permission range based on account information, accurately allocating initial permissions based on roles, and ensuring that permission management complies with the organizational structure and business logic. Combining the platform and client type to determine the permission difference set, meet the personalized permission requirements in different scenarios, and achieve refined management. Furthermore, the current permission range is determined by comprehensively considering the static risk of the device, the permission difference set, and the basic permission range, taking into account the safety risks of the device and enhancing the security of the system. The permission range is updated in real time according to the dynamic risk of the device and the user's dialogue request, so that permission management can adapt to complex and changing environments and improve the adaptability of the system. Responding to dialogue requests with the help of a large model combined with the latest permission range not only uses the large model to provide high-quality responses, but also ensures the security of information interaction and enhances the user interaction experience.

[0195] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the present invention and its equivalents, the present invention is intended to include these modifications and variations.

Claims

1. An intelligent rights management and dialogue system for multi-platform client-integrated large model services, characterized by: include: A basic authority determination module is used to determine the node to which the corresponding user identity information belongs in the organizational structure based on the account information of any platform received from any client, and to determine the basic authority scope of the corresponding user identity information based on the node; The platform and client differentiation module is used to retrieve the preset organization cross-platform client permission differentiation table based on the platform type and client type of the received account information, and determine the permission difference set of the corresponding user identity information under the corresponding platform type and the corresponding client type; The permission concretization module is used to determine the current permission scope of the corresponding user identity information based on the device static risk analysis results of the client that receives the account information, the permission difference set, and the basic permission scope; The dynamic permission update module is used to analyze the two-dimensional drift information based on the dynamic risk analysis results of the client device that receives the account information and all the dialogue requests entered by the user, and to update the current permission scope in real time based on the two-dimensional drift information, and to respond to the dialogue request based on the large model accessed by the platform and the latest permission scope.

2. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 1 is characterized in that: Basic permission determination module, including: The registration information retrieval submodule is used to retrieve the pre-registration information of all members under the organizational structure based on the account information of any platform received from any client, and obtain the corresponding user identity information; The structure database search submodule is used to search the organizational structure database based on the corresponding user identity information to determine the corresponding department; The architecture belonging determination submodule is used to determine the node to which the corresponding user identity information belongs in the organizational structure based on the corresponding department; The predefined permission association submodule is used to determine the predefined permission range of the node to which it belongs, which is used as the basic permission range corresponding to the user identity information.

3. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 1 is characterized in that: Platform and client differentiation modules, including: The type determination submodule is used to determine the platform type and client type of the received account information; The permission difference information retrieval submodule is used to retrieve the preset organization cross-platform client permission differentiation table based on platform type and client type to obtain all permission difference information; The permission difference information aggregation submodule is used to aggregate all permission difference information as a permission difference set of corresponding user identity information under the corresponding platform type and the corresponding client type.

4. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 1 is characterized in that: Permission specific module, including: The static risk assessment submodule is used to obtain the client's device static risk score and all device static risk items as the client's device static risk analysis results based on the client's system configuration, application, application application permissions, firewall configuration, IP address, and open ports of the client receiving the account information; The risk permission constraint submodule is used to determine the permission constraint factors of all device static risk items based on the client's device static risk score value. Based on the permission constraint factors of all device static risk items and all device static risk items in the device static risk analysis results, the risk item-permission range association table is retrieved and summarized to obtain the permission constraint set; The permission update submodule is used to update the basic permission range based on the permission constraint set and the permission difference set, and obtain the current permission range corresponding to the user identity information.

5. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 4 is characterized in that: Static risk assessment submodule, including: The system configuration risk assessment unit is used to compare the account policies, access control settings, and network service settings in the system configuration with the preset security configuration benchmark to obtain all risk items of the system configuration, and assign scores to the system configuration comparison results based on preset risk assessment rules to obtain the risk score value of the system configuration; An application risk assessment unit is used to assign a risk value to the source of each application installed on the client based on the application source risk assessment rules, and to obtain a risk score value and all risk items for each application by combining the validity of each application's digital signature and the degree of matching with malware characteristics; The application permission risk assessment unit is used to determine the rationality of the permissions applied for by the corresponding application based on the functional requirements of all applications installed on the client, and obtain the risk score value and all risk items of the application permissions; The device static risk aggregation unit is used to analyze the risk score value and all risk items of the client's firewall configuration, the risk score value and all risk items of the IP address and open port, and combine the risk score value and all risk items of the system configuration, the risk score value and all risk items of all applications, and the risk score value and all risk items of application permissions to obtain the device static risk score value and all device static risk items of the client that receives the account information.

6. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 1 is characterized in that: Permission dynamic update module, including: A first risk analysis submodule is configured to generate a first risk vector based on all security vulnerability items and a risk value of each security vulnerability item in the real-time security vulnerability screening result in the device dynamic risk analysis result of the client receiving the account information; a second risk analysis submodule, configured to determine all unupdated security patches based on the real-time security patch update status in the device dynamic risk analysis result of the client receiving the account information, and generate a second risk vector based on pre-assigned scores of all unupdated security patches; A third risk analysis submodule, configured to generate a third risk vector based on the matching degree between the sensitivity and encryption level of all group sensitive information transmitted in the latest period in the dynamic risk analysis result of the device of the client receiving the account information; A drift matrix generation submodule, configured to generate a first drift matrix based on the first risk vector, the second risk vector, and the third risk vector; A second drift analysis submodule, configured to analyze a second drift matrix based on all dialogue requests input by the user; A drift trend marking submodule, configured to update the current authority range in real time based on the first drift matrix and the second drift matrix; The large model response submodule is used to respond to dialogue requests based on the large model connected to the platform and the latest permission range; The two-dimensional drift information includes a first drift matrix and a second drift matrix.

7. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 6 is characterized in that: The second drift analysis submodule includes: A first permission line fitting unit is configured to analyze the target permission classes of all dialogue requests entered by the user and the request depth of each target permission, determine the ordinate value of each dialogue request in a preset two-dimensional coordinate system based on the request depth of the target permissions of all dialogue requests, determine the abscissa difference between each group of adjacent dialogue requests in the preset two-dimensional coordinate system based on the permission category span of the target permission classes of each group of adjacent dialogue requests, determine the corresponding coordinate point of each dialogue request in the preset two-dimensional coordinate system in combination with a preset starting abscissa value, and fit the user's total requested permission line based on the corresponding coordinate points of all dialogue requests in the preset two-dimensional coordinate system; an over-limit conversation request screening unit, configured to screen out, from all conversation requests input by the user, all conversation requests that do not meet the authority range of the corresponding user identity information at the corresponding moment, as all over-limit conversation requests; A second permission line fitting unit is configured to determine a vertical coordinate value of each over-limit dialogue request in a preset two-dimensional coordinate system based on the request depth of the target over-range permission of all over-limit dialogue requests, determine a horizontal coordinate difference between each group of adjacent over-limit dialogue requests in the preset two-dimensional coordinate system based on the permission category span of the target over-range permission class of each group of adjacent over-limit dialogue requests, determine a corresponding coordinate point of each over-limit dialogue request in the preset two-dimensional coordinate system in combination with a preset starting horizontal coordinate value, and fit the user's over-limit request permission line based on the corresponding coordinate points of all over-limit dialogue requests in the preset two-dimensional coordinate system; The second drift matrix analysis unit is configured to analyze a second drift matrix based on the user's total claim authority line and the excess claim authority line.

8. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 7 is characterized in that: The second drift matrix analysis unit includes: a first drift analysis subunit, configured to use a vector pointing from the coordinate value of each over-limit dialogue request in the total claim authority line to the coordinate value in the over-limit claim authority line as a first drift vector of each over-limit dialogue request; a self-focusing vector calibration subunit, configured to use a vector in which the coordinate value corresponding to the immediately preceding dialogue request of each over-limit dialogue request in the total claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the total claiming authority line as a first self-focusing vector, a vector in which the coordinate value corresponding to the immediately succeeding dialogue request of each over-limit dialogue request in the total claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the total claiming authority line as a second self-focusing vector, a vector in which the coordinate value corresponding to the immediately preceding over-limit dialogue request of each over-limit dialogue request in the over-limit claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the over-limit claiming authority line as a third self-focusing vector, and a vector in which the coordinate value corresponding to the immediately succeeding over-limit dialogue request of each over-limit dialogue request in the over-limit claiming authority line points to the coordinate value of the corresponding over-limit dialogue request in the over-limit claiming authority line as a fourth self-focusing vector; a second drift analysis subunit, configured to use the difference between the first self-aggregation vector and the third self-aggregation vector of each exceeding-limit dialogue request as the second drift vector of each exceeding-limit dialogue request; a third drift analysis subunit, configured to use the difference between the second self-aggregation vector and the fourth self-aggregation vector of each exceeding-limit dialogue request as a third drift vector of each exceeding-limit dialogue request; The drift matrix generating subunit is configured to generate a second drift matrix for all the exceeding-limit dialogue requests based on the first drift vector, the second drift vector, and the third drift vector of all the exceeding-limit dialogue requests.

9. The intelligent rights management and dialogue system for multi-platform client integrated large model services according to claim 6 is characterized in that: Drift trend marking submodule, including: a drift trend marking unit, configured to locally link the first drift matrix and the second drift matrix with the complete authority representation graph and mark the real-time drift trend in the complete authority representation graph to obtain a real-time drift trend marking graph; The authority range updating unit is used to update the current authority range in real time based on the real-time drift trend mark graph.

10. An intelligent rights management and dialogue method for multi-platform client integrated large model services, characterized in that: include: S1: Based on the account information of any platform received from any client, determine the node to which the corresponding user identity information belongs in the organizational structure, and determine the basic permission scope of the corresponding user identity information based on the node; S2: Based on the platform type and client type of the received account information, a preset organization cross-platform client permission differentiation table is retrieved to determine a permission difference set for the corresponding user identity information under the corresponding platform type and the corresponding client type; S3: Determine the current permission scope of the corresponding user identity information based on the static risk analysis results of the client device that received the account information, the permission difference set, and the basic permission scope; S4: Analyze the two-dimensional drift information based on the dynamic risk analysis results of the client device that receives the account information and all the dialogue requests entered by the user, and update the current permission range in real time based on the two-dimensional drift information, and respond to the dialogue request based on the large model accessed by the platform and the latest permission range.

Images