Logistics authority dynamic allocation method, apparatus and device, and storage medium

Abstract

The invention relates to the technical field of logistics, and discloses a logistics authority dynamic allocation method, device and equipment and a storage medium, and the method comprises the steps: obtaining target user behavior data and target business data, constructing a user portrait containing static attributes and dynamic behavior data, and according to the dynamic behavior data, carrying out dynamic allocation on the user portrait; the method comprises the steps of predicting a real-time authority demand of a user through a machine learning model, determining a real-time risk level of the user, dynamically generating an authority strategy meeting the real-time authority demand through a rule engine according to a user portrait, the real-time risk level and current service data, and performing real-time authentication by applying the dynamic authority strategy in response to a data access request. And the query process is optimized based on the resource prediction model so as to return a logistics permission dynamic allocation result within the permission range, and the logistics permission of the user is dynamically allocated. According to the scheme, the problems of low logistics data utilization rate and query efficiency, high data security risk and insufficient multi-platform collaboration in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the field of logistics technology, and in particular to a method, apparatus, equipment and storage medium for dynamic allocation of logistics permissions. Background Technology

[0002] Traditional logistics management systems primarily employ a role-based access control (RBAC) model. Once permissions are assigned to a role, they remain fixed until manually modified by the administrator. User permissions are entirely determined by their assigned role. The system cannot dynamically adjust based on real-time business scenarios (such as month-end reconciliation or promotional periods), user behavior (such as query frequency or access patterns), or the sensitivity of the data itself, resulting in low data utilization. Queries rely on direct queries from traditional relational databases. When dealing with tens of millions or even larger volumes of historical data, the lack of effective preprocessing and optimization mechanisms easily triggers time-consuming full table scans, causing rapid overload of database server CPU and memory resources. The system cannot predict peak and trough query loads or perform elastic allocation of computing resources. This leads to a severe impact on user experience and decision-making efficiency. Furthermore, to cope with occasional peak query times, enterprises need to continuously maintain high-performance, high-cost hardware, resulting in low resource utilization. The protection of sensitive data lacks fine-grained control, failing to achieve precise control at the field (column) or record (row) level. Audit trails are weak and easily tampered with, making audit logs unreliable. Permission changes rely on manual approval, resulting in slow processes that cannot meet the needs of rapidly changing business needs and are prone to vulnerabilities due to human error. The risk of sensitive data leakage is high, and in the event of a security incident, it is difficult to provide legally credible and tamper-proof operational evidence. Insufficient multi-source data collaboration, significant differences in data formats between internal and external systems, independent operation of each system, and a lack of effective correlation and integration between data sources contribute to a poor user experience and difficulties in data analysis. Therefore, logistics enterprises urgently need a dynamic allocation method for logistics permissions to address the pain points of traditional logistics systems, such as low data utilization, low query efficiency, high data security risks, and insufficient multi-platform collaboration. Summary of the Invention

[0003] This invention provides a method, device, and storage medium for dynamic allocation of logistics permissions, which solves the problems of low utilization rate of logistics data, low query efficiency, high data security risks, and insufficient multi-platform collaboration in the prior art.

[0004] According to one aspect of this application, a method for dynamically allocating logistics permissions is disclosed, the method comprising: Acquire target user behavior data and target business data; Based on the target behavior data and the target business data, a user profile is constructed, which includes static attributes and dynamic behavior data. Based on the dynamic behavior data, the real-time permission requirements of the target user are predicted using a pre-built machine learning model; Determine the user's real-time risk level; Based on the user profile, real-time risk level, and current business data, a permission policy that meets the real-time permission requirements is dynamically generated through a rule engine. The permission policy includes at least the data fields that are allowed to be accessed and the operations that are allowed to be performed. In response to a data access request, the dynamic permission policy is applied for real-time authentication, and the query process is optimized based on a resource prediction model to return the dynamic allocation result of logistics permissions within the permission scope. Based on the dynamic allocation results of the logistics permissions, the user's logistics permissions are dynamically allocated.

[0005] According to another aspect of this application, a dynamic allocation device for logistics permissions is also disclosed, the device comprising: The data acquisition module is used to acquire target user behavior data and target business data; The user profile building module is used to build a user profile based on the target behavior data and the target business data. The user profile includes static attributes and dynamic behavior data. The real-time permission requirement prediction module is used to predict the real-time permission requirements of the target user based on the dynamic behavior data using a pre-built machine learning model. The real-time risk level determination module determines the user's real-time risk level. The permission policy determination module dynamically generates permission policies that meet the real-time permission requirements based on the user profile, real-time risk level, and current business data through a rule engine. The permission policy includes at least the data fields that are allowed to be accessed and the operations that are allowed to be performed. The dynamic allocation result determination module is used to respond to data access requests, apply the dynamic permission strategy for real-time authentication, and optimize the query process based on the resource prediction model to return the dynamic allocation result of logistics permissions within the permission range. The dynamic allocation module is used to dynamically allocate the user's logistics permissions based on the dynamic allocation results of the logistics permissions.

[0006] According to another aspect of this application, an electronic device is also disclosed, the electronic device including a memory and at least one processor, the memory storing instructions; the at least one processor invokes the instructions in the memory to cause the electronic device to perform the steps of the dynamic allocation method for logistics permissions as described in any of the preceding claims.

