A method, device, and storage medium for charging pile access control based on dynamic attributes.

Abstract

The application relates to the field of new energy automobile power supply, and provides a charging pile permission management method and device based on dynamic attributes and a storage medium, the method comprises the following steps: collecting a set of dynamic attributes related to a business request; generating a real-time permission decision instruction based on the set of dynamic attributes and a predetermined permission policy; performing corresponding operations according to the target object level of the real-time permission decision instruction, wherein if the target object is a device-level resource, a charging pile control operation corresponding to the real-time permission decision instruction is performed, and if the target object is a management node, a permission token distribution operation is performed; in the permission decision and execution process, the involved data is subjected to security processing; the permission decision and execution process is monitored and recorded to generate monitoring data, and an abnormal index is generated based on monitoring data analysis; an operation log is generated based on the monitoring data and is stored. The application can realize dynamic, accurate, safe and controllable management of charging pile permissions and full-process auditability.

Description

Technical Field

[0001] This application relates to the field of power supply for new energy vehicles, and in particular to a method, device and storage medium for managing the access rights of charging piles based on dynamic attributes. Background Technology

[0002] With the widespread adoption of new energy vehicles, charging piles, as a critical infrastructure, are experiencing continuous expansion in operational scale, with a surge in the number of connected users and devices. The charging process involves sensitive operations such as electricity trading, user payments, and equipment control, posing increasingly severe security challenges to the access control management of charging pile systems. An efficient and secure access control system must ensure equipment operation and data security while simultaneously considering user experience and operational efficiency. This places higher demands on the dynamism, granularity, and reliability of access control management.

[0003] Currently, most existing charging pile access control solutions grant permissions by pre-assigning static roles to users. While some solutions can make dynamic decisions based on attributes, in practice, these strategies are often relatively static, and the decision-making process is independent of subsequent command execution, security protection, and behavior monitoring, creating multiple "data silos." For example, commands generated by the access control decision engine may not be promptly perceived by the security module to take corresponding data protection measures, and operation logs recorded by the monitoring system may be difficult to use for effective audit analysis due to a lack of contextual association. In other words, existing technologies mainly suffer from rigid access control decision-making mechanisms, slow response times, difficulty in tracing and assigning responsibility for security incidents afterward, and a lack of a comprehensive, end-to-end data security and auditing mechanism. Summary of the Invention

[0004] This application provides a charging pile permission management method, device, and storage medium based on dynamic attributes, which can realize dynamic, accurate, secure and controllable management of charging pile permissions and ensure the auditability of the entire process.

[0005] On the one hand, this application provides a charging pile access control method based on dynamic attributes, the method comprising:

[0006] Collect dynamic attribute sets related to business requests;

[0007] Real-time permission decision instructions are generated based on the dynamic attribute set and the predetermined permission policy;

[0008] According to the target object level of the real-time permission decision instruction, the corresponding operation is executed. If the target object is a device-level resource, the charging pile control operation corresponding to the instruction is executed. If the target object is a management node, the permission token distribution operation is executed.

[0009] During the authorization decision-making and execution process, the data involved is handled securely.

[0010] Monitor and record the permission decision-making and execution process to generate monitoring data, and analyze and generate abnormal indicators based on the monitoring data;

[0011] Operation logs are generated and stored based on the monitoring data for audit analysis.

[0012] On the other hand, this application provides a charging pile access control device based on dynamic attributes, the device comprising:

[0013] The data collection module is used to collect dynamic attribute sets related to business requests;

[0014] The first generation module is used to generate real-time permission decision instructions based on the dynamic attribute set and the predetermined permission policy.

[0015] The execution module is used to perform corresponding operations according to the target object level of the real-time permission decision instruction. If the target object is a device-level resource, the charging pile control operation corresponding to the instruction is executed; if the target object is a management node, the permission token distribution operation is executed.

[0016] The security processing module is used to perform security processing on the data involved in the permission decision-making and execution process;

[0017] The monitoring module is used to monitor and record the permission decision and execution process to generate monitoring data, and to analyze and generate abnormal indicators based on the monitoring data;

[0018] The second generation module is used to generate and store operation logs based on the monitoring data for audit analysis based on the operation logs.

[0019] Thirdly, this application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the technical solution of the charging pile permission management method based on dynamic attributes as described above.

[0020] Fourthly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described charging pile permission management method based on dynamic attributes.

[0021] As can be seen from the technical solution provided in this application, on the one hand, by collecting dynamic attribute sets in real time and generating decision instructions based on predetermined permission policies, the permission decision-making process can fully consider the specific context of the current environment, thereby achieving more granular and practical dynamic permission control, effectively avoiding excessive or insufficient permission granting; on the other hand, by performing secure processing on sensitive data involved in the permission decision-making and execution process, security protection measures are deeply embedded in the core business process, rather than as an independent subsequent step, thus providing protection from the initial data generation stage and reducing the risk of sensitive data leakage during the process; thirdly, by monitoring and recording the entire process of permission decision-making and execution to generate monitoring data, and analyzing and generating abnormal indicators based on this data, continuous assessment of the system's security status and proactive discovery of potential risks can be achieved, providing a basis for timely intervention. Furthermore, generating and storing operation logs based on monitoring data provides a complete and reliable data foundation for subsequent audit analysis, enabling any operation to be traced and verified, significantly enhancing the system's accountability. In summary, the technical solution of this application can achieve dynamic, accurate, secure, and controllable management of charging pile permissions, and ensure the auditability of the entire process. Attached Figure Description

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

[0023] Figure 1 This is a flowchart of a charging pile access control method based on dynamic attributes provided in an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of the structure of the charging pile access control device based on dynamic attributes provided in the embodiments of this application;

[0025] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] In this specification, adjectives such as "first" and "second" are used only to distinguish one element or action from another, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element or component or step (etc.) should not be construed as being limited to only one of the elements, components, or steps, but may be one or more of the elements, components, or steps, etc.

[0028] For ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn to actual scale.

