Data authorization management method and device, storage medium and terminal

Abstract

The embodiment of the invention discloses a data authorization management method and device, a storage medium and a terminal. After a user data access request is received, firstly, target request scene information is accurately determined, and a context basis is provided for subsequent processing. Then based on the scene information, a target data field set necessary for completing the scene is identified through a dynamic intelligent matching mechanism, authorization granularity control of the field level is achieved, and accurate matching of data supply and demand is ensured. And generating a field-level authorization strategy according to the determined field set, converting the minimum necessary data range into an executable security rule, definitely delimiting the data boundary of the access, and enhancing the compliance certainty. The data access operation is executed according to the strategy, the data acquisition is strictly limited in the necessary field range, the data minimization principle is implemented, and the processing efficiency and transparency of the data access event are improved.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a data authorization management method, apparatus, storage medium, and terminal. Background Technology

[0002] With the strengthening of global data protection regulations, data minimization has become a core principle, requiring the processing of only the minimum data necessary to achieve a specific purpose. Existing credit data systems have significant shortcomings in authorization granularity, dynamic policy adaptation, and service scenario identification, leading to problems such as excessive collection, lack of flexibility, and difficulty in traceability. These deficiencies stem from insufficient consideration of dynamic service needs and refined management in early design, increasing not only user privacy risks but also subjecting institutions to compliance penalties and reputational damage, ultimately hindering the secure flow of data elements. Summary of the Invention

[0003] This specification provides a data authorization management method, apparatus, storage medium, and terminal, which can solve the technical problems of single and rigid data authorization strategies in related technologies.

[0004] Firstly, embodiments of this specification provide a data authorization management method, the method comprising: Receive data access requests triggered by users and determine the target request scenario information in the aforementioned data access requests; Based on the above target request scenario information, identify the set of target data fields required to complete the above data access request; Based on the aforementioned target data field set, a field-level authorization policy is generated. This authorization policy is used to limit the scope of allowed data access to the aforementioned target data field set. The data access operation corresponding to the above data access request shall be executed in accordance with the above authorization policy.

[0005] In one possible implementation, the above-mentioned identification of the target data field set required to complete the above-mentioned data access request based on the target request scenario information includes: parsing the field request intent contained in the target request scenario information based on a pre-built domain knowledge graph, wherein the domain knowledge graph contains the association relationship between different request scenarios and various data fields; and identifying the target data field set required to complete the above-mentioned data access request from the domain knowledge graph according to the field request intent.

[0006] In one possible implementation, determining the target request scenario information in the data access request includes: dynamically identifying the request scenario type corresponding to the data access request through a scenario recognition model, and determining the target request scenario information corresponding to the request scenario type.

[0007] In one possible implementation, the above-mentioned generation of field-level authorization policies based on the target data field set includes: performing dynamic sensitivity assessment on each data field included in the target data field set to obtain the sensitivity of each data field in the target request scenario; and generating field-level authorization policies based on the sensitivity of each data field in the target request scenario.

[0008] In one possible implementation, the dimensions of the dynamic sensitivity assessment described above include at least one of the following: the inherent properties of the data field, the current request context, the device security status, and the network environment.

[0009] In one possible implementation, the method further includes: during the data access process, recording field-level access logs corresponding to the data access operations, wherein the field-level access logs include at least the information of the accessed data field, access time, access subject, and access result; performing risk analysis based on the field-level access logs, and generating a risk alarm and executing a predetermined risk mitigation operation when a preset abnormal pattern is detected in the data access operations.

[0010] Secondly, embodiments of this specification provide a data authorization management device, the device comprising: The scene recognition module is used to receive data access requests triggered by users and determine the target request scene information in the data access requests. The field recognition module is used to identify the set of target data fields required to complete the above data access request based on the target request scenario information. The policy generation module is used to generate field-level authorization policies based on the above-mentioned target data field set. The authorization policies are used to limit the scope of data that can be accessed to the above-mentioned target data field set. The data access module is used to execute the data access operation corresponding to the above data access request in accordance with the above authorization policy.

[0011] Thirdly, embodiments of this specification provide a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of the method described above.

[0012] Fourthly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method described above.

[0013] Fifthly, embodiments of this specification provide a terminal including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is adapted to be loaded by the processor and to execute the steps of the method described above.

