Automobile financial data access method and system based on permission control

Abstract

The application provides a kind of based on permission control's automobile financial data access method and system, it is related to financial data security access technical field, according to identity identification string, access preset permission policy mapping table, extract and the access control rule entry corresponding to identity identification string and role attribution label includes resource locator and operation permission binding record and time domain constraint condition;Permission matching is carried out to target data resource locator using binding record, and operation permission type is obtained, time domain compliance determination is carried out to time stamp using time domain constraint condition, and time domain compliance state identification is obtained;When time domain compliance state identification indicates that time stamp is in valid interval, corresponding access action is carried out to target data according to operation permission type, access receipt is obtained and returned to request end.The application realizes the multi-dimensional fine control of automobile financial data.

Description

Technical Field

[0001] This invention relates to the field of financial data security access technology, and more specifically, to a method and system for accessing automotive financial data based on access control. Background Technology

[0002] With the deepening of digital transformation in the auto finance industry, auto finance data encompasses a variety of highly sensitive business data, including customer credit information, vehicle mortgage registration data, repayment records, and risk control assessment models. The security of access to this data directly impacts the compliant operation of financial institutions and the protection of customer privacy. Existing auto finance data access control technologies typically employ a role-based static permission allocation mechanism. This involves pre-setting fixed data access permission ranges for different roles, and performing a one-time authentication based solely on the role label when an access request arrives. This approach has significant shortcomings in practical applications: On the one hand, existing technologies only focus on the static binding relationship between the requester's role attributes and the target resource when determining permissions, while ignoring compliance verification of the time-domain dimension of the access request initiation time. This can lead to unauthorized data access behavior during non-business hours, system maintenance windows, or temporary control periods. On the other hand, existing technologies lack a systematic mechanism to jointly map the requester's identity identifier string with the role affiliation label and accurately extract complete access control rule entries, including resource locators, operation permission binding records, and time-domain constraints, from the preset permission policy mapping table. This results in coarse-grained permission determination and a lack of time-domain control, making it difficult to meet the refined control requirements of auto finance businesses for data access in terms of multiple dimensions of joint constraints, such as identity verification, role verification, resource matching, and time compliance. Summary of the Invention

[0003] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a method for accessing automotive financial data based on access control, the method comprising: The system receives an auto finance data access request from the requesting client. The auto finance data access request carries the requesting client's identity string, the requesting client's role affiliation tag, the resource locator of the target auto finance data, and the request initiation timestamp. Based on the requester's identity string, a preset permission policy mapping table is retrieved, and access control rule entries corresponding to the requester's identity string and the requester's role affiliation tag are extracted. The access control rule entries include resource locators and operation permissions binding records as well as time-domain constraints. By using the binding record of resource locators and operation permissions in the access control rule entries, permission matching processing is performed on the resource locators of the target auto finance data to obtain the operation permission type, and the time domain constraint conditions are used to perform time domain compliance judgment processing on the request initiation timestamp to obtain the time domain compliance status identifier. When the time-domain compliance status indicator indicates that the request initiation timestamp is within the valid range defined by the time-domain constraints, the corresponding data access action is performed on the target auto finance data according to the operation permission type, an auto finance data access receipt is obtained, and the auto finance data access receipt is returned to the access requesting end.

[0004] Furthermore, embodiments of the present invention also provide an auto finance data access system based on access control, comprising: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the above-described access control-based automotive finance data access method by executing the machine-executable instructions.

[0005] Based on the above, firstly, by receiving an access request carrying a requester's identity string, requester's role affiliation tag, target auto finance data resource locator, and request initiation timestamp, then, based on the requester's identity string, a preset permission policy mapping table is retrieved, and access control rule entries corresponding to the identity string and role affiliation tag, containing resource locator and operation permission binding records and time domain constraints, are extracted. The identity string and role tag are then jointly mapped, enabling permission determination to be precise down to the fine-grained operation permissions of a specific identity subject under a specific role. On this basis, the resource locator and operation permission binding records in the access control rule entries are used to further refine the permissions. The system performs permission matching on the target data resource locator to obtain the operation permission type by binding the permission binding record. At the same time, it uses time-domain constraints to determine the time-domain compliance of the request initiation timestamp to obtain the time-domain compliance status identifier. This organically combines operation permission verification at the resource dimension with compliance verification at the time dimension, ensuring that data access actions are only executed under the premise of time-domain compliance, effectively preventing the risk of data leakage during unauthorized periods. Finally, when the time-domain compliance status identifier indicates that it is valid, the corresponding data access action is performed according to the operation permission type and an access receipt is returned, which significantly improves the security, compliance and refined control level of auto finance data access. Attached Figure Description

[0006] Figure 1 This is a schematic diagram of the execution flow of the auto finance data access method based on access control provided in an embodiment of the present invention.

[0007] Figure 2 This is a schematic diagram illustrating the principle of permission policy mapping and access control rule matching provided in the embodiments of this application.

[0008] Figure 3 This is a schematic diagram of the access request management interface provided in the embodiments of this application.

[0009] Figure 4 This is a schematic diagram of the access request details interface provided in an embodiment of this application.

[0010] Figure 5 This is a schematic diagram of the approval confirmation interface provided in the embodiments of this application.

[0011] Figure 6 This is a schematic diagram of the request details and access receipt interface provided in the embodiments of this application.

[0012] Figure 7 This is a schematic diagram of the system notification center interface provided in an embodiment of this application.

[0013] Figure 8 This is a schematic diagram of the access trend and resource popularity analysis interface provided in the embodiments of this application.

[0014] Figure 9 This is a schematic diagram of the real-time access log and concurrent capacity monitoring interface provided in the embodiments of this application. Detailed Implementation

[0015] Figure 1 This is a flowchart illustrating an embodiment of an auto finance data access method based on access control, applied to data access control scenarios within an auto finance business system. The auto finance business system stores sensitive business data involving customer financial transactions, vehicle mortgage contracts, and repayment records. Access permissions for this data from different roles requiring access requests need to be finely controlled. In this embodiment, the collection and use of data such as the access requester's identity string, role affiliation tag, and financial data resource locator all require explicit authorization and consent from the information subject and are strictly limited to legitimate and necessary purposes related to auto finance business processing and risk control compliance. Data transmission uses a TLS encrypted channel, and the identity string undergoes irreversible desensitization processing using a salted hash algorithm during storage. Plaintext identity information is not stored in log records. The following section combines... Figure 1 The specific implementation methods described above will be explained.

[0016] Step S110: Receive the auto finance data access request sent by the access requesting end. The auto finance data access request carries the requesting end's identity identifier string, the requesting end's role affiliation tag, the resource locator of the target auto finance data, and the request initiation timestamp.

[0017] In this embodiment, the requesting end is a client terminal deployed within the auto finance business network, which sends a POST request to the auto finance data access gateway via the HTTP protocol. The message body of this POST request is serialized in JSON format and contains four fields: the UID field stores the requester's identity string, with a value of a single string; the ROL field stores the requester's role affiliation tag, with a value of a member from a preset role tag enumeration; the URL field stores the resource locator of the target auto finance data; and the TS field stores the request initiation timestamp, with a value of a Unix timestamp. After the inbound listener of the auto finance data access gateway detects this POST request, it calls the request parsing processor to extract the values ​​of the above four fields from the message body and constructs an internal data structure instance for the auto finance data access request. The attributes of this instance include the requester's identity string A1, the requester's role affiliation tag B1, the resource locator of the target auto finance data C1, and the request initiation timestamp D1. Upon receiving the request message body, the inbound listener of the data access gateway first verifies whether the message body format conforms to the preset JSON Schema definition. If the verification passes, it assigns the parsed field values ​​to the internal data structure instance and then passes the instance to the permission verification processor.

[0018] Step S120: Retrieve the preset permission policy mapping table based on the requester's identity string, and extract the access control rule entries corresponding to the requester's identity string and the requester's role affiliation label. The access control rule entries include the binding record of resource locator and operation permission, as well as time-domain constraints.

[0019] Step S121: The identity string of the requesting party is irreversibly transformed according to the preset hash transformation logic to generate an identity hash feature code with a fixed-length byte sequence.

[0020] The default hash transformation logic uses the SHA-256 hash algorithm. The requester's identity string A1 is taken as input and converted into a byte array using UTF-8 character encoding. A default fixed salt byte string is appended to the end of this byte array. The salt value is generated by a secure random number generator and stored in the secure credential vault. The concatenated byte array is then input into the SHA-256 hash algorithm's compression function. After message segmentation, initialization vector assignment, and 64 rounds of compression iterations, a 256-bit hash value is output. This 256-bit hash value is converted into a fixed-length byte sequence of 32 bytes, which is the identity hash signature H1. The introduction of the salt value ensures that even if two requesters have the same identity string, different salt values ​​will result in different hash signatures, thus preventing hash reverse engineering attacks using rainbow tables. The generated H1 replaces the original plaintext identity string for transmission and matching in subsequent steps. The original identity string is erased from memory after the request is processed and is not retained in the log file or cache.

[0021] Step S122: Perform hierarchical path tracing processing on the requesting end role affiliation tag and the preset role hierarchy tree to obtain the role hierarchy path sequence of the requesting end role affiliation tag in the preset role hierarchy tree.

[0022] The default role hierarchy tree is a tree-like data structure, with the root node representing the highest-authority role and leaf nodes representing basic-authority roles. Each node in the tree stores a role tag value and a pointer to its parent node; the parent node pointer of the root node is null. Taking the requesting party's role affiliation tag B1 as input, a breadth-first search algorithm is used to locate the node matching this tag value in the default role hierarchy tree. After locating the matching node, starting from that node, the tree traces upwards layer by layer along the parent node pointers back to the root node, pushing the role tag values ​​of each node along the way onto a stack in the tracing order. After tracing is complete, the elements are popped from the stack in sequence, forming a role hierarchy path sequence P1 from the root node to the matching node. P1 is an ordered list, where the first element is the root node's role tag, and the last element is the requesting party's role affiliation tag B1 itself. If B1 has multiple matching nodes in the default role hierarchy tree, a separate role hierarchy path sequence is generated for each matching node, and the sequence with the shortest path length is taken as P1.

[0023] Step S123: Using the identity hash feature code and role hierarchy path sequence as the joint query key, perform partition index positioning processing in the preset permission policy mapping table to determine the logical storage partition in the preset permission policy mapping table that stores the corresponding access control rule entries, and extract the policy data block to be decoded from the logical storage partition that has a mapping relationship with the joint query key. The policy data block to be decoded contains a resource binding policy set and a time domain restriction policy set that have been nested and encapsulated.

[0024] The preset permission policy mapping table is stored in a relational database using a two-level index structure. The first-level index is a hash modulo partition index, which interprets the 32-byte sequence of the identity hash feature code H1 into a big-endian unsigned integer. This integer is then moduloed by the total number of partitions to obtain the partition number, which is used to locate the corresponding logical storage partition. The second-level index is a composite key-value index. Within the located logical storage partition, the concatenated string of the identity hash feature code H1 and the role hierarchy path sequence P1 is used as the join key. An equality lookup is performed in the B+ tree index within the partition. If the lookup is successful, the storage record associated with the join key is read from the data page. This record contains a policy data block field to be decoded. The policy data block to be decoded is encoded using the Protocol Buffers nested message format. The outer message type is PolicyBundle, containing two byte stream fields: the resBundle field stores the serialized byte stream of the resource binding policy set, and the timeBundle field stores the serialized byte stream of the time-domain restriction policy set. The two byte streams mentioned above are processed by inner message serialization and gzip compression, respectively, forming a nested encapsulation structure.

[0025] Step S124: Call the policy decapsulator that matches the data encapsulation format of the policy data block to be decoded, perform layered decapsulation processing on the policy data block to be decoded, and separate the first byte stream segment corresponding to the resource binding policy set and the second byte stream segment corresponding to the time domain restriction policy set.

[0026] The policy descrambling unit is a dynamic message deserializer based on Protocol Buffers. It reads the byte stream of the policy data block to be decoded, calls the `ParseFromString` method of the Protocol Buffers runtime library to deserialize the byte stream into a `PolicyBundle` memory object. From the `PolicyBundle` object, it reads the byte array of the `resBundle` field, which represents the first byte stream segment; and reads the byte array of the `timeBundle` field, which represents the second byte stream segment. It then performs gzip decompression on both byte stream segments, temporarily storing the decompressed byte arrays in a memory buffer for subsequent steps of policy entry deserialization and time-domain parameter deserialization.

[0027] Step S125: Perform policy entry deserialization on the first byte stream segment to restore the set of binding records of resource locators and operation permissions with resource locators as index items and operation permissions as value items. Perform time domain parameter deserialization on the second byte stream segment to restore the set of time domain constraints with resource locators as index items and effective time period start and end points as value items.