[0029] Currently, most existing charging pile access control solutions grant permissions by pre-assigning static roles to users. Alternatively, while dynamic decisions can be made based on attributes, in practice, these strategies are often relatively static, and the decision-making process is independent of subsequent command execution, security protection, and behavior monitoring, creating multiple "data silos." For example, commands generated by the access control decision engine may not be promptly perceived by the security module to take corresponding data protection measures, and operation logs recorded by the monitoring system may be difficult to use for effective audit analysis due to a lack of contextual association. Therefore, existing technologies mainly suffer from the following shortcomings: First, the access control decision-making mechanism is rigid, making it difficult to integrate multi-dimensional dynamic attributes for real-time and accurate access control calculations, and unable to adapt to complex and ever-changing charging environments. Second, there is insufficient coordination between access control decision-making and command execution, security processing, and monitoring auditing, resulting in process breaks and slow system response to security threats, making it difficult to trace and assign responsibility for security incidents afterward. Third, there is a lack of a fully integrated data security and auditing mechanism, making it difficult to ensure the immutability and verifiability of operation records while protecting data privacy.

[0030] To address the aforementioned problems in the existing technology, this application proposes a charging pile access control method based on dynamic attributes, the flowchart of which is attached. Figure 1 As shown, the main steps include S101 to S106, which are detailed below:

[0031] Step S101: Collect the dynamic attribute set related to the business request.

[0032] Existing technologies rely solely on static attributes (e.g., user identity) for decision-making, resulting in permission granting being disconnected from the current real-world environment. This can lead to misauthorization (e.g., granting charging permission to users with insufficient balances) or insufficient permission granting (e.g., failing to allocate fast-charging stations to high-priority vehicles), posing both security risks and impacting operational efficiency. In other words, traditional permission models depend on pre-assigned roles or static attributes, failing to respond to real-time changing contexts (e.g., sudden drops in user credit scores, abnormal charging station power, sudden peak electricity prices). To address the inherent contradiction between single-source permission decision-making, static attributes, and the ever-changing charging application environment, dynamic attributes can be collected related to business requests, including user status attributes, device operation attributes, and business request attributes. This approach provides the entire system with real-time, multi-dimensional perception capabilities, ensuring that permission decisions are based on the latest and most comprehensive environmental conditions, laying a data foundation for subsequent intelligent decision-making.

[0033] As an embodiment of this application, the aforementioned dynamic attribute set related to the collection of business requests can be: asynchronously acquiring multi-source heterogeneous data streams from user terminals, charging pile sensors, and business servers; performing confidence assessment and data fusion processing on the multi-source heterogeneous data streams to generate structured attribute data with timestamps and confidence labels, thus forming a dynamic attribute set; wherein, the confidence assessment and data fusion processing on the multi-source heterogeneous data streams to generate structured attribute data with timestamps and confidence labels can be specifically implemented as follows: automatically attaching a timestamp of its reception by the system to each data item of the multi-source heterogeneous data stream; calculating a confidence score for each data item with an attached timestamp based on a predefined set of assessment rules, the calculation process including: assigning a basic source reliability weight to the data item based on its source type; verifying whether the value of the data item is within its preset reasonable value range, and generating a logical reasonableness assessment. The process involves: analyzing the degree of abrupt change of a data item relative to its historical data sequence and generating a time-series consistency score; calculating a comprehensive confidence score for the data item based on the reliability weight of the underlying source, the logical rationality score, and the time-series consistency score; classifying and associating data items with timestamps and comprehensive confidence scores according to their corresponding entity objects and attribute types, and converting heterogeneous data of different formats into standardized data formats; for multiple data items belonging to the same entity object and the same attribute type, performing a weighted fusion calculation based on their respective comprehensive confidence scores to generate a fused final attribute value, and calculating the overall confidence of the final attribute value based on the confidence scores of each data item participating in the fusion; combining the fused final attribute value, its corresponding overall confidence, and the associated timestamp information to generate a structured attribute data with a confidence label, and outputting it to the dynamic attribute set.

[0034] Step S102: Generate real-time permission decision instructions based on the dynamic attribute set and the predefined permission policy.

[0035] As mentioned earlier, existing permission decision-making mechanisms are rigid, making it difficult to integrate multi-dimensional dynamic attributes for real-time and accurate permission calculation, and unable to adapt to complex and ever-changing charging environments. These shortcomings stem from the fact that existing solutions mostly employ simple "if-then" static rules, thus failing to resolve the contradiction between fixed and rigid permission calculation logic and the need for intelligent balancing of multiple factors. To achieve intelligent conversion from raw data to executable instructions, thereby realizing accurate and dynamic permission control, this application can generate real-time permission decision instructions based on a dynamic attribute set and predetermined permission policies. These predetermined permission policies can be a hybrid strategy that integrates role-based access control (RBAC) and attribute-based access control (ABAC).

[0036] Corresponding to the predetermined permission policy, which is a hybrid policy integrating RBAC and ABAC, as an embodiment of this application, the generation of real-time permission decision instructions based on the dynamic attribute set and the predetermined permission policy can be achieved through steps S1021 to S1023, as detailed below:

[0037] Step S1021: Generate a basic permission set by matching the user's identity from the RBAC role permission template, and mark the reliability of the basic permission set based on the confidence label.

[0038] In this embodiment, the basic permission set includes a predefined set of permissions bound to the user's identity (role). These permissions are typically coarse-grained operation permissions, such as operation permissions, access permissions, and resource permissions, etc. It should be noted that the term "basic permission set" is used because, on the one hand, in the RBAC+ABAC hybrid model, RBAC plays a primary role, quickly granting the user an initial, coarse-grained permission range based on the user's most core and stable attribute—identity (Role). This permission set serves as the basis and input for subsequent fine-grained dynamic decisions by ABAC. On the other hand, ABAC subsequently modifies, scales, or activates this "basic permission set" based on dynamic environmental attributes (e.g., time, location, device status, etc.). For example, RBAC grants the user the basic permission to "start charging," but ABAC will decide whether to actually allow the start based on the current electricity price (a dynamic attribute). Therefore, the permissions generated by RBAC are static and basic, while the final instructions generated by ABAC are dynamic and real-time.

[0039] As an embodiment of this application, the specific implementation of marking the reliability of the basic permission set based on confidence labels can be as follows: determine the core dynamic attribute set on which the basic permission set depends according to a predefined mapping rule; extract the confidence labels corresponding to the core dynamic attributes from the core dynamic attribute set; calculate the overall reliability score of the basic permission set based on the extracted multiple confidence labels using a predefined aggregation algorithm (e.g., taking the minimum value, calculating the arithmetic mean, or calculating the weighted average, etc.); and bind and mark the calculated overall reliability score as metadata with the basic permission set to obtain the basic permission set with reliability labels.