[0014] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification provides a data authorization management method that receives a user-triggered data access request and determines the target request scenario information within the request. Based on the target request scenario information, it identifies the set of target data fields required to complete the data access request. It then generates a field-level authorization policy based on the target data field set, limiting the scope of allowed data access to within the target data field set. Finally, it executes the data access operation corresponding to the data access request according to the authorization policy. When the system receives a user-triggered data access request, it first accurately determines the corresponding target request scenario information. Using the current scenario as the starting point for authorization decisions, it proactively identifies and extracts the scenario intent behind the request, laying a precise contextual foundation for subsequent data minimization processing. After clarifying the request scenario, it dynamically analyzes and identifies the set of target data fields necessary to complete the specific scenario based on the target request scenario information. Through a dynamic and intelligent matching mechanism, it can automatically infer the fields necessary to serve the target request scenario, achieving a single-field-level authorization scope granularity. This enables precise and dynamic matching of demand and data supply in subsequent implementations, avoiding the exposure and collection of unnecessary data. Next, based on the determined set of target data fields, it executes the operation of generating a field-level authorization policy. The target data field set is transformed into a set of security rules with clearly defined permitted scope that the system can execute. This strategy precisely defines the specific data boundaries that the access operation can reach, enhancing the compliance certainty of the system during data access. Finally, based on the generated field-level authorization policy, the corresponding data access operation is executed, controlling data access within the necessary field range. This step minimizes the scope of data access at the operational level, provides precise field-level granularity for subsequent auditing and traceability, and makes the response path for data access events clearer and more efficient. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 An exemplary system architecture diagram of a data authorization management method provided in the embodiments of this specification; Figure 2 A flowchart illustrating a data authorization management method provided in an embodiment of this specification; Figure 3 A flowchart illustrating a data authorization management method provided in an embodiment of this specification; Figure 4 This specification provides a schematic diagram of the overall architecture of a data authorization management method as illustrated in an embodiment. Figure 5 A flowchart illustrating the scene dynamic recognition process provided in the embodiments of this specification; Figure 6 A structural block diagram of a data authorization management device provided in the embodiments of this specification; Figure 7 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Detailed Implementation

[0017] To make the features and advantages of the embodiments of this specification more apparent and understandable, the technical solutions of the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the embodiments of this specification.

[0018] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those in this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments in this specification as detailed in the appended claims. Furthermore, in the description of the embodiments in this specification, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments in this specification, "multiple" refers to two or more.

[0019] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0020] With the increasing sophistication and implementation of data protection regulations globally, the principle of "data minimization" has been established as one of the core guidelines in data processing activities. This principle strictly requires data controllers to process only the minimum amount of data necessary to achieve a specific purpose. Against this backdrop, the credit reporting industry, as a typical sector handling large amounts of highly sensitive personal financial information, also faces compliance challenges.

[0021] Currently, several key technical flaws exist in the authorization and sharing system of credit data, hindering its efficient, secure, and compliant operation. The primary problem lies in the commonly used coarse-grained authorization model, with most systems still relying on an "all or nothing" overall authorization mechanism. Users cannot finely define and control the scope of shared data, leading to financial institutions obtaining complete and detailed credit histories even in scenarios requiring limited information, such as preliminary checks for rental eligibility. This clearly constitutes excessive data collection and use. Secondly, traditional access control models, such as Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC), often exhibit static and rigid policies. These policies are typically predefined during the system design phase and are difficult to dynamically adjust based on changing needs and the user's real-time context, thus showing significant shortcomings in flexibly adapting to complex application scenarios. Furthermore, existing systems generally lack the ability to intelligently identify the correlation between service scenarios and data requirements. The system cannot automatically parse the specific service intent behind a data request, and therefore cannot accurately match the minimum set of data fields necessary to achieve that intent. It still heavily relies on human experience for strategy configuration, which is not only inefficient but also highly susceptible to errors due to human factors. Finally, in terms of compliance verification and data traceability, because authorization operations and access logs are not recorded precisely at the field level, it is difficult to quickly and accurately determine responsibility and assess the scope of impact in the event of data breaches or misuse, making the audit process complex and costly. These limitations increase the risk of personal privacy breaches for users, thereby weakening overall trust in the digital financial services system. For financial institutions, they may directly face a series of penalties for violations. From a macro-level industry perspective, these obstacles severely restrict the secure and efficient circulation and value release of data as a key production factor.

[0022] From the broader perspective of internet big data applications, these issues essentially reflect the universal challenges of effective data classification and management within complex data ecosystems. In the internet big data environment, how to achieve precise classification, dynamic authorization, and compliant use of data assets based on service objectives, data sensitivity, and usage context has become a core issue concerning maximizing data value and controlling security risks.

[0023] Therefore, this specification provides a data authorization management method to solve the technical problem of the above-mentioned single and rigid data authorization strategy.

[0024] Please see Figure 1 , Figure 1 This is an exemplary system architecture diagram of a data authorization management method provided in the embodiments of this specification.

[0025] like Figure 1 As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 serves as the medium for providing a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired or wireless communication links, such as wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables, and wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0026] Terminal 101 can interact with server 103 via network 102 to receive messages from or send messages to server 103. Alternatively, terminal 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Terminal 101 can be hardware or software. When terminal 101 is hardware, it can be various electronic devices, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal 101 is software, it can be installed in the aforementioned electronic devices and can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0027] In the embodiments of this specification, terminal 101 first receives a data access request triggered by a user and determines the target request scenario information in the data access request; then, terminal 101 identifies the target data field set required to complete the data access request based on the target request scenario information; further, terminal 101 generates a field-level authorization policy based on the target data field set, the authorization policy being used to limit the scope of allowed data access to within the target data field set; finally, terminal 101 executes the data access operation corresponding to the data access request according to the authorization policy.