[0028] The byte array after segmenting and decompressing the first byte stream is the serialized result of the ProtocolBuffers resource binding policy set. Its message type is defined as ResBindingSet, containing a repeated field `entries`. Each `entries` element is a ResBinding message, which contains two fields: the `uri` field stores the resource locator string, and the `perm` field stores the operation permission type enumeration value, which can be one of READ_ONLY, READ_WRITE, or EXECUTE. The ProtocolBuffers' ParseFromString method is called to deserialize the first byte stream into a ResBindingSet memory object. The `entries` list is traversed, and the `uri` and `perm` fields of each ResBinding element are extracted to construct a key-value pair structure, where the key is the `uri` field value and the value is the `perm` field value. All key-value pairs are then aggregated into a resource locator and operation permission binding record set M1. The byte array after segmenting and decompressing the second byte stream is the serialized result of the time-domain constraint policy set. Its message type is defined as TimeConstraintSet, containing a repeated field `entries`. Each `entries` element is a TimeConstraint message containing three fields: `uri` (resource locator string), `tStart` (start timestamp of the valid time period), and `tEnd` (end timestamp of the valid time period). It is deserialized into a TimeConstraintSet memory object in the same way. The values ​​of the `uri`, `tStart`, and `tEnd` fields of each TimeConstraint element are extracted, and a key-value pair structure is constructed with `uri` as the key and (tStart, tEnd) tuples as values. All key-value pairs are then aggregated into a time-domain constraint set T1.

[0029] Step S126: Perform equi-join processing on the set of binding records of resource locators and operation permits and the set of time-domain constraints according to the resource locator, so that the operation permit corresponding to each resource locator is associated with its time-domain constraints.

[0030] The equi-join processing employs a hash join algorithm. Using a set of binding records M1 containing resource locators and operation permissions as the construction table, each key-value pair in M1 is traversed, and the string hash value of the resource locator is used as the hash key. The key-value pair is then inserted into the corresponding bucket of the memory hash map. Next, using a set of temporal constraints T1 as the probe table, each key-value pair in T1 is traversed. For each key-value pair, the same string hash value is calculated for the resource locator. The corresponding bucket in the hash map is then searched for a binding record entry with the same resource locator. If found, the operation permission field value in the binding record entry is associated with the (tStart, tEnd) tuple in the temporal constraint entry, forming an associated record. The data structure of the associated record is a triple (uri, perm, (tStart, tEnd)). All associated records are aggregated into an associated record set J1.

[0031] Step S127: After the operation permission and time-domain constraint conditions that have been associated and corresponded after the equi-join processing are processed, the rule entries are encapsulated to generate a single access control rule entry unit. All the generated access control rule entry units are combined into an access control rule entry set. Each access control rule entry in the access control rule entry set contains a resource locator and operation permission binding record as well as time-domain constraints.

[0032] For each associated record in the associated record set J1, create an access control rule entry unit object. The access control rule entry unit object's uri attribute is assigned the value of the associated record's uri field, the permission attribute is assigned the value of the associated record's perm field, and the timeWindow attribute is assigned the (tStart, tEnd) tuple from the associated record. Add the access control rule entry unit object generated for each associated record to the access control rule entry set R1. R1 is a list data structure in memory, where each element is an access control rule entry unit object.

[0033] Step S130: Using the binding record of resource locators and operation permissions in the access control rule entries, perform permission matching processing on the resource locators of the target auto finance data to obtain the operation permission type, and use time-domain constraints to perform time-domain compliance judgment processing on the request initiation timestamp to obtain the time-domain compliance status identifier.

[0034] Step S131: The resource locator of the target auto finance data is segmented according to a preset character delimiter to obtain a resource locator segment sequence. The resource locator segment sequence includes resource domain segment, resource category segment, and resource instance identifier segment.

[0035] The resource locator C1 for the target auto finance data is a path string using forward slashes as delimiters. The default delimiter is the forward slash. A string splitting operation is performed on C1, splitting the string into multiple substrings using forward slashes as delimiters. These substrings are then stored sequentially in the resource locator segment sequence S1. S1 is an ordered list. The first element corresponds to the resource domain segment, indicating the business domain to which the data belongs; the second element corresponds to the resource category segment, indicating the category of the data within the business domain; and the third and subsequent elements correspond to the resource instance identifier segment, representing the specific data instance.

[0036] Step S132: Extract the resource domain segment and resource category segment from the resource locator segment sequence, combine them to generate a resource locator prefix pattern string, and use the resource locator prefix pattern string as the matching benchmark to perform prefix matching traversal processing in the binding records of resource locators and operation permissions, and filter out all candidate binding records whose resource locator prefixes are consistent with the resource locator prefix pattern string.

[0037] Extract the first element from S1 as the resource domain segment E1, and the second element as the resource category segment F1. Concatenate E1 with the forward slash character and F1 to obtain the resource location prefix pattern string G1. Iterate through each binding record in the resource locator and operation permission binding record set M1, and call the string prefix matching function on the URI field value of each binding record to determine whether the URI field value is prefixed with G1. If the prefix match is successful, add the binding record to the candidate binding record list L1.

[0038] Step S133: Perform exact matching processing on the resource locators in the selected candidate binding records, compare the resource locators of the target auto finance data with the resource locators in each candidate binding record segment by segment, and determine the unique binding record that is completely consistent with the resource locators of the target auto finance data.

[0039] Iterate through each candidate binding record in the candidate binding record list L1, and perform a string equality comparison between the resource locator C1 of the target auto finance data and the URI field value of the candidate binding record. If every character of C1 is identical to the URI field value, then the candidate binding record is determined to be the unique binding record B2 that is completely identical to C1. If there is no candidate binding record in L1 that is completely identical to C1, then the permission matching process fails, the access process is terminated, and a permission denial response is returned.

[0040] Step S134: Extract the corresponding operation permission field value from the unique binding record, and use the operation permission field value as the operation permission type for the target auto finance data.

[0041] Read the value of the perm field from the uniquely bound record B2. This value is the operation permission type enumeration value, denoted as P1. The value of P1 determines the types of data operations that can be performed on the target auto finance data. READ_ONLY indicates that only read operations are allowed, READ_WRITE indicates that both read and write operations are allowed, and EXECUTE indicates that specific data processing programs are allowed.

[0042] Step S135: Using the resource locator of the target auto finance data as the index key, query the start and end point information of the valid time period associated with the resource locator in the time domain constraints. The start and end point information of the valid time period includes the start time value and the end time value of the time period.

[0043] Using the resource locator C1 of the target auto finance data as the query key, a hash lookup is performed in the time-domain constraint set T1. If an entry with the key equal to C1 exists in T1, the corresponding (tStart, tEnd) tuple is retrieved, with tStart recorded as the start time value TS1 and tEnd as the end time value TE1. If no entry with the key equal to C1 exists in T1, TS1 is defaulted to 0, and TE1 is set to the maximum timestamp value, indicating no time-domain constraint.

[0044] Step S136: Perform a time-series comparison between the request initiation timestamp and the time value of the start point of the time period. If the request initiation timestamp is not earlier than the time value of the start point of the time period, generate a start point satisfaction status flag. Perform a time-series comparison between the request initiation timestamp and the time value of the end point of the time period. If the request initiation timestamp is not later than the time value of the end point of the time period, generate an end point satisfaction status flag.

[0045] Extract the request initiation timestamp D1 from the auto finance data access request. Compare D1 with TS1. If D1 is greater than or equal to TS1, the starting point is generated and the status is marked as true; otherwise, it is marked as false. Compare D1 with TE1. If D1 is less than or equal to TE1, the ending point is generated and the status is marked as true; otherwise, it is marked as false.

[0046] Step S137: Perform a logical conjunction operation on the start point satisfying state flag and the end point satisfying state flag. If both the start point satisfying state flag and the end point satisfying state flag indicate that the timing condition is met, then generate a time domain compliance status identifier that represents that the request initiation timestamp is in the valid range.

[0047] Perform a logical AND operation on the start point and end point satisfying status flags. If both are true, the time-domain compliance status flag is VALID. If either is false, the time-domain compliance status flag is INVALID.

[0048] Step S140: When the time domain compliance status indicator indicates that the request initiation timestamp is within the valid range defined by the time domain constraints, perform the corresponding data access action on the target auto finance data according to the operation license type, obtain the auto finance data access receipt, and return the auto finance data access receipt to the access request end.

[0049] Step S141: Obtain the status bit value of the time domain compliance status identifier. If the status bit value is a valid status value, the execution process of subsequent data access actions will be triggered.

[0050] Read the status bit value of the time-domain compliance status identifier. If the value is VALID, proceed to step S142. If the value is INVALID, generate a data access receipt containing a rejection reason code and directly jump to step S145 to perform the receipt return operation.

[0051] Step S142: Based on the license type code of the operation license type, find the data access execution function pointer corresponding to the license type code in the preset operation execution mapping table, and call the corresponding data access execution unit through the data access execution function pointer.

[0052] The default operation execution map is a hash map stored in memory, where the key is an enumeration value of the operation license type and the value is the function entry address of the data access execution unit. Using operation license type P1 as the key, the corresponding function entry address is searched in the default operation execution map and assigned to the function pointer variable Fp. A function call is then initiated through Fp to execute the corresponding data access execution unit.

[0053] Step S143: The resource locator of the target auto finance data is passed to the data access execution unit. The data access execution unit locates the data storage node in segments according to the resource ownership domain in the resource locator, and locks the target data storage block in the data storage node in segments according to the resource instance identifier in the resource locator.

[0054] The data access execution unit receives the resource locator C1 of the target auto finance data as an input parameter. The unit parses the resource ownership domain segment E1 from C1 and searches for the corresponding data storage node network address in the data storage node registry based on E1. It then connects to the data storage node via a remote procedure call and sends a data location request carrying the resource instance identifier segment. The data storage node searches its local storage engine based on the resource instance identifier segment, locks the target data storage block Block1, and returns the file handle of that storage block.

[0055] Step S144: The data access execution unit performs corresponding data operations on the target data storage block according to the operation permission type. If the operation permission type is read-only, a data block read operation is performed and the read byte content is cached in the memory buffer. If the operation permission type is read-write, a data block read-write operation is performed. After the data operation is completed, the data access execution unit collects the execution status code of the operation execution process and the metadata of the operation execution result. The metadata includes the number of data record entries affected by the operation.

[0056] The data access execution unit determines the value of the operation permission type P1. If P1 is READ_ONLY, it calls the file read interface of the storage block to read the byte content of the target data storage block Block1 into the memory buffer, and closes the file handle after reading. If P1 is READ_WRITE, it first calls the file read interface to read the content of Block1 into the memory buffer, allowing the caller to modify the data in the memory buffer. After modification, it calls the file write interface to write the content of the memory buffer back to Block1, and closes the file handle after writing. After the operation is completed, the data access execution unit collects the execution status code of the operation execution process. The execution status code is an integer value, where 0 indicates success and a non-zero value indicates failure and carries a specific error code. At the same time, it collects the metadata of the operation execution result. The number of data record entries affected by the operation in the metadata is determined according to the operation type: for READ_ONLY operations, this number is the total number of bytes read divided by the average byte length of a single data record and rounded up; for READ_WRITE operations, this number is the count of the data record entries actually modified.

[0057] Step S145: Perform structured encapsulation of the execution status code and metadata to generate the access execution result data body. Obtain the request initiation timestamp carried in the auto finance data access request. Add the request initiation timestamp and the access completion timestamp together as access operation time sequence records to the access execution result data body.

[0058] Construct a JSON object as the access execution result data body. This JSON object contains a `code` field to store the execution status code, a `meta` field to store metadata sub-objects, and a `recordCount` field to store the number of data record entries affected by the operation. Read the current operating system clock as the access completion time timestamp D2. Combine the request initiation timestamp D1 and the access completion timestamp D2 into a JSON sub-object containing the `reqTime` and `respTime` fields, and add this sub-object to the `timeline` field of the access execution result data body.

[0059] Step S146: Serialize the access execution result data body into an auto finance data access receipt with a preset communication protocol format, and transmit the auto finance data access receipt in the form of a message packet back to the access request end. The message header of the auto finance data access receipt contains a response code that the access request end can recognize.

[0060] The JSON object generated in step S145 is serialized using the JSON serialization library's serialization method to become a JSON string. This JSON string is then encapsulated into the message body of an HTTP response message. The HTTP response message header sets the Content-Type to application / json and the response code to 200 to indicate that the request has been processed. This HTTP response message is then transmitted back to the requesting end via the outbound sender of the auto finance data access gateway.

[0061] Step S210: Construct a tree-like index structure for automotive finance data resource locators. The tree-like index structure takes the business domain to which the data belongs as the root node, the data sub-category as the intermediate node, and the data resource locator as the leaf node.

[0062] Retrieve resource locators for all registered target auto finance data in the auto finance data system. For each resource locator, segment it using a slash character as the delimiter to obtain a resource locator segment sequence. Extract the first segment from the resource locator segment sequence as the data's business domain identifier, extract the second segment as the data subcategory identifier, and merge the remaining segments into a complete path string for the data resource locator. Using the data's business domain identifier as the root node name, find or create the corresponding root node in the tree index structure. Under the root node, using the data subcategory identifier as the intermediate node name, find or create the corresponding intermediate node. Under the intermediate node, using the complete path string as the leaf node name, create a leaf node and establish a mapping reference relationship between the leaf node and the resource locator. After all resource locators have been processed, a complete tree index structure is generated and stored in memory. Each node contains a node name, node type, and a list of child node pointers.