[0040] Step S1022: Input the basic permission set with reliability tags and structured attribute data into the ABAC policy engine.

[0041] Step S1023: Load dynamic constraint rules linked to the environment state through the ABAC policy engine, perform multi-attribute fusion calculation based on game theory weighted strategy, and output real-time permission decision instructions and decision confidence.

[0042] In this embodiment, the dynamic constraint rules linked to environmental states are policy rules in the ABAC policy engine whose judgment logic or parameters can be automatically adjusted according to changes in the external environmental state. These include time-related rules (e.g., "During off-peak electricity pricing at night (time state), VIP users (roles) are allowed to reserve charging permissions (permissions)"), system load-related rules (e.g., "When the grid load is higher than threshold X (environmental state), the power permissions of all charging piles are dynamically reduced by 20%)), security situation-related rules (e.g., "When a high level of network attack threat is detected (environmental state), all remote management commands require secondary authentication (constraints)"), and business activity-related rules (e.g., "During large-scale events held in business districts (environmental state), surrounding charging stations suspend off-peak permissions for non-vehicle owners (permissions)"), and so on. It should be noted that the "linkage" in "dynamic constraint rules linked to environmental states" means that the triggering conditions or parameters in the execution results of these rules (e.g., threshold X, reduction rate of 20%) are obtained from real-time environmental data, rather than pre-written fixed values.

[0043] As an embodiment of this application, the specific implementation of multi-attribute fusion calculation based on game theory weighted strategy can be as follows: construct a game model with the goals of permission granting security, business processing efficiency and user satisfaction; use the dynamic attribute set as the strategy input of the game participants, and dynamically allocate the weight of each attribute by calculating the Nash equilibrium point; and dynamically modify and resolve the basic permission set according to the weighted attribute weights and dynamic constraint rules. The specific implementation of "using a dynamic attribute set as the strategy input for game participants and dynamically allocating the weights of each attribute by calculating the Nash equilibrium point" in the above embodiment can be as follows: Define each attribute in the dynamic attribute set as a game participant; the dynamic attribute set includes multiple attributes used for permission evaluation; define a strategy set for each attribute participant, where the strategies in the strategy set are candidate allocation schemes for the weight values ​​of that attribute; construct a utility function for each attribute participant based on a preset permission evaluation objective, where the utility function measures the quality of the overall permission evaluation result under the strategy of that attribute participant; construct a non-cooperative game model based on the strategy sets and utility functions of all attribute participants; calculate the Nash equilibrium point of the non-cooperative game model, where the Nash equilibrium point corresponds to a set of stable weight allocation schemes; extract the attribute weight values ​​corresponding to the Nash equilibrium point as the final dynamically allocated weights in the current environment.

[0044] As another embodiment of this application, the specific implementation of multi-attribute fusion calculation based on game theory weighted strategy can also be as follows: Construct a multi-objective game model, abstracting the predetermined permission strategy into a game between multiple participants (i.e., multiple decision objectives, such as security objectives, efficiency objectives, economic objectives, and user experience objectives); define a strategy set (usually expressed as different execution preferences for ABAC environment constraint rules) and its payoff function for each decision objective; for example, the payoff function of the security objective is negatively correlated with the "operational risk coefficient," and the payoff function of the efficiency objective is negatively correlated with the "decision delay"; and dynamically set the attribute set... Using a basic set of permissions with reliability labels as the input state of the game, the optimal weight allocation scheme that enables all objectives to achieve balance under the current environment is dynamically solved by calculating the Nash equilibrium point. This means assigning weights to each decision objective. The basic permission set contains multiple permissions and their corresponding initial reliability scores. Based on the solved optimal weights, multiple environmental constraint rules are subjected to weighted logical operations to dynamically modify and resolve conflicts in the basic permission set. Finally, an optimal permission decision instruction and its decision confidence (which can be calculated based on the stability of the game equilibrium or the consensus of the weight allocation) are output. The specific implementation of "using the dynamic attribute set and the basic permission set with reliability labels as the input state of the game, and dynamically solving the optimal weight allocation scheme that enables all objectives to achieve balance in the current environment by calculating the Nash equilibrium point" in the above embodiment can be as follows: Define two game participants: the first participant represents the security objective, and the second participant represents the efficiency objective; use the dynamic attribute set and the basic permission set with reliability labels as the initial state of the game; define the strategy of the first participant as proposing a weight allocation scheme that tends to improve the reliability of permissions for the dynamic attribute set; define the strategy of the second participant as: for the dynamic attribute set, propose a weight allocation scheme that tends to improve the reliability of permissions. This paper proposes a weight allocation scheme that tends to maintain or improve the efficiency of permission evaluation. A first utility function is constructed for the first participant, whose value increases with the reliability of the final permission. A second utility function is constructed for the second participant, whose value increases with the efficiency of permission evaluation. Based on the policy sets and utility functions of the two participants, a multi-objective non-cooperative game model is constructed. The Nash equilibrium point of the multi-objective non-cooperative game model is calculated, representing the optimal state when the security and efficiency objectives are balanced. The weight allocation scheme corresponding to the Nash equilibrium point is extracted as the optimal weight allocation for the dynamic attribute set and used for the final permission evaluation calculation.

[0045] As can be seen from steps S1021 to S1023 of the above embodiments, on the one hand, by using a hybrid strategy of RBAC and ABAC, the simplicity and stability of RBAC in management (quick generation of basic permissions) are utilized, while the flexibility and fine granularity of ABAC (dynamic adjustment) are absorbed, overcoming the limitations of a single model. The introduction of a confidence-based reliability label enables the decision engine to know the reliability of the data on which the current decision is based, thereby providing a basis for triggering additional verification for high-risk decisions and enhancing the robustness of the system. On the other hand, by using a game theory-based weighted strategy, potentially conflicting decision objectives (e.g., security first vs. user experience first) from different business departments (e.g., security, operations, customer service, etc.) are incorporated into a unified mathematical model for automatic optimization, thereby making the most reasonable trade-off decision in complex scenarios, rather than a simplistic "one-size-fits-all" approach.

[0046] Step S103: Execute the corresponding operation according to the target object level of the real-time permission decision instruction. If the target object is a device-level resource, execute the charging pile control operation corresponding to the real-time permission decision instruction. If the target object is a management node, execute the permission token distribution operation.

[0047] If, as with existing technologies, instructions are executed indiscriminately on all target objects, it may lead to incorrect instruction delivery (e.g., sending management instructions to a charging pile that it cannot understand), or cause instruction storms and network congestion, reducing system reliability and efficiency. Considering that charging pile systems are typically heterogeneous layered architectures (platform-operator-site-charging pile), requiring different instruction execution mechanisms, this application, to ensure that the permission decision instructions generated by intelligent decision-making can accurately and efficiently act on the target object—that is, to achieve precise matching between real-time permission decision instructions and execution interfaces, and to guarantee the effectiveness of permission management—can execute corresponding operations based on the target object level of the real-time permission decision instructions. Specifically, if the target object is a device-level resource, then the charging pile control operation corresponding to the real-time permission decision instruction is executed; if the target object is a management node, then the permission token distribution operation is executed. Without loss of generality, as one embodiment of this application, the corresponding operation performed according to the target object level of the real-time permission decision instruction may be: parsing the real-time permission decision instruction and its decision confidence level; when the decision confidence level is lower than a first preset threshold, triggering a manual review process and pausing execution; when the decision confidence level is higher than or equal to the first preset threshold, triggering the execution interface corresponding to the target object level identifier according to the predefined target object level identifier-operation mapping relationship.

[0048] Specifically, as an embodiment of this application, if the target object is a device-level resource, the charging pile control operation corresponding to the real-time permission decision instruction can be performed as follows: adaptively selecting the redundancy check level of the control instruction based on the decision confidence level; converting the real-time permission decision instruction into a control command set conforming to the target charging pile communication protocol; distributing the control command set to the target charging pile in batches through the security-enhanced device control interface, and monitoring the instruction execution status in real time. If the execution fails, a rollback process based on the decision log is initiated according to the selected redundancy check level. It should be noted that the redundancy check level in the above embodiment refers to the security check strength before the real-time permission decision instruction is issued, such as low redundancy check (i.e., only basic format check is performed), medium redundancy check (i.e., digital signature verification is added), or high redundancy check (i.e., on the basis of the former two, a two-way handshake confirmation with the device is added), etc. Since a high redundancy check level should be selected if the decision confidence level is low, and high redundancy check increases the complexity and failure probability of instruction execution, a rollback process based on the decision log can be initiated according to the selected redundancy check level after the real-time monitoring instruction execution fails.

[0049] As an embodiment of this application, if the target object is a management node, the permission token distribution operation can be performed by: generating a traceable permission token containing the validity period of the permission, the scope of operation, the dynamic environment fingerprint and the digital signature; distributing the traceable permission token to the next-level management node or device through a secure communication link based on quantum key distribution; and dynamically verifying the validity of the traceable permission token each time it is used, based on the current environment attributes.

[0050] Step S104: During the permission decision-making and execution process, perform security processing on the data involved.

[0051] If the generated data is encrypted after the operation is completed, a security delay will occur, and sensitive data is at risk of leakage during the gap between generation, transmission, and processing. To achieve deep coupling and internalization of security measures with business processes—that is, to "shift" security processing to the left and integrate it into core processes—and achieve immediate protection of sensitive data, thereby shortening the data exposure window and fundamentally improving the system's security level, this application can perform security processing on the data involved in the permission decision-making and execution process. Specifically, as an embodiment of this application, security processing of the data involved in the permission decision-making and execution process can be as follows: identifying structured and unstructured sensitive data generated during the execution of charging pile control operations or the distribution of permission tokens; dynamically selecting and loading appropriate de-identification algorithms to process the identified sensitive data according to the data's sensitivity level and the context of the real-time permission decision instruction; wherein, the implementation of dynamically selecting and loading appropriate de-identification algorithms to process the identified sensitive data according to the data's sensitivity level and the context of the real-time permission decision instruction can specifically be as follows: identifying the specific type of sensitive data (e.g., personal information) according to a predefined data classification strategy. The system identifies sensitive data (such as identity information, payment information, device location information, etc.) and their sensitivity levels (e.g., high, medium, low); based on the context information of real-time permission decision instructions (including operation type, target object level, and decision confidence level), it matches applicable desensitization strategies from a predefined desensitization strategy library. Each desensitization strategy defines the desensitization algorithm (e.g., generalization, hashing, masking, encryption, etc.) and its parameters (e.g., hash salt value, mask character, etc.) to be used for different sensitivity levels and types of data. According to the matched desensitization strategy, the system dynamically loads the corresponding desensitization algorithm component into memory and calls the algorithm component, using the parameters to process the identified sensitive data.

[0052] In the current technology for power supply in new energy vehicles, the most common method for protecting sensitive data such as payment information is overall encrypted storage. This involves encrypting the complete payment data (e.g., credit card number, transaction amount) once (e.g., using the AES-256 algorithm) and then storing the entire ciphertext in a centralized database. Because the encrypted data is stored as a single, complete unit, if an attacker breaks into the database and steals the ciphertext, or even obtains the encryption key in some way, the entire payment information will be completely exposed. Therefore, the current technology is an "all-or-nothing" risk model, with extremely high costs for failed defenses. Furthermore, the centralized database, due to its storage of a large amount of high-value payment information, itself becomes a "honeypot" for hackers, greatly increasing the risk of attack. Therefore, to address the deeper security issue of how to further reduce the actual risks of data leakage on top of encryption, the above embodiments further include the following secure processing of the data involved in the permission decision-making and execution process: dynamically dividing the anonymized payment information data into multiple data fragments based on its data characteristics; independently generating encryption keys for each data fragment and encrypting each fragment using different encryption algorithms; distributing and storing the encrypted data fragments and their corresponding key fragments on different geographically based storage nodes, and recording the fragment mapping relationship in a secure metadata pool; wherein, the specific implementation of dynamically dividing the anonymized payment information data into multiple data fragments based on its data characteristics is detailed below. The process can be as follows: Analyze the structural and content characteristics of the anonymized payment information data. The structural characteristics include data length and field types, while the content characteristics include data entropy and key field distribution. Based on the analysis results, and combined with predefined segmentation rules, dynamically determine the segmentation strategy. This strategy includes the number of fragments, the location of segmentation points, and whether to use redundant segmentation. Based on the determined segmentation strategy, call the corresponding segmentation algorithm (e.g., fixed-length segmentation, delimiter-based segmentation, or content-sensitivity-based adaptive segmentation) to segment the payment information data, generating multiple data fragments. It should be noted that the security metadata pool in the above embodiment is defined as a centralized security information management and indexing system. Essentially, it is a secure database or knowledge base used to store and manage all metadata related to data security (i.e., data about data), rather than the original data itself.A security metadata pool typically includes data shard mapping relationships (which record which storage node in which geographical location the encrypted data shards are stored), key management information (i.e., the index information for storing key shards (note that it does not directly store the keys themselves), access control policies (access control policies define which system components or roles have the right to access which metadata), security audit trails (security audit trails record access logs to the metadata itself for secondary auditing), and blockchain hash pointers, etc.

[0053] As can be seen from the above embodiments, by constructing a defense-in-depth system through sharded encrypted distributed storage, even if an attacker successfully compromises a storage node, they can only obtain one or more meaningless data shards (e.g., just an encrypted, incomplete string). Due to the lack of other shards and corresponding keys, the attacker cannot recover any original payment information with actual value, thus greatly reducing the actual damage caused by a single security incident. On the other hand, payment information data is decomposed into multiple fragments and stored in different geographical locations, with no single storage node storing complete data, thereby eliminating the "honeypot" effect. Attackers cannot gain huge benefits by breaching a single point. Furthermore, due to the construction of de-identification, sharding, algorithm-based encryption, distributed storage, and mapping relationship isolation (storing the "map" of shard location relationships separately in a secure metadata pool), if an attacker wants to completely steal data, they need to compromise multiple systems simultaneously, increasing the difficulty exponentially.

[0054] Step S105: Monitor and record the permission decision and execution process to generate monitoring data, and analyze the monitoring data to generate abnormal indicators.

[0055] Traditional auditing often relies on static analysis of logs after an incident, a passive response model that fails to provide real-time insight into abnormal behavior and lacks proactive warning and intervention capabilities. To address the contradiction between opaque system operation and passive response versus the need for proactive warning and self-monitoring, this application monitors and records permission decisions and execution processes to generate monitoring data. Based on this data analysis, it generates anomaly indicators. Thus, through continuous monitoring and analysis, deviations from normal patterns can be detected immediately, and anomaly indicators provide a basis for proactive defense decisions, enabling the system to evolve from "passive response" to "proactive immunity." As one embodiment of this application, monitoring and recording the permission decision and execution process to generate monitoring data can be achieved by: synchronously collecting user operation behavior data, permission command data, and device response data, and injecting decision context data generated by the ABAC strategy engine; constructing a four-dimensional real-time monitoring matrix, wherein the four dimensions of the four-dimensional real-time monitoring matrix include user, command, device, and decision context; and generating a multimodal behavior stream with time-series labels and association identifiers based on the four-dimensional real-time monitoring matrix. Specifically, the specific implementation of generating a multimodal behavior stream with time-series labels and association identifiers based on the four-dimensional real-time monitoring matrix can be as follows: based on a unified timestamp and transaction ID, associating and aligning data from the four dimensions of user, command, device, and decision context to ensure that data for the same event in different dimensions can be correctly aggregated; encapsulating the associated data into basic behavior event units according to the time sequence; each behavior event unit includes event content, timestamp, source dimension, and association identifier; arranging the behavior event units in chronological order and injecting association identifiers describing the causal relationship between events to generate a continuous multimodal behavior data stream with time sequence and association relationships.

[0056] As one embodiment of this application, generating anomaly indicators based on monitoring data analysis can be as follows: inputting the current multimodal behavior flow into a pre-trained dynamic behavior profile model, calculating the deviation between the current multimodal behavior flow and historical normal behavior patterns; performing joint analysis based on the deviation and decision confidence to generate a comprehensive anomaly coefficient; when the comprehensive anomaly coefficient exceeds a preset threshold, generating a tiered alarm instruction and triggering an adaptive circuit breaker mechanism to restrict associated operations; here, the pre-trained dynamic behavior profile model is generated through unsupervised learning of normal operation patterns in historical monitoring data using machine learning, and its update cycle is linked to the update cycle of the permission policy. As for the joint analysis based on the deviation and decision confidence to generate a comprehensive anomaly coefficient, the specific implementation can be as follows: Map the deviation and decision confidence to a unified numerical range (e.g., between 0 and 1) to eliminate dimensional differences and make them comparable; based on the current security situation level (e.g., normal, attention, warning) and the criticality of the operation, adaptively allocate the weights of the deviation and decision confidence in this joint analysis using a predefined weight allocation strategy. For example, under a high security situation, the weight of behavioral deviation increases; for critical operations, the weight of decision confidence increases; according to the adaptively allocated weights, perform a weighted calculation on the standardized deviation and decision confidence to generate a comprehensive anomaly coefficient. The weighted calculation can use one of the following formulas: 1) Weighted product formula, i.e., Comprehensive anomaly coefficient = ,in, and These are the weights for deviation and low confidence in the decision, respectively. and These represent the deviation degree and the low confidence level of the decision, respectively. The lower the decision confidence level, the worse the reliability of the dynamic attribute set on which the authority decision is based, or the greater the conflict of policy rules. This is itself an inherent signal that there is anomaly or high risk in the system's decision-making process; 2) Weighted comprehensive formula, that is, comprehensive anomaly coefficient = α Standardized deviation+ β *(1-standardized decision confidence level), where, α and β These are dynamic weighting coefficients, and α + β =1; Output the calculated comprehensive anomaly coefficient and pass it to the subsequent alarm and circuit breaker mechanism.

[0057] Step S106: Generate and store operation logs based on monitoring data for use in audit analysis based on operation logs.

[0058] In existing technologies, logs are often stored in centralized databases, which poses a risk of single-point tampering or deletion. Their authenticity and integrity are difficult to guarantee, resulting in insufficient credibility of audit results and rendering them unusable as valid legal or accountability evidence. To provide an immutable chain of evidence, ensuring that any operation is traceable and verifiable, and thus resolving the contradiction between the ease of tampering and the difficulty in ensuring the reliability of operation records and the high reliability required for auditing and accountability, this application can generate and store operation logs based on monitoring data for use in operation log-based audit analysis.

[0059] Specifically, as an embodiment of this application, generating and storing operation logs based on monitoring data can be achieved by: extracting key operation events, execution results, context attributes, and sharding mapping relationships from the monitoring data; organizing and packaging the extracted information using a Merkle tree structure to generate log blocks, wherein the header of the log block contains a hash pointer to the previous log block on the blockchain; submitting the log blocks to a permissioned blockchain network jointly maintained by charging pile operators and regulatory agency nodes; verifying and storing the log blocks based on a distributed consensus algorithm using majority voting; and feeding back the hash of the block with successful consensus to the security metadata pool. The specific implementation of "verifying and storing the distributed consensus algorithm based on majority voting and feeding back the hash of the consensus-successful block to the security metadata pool" in the above embodiment can be as follows: The log block is broadcast to all consensus nodes in the permissioned blockchain network composed of charging pile operator nodes and regulatory agency nodes; the master node of the current round receives the log block, verifies its legality, assigns a unique sequence number to the log block after verification, and generates a pre-preparation message containing the sequence number and log block hash, which is then broadcast to all replica nodes; each replica node receives the pre-preparation message, verifies its digital signature, whether the sequence number is consecutive, and whether the log block hash matches the received log block content; if the verification is successful, proceed to the next step; the replica node generates a preparation message and broadcasts it to all other nodes in the network, wherein the preparation message contains the sequence number and log block hash it recognizes; each node collects preparation messages from other nodes; when a node collects preparation messages for the same sequence number and log block hash... When the number of valid preparation messages exceeds the first preset threshold (usually 2f, where f is the tolerable number of malicious nodes), a preparation certificate is considered to have been formed, indicating that the network has reached a preliminary consensus on the order of log blocks, and the node enters the next stage. The node generates a commit message (which confirms that it has received sufficient preparation messages and promises to persistently store the log block) and broadcasts this commit message to all other nodes, while starting to collect commit messages from other nodes. When a node collects more than the second preset threshold (usually 2f+1) of valid commit messages for the same sequence number and log block hash, a commit certificate is considered to have been formed, indicating that the network has reached a final consensus. The node then formally writes the log block into its local immutable storage. After completing local storage, each consensus node returns the block hash value (i.e., the unique fingerprint of the block) corresponding to the log block that achieved successful consensus to the secure metadata pool for associated storage, thereby establishing a verifiable link between the blockchain evidence and the original secure metadata.

[0060] As another embodiment of this application, generating and storing operation logs based on monitoring data can also be achieved through the following steps S1061 to S1065:

[0061] Step S1061: The monitoring agent extracts key operation events, execution results, context attributes, and data sharding mapping relationships from the security metadata pool from the monitoring data. It combines this information to generate a raw log event, uses a secret sharing algorithm to divide the raw log event into N encrypted shards, and distributes the different encrypted shards to M different log audit participants, where M is less than or equal to N.

[0062] Step S1062: After receiving its ciphertext fragment, each log audit participant inputs it into its local trusted execution environment to digitally sign the ciphertext fragment, generating a signed ciphertext fragment. The trusted execution environment is based on its built-in cryptographic key.

[0063] Step S1063: The designated coordinator initiates a log verification request. Without reconstructing the original log event, each log audit participant executes a pre-agreed multi-party secure computation protocol based on its own signed ciphertext fragments. The multi-party secure computation protocol is configured to achieve the following computational objectives: a) verify the validity of the digital signatures of each ciphertext fragment to authenticate the authenticity and integrity of the source of each fragment; b) collaboratively compute and generate the cryptographic hash value of the entire original log event based on all fragments; c) generate a multi-party joint digital signature for the calculated hash value.

