Authority management method, device and equipment

Abstract

The invention provides an authority management method, device and equipment, and relates to the technical field of information security, and the method comprises the steps: obtaining the main information of an access user, and urban data space trust model data; performing trust verification on the subject information to obtain a first trust degree; under the condition that the first trust degree is a first class value, determining a second trust degree according to the historical failure trust verification times and the historical success trust verification times; according to the successful trust verification duration, determining a third trust degree; and managing the authority of the access user according to the first trust degree, the second trust degree and the third trust degree. According to the embodiment of the invention, the method can guarantee the access safety of interoperation between urban information systems.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a permission management method, apparatus, and device. Background Art

[0002] The urban data space trust model is a technical framework or management mechanism used to ensure the security, reliability and credibility of data in the process of city-level data sharing, exchange and collaborative application.

[0003] In existing technologies, user permissions are typically managed through a city data space trust model. However, business systems related to the collection, processing, and analysis of urban data exhibit significant characteristics of clustering, high adaptability, and high elasticity. Existing city data spaces face circulation and utilization difficulties, such as insufficient dynamic data supply, low autonomy and trustworthiness, unstable security guarantees, and weak interoperability. As security entities constantly change with the development of data services and the passage of time, existing city data space trust models cannot guarantee access security for interoperability between urban information systems. Summary of the Invention

[0004] The technical problem to be solved by this application is to provide a permission management method, device and equipment to address the above-mentioned deficiencies in the existing technology, so as to solve the problem that the urban data space trust model in the existing technology cannot guarantee the access security of interoperability between urban information systems.

[0005] In a first aspect, the present application provides a rights management method, the method comprising:

[0006] Obtain the subject information of the accessing user, which includes the first user information. The first user information includes the number of historical failed trust verifications, the number of historical successful trust verifications, and the duration of successful trust verifications. The duration of successful trust verification is the number of natural days between the date of the accessing user's last successful trust verification and the date of the current trust verification plus one;

[0007] Conduct trust verification on the subject information and obtain the first degree of trust;

[0008] When the first trust level is a first-class value, determining a second trust level based on the number of historical failed trust verifications and the number of historical successful trust verifications;

[0009] Determine the third level of trust based on the duration of successful trust verification;

[0010] The authority of the access user is managed according to the first trust level, the second trust level and the third trust level.

[0011] In some implementations of the first aspect, the subject information includes first device information, first user information, and first operating environment information; and performing trust verification on the subject information to obtain a first trust level specifically includes:

[0012] Obtaining city data space trust model data, the city data space trust model data including preset device information, preset user information, and preset operating environment information;

[0013] Performing trust verification on the first device information using the preset device information to obtain a first sub-trust degree;

[0014] When the first sub-trustworthiness is the first value, the first user information is trusted using the preset user information to obtain a second sub-trustworthiness;

[0015] When the second sub-trust level is the first value, the first operating environment information is trusted and verified using the preset operating environment information to obtain a third sub-trust level;

[0016] The sum of the first sub-trust degree, the second sub-trust degree, and the third sub-trust degree is determined as the first trust degree.

[0017] In some implementations of the first aspect, after trust verification is performed on the first device information using preset device information to obtain the first sub-trust level, the method further includes:

[0018] When the first sub-trust degree is the second value, the first trust degree is determined to be the first sub-trust degree.

[0019] In some implementations of the first aspect, after trustworthiness verification is performed on the first user information using preset user information to obtain the second sub-trustworthiness, the method further includes:

[0020] When the second sub-trust degree is the second value, the sum of the first sub-trust degree and the second sub-trust degree is determined as the first trust degree.

[0021] In some implementations of the first aspect, the second trust level satisfies formula (1), which includes:

[0022] A2=sucs(s) / (sucs(s)+fais(s)) (1)

[0023] Among them, A2 represents the second trust level; sucs(s) represents the number of historical successful trust verifications; fais(s) represents the number of historical failed trust verifications.

[0024] In some implementations of the first aspect, the third trust level satisfies formula (2), which includes:

[0025] A3=1 / t (2)

[0026] Among them, A3 represents the third level of trust; t represents the duration of successful trust verification.

[0027] In some implementations of the first aspect, managing the access rights of the user based on the first trust level, the second trust level, and the third trust level specifically includes:

[0028] The sum of the first trust, the second trust, and the third trust is taken as the total trust value;

[0029] The access permissions of users are managed based on the total trust value.

[0030] In some implementations of the first aspect, managing the access rights of the user based on the total trust value specifically includes:

[0031] When the total trust value is greater than the first threshold and less than or equal to the second threshold, monitoring the behavior of the accessing user;

[0032] When the total trust value is greater than the third threshold and less than or equal to the first threshold, the accessing user is subjected to behavior monitoring and mandatory authentication;

[0033] When the total trust value is greater than or equal to the fourth threshold and less than or equal to the third threshold, the access user is denied authorization.

[0034] Based on the same inventive concept, in a second aspect, an embodiment of the present application provides a rights management device, the device comprising:

[0035] A first acquisition module is configured to acquire subject information of the accessing user, the subject information including first user information, the first user information including the number of historical failed trust verifications, the number of historical successful trust verifications, and the duration of successful trust verifications, where the duration of successful trust verifications is the number of natural days between the date of the accessing user's last successful trust verification and the date of the current trust verification plus one;

[0036] a trust verification module, connected to the first acquisition module, configured to perform trust verification on the subject information to obtain a first trust level;

[0037] a first determination module, connected to the trust verification module, configured to determine a second trust level based on a historical number of failed trust verifications and a historical number of successful trust verifications when the first trust level is a first type value;

[0038] a second determination module, connected to the first determination module, configured to determine a third degree of trust based on a successful trust verification duration;

[0039] The management module is connected to the trust verification module, the first determination module and the second determination module, and is used to manage the authority of the access user according to the first trust level, the second trust level and the third trust level.

[0040] Based on the same inventive concept, in a third aspect, an embodiment of the present application provides a rights management device, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to implement the rights management method of the first aspect mentioned above.

[0041] Based on the same inventive concept, in a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the permission management method of the first aspect mentioned above is implemented.

[0042] According to the permission management method, apparatus and equipment provided in the embodiments of the present application, the subject information of the accessing user is first obtained; then, the subject information is trust verified to obtain a first trust level; then, when the first trust level is a first-category value, the second trust level is determined based on the number of historical failed trust verifications and the number of historical successful trust verifications of the accessing user; then, the third trust level is determined based on the duration of the successful trust verification of the accessing user; then, the permissions of the accessing user are managed based on the first trust level, the second trust level and the third trust level. That is to say, in an embodiment of the present application, trust verification is performed on the accessing user by means of user subject information, the number of historical failed trust verifications and the number of historical successful trust verifications (i.e., business factors), and the duration of successful trust verification (i.e., time factors), to obtain a first trust level, a second trust level, and a third trust level, so as to ensure that the urban data space can adapt to the mutual trust relationship between security entities that changes with the development of data services and the passage of time, and then manage the permissions of the accessing users according to the first trust level, the second trust level, and the third trust level, and dynamically evaluate the user's trust level, and manage the user's permissions based on the trust level, thereby realizing dynamic access control of the access subject and thus ensuring the access security of interoperability between urban information systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A flowchart of a rights management method provided in an embodiment of the present application;