[0007] According to another aspect of this application, a computer-readable storage medium is also disclosed, wherein instructions are stored on the computer-readable storage medium, characterized in that, when executed by a processor, the instructions implement the various steps of the dynamic allocation method for logistics permissions as described in any of the preceding claims.

[0008] The present invention includes, but is not limited to, the following beneficial effects: (1) This solution systematically acquires two types of core data, namely behavior and business, to ensure that the input of all subsequent intelligent analysis is comprehensive, relevant and of high quality, so that the permission management is based on objective and real-time factual data, laying the foundation for data-driven decision-making; (2) By predicting the real-time permission needs of users, the proactive and intelligent allocation of permissions is realized, which improves business agility and user experience; (3) By calculating the risk level in real time, abnormal behavior can be responded to immediately. When predicting user needs, combined with risk assessment, stricter control is applied to effectively prevent internal threats and account theft, and achieve a balance between security and efficiency; (4) By using multi-factor fusion decision-making such as profile, risk, and scenario and context awareness to achieve fine-grained real-time decision-making, permission changes respond to changes in data and business in real time, and finally realize the automation, real-time and precise adjustment of permission allocation, which solves the pain points of rigid permissions, low data utilization, low query efficiency, high data security risk and insufficient multi-platform collaboration in traditional logistics systems. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0010] Figure 1 This is a flowchart of a logistics permission dynamic allocation method according to an embodiment of this application; Figure 2 This is another flowchart of the dynamic allocation method for logistics permissions in this application embodiment; Figure 3 This is another flowchart of the dynamic allocation method for logistics permissions in this application embodiment; Figure 4 This is another flowchart of the dynamic allocation method for logistics permissions in this application embodiment; Figure 5 This is another flowchart of the dynamic allocation method for logistics permissions in this application embodiment; Figure 6 This is another flowchart of the dynamic allocation method for logistics permissions in this application embodiment; Figure 7 This is another flowchart of the dynamic allocation method for logistics permissions in this application embodiment; Figure 8 This is a structural block diagram of the logistics permission dynamic allocation device according to an embodiment of this application; Figure 9 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0011] This invention provides a method, apparatus, device, and storage medium for dynamically allocating logistics permissions. The method includes acquiring target user behavior data and target business data; constructing a user profile based on the target behavior data and target business data, the user profile including static attributes and dynamic behavior data; predicting the real-time permission needs of the target user using a pre-built machine learning model based on the dynamic behavior data to determine the user's real-time risk level; dynamically generating a permission policy that meets the real-time permission needs using a rule engine based on the user profile, real-time risk level, and current business data, the permission policy including at least allowed data fields and allowed operations; responding to data access requests, applying the dynamic permission policy for real-time authentication; optimizing the query process based on a resource prediction model to return a dynamic allocation result of logistics permissions within the permission range; and dynamically allocating the user's logistics permissions based on the dynamic allocation result. This solution achieves automated, real-time, and precise adjustment of permission allocation, solving the pain points of low data utilization, low query efficiency, high data security risks, and insufficient multi-platform collaboration in traditional logistics systems.

[0012] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0013] For ease of understanding, the specific process of the embodiments of the present invention will be described below. Figure 1 A flowchart for a method of dynamically allocating logistics permissions, such as Figure 1 As shown, it includes the following steps: S100: Obtain target user behavior data and target business data.

[0014] Specifically, such as Figure 2The diagram shown is another flowchart of the dynamic allocation method for logistics permissions according to an embodiment of this application. This flowchart is an exemplary illustration of obtaining target user behavior data and business target data in this method. (See attached diagram.) Figure 2 It includes the following steps: S200: Collect initial user behavior data and initial business data from multiple heterogeneous data sources.

[0015] Specifically, such as Figure 3 The diagram shown is another flowchart of the dynamic allocation method for logistics permissions according to an embodiment of this application. This flowchart is an exemplary illustration of step S200 in this method, including the following steps: S300 identifies and defines multiple heterogeneous data sources used for logistics authorization decisions.

[0016] Among them, the various heterogeneous data sources include at least a first type of data source for collecting user behavior data and a second type of data source for collecting logistics business data.

[0017] Specifically, logistics companies' data is scattered across various business systems such as orders, warehousing, customers, and finance. Before making logistics access decisions, it is necessary to communicate with each business system, list all systems, databases, API interfaces, and log files that may contain relevant data, and take stock of and sort out the company's IT environment to identify a list of potential data sources.

[0018] The identified data sources are categorized, labeled, and specified. Specifically, the data sources are divided into two categories: a first category for collecting user behavior data and a second category for collecting logistics business data. The first category records user account activity traces within the system, such as user login logs, query audit logs, button click event streams, API call records, and session management logs. This data is used to build dynamic user behavior profiles and determine user intent and the risks associated with that intent. The second category records logistics business entities and their status and rules, such as waybill tables containing sender and receiver IDs, goods, and fees; customer master data tables; warehouse location tables; freight contract tables; and product category tables. This data is used to determine the current business scenario and whether the data is sensitive.

[0019] This step clarifies what data is needed and where the data should come from, providing a data foundation for the subsequent collection of user behavior data and business data.

[0020] S302. For the first type of data source and the second type of data source, determine the appropriate data acquisition tool or protocol according to their respective data types and access protocols, so as to establish a data acquisition channel corresponding to each type of data source.