[0064] Step S1064: Combine the cryptographic hash value calculated in step S1063 with its corresponding multi-party joint digital signature to generate a global log integrity certificate. After associating the global log integrity certificate with a unique serial number, publish it to a public lightweight index service.

[0065] Step S1065: Each log audit participant independently stores its signed encrypted fragments in its local secure storage module.

[0066] After each log audit participant independently stores its signed encrypted fragments in its local secure storage module, when an audit is required, the auditor obtains the sequence number of the target log and its corresponding global log integrity certificate from the public lightweight index service; the auditor collects the signed encrypted fragments stored by at least K log audit participants (K is the threshold set by the secret sharing algorithm); using the collected fragments, the auditor performs the following operations: a) verifying the signature of each fragment; b) if the verification passes, reconstructing the original log event; c) calculating the hash value of the reconstructed original log event and comparing it with the hash value in the global log integrity certificate obtained from the index service; if the two match, it proves that the log has not been tampered with since its generation, and the verification passes.

[0067] As for audit analysis based on operation logs, its specific implementation can be as follows: In response to audit instructions or abnormal indicators, obtain relevant operation logs and data shard mapping relationships from the permissioned blockchain network and security metadata pool; reconstruct the original operation data based on the mapping relationship, and reconstruct a complete and verifiable operation path topology from permission decision generation to instruction execution completion; perform semantic analysis on the operation path topology based on predefined compliance policies, and automatically generate a machine-readable audit compliance report with digital signatures; wherein, performing semantic analysis on the operation path topology based on predefined compliance policies can be as follows: verify whether the permission decision instructions at each stage of the operation path have passed the legality verification of the ABAC policy engine, and verify whether their decision confidence level matches the final execution result; based on the reconstructed original operation data, verify whether the entire process of sensitive data processing complies with desensitization and encryption rules, and output data security compliance proof.