[0028] Server 103 can be a server that provides various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0029] Alternatively, the system architecture may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification can be applied to a system structure that only includes terminal 101. The embodiments of this specification do not limit this.

[0030] It should be understood that Figure 1 The number of terminals, networks, and servers shown is only illustrative; the number can be any number of terminals, networks, and servers depending on the implementation requirements.

[0031] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data authorization management method provided in an embodiment of this specification. The execution entity in this embodiment can be a terminal executing data authorization management, a processor within the terminal executing the data authorization management method, or a data authorization management service within the terminal executing the data authorization management method. For ease of description, the following example uses a processor within the terminal as the execution entity to illustrate the specific execution process of the data authorization management method.

[0032] like Figure 2 As shown, data authorization management methods may include at least: S202. Receive a data access request triggered by a user and determine the target request scenario information in the data access request.

[0033] Optionally, considering that only when the purpose of data use is clearly defined can all subsequent decisions about the scope of data access have an objective basis, and the scenario information targeted by the data request can reflect the user's needs and purpose for using the data, in the embodiments of this specification, the scenario information is used to measure the minimum authorized scope of data use. This can support the efficient operation of the service while strictly implementing the principle of data minimization, ensuring data security and protecting user rights at the same time.

[0034] Specifically, when the system receives a data access request, it determines the purpose of the access by identifying the target request scenario information within the request. This transforms the authorization basis from traditional static identity or role attributes to a dynamic context strongly associated with the data usage objective, ensuring the clarity of the data processing activity's purpose from the source. The core technology of this step lies in context-aware and semantic parsing of the request's metadata. In practice, the system can extract key parameters, interface identifiers, user behavior sequences, and other features contained in the request, and combine them with a predefined scenario classification model to accurately determine the specific request scenario to which the request belongs, such as "credit approval," "service activation qualification pre-screening," or "marketing profile analysis," laying a precise contextual foundation for subsequent data minimization processing.

[0035] S204. Identify the set of target data fields required to complete the data access request based on the target request scenario information.

[0036] Optionally, after clarifying the target request scenario information, the minimum necessary data range can be further determined. This step relies on a built-in, cognitively capable decision engine that encapsulates complex service logic. This engine may be based on a well-constructed domain knowledge graph that clearly defines the inherent connections and dependencies between various scenarios and underlying data fields; or it may introduce machine learning models that, through learning from historical compliant access data, develop the ability to predict the necessary field sets for specific scenarios. This step achieves a dynamic and precise mapping from service scenarios to data field sets. For example, in a "credit approval" scenario, the engine will automatically infer the required fields such as "personal identity information," "asset proof," and "credit report summary" based on risk control rules, and will never include irrelevant information such as "personal interests and hobbies." This allows the authorization granularity to be refined from the traditional data table or database level down to the individual data field level, achieving a precise match between demand and data supply, and avoiding excessive data collection and use.

[0037] S206. Generate field-level authorization policies based on the target data field set. The authorization policies are used to limit the scope of allowed data access to the target data field set.

[0038] Furthermore, the system generates a field-level authorization policy based on the target data field set output from the previous step, that is, transforming the target data field set into a structured, machine-readable authorization policy file. The policy obtained in the embodiments of this specification is a clear, fine-grained access control list, which precisely defines the boundaries of data resources that the requester is authorized to access in the current session. In other words, the authorization policy limits the scope of allowed data access to within the target data field set. In a feasible implementation, pre-defined verification logic can also be embedded during the policy generation process, such as comparing it with data classification and grading standards to ensure that highly sensitive fields can only be accessed under specific high-level authorization. By concretizing the abstract compliance requirements ("data minimization" principle) into a clear, immutable, and technically verifiable authorization policy, the system's compliance certainty and predictability of access behavior are greatly enhanced, providing an authoritative basis for the final policy execution.

[0039] S208. Execute the data access operation corresponding to the data access request according to the authorization policy.

[0040] Optionally, in the final stage of the entire process, all prior decisions are applied to actual data interaction, executing the data access operation corresponding to the data access request according to the authorization policy. Specifically, this can be implemented through a policy execution point located on a critical channel of the data access path. When a specific query or data retrieval operation occurs, the execution point intercepts the request and verifies in real time whether the data field to be accessed is within the scope allowed by the authorization policy generated in step S206, thereby achieving real-time verification and filtering of data flow permissions. For authorized fields, the request can pass normally and retrieve data; for unauthorized fields, even if they may exist in the same data table as other authorized fields, they will be filtered or intercepted in the returned results. This embodiment implements the principle of least privilege at the security level and facilitates the subsequent generation of accurate and error-free access logs at the field level, providing clarity and convenience for security auditing, event tracing, and compliance evidence collection, making the entire data flow process highly transparent and controllable.