[0021] Specifically, the first and second types of data sources differ fundamentally in their data characteristics and collection objectives. The first type of data source is typically an event stream, with a massive amount of data but a relatively simple record format, and high requirements for real-time performance. The second type of data source is typically a state snapshot, which may be associated with multiple systems, has a complex data structure, and may have a lower update frequency, but high requirements for consistency and integrity. These differentiated data characteristics dictate that this type of data cannot be collected using methods that collect static business tables. It is necessary to select collection tools or access protocols suitable for its data characteristics to establish data collection channels corresponding to different data sources. For example, for relational database tables, the collection tool needs to support SQL statement queries, JDBC, or ODBC; for server log files, Kafka messages, and other cascading / log data, the collection tool needs to support file end listening and streaming consumption; for API data such as JSON / XML returned by RESTful or gRPC interfaces, the collection tool needs to support HTTP clients, authentication, polling, or webhooks.

[0022] In one scenario, a logistics company's first data source is the access logs from the user order query API gateway. System evaluation indicates the data type is streaming JSON, a semi-structured format, and the access protocol is Kafka Consumer API. Therefore, the suitable data acquisition tool is Apache Flink's Kafka Connector, establishing a real-time streaming acquisition channel to consume and parse the logs in real time. The second data source is a waybill table stored in an Oracle database. System evaluation indicates the data type is structured table data, and the access protocol is JDBC. Therefore, the suitable acquisition tool is Debezium's Oracle Connector, establishing a CDC change log acquisition channel to capture additions, deletions, and modifications to the waybill table in real time and write them to a Kafka message queue.

[0023] By establishing efficient collection channels for behavioral data sources, instantaneous changes in user behavior can be captured in a timely manner, thereby triggering subsequent real-time risk assessments and policy adjustments. This provides technical support for dynamic permission allocation. At the same time, by establishing independent and suitable collection channels for each type of data source, decoupling and reuse are achieved. When a new data source is added in the future, it is only necessary to determine the appropriate collection tool and establish a new channel for it, without having to modify other existing channels and downstream processing logic. Furthermore, a single set of data can be used by multiple downstream processes simultaneously.

[0024] S304. Configure the acquisition parameters for each data acquisition channel to collect data related to permission decisions in a targeted manner.

[0025] Among them, the channels used to collect user behavior data shall have collection parameters including at least the source path of the user operation log, the user session identifier field, and the operation time field; the channels used to collect logistics business data shall have collection parameters including at least the waybill identifier, the user identifier involved, the cargo attributes, and the routing information. Specifically, targeted collection means collecting data with goals, selection, and filtering, rather than accepting everything. Targeted collection solves the problem of extracting high-value information from massive amounts of raw data, which is a prerequisite for improving the efficiency of subsequent processing and the accuracy of models. The basis for targeted collection is related to permission decisions. All configured collection parameters must serve to answer the core questions of permission decisions: who, under what circumstances, can perform what operations on what data. This step is the key link in the entire data collection process, moving from connectivity to accuracy and efficiency, ensuring that the collected data is useful, not invalid noise.

[0026] S306. Run each data acquisition channel and extract raw data from the corresponding heterogeneous data source according to the acquisition parameters.

[0027] S202. Perform data parsing on the initial user behavior data and initial business data respectively to obtain behavior parsing data and business parsing data.

[0028] Specifically, the system receives initial user data and initial business data, determines their data source type, and assigns the corresponding optimal parser based on the identified data type. The assigned parser then transforms the initial user data and initial business data stream into a unified structured data object within the system, namely, behavioral parsing data and business parsing data, according to the corresponding format specifications.

[0029] S204. A token bucket algorithm is used for flow control. Behavioral analysis data and business analysis data are input into the real-time processing pipeline and the batch processing pipeline respectively for mixed processing to generate preliminary standardized data. Specifically, the real-time processing pipeline uses the Apache Flink framework to perform windowed aggregation calculations on logistics trajectory and cost calculation stream data, while the batch processing pipeline uses Apache NiFi to periodically extract historical order and warehouse record data.

[0030] Specifically, during peak business periods, the rate of data inflow may surge instantly, exceeding the processing capacity of downstream real-time processing pipelines, leading to task overload, memory overflow, and even server crashes. In such cases, it is necessary to provide the system with a stable and predictable data processing throughput to prevent the impact of sudden traffic surges. The token bucket algorithm is employed, where the system generates tokens at a constant rate (e.g., 5000 QPS) and places them in a bucket. For each parsed record processed, a token is retrieved from and consumed from the bucket. Each parsed data entry must acquire a token to be allowed into the downstream channel. The token bucket has a limited capacity; during periods of low traffic, unused tokens accumulate in the bucket. When a sudden surge in traffic occurs, these accumulated tokens can be consumed all at once, allowing for a higher-than-average traffic flow for a short period. When the accumulated tokens are exhausted, and the surge in traffic exceeds the token generation rate, the bucket becomes temporarily short of tokens, and data must wait until new tokens are generated. This smooths the traffic flow while also accommodating burst processing capabilities, providing a reliable and stable data input rate for the subsequent real-time processing channels, ensuring a smooth, predictable, and controlled data flow.