[0044] Figure 2 Another flowchart of the rights management method provided in the embodiment of the present application;

[0045] Figure 3 A schematic diagram of the structure of the rights management device provided in an embodiment of the present application;

[0046] Figure 4A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to enable those skilled in the art to better understand the technical solution of the present application, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0048] It should be understood that the specific embodiments and drawings described herein are only used to explain the present application, rather than to limit the present application.

[0049] It can be understood that, in the absence of conflict, the various embodiments and features in the embodiments of the present application can be combined with each other.

[0050] It will be understood that, for the sake of ease of description, the drawings of this application only show the parts related to this application, while the parts not related to this application are not shown in the drawings.

[0051] It can be understood that each unit and module involved in the embodiments of the present application may correspond to only one physical structure, or may be composed of multiple physical structures, or multiple units and modules may be integrated into one physical structure.

[0052] It can be understood that the terms "first", "second", etc. in the embodiments of the present application are used to distinguish different objects, or to distinguish different processing of the same object, rather than to describe a specific order of objects.

[0053] It is understandable that, in the absence of conflict, the functions and steps marked in the flowcharts and block diagrams of the present application may occur in an order different from that marked in the drawings.

[0054] It is understood that the flowcharts and block diagrams of the present application illustrate the possible architectures, functions, and operations of the systems, devices, equipment, and methods according to the various embodiments of the present application. Each box in the flowchart or block diagram may represent a unit, module, program segment, or code, which contains executable instructions for implementing the specified functions. Moreover, each box or combination of boxes in the block diagram and flowchart may be implemented by a hardware-based system that implements the specified functions, or by a combination of hardware and computer instructions.

[0055] It can be understood that the units and modules involved in the embodiments of the present application can be implemented by software or hardware, for example, the units and modules can be located in a processor.

[0056] Example 1

[0057] The rights management method provided in the embodiment of the present application is applicable to the application scenario of interoperability between urban information systems. The rights management method can be executed by a rights management device and an electronic device, etc. The following takes the rights management method executed by an electronic device as an example for description.

[0058] like Figure 1 As shown, the rights management method provided in the embodiment of the present application may include steps S110 to S150.

[0059] S110. Obtain the subject information of the accessing user, where the subject information includes first user information. The first user information includes the number of historical failed trust verifications, the number of historical successful trust verifications, and the duration of successful trust verifications. The duration of successful trust verification is the number of natural days between the date of the accessing user's last successful trust verification and the date of this trust verification plus one.

[0060] S120: Perform trust verification on the subject information to obtain a first trust level.

[0061] S130 : When the first trust level is a first-category value, determine a second trust level according to a historical number of failed trust verifications and a historical number of successful trust verifications of the accessing user.

[0062] S140: Determine a third trust level according to a successful trust verification duration of the accessing user.

[0063] S150: Manage the access rights of the user according to the first trust level, the second trust level, and the third trust level.

[0064] According to the permission management method provided in the embodiment of the present application, the subject information of the access user is first obtained; then, the subject information is trusted and verified to obtain a first trust degree; then, when the first trust degree is a first-class value, a second trust degree is determined based on the number of historical failed trust verifications and the number of historical successful trust verifications of the access user; then, a third trust degree is determined based on the duration of successful trust verification of the access user; then, the permission of the access user is managed based on the first trust degree, the second trust degree, and the third trust degree. That is, in the embodiment of the present application, the first trust degree, the second trust degree, and the third trust degree are obtained by trust verification of the access user based on the user subject information, the number of historical failed trust verifications and the number of historical successful trust verifications (i.e., the business factor), and the duration of successful trust verification (i.e., the time factor), so as to ensure that the city data space can adapt to the mutual trust relationship between security entities that changes continuously with the development of data business and the passage of time, and then manage the permission of the access user based on the first trust degree, the second trust degree, and the third trust degree, so as to dynamically evaluate the user's trust degree and manage the user's permission based on the trust degree, so as to realize dynamic access control of the access subject and thus ensure the access security of interoperability between city information systems.

[0065] The specific implementation methods of the above steps are introduced below.

[0066] In step S110 , illustratively, the subject information includes first user information, first device information, and first operating environment information.

[0067] For example, the first user information further includes a first universally unique identifier (UUID) of the accessing user, first authentication data, a first login time, and a first login frequency. The first authentication data may include a first user account and a first user password.

[0068] Exemplarily, the first device information includes first device hardware information, a first media access control address (MAC), a first trust state, a first device version number, and a first device software number.

[0069] Exemplarily, the first operating environment information includes a first application programming interface (Application Programming Interface, API).

[0070] For example, taking the last successful visit of the visiting user as the anchor point, if the user visits again on the same day, the successful trust verification time is 1; if the user visits on the second natural day (i.e., after 0:00), the successful trust verification time is 2.

[0071] For example, the first universal unique identification code and the first authentication data of the accessing user can be obtained by embedding the software development kit (SDK) into the web page / mobile application client (APP); the first login time and the first login frequency can be captured through the network splitter (NetFlow) or the extended Berkeley Packet Filter (eBPF).

[0072] For example, the UUID can be called through the system API. For example, the Android system obtains the first device hardware information, the first MAC, and the first trust status through the Build class; for another example, the Apple mobile operating system (iOS) system obtains the first device hardware information, the first MAC, and the first trust status through the User Interface Device (UIDevice) class that requires user authorization. The first device version number can be obtained through static analysis and dynamic monitoring. Among them, static analysis is to use the Android Package Decompiler Tool (Android Package Tool, APKtool) to decompile APL and verify the certificate chain (OpenSSL); dynamic monitoring is to use Frida to hook key APIs (such as network requests) and record sensitive operations.

[0073] In step S120, after obtaining the subject information of the accessing user and the city data space trust model data, the electronic device may also perform trust verification on the subject information to obtain a first trust level.

[0074] In some embodiments, the subject information further includes first device information, first user information, and first operating environment information;

[0075] Perform trust verification on the subject information to obtain the first level of trust, specifically including:

[0076] Obtaining city data space trust model data, where the city data space trust model data includes preset device information, preset user information, and preset operating environment information;

[0077] Performing trust verification on the first user information using the preset device information to obtain a first sub-trust degree;

[0078] When the first sub-trustworthiness is the first value, the first user information is trusted using the preset user information to obtain a second sub-trustworthiness;