[0041] This specification provides a data authorization management method that receives a user-triggered data access request and determines the target request scenario information within the request. Based on the target request scenario information, it identifies the set of target data fields required to complete the data access request. It then generates a field-level authorization policy based on the target data field set, limiting the scope of allowed data access to the target data field set. Finally, it executes the data access operation corresponding to the data access request according to the authorization policy. When the system receives a user-triggered data access request, it first accurately determines the corresponding target request scenario information. Using the current scenario as the starting point for authorization decisions, it proactively identifies and extracts the scenario intent behind the request, laying a precise contextual foundation for subsequent data minimization processing. After clarifying the request scenario, it dynamically analyzes and identifies the set of target data fields necessary to complete the specific scenario based on the target request scenario information. Through a dynamic and intelligent matching mechanism, it can automatically infer the fields necessary to serve the target request scenario, achieving a single-field-level authorization scope granularity. This enables precise and dynamic matching of demand and data supply in subsequent implementations, avoiding the exposure and collection of unnecessary data. Next, based on the determined set of target data fields, it executes the operation of generating a field-level authorization policy. The target data field set is transformed into a set of security rules with clearly defined permitted scope that the system can execute. This strategy precisely defines the specific data boundaries that the access operation can reach, enhancing the compliance certainty of the system during data access. Finally, based on the generated field-level authorization policy, the corresponding data access operation is executed, controlling data access within the necessary field range. This step minimizes the scope of data access at the operational level, provides precise field-level granularity for subsequent auditing and traceability, and makes the response path for data access events clearer and more efficient.

[0042] Please see Figure 3 , Figure 3 This is a flowchart illustrating a data authorization management method provided in an embodiment of this specification.

[0043] like Figure 3 As shown, data authorization management methods may include at least: S302. Receive a data access request triggered by a user, dynamically identify the request scenario type corresponding to the data access request through a scenario recognition model, and determine the target request scenario information corresponding to the request scenario type.

[0044] Optionally, please refer to Figure 4 , Figure 4 This is a schematic diagram of the overall architecture of a data authorization management method provided in an embodiment of this specification. Figure 4As shown, the exemplary overall architecture includes a Presentation Layer, Application Layer, Service Layer, Core Layer, and Data Persistence Layer. The Presentation Layer primarily manifests as a user interface, using various media such as Web, App, and management console. It is responsible for user interaction, providing an operational interface and visual displays. All user requests originate from this layer, and the final results are displayed here. The Application Layer specifically includes an authorization request processing module, used to receive user instructions, coordinate lower-level services, and complete operations such as creating, querying, and updating authorization policies; and an authorization verification execution module, used to receive data access requests, query the policy engine, execute the final authorization decision (allow / deny), and record logs. The Core Layer, as the system's rule center, contains all core rules, models, and classification definitions. Its authorization policy management engine is a core module, responsible for policy parsing, calculation, and decision-making. The Data Persistence Layer is responsible for the persistent storage of all data, decoupled from the upper layers to ensure data security and reliability.

[0045] In the embodiments described in this specification, the system receives data access requests triggered by users from the presentation layer at the application layer. When the data access request arrives at the system application layer, the authorization request processing module of the application layer captures it and coordinates with the scene dynamic recognition service in the service layer to perform in-depth analysis. For details, please refer to... Figure 5 , Figure 5 This is a flowchart illustrating the scene dynamic recognition process provided in the embodiments of this specification. Figure 5 As shown, the system uses a trained scene recognition model to perform real-time inference on the multi-dimensional contextual features of the request. These contextual features include, but are not limited to, the requester's subject type (e.g., internal risk control department or cooperating third party), request content (e.g., the sequence of request operations), user behavior, and device environment (e.g., device fingerprint of the access point, network environment parameters). By normalizing and extracting features from this heterogeneous data, the model can dynamically and accurately determine the request scene type of the current request, such as classifying it as "pre-loan approval," "post-loan risk monitoring," or "insurance underwriting." After determining the request scene type, the system can further determine the target request scene information corresponding to the request scene type, that is, the authorization field information related to the current scene.

[0046] In practical implementation, the highest probability scenario can be identified as the request scenario type corresponding to the data access request. Based on the user's historical request data, the confidence level of this result is calculated. The confidence level characterizes the reasonableness and reliability of the current result. When the confidence level is greater than or equal to a preset threshold (e.g., 0.7), the highest probability scenario is determined as the request scenario type corresponding to the data access request. If the confidence level is less than the preset threshold, the default scenario is determined as the request scenario type corresponding to the data access request. The default scenario is a scenario with a strictly regulated scope of authorization and high controllability. This provides a reliable contextual anchor for all subsequent data minimization decisions, ensuring that data processing activities are closely associated with a specific and legitimate service purpose from beginning to end.

[0047] S304. Based on a pre-built domain knowledge graph, parse the fields containing the request intent in the target request scenario information. The domain knowledge graph contains the association between different request scenarios and various data fields.

[0048] Optionally, after clarifying the target request scenario information, the system uses an automatic minimization filtering service at the service layer to parse the field request intent contained in the target request scenario information from a pre-built domain knowledge graph. This domain knowledge graph is a semantic network that systematically encodes expert knowledge, compliance rules, and service logic for specific industry domains (such as credit reporting, finance, and healthcare) in a machine-readable form. Internally, it clearly defines the sets of data fields required by different domain scenarios to achieve certain functions, as well as the inherent relationships and constraints between these fields. For example, in the credit reporting scenario, the credit reporting domain knowledge graph explicitly records that the core reliance of the "pre-loan approval" scenario on fields such as "basic personal information," "occupation and asset data," and "historical credit record summary," while excluding irrelevant or overly sensitive information such as "transaction details."