[0031] The real-time processing pipeline uses the Apache Flink framework, which has high throughput computing capabilities, to process hot data whose value decays rapidly over time and requires immediate analysis, such as logistics trajectories and cost calculation stream data. Through windowed aggregation calculations, it generates low-latency real-time business data that reflects the latest status. The batch processing pipeline uses Apache NiFi to process historical order and warehouse record data that are large in volume, have low real-time requirements, but require accurate and complete calculations, i.e., warm / cold data. It extracts full or incremental data from the past 24 hours from the source database daily to generate comprehensive and accurate historical data snapshots and aggregation results.

[0032] S206. For the initially standardized data, perform intelligent cleaning and security desensitization processing in parallel to obtain initial preprocessed data.

[0033] Specifically, based on the 3σ principle, outliers in freight charges are identified. The system calculates the mean and standard deviation of historical freight charges in real time or in batches. For each order data to be processed, its freight charge value is checked. When the freight charge value of a single order exceeds the mean ± 3 times the standard deviation, the freight charge value of that order is marked as statistically abnormal, and a manual review process is triggered. Based on a pre-trained isolated forest model, logical errors in the timestamps of logistics nodes are identified by constructing isolated trees. Data cleaning ensures that the data input into subsequent models and decision engines is reliable and accurate.

[0034] A strategy combining static encryption and dynamic mask generation is adopted to securely anonymize the data, making the data usable but invisible. Sensitive information such as customer mobile phone numbers and ID card numbers are encrypted using the AES-256-GCM encryption algorithm before storage. The key is dynamically rotated by the Key Management Service (KMS). Before the data query results are returned to the user, the fields are filtered and formatted in real time according to the user's role and user permission tags by calling the predefined mask rules in the preset rule base.

[0035] By performing secure data anonymization, compliance requirements are met while ensuring the secure flow of data under access control, supporting business operations for different roles and achieving fine-grained data security.

[0036] S208. Standardize and transform the initial preprocessed data according to the predefined data model to generate target user behavior data and target business data.

[0037] S102. Based on the target behavior data and target business data, construct user profiles, which include static attributes and dynamic behavior data.

[0038] Specifically, dynamic user behavior features and static attributes are extracted from target behavioral data and target business data. Dynamic user behavior features mainly include recent login frequency, sensitive data query ratio, average session duration, behavioral sequence patterns, and other data that are updated in real time or periodically and reflect the user's latest status. Static attributes include relatively stable data with low change frequency, such as user role, company size, and years of service. The extracted dynamic behavior features and static attributes are transformed into readable and computable tags, and the tags and features are transformed into machine-readable feature vectors, i.e., user profiles.

[0039] S104. Based on dynamic behavior data, predict the real-time permission requirements of the target user through a pre-built machine learning model.

[0040] Specifically, dynamic behavioral data is processed from real-time updated user profiles to extract feature vectors required by the machine learning model. These feature vectors are then sent to a pre-trained machine learning model, which receives the features, runs its internal algorithm, and calculates the prediction results.

[0041] S106. Determine the user's real-time risk level.

[0042] Specifically, such as Figure 4 The diagram shown is another flowchart of the dynamic allocation method for logistics permissions according to an embodiment of this application. This flowchart is an exemplary illustration of step S106 in this method, including the following steps: S400: Real-time collection of multi-dimensional risk signals related to target users.

[0043] Risk signals include at least: real-time user behavior signals, including operation frequency, operation time, access sequence, and login environment information.

[0044] S402. The user's multi-dimensional risk signals and business context signals are fused with the static attribute features extracted from the user profile to generate a risk state feature vector that represents the overall risk state. Business context signals include the data sensitivity level and operation sensitivity level involved in the target user's current operation.

[0045] Specifically, step S400 completes the collection of multi-dimensional risk signals. However, these signals are discrete, heterogeneous, and cannot be directly understood by machine learning models. The collected multi-dimensional risk signals, business context signals, and quantifiable features are extracted from the user profile, normalized and scaled to scale features of different scales to the same range. Then, all the processed feature values ​​are concatenated and combined in a predefined and fixed order to generate a risk state feature vector.

[0046] S404. Input the risk status feature vector into a pre-trained risk assessment machine learning model to obtain the risk level label.

[0047] The risk assessment machine learning model is trained based on historical normal operation and security incident data.

[0048] S406. Map the risk level labels to standardized real-time risk levels.

[0049] S108. Based on user profiles, real-time risk levels, and current business data, dynamically generate permission policies that meet real-time permission requirements through the rule engine.

[0050] The permission policy should include at least the data fields that are allowed to be accessed and the operations that are allowed to be performed.

[0051] Specifically, user profiles define the requesting object, including static identity and dynamic behavioral patterns. For example, the profile of a finance specialist determines that the initial scope of the policy must revolve around financial data. Real-time risk levels provide the core security constraint of "whether or not to grant access." Even if the user profile and the request are the same, different risk levels will result in significantly different generated permission policies. For low-risk levels, a lenient and convenient policy may be generated, while for high-risk levels, even if the request is reasonable, enhanced authentication may be triggered, only anonymized data may be returned, or access may be directly denied. The current business scenario defines "under what circumstances." For the same request, in a daily operation scenario, the requester may see all information, while in a customer complaint handling scenario, the system may automatically correlate information. It also opens permissions for more fields such as related recordings and work orders. In month-end audit scenarios, it may temporarily open access to view historical modification logs to ensure that permissions are linked to specific business needs. User profiles, real-time risk levels, and current business data are input into the Drools rule engine to execute business rules such as if-then-else and calculate the final policy parameters. The permission policy includes at least the data fields that can be accessed and the operations that can be performed. The data fields that can be accessed implement column-level permission control. The policy will clearly list the name of every field that the user can see, while hiding sensitive fields and allowing operations define what can be done on the allowed fields. The combination of these two parts constitutes a highly precise permission space in both data and operation dimensions.