[0079] When the second sub-trust level is the first value, the first operating environment information is trusted and verified using the preset operating environment information to obtain a third sub-trust level;

[0080] The sum of the first sub-trust degree, the second sub-trust degree, and the third sub-trust degree is determined as the first trust degree.

[0081] In this embodiment, by performing trust verification on the first device information, the first user information and the first operating environment information in sequence, the first sub-trust, the second sub-trust and the third sub-trust are obtained, and then the first sub-trust, the second sub-trust and the third sub-trust are determined as the first trust, which can improve the accuracy of the first trust determination and provide a basis for subsequent protection of interoperable access security between urban information systems.

[0082] Exemplarily, the preset device information includes preset device hardware information, preset MAC, preset trust status, preset device version number, and preset device software number.

[0083] For example, the preset user information includes a preset number of failed trust verifications in history, a preset number of successful trust verifications in history, a preset successful trust verification duration, a preset UUID, preset authentication data, a preset login time, and a preset login frequency. The preset authentication data may include a preset user account and a preset user password.

[0084] Exemplarily, the preset operating environment information includes a preset API.

[0085] Exemplarily, the electronic device pre-stores the city data space trust model data for subsequent direct call.

[0086] Exemplarily, trust verification is performed on the first user information using the preset user information to obtain a first sub-trust level, specifically including: determining the first sub-trust level to be a first value if the first user information is identical to the preset user information; and determining the first sub-trust level to be a second value if the first user information is different from the preset user information. The first user information being identical to the preset user information may mean that all information in the first user information is identical to the information corresponding to it in the preset user information; and the first user information being different from the preset user information may mean that at least one information in the first user information is different from the information corresponding to it in the preset user information.

[0087] That is to say, when the number of historical failed trust verifications is the same as the preset number of historical failed trust verifications, the number of historical successful trust verifications is the same as the preset number of historical successful trust verifications, the successful trust verification duration is the same as the preset successful trust verification duration, the first UUID is the same as the preset UUID, the first authentication data is the same as the preset authentication data, the first login time is the same as the preset login time, and the first login frequency is the same as the preset login frequency, the first user information is determined to be the same as the preset user information. When at least one of the number of historical failed trust verifications is the same as the preset number of historical failed trust verifications, the number of historical successful trust verifications is the same as the preset number of historical successful trust verifications, the successful trust verification duration is the same as the preset successful trust verification duration, the first UUID is the same as the preset UUID, the first authentication data is the same as the preset authentication data, the first login time is the same as the preset login time, and the first login frequency is the same as the preset login frequency, the first user information is determined to be different from the preset user information.

[0088] It should be noted that the first and second values can be set according to actual circumstances and are not limited here. For example, the first value is 1 and the second value is -1. When the sub-trust level is the first value, it indicates that the trust level verification has passed, and when the sub-trust level is the second value, it indicates that the trust level verification has failed.

[0089] Exemplarily, the preset device information is used to perform trust verification on the first device information to obtain a second sub-trust, specifically including: when the first device information is the same as the preset device information, determining the second sub-trust to be a first value; when the first device information is different from the preset device information, determining the second sub-trust to be a second value. More specifically, when the first device hardware information is the same as the preset device hardware information, the first MAC is the same as the preset MAC, the first trust status is the same as the preset trust status, the first device version number is the same as the preset device version number, and the first device software number is the same as the preset device software number, determining that the first device information is the same as the preset device information; when at least one of the first device hardware information is different from the preset device hardware information, the first MAC is the same as the preset MAC, the first trust status is the same as the preset trust status, the first device version number is the same as the preset device version number, and the first device software number is the same as the preset device software number, determining that the first device information is different from the preset device information.

[0090] Exemplarily, the preset operating environment information is used to perform trust verification on the first operating environment information to obtain a third sub-trust level, specifically including: when the first API is the same as the preset API, determining the third sub-trust level to be the first value; when the first API is different from the preset API, determining the third sub-trust level to be the second value.

[0091] Exemplarily, when the third sub-trust level is a first value, the first trust level is three times the first value. For example, if the first value is 1, the first trust level is 3. When the third sub-trust level is a second value, the first trust level is twice the sum of the first value and the second value. For example, if the first value is 1 and the second value is -1, the first trust level is 1.

[0092] In other embodiments, after trust verification is performed on the first device information using the preset device information to obtain the first sub-trust level, the method further includes:

[0093] When the first sub-trust degree is the second value, the first trust degree is determined to be the first sub-trust degree.

[0094] In this embodiment, when the first sub-trust level is the second value, that is, the trust verification of the first device information fails, trust verification of the first user information and the first operating environment information is not performed at this time, and the first trust level is directly derived as the first sub-trust level, that is, the first trust level is the second value, which provides a basis for subsequent permission management of access users.

[0095] Exemplarily, if the second value is -1, then the first trust level is -1.

[0096] In some further embodiments, after verifying the trustworthiness of the first user information using the preset user information to obtain the second sub-trustworthiness, the method further includes:

[0097] When the second sub-trust degree is the second value, the sum of the first sub-trust degree and the second sub-trust degree is determined as the first trust degree.

[0098] In this embodiment, the second sub-trust is the second value, the first device information verification passes, but the first user information trust verification fails. At this time, the trust verification of the first operating environment information is not performed, and the first trust is directly obtained as the sum of the first sub-trust and the second sub-trust, that is, the first trust is the sum of the first value and the second value, which provides a basis for subsequent permission management of access users.

[0099] Exemplarily, if the first value is 1 and the second value is -1, then the first trust level is 0.

[0100] Exemplarily, before performing trust verification on the subject information to obtain the first trust level, the method may include: extracting, classifying, storing, and managing the subject information.

[0101] For example, the classification storage method is:

[0102] (1) Data lake design: raw data (Amazon Web Services Simple Storage Service (AWS S3), partitioned by data type), metadata (Apache Atlas tags data with sensitivity levels of personally identifiable information (PII) / non-PII);

[0103] (2) Format standardization: user data (Parquet format, partitioned by user ID), traffic data (JSON Lines format, sharded by time window)

[0104] (3) Database selection: user information (relational database management system MYSQL), traffic logs (time series database InfluxDB or Prometheus monitoring system Prometheus), user device association information (Neo4j);

[0105] Exemplarily, the management method:

[0106] (1) Data cleaning: Use Spark Structured Query Language (Spark SQL) to remove duplicate records, use the rule engine to supplement missing fields, and unify the timestamp format (ISO8601) and character encoding (UTF-8);

[0107] (2) Data security: static encryption (AWS S3 Server-Side Encryption with Key Management Service (SSE-KMS) encryption), access control RBAC (role-based permissions) + ABAC (attribute-based IP range), privacy enhancement (adding noise to aggregated data);

[0108] (3) Data analysis: Blockchain evidence storage (Hyperledger Fabric, a blockchain framework, records key event hashes).