[0068] From the above appendix Figure 1 The example of a dynamic attribute-based charging pile access control method demonstrates several advantages. First, by collecting dynamic attribute sets in real time and generating decision instructions based on predetermined access policies, the access decision-making process can fully consider the specific context of the current environment, thereby achieving more granular and practically tailored dynamic access control, effectively preventing excessive or insufficient access grants. Second, by securely processing sensitive data involved in access decision-making and execution, security measures are deeply embedded in core business processes, rather than as a separate subsequent step, providing protection from the outset and reducing the risk of sensitive data leakage during the process. Third, by monitoring and recording the entire process of access decision-making and execution to generate monitoring data, and analyzing and generating anomaly indicators, continuous assessment of system security status and proactive discovery of potential risks can be achieved, providing a basis for timely intervention. Furthermore, generating and storing operation logs based on monitoring data provides a complete and reliable data foundation for subsequent audit analysis, enabling any operation to be traced and verified, significantly enhancing system accountability. In summary, the technical solution of this application can realize dynamic, accurate, secure and controllable management of charging pile permissions, and ensure the auditability of the entire process.

[0069] Please see the appendix Figure 2 This application provides a charging pile access control device based on dynamic attributes. The device may include a data acquisition module 201, a first generation module 202, an execution module 203, a security processing module 204, a monitoring module 205, and a second generation module 206, as detailed below:

[0070] The data acquisition module 201 is used to collect dynamic attribute sets related to business requests;

[0071] The first generation module 202 is used to generate real-time permission decision instructions based on a dynamic attribute set and a predetermined permission policy.

[0072] The execution module 203 is used to perform corresponding operations according to the target object level of the real-time permission decision instruction. If the target object is a device-level resource, the charging pile control operation corresponding to the real-time permission decision instruction is executed. If the target object is a management node, the permission token distribution operation is executed.

[0073] The security processing module 204 is used to perform security processing on the data involved in the permission decision-making and execution process;

[0074] The monitoring module 205 is used to monitor and record the permission decision and execution process to generate monitoring data, and to analyze and generate abnormal indicators based on the monitoring data.

[0075] The second generation module 206 is used to generate and store operation logs based on monitoring data for audit analysis based on operation logs.

[0076] From the above appendix Figure 2 As illustrated by the example of a charging pile access control device based on dynamic attributes, on the one hand, by collecting dynamic attribute sets in real time and generating decision instructions based on predetermined access policies, the access decision-making process can fully consider the specific context of the current environment, thereby achieving more granular and practical dynamic access control, effectively avoiding excessive or insufficient access granting. On the other hand, by performing secure processing on sensitive data involved in the access decision-making and execution process, security protection measures are deeply embedded in the core business process, rather than as a separate subsequent step, thus providing protection from the initial data generation stage and reducing the risk of sensitive data leakage during the process. Thirdly, by monitoring and recording the entire process of access decision-making and execution to generate monitoring data, and analyzing and generating abnormal indicators based on this data, continuous assessment of the system's security status and proactive discovery of potential risks can be achieved, providing a basis for timely intervention. Furthermore, generating and storing operation logs based on monitoring data provides a complete and reliable data foundation for subsequent audit analysis, enabling any operation to be traced and verified, significantly enhancing the system's accountability. In summary, the technical solution of this application can realize dynamic, accurate, secure and controllable management of charging pile permissions, and ensure the auditability of the entire process.