[0052] S110. In response to the data access request, apply a dynamic permission policy for real-time authentication, and optimize the query process based on a resource prediction model to return the dynamic allocation result of logistics permissions within the permission scope.

[0053] S112. Dynamically allocate users' logistics permissions based on the results of dynamic allocation of logistics permissions.

[0054] Specifically, such as Figure 5 The diagram shown is another flowchart of the dynamic allocation method for logistics permissions according to an embodiment of this application. This flowchart is an exemplary illustration of step S110 in this method, including the following steps: S500: In response to a data access request, extract a dynamic permission policy matching the current access request from the policy library based on the user identifier carried in the data access request and the context of the data access request.

[0055] Specifically, the system captures the user's original data access request at the API network management, application layer filter, or database proxy. It parses the verified user ID from the request's security context. If the request does not carry a valid identity, it directly returns "unauthorized" and terminates the process. A request context object is then constructed to encapsulate all metadata of the request, including at least the user ID, the target of the request, the attempted action, the request timestamp, the timestamp source, the user agent, and key business parameters in the request. The constructed context object is then converted into a set of policy retrieval keys for quickly querying the policy library. The generated policy retrieval keys and the complete context object are input into a pre-set policy template library. The policy library executes matching logic and outputs the matched dynamic permission policy based on the principle of first-match or best-match.

[0056] S502. The target data identifier and request operation type carried in the data access request are compared and authenticated in real time with the dynamic permission policy.

[0057] Specifically, key elements are extracted from the original access request to accurately identify the data and operations used for authentication; the matched dynamic permission policies are parsed to clarify the permitted data range and operation list from the matched policy objects; real-time comparison authentication is performed, including data range authentication and operation type authentication. Data range authentication determines whether the requested data identifier falls entirely within the permitted data range. This is a set inclusion relationship verification; if the requested data identifier falls entirely within the permitted data range, authentication passes; otherwise, the entire request is rejected. Operation type authentication determines whether the requested operation type exists in the permitted operation list. This is a set membership relationship verification; if the requested operation type exists in the permitted operation list, authentication passes; otherwise, authentication fails. Only when both data range and operation type authentications pass is the final comparison authentication allowed. Any failure results in immediate rejection. If authentication passes, the request is allowed and forwarded to the actual business processor or database. If authentication fails, the request is immediately terminated, a standardized error response is returned, and a detailed security audit log is recorded, including the user, time, request content, matched policy, and reason for authentication failure.

[0058] S504. If authentication is successful, computing resources are dynamically allocated to the data access request based on the current system load status determined by the resource prediction model, and the original query statement is optimized and rewritten according to the data range limited by the dynamic permission policy.

[0059] Specifically, if authentication is successful, appropriate computing resources are allocated to the current request based on the overall health of the system and the complexity of the request; the original query statement sent by the user from their perspective is rewritten into a secure optimized statement that the database can execute efficiently and is strictly limited to their permission scope: the original SQL is parsed into an abstract syntax tree using an SQL parser, the data range and operation range are extracted from the permission policy to rewrite the query statement, row-level and column-level filtering is performed, security conditions are injected, and optimization is performed based on the rewritten query.

[0060] S506. Execute the optimized query statement and obtain the data result set.

[0061] S508. Based on the field-level access control rules in the dynamic permission policy, filter and de-identify the data result set.

[0062] S510: The processed data results within the scope of permissions are used as the returned dynamic allocation results of logistics permissions.

[0063] In one instance, Figure 6 Another flowchart of the dynamic allocation method for logistics permissions according to an embodiment of this application includes the following steps: S600: Obtain the event data of permission policy change events and key data access operations to be certified, and serialize the event data into log data in a predetermined format.

[0064] Specifically, the system captures data on permission policy change events and key data access operation times in real time and without omission. The captured data information is then populated into data objects to construct structured event objects. These structured event objects are then transformed into compact byte sequences that conform to a predetermined pattern, i.e., log data in a predetermined format.

[0065] S602. Use a cryptographic hash function to calculate the log data and generate the corresponding first hash value.

[0066] Specifically, a cryptographically secure, collision-resistant one-way hash function is selected to perform the hash calculation. S604. Send the transaction data containing the first hash value and timestamp to the blockchain network so that the consensus nodes in the blockchain network can reach a consensus on the transaction, and append the block containing the transaction to the blockchain to form an immutable audit log.

[0067] Specifically, hash values ​​have the characteristics of uniqueness, sensitivity, and irreversibility. Two different logs will almost never have the same hash value. Even if only one punctuation mark is changed in the original log, its hash value will become unrecognizable, and the original log content cannot be deduced from the hash value. The transaction data containing the first hash value and timestamp is sent to the blockchain to generate a digital signature, and finally a signed transaction is obtained. The signed transaction is sent to the blockchain for notarization, and finally a consensus algorithm is run to form an immutable record, forming a digital evidence with legal effect.