[0109] Exemplarily, before performing trust verification on the subject information and obtaining a first degree of trust, the method may include: verifying the integrity of the subject information; if the verification passes, performing trust verification on the subject information and obtaining a first degree of trust; if the verification fails, outputting an error prompt message, the error prompt message being used to indicate that the data of the subject information is incomplete and / or the format is incorrect, so as to remind the accessing user to make corrections or re-enter the data through the error prompt message.

[0110] Exemplarily, the conditions for determining the completeness of the subject information are: hash verification consistency (using a hash algorithm (such as SHA-256) to generate the hash value of the data, the receiver recalculates the hash value and compares it with the hash value provided by the sender, if they are the same, it is complete), digital signature verification is passed (the sender signs the hash value of the data with a private key, and the receiver uses the public key to verify the validity of the signature), and the checksum matches (the cyclic redundancy check (CRC) value is the same as the original data); conditions for the correct format of the subject information: pattern verification is passed, field type matches, fields are complete (required fields exist and are not empty), and the encoding specifications comply with the standards.

[0111] In step S130, after the electronic device performs trust verification on the subject information and obtains the first trust level, it can also determine the second trust level based on the historical number of failed trust verifications and the historical number of successful trust verifications of the accessing user when the first trust level is a first type value.

[0112] Exemplarily, the first category value is three times the first value. For example, if the first value is 1, then the first category value is 3.

[0113] Exemplarily, the first trust level is a first-category value, that is, the first sub-trust level, the second sub-trust level, and the third sub-trust level are all first values, that is, the first device information, the first user information, and the first operating environment information are all trusted and verified.

[0114] It is understandable that, when the first trust degree is not a first-category value and it is determined that the accessing user has failed the trust verification, the first trust degree is determined as the total trust degree value.

[0115] Exemplarily, when the first trust level is a first-category value, the method further includes: aggregating the first device information into a verification center according to a preset format rule.

[0116] Exemplarily, the preset format rules include:

[0117] (1) Equipment basic information format rules (required)