[0049] Furthermore, the process of parsing the field request intent involves semantic expansion and reasoning of the target request scenario information through the knowledge graph, transforming abstract scenario tags into a concrete, service logic-driven list of data requirements. This step solidifies the domain knowledge of human experts into automatically executable judgment logic, providing a reliable theoretical basis and rule guarantee for generating the minimum necessary dataset, effectively avoiding compliance risks and logical black box issues that may arise from purely data-driven methods.

[0050] S306. Based on the field request intent, identify the set of target data fields required to complete the data access request from the domain knowledge graph.

[0051] Optionally, based on step S304, this application further outputs a precise and executable set of data fields based on the field request intent parsed from the domain knowledge graph. In specific implementation, based on the determined scenario nodes, the application traverses and retrieves along the relationship paths defined in the domain knowledge graph to locate all the necessary data fields directly associated with them. Furthermore, it constrains the time range and aggregation granularity of the fields according to built-in rules (such as "only records from the last three years"), ultimately outputting a target data field set that has been filtered and verified by service logic. This process achieves automated and precise mapping between field request intents and data assets. It allows the granularity of authorization decisions to be refined from the traditional data table or database level to the level of individual data fields, ensuring that every data field allowed by the subsequent authorization strategy has a clear purpose and necessity to support the current request scenario, thus avoiding excessive data collection from the decision-making logic perspective.

[0052] S308. Perform dynamic sensitivity assessment on each data field contained in the target data field set to obtain the sensitivity of each data field in the target request scenario; generate a field-level authorization policy based on the sensitivity of each data field in the target request scenario.

[0053] Optionally, considering that the aforementioned target data field set is logically necessary for the service, but its security risks may dynamically change with the context, a dynamic field sensitivity assessment service in the service layer can be used to dynamically assess the sensitivity of each data field in the target data field set, thereby obtaining the sensitivity of each data field in the target request scenario. The dynamic field sensitivity assessment service is responsible for transforming the sensitivity of a data field from a static, predefined label into a real-time calculated, continuous risk quantification value. The dimensions of dynamic sensitivity assessment integrate at least several dynamic factors, including the inherent attributes of the data field (such as its preset level in the data classification and grading system), the current request context (such as whether this access is for internal risk control or external cooperation), the device security status (such as whether the requesting device is jailbroken or rooted), and the network environment (such as whether access is through a trusted network). A quantitative model jointly evaluates these multi-dimensional information, ultimately outputting a personalized sensitivity score for each field in the current specific context.

[0054] Furthermore, within the core layer's authorization policy management engine, the system integrates the target data field set (necessity) and dynamic sensitivity (real-time risk) to generate the final field-level authorization policy. For example, for highly sensitive fields, even if necessary, secondary authentication may be triggered, or only partially masked information may be returned. The final generated authorization policy is a set of machine-readable rules that precisely define each allowed field and its access conditions (such as whether it can be downloaded raw or only visualized) in this data access operation. On one hand, this step introduces dynamic risk perception capabilities, enabling the authorization policy to adapt to complex and ever-changing security environments, achieving context-aware intelligent security control. On the other hand, it integrates the two objectives of data minimization and security risk minimization at the policy level, generating optimal authorization decisions that meet service requirements while taking into account real-time risk conditions, greatly improving the security and compliance robustness of the data sharing process.

[0055] S310. During the data access process, record the field-level access logs corresponding to the data access operations. The field-level access logs shall include at least the information of the accessed data field, the access time, the access subject, and the access result. Perform risk analysis based on the field-level access logs. When a preset abnormal pattern is detected in the data access operation, generate a risk alarm and execute the predetermined risk mitigation operation.

[0056] Optionally, within a refined data authorization management system, the execution of authorization decisions and continuous post-event monitoring constitute a crucial closed loop to ensure the system's continuous, secure, and reliable operation. This stage focuses on the transparent recording and dynamic risk response of the data access process. First, during the specific execution of data access operations, the system synchronously generates and persists field-level access logs. The key point of this step is to refine the visibility of access behavior from the traditional dataset or table level to each specific data field being accessed. When the authorization verification execution module allows the data request according to the policy, the system will trigger a logging mechanism at the interception point in the application layer or data persistence layer the instant the data is actually read or returned.

[0057] In one feasible implementation, the recorded field-level access log is a structured audit event. Its core metadata includes at least the following dimensions: a unique identifier for the accessed data field, used to accurately trace back to the smallest data unit; a timestamp of the access, used to establish the event sequence; the identity information of the accessing entity, clarifying the responsible party; and the specific result status of the access, such as successfully returning data, returning a null value due to policy rejection, or triggering data masking. By achieving end-to-end observability at the field level, precise evidence is provided for post-event auditing, compliance verification, and security incident investigation. Once an abnormal data access or leakage incident occurs, auditors can quickly and accurately pinpoint which field was accessed, when, and by whom, and in what way, greatly improving the accuracy and efficiency of auditing.