[0068] In one instance, Figure 7 Another flowchart of the dynamic allocation method for logistics permissions according to an embodiment of this application includes the following steps: S700 collects operational feedback data and user interaction feedback data.

[0069] Collect user interaction feedback data, including user-submitted satisfaction ratings, complaints in permission request reasons, displayed feedback such as customer service tickets, and implicit feedback such as user behavior data.

[0070] S702. The running feedback data and user interaction feedback data are used as reward signals and input into the reinforcement learning model.

[0071] S704. Using a reinforcement learning model, iteratively optimize the rule logic of the real-time permission policy to generate an optimized permission policy.

[0072] S706. Update the previously implemented dynamic permission policy with the optimized permission policy.

[0073] Specifically, the current version of the rule logic is run in a real environment for a period of time to generate a large amount of trajectory data. The reinforcement learning model analyzes this trajectory data and calculates how much additional reward can be obtained when a slightly different rule parameter adjustment is adopted. Based on the calculated advantage, the model uses the gradient descent algorithm to make small and stable updates to the parameters of the rule logic along the direction that can increase the expected reward, and obtains the optimized permission policy. The optimized permission policy is then updated to the previous dynamic permission policy, and a new round of experience data is collected. The update is repeated to continuously approach the optimal permission policy.

[0074] Furthermore, Figure 8 This is a structural block diagram of the logistics permission dynamic allocation device according to an embodiment of this application, such as... Figure 8 As shown, the device includes: The data acquisition module is used to acquire target user behavior data and target business data; The user profile building module is used to build user profiles based on target behavior data and target business data. The user profiles include static attributes and dynamic behavior data. The real-time permission requirement prediction module is used to predict the real-time permission requirements of target users based on dynamic behavioral data and through a pre-built machine learning model. The real-time risk level determination module determines the user's real-time risk level. The permission policy determination module dynamically generates permission policies that meet real-time permission requirements based on user profiles, real-time risk levels, and current business data through a rule engine. The permission policy includes at least the data fields that are allowed to be accessed and the operations that are allowed to be performed. The dynamic allocation result determination module is used to respond to data access requests, apply dynamic permission policies for real-time authentication, and optimize the query process based on resource prediction models to return the dynamic allocation result of logistics permissions within the permission scope. The dynamic allocation module is used to dynamically allocate users' logistics permissions based on the dynamic allocation results of logistics permissions.

[0075] Furthermore, the data acquisition module includes: The user initial data acquisition unit is used to collect initial user behavior data and initial business data from multiple heterogeneous data sources; The data parsing unit is used to parse the initial user behavior data and initial business data respectively to obtain behavior parsing data and business parsing data. The data input unit is used to perform flow control using the token bucket algorithm. It inputs behavioral analysis data and business analysis data into the real-time processing pipeline and the batch processing pipeline respectively for mixed processing to generate preliminary data. The real-time processing pipeline uses the Apache Flink framework to perform windowed aggregation calculations on logistics trajectory and cost calculation stream data, while the batch processing pipeline uses Apache NiFi to periodically extract historical order and warehouse record data. The data cleaning and desensitization unit is used to perform intelligent cleaning and secure desensitization processing on the initially standardized data in parallel to obtain the initial pre-processed data; The standardization transformation unit is used to standardize and transform the initial preprocessed data according to a predefined data model to generate target user behavior data and target business data.

[0076] Furthermore, the user initial data acquisition unit includes: The multi-source heterogeneous data source identification and definition subunit is used to identify and define a variety of heterogeneous data sources for logistics authorization decisions, including at least a first type of data source for collecting user behavior data and a second type of data source for collecting logistics business data. The data acquisition tool determination subunit is used to determine the appropriate data acquisition tool or protocol for the first type of data source and the second type of data source, based on their respective data types and access protocols, so as to establish a data acquisition channel corresponding to each type of data source. The data acquisition parameter configuration subunit is used to configure the acquisition parameters for each data acquisition channel in order to collect data related to permission decisions in a targeted manner. Among them, the acquisition parameters of the channel used to collect user behavior data shall include at least the source path of the user operation log, the user session identifier field, and the operation time field; the acquisition parameters of the channel used to collect logistics business data shall include at least the waybill identifier, the user identifier involved, the cargo attributes, and the routing information. The data acquisition channel operation subunit is used to run each data acquisition channel and extract raw data from the corresponding heterogeneous data source according to the acquisition parameters.

[0077] Furthermore, in some embodiments, the real-time risk level determination module includes: The multi-dimensional risk signal acquisition unit is used to collect multi-dimensional risk signals related to the target user in real time; the risk signals include at least: real-time user behavior signals, including operation frequency, operation time, access sequence and login environment information; The feature fusion unit is used to fuse the user's multi-dimensional risk signals and business context signals with the static attribute features extracted from the user profile to generate a risk state feature vector that represents the comprehensive risk state. The business context signals include the data sensitivity level and operation sensitivity level involved in the target user's current operation. The feature vector input unit is used to input the risk state feature vector into the pre-trained risk assessment machine learning model to obtain the risk level label. The risk assessment machine learning model is trained based on historical normal operation and safety event data. Furthermore, in some embodiments, the dynamic allocation result determination module includes: The data access request response unit is used to respond to a data access request by retrieving a dynamic permission policy that matches the current access request from the policy library based on the user identifier and the context of the data access request carried in the data access request. The comparison and authentication unit is used to compare and authenticate the target data identifier and request operation type carried in the data access request with the dynamic permission policy in real time. The query statement optimization unit is used to dynamically allocate computing resources to data access requests based on the current system load status determined by the resource prediction model if authentication is successful, and to optimize and rewrite the original query statement according to the data range limited by the dynamic permission policy. The data result set acquisition unit is used to execute the optimized query statement and acquire the data result set. The data result set processing unit is used to filter and de-identify the data result set according to the field-level access control rules in the dynamic permission policy.