[0118] Device identifier (UUID (RFC4122)), operating system attributes (structured objects: -os_name (enumeration value: Android / iOS / Windows / Linux), -os_version (semantic version, such as 12.0.1)), hardware model (string (brand + model), special characters prohibited), timestamp (ISO8601 format (Coordinated Universal Time (UTC) time zone, accurate to milliseconds).

[0119] (2) Structured data format rules

[0120] Use JSON, with the root object containing all fields. Nested arrays and undefined fields are prohibited. Field constraints include required fields (device_id, os, hardware, timestamp), optional fields, and enumeration values (os.name and network_type must strictly match predefined values and are case-sensitive).

[0121] (3) Encoding and character set rules

[0122] JavaScript Object Notation (JSON) files must use Unicode Transformation Format–8-bit (UTF-8) encoding, and the Byte Order Mark (BOM) header is prohibited. Non-American Standard Code for Information Interchange (ASCII) characters (such as Chinese manufacturer names) must be explicitly escaped (e.g., \u534e\u4e3a) or included directly. Use JSON Schema to verify structural validity.

[0123] (4) Security and integrity rules

[0124] Calculate the SHA-256 hash of the complete JSON data (including all fields) and store it in a separate field called data_hash. Use the private key to sign data_hash, and store the signature value in the signature field.

[0125] Signature verification process: The recipient recalculates the hash → uses the public key to verify the validity of the signature.

[0126] In some implementations, the second trust level satisfies formula (1), which includes:

[0127] A2=sucs(s) / (sucs(s)+fais(s)) (1)

[0128] Among them, A2 represents the second trust level; sucs(s) represents the number of historical successful trust verifications; fais(s) represents the number of historical failed trust verifications.

[0129] In this embodiment, the second degree of trust can be determined quickly and accurately using the above formula (1).

[0130] For example, if the number of historical successful trust verifications is 3 and the number of historical failed trust verifications is 1, the second trust level is 0.75.

[0131] It is understandable that the value range of the second trust level is [0, 1].

[0132] Exemplarily, when the second trust level is the first value, the method further includes: collecting the first user information into the verification center according to a preset format rule.

[0133] In step S140 , after determining the second trust level based on the historical number of failed trust verifications and the historical number of successful trust verifications of the accessing user, the electronic device may further determine the third trust level based on the duration of successful trust verifications of the accessing user.

[0134] In some implementations, the third trust level satisfies formula (2), which includes:

[0135] A3=1 / t (2)

[0136] Among them, A3 represents the third level of trust; t represents the duration of successful trust verification.

[0137] In this embodiment, the third degree of trust can be determined quickly and accurately using the above formula (2).

[0138] Exemplarily, if the successful trust verification duration is 2, the third trust degree is 0.5.

[0139] It is understandable that the value range of the third trust level is [0, 1].

[0140] Exemplarily, when the third trust level is the first value, the method further includes: collecting the first operating environment information into the verification center according to a preset format rule.

[0141] In step S150, after determining the third trust level according to the duration of successful trust verification of the accessing user, the electronic device may further manage the authority of the accessing user according to the first trust level, the second trust level and the third trust level.

[0142] In some embodiments, a first weight value, a second weight value, and a third weight value may be obtained first, where the first weight value is the weight value of the first trust, the second weight value is the weight value of the second trust, and the third weight value is the weight value of the third trust; based on the first trust, the second trust, the third trust, the first weight value, the second weight value, and the third weight value, a weighted sum is performed to obtain a total trust value; and based on the total trust value, the permissions of the access user are managed.

[0143] In other implementations, the permissions of the accessing user are managed based on the first trust level, the second trust level, and the third trust level, specifically including:

[0144] The sum of the first trust, the second trust, and the third trust is taken as the total trust value;

[0145] The access permissions of users are managed based on the total trust value.

[0146] In this embodiment, by taking the sum of the first trust, the second trust and the third trust as the total trust value and managing the access user's authority based on the total trust value, the user's trust can be dynamically evaluated, and the user's authority can be managed based on the trust, which can realize dynamic access control of the access subject and thus ensure the access security of interoperability between urban information systems.

[0147] In some examples, the permissions of access users are managed based on the total trust value, specifically including:

[0148] When the total trust value is greater than the first threshold and less than or equal to the second threshold, monitoring the behavior of the accessing user;

[0149] When the total trust value is greater than the third threshold and less than or equal to the first threshold, the accessing user is subjected to behavior monitoring and mandatory authentication;

[0150] When the total trust value is greater than or equal to the fourth threshold and less than or equal to the third threshold, the access user is denied authorization.

[0151] In this example, by adopting multiple thresholds and total trust values to perform hierarchical processing on access users, the management efficiency of access users can be improved, the risk of authority abuse can be reduced, and the access security of interoperability between urban information systems can be further guaranteed.

[0152] It is understood that the second threshold is greater than the first threshold, the first threshold is greater than the third threshold, and the third threshold is greater than the fourth threshold. The specific values of the first to fourth thresholds can be set according to actual conditions and are not limited here. For example, the first threshold is 4, the second threshold is 4.5, the third threshold is 3, and the fourth threshold is -1.

[0153] For example, when the total trust value is greater than the second threshold, the accessing user may be considered as a high-trust user, and a loose policy may be adopted to minimize restrictions on the accessing user's permissions.

[0154] For example, if the total trust value is greater than a first threshold and less than or equal to a second threshold, the user can be considered a medium-trust user, and enhanced monitoring and partial restrictions can be implemented. For example, the user's behavior can be tracked in real time to identify abnormal patterns, perform log analysis (recording user operation paths and API call frequency), and use existing machine learning models to detect whether the user deviates from normal behavior patterns (such as suddenly exporting large amounts of data).

[0155] For example, when the total trust value is greater than the third threshold and less than or equal to the first threshold, the accessing user can be considered a low-trust user and needs to be strictly controlled and restricted in key operations. For example, the behavior of the accessing user can be tracked in real time, abnormal patterns can be identified, log analysis can be performed (recording user operation paths and API call frequencies), and existing machine learning models can be used to detect whether the accessing user deviates from normal behavior patterns (such as sudden large-scale data exports, etc.), requiring additional authentication, trust renewal, and periodic re-authentication. Among them, trust renewal can be the trust value decaying over time, and regular active verification is required to maintain authority; periodic re-authentication can be re-login or verification of the device at preset time intervals, and the preset time can be set according to actual conditions, such as one week, one month, etc.

[0156] For example, when the total trust value is greater than or equal to the fourth threshold and less than or equal to the fourth threshold, the accessing user may be considered as an extremely low-trust user, and authorization is denied to the accessing user to completely block high-risk operations.

[0157] For example, the server's load status is determined, and real-time monitoring and feedback are used for system resource indicators (CPU usage, memory usage, disk I / O, network bandwidth) and application layer indicators (request response time, number of concurrent connections, queue length) to determine load and dynamically adjust the strategy. Load states are divided into three categories: low load (CPU <50%, memory <60%, response time <100ms), normal load (CPU 50%-80%, memory 60%-80%, response time 100-500ms), and high load (CPU >80%, memory >80%, response time >500ms or increased error rate). The dynamic response strategy is implemented through traffic scheduling, automatic scaling, downgrade, and current limiting. Access to trusted users is controlled to ensure that high-priority users with high trust values access the server first.

[0158] Exemplarily, the method also includes: in the case where the access of the visiting user is successful, the preset number of historical successful trust verifications is updated to the number of historical successful trust verifications plus one, and the updated preset number of historical successful trust verifications is stored in the city data space trust model data as a source of dynamic trust data to ensure that subsequent trust decisions have real-time dynamic characteristics; in the case where the access of the visiting user fails, the preset number of historical failed trust verifications is updated to the number of historical failed trust verifications plus one, and the updated preset number of historical failed trust verifications is stored in the city data space trust model data as a source of dynamic trust data to ensure that subsequent trust decisions have real-time dynamic characteristics.

[0159] In order to better understand the rights management method provided in the embodiment of the present application, a specific implementation method is described below.

[0160] Early trust management models were entirely based on trust credentials, generally issued by third-party trust institutions such as CAs. They could accurately describe the initial state of the system's trust system. However, with the emergence of complex distributed systems, this type of static trust management model is no longer able to adapt to the needs of system permission management, which has high requirements for elasticity and adaptability. Trust model verification technology cannot meet the requirements of real-time dynamic changes.

[0161] In addition, the business systems related to the collection, processing and analysis of urban data have the significant characteristics of clustering, high adaptability and high elasticity. The existing urban data space has circulation and utilization difficulties such as insufficient dynamic data supply, low autonomy and credibility, unstable security, and weak interoperability. Security entities are constantly changing with data business, and the existing data space trust model cannot guarantee access security.

[0162] like Figure 2 As shown, the rights management method provided in the embodiment of the present application includes steps S1 to S10.

[0163] S1. Extract, classify, store and manage user data (i.e., first user information), device data (i.e., first device information), application data, authentication data (i.e., first authentication data) and traffic list (i.e., first login time and first login frequency).

[0164] S2. Verify whether the data (i.e., subject information) is complete and the format is correct; if incomplete or incorrect, return to make corrections and re-enter; if complete and correct, proceed to step S3.

[0165] S3. Verify the device software number (i.e., the first device software number) and version number (i.e., the first device version number); if the verification passes, the trust level (i.e., the first sub-trust level) is recorded as 1, entered into the verification center, and step S4 is executed; if inconsistent, the trust level is -1 and the verification fails.

[0166] S4. Verify the user identity information (i.e., the first user information); if the verification is successful, the trust level (i.e., the second sub-trust level) is recorded as 1, entered into the verification center, and step S5 is executed; if it is inconsistent, the trust level is -1, and the verification fails;

[0167] S5. Verify the operating environment (i.e., the first operating environment information); if the verification passes, the trust level (i.e., the third sub-trust level) is recorded as 1, entered into the verification center, and step S6 is executed; if it is inconsistent, the trust level is -1, and the verification fails;

[0168] S6. Determine historical trust verification data, with a trust degree interval of [0, 1].

[0169] S7. Confirm the historical access validity, and the trust level range is [0, 1].

[0170] S8. Confirm the user's trust value (i.e., total trust value).

[0171] S9. Adjust user trust permissions.

[0172] S10. The access verification result is processed by the trust data management module and then stored in the city data space trust model.

[0173] Match the access user subject information (including user data, device data, application data, authentication data and traffic list) with the data information in the urban data space trust model, and assign trust value based on the matching results. The specific assignment results are shown below, and user permissions are adjusted accordingly based on the trust value.

[0174] User data (user UUID universal unique identifier, behavioral data), device data (hardware information, MAC address, trust status), application data (version number), authentication data (password), and traffic list (time and frequency, API interface name) are extracted, classified, stored, and managed.

[0175] Data acquisition method:

[0176] (1) User data: embedded in the Web / App through the front-end SDK to record user behavior, including proactive provision (users fill in identity information and third-party authentication information when registering) and behavior logs (the system records user operations (login, click, access request));

[0177] (2) Device data: System API calls UUID: Android obtains device information through the Build class, and iOS obtains device information through UIDevice (user authorization required). Read the operating system version (uname-a) and hardware model (device tree information) based on device properties;

[0178] (3) Application data: static analysis (using Apktool to decompile APK and verify the certificate chain (OpenSSL)), dynamic monitoring (Frida hooks key APIs (such as network requests) and records sensitive operations);

[0179] (4) Authentication data: The client generates a public-private key pair and registers the public key with the server. The private key is used to sign the challenge during login, and the server verifies the signature.

[0180] (5) Traffic list: Network splitter (NetFlow) or eBPF captures raw traffic.

[0181] Data classification storage method:

[0182] (1) Data lake design: raw data (AWS S3, partitioned by data type), metadata (Apache Atlas tags data sensitivity level PII / non-PII);

[0183] (2) Format standardization: user data (Parquet format, partitioned by user ID), traffic data (JSON Lines format, sharded by time window);

[0184] (3) Database selection: user information (MYSQL), traffic logs (InfluxDB or Prometheus), user device association information (Neo4j).

[0185] Management methods:

[0186] (1) Data cleaning: Use Spark SQL to remove duplicate records, use the rule engine to supplement missing fields, and unify the timestamp format (ISO8601) and character encoding (UTF-8);

[0187] (2) Data security: encryption at rest (AWS S3 SSE-KMS encryption), access control RBAC (role-based permissions) + ABAC (attribute-based IP range), privacy enhancement (adding noise to aggregated data);

[0188] (3) Data analysis: Blockchain evidence storage (Hyperledger Fabric records key event hashes).

[0189] Verify that the data is complete and formatted correctly. Conditions for determining data integrity include: hash verification consistency (using a hash algorithm (such as SHA-256) to generate the data's hash value, the receiver recalculates the hash value and compares it with the hash value provided by the sender; if they match, the data is complete), digital signature verification (the sender signs the data's hash value with their private key, and the receiver uses their public key to verify the validity of the signature), and checksum matching (the cyclic redundancy check (CRC) value is consistent with the original data). Conditions for determining data format correctness include: schema verification, field type matching, field integrity (required fields exist and are not empty), and coding standards that meet standards.

[0190] If the data is incomplete or incorrectly formatted, return to correct it and re-enter it;

[0191] If the data is complete and in the correct format, all verified data will enter the downstream circulation through the connector.

[0192] Evaluate the trustworthiness of device information data in the urban data space trust model, including:

[0193] Through the standard communication interface, the device data is tested for trust with the city data space trust model data, and the device software number and version number are verified. If the device software number and version number are inconsistent, the judgment is stopped, the trust level is recorded as -1, and the verification fails.

[0194] If the device information verification passes, the trust level is recorded as 1. After the device data information is determined, the device data information is collected and connected to the verification center according to the format rules.

[0195] Equipment data information and format rules:

[0196] (1) Equipment basic information format rules (required)

[0197] Device identifier (UUID (RFC4122)), operating system attributes (structured objects: -os_name (enumeration value: Android / iOS / Windows / Linux), -os_version (semantic version, such as 12.0.1)), hardware model (string (brand + model), special characters prohibited), timestamp (ISO8601 format (UTC time zone), accurate to milliseconds).

[0198] (2) Structured data format rules

[0199] Use JSON, with the root object containing all fields. Nested arrays and undefined fields are prohibited. Field constraints include required fields (device_id, os, hardware, timestamp), optional fields, and enumeration values (os.name and network_type must strictly match predefined values and are case-sensitive).

[0200] (3) Encoding and character set rules

[0201] JSON files must use UTF-8 encoding, and the BOM header is prohibited. Non-ASCII characters (such as Chinese manufacturer names) must be explicitly escaped (e.g., \u534e\u4e3a) or included directly. Use JSONSchema to verify the structure.

[0202] (4) Security and integrity rules

[0203] Calculate the SHA-256 hash of the complete JSON data (including all fields) and store it in a separate field called data_hash. Use the private key to sign data_hash, and store the signature value in the signature field.

[0204] Signature verification process: The recipient recalculates the hash → uses the public key to verify the validity of the signature.

[0205] Evaluate the trustworthiness of user identity data in the urban data space trust model, including:

[0206] User identity verification is completed through distributed identifiers, identity authentication technology, and digital signature technology. The user identity data is tested for trustworthiness with the city data space trust model data. If there is any inconsistency in the user identity information, the judgment is stopped, the trustworthiness is recorded as -1, and the verification fails.

[0207] If the user identity information is legal, the trust level is recorded as 1. After confirming that the user identity is legal, the legalized user identity information is collected and connected to the verification center according to the format rules.

[0208] Evaluate the trustworthiness of user identity data in the urban data space trust model, including:

[0209] User identity verification is completed through distributed identifiers, identity authentication technology, and digital signature technology. The user identity data is tested for trustworthiness with the city data space trust model data. If there is any inconsistency in the user identity information, the judgment is stopped, the trustworthiness is recorded as -1, and the verification fails.

[0210] If the user identity information is legal, the trust level is recorded as 1. After confirming that the user identity is legal, the legalized user identity information is collected and connected to the verification center according to the format rules.

[0211] Evaluate the trustworthiness of user identity data in the urban data space trust model, including:

[0212] User identity verification is completed through distributed identifiers, identity authentication technology, and digital signature technology. The user identity data is tested for trustworthiness with the city data space trust model data. If there is any inconsistency in the user identity information, the judgment is stopped, the trustworthiness is recorded as -1, and the verification fails.

[0213] If the user identity information is legal, the trust level is recorded as 1. After confirming that the user identity is legal, the legalized user identity information is collected and connected to the verification center according to the format rules.

[0214] Confirm the trustworthiness of historical access time in the urban data space trust model, including:

[0215] The number of days between the last successful trust verification and this interoperation is t. The last successful access date is used as the anchor point. If the access is made on the same day, t = 1. If the access is made on the second natural day (i.e., after midnight), t = 2. The trust level is recorded as 1 / t. If there is no historical access event, the trust level is recorded as 0. The trust level interval is [0, 1].

[0216] After all verification links are passed (i.e., device information, user data information, and operating environment information are all in compliance), all trust values are added together, and the trust level interval is [3-5] to determine the user trust value. The data resources of the relevant subjects enter the downstream circulation through the connector.

[0217] Carry out hierarchical management and control based on user trust value, implement behavior monitoring, mandatory authentication, trust renewal, authorization rejection and other operations.

[0218] Hierarchical control: High trust (trust level (4.5, 5]): loose policy, minimize restrictions. Medium trust (trust level (4, 4.5]): enhanced monitoring and partial restrictions. Low trust (trust level [3, 4]): strict control, restricting key operations;

[0219] Behavior monitoring: Track the behavior of low- and medium-trust users in real time, identify abnormal patterns, and conduct log analysis (recording user operation paths and API call frequency) and machine learning models (detecting deviations from normal behavior patterns, such as sudden large-scale data exports);

[0220] Mandatory authentication: When the trust level is low, additional authentication is required; Trust renewal: The trust value decays over time, and regular active verification is required to maintain permissions, and regular re-authentication is required (re-login or device verification is required every 30 days);

[0221] Deny authorization: When the trust level is extremely low (trust level [-1, 3]), high-risk operations are completely blocked.

[0222] Determine the server's load status, using real-time monitoring and feedback of system resource indicators (CPU usage, memory usage, disk I / O, network bandwidth) and application-layer indicators (request response time, number of concurrent connections, queue length) to determine load and dynamically adjust strategies. Load states are categorized into three types: low load (CPU <50%, memory <60%, response time <100ms), normal load (CPU 50%-80%, memory 60%-80%, response time 100-500ms), and high load (CPU >80%, memory >80%, response time >500ms or increased error rate). Dynamic response strategies are implemented through traffic scheduling, automatic scaling, downgrades, and rate limiting. Access to trusted users is controlled to ensure that high-priority users with high trust scores access the server first.

[0223] The visit verification results are processed by the trust data management module and stored in the urban data space trust model. This serves as the source of dynamic trust data to ensure that subsequent trust decisions have real-time dynamic characteristics.

[0224] In this embodiment, a dynamic trust management trust tag based on time and business factors is provided to ensure that the data space can adapt to the evolving trust relationships between entities as business evolves and time passes. This model is flexible, autonomous, and scalable. By forming and changing cooperative relationships between data entities through trust, it achieves logical reconstruction of the data space, providing security guarantees for the effective collaboration of data information to achieve common goals.

[0225] In an embodiment of the present application, dynamic trust management can be used to ensure the secure connection of devices. When the software version, user information, etc. of the device changes, the dynamic trust management system can automatically detect and decide whether to allow the device to continue to connect or retrieve data based on preset rules. It is implemented by relying on the participant information service and the DA dynamic attribute service (DynamicAttribute Provisioning Service) to ensure that data is used when conditions are met. The data usage policy stipulates that only software with authorized version numbers and trusted entities can process data. If the software version or entity information changes, the data provider can automatically suspend the supply.

[0226] In this embodiment, user behavior is tracked in real time during user interactions, and feedback is provided to promptly stop unsafe behaviors and reduce trust values. Trust is assessed and updated in real time, allowing for dynamic adjustments to user permissions. Dynamic trust management reflects the dynamic nature of trust as the environment changes, emphasizing the dynamic process from trust assessment to trusted decision-making.

[0227] In this embodiment, a comprehensive assessment of the trust value of entities is conducted based on the city data space. City data is then evaluated and judged, incorporated into the unified management of the city data space, and trust decisions are made based on the assessment results. The trust decision results influence the authorization results for the entity. The trust data generated during data operation is fed back into the trust model, which has a self-growing nature and forms a closed trust management loop.

[0228] In an embodiment of the present application, a city data space trust model based on dynamic trust management is proposed, which provides a trusted data management method to solve the data evaluation and management problems of urban data information with large data volume, wide data types, and frequent data updates and changes, realizes dynamic access control between different trust subjects, and provides security guarantees for the interoperability between urban information systems.

[0229] In an embodiment of the present application, a dynamic trust management method based on time factors and business factors is provided to create trust labels to verify the integrity, consistency, accuracy, etc. of data resources, to verify the identity of the subjects participating in data exchange, the proof of participation in the data space, and the governance compliance, and to incorporate urban data into the unified management of the urban data space, so as to facilitate the evaluation, access, retrieval and application of trusted data in the data space.

[0230] It should be noted that the embodiments of the present application have at least the following beneficial effects:

[0231] 1. Through the verification center component, the identity of the subject participating in the data exchange, the proof of participation in the data space, and the governance compliance are verified, including device trust, user trust, operating environment trust, and historical verification trust. Not only will access to user information affect the access verification results, but historical verification information will also have an impact on this verification.

[0232] 2. A dynamic trust management verification method for the urban data space trust model represents the matching result between the access subject and the urban data space trust model data as a trust level. A series of verification methods are used to determine the user's trust value. Based on the trust value, permissions are assigned to the user to provide decision support for access control.

[0233] Example 2

[0234] The embodiment of the present application also provides a rights management device. Figure 3 As shown, the rights management device provided in the embodiment of the present application includes a first acquisition module 310 , a trust verification module 320 , a first determination module 330 , a second determination module 340 and a management module 350 .

[0235] The first acquisition module 310 is configured to acquire the subject information of the accessing user, the subject information including the first user information, the first user information including the number of historical failed trust verifications, the number of historical successful trust verifications, and the duration of successful trust verifications, where the duration of successful trust verifications is the number of natural days between the date of the accessing user's last successful trust verification and the date of the current trust verification plus one;

[0236] The trust verification module 320 is connected to the first acquisition module 310 and is used to perform trust verification on the subject information to obtain a first trust level;

[0237] A first determination module 330, connected to the trust verification module 320, is configured to determine a second trust level based on a historical number of failed trust verifications and a historical number of successful trust verifications of the accessing user when the first trust level is a first type value;

[0238] The second determination module 340 is connected to the first determination module 330 and is used to determine a third trust level according to a successful trust verification duration of the accessing user;

[0239] The management module 350 is connected to the trust verification module 320 , the first determination module 330 and the second determination module 340 , and is used to manage the access rights of the user according to the first trust level, the second trust level and the third trust level.

[0240] According to the rights management device provided by the embodiment of the present application, the subject information of the access user is first obtained; then, the subject information is trusted and verified to obtain a first trust degree; then, when the first trust degree is a first-class value, a second trust degree is determined based on the number of historical failed trust verifications and the number of historical successful trust verifications of the access user; then, a third trust degree is determined based on the duration of successful trust verification of the access user; then, the rights of the access user are managed based on the first trust degree, the second trust degree, and the third trust degree. That is, in the embodiment of the present application, the first trust degree, the second trust degree, and the third trust degree are obtained by trust verification of the access user based on the user subject information, the number of historical failed trust verifications and the number of historical successful trust verifications (i.e., the business factor), and the duration of successful trust verification (i.e., the time factor), so as to ensure that the city data space can adapt to the mutual trust relationship between security entities that changes with the development of data business and the passage of time, and then manage the rights of the access user based on the first trust degree, the second trust degree, and the third trust degree, so as to dynamically evaluate the user's trust degree and manage the user's rights based on the trust degree, so as to realize dynamic access control of the access subject and thus ensure the access security of interoperability between city information systems.

[0241] In some embodiments, the subject information includes first user information, first device information, and first operating environment information;

[0242] The trust verification module 320 is specifically configured to:

[0243] Obtaining city data space trust model data, the city data space trust model data including preset device information, preset user information, and preset operating environment information;

[0244] Performing trust verification on the first device information using the preset device information to obtain a first sub-trust degree;

[0245] When the first sub-trustworthiness is the first value, the first user information is trusted using the preset user information to obtain a second sub-trustworthiness;

[0246] When the second sub-trust level is the first value, the first operating environment information is trusted and verified using the preset operating environment information to obtain a third sub-trust level;

[0247] The sum of the first sub-trust degree, the second sub-trust degree, and the third sub-trust degree is determined as the first trust degree.

[0248] In some implementations, the trust verification module 320 is specifically configured to:

[0249] When the first sub-trust degree is the second value, the first trust degree is determined to be the first sub-trust degree.

[0250] In some implementations, the trust verification module 320 is specifically configured to:

[0251] When the second sub-trust degree is the second value, the sum of the first sub-trust degree and the second sub-trust degree is determined as the first trust degree.

[0252] In some implementations, the second trust level satisfies formula (1), which includes:

[0253] A2=sucs(s) / (sucs(s)+fais(s)) (1)

[0254] Among them, A2 represents the second trust level; sucs(s) represents the number of historical successful trust verifications; fais(s) represents the number of historical failed trust verifications.

[0255] In some implementations, the third trust level satisfies formula (2), which includes:

[0256] A3=1 / t (2)

[0257] Among them, A3 represents the third level of trust; t represents the duration of successful trust verification.

[0258] In some implementations, the management module 350 is specifically configured to:

[0259] The sum of the first trust, the second trust, and the third trust is taken as the total trust value;

[0260] The access permissions of users are managed based on the total trust value.

[0261] In some implementations, the management module 350 is specifically configured to:

[0262] When the total trust value is greater than the first threshold and less than or equal to the second threshold, monitoring the behavior of the accessing user;

[0263] When the total trust value is greater than the third threshold and less than or equal to the first threshold, the accessing user is subjected to behavior monitoring and mandatory authentication;

[0264] When the total trust value is greater than or equal to the fourth threshold and less than or equal to the third threshold, the access user is denied authorization.

[0265] The permission management device provided in the embodiment of the present application can execute the permission management method in Example 1, that is, it has the beneficial effects and implementation methods in Example 1 of the present application. For details, please refer to the specific description of the permission management method in the above Example 1, and this embodiment will not be repeated here.

[0266] Example 3

[0267] refer to Figure 4 This embodiment provides an electronic device, including a memory 21 and a processor 22. The memory 21 stores a computer program, and the processor 22 is configured to run the computer program to execute the permission management method in Example 1.

[0268] The memory 21 is connected to the processor 22 . The memory 21 may be a flash memory, a read-only memory, or other memory. The processor 22 may be a central processing unit or a single-chip microcomputer.

[0269] Example 4

[0270] This embodiment provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the rights management method in the above-mentioned embodiment 1 is implemented.

[0271] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable read only memory), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0272] It is understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present application, and the present application is not limited thereto. Those skilled in the art may make various modifications and improvements without departing from the spirit and substance of the present application, and such modifications and improvements are also considered to be within the scope of protection of the present application.