[0058] Furthermore, the system performs proactive, near real-time risk analysis based on this continuously generated fine-grained audit data. This function is typically carried out by a separate real-time authorization monitoring and early warning service within the service layer. It continuously processes field-level access log streams and, based on a built-in rule engine and anomaly detection model, dynamically assesses data access behavior for security reasons. Predefined anomaly patterns are the core basis for this analysis process. These patterns are usually predefined based on service logic and security policies and may manifest in various forms. For example, a data crawling pattern that performs high-frequency scanning of a large number of highly sensitive fields within a short period; an anomaly access sequence that matches the characteristics of an insider threat and occurs outside of working hours; or a behavioral pattern where access requests to multiple related fields of the same data entity are logically contradictory, suggesting possible fraudulent intent. When the analysis engine detects that the access behavior matches any anomaly pattern, the system triggers a predefined risk mitigation workflow. This typically includes, but is not limited to, generating and pushing risk alerts of different levels to the security operations center, automatically suspending sessions of suspicious entities or temporarily increasing their authentication strength, and even executing predefined scripts for automatic blocking or data anonymization. This step endows the system with dynamic risk immunity and self-healing capabilities, enabling it to dynamically perceive and respond to potential threats based on real-time access behavior feedback, thereby building a proactive data security protection system that can continuously evolve and adapt to counteract threats.

[0059] This specification provides a data authorization management method through its embodiments. By recording field-level access logs and performing real-time risk analysis based on these logs, it not only ensures the transparency and auditability of the data access process but also enables the timely detection, early warning, and handling of security risks, significantly improving the resilience and reliability of data infrastructure in the face of internal and external security threats.

[0060] In the typical data-intensive application scenario of credit reporting, the sophisticated authorization management system constructed in this solution can fully achieve the goals of data security and compliant data flow. Taking a specific data access request as an example, the data authorization management methods can at least include: Optionally, the process is triggered when a user initiates a data query request through the presentation layer's interface (such as a financial institution's credit approval system). This request carries rich context, and the system first performs in-depth analysis of the request through a request scenario dynamic identification service deployed at the service layer. This service analyzes multi-dimensional information such as the request source, operation sequence, and interface characteristics in real time, using a built-in scenario classification model to accurately determine the request scenario type to which the current request belongs. For example, the system can accurately identify whether this query is for "credit card limit approval," "personal loan risk assessment," or "post-loan asset quality monitoring." Determining the request scenario provides a legitimate basis and contextual anchor for all subsequent data minimization decisions.

[0061] Optionally, after clarifying the request scenario, the process enters the core intelligent decision-making stage. The system utilizes an enhanced automatic minimization filtering service, which collaborates with a pre-built credit reporting domain knowledge graph in the core layer. This domain knowledge graph systematically encodes the professional rules, compliance requirements, and logical relationships between data fields in credit reporting services. Based on the identified request scenario, the service infers from the knowledge graph and extracts the minimum set of data fields necessary to complete the scenario. For example, for the "credit card limit approval" scenario, the knowledge graph explicitly indicates the need for core fields such as "personal identification identifier," "summary of credit transactions in the past six months," and "current total debt-to-asset ratio," while automatically excluding fields irrelevant to the scenario or overly sensitive, such as "counterparty information for each specific transaction" or "non-credit utility payment records." This process achieves a precise mapping from request intent to data assets, ensuring a strict match between data supply and demand from the source of decision-making logic.

[0062] Furthermore, the system will initiate a dynamic field sensitivity assessment service to perform context-aware risk calibration on the initial set of fields selected above. In this stage, the sensitivity of each data field is no longer a static label, but a dynamic quantitative value calculated in real time, comprehensively considering the current request context (such as whether the requester is a licensed financial institution), the user's real-time environment (such as the security status of the login device and the trustworthiness of the network environment), and the field's inherent attributes (such as the preset level in data classification and grading). This mechanism enables the system to intelligently perceive changes in risk. For example, when a request is detected to originate from a network environment that may pose a security risk, even fields that are necessary in the request will have their dynamic sensitivity increased accordingly.

[0063] Furthermore, the core layer's authorization policy management engine integrates two major factors: "necessity" (from the field set of the knowledge graph) and "real-time risk" (from dynamic sensitivity assessment) to generate a final, field-level, fine-grained authorization policy. This policy precisely specifies the list of fields allowed for this access and may impose additional access conditions on highly sensitive fields. Subsequently, under the control of the application layer's authorization verification execution module, data access operations are strictly limited to execution within this policy. The system only extracts and returns authorized fields from the credit database in the data persistence layer; all fields not explicitly permitted are effectively filtered in the returned results. Throughout the entire data access lifecycle, the system continuously performs end-to-end monitoring and recording at the field level. Each access behavior to a specific field, including the access subject, time, field identifier, and operation result, is recorded in real time and stored in the field-level authorization log library. The service layer's real-time authorization monitoring and early warning service performs continuous risk analysis based on these fine-grained log streams, dynamically perceiving potential security threats through predefined rules and anomaly detection models (such as crawling behavior that frequently accesses multiple sensitive fields within a short period). Once an abnormal pattern is detected, the system will trigger an alert and execute predetermined risk mitigation measures, such as suspending the session or notifying the security operations center for manual intervention, thereby building a complete data security closed loop from pre-event prevention and in-event control to post-event auditing and emergency response.