[0063] Step S220: Assign a node operation permission inheritance attribute to each non-leaf node in the tree index structure. The node operation permission inheritance attribute is used to specify whether the child nodes under the non-leaf node automatically inherit the operation permission configuration set by the non-leaf node.

[0064] Traverse all root and intermediate nodes in the tree-indexed structure, creating a node operation permission inheritance attribute object for each non-leaf node. This attribute object contains two fields: `inheritFlag`, a boolean type, where a value of `true` indicates that child nodes automatically inherit the operation permission configuration of this non-leaf node, and a value of `false` indicates that they do not inherit; and `inheritPerm`, an enumeration value of the operation permission type, storing the operation permission configuration set for this non-leaf node, with a value of one of `READ_ONLY`, `READ_WRITE`, or `EXECUTE`. The `inheritFlag` of the root node is set to `true` by default, and `inheritPerm` is set to `READ_ONLY` by default. The `inheritFlag` and `inheritPerm` of intermediate nodes are inherited from their parent nodes; if the parent node's `inheritFlag` is `false`, then the intermediate node's `inheritFlag` is also set to `false`. The created node operation permission inheritance attribute object is then attached to the `extendAttr` field of the corresponding non-leaf node.

[0065] Step S230: Bind an operation permission whitelist and a time-domain constraint blacklist to each leaf node of the tree index structure. The operation permission whitelist records the types of operations that are allowed to be performed on the data resources corresponding to the leaf node, and the time-domain constraint blacklist records the time intervals during which access to the data resources corresponding to the leaf node is prohibited.

[0066] Traverse all leaf nodes in the tree-structured index. For each leaf node, retrieve the access control rule entry for the resource locator corresponding to that leaf node from the preset permission policy mapping table, extract the operation permission type from it as the initial value of the default operation permission whitelist for that leaf node. The operation permission whitelist is a list of operation permission type enumeration values. Simultaneously, create a time-domain constraint blacklist for that leaf node. The time-domain constraint blacklist is a list of time intervals, where each element is a (tStart, tEnd) tuple. The initial value of the time-domain constraint blacklist is derived backward from the time-domain constraints of the resource locator in the preset permission policy mapping table, using time intervals not covered by the time-domain constraints as blacklist intervals. If the time-domain constraint is (t1, t2), and t1 is greater than 0, then add the interval (0, t1) to the blacklist and the interval (t2, MAX) to the blacklist, where MAX is the maximum timestamp value. Bind the operation permission whitelist and the time-domain constraint blacklist to the whitelist and blacklist fields of the leaf node.

[0067] Step S240: After receiving the auto finance data access request, perform tree path backtracking processing on the resource locator of the target auto finance data, and extract the node operation permission inheritance attributes of all non-leaf nodes on the complete path from the leaf node to the root node in sequence.

[0068] Upon receiving the auto finance data access request in step S110, the resource locator C1 of the target auto finance data is obtained. The leaf node corresponding to C1 is located in the tree index structure using a segmented matching method. Starting from this leaf node, the process traces back up layer by layer along the parent node pointer to the root node, adding the node operation permission inheritance attribute objects of each non-leaf node encountered in a bottom-up order to list LA1. The first element in LA1 is the inherited attribute of the direct parent intermediate node of the leaf node, and the last element is the inherited attribute of the root node.

[0069] Step S250: Starting from the root node of the complete path, merge the node operation permission inheritance attributes of each non-leaf node with the operation permission whitelist of the leaf nodes layer by layer to generate a fused operation permission set. Remove operation permissions covered by time intervals in the time domain constraint blacklist from the fused operation permission set to generate a final effective operation permission set. Replace the operation permission type in the access control rule entry with the final effective operation permission set for implementing corresponding data access actions on the target auto finance data.

[0070] Reverse list LA1 to obtain the inherited attribute sequence from the root node to the leaf node. Create an empty merged operation permission set S2, initially adding all operation permission types from the leaf node's operation permission whitelist to S2. Iterate through each node's operation permission inherited attribute object in the inherited attribute sequence. If the currently iterated inherited attribute object's inheritFlag is true, add its inheritPerm value to S2. After iteration, for each operation permission type in S2, check if the operation permission type is covered by any time interval in the leaf node's time-domain constraint blacklist. The coverage determination method is: extract the current system timestamp Dnow. If Dnow falls within the range of any time interval in the time-domain constraint blacklist, it is determined that the time interval covers the operation permission at the current moment, and the corresponding operation permission type is removed from S2. After the removal operation is completed, the remaining operation permission types in S2 are the final effective operation permission set. Take the operation license type with the widest permission range from the final effective operation license set and replace the original operation license type P1 obtained in step S134. Then, perform the data access action in step S140 according to the replaced operation license type.

[0071] Step S310: Obtain the historical request initiation timestamp sequence and historical target data resource locator sequence carried by the multiple historical auto finance data access requests sent by the access requesting end.

[0072] From the access log storage of the auto finance data access gateway, using the identity hash feature H1 of the access requester as the query condition, extract all historical auto finance data access request records of the requester within a preset time range. Extract the request initiation timestamp field value and the target data resource locator field value from each record. Sort all request initiation timestamps chronologically to generate a historical request initiation timestamp sequence TSseq. Sort all target data resource locators chronologically according to their corresponding timestamps to generate a historical target data resource locator sequence URLseq. TSseq and URLseq are one-to-one equal-length sequences, with a sequence length denoted as N.

[0073] Step S320: Based on the historical request initiation timestamp sequence and the historical target data resource locator sequence, construct the access behavior time sequence of the access request end. Each time point in the access behavior time sequence contains the access time value and the access data resource locator.

[0074] Create an access behavior time series object BST, which is an ordered list where each element is a time series object. Iterate through indices i from 1 to N, extract the i-th timestamp value from TSseq as the access time value ti, and extract the i-th resource locator from URLseq as the access data resource locator ui. Construct a time series object (ti, ui) and append this time series object to the end of BST. BST represents the complete access behavior time series of the requesting client within a preset time range.

[0075] Step S330: Perform time-series pattern mining processing on the access behavior time series to extract the access frequency fluctuation pattern and access resource switching pattern of the access request end within the preset time window.

[0076] The time series pattern mining process employs a sliding window method. The sliding window length is set to W time series points, with a sliding step size of 1. For the access behavior time series BST, starting from the first time series point, the sliding window is sequentially processed, and the subsequences within each window are statistically analyzed. The access frequency fluctuation pattern is extracted as follows: for each time series point within a window, the difference between the timestamps of adjacent time series points is calculated to generate a time interval sequence. The mean μgap and standard deviation σgap of this time interval sequence are calculated, and (μgap, σgap) is used as the access frequency feature tuple for that window. All access frequency feature tuples from all windows are arranged in window order to generate the access frequency fluctuation pattern Fpat. The resource access switching pattern is extracted as follows: for each time series point within a window, the frequency distribution of different resource locators within the window is statistically analyzed. The Helling distance of the resource locator frequency distribution between adjacent windows is calculated. All Helling distances between adjacent windows are arranged in order to generate the resource access switching pattern Rpat.

[0077] Step S340: Generate a behavior pattern label vector for the access request end based on the access frequency fluctuation pattern and access resource switching pattern. The behavior pattern label vector includes a frequency feature dimension and a resource preference dimension.

[0078] For all (μgap, σgap) pairs in the access frequency fluctuation pattern Fpat, calculate the mean μgap and mean σgap across the entire window, and use these two means as the two components of the frequency feature dimension. For all Helling distance values ​​in the access resource switching pattern Rpat, calculate their mean and maximum values, and use these mean and maximum values ​​as the two components of the resource preference dimension. Concatenate the two components of the frequency feature dimension and the two components of the resource preference dimension along the dimensional direction to generate a four-dimensional real vector, which is the behavior pattern label vector Vbehav.

[0079] Step S350: Associate and bind the behavior pattern tag vector with the access control rule entries corresponding to the access request end stored in the preset permission policy mapping table to generate behavior-aware access control rule entries.

[0080] In the preset permission policy mapping table, locate the set R1 of access control rule entries with the identity hash feature code H1 as the query key. For each access control rule entry in R1, add a behaviorProfile field to its extended attribute field, and store the four component values ​​of the behavior pattern label vector Vbehav in comma-separated string format in this field. The access control rule entry after completing the extended attribute assignment is the behavior-aware access control rule entry.

[0081] Step S360: When a request for access to auto finance data is received again from the access requester, the deviation between the current access behavior and the behavior-aware access control rule entry is calculated. If the result of the deviation calculation exceeds the preset deviation tolerance threshold, the operation permission type in the current access control rule entry is temporarily contracted to obtain a temporary operation permission type. Based on the temporary operation permission type, the corresponding data access action is performed on the target auto finance data.

[0082] When the same request for access to automotive finance data is received again, the access behavior time series of the W most recent time points before the current request time is extracted, and the current behavior pattern label vector Vcurrent is calculated according to the methods in steps S330 and S340. The historical behavior pattern label vector Vhist stored in the behaviorProfile field is read from the behavior-aware access control rule entries. The deviation Ddev = ||Vcurrent - Vhist|| is calculated, which is the Euclidean distance between the two four-dimensional vectors. If Ddev is greater than the preset deviation tolerance threshold Dth, a temporary contraction process is performed on the operation permission type P1. The temporary contraction process is as follows: if P1 is READ_WRITE, the temporary operation permission type Pt is set to READ_ONLY; if P1 is READ_ONLY, the temporary operation permission type Pt is set to READ_ONLY; if P1 is EXECUTE, access is denied. P1 is replaced with the temporary operation permission type Pt, and the data access action is performed according to step S140.

[0083] Step S410: Construct a knowledge base for resolving permission policy conflicts. The knowledge base contains the correspondence between conflict type tags and resolution rule sets. Conflict type tags include permission inheritance conflicts and time interval overlap conflicts.

[0084] Create a knowledge base for resolving permission policy conflicts, stored in a relational database table. The table structure contains three columns: `tag` stores the conflict type tag string, with values ​​of `INHERIT_CONFLICT` or `TIME_OVERLAP_CONFLICT`; `ruleID` stores the resolution rule identifier string; and `ruleBody` stores the description text of the resolution rule. Pre-define two records in this knowledge base. Record 1: tag is `INHERIT_CONFLICT`, ruleBody description: prioritize the operation permission type corresponding to the source policy identifier with the higher role hierarchy depth. Record 2: tag is `TIME_OVERLAP_CONFLICT`, ruleBody description: prioritize the operation permission type corresponding to the later end time of the time period in the time-domain constraints.

[0085] Step S420: After each access control rule entry is generated, a conflict scan is performed on all access control rule entries in the access control rule entry set to detect whether there is an inconsistency between operation license types pointing to the same resource locator. If an inconsistency is detected between operation license types pointing to the same resource locator, the inconsistent operation license types and their respective source policy identifiers are encapsulated into a license inheritance conflict instance.

[0086] After generating the access control rule entry set R1 in step S127, conflict scanning is performed on R1. All access control rule entry units in R1 are traversed, and grouped and aggregated using a hash mapping with the resource locator (URI) field as the grouping key. For each group, if the group contains at least two access control rule entry units, the operation permission type field values ​​of the two entries are compared. If the operation permission type field values ​​of the two entries are different, a permission inheritance conflict instance is created. This instance contains three fields: the URI field stores the resource locator involved in the conflict, the perm1 field stores the operation permission type of the first entry and its source policy identifier, and the perm2 field stores the operation permission type of the second entry and its source policy identifier. The source policy identifier is the row identifier of the access control rule entry unit in the preset permission policy mapping table. This permission inheritance conflict instance is added to the conflict instance list Lconflict.

[0087] Step S430: Determine the conflict type label of the permission inheritance conflict instance as a permission inheritance conflict, and search for the resolution rule set corresponding to the conflict type label in the permission policy conflict resolution knowledge base. Extract the permission inheritance conflict resolution rule from the resolution rule set. The permission inheritance conflict resolution rule specifies that the operation permission type corresponding to the source policy identifier with a larger role level depth shall prevail, and the operation permission type corresponding to the source policy identifier with a smaller role level depth shall prevail.

[0088] For each permission inheritance conflict instance in the conflict instance list Lconflict, set its conflict type tag to INHERIT_CONFLICT. Using INHERIT_CONFLICT as the query condition, search the permission policy conflict resolution knowledge base for records matching the tag column, and extract the ruleBody field of that record as the permission inheritance conflict resolution rule. This rule specifies: trace the role hierarchy depth corresponding to the source policy identifiers of perm1 and perm2 in conflict, respectively. The role hierarchy depth is defined as the node depth value of the role associated with that source policy identifier in the preset role hierarchy tree, with the root node depth being 0. Compare the two role hierarchy depths, and take the operation permission type corresponding to the source policy identifier with the larger role hierarchy depth as the final selected operation permission type.