Claims

1. A rights management method, characterized in that: include: Obtaining subject information of the accessing user, the subject information including first user information, the first user information including the number of historical failed trust verifications, the number of historical successful trust verifications, and the duration of successful trust verifications, where the duration of successful trust verifications is the number of natural days between the date of the accessing user's last successful trust verification and the date of the current trust verification plus one; Performing trust verification on the subject information to obtain a first trust level; When the first trust level is a first type value, determining a second trust level according to the number of historical failed trust verifications and the number of historical successful trust verifications; Determining a third trust level based on the successful trust verification duration; The authority of the access user is managed according to the first trust level, the second trust level, and the third trust level.

2. The method according to claim 1, characterized in that The subject information also includes first device information, first user information and first operating environment information; The performing trust verification on the subject information to obtain a first trust level specifically includes: Obtaining city data space trust model data, wherein the city data space trust model data includes preset device information, preset user information, and preset operating environment information; Using the preset device information to perform trust verification on the first device information to obtain a first sub-trust level; When the first sub-trustworthiness is a first value, performing trustworthiness verification on the first user information using the preset user information to obtain a second sub-trustworthiness; When the second sub-trust level is the first value, the first operating environment information is trusted and verified using the preset operating environment information to obtain a third sub-trust level; The sum of the first sub-trust degree, the second sub-trust degree, and the third sub-trust degree is determined as the first trust degree.