[0078] Furthermore, in some embodiments, the apparatus further includes: The predefined format log data acquisition module is used to acquire event data of permission policy change events and key data access operations to be certified, and serialize the event data into log data in a predefined format. The log data calculation module is used to calculate the log data using a cryptographic hash function to generate the corresponding first hash value; The audit log generation module is used to send transaction data containing a first hash value and a timestamp to the blockchain network so that the consensus nodes in the blockchain network can reach a consensus on the transaction and append the block containing the transaction to the blockchain to form an immutable audit log.

[0079] Furthermore, in some embodiments, the apparatus further includes: The feedback data acquisition module is used to collect operational feedback data and user interaction feedback data; The feedback data input module is used to input the running feedback data and user interaction feedback data as reward signals into the reinforcement learning model; The model optimization module is used to iteratively optimize the rule logic of the real-time permission policy using a reinforcement learning model to generate an optimized permission policy. The dynamic permission policy update module is used to update the existing dynamic permission policy with the optimized permission policy.

[0080] This solution systematically acquires two core data categories: behavioral and business data. This ensures that all subsequent intelligent analysis inputs are comprehensive, relevant, and of high quality, grounding access control in objective, real-time factual data and laying the foundation for data-driven decision-making. By predicting users' real-time access needs, it achieves proactive and intelligent access allocation, improving business agility and user experience. Through real-time risk level calculation, it can respond instantly to abnormal behavior. When predicting user needs, it combines risk assessment with stricter controls to effectively prevent internal threats and account theft, achieving a balance between security and efficiency. Through multi-factor fusion decision-making based on user profiles, risks, and scenarios, along with context awareness, it enables fine-grained real-time decision-making, ultimately achieving automated, real-time, and precise access control adjustments. This solves the pain points of traditional logistics systems, such as rigid access control, low data utilization, low query efficiency, high data security risks, and insufficient multi-platform collaboration.

[0081] The application of the relevant modules of the device in this example can be referred to the relevant introduction of the method principle above, and will not be repeated here.

[0082] above Figure 8 The dynamic allocation device for logistics permissions in this embodiment of the invention will be described in detail from the perspective of modular functional entities. The electronic device in this embodiment of the invention will be described in detail from the perspective of hardware processing.

[0083] Figure 9 This is a schematic diagram of the structure of an electronic device 900 provided in an embodiment of the present invention. The electronic device 900 can vary significantly due to different configurations or performance characteristics. It may include one or more central processing units (CPUs) 910 (e.g., one or more processors) and a memory 920, and one or more storage media 930 (e.g., one or more mass storage devices) for storing application programs 933 or data 932. The memory 920 and storage media 930 may be temporary or persistent storage. The program stored in the storage media 930 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the electronic device 900. Furthermore, the processor 910 may be configured to communicate with the storage media 930 and execute the series of instruction operations in the storage media 930 on the electronic device 900.

[0084] Electronic device 900 may also include one or more power supplies 940, one or more wired or wireless network interfaces 950, one or more input / output interfaces 960, and / or one or more operating systems 931, such as Windows Server, MacOSX, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 9 The illustrated electronic device structure does not constitute a limitation on electronic devices and may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0085] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the logistics permission dynamic allocation method.

[0086] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system, device, or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0087] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0088] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for dynamically allocating logistics permissions, characterized in that, The method includes: Acquire target user behavior data and target business data; Based on the target behavior data and the target business data, a user profile is constructed, which includes static attributes and dynamic behavior data. Based on the dynamic behavior data, the real-time permission requirements of the target user are predicted using a pre-built machine learning model; Determine the user's real-time risk level; Based on the user profile, real-time risk level, and current business data, a permission policy that meets the real-time permission requirements is dynamically generated through a rule engine. The permission policy includes at least the data fields that are allowed to be accessed and the operations that are allowed to be performed. In response to a data access request, the dynamic permission policy is applied for real-time authentication, and the query process is optimized based on a resource prediction model to return the dynamic allocation result of logistics permissions within the permission scope. Based on the dynamic allocation results of the logistics permissions, the user's logistics permissions are dynamically allocated.

2. The dynamic allocation method for logistics permissions according to claim 1, characterized in that, The acquisition of target user behavior data and target business data includes: Initial user behavior data and initial business data are collected from multiple heterogeneous data sources; The initial user behavior data and initial business data are parsed separately to obtain behavior parsing data and business parsing data. The token bucket algorithm is used for flow control. The behavior parsing data and the business parsing data are respectively input into the real-time processing pipeline and the batch processing pipeline for mixed processing to generate preliminary data. The real-time processing pipeline uses the Apache Flink framework to perform windowed aggregation calculations on logistics trajectory and cost calculation stream data, while the batch processing pipeline uses Apache NiFi to periodically extract historical order and warehouse record data. The initially standardized data is then subjected to parallel intelligent cleaning and secure desensitization processing to obtain initial preprocessed data. The initial preprocessed data is standardized and transformed according to a predefined data model to generate the target user behavior data and target business data.