[0089] Step S440: Based on the license inheritance conflict resolution rules, select the final operation license type from the inconsistent operation license types, and replace the corresponding operation license type in the access control rule entry set with the final operation license type.

[0090] For each permission inheritance conflict instance in the conflict instance list Lconflict, read the source policy identifiers of its perm1 and perm2. Using the source policy identifiers, backtrack through the preset role hierarchy tree to obtain the depth values ​​depth1 and depth2 of the role hierarchy. If depth1 is greater than depth2, the final selected operation permission type is the operation permission type in perm1; otherwise, the operation permission type in perm2 is used. In the access control rule entry set R1, locate the two access control rule entry units corresponding to the URI involved in the conflict instance, and update the operation permission type field values ​​of both entries to the final selected operation permission type. After the update, the operation permission inconsistency conflict corresponding to the URI is eliminated.

[0091] Step S510: Obtain the requester's identity string carried in the auto finance data access request, input the requester's identity string into the preset identity association graph for related entity retrieval processing, and extract the set of related identity strings that are connected to the requester's identity string by related edges.

[0092] The pre-defined identity association graph is stored in the form of a graph database. Nodes in the graph are hash signatures of identity identifier strings, and undirected edges represent business relationships between two identities. The requesting identity identifier string A1 is converted into an identity hash signature H1 using the method in step S121. Using H1 as the query condition, a neighbor node query is performed in the graph database. A one-hop traversal is performed along all associated edges connected to node H1, extracting the identity hash signatures of all traversed neighbor nodes to form a set of associated identity identifier strings Q1. Each element in Q1 is an identity hash signature.

[0093] Step S520: Extract the associated role affiliation tag and associated access control rule entry corresponding to each associated identity string in the associated identity string set. Perform intersection processing on the resource locator and operation permission binding record in the associated access control rule entry and the resource locator and operation permission binding record in the access control rule entry of the access requester itself to generate a shared resource locator set.

[0094] For each identity hash feature in the associated identity string set Q1, following steps S120 to S127, extract the set of access control rule entries corresponding to that identity hash feature from the preset permission policy mapping table, and denote it as the associated access control rule entry set R2. Extract the URI field of each access control rule entry unit in R2 to form the associated resource locator set U2. Simultaneously, extract the URI field of each access control rule entry unit in the access requester's own access control rule entry set R1 to form its own resource locator set U1. Calculate the intersection of U1 and U2 to obtain the shared resource locator set Ushared.

[0095] Step S530: For each shared resource locator in the shared resource locator set, perform operation permission merging processing, perform a permission range union operation on the operation permission type of the access requester and the operation permission type of the associated identity string to generate a shared operation permission type, and use the shared operation permission type as the extended operation permission type of the access requester for the shared resource locator.

[0096] For each shared resource locator (URI) in the shared resource locator set Ushared, find the corresponding operation license type Pself in R1 and the corresponding operation license type Passoc in R2. The license scope of an operation license type is defined as the set of all operational capabilities that can be derived from that operation license type. The license scope of READ_ONLY is {read}, the license scope of READ_WRITE is {read, write}, and the license scope of EXECUTE is {read, execute}. The shared license scope is obtained by taking the union of the license scopes of Pself and Passoc. Within the shared license scope, the smallest operation license type that covers this scope is selected as the shared operation license type Pshared. Pshared is used as the extended operation license type for the URI by the access requesting end and stored in the extended operation license mapping table, with the key being URI and the value being Pshared.

[0097] Step S540: Perform the corresponding data access action on the target auto finance data corresponding to the shared resource locator according to the extended operation license type.

[0098] When the resource locator C1 of the target auto finance data in step S130 belongs to a key in the extended operation license mapping table, the operation license type P1 is replaced with the extended operation license type Pshared corresponding to C1 in the extended operation license mapping table, and the data access action is performed according to step S140. If C1 does not belong to a key in the extended operation license mapping table, the original operation license type P1 remains unchanged.

[0099] Step S610: Obtain the request initiation timestamps carried by all auto finance data access requests issued by the access requesting end within the preset sliding time window, generate a request initiation timestamp sequence, calculate the time interval value sequence of adjacent request initiation timestamps in the request initiation timestamp sequence, and generate access rhythm feature parameters based on the mean and fluctuation amplitude of the time interval value sequence.

[0100] Retrieve all auto finance data access requests issued by the requesting client within a preset sliding time window Tw from the access log storage. Extract the request initiation timestamp for each request and sort them chronologically to obtain the request initiation timestamp sequence TS1. Calculate the difference between two adjacent timestamp values ​​in TS1 to obtain the time interval value sequence ΔTS1. Calculate the mean μΔ and standard deviation σΔ of ΔTS1. The access rhythm feature parameter Rhy=(μΔ, σΔ) is a two-dimensional real number vector.

[0101] Step S620: Obtain the resource locator sequence of the target auto finance data accessed by the access requester within a preset sliding time window, extract the resource category segment of each resource locator, and generate a resource category transfer sequence.

[0102] Retrieve resource locators for all target auto finance data accessed by the requesting client within a preset sliding time window Tw from the access log storage. Arrange them in chronological order of access time to obtain the resource locator sequence URL1. For each resource locator in URL1, extract the second segment after splitting by a forward slash character as a resource category segment, generating a resource category transition sequence CatSeq. CatSeq is an ordered list of category label strings, with a list length equal to the length of URL1.

[0103] Step S630: Count the frequency of each resource category in two consecutive visits in the resource category transfer sequence, construct a resource category transfer frequency statistics table, perform row normalization on the resource category transfer frequency statistics table, and generate a resource category transfer probability matrix.

[0104] Extract all unique resource category labels appearing in the resource category transition sequence CatSeq, assuming the total number of unique categories is K. Create a K-row, K-column zero matrix as the resource category transition frequency statistics table Freq. Iterate through adjacent category labels (c1, c2) in CatSeq, letting the row index of c1 in the category label list be i and the column index of c2 be j. Increment the value of the element in the i-th row and j-th column of Freq by 1. After the iteration is complete, perform row normalization on each row of Freq: for the i-th row, calculate the sum of all elements in that row, rowSum, and divide each element value in that row by rowSum until the sum of all elements in that row is 1. The normalized matrix is ​​the resource category transition probability matrix Prob. The element Prob(i, j) in the i-th row and j-th column of Prob represents the probability of transitioning from the previously visited resource category i to the next visited resource category j.

[0105] Step S640: Normalize the access rhythm feature parameters to generate a standardized rhythm deviation index. Simultaneously, calculate the resource category transition probability matrix to generate a behavior pattern deviation index. Input the rhythm deviation index and the behavior pattern deviation index into a preset access behavior anomaly evaluator for multi-dimensional fusion analysis. The preset access behavior anomaly evaluator performs anomaly scoring on the current access behavior and generates anomaly score values. When the anomaly score value exceeds a preset anomaly warning threshold, downgrade the operation permission type in the access control rule entry corresponding to the access request end from read-write type to read-only type.

[0106] The mean of the average time interval (μbase) and the standard deviation of the average time interval (σbase) during past normal access periods are obtained from the historical normal behavior baseline database. The rhythm deviation index Rdev = |μΔ - μbase| / μbase + |σΔ - σbase| / σbase. The resource category transition probability matrix Probbase for the access requester during past normal access periods is obtained from the historical normal behavior baseline database. The behavior pattern deviation index Pdev = ∑(i=1 to K)∑(j=1 to K)|Prob(i,j) - Probbase(i,j)|, which is the sum of the absolute differences of all corresponding elements in the two matrices. The default access behavior anomaly evaluator is a linearly weighted scoring function, with an anomaly score Score = α × Rdev + β × Pdev, where α and β are default weight coefficients, and α + β = 1. When the Score is greater than the default anomaly warning threshold Sth, the operation permission type of all entries in the access control rule entry set R1 corresponding to the access requester that are of the READ_WRITE type is downgraded to READ_ONLY.

[0107] Step S650: Perform the corresponding data access action on the target auto finance data according to the downgraded operation license type.

[0108] Replace the original operation license type P1 obtained in step S134 with the downgraded operation license type, and perform the data access action in step S140.

[0109] For example, step S710: Construct a data resource access popularity tracking linked list. Each node of the data resource access popularity tracking linked list contains a resource locator field, an access count accumulation field, and a last access time field.

[0110] The data resource access popularity tracking list is a doubly linked list data structure stored in memory. Each list node definition contains three fields: `uri` (a string) stores the resource locator; `count` (an unsigned integer) stores the accumulated access count; and `lastTime` (a timestamp) stores the last access time. The list is initially empty.

[0111] Step S720: After each data access action to the target auto finance data is completed, extract the resource locator of the target auto finance data as the resource locator to be updated.

[0112] After the data access action in step S140 is completed, the resource locator C1 of the target auto finance data for this access is obtained and used as the resource locator Uupdate to be updated.

[0113] Step S730: Search for a linked list node in the data resource access popularity tracking linked list that matches the resource locator to be updated. If found, increment the value of the access count accumulation field of the linked list node and update the last access time field to the timestamp of the current access completion time.

[0114] Starting from the head node of the data resource access popularity tracking list, traverse the list along the next pointer, comparing the uri field value of each node with Uupdate to see if they match exactly. If they match, increment the count field value of that node by 1 and update the lastTime field to the access completion timestamp D2 of the current moment.

[0115] Step S740: If no linked list node matching the resource locator to be updated is found, a new linked list node is added to the tail of the data resource access heat tracking linked list. The resource locator field of the new linked list node is set to the resource locator to be updated, and the value of the access count accumulation field is initialized to the initial count value and the last access time field is set to the timestamp of the current access completion time.

[0116] If no node matching the uri field value of Uupdate is found after traversing the entire linked list, a new linked list node object is created. The new node's uri field is set to Uupdate, the count field is set to 1, and the lastTime field is set to D2. The new node is inserted at the tail of the linked list, and the tail pointer is updated.

[0117] Step S750: Perform a sorting operation on all linked list nodes in the data resource access popularity tracking linked list, sort them in descending order using the access count accumulation field as the sorting key value, generate a popularity sorted linked list, extract a preset number of linked list nodes from the head of the popularity sorted linked list, and form a hot resource locator set from the resource locator fields in the extracted linked list nodes.

[0118] Copy all nodes from the data resource access popularity tracking linked list to a temporary array. Apply a merge sort algorithm to this temporary array, using a sorting comparison function to compare nodes in descending order based on their count field values. After sorting, the temporary array becomes the popularity-sorted linked list. Starting from the head of the popularity-sorted linked list, extract the first M nodes, where M is a preset number to extract. Extract the uri field values ​​from these M nodes to form a hot resource locator set Uhot.

[0119] Step S760: Tighten the operation permission type in the access control rule entry corresponding to each hot resource locator in the hot resource locator set, and tighten the operation permission type from read-write type to read-only type.

[0120] In the preset permission policy mapping table, each hot resource locator URI in the hot resource locator set Uhot is used as the lookup key to locate the corresponding access control rule entry. If the operation permission type of this entry is READ_WRITE, it is changed to READ_ONLY. If it is READ_ONLY or EXECUTE, it remains unchanged.

[0121] Step S770: Upon receiving an auto finance data access request for any hot resource locator in the hot resource locator set, perform the corresponding data access action on the target auto finance data according to the operation license type after license tightening.

[0122] When a new auto finance data access request is subsequently received, and the resource locator C1 of the target auto finance data belongs to Uhot, the operation permission type corresponding to the resource locator is extracted from the preset permission policy mapping table. At this time, the operation permission type has been tightened to READ_ONLY as per step S760. The data access action in step S140 is then executed with the tightened operation permission type.

[0123] Step S810: Attach a rule expiration transfer label to each access control rule entry in the preset permission policy mapping table. The rule expiration transfer label includes a transfer trigger condition field and a transfer target rule identifier field.

[0124] Iterate through each access control rule entry in the preset permission policy mapping table and add an extended attribute field, `transferTag`, to that entry. The `transferTag` field is a JSON object containing two subfields: `triggerCondition` stores a description of the transfer trigger condition, and `targetRuleID` stores a string identifying the target rule. For newly created access control rule entries, the initial value of the `transferTag` field is empty, indicating that rule invalidation transfer is not enabled. For entries that require rule invalidation transfer, the permission administrator sets the values ​​of `triggerCondition` and `targetRuleID` through the configuration interface.

[0125] Step S820: Monitor the time difference between the time domain constraint end point time value and the current system base time value of each access control rule entry in the preset permission policy mapping table. When the time difference is lower than the preset near-failure threshold, trigger the rule failure transfer process for that access control rule entry.

[0126] A timed polling task is initiated, scanning the preset permission policy mapping table once at preset time intervals. For each access control rule entry, the time value TE1 of the time domain constraint is read. The current system base time value Dnow is obtained. The time difference ΔT = TE1 - Dnow is calculated. If ΔT is less than the preset near-failure threshold Tth, and ΔT is greater than 0, the rule failure transfer process for that entry is triggered.