3. The method according to claim 2, characterized in that After trust verification is performed on the first device information using the preset device information to obtain a first sub-trust level, the method further includes: When the first sub-trust level is the second value, the first trust level is determined to be the first sub-trust level.

4. The method according to claim 2, characterized in that After verifying the trustworthiness of the first user information using the preset user information to obtain the second sub-trustworthiness, the method further includes: When the second sub-trust degree is a second value, the sum of the first sub-trust degree and the second sub-trust degree is determined as the first trust degree.

5. The method according to any one of claims 1 to 4, characterized in that The second trust level satisfies formula (1), which includes: A2=sucs(s) / (sucs(s)+fais(s)) (1) Among them, A2 represents the second trust level; sucs(s) represents the number of historical successful trust verifications; fais(s) represents the number of historical failed trust verifications.

6. The method according to any one of claims 1 to 4, characterized in that The third trust degree satisfies formula (2), and the formula (2) includes: A3=1 / t (2) Among them, A3 represents the third level of trust; t represents the duration of successful trust verification.

7. The method according to any one of claims 1 to 4, characterized in that The managing the authority of the access user according to the first trust level, the second trust level, and the third trust level specifically includes: Taking the sum of the first trust degree, the second trust degree and the third trust degree as the total trust degree value; The authority of the access user is managed according to the total trust value.