[0077] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 3As shown, the electronic device 3 in this embodiment mainly includes: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program for a charging pile access control method based on dynamic attributes. When the processor 30 executes the computer program 32, it implements the steps described in the above embodiment of the charging pile access control method based on dynamic attributes, for example... Figure 1 The steps S101 to S106 are shown. Alternatively, when the processor 30 executes the computer program 32, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 2 The functions of the acquisition module 201, the first generation module 202, the execution module 203, the security processing module 204, the monitoring module 205, and the second generation module 206 are shown.

[0078] For example, the computer program 32 of the charging pile permission management method based on dynamic attributes mainly includes: collecting a set of dynamic attributes related to business requests; generating real-time permission decision instructions based on the dynamic attribute set and a predetermined permission policy; executing corresponding operations according to the target object level of the real-time permission decision instructions, wherein if the target object is a device-level resource, the charging pile control operation corresponding to the real-time permission decision instructions is executed, and if the target object is a management node, the permission token distribution operation is executed; performing security processing on the data involved in the permission decision and execution process; monitoring and recording the permission decision and execution process to generate monitoring data, and generating abnormal indicators based on the monitoring data analysis; generating operation logs based on the monitoring data and storing them for audit analysis based on the operation logs. The computer program 32 can be divided into one or more modules / units, one or more modules / units are stored in the memory 31 and executed by the processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution process of the computer program 32 in the electronic device 3. For example, computer program 32 can be divided into the functions of acquisition module 201, first generation module 202, execution module 203, security processing module 204, monitoring module 205, and second generation module 206 (a module in the virtual device). The specific functions of each module are as follows: Acquisition module 201 is used to acquire dynamic attribute sets related to business requests; first generation module 202 is used to generate real-time permission decision instructions based on the dynamic attribute sets and predetermined permission policies; execution module 203 is used to execute corresponding operations according to the target object level of the real-time permission decision instructions. If the target object is a device-level resource, the charging pile control operation corresponding to the real-time permission decision instructions is executed; if the target object is a management node, the permission token distribution operation is executed; security processing module 204 is used to perform security processing on the data involved in the permission decision and execution process; monitoring module 205 is used to monitor and record the permission decision and execution process to generate monitoring data, and generate abnormal indicators based on the monitoring data analysis; second generation module 206 is used to generate operation logs based on the monitoring data and store them for audit analysis based on the operation logs.

[0079] Electronic device 3 may include, but is not limited to, processor 30 and memory 31. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0080] The processor 30 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0081] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0082] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed. That is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above-described device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0086] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0087] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0088] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a storage medium. Based on this understanding, all or part of the processes in the above-described embodiments can also be implemented by a computer program instructing related hardware. The computer program for the dynamic attribute-based charging pile permission management method can be stored in a storage medium. When executed by a processor, the computer program can implement the steps of the above-described method embodiments, namely: collecting a set of dynamic attributes related to the business request; generating a real-time permission decision instruction based on the dynamic attribute set and a predetermined permission policy; performing corresponding operations according to the target object level of the real-time permission decision instruction, wherein if the target object is a device-level resource, the charging pile control operation corresponding to the real-time permission decision instruction is executed, and if the target object is a management node, the permission token distribution operation is executed; the data involved in the permission decision and execution process is securely processed; the permission decision and execution process is monitored and recorded to generate monitoring data, and abnormal indicators are generated based on the monitoring data analysis; operation logs are generated based on the monitoring data and stored for audit analysis based on the operation logs. Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Storage media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the contents of storage media can be appropriately added or removed according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, storage media do not include electrical carrier signals and telecommunication signals.