3. The method for dynamically allocating logistics permissions according to claim 2, characterized in that, The collection of user behavior data and business data from multiple heterogeneous data sources includes: Identify and define multiple heterogeneous data sources for logistics authorization decisions, including at least a first type of data source for collecting user behavior data and a second type of data source for collecting logistics business data. For the first type of data source and the second type of data source, based on their respective data types and access protocols, determine the appropriate data acquisition tools or protocols to establish data acquisition channels corresponding to each type of data source; For each data acquisition channel, its acquisition parameters are configured to collect data related to permission decisions in a targeted manner; wherein, for the channel used to collect user behavior data, its acquisition parameters include at least the source path of the user operation log, the user session identifier field, and the operation time field; for the channel used to collect logistics business data, its acquisition parameters include at least the waybill identifier, the user identifier involved, the cargo attributes, and the routing information. Run each data acquisition channel and extract raw data from the corresponding heterogeneous data source according to the acquisition parameters.

4. The method for dynamically allocating logistics permissions according to claim 1, characterized in that, The determination of a user's real-time risk level includes: Real-time collection of multi-dimensional risk signals related to the target user; the risk signals include at least: real-time user behavior signals, including operation frequency, operation time, access sequence and login environment information; The user's multi-dimensional risk signals and business context signals are fused with static attribute features extracted from the user profile to generate a risk state feature vector that represents the overall risk state. The business context signals include the data sensitivity level and operation sensitivity level involved in the target user's current operation. The risk status feature vector is input into a pre-trained risk assessment machine learning model to obtain a risk level label, wherein the risk assessment machine learning model is trained based on historical normal operation and safety event data; The risk level labels are mapped to standardized real-time risk levels.

5. The method for dynamically allocating logistics permissions according to claim 1, characterized in that, The process of responding to a data access request, applying the dynamic permission strategy for real-time authentication, and optimizing the query process based on a resource prediction model to return the dynamic allocation results of logistics permissions within the permission scope includes: In response to the data access request, a dynamic permission policy matching the current access request is extracted from the policy library based on the user identifier carried in the data access request and the context of the data access request. The target data identifier and request operation type carried in the data access request are compared and authenticated in real time with the dynamic permission policy. If authentication is successful, computing resources are dynamically allocated to the data access request based on the current system load status determined by the resource prediction model, and the original query statement is optimized and rewritten according to the data range limited by the dynamic permission policy. Execute the optimized query statement and retrieve the data result set; The data result set is filtered and anonymized according to the field-level access control rules in the dynamic permission policy. The processed data results, within the scope of permissions, will be used as the returned dynamic allocation result of the logistics permissions.

6. The method for dynamically allocating logistics permissions according to claim 1, characterized in that, The method further includes: Obtain event data of permission policy change events and key data access operations to be certified, and serialize the event data into log data in a predetermined format; The log data is calculated using a cryptographic hash function to generate a corresponding first hash value; The transaction data containing the first hash value and timestamp is sent to the blockchain network so that the consensus nodes in the blockchain network can reach a consensus on the transaction and append the block containing the transaction to the blockchain to form an immutable audit log.

7. The method for dynamically allocating logistics permissions according to claim 1, characterized in that, After dynamically allocating the user's logistics permissions based on the logistics permission dynamic allocation result, the method further includes: Collect operational feedback data and user interaction feedback data; The operational feedback data and user interaction feedback data are used as reward signals and input into the reinforcement learning model. Using the reinforcement learning model, the rule logic of the real-time permission policy is iteratively optimized to generate an optimized permission policy; The optimized permission policy is then updated in the prior dynamic permission policy.

8. A dynamic allocation device for logistics permissions, characterized in that, The device includes: The data acquisition module is used to acquire target user behavior data and target business data; The user profile building module is used to build a user profile based on the target behavior data and the target business data. The user profile includes static attributes and dynamic behavior data. The real-time permission requirement prediction module is used to predict the real-time permission requirements of the target user based on the dynamic behavior data using a pre-built machine learning model. The real-time risk level determination module is used to determine the user's real-time risk level. The permission policy determination module is used to dynamically generate permission policies that meet the real-time permission requirements based on the user profile, real-time risk level and current business data through a rule engine. The permission policy includes at least the data fields that are allowed to be accessed and the operations that are allowed to be performed. The dynamic allocation result determination module is used to respond to data access requests, apply the dynamic permission strategy for real-time authentication, and optimize the query process based on the resource prediction model to return the dynamic allocation result of logistics permissions within the permission range. The dynamic allocation module is used to dynamically allocate the user's logistics permissions based on the dynamic allocation results of the logistics permissions.

9. An electronic device, characterized in that, The electronic device includes a memory and at least one processor, the memory storing instructions; the at least one processor invokes the instructions in the memory to cause the electronic device to perform the steps of the dynamic allocation method for logistics permissions as described in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instruction is executed by the processor, it implements each step of the dynamic allocation method for logistics permissions as described in any one of claims 1-7.

Images