[0127] Step S830: Extract the transfer trigger condition field of the access control rule entry to be invalidated. The transfer trigger condition field contains the default inheritance mode identifier and the condition evaluation expression. If the default inheritance mode identifier is in an active state, the rule transfer operation is executed directly. If the default inheritance mode identifier is in an inactive state, the condition evaluation expression is evaluated for truth value.

[0128] The `triggerCondition` subfield is parsed from the `transferTag` field of the entry to be invalidated. The `triggerCondition` subfield contains a `defaultInherit` boolean value and a `conditionExpr` string. If `defaultInherit` is true, condition evaluation is skipped, and step S840 is executed directly. If `defaultInherit` is false, `conditionExpr` is evaluated. `conditionExpr` is a logical expression string, parsed and executed by the condition engine. The expression can reference other attribute values ​​of the current access control rule entry as variables. The evaluation result is a boolean type. If the result is true, step S840 is executed; if the result is false, the current rule invalidation transfer process is terminated.

[0129] Step S840: When the result of the condition evaluation expression is true, extract the transfer target rule identifier field of the access control rule entry to be invalidated. The transfer target rule identifier field stores a unique rule identifier pointing to another access control rule entry in the preset permission policy mapping table.

[0130] Parse the targetRuleID subfield from the transferTag field of the entry to be invalidated. The string stored in this subfield is the identifier of the transfer target rule, denoted as RuleIDtarget.

[0131] Step S850: Based on the unique rule identifier in the target rule identifier field, retrieve the target access control rule entry that matches the unique rule identifier in the preset permission policy mapping table, and extract the resource locator and operation permission binding record and time domain constraint conditions of the target access control rule entry.

[0132] Using RuleIDtarget as the query key, perform a primary key lookup in the preset permission policy mapping table to obtain the target access control rule entry that matches RuleIDtarget. Extract the resource locator and operation permission binding record from this target entry, denoted as (uriTarget, permTarget), and the time-domain constraint (tStartTarget, tEndTarget).

[0133] Step S860: Merge the resource locator and operation permission binding record of the access control rule entry to be expired and the resource locator and operation permission binding record of the target access control rule entry to generate a transitional operation permission binding record.

[0134] Extract the resource locator and operation license binding records (uriSrc, permSrc) from the entries to be expired. The resource locator in the transitional operation license binding record is uriSrc. The operation license type is the wider of permSrc and permTarget: if the license range of permSrc includes the license range of permTarget, then permSrc is used; otherwise, permTarget is used.

[0135] Step S870: Use the time period termination point time value in the time domain constraint of the access control rule entry to be invalidated as the effective start time point of the transitional operation license binding record, and use the time period termination point time value in the time domain constraint of the target access control rule entry as the effective end time point of the transitional operation license binding record to generate the transitional time domain constraint.

[0136] Extract the time value TE1, the time period termination point of the time domain constraint, from the entry to be invalidated. Extract the time value TE2, the time period termination point of the time domain constraint, from the target entry. The time period start point of the transition period time domain constraint is TE1, and the time period termination point is TE2.

[0137] Step S880: Combine the transitional operation permission binding record and the transitional time domain constraint into a transitional access control rule entry, insert the transitional access control rule entry into the preset permission policy mapping table and mark it as temporarily effective.

[0138] Create a new access control rule entry unit, setting its resource locator and operation permission binding record to the result of step S860, and its time-domain constraint condition to the result of step S870. Insert this new entry into the preset permission policy mapping table and attach a temporary effective status flag to it, with the status value denoted as TRANSITION. The unique rule identifier for this entry is automatically assigned by the rule identifier generator.

[0139] Step S890: When a new auto finance data access request is received from the access request terminal and the current system base time value is within the range defined by the transition period time domain constraint, the corresponding data access action is performed on the target auto finance data according to the operation license type in the transition period operation license binding record.

[0140] When step S130 processes the time domain compliance determination, if the current system base time value Dnow is within the range defined by the transition period time domain constraints, and the resource locator C1 of the target auto finance data matches the resource locator of the transition period access control rule entry, then the operation license type in the transition period operation license binding record is used as P1, and the data access action is executed according to step S140.

[0141] Step S8100: When the effective termination time of the transition period time domain constraint is reached, remove the transition period access control rule entry from the preset permission policy mapping table, and perform the corresponding data access action on the target auto finance data according to the target access control rule entry.

[0142] A periodic polling task continuously monitors the time end point of transition period access control rule entries. When Dnow exceeds this time end point, the transition period entry is deleted from the preset permission policy mapping table. Thereafter, when an access request for this resource locator is received, the operation permission type and time domain constraints in the target access control rule entry are directly used for permission determination.

[0143] Step S910: Construct an operation license semantic compatibility matrix. The row and column indices of the operation license semantic compatibility matrix are both operation license types. The matrix elements store compatibility direction tags between the operation license types represented by the row and column indices. The compatibility direction tags include forward compatibility tags, reverse compatibility tags, and bidirectional compatibility tags.

[0144] The operation license semantic compatibility matrix is ​​a two-dimensional array. The row and column indices are members of the operation license type enumeration set, which includes READ_ONLY, READ_WRITE, and EXECUTE. The matrix elements are selected from a predefined compatibility flag enumeration, which contains three values: FWD (forward compatibility), REV (reverse compatibility), and BID (bidirectional compatibility). The matrix assignment rules are as follows: for READ_WRITE and READ_ONLY, the matrix element is FWD, indicating forward compatibility; for READ_ONLY and READ_WRITE, the matrix element is REV; and for READ_WRITE and EXECUTE, the matrix element is BID, indicating bidirectional compatibility. The matrix is ​​filled in once during initialization according to the above rules and stored as a static constant two-dimensional array.

[0145] Step S920: Before performing the corresponding data access action on the target auto finance data according to the operation license type, extract the original operation intent description field requested by the auto finance data access request. The original operation intent description field is the non-standard operation intent text declared by the access request end.

[0146] Before step S140 is executed, the operation intent description field is extracted from the message body of the auto finance data access request. This field is a string type and stores the natural language description text of the supplementary operation intent declared by the access requester in addition to the standard operation permission type enumeration. If this field does not exist in the request message body, the original operation intent description field is an empty string.

[0147] Step S930: The original operation intent description field is segmented and converted into an operation intent feature vector. The operation intent feature vector is input into a preset operation intent classifier to obtain the classification probability distribution of the operation intent feature vector on a preset set of operation permission types. The operation permission type with the highest classification probability value in the classification probability distribution is selected as the inferred operation permission type.

[0148] The original operation intent description field is segmented using a word-sequence-based maximum forward matching segmentation algorithm to obtain a word sequence. Each word in the word sequence is mapped to a fixed-dimensional word vector using a pre-trained word embedding matrix (Dword dimension). The word embedding matrix is ​​then averaged digit by digit to obtain the operation intent feature vector `Vintent` (Dword dimension). The preset operation intent classifier is a three-layer fully connected feedforward neural network with an input layer dimension of Dword, a hidden layer dimension of Hclass with ReLU activation, and an output layer dimension of 3 with Softmax activation. The three neurons in the output layer correspond to the classification probabilities of READ_ONLY, READ_WRITE, and EXECUTE, respectively. `Vintent` is input into the preset operation intent classifier, and the classification probability distribution is calculated through forward propagation. The operation permission type with the highest classification probability is selected as the inferred operation permission type `Pinf`.

[0149] Step S940: Using the operation license type as the row index and the inferred operation license type as the column index, query the compatibility directionality marker in the operation license semantic compatibility matrix. If the queried compatibility directionality marker is a positive compatibility marker, it means that the capability range of the operation license type covers the capability range of the inferred operation license type. If the queried compatibility directionality marker is a negative compatibility marker, it means that the capability range of the inferred operation license type covers the capability range of the operation license type.

[0150] Using the operation license type P1 obtained in step S134 as the row index and the inferred operation license type Pinf as the column index, a two-dimensional array value retrieval operation is performed in the operation license semantic compatibility matrix to obtain the compatibility directionality label Mcomp. If Mcomp equals FWD, it is determined that the capability range of P1 covers Pinf. If Mcomp equals REV, it is determined that the capability range of Pinf covers P1. If Mcomp equals BID, it is determined that the capability ranges of the two overlap.

[0151] Step S950: When the queried compatibility directionality mark is a positive compatibility mark, keep the operation license type unchanged, perform the corresponding data access action on the target auto finance data, and at the same time, feed back the execution result of the data access action as the operation result corresponding to the inferred operation license type to the access request end.

[0152] When Mcomp equals FWD, the operation license type P1 remains unchanged, and the data access action is executed according to step S140. In the access execution result data body generated in step S140, a new inferredResult field is added. The original operation intent description field and the inferred operation license type Pinf are written into this field, indicating that the execution result of the data access action has covered the operation result required for the inferred operation intent. This data access receipt is then returned to the access requesting end.

[0153] Step S960: When the queried compatibility directionality mark is a reverse compatibility mark, send an operation intent confirmation prompt to the access requesting end. The operation intent confirmation prompt carries the inferred operation license type and its operation description text, requesting the access requesting end to confirm whether to change the access intent to the inferred operation license type.

[0154] When Mcomp equals REV, pause the execution of step S140. Construct an operation intent confirmation message, which includes a field suggestedPerm storing the inferred operation permission type Pinf and a field description storing the operation description text corresponding to Pinf. Encapsulate this message into an HTTP response with a response code of 300 and return it to the requesting client. Upon receiving this response, the requesting client can return either confirmation or rejection feedback.

[0155] Step S970: When the queried compatibility directionality mark is a bidirectional compatibility mark, the operation license type and the license capability boundary of the inferred operation license type are fused to generate an expanded operation license type, and the corresponding data access action is performed on the target auto finance data according to the expanded operation license type.

[0156] When Mcomp equals BID, the union of the license capability set S1 of operation license type P1 and the license capability set Sinf of inferred operation license type Pinf is obtained to obtain the expanded license capability set Saug. The smallest operation license type that can cover Saug is selected from the preset operation license type enumeration as the expanded operation license type Paug. P1 is replaced with Paug, and the data access action is performed according to step S140.

[0157] Step S980: When no compatible directional marker between the operation license type and the inferred operation license type can be found in the operation license semantic compatibility matrix, refuse to execute the data access action and return an operation intent incompatibility notification to the access requester.

[0158] If the element in row P1, column Pinf of the operation permission semantic compatibility matrix is ​​null or marked with a default NONE flag, it indicates that there is no compatibility relationship between the two. In this case, the data access action is refused, and an operation intent incompatibility notification message is constructed. The message contains the field `origPerm` storing P1, the field `infPerm` storing Pinf, and the field `reason` storing a description of the incompatibility reason. This notification is encapsulated as an HTTP response with a 403 response code and returned to the requesting client.

[0159] Step S990: Collect confirmation feedback from the access requester regarding the operation intent confirmation prompt. If the confirmation feedback indicates a change, perform the corresponding data access action on the target auto finance data based on the inferred operation permission type.

[0160] When the requesting end returns confirmation feedback to the operation intent confirmation prompt sent in step S960, the operation license type P1 is replaced with the inferred operation license type Pinf, and the data access action is executed according to step S140. If the confirmation feedback indicates rejection of the change, the original operation license type P1 is maintained and the data access action is executed. If the license capability of P1 cannot meet the original operation intent, the operation intent is partially met in the access execution result data body.

[0161] Step S1010: Construct a resource locator lineage tracing graph. The nodes in the resource locator lineage tracing graph represent resource locators, and the directed edges represent the lineage derivation relationship of the source resource locator to the target resource locator after data transformation operations. Each directed edge is labeled with a data transformation operation type.

[0162] The resource locator lineage tracing graph is stored in memory using a directed acyclic graph (DAG) data structure. Node objects contain a `uri` field storing the resource locator string. Directed edge objects contain a `srcNode` field pointing to the source node, a `dstNode` field pointing to the target node, and an `opLabel` field storing the data transformation operation type label string. The data transformation operation type label can take the values ​​MERGE, SPLIT, and MASK. The graph is initially empty; nodes and directed edges are dynamically added as data access actions are performed.

[0163] Step S1020: When a corresponding data access action is performed on the target auto finance data and the operation permission type is read / write, monitor whether the data access action generates a new resource locator. If a new resource locator is generated, add a node to the resource locator lineage tracing graph, and establish a directed edge between the node corresponding to the resource locator of the target auto finance data and the newly added node. The direction of the directed edge is from the resource locator node of the target auto finance data to the newly added node, and attach a data transformation operation type label of the data access action to the directed edge.

[0164] When executing a READ_WRITE type data access action in step S144, the data access execution unit checks whether a new resource locator creation operation has been triggered after completing the write operation. If the write operation results in the addition of new data resources and the allocation of a new resource locator Cnew in the system, the following operations are performed in the resource locator lineage tracing graph: Create a new node Nnew, with its uri field set to Cnew. Locate the node Nsrc corresponding to the resource locator C1 of the target auto finance data in the graph. Create a directed edge from Nsrc to Nnew, and write the type label of this data transformation operation in the opLabel field of the directed edge. The type label is determined as follows: if this write operation merges multiple data sources into Cnew, then opLabel is set to MERGE; if this write operation splits one data source into multiple targets, then a directed edge is created for each target resource locator, and opLabel is set to SPLIT; if this write operation includes data anonymization processing, then opLabel is set to MASK.