[0089] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application 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. These 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 this application, and should all be included within the protection scope of this application. The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the protection scope of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this invention.

Claims

1. A dynamic attribute-based charging pile permission management method, characterized in that, The method comprises: collecting a set of dynamic attributes related to a service request, the collecting a set of dynamic attributes related to a service request comprising: asynchronously acquiring multi-source heterogeneous data streams from a user terminal, a charging pile sensor and a service server; performing confidence evaluation and data fusion processing on the multi-source heterogeneous data streams to generate structured attribute data with a timestamp and a confidence label, constituting the set of dynamic attributes; generating a real-time permission decision instruction based on the set of dynamic attributes and a predetermined permission policy, the predetermined permission policy being a hybrid policy combining role-based access control (RBAC) and attribute-based access control (ABAC), the generating a real-time permission decision instruction based on the set of dynamic attributes and a predetermined permission policy comprising: generating a basic permission set from an RBAC role permission template according to a user identity, and marking the reliability of the basic permission set based on the confidence label; inputting the basic permission set with the reliability mark and the structured attribute data into an ABAC policy engine; loading dynamic constraint rules linked with environmental states through the ABAC policy engine, performing multi-attribute fusion calculation based on a game theory weighted strategy, and outputting the real-time permission decision instruction and decision confidence; the multi-attribute fusion calculation based on the game theory weighted strategy comprising: constructing a game model with the security of permission granting, business processing efficiency and user satisfaction as targets; taking the set of dynamic attributes as the strategy input of game participants, and dynamically allocating the weights of each attribute by calculating the Nash equilibrium point; dynamically modifying and conflict resolving the basic permission set according to the weighted attribute weights and the dynamic constraint rules; performing corresponding operations according to the target object level of the real-time permission decision instruction, wherein if the target object is a device-level resource, performing a charging pile control operation corresponding to the real-time permission decision instruction, and if the target object is a management node, performing a permission token distribution operation; safely processing data involved in the permission decision and execution process; monitoring and recording the permission decision and execution process to generate monitoring data, and analyzing abnormal indicators based on the monitoring data, the monitoring and recording the permission decision and execution process to generate monitoring data comprising: synchronously collecting user operation behavior data, permission instruction data and device response data, and injecting decision context data generated by the ABAC policy engine; constructing a four-dimensional real-time monitoring matrix, the four dimensions of the four-dimensional real-time monitoring matrix including user, instruction, device and decision context; based on the four-dimensional real-time monitoring matrix, generating a multi-modal behavior stream with a time sequence label and an association identifier; generating an operation log based on the monitoring data and storing it for audit analysis based on the operation log. 2.The dynamic attribute based charging pile authority management method of claim 1, wherein, The safely processing data involved in the permission decision and execution process comprises: identifying structured and unstructured sensitive data generated in the execution of the charging pile control operation or the distribution of the permission token. According to the sensitive level of the data and the context of the real-time permission decision instruction, a corresponding desensitization algorithm is dynamically selected and loaded to process the identified sensitive data. 3.The dynamic attribute based charging pile permission management method of claim 2, wherein, Also includes: The payment information data after desensitization processing is dynamically divided into multiple data shards according to its data characteristics; An encryption key is independently generated for each data shard, and different encryption algorithms are used to encrypt each shard; The encrypted data shards and the corresponding key shards are distributedly stored in different storage nodes based on geographic location, and the shard mapping relationship is recorded to a secure metadata pool.

4. A dynamic attribute-based charging pile permission management device, characterized in that, The device comprises: The acquisition module is configured to acquire a set of dynamic attributes related to a service request, including: asynchronously acquiring multi-source heterogeneous data streams from a user terminal, a charging pile sensor, and a service server; performing confidence evaluation and data fusion processing on the multi-source heterogeneous data streams to generate structured attribute data with a timestamp and a confidence label, thereby forming the set of dynamic attributes; The first generation module is configured to generate a real-time permission decision instruction based on the set of dynamic attributes and a predetermined permission policy, wherein the predetermined permission policy is a hybrid policy that combines Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), and the generation of the real-time permission decision instruction based on the set of dynamic attributes and the predetermined permission policy includes: generating a basic permission set from an RBAC role permission template based on user identity, and marking the reliability of the basic permission set based on the confidence label; inputting the basic permission set with the reliability mark and the structured attribute data into an ABAC policy engine; loading dynamic constraint rules linked to environmental states through the ABAC policy engine, performing multi-attribute fusion calculation based on a game theory weighted strategy, and outputting the real-time permission decision instruction and decision confidence; the multi-attribute fusion calculation based on the game theory weighted strategy includes: constructing a game model targeting at permission granting security, business processing efficiency, and user satisfaction; inputting the set of dynamic attributes as strategy of game participants, and dynamically allocating weights of each attribute by calculating Nash equilibrium points; dynamically modifying and conflict resolving the basic permission set according to the weighted attribute weights and the dynamic constraint rules; The execution module is configured to perform corresponding operations according to the target object level of the real-time permission decision instruction, wherein if the target object is a device-level resource, it performs a charging pile control operation corresponding to the real-time permission decision instruction, and if the target object is a management node, it performs a permission token distribution operation; The security processing module is configured to perform security processing on the data involved in the permission decision and execution process. A monitoring module is configured to monitor and record the permission decision and execution process to generate monitoring data, and analyze an abnormal index based on the monitoring data. The monitoring and recording of the permission decision and execution process to generate the monitoring data includes: synchronously collecting user operation behavior data, permission instruction data, and device response data, and injecting decision context data generated by the ABAC policy engine; constructing a four-dimensional real-time monitoring matrix, four dimensions of the four-dimensional real-time monitoring matrix including user, instruction, device, and decision context; based on the four-dimensional real-time monitoring matrix, generating a multi-modal behavior flow with a time sequence label and an association identifier; A second generation module is configured to generate and store an operation log based on the monitoring data, for audit analysis based on the operation log.

5. An electronic device, the device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 3.

6. A storage medium storing a computer program, characterized by The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 3.

Images