8. The method according to claim 7, characterized in that The managing of the access rights of the access user according to the total trust value specifically includes: When the total trust value is greater than a first threshold and less than or equal to a second threshold, monitoring the behavior of the accessing user; When the total trust value is greater than a third threshold value and less than or equal to the first threshold value, performing behavior monitoring and mandatory authentication on the accessing user; When the total trust value is greater than or equal to the fourth threshold and less than or equal to the third threshold, the access user is denied authorization.

9. A rights management device, characterized in that: include: A first acquisition module is configured to acquire subject information of an accessing user, the subject information including first user information, the first user information including a historical number of failed trust verifications, a historical number of successful trust verifications, and a successful trust verification duration, where the successful trust verification duration is the number of natural days between the date of the accessing user's last successful trust verification and the date of the current trust verification plus one; a trust verification module, connected to the first acquisition module, configured to perform trust verification on the subject information to obtain a first trust level; a first determination module, connected to the trust verification module, configured to determine a second trust level according to the number of historical failed trust verifications and the number of historical successful trust verifications when the first trust level is a first type value; a second determining module, connected to the first determining module, configured to determine a third degree of trust according to the successful trust verification duration; A management module is connected to the trust verification module, the first determination module and the second determination module, and is used to manage the authority of the access user according to the first trust level, the second trust level and the third trust level.

10. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to implement the rights management method according to any one of claims 1 to 8.

Images