[0165] Step S1030: When the data transformation operation type label indicates a data merging type, the operation permission types in the access control rule entries of all source resource locator nodes participating in the merging are intersected to generate the initial operation permission type of the merged resource locator.

[0166] When the opLabel of a directed edge in step S1020 is MERGE, the merge operation permission calculation is triggered. In the resource locator lineage tracing graph, all incoming edges pointing to Nnew are searched, and the source node URI of each incoming edge is collected. These source node URIs represent all the source resource locators participating in the merge. For each source resource locator, the corresponding operation permission type is extracted from the preset permission policy mapping table. The intersection of the permission capability sets of all the above operation permission types is calculated, and the largest operation permission type that covers this intersection is selected from the preset operation permission type enumeration as the initial operation permission type for the merged resource locator Cnew.

[0167] Step S1040: When the data transformation operation type label indicates a data splitting type, the operation permission type in the access control rule entry of the source resource locator node to be split is directly assigned to each new resource locator generated after splitting, as the initial operation permission type of the split resource locator.

[0168] When the opLabel of a directed edge in step S1020 is SPLIT, the split operation license inheritance is triggered. In the resource locator lineage tracing graph, all outgoing edges pointed to by Nsrc with opLabel set to SPLIT are searched, and the target node uri for each outgoing edge is collected. For each target node uri, the operation license type P1 corresponding to the source resource locator C1 to be split is directly assigned to the initial operation license type corresponding to the target node uri.

[0169] Step S1050: When the data transformation operation type label indicates a data desensitization type, the operation permission type in the access control rule entry of the resource locator node to be desensitized is upgraded, the read-only type is upgraded to the read-write type, and the upgraded operation permission type is used as the initial operation permission type of the desensitized resource locator.

[0170] When the opLabel of the directed edge in step S1020 is set to MASK, the de-identification operation permission upgrade is triggered. The operation permission type P1 of the de-identified source resource locator C1 is retrieved from the preset permission policy mapping table. If P1 is READ_ONLY, it is upgraded to READ_WRITE; if P1 is READ_WRITE, it remains unchanged; if P1 is EXECUTE, it remains unchanged. The upgraded operation permission type is used as the initial operation permission type of the de-identified resource locator Cnew.

[0171] Step S1060: Write the initial operation permission type of the merged resource locator, the initial operation permission type of the split resource locator, and the initial operation permission type of the de-identified resource locator into the access control rule entries of the corresponding resource locator in the preset permission policy mapping table.

[0172] For the initial operation permission type of each new resource locator generated in steps S1030, S1040, and S1050, the access control rule entry corresponding to the new resource locator is searched or created in the preset permission policy mapping table, and the operation permission type field of the entry is set to the corresponding initial operation permission type. If the new resource locator does not yet exist in the mapping table, a new access control rule entry unit is created, with the uri field set to the new resource locator, the permission field set to the initial operation permission type, and the timeWindow field set to (0, MAX) by default.

[0173] Step S1070: When a request for access to automotive finance data for a newly added resource locator is received, reverse lineage tracing is performed along the resource locator lineage tracing graph to extract access control rule entries for all ancestor resource locator nodes of the newly added resource locator.

[0174] When a subsequent step S110 receives an access request for auto finance data, and the resource locator C1 of the target auto finance data is a newly created resource locator from steps S1020 to S1060, the node Nnew corresponding to C1 is located in the resource locator lineage tracing graph. Starting from Nnew, a depth-first search is performed to trace back along the incoming edges, collecting all source node uri along the tracing path to form an ancestor resource locator node set A. For each ancestor resource locator in A, its corresponding access control rule entry is extracted from the preset permission policy mapping table.

[0175] Step S1080: Perform interval union processing on the temporal constraints in the access control rule entries of all extracted ancestor resource locator nodes to generate the comprehensive temporal constraints of the newly added resource locator. The effective interval of the comprehensive temporal constraints is the interval union of the temporal constraints of all ancestor resource locator nodes.

[0176] For each ancestor resource locator in A, the temporal constraints (tStart, tEnd) are collected into a list of intervals. An interval union operation is performed on this list, merging overlapping or consecutive intervals into a continuous list. The merged intervals may consist of one or more non-overlapping intervals; the union of these intervals constitutes the comprehensive temporal constraint. The interval covering the current system reference time value Dnow is selected as the temporal constraint for the newly added resource locator C1. This comprehensive temporal constraint replaces the temporal constraint in the access control rule entry corresponding to the newly added resource locator, and then temporal compliance determination is performed according to step S130.

[0177] Step S1110: Attach an access requester quantity capacity threshold parameter to the data resource locator of each auto finance data. The access requester quantity capacity threshold parameter is stored in the extended field of the access control rule entry corresponding to the data resource locator in the preset permission policy mapping table.

[0178] In the preset permission policy mapping table, a new extended attribute field, `capThreshold`, is added to each access control rule entry. This field is an integer value representing the maximum number of concurrent requests allowed to access data simultaneously for that data resource locator. For entries not explicitly set, `capThreshold` takes the preset default concurrent capacity value.

[0179] Step S1120: Before each time a car finance data access request is received and the corresponding data access action is performed on the target car finance data, a concurrent access request counting operation is performed to count the set of concurrent request client identity strings that are currently in the process of data access and are accessing the same target car finance data resource locator.

[0180] Before performing the data access action in step S140, a query operation is performed on the concurrent access state table. The concurrent access state table is a hash map in memory, where the key is a resource locator string and the value is a set of hash signatures of the requesting client currently accessing the data. Using the resource locator C1 of the target auto finance data as the key, the corresponding set of hash signatures of the requesting client is searched in the concurrent access state table.

[0181] Step S1130: Calculate the number of requester identity strings in the set of concurrent requester identity strings to obtain the number of concurrent requesters. When the number of concurrent requesters is less than the access requester capacity threshold parameter corresponding to the resource locator of the target auto finance data, allow the auto finance data access request to enter the normal data access process and add the requester identity string to the set of concurrent requester identity strings.

[0182] Calculate the number of elements Ncon in Scon. Retrieve the access requester capacity threshold parameter Cmax corresponding to C1 from the preset permission policy mapping table. If Ncon is less than Cmax, allow this access request to enter the normal data access process, add the requester's identity hash feature code H1 to the Scon set, and update the concurrent access status table.

[0183] Step S1140: When the number of concurrent requesters is equal to the access requester capacity threshold parameter, extract the requester role affiliation tag corresponding to each requester identity string in the set of concurrent requester identity strings, and calculate the role priority score of each requester role affiliation tag.

[0184] If Ncon equals Cmax, then for each requester's identity hash feature in Scon, the corresponding requester role affiliation tag is extracted from the preset permission policy mapping table according to the method in step S120. Based on the preset role priority score mapping table, each requester role affiliation tag is mapped to a role priority score; roles with higher role priority scores have higher priority in concurrent contention.

[0185] Step S1150: Extract the priority score of the role of the requesting end corresponding to the requesting end identity string carried in the auto finance data access request. If the priority score of the role of the requesting end is greater than the lowest priority score in the set of concurrent requesting end identity strings, remove the requesting end identity string with the lowest priority score from the set of concurrent requesting end identity strings, send an access interruption notification to the accessing end corresponding to the removed requesting end identity string with the interruption reason being priority preemption, and add the requesting end identity string to the set of concurrent requesting end identity strings to allow it to enter the normal data access process.

[0186] Obtain the role priority score Pnew of the requesting client corresponding to the requesting client's identity hash feature H1. Search for the lowest role priority score Pmin and its corresponding requesting client identity hash feature Hmin in Scon. If Pnew is greater than Pmin, remove Hmin from Scon and send an access interruption notification to the accessing client corresponding to Hmin, including the interruption reason code PREEMPTION. Add H1 to Scon, allowing this access request to enter the normal data access process, and continue to step S140.

[0187] Step S1160: If the priority score of the role to be requested is not greater than the lowest priority score, then the auto finance data access request is rejected and the normal data access process is entered. The capacity saturation rejection response is returned to the access requesting party with the reason for rejection being concurrent capacity saturation.

[0188] If Pnew is less than or equal to Pmin, the access request is rejected and the normal data access process begins. A capacity saturation rejection response message is constructed, containing the rejection reason code CAP_SATURATION, and returned to the requesting client.

[0189] Step S1170: When the number of concurrent requesters exceeds the capacity threshold parameter for the number of access requesters, the auto finance data access request is directly rejected to enter the normal data access process, and a capacity over-limit rejection response is returned to the access requester.

[0190] If Ncon is greater than Cmax, the access request is rejected directly, and a capacity over-limit rejection response message containing the rejection reason code CAP_EXCEED is constructed and returned to the requesting client.

[0191] Step S1210: Construct an operation license decay curve configuration table. The operation license decay curve configuration table is indexed by the data resource locator and stores the operation license decay start time, operation license decay step interval, and operation license decay step amount.

[0192] The operation license decay curve configuration table is a configuration table in a relational database. The table structure contains four columns: uri (data resource locator string), decayStart (operation license decay start timestamp), decayInterval (operation license decay step interval duration), and decayStep (operation license decay step size). decayStep takes the value of a preset decay step enumeration value, and each enumeration value corresponds to an operation license degradation mapping relationship.

[0193] Step S1220: Monitor the time relationship between the current system base time value and the operation permission decay start time point. When the current system base time value reaches or exceeds the operation permission decay start time point, trigger the operation permission decay process for the data resource locator.

[0194] The scheduled polling task scans the operation license decay curve configuration table once every preset detection period. For each record in the configuration table, it obtains the current system base time value Dnow and compares Dnow with the decayStart field value of the record. If Dnow is greater than or equal to decayStart, and the operation license decay process corresponding to the record has not yet started, then the operation license decay process for that record is triggered, a decay process record is created in the process management table, and its status is marked as ACTIVE.

[0195] Step S1230: After the operation permission decay process is triggered, the operation permission decay start time is used as the starting point of the timing. The operation permission decay step operation is periodically executed according to the operation permission decay step interval. Each decay step operation adjusts the current operation permission type to the lower level permission capability specified by the operation permission decay step amount according to the predefined permission downgrade mapping relationship.

[0196] After the decay process starts, starting from decayStart, a decay step operation is performed every decayInterval. The predefined permission degradation mapping relationship is as follows: if the current operation permission type is READ_WRITE, a decay step of one level will downgrade to READ_ONLY, and a decay step of two levels will downgrade to DENY; if the current operation permission type is READ_ONLY, a decay step of one level will downgrade to DENY; if the current operation permission type is EXECUTE, a decay step of one level will downgrade to READ_ONLY; if the current operation permission type is DENY, decay will not continue.

[0197] Step S1240: Update the operation permission type after each decay step operation to the access control rule entry corresponding to the data resource locator in the preset permission policy mapping table, overwriting the operation permission type in the original resource locator and operation permission binding record.

[0198] After each decay step operation is executed, the decayed operation permission type Pdecay is obtained. The access control rule entry unit corresponding to the URI is located in the preset permission policy mapping table, and the permission field value of the entry is updated to Pdecay.

[0199] Step S1250: When a request for access to auto finance data is received for a data resource locator that is in the process of operation license decay, the corresponding data access action is performed on the target auto finance data according to the updated operation license type.

[0200] When step S110 receives an auto finance data access request and the resource locator C1 of the target auto finance data is in the operation permission decay process, the access control rule entry corresponding to C1 is extracted from the preset permission policy mapping table. At this time, the operation permission type of this entry has been updated to the decayed Pdecay as per step S1240. Using Pdecay as the operation permission type, permission determination and data access actions are performed according to steps S130 and S140.

[0201] Step S1260: At the same time as each operation license decay step operation is performed, an operation license decay event record is generated and written to the decay audit log. The operation license decay event record includes the decay occurrence timestamp, the operation license type before decay, the operation license type after decay, and the decay step amount.

[0202] Each time a decay step operation is executed, a decay event record is generated. This record contains the following fields: `ts` (timestamp of decay occurrence, `Dnow`), `permBefore` (operation permission type before decay), `permAfter` (operation permission type after decay, `Pdecay`), and `stepAmount` (decay step size). This record is appended to the decay audit log file or audit log database table.

[0203] Step S1270: When the operation permission decay process adjusts the operation permission type to an empty permission state, terminate the operation permission decay process and mark the access control rule entry corresponding to the data resource locator as a permanent denial state in the preset permission policy mapping table.

[0204] When the decayed operation permission type reaches the DENY state, the operation permission decay process is terminated, and the corresponding record in the process management table is updated to TERMINATED. The access control rule entry corresponding to the URI is marked as permanently denied in the preset permission policy mapping table by setting `permanentDenyFlag` to `true` in the entry's extended attribute.