[0064] In the embodiments of this specification, a data authorization management method is provided. When used in the complete interactive process of credit investigation scenarios, it demonstrates a system centered on the request scenario and employing strategies such as intelligent decision-making and dynamic risk perception. This not only achieves field-level data minimization and precise authorization in terms of technology, but also ensures the efficient circulation and value release of data under the premise of security and compliance in terms of mechanism.

[0065] Please see Figure 6 , Figure 6 This is a structural block diagram of a data authorization management device provided as an embodiment of this specification. Figure 6 As shown, the data authorization management device 600 includes: Scene recognition module 610 is used to receive data access requests triggered by users and determine the target request scene information in the data access requests; The field recognition module 620 is used to identify the set of target data fields required to complete the data access request based on the target request scenario information. The strategy generation module 630 is used to generate field-level authorization policies based on the target data field set. The authorization policies are used to limit the scope of data that can be accessed to the target data field set. The data access module 640 is used to perform data access operations corresponding to data access requests based on the authorization policy.

[0066] Optionally, the field recognition module 620 is also used to parse the field request intent contained in the target request scenario information based on a pre-built domain knowledge graph. The domain knowledge graph contains the association between different request scenarios and various data fields. Based on the field request intent, the target data field set required to complete the data access request is identified from the domain knowledge graph.

[0067] Optionally, the scene recognition module 610 is also used to dynamically identify the request scene type corresponding to the data access request through the scene recognition model, and determine the target request scene information corresponding to the request scene type.

[0068] Optionally, the policy generation module 630 is also used to perform dynamic sensitivity assessment on each data field contained in the target data field set to obtain the sensitivity of each data field in the target request scenario; and generate a field-level authorization policy based on the sensitivity of each data field in the target request scenario.

[0069] Optionally, the dimensions of dynamic sensitivity assessment include at least one of the following: the inherent properties of the data field, the current request context, the device security status, and the network environment.

[0070] Optionally, the data authorization management device 600 further includes: an access log collection module, used to record field-level access logs corresponding to data access operations during the data access process. The field-level access logs include at least the information of the accessed data field, access time, access subject, and access result; and to perform risk analysis based on the field-level access logs. When a preset abnormal pattern is detected in the data access operation, a risk alarm is generated and a predetermined risk mitigation operation is executed.

[0071] This specification provides a data authorization management device, comprising: a scene recognition module for receiving a user-triggered data access request and determining the target request scene information in the data access request; a field recognition module for identifying the set of target data fields required to complete the data access request based on the target request scene information; a policy generation module for generating a field-level authorization policy based on the target data field set, the authorization policy limiting the scope of allowed data access to within the target data field set; and a data access module for executing the data access operation corresponding to the data access request according to the authorization policy. When the system receives a user-triggered data access request, it first accurately determines the corresponding target request scene information, using the current scene as the starting point for authorization decisions. By actively identifying and extracting the scene intent behind the request, it lays a precise contextual foundation for subsequent data minimization processing. After clarifying the request scene, it dynamically analyzes and identifies the set of target data fields necessary to complete the specific scene based on the target request scene information. Through a dynamic and intelligent matching mechanism, it can automatically infer the fields necessary to serve the target request scene, achieving a single-field-level authorization scope granularity, enabling precise and dynamic matching of demand and data supply in the subsequent process, and avoiding the exposure and collection of unnecessary data. Next, based on the determined set of target data fields, the process of generating field-level authorization policies is executed. This transforms the target data field set into a set of security rules with clearly defined permitted scopes that the system can execute. This policy precisely defines the specific data boundaries that this access operation can reach, enhancing the compliance certainty of the system during data access. Finally, based on the generated field-level authorization policies, the corresponding data access operations are executed, controlling data access within the necessary field range. This step minimizes the scope of data access at the operational level, provides precise field-level granularity for subsequent auditing and traceability, and makes the response path for data access events clearer and more efficient.

[0072] This specification provides a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of any of the methods described above.

[0073] This specification also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the steps of any of the methods described in the above embodiments.

[0074] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 7As shown, terminal 700 may include: at least one terminal processor 701, at least one network interface 704, user interface 703, memory 705, and at least one communication bus 702.

[0075] The communication bus 702 is used to enable communication between these components.

[0076] The user interface 703 may include a display screen and a camera. Optionally, the user interface 703 may also include a standard wired interface and a wireless interface.

[0077] The network interface 704 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0078] The terminal processor 701 may include one or more processing cores. The terminal processor 701 connects to various parts within the terminal 700 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 705, and by calling data stored in the memory 705. Optionally, the terminal processor 701 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The terminal processor 701 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the terminal processor 701.

[0079] The memory 705 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 705 may include a non-transitory computer-readable storage medium. The memory 705 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 705 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 705 may also be at least one storage device located remotely from the aforementioned terminal processor 701. Figure 7 As shown, the memory 705, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a data authorization management program.

[0080] exist Figure 7 In the terminal 700 shown, the user interface 703 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 701 can be used to call the data authorization management program stored in the memory 705 and specifically perform the following operations: Receive data access requests triggered by users and determine the target request scenario information in the data access requests; Identify the set of target data fields required to complete the data access request based on the target request scenario information; Generate field-level authorization policies based on the target data field set. These authorization policies are used to limit the scope of allowed data access to the target data field set. Perform the data access operation corresponding to the data access request according to the authorization policy.

[0081] In some embodiments, when the terminal processor 701 performs the following steps when identifying the set of target data fields required to complete a data access request based on target request scenario information: based on a pre-built domain knowledge graph, parse the field request intent contained in the target request scenario information, wherein the domain knowledge graph contains the association between different request scenarios and various data fields; and identify the set of target data fields required to complete a data access request from the domain knowledge graph according to the field request intent.

[0082] In some embodiments, when the terminal processor 701 executes the determination of the target request scenario information in the data access request, it specifically performs the following steps: dynamically identifying the request scenario type corresponding to the data access request through a scenario recognition model, and determining the target request scenario information corresponding to the request scenario type.

[0083] In some embodiments, when the terminal processor 701 executes the generation of a field-level authorization policy based on a target data field set, it specifically performs the following steps: performing dynamic sensitivity assessment on each data field included in the target data field set to obtain the sensitivity of each data field in the target request scenario; and generating a field-level authorization policy based on the sensitivity of each data field in the target request scenario.

[0084] In some embodiments, the dimensions of dynamic sensitivity assessment include at least one of the following: the inherent properties of the data field, the current request context, the device security status, and the network environment.

[0085] In some embodiments, the terminal processor 701 further performs the following steps: during the data access process, it records the field-level access log corresponding to the data access operation. The field-level access log includes at least the information of the accessed data field, the access time, the access subject, and the access result; it performs risk analysis based on the field-level access log, and when a preset abnormal pattern is detected in the data access operation, it generates a risk alarm and executes a predetermined risk mitigation operation.

[0086] In the several embodiments provided in this specification, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0087] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0088] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

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

[0090] Furthermore, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the credit data and personal data involved in this specification were obtained with full authorization.

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

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

[0093] The above is a description of a data authorization management method, apparatus, storage medium, and terminal provided in the embodiments of this specification. For those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this specification.

Claims

1. A data authorization management method, the method comprising: Receive a data access request triggered by a user and determine the target request scenario information in the data access request; Based on the target request scenario information, identify the set of target data fields required to complete the data access request; A field-level authorization policy is generated based on the target data field set, and the authorization policy is used to limit the scope of data that is allowed to be accessed to the target data field set; The data access operation corresponding to the data access request is executed according to the authorization policy.

2. The method according to claim 1, wherein identifying the set of target data fields required to complete the data access request based on the target request scenario information includes: Based on a pre-built domain knowledge graph, the request intent of the fields contained in the target request scenario information is parsed. The domain knowledge graph contains the association between different request scenarios and various data fields. Based on the field request intent, identify the set of target data fields required to complete the data access request from the domain knowledge graph.

3. The method according to claim 1, wherein determining the target request scenario information in the data access request includes: The scene recognition model dynamically identifies the request scene type corresponding to the data access request and determines the target request scene information corresponding to the request scene type.

4. The method according to claim 1, wherein generating a field-level authorization strategy based on the target data field set includes: Dynamic sensitivity assessment is performed on each data field included in the target data field set to obtain the sensitivity of each data field in the target request scenario; Generate field-level authorization policies based on the sensitivity of each data field in the target request scenario.

5. The method according to claim 4, wherein the dimensions of the dynamic sensitivity assessment include at least one of the inherent attributes of the data field, the current request context, the device security status, and the network environment.

6. The method according to claim 1, further comprising: During the data access process, the field-level access logs corresponding to the data access operations are recorded. The field-level access logs include at least the information of the accessed data field, the access time, the access subject, and the access result. Risk analysis is performed based on the field-level access logs. When a preset abnormal pattern is detected in the data access operation, a risk alarm is generated and a predetermined risk mitigation operation is executed.

7. A data authorization management device, the device comprising: The scene recognition module is used to receive data access requests triggered by users and determine the target request scene information in the data access requests; The field recognition module is used to identify the set of target data fields required to complete the data access request based on the target request scenario information. The strategy generation module is used to generate field-level authorization policies based on the target data field set, wherein the authorization policies are used to limit the scope of data that can be accessed to the target data field set; The data access module is used to execute the data access operation corresponding to the data access request according to the authorization policy.

8. A computer program product comprising instructions that, when run on a computer or processor, causes the computer or processor to perform the steps of the method as claimed in any one of claims 1 to 6.

9. A computer storage medium storing a plurality of instructions adapted for loading by a processor and performing the steps of the method as claimed in any one of claims 1 to 6.

10. A terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as claimed in any one of claims 1 to 6.

Images