[0205] Step S1280: During the operation license decay process, if a license exemption instruction for the data resource locator is received, the operation license decay process is paused, the operation license type is restored to the original operation license type stored in the operation license decay curve configuration table before the operation license decay start time point, and the operation license decay start time point is reset to a preset delay time point after the pause time. When the reset operation license decay start time point is reached, the operation license decay process is restarted, and the periodic operation license decay step operation is continued to be performed according to the operation license decay step interval and operation license decay step amount.

[0206] The license exemption command is issued by a role with administrator privileges through the management interface, carrying the target URI and exemption duration. Upon receiving the license exemption command, the operation license decay process corresponding to that URI is paused, and the process status is updated to SUSPENDED. The original operation license type recorded during configuration for that URI is read from the operation license decay curve configuration table, and the operation license type for that URI in the preset permission policy mapping table is restored to the original operation license type. The new decay start time is calculated as Dnow plus the exemption duration, and the decayStart field value in the process management table is updated. When Dnow reaches the new decay start time, the process status is restored to ACTIVE, and the periodic decay step operation continues according to decayInterval and decayStep.

[0207] Step S1310: Construct an access request behavior trajectory graph model. The access request behavior trajectory graph model includes request node, data resource node and operation edge. The request node stores the request identity identifier string, the data resource node stores the resource locator, and the operation edge stores the operation permission type and the operation occurrence timestamp.

[0208] The access request behavior trajectory model is stored in a graph database as an attribute graph. Nodes in the graph have two types of labels: the "User" label represents a requesting node, with the attribute "uid" storing the requesting node's identity hash; the "Data" label represents a data resource node, with the attribute "uri" storing the resource locator. Directed edges in the graph are labeled "ACCESS," with the attribute "perm" storing the operation permission type and the attribute "ts" storing the operation's timestamp. The graph is initially empty.

[0209] Step S1320: After each data access action to any target auto finance data is completed, add an operation edge to the access request behavior trajectory graph model. The starting node of the operation edge is the requesting node that issued this auto finance data access request, and the ending node of the operation edge is the data resource node corresponding to the target auto finance data accessed this time.

[0210] After step S140 is completed, obtain the requester's identity hash feature H1 and the resource locator C1 of the target auto finance data. Search the graph database for a node labeled User with uid equal to H1; if it does not exist, create a new node Nu. Search for a node labeled Data with uri equal to C1; if it does not exist, create a new node Nd. Create a directed edge from Nu to Nd, labeled ACCESS.

[0211] Step S1330: Extract the operation permission type and operation occurrence timestamp of the operation edge, and attach the operation permission type and operation occurrence timestamp as operation attribute fields to the operation edge.

[0212] Obtain the operation permission type P1 and the access completion timestamp D2 for this data access action. Assign P1 to the perm attribute of the directed edge created in step S1320, and assign D2 to the ts attribute.

[0213] Step S1340: Perform time-series sorting on all operation edges connected to the same request node in the access request behavior trajectory graph model, and generate the operation edge time-series chain of the request node according to the order of the operation timestamps.

[0214] Starting with the requesting node Nu, query the graph database for all ACCESS edges originating from Nu. Sort the query results in ascending order by the edge's ts attribute value. The sorted edge list is Nu's operation edge sequence chain, Echain.

[0215] Step S1350: Extract the data resource nodes pointed to by two adjacent operation edges in the operation edge timing chain to form a data resource node transfer pair, and add a transfer time interval to each data resource node transfer pair. The transfer time interval is determined by the difference between the operation timestamps of the two adjacent operation edges.

[0216] Traverse the sequential chain Echain of operations between two adjacent edges ei and e(i+1), extract the data resource node Nd_i pointed to by ei, and extract the data resource node Nd_(i+1) pointed to by e(i+1). Construct the data resource node transition pair (Nd_i, Nd_(i+1)). Calculate the transition time interval Δt = ts(e(i+1)) - ts(ei). Add the triple (Nd_i, Nd_(i+1), Δt) to the transition pair list Ltrans.

[0217] Step S1360: Count the frequency of data resource node transfer pairs corresponding to all requesting nodes in the access request behavior trajectory graph model, generate a data resource node transfer frequency table, perform row normalization operation on the data resource node transfer frequency table, and generate a data resource node transfer probability distribution. The data resource node transfer probability distribution is used to characterize the probability of jumping from one data resource node to another.

[0218] Summarize the transfer pair lists for all requesting nodes in the graph database and count the frequency of each (source node URI, target node URI) combination. Construct a data resource node transfer frequency table, with the row index being the source node URI and the column index being the target node URI. Perform row normalization on each row of the transfer frequency table: divide each element of the row by the sum of all elements in the row until the sum of the elements in the row is 1. The normalized table is the data resource node transfer probability distribution ProbTrans.

[0219] Step S1370: When a new auto finance data access request is received from the access requesting end, extract the preceding data resource nodes accessed by the access requesting end in the previous data access action, and predict the expected target data resource node set of the access requesting end based on the preceding data resource nodes and the data resource node transition probability distribution.

[0220] When a new auto finance data access request is received from the requesting client, the target data resource node of the most recent ACCESS edge of the requesting client is queried in the graph database, and its URI is denoted as Uprev. In the data resource node transfer probability distribution ProbTrans, the row with row index Uprev is found, and the column index URIs of the row with probability values ​​greater than the preset jump probability threshold are extracted to form the expected target data resource node set Uexpect.

[0221] Step S1380: Compare the expected target data resource node set with the resource locator of the target auto finance data carried in this auto finance data access request. If the resource locator of the target auto finance data does not belong to the expected target data resource node set, an access behavior deviation mark is generated. When the access behavior deviation mark is generated, a temporary downgrade is performed on the operation permission type in the access control rule entry to obtain a temporary downgrade operation permission type, and the corresponding data access action is performed on the target auto finance data according to the temporary downgrade operation permission type.

[0222] The resource locator C1 of the target auto finance data in this auto finance data access request is compared with each URI in Uexpect. If C1 does not belong to any URI in Uexpect, an access behavior deviation flag is generated, and the flag value is recorded as true. When the access behavior deviation flag is true, a temporary downgrade is performed on the operation permission type P1: if P1 is READ_WRITE, it is downgraded to READ_ONLY; if P1 is EXECUTE, it is downgraded to READ_ONLY; if P1 is READ_ONLY, it remains unchanged. The operation permission type after the temporary downgrade is recorded as Ptemp. Ptemp replaces P1, and the data access action is executed according to step S140.

[0223] In real-world business scenarios, access control for auto finance data is first achieved through… Figure 2 The policy mapping and rule matching logic shown executes permission determination. In this processing step, the requester's identity identifier string is hashed to generate an identity hash feature code, and the requester's role attribution label is traced through a preset role hierarchy tree to generate a role hierarchy path sequence. The two are combined as a joint query key, and partition indexing is performed in the preset permission policy mapping table to extract the policy data block to be decoded with a double-layer nested encapsulation structure. After the policy decapsulation process is layered, the data block is separated into a first byte stream segment and a second byte stream segment, corresponding to the serialized data of the resource binding policy set and the serialized data of the time domain restriction policy set, respectively. The two segments are deserialized to restore the resource locator and operation permission binding record set and the time domain constraint condition set, respectively, and are associated through equi-join processing. The associated operation permission and time domain constraint conditions are encapsulated by rule entries to form an access control rule entry set. When the target data resource locator is input, the resource attribution domain segment, resource category segment, and resource instance identifier segment are obtained through segmentation processing, and are merged to generate a resource locator prefix pattern string. The prefix pattern string is used to perform prefix matching traversal in the access control rule entry set, and then the unique binding record is located and the operation permission type is extracted through exact matching. Simultaneously, the request initiation timestamp is compared temporally with the start and end points of the time period in the time domain constraints corresponding to the target resource locator, generating start point satisfaction status flags and end point satisfaction status flags. These two flags are then logically joined to obtain the time domain compliance status identifier. This processing flow corresponds to the specific execution of steps S120 and S130.

[0224] Subsequently, the access request data entered. Figure 3The approval management process shown is in progress and being processed. Through this interface, users can view the access requests submitted by the requesting party, categorized into four status dimensions: "Pending Approval Request," "Approved," "Rejected," and "All Records." The "Add Policy Entry" and "Batch Import" entries in the upper right corner of the interface provide operational support for expanding and batch configuring the policy mapping table in step S120. The pending approval request list displays specific request instances by fields such as sequence number, request ID, requesting party identifier, role affiliation, target resource locator, operation license type, request time, and status. For example, request ID "REQ-20250707-001" corresponds to a read-only access request for / loan / contract / read by requester ID-8821 (Senior Analyst), with a status marked "Pending Approval"; request ID "REQ-20250707-002" corresponds to a read / write request for / risk / report / write by an external auditor, with a status marked "Approved"; and request ID "REQ-20250707-003" corresponds to an access request for / finance / asset / delete by a regular user, with a status marked "Rejected". Furthermore, the top of the list provides multi-dimensional filtering conditions based on status, role, time range, and resource locator for refined retrieval and positioning of the request data received in step S110.

[0225] Once a specific request is selected Figure 4 The details page shows the specific comparison process for permission determination in step S130. For example, the details of request REQ-20250707-001 show the anonymized identity hash identifier, role hierarchy depth, and target resource locator. The "Policy Matching Path" area of ​​the interface displays the complete permission determination chain in the form of a step sequence: Step ① marks the identity hash location partition P-03; Step ② marks the role hierarchy path tracing from root through analyst to senior analyst; Step ③ marks the resource binding policy matching, mapping / loan / contract / read to read-only permission; Step ④ marks the time domain constraint verification, proving that the request time 10:23 is within the valid range of [08:00, 18:00]; Step ⑤ marks the concurrency capacity verification, showing that the current concurrency is 4 / 5 and has not yet saturated. Each of the above steps is accompanied by a compliance status mark, intuitively reflecting the pass status of each verification in step S130.

[0226] exist Figure 5In the approval confirmation process shown, the system provides the final authorization confirmation operation based on the permission information determined in step S140. The confirmation pop-up window lists the request ID, requesting party information, authorization operation license type, and time validity period (2025-07-07 08:00 to 2025-07-07 18:00), and provides "Confirm Passed" and "Cancel" buttons to perform the establishment or revocation of permission status.

[0227] Feedback data after the data access action is executed, through Figure 6 The request details and access receipt panel are displayed. This panel presents the permission determination results and execution receipts in a structured manner, listing the matching policy ID, operation permission type, time-domain compliance status, and concurrency capacity status. At the same time, the "Access Receipt" card displays the execution result of this data access, including the status code "200 OK", the number of affected records "1247", and the response time "12ms".

[0228] Figure 7 The system notification center displayed centrally shows various alarms and policy change events triggered during operation. Alarm entries are arranged in reverse chronological order, recording information such as policy entry expiration reminders, priority preemption caused by full concurrency capacity, temporary degradation triggered by deviations in requester behavior patterns, and successful automatic policy renewal. The above notification content is related to the abnormal behavior detection, behavior pattern deviation judgment, and concurrency capacity control processes in steps S310 to S360 and S610 to S660.

[0229] exist Figure 8 The access trend and resource popularity analysis view presents macro-statistics and operational trends in visual charts. The top indicator cards display the total number of requests today (1365), approval rate (94.2%), number of anomaly blocking incidents (27), and average response time (48ms), accompanied by arrows showing the month-on-month changes. The anomaly score trend chart in the lower left shows the fluctuation of anomaly scores over the past 24 hours, with red dots marking anomaly peaks exceeding the warning threshold. The lower right uses a horizontal bar chart to list the access frequency distribution of the top 10 data resources, such as / loan / contract / read (386 accesses), / risk / report / write (298 accesses), and / finance / asset / read (231 accesses).

[0230] Figure 9The real-time monitoring view shown provides dynamic tracking of the system's operational status. The log stream on the left scrolls in real time, recording the processing status of each access request from 10:56:17 to 10:56:50, including entries such as successful access, policy renewal, and exception handling. The right side uses a circular progress chart to visually display the current concurrent usage status of each hot resource. For example, / loan / contract / read is at 80% (4 / 5), / risk / report / write is at 100% (2 / 2) and fully loaded, / finance / asset / read is at 60% (6 / 10), and / customer / profile / read is at 40% (4 / 10). The above interface monitoring data provides visualized data for the concurrent capacity monitoring and real-time access log recording in steps S610 to S660.

[0231] In an exemplary embodiment, an access control-based automotive finance data access system is provided. This system can be a terminal, server, etc., and its internal structure includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, near-field communication, or other technologies. When the computer program is executed by the processor, it implements an access control-based automotive finance data access method. The display unit is used to form a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, or a button, trackball, or touchpad set on the casing of an access control-based automotive financial data access system, or an external keyboard, touchpad, or mouse, etc.

[0232] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A method for accessing auto finance data based on access control, characterized in that, The method includes: The system receives an auto finance data access request from the requesting client. The auto finance data access request carries the requesting client's identity string, the requesting client's role affiliation tag, the resource locator of the target auto finance data, and the request initiation timestamp. Based on the requester's identity string, a preset permission policy mapping table is retrieved, and access control rule entries corresponding to the requester's identity string and the requester's role affiliation tag are extracted. The access control rule entries include resource locators and operation permissions binding records as well as time-domain constraints. By using the binding record of resource locators and operation permissions in the access control rule entries, permission matching processing is performed on the resource locators of the target auto finance data to obtain the operation permission type, and the time domain constraint conditions are used to perform time domain compliance judgment processing on the request initiation timestamp to obtain the time domain compliance status identifier. When the time domain compliance status indicator indicates that the request initiation timestamp is within the valid range defined by the time domain constraint, the corresponding data access action is performed on the target auto finance data according to the operation permission type, an auto finance data access receipt is obtained, and the auto finance data access receipt is returned to the access request end. The step of retrieving a preset permission policy mapping table based on the requester's identity string and extracting access control rule entries corresponding to the requester's identity string and the requester's role affiliation tag includes: The requester's identity string is irreversibly transformed according to a preset hash transformation logic to generate an identity hash feature code with a fixed-length byte sequence. The requesting party's role attribution tag is subjected to hierarchical path tracing processing with the preset role hierarchy tree to obtain the role hierarchy path sequence of the requesting party's role attribution tag in the preset role hierarchy tree; Using the identity hash feature code and the role hierarchy path sequence as the joint query key, the partition index positioning process is performed in the preset permission policy mapping table to determine the logical storage partition in the preset permission policy mapping table that stores the corresponding access control rule entries. The policy data block to be decoded that has a mapping relationship with the joint query key is extracted from the logical storage partition. The policy data block to be decoded contains a resource binding policy set and a time domain restriction policy set that have been nested and encapsulated. Call the policy decapsulator that matches the data encapsulation format of the policy data block to be decoded, and perform layered decapsulation processing on the policy data block to be decoded to separate the first byte stream segment corresponding to the resource binding policy set and the second byte stream segment corresponding to the time domain restriction policy set; The first byte stream segment is deserialized with policy entries to restore the set of binding records of resource locators and operation permissions with resource locators as indexes and operation permissions as values. The second byte stream segment is deserialized with time-domain parameters to restore the set of time-domain constraints with resource locators as indexes and start and end points of valid time periods as values. The set of binding records between the resource locator and the operation permit is joined with the set of time-domain constraints according to the resource locator, so that the operation permit corresponding to each resource locator is associated with its time-domain constraints. After the operation permissions and time-domain constraints that have been associated and corresponded through equi-join processing are processed into rule entries, a single access control rule entry unit is generated. All the generated access control rule entry units are combined into an access control rule entry set. Each access control rule entry in the access control rule entry set contains a resource locator and operation permission binding record as well as time-domain constraints.

2. The method for accessing auto finance data based on access control according to claim 1, characterized in that, The process involves using the binding record between resource locators and operation permissions in the access control rule entries to perform permission matching on the resource locators of the target auto finance data to obtain the operation permission type, and using the time-domain constraints to perform time-domain compliance determination on the request initiation timestamp to obtain a time-domain compliance status identifier, including: The resource locator of the target auto finance data is segmented according to a preset character delimiter to obtain a resource locator segment sequence. The resource locator segment sequence includes a resource domain segment, a resource category segment, and a resource instance identifier segment. Extract the resource domain segment and resource category segment from the resource locator segment sequence, combine them to generate a resource locator prefix pattern string, and use the resource locator prefix pattern string as the matching benchmark to perform prefix matching traversal processing in the binding records of resource locators and operation permissions, and filter out all candidate binding records whose resource locator prefixes are consistent with the resource locator prefix pattern string. Perform exact matching processing on the resource locators in the selected candidate binding records, and compare the resource locators of the target auto finance data with the resource locators in each candidate binding record segment by segment to determine the unique binding record that is completely consistent with the resource locators of the target auto finance data. Extract the corresponding operation permission field value from the unique binding record, and use the operation permission field value as the operation permission type for the target auto finance data; Using the resource locator of the target auto finance data as the index key, query the start and end point information of the valid time period associated with the resource locator in the time domain constraints. The start and end point information of the valid time period includes the start time value and the end time value of the time period. The request initiation timestamp is compared with the time value of the start point of the time period. If the request initiation timestamp is not earlier than the time value of the start point of the time period, a start point satisfaction status flag is generated. The request initiation timestamp is compared with the time value of the end point of the time period. If the request initiation timestamp is not later than the time value of the end point of the time period, an end point satisfaction status flag is generated. Perform a logical conjunction operation on the start point satisfying status flag and the end point satisfying status flag. If both the start point satisfying status flag and the end point satisfying status flag indicate that the timing condition is met, then generate a time-domain compliance status identifier that represents that the request initiation timestamp is in the valid range.

3. The method for accessing auto finance data based on access control according to claim 1, characterized in that, When the time-domain compliance status indicator indicates that the request initiation timestamp is within the valid range defined by the time-domain constraints, the corresponding data access action is performed on the target auto finance data according to the operation permission type, an auto finance data access receipt is obtained, and the auto finance data access receipt is returned to the access requesting end, including: Obtain the status bit value of the time-domain compliance status identifier. If the status bit value is a valid status value, then trigger the execution process of subsequent data access actions. Based on the license type code of the operation license type, the data access execution function pointer corresponding to the license type code is searched in the preset operation execution mapping table, and the corresponding data access execution unit is called through the data access execution function pointer; The resource locator of the target auto finance data is passed to the data access execution unit, which then locates the data storage node in segments according to the resource ownership domain in the resource locator, and locks the target data storage block in the data storage node in segments according to the resource instance identifier in the resource locator. The data access execution unit performs corresponding data operations on the target data storage block according to the operation permission type. If the operation permission type is read-only, a data block read operation is performed and the read byte content is cached in a memory buffer. If the operation permission type is read-write, a data block read-write operation is performed. After the data operation is completed, the data access execution unit collects the execution status code of the operation execution process and the metadata of the operation execution result. The metadata includes the number of data record entries affected by the operation. The execution status code and the metadata are structured and encapsulated to generate an access execution result data body. The request initiation timestamp carried in the auto finance data access request is obtained, and the request initiation timestamp and the access completion timestamp are added together as access operation time sequence records to the access execution result data body. The access execution result data body is serialized into an auto finance data access receipt with a preset communication protocol format, and the auto finance data access receipt is transmitted back to the access requesting end in the form of a message packet. The message header of the auto finance data access receipt contains a response code that the access requesting end can recognize.

4. The method for accessing auto finance data based on access control according to claim 1, characterized in that, The method further includes: Construct a tree-like index structure for automotive finance data resource locators, wherein the tree-like index structure takes the business domain to which the data belongs as the root node, the data sub-category as the intermediate node, and the data resource locator as the leaf node; Assign a node operation permission inheritance attribute to each non-leaf node of the tree index structure. The node operation permission inheritance attribute is used to specify whether the child nodes under the non-leaf node automatically inherit the operation permission configuration set by the non-leaf node. Each leaf node of the tree index structure is bound to an operation permission whitelist and a time domain constraint blacklist. The operation permission whitelist records the types of operations that are allowed to be performed on the data resources corresponding to the leaf node, and the time domain constraint blacklist records the time intervals during which access to the data resources corresponding to the leaf node is prohibited. Upon receiving the auto finance data access request, a tree-like path backtracking process is performed on the resource locator of the target auto finance data, and the node operation permission inheritance attributes of all non-leaf nodes on the complete path from the leaf node to the root node are extracted in sequence. Starting from the root node of the complete path, the node operation permission inheritance attributes of each non-leaf node are merged with the operation permission whitelist of the leaf nodes layer by layer to generate a fused operation permission set. Operation permissions covered by the time interval in the time domain constraint blacklist are removed from the fused operation permission set to generate a final effective operation permission set. The operation permission type in the access control rule entry is replaced by the final effective operation permission set and used to implement corresponding data access actions on the target auto finance data.

5. The method for accessing auto finance data based on access control according to claim 1, characterized in that, The method further includes: Obtain the historical request initiation timestamp sequence and historical target data resource locator sequence carried in the multiple historical auto finance data access requests sent by the access requesting end; Based on the historical request initiation timestamp sequence and the historical target data resource locator sequence, an access behavior time sequence of the access request terminal is constructed, wherein each time point in the access behavior time sequence includes an access time value and an access data resource locator. Perform time-series pattern mining processing on the access behavior time series to extract the access frequency fluctuation pattern and access resource switching pattern of the access request end within a preset time window; Based on the access frequency fluctuation pattern and the access resource switching pattern, a behavior pattern label vector of the access request terminal is generated, and the behavior pattern label vector includes a frequency feature dimension and a resource preference dimension. The behavior pattern tag vector is associated and bound with the access control rule entries corresponding to the access request terminal stored in the preset permission policy mapping table to generate behavior-aware access control rule entries. When the access request terminal receives another request for access to auto finance data, the current access behavior is compared with the behavior-aware access control rule entry for deviation calculation. If the result of the deviation calculation exceeds the preset deviation tolerance threshold, the operation permission type in the current access control rule entry is temporarily contracted to obtain a temporary operation permission type. Based on the temporary operation permission type, the corresponding data access action is performed on the target auto finance data.

6. The method for accessing auto finance data based on access control according to claim 1, characterized in that, The method further includes: Construct a knowledge base for resolving permission policy conflicts. The knowledge base includes the correspondence between conflict type tags and resolution rule sets. The conflict type tags include permission inheritance conflicts and time interval overlap conflicts. After each access control rule entry is generated, a conflict scan is performed on all access control rule entries in the access control rule entry set to detect whether there is an inconsistency between operation license types pointing to the same resource locator. If an inconsistency is detected between operation license types pointing to the same resource locator, the inconsistent operation license types and their respective source policy identifiers are encapsulated into a license inheritance conflict instance. The conflict type label of the permission inheritance conflict instance is determined as a permission inheritance conflict, and the resolution rule set corresponding to the conflict type label is searched in the permission policy conflict resolution knowledge base. The permission inheritance conflict resolution rule is extracted from the resolution rule set. The permission inheritance conflict resolution rule specifies that the operation permission type corresponding to the source policy identifier with a large role level depth is the first choice, and the operation permission type corresponding to the source policy identifier with a small role level depth is the second choice. Based on the permission inheritance conflict resolution rules, a final operation permission type is selected from the inconsistent operation permission types, and the final operation permission type replaces the corresponding operation permission type in the access control rule entry set.

7. The method for accessing auto finance data based on access control according to claim 1, characterized in that, The method further includes: Obtain the requester identity string carried in the auto finance data access request, input the requester identity string into a preset identity association graph for associated entity retrieval processing, and extract the set of associated identity strings that are connected to the requester identity string by an associated edge. Extract the associated role affiliation tag and associated access control rule entry corresponding to each associated identity string in the associated identity string set. Perform intersection processing on the resource locator and operation permission binding record in the associated access control rule entry and the resource locator and operation permission binding record in the access control rule entry of the access requesting end itself to generate a shared resource locator set. For each shared resource locator in the set of shared resource locators, an operation permission merging process is performed. The operation permission type of the access requester and the operation permission type of the associated identity string are subjected to a permission range union operation to generate a shared operation permission type. The shared operation permission type is used as the extended operation permission type of the access requester for the shared resource locator. Based on the extended operation license type, perform corresponding data access actions on the target auto finance data corresponding to the shared resource locator.

8. The method for accessing auto finance data based on access control according to claim 1, characterized in that, The method further includes: The system obtains the request initiation timestamps carried by all auto finance data access requests issued by the access requesting end within a preset sliding time window, generates a request initiation timestamp sequence, calculates the time interval value sequence of adjacent request initiation timestamps in the request initiation timestamp sequence, and generates access rhythm feature parameters based on the mean and fluctuation amplitude of the time interval value sequence. Obtain the resource locator sequence of the target auto finance data accessed by the access requesting terminal within the preset sliding time window, extract the resource category segment of each resource locator, and generate a resource category transfer sequence; The frequency of each resource category in two consecutive accesses in the resource category transfer sequence is counted, a resource category transfer frequency statistics table is constructed, and the resource category transfer frequency statistics table is row normalized to generate a resource category transfer probability matrix. The access rhythm feature parameters are normalized to generate a standardized rhythm deviation index. Simultaneously, the resource category transition probability matrix is ​​calculated to generate a behavior pattern deviation index. The rhythm deviation index and the behavior pattern deviation index are input into a preset access behavior anomaly evaluator for multi-dimensional fusion analysis. The preset access behavior anomaly evaluator performs anomaly scoring on the current access behavior, generating an anomaly score value. When the anomaly score value exceeds a preset anomaly warning threshold, the operation permission type in the access control rule entry corresponding to the access request terminal is downgraded from read-write to read-only. Based on the downgraded operation permission type, the corresponding data access actions are performed on the target auto finance data.

9. A vehicle finance data access system based on access control, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the access control-based auto finance data access method according to any one of claims 1 to 8 by executing the machine-executable instructions.

Images