Simulation authorization evaluation method and system, electronic device and storage medium

Abstract

The application relates to a simulation authorization evaluation method and system, an electronic device and a storage medium. The method comprises the following steps: obtaining static authorization information of a simulation system recorded when a license is issued, and obtaining dynamic authorization information of the simulation system collected during running; the static authorization information comprises basic license features, and the dynamic authorization information comprises host environment features and service behavior features; the authorization state of the simulation system is evaluated according to the basic license features, the host environment features and the service behavior features; and control measures matched with the authorization state are triggered for the simulation system. The scheme provided by the application can improve the authorization robustness in a private delivery environment and enhance the identification capability of abnormal use behaviors.

Description

Technical Field

[0001] This application relates to the field of simulation technology, and in particular to a simulation licensing evaluation method, system, electronic device, and storage medium. Background Technology

[0002] With the rapid development of AI (Artificial Intelligence) technology, multi-agent AI simulation orchestration systems are gaining popularity among users due to their advantages in efficient collaboration and flexible scheduling. In private deployments or enterprise delivery scenarios, multi-agent AI simulation orchestration systems typically face challenges such as authorization abuse, environment migration, image replication, abnormal concurrency, and unauthorized calls.

[0003] In related technologies, the authorization mechanism is mainly based on static authorization of hardware fingerprints or periodic verification based on centralized license servers. However, the first solution relies too much on static environment characteristics and has poor adaptability to virtual machine, container and cluster migration scenarios. The second solution is difficult to identify situations where the authorized subject has not changed the hardware environment but has already made abnormal calls or used without authorization. Summary of the Invention

[0004] To address or partially address the problems existing in related technologies, this application provides a simulation license evaluation method, system, electronic device, and storage medium, which can improve the robustness of licenses in a private delivery environment and enhance the ability to identify abnormal usage behavior.

[0005] The first aspect of this application provides a simulation licensing evaluation method, including: The system acquires static license information of the simulation system recorded when the license is issued, and dynamic license information of the simulation system collected during operation; the static license information includes basic license characteristics, and the dynamic license information includes host environment characteristics and business behavior characteristics. The authorization status of the simulation system is assessed based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics. The simulation system is triggered with control measures that match the authorized state.

[0006] In one embodiment, the basic licensing features include at least one of the following: authorizing subject, permitted functional scope, resource limit, license period, and signature information; the host environment features include at least one of the following: hardware fingerprint, container identifier, network topology change, time offset, and virtualization features; and the business behavior features include at least one of the following: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaboration behavior, knowledge base operation behavior, spatial distribution features, and task attribute features. The step of evaluating the authorization status of the simulation system based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics includes: Based on the basic licensing characteristics, the host environment characteristics, and the business behavior characteristics, the authorization deviation of the simulation system is calculated; The authorization status of the simulation system is evaluated by comparing the authorized deviation with a preset deviation threshold.

[0007] In one embodiment, the authorization status includes at least one of normal authorization status, suspicious authorization status, and unauthorized authorization status; the preset deviation threshold includes a first deviation threshold and a second deviation threshold, wherein the first deviation threshold is less than the second deviation threshold; the step of evaluating the authorization status of the simulation system based on a comparison of the authorization deviation degree with the preset threshold includes: If the authorization deviation is less than the first deviation threshold, then the authorization status of the simulation system is assessed as a normal authorization status; or... If the authorization deviation is greater than or equal to the first deviation threshold and less than the second deviation threshold, then the authorization status of the simulation system is assessed as a suspicious authorization status; or, If the authorization deviation is greater than or equal to the second deviation threshold, the authorization status of the simulation system is assessed as an unauthorized authorization status.

[0008] In one embodiment, the control measures include at least one of maintaining normal release, secondary verification, rate limiting, module degradation, and module locking; the triggering of control measures on the simulation system that match the authorized state includes: When the authorization status is the normal authorization status, the simulation system is maintained in normal operation; or... When the authorization status is the suspicious authorization status, the simulation system undergoes secondary verification or rate limiting; or... When the authorization status is the unauthorized authorization status, the simulation system is downgraded or locked.

[0009] In one embodiment, the multi-agent cooperative behavior includes the calling order and calling frequency of each agent in the simulation system; the method further includes: The calling order and calling frequency of each intelligent agent are mapped into a temporal behavior feature vector; The difference between the time-series behavior feature vector and the preset authorization threshold is calculated to obtain the authorization deviation of the simulation system.

[0010] In one embodiment, the method further includes: When the system detects that the same authorized entity exhibits abnormally high-frequency task issuance in its task scheduling behavior, cross-environment migration in its spatial distribution characteristics, and batch access to the knowledge base in its knowledge base operation behavior within a preset time period, the system's authorization status will be assessed as suspicious.

[0011] In one embodiment, the method further includes: Based on the key authorization key stored in trusted hardware, the simulation system performs identity verification; and / or, Perform integrity verification on the license; and / or, Based on the clock information of the trusted hardware, the validity period of the license is verified. When the simulation system passes the identity response verification, and / or the license passes the integrity verification, and / or the license period passes the timeliness verification, the authorization status of the simulation system is assessed as a normal authorization status.

[0012] A second aspect of this application provides a simulation licensing evaluation system, comprising: The information acquisition module is used to acquire the static authorization information of the simulation system recorded when the license is issued, and to acquire the dynamic authorization information of the simulation system collected during operation; the static authorization information includes basic license characteristics, and the dynamic authorization information includes host environment characteristics and business behavior characteristics; The evaluation and decision-making module is used to evaluate the authorization status of the simulation system based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics. The execution module is used to trigger control measures on the simulation system that match the authorized state.

[0013] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0014] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.

[0015] The technical solution provided in this application may include the following beneficial effects: The solution provided in this application acquires static authorization information of the simulation system recorded at the time of license issuance, as well as dynamic authorization information of the simulation system collected during operation. Static authorization information includes basic license characteristics, while dynamic authorization information includes host environment characteristics and business behavior characteristics. Based on these characteristics, the authorization status of the simulation system is assessed, and control measures matching the authorization status are triggered. This application, by introducing host environment characteristics and business behavior characteristics (which are dynamic authorization information that changes with the operation of the simulation system) on top of basic license characteristics (which belong to static authorization information), can well adapt to virtual machine, container, and cluster migration scenarios. Furthermore, by dynamically associating the actual system usage behavior (i.e., business behavior characteristics) with the authorization boundary, the protection granularity is refined. Therefore, even if the authorized entity does not change the hardware environment, it can effectively identify abnormal calls, unauthorized use, etc., thereby improving the authorization robustness in a private delivery environment and enhancing the ability to identify abnormal usage behavior.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0018] Figure 1 This is a schematic flowchart illustrating the simulation licensing evaluation method shown in the embodiments of this application; Figure 2 This is another schematic diagram of the simulation licensing evaluation method shown in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the simulation licensing evaluation system shown in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0019] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0020] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0021] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0022] In related technologies, the authorization mechanism is mainly based on static authorization of hardware fingerprints or periodic verification based on centralized license servers. However, the first solution relies too much on static environment characteristics and has poor adaptability to virtual machine, container and cluster migration scenarios. The second solution is difficult to identify situations where the authorized subject has not changed the hardware environment but has already made abnormal calls or used without authorization.

[0023] To address the aforementioned issues, this application provides a simulation-based authorization evaluation method. By introducing host environment characteristics and business behavior characteristics (dynamic authorization information that changes with the operation of the simulation system) on top of basic license features (which are static authorization information), this method can effectively adapt to virtual machine, container, and cluster migration scenarios. Furthermore, by dynamically associating actual system usage behavior (i.e., business behavior characteristics) with authorization boundaries, the protection granularity is refined. Therefore, even if the authorization subject has not changed the hardware environment, it can effectively identify abnormal calls, unauthorized use, and other situations, thereby improving the robustness of authorization in a private delivery environment and enhancing the ability to identify abnormal usage behavior.

[0024] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0025] Figure 1 This is a schematic flowchart illustrating the simulation licensing evaluation method shown in the embodiments of this application.

[0026] See Figure 1 The simulation-based licensing evaluation method of this application may include: S110, obtain the static authorization information of the simulation system recorded when the license is issued, and obtain the dynamic authorization information of the simulation system collected during operation; the static authorization information includes basic license characteristics, and the dynamic authorization information includes host environment characteristics and business behavior characteristics.

[0027] In the embodiments of this application, it can be applied to a simulation authorization evaluation system (hereinafter referred to as the "evaluation system"). The simulation authorization evaluation system includes a dedicated authentication service independent of the simulation system and local modules deployed on the simulation system (such as an environment acquisition module and a behavior acquisition module). The simulation system is a multi-agent AI simulation orchestration system.

[0028] The dedicated authentication service includes an authorization registration module. When issuing a license to a simulation system, the authorization registration module can record the basic licensing characteristics related to the license. These basic licensing characteristics may include, but are not limited to, the authorizing entity, the scope of permitted functions, the resource limit, the license period, and signature information.

[0029] During the operation of the simulation system, the environment acquisition module deployed locally on the simulation system can continuously detect the host environment status of the simulation system. The host environment characteristics may include, but are not limited to: hardware fingerprint, container identification, network topology changes, time offset and virtualization characteristics.

[0030] During the operation of the simulation system, the behavior acquisition module deployed locally on the simulation system can continuously collect the business behavior characteristics of the simulation system. Business behavior characteristics (or multi-agent simulation behavior profile / business usage profile) are observable indicators that can reflect the compliance of the simulation system's usage behavior. Business behavior characteristics may include, but are not limited to: task scheduling behavior, solver call behavior, functional module call behavior, multi-agent collaboration behavior, knowledge base operation behavior, spatial distribution characteristics, and task attribute characteristics.

[0031] The environment collection module can upload the host environment status to the dedicated authentication service, and the behavior collection module can upload business behavior characteristics to the dedicated authentication service.

[0032] It should be noted that the basic license characteristics are static license information that will not change as the simulation system runs, while the host environment state and business behavior characteristics are dynamic license information that can change as the simulation system runs.

[0033] S120 assesses the authorization status of the simulation system based on basic license characteristics, host environment characteristics, and business behavior characteristics.

[0034] The dedicated authentication service includes an assessment and decision-making module. This module can integrate basic licensing characteristics with the aforementioned collected results (i.e., host environment characteristics and business behavior characteristics) to form a multi-dimensional authorization assessment vector. This vector is then used to assess the trust status of the simulation system's authorization status.

[0035] S130 refers to control measures that match the triggering and authorized states of the simulation system.

[0036] The dedicated authentication service includes a disposition execution module, which can implement tiered responses to the simulation system based on the evaluation results (i.e., authorization status) output by the evaluation decision module. Specifically, embodiments of this application can pre-configure various control measures. The disposition execution module can determine the matching control measure from among these measures based on the current authorization status of the simulation system, and then issue the control measure to the simulation system to dynamically adjust its capabilities. For example, when the authorization status indicates that the simulation system is normal, the issued control measure can be used to instruct the release of available functions / resources to the simulation system; conversely, when the authorization status indicates that the simulation system is abnormal, the issued control measure can be used to instruct the restriction of available functions / resources of the simulation system.

[0037] As can be seen from this example, the solution provided in this application, by introducing host environment characteristics and business behavior characteristics (which are dynamic authorization information that can change with the operation of the simulation system) on the basis of basic license characteristics (which belong to static authorization information), can adapt well to virtual machine, container and cluster migration scenarios; furthermore, by dynamically associating the actual system usage behavior (i.e. business behavior characteristics) with the authorization boundary, the protection granularity is refined. Therefore, even if the authorization subject does not change the hardware environment, it can effectively identify abnormal calls, unauthorized use and other situations, thereby improving the authorization robustness in the private delivery environment and enhancing the ability to identify abnormal usage behavior.

[0038] Figure 2 This is another schematic diagram of the simulation licensing evaluation method shown in this application.

[0039] See Figure 2 The simulation-based licensing evaluation method of this application may include: S210, obtain the static license information of the simulation system recorded when the license is issued, and obtain the dynamic license information of the simulation system collected during operation; the static license information includes basic license characteristics, and the dynamic license information includes host environment characteristics and business behavior characteristics.

[0040] This step can be found in the description in S110, and will not be repeated here.

[0041] S220 calculates the authorization deviation of the simulation system based on basic license characteristics, host environment characteristics, and business behavior characteristics.

[0042] The evaluation and decision-making module can integrate basic licensing characteristics with host environment characteristics and business behavior characteristics to form a multi-dimensional authorization evaluation vector, so as to calculate the authorization deviation of the simulation system based on the multi-dimensional authorization evaluation vector.

[0043] Authorization deviation is a metric used to quantify the degree of inconsistency between the actual operating environment and behavior of a simulation system and the scope of the license agreement. It uses the license issued to the system as a baseline constraint and integrates multi-dimensional environmental characteristics such as hardware fingerprints, container identifiers, and network topology changes, as well as multi-dimensional behavioral characteristics such as task scheduling, function calls, resource usage, proxy collaboration, and environment migration. It calculates the degree to which the actual operating environment and behavior deviate from the license agreement to determine whether the simulation system has unauthorized behaviors such as unauthorized use, excessive calls, unauthorized migration, and abnormal access. The larger the authorization deviation, the greater the difference between the actual operating environment or behavior of the simulation system and the license agreement, and the higher the risk of authorization violation and the degree of unauthorized use.

[0044] In one embodiment, the basic licensing features include at least one of the following: the authorizing entity, the scope of permitted functions, the resource limit, the license period, and signature information; the host environment features include at least one of the following: hardware fingerprint, container identifier, network topology change, time offset, and virtualization features; and the business behavior features include at least one of the following: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaborative behavior, knowledge base operation behavior, spatial distribution features, and task attribute features.

[0045] Basic license characteristics may include, but are not limited to: the authorizing entity, the permitted scope of functions, resource limits, license period, and signature information. The authorizing entity refers to the unit or individual that has obtained a legal license to use the simulation system; it is the party to whom the authorization belongs. This may include, for example, the unit name, organization code, user ID, and unique device identifier, and is used to prevent unauthorized use or transfer of authorization. The permitted scope of functions refers to the functional modules, business capabilities, or operational permissions that the simulation system grants to users under the license. This may include, for example, basic simulation, advanced algorithms, multi-node parallelism, dedicated model libraries, and data export, and is used to control whether users can use the purchased / authorized functions, and whether unauthorized modules are available. The resource limit refers to the maximum amount of resources the system can use as agreed in the license agreement. This may include, for example, the number of concurrent tasks, the number of CPU (Central Processing Unit) cores, the memory limit, the number of simulation nodes, the model size, storage capacity, and the maximum simulation step size, and is used to prevent over-scale use, ensure system stability, and comply with commercial licensing agreements. The license period refers to the start and end time of the legally valid authorization for the simulation system. It may include, for example, the effective date, the expiration date, and whether the license is permanent. It can be used to control the validity of the authorization; after expiration, the simulation system automatically enters a restricted or unavailable state. The signature information refers to the legality verification information of the authorization file generated by the software vendor using encryption algorithms. It is usually a string of encrypted data or a digital certificate, and can be used to verify whether the authorization file has been tampered with or forged, ensuring that the authorization file is authentic, valid, and has not been cracked or altered.

[0046] Host environment characteristics may include, but are not limited to: hardware fingerprints, container identifiers, network topology changes, time offsets, and virtualization characteristics. Hardware fingerprints refer to the unique identification information of hardware devices, such as CPU serial numbers / models, motherboard UUIDs (Universally Unique Identifiers), hard drive serial numbers, BIOS (Basic Input / Output System) information, and MAC (Media Access Control) addresses, which can be used for device uniqueness verification, anti-copying, authorization binding, and environment tracing. Container identifiers refer to the unique identification information assigned to each container instance at runtime, used to identify the container instance, orchestration environment, number of replicas, and whether it is a cloned container. Network topology changes refer to the dynamic changes in the network structure of the current host / container, such as changes in nodes, links, routes, and network segments, which can be used for environment migration detection, abnormal network environment identification, and security risk assessment. Time offset refers to the difference between the current time of the simulation system and the standard time, which can be used to detect whether the time has been tampered with, whether the environment is abnormal, or whether there is an attempt to bypass authorization / auditing. Virtualization features are characteristic information used to determine whether the current simulation system is running in a virtual machine, container, cloud host, or simulator. For example, they may include: VM (Virtual Machine) identifier, virtual disk, virtual network card, virtualization instruction set / CPU flag, etc., which can be used to identify whether it is a virtual environment, whether it is a reverse analysis environment, or whether it has been copied.

[0047] Business behavior characteristics may include, but are not limited to: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaboration behavior, knowledge base operation behavior, spatial distribution characteristics, and task attribute characteristics. Among these, task scheduling behavior refers to the temporal patterns, frequency characteristics, and scheduling modes of task initiation, submission, queuing, distribution, and execution during the simulation system's operation, used to describe whether simulation tasks conform to authorized constraints in terms of time and process dimensions. Solver invocation behavior refers to the invocation method, frequency, distribution, and usage patterns of solvers in the simulation system, reflecting whether solver resources are used normally within the authorized scope and whether there are any over-limit, unauthorized, or abnormal invocations. Functional module invocation behavior refers to the invocation sequence, frequency, and usage distribution characteristics of each functional module in the simulation system, used to determine whether module-level usage behavior deviates from the authorized functional scope and usage permissions. Multi-agent collaboration behavior refers to the interaction methods, invocation order, collaboration structure, and coordination modes between multiple agents (or agents), reflecting whether multi-agent collaborative work exceeds the authorized node range and collaboration rules. Knowledge base operation behavior refers to the operational characteristics of accessing the knowledge base in the simulation system, such as the rhythm of access, batch reading, data querying, and exporting. It is used to measure whether data resource access behavior conforms to the authorized access scope, access volume, and operation permissions. Spatial distribution characteristics refer to the distribution and migration characteristics of simulation tasks, computing nodes, and runtime environments in the physical or logical domain, reflecting whether the runtime environment exceeds the authorized spatial scope and deployment constraints. Task attribute characteristics refer to the inherent attributes of the simulation task itself, such as its type, scale, complexity, business scenario, and resource requirements. These are used to determine whether the simulation task itself belongs to the authorized task type and processing scope.

[0048] Furthermore, task scheduling behavior can include, but is not limited to: request frequency, task distribution mode, task submission frequency and temporal distribution, abnormally high-frequency task distribution, and task submission rhythm characteristics. Request frequency refers to the number of requests to system interfaces or services per unit of time. Task distribution mode refers to the mechanism and method of task scheduling, allocation, and distribution. Task submission frequency and temporal distribution refer to the frequency at which users or agents submit tasks per unit of time, and the distribution pattern of tasks on the timeline. This can include, for example, the number of tasks submitted per unit of time, peak / valley period characteristics, whether the submission interval is uniform, whether there are sudden increases, and temporal patterns (periodic, random, regular), which can be used to identify abnormal submissions, malicious load testing, batch script submissions, and abnormal concurrency. Abnormally high-frequency task distribution refers to sudden, intensive task distribution abnormal behavior exceeding normal thresholds. Task submission rhythm characteristics refer to the periodic and regular rhythmic characteristics of task submissions.

[0049] Furthermore, solver invocation behavior can include, but is not limited to: simulation intent specification object (SolverSpec) invocation patterns, SolverSpec invocation distribution, specification invocation distribution characteristics, and solver usage pattern characteristics. SolverSpec invocation patterns refer to the invocation methods and triggering modes of the solver specification interface. SolverSpec invocation distribution refers to the frequency and distribution patterns of solver specification interface invocations. Specification invocation distribution characteristics refer to the distribution characteristics of the frequency, permission scope, and compliance of invocations of system interfaces, protocols, APIs, services, and constraint rules. For example, this can include: which interfaces are called frequently / frequently, whether sensitive interfaces or high-risk interfaces are called in a concentrated manner, and whether they comply with authorization specifications, traffic specifications, and permission specifications. These characteristics can be used to identify unauthorized invocations, API abuse, specification violations, and abnormal traffic. Solver usage pattern characteristics refer to the behavioral characteristics formed by the way, frequency, resource consumption, and parameter configuration of the solver. For example, it can include: number of times the solver is started, the duration of a single solution, memory / CPU usage pattern, the size of the problem being solved, whether the parameter settings are abnormal, whether the solution is repeated, brute force solution, etc. It can be used to identify pirated / cracked use, large-scale solution beyond the license, resource abuse, and abnormal computational behavior.

[0050] Furthermore, functional module calling behavior can include, but is not limited to: module usage distribution, functional module calling sequence characteristics, and functional module calling pattern characteristics. Module usage distribution refers to the frequency, proportion, and usage distribution of each functional module called in the simulation system. Functional module calling sequence characteristics refer to the behavioral features formed by the order, path, and jump relationship of each functional module being called sequentially during the simulation system's operation. For example, this can include: a calling chain such as functional module A → functional module B → functional module C, high-frequency paths, loop counts, branch selection, regularity of the sequence, and abnormal deviations, which can be used for behavioral baseline modeling, abnormal process detection, unauthorized operations, and reverse engineering / cracking behavior identification. Functional module calling pattern characteristics refer to the way, habits, and behavioral patterns of functional modules being called.

[0051] Furthermore, multi-agent collaborative behavior can include, but is not limited to, agent invocation sequence, agent collaboration mode characteristics, agent invocation order, and agent invocation frequency. Here, agent invocation sequence refers to the order in which agents (agents refer to intelligent agents) are invoked and executed. Agent collaboration mode characteristics refer to the behavioral patterns of division of labor, communication, scheduling, dependence, and collaborative task completion among multiple AI agents in a multi-agent simulation system. These can include, for example, master-slave mode, distributed parallelism, pipeline collaboration, inter-agent communication frequency, data exchange volume, and task allocation strategies, and can be used to identify abnormal network topology, illegal agent expansion, malicious collaboration, and impersonating agents. Agent invocation order refers to the sequential order in which each agent in the simulation system is invoked. Agent invocation frequency refers to the number and frequency of times each agent in the simulation system is invoked.

[0052] Furthermore, knowledge base operation behaviors can include, but are not limited to: knowledge base access rhythm, knowledge base batch access behavior, and data export behavior characteristics. Among these, knowledge base access rhythm refers to the time intervals and periodic patterns of accessing the knowledge base in the simulation system. Knowledge base batch access behavior refers to the behavior of accessing the knowledge base in the simulation system in a concentrated, batch manner. Data export behavior characteristics refer to the frequency, scale, and behavioral habits of data export operations in the simulation system.

[0053] Furthermore, spatial distribution characteristics can include, but are not limited to, cross-environment migration and physical domain distribution characteristics. Cross-environment migration refers to the behavioral characteristics of objects such as tasks, data, or agents migrating between different operating environments. Physical domain distribution characteristics refer to the spatial distribution characteristics of objects such as tasks and resources within physical regions and deployment environments.

[0054] Furthermore, task attribute characteristics may include, but are not limited to, simulation task type. Here, simulation task type refers to the business type, scenario type, and computation type to which the simulation task belongs.

[0055] Among them, the basic licensing features that are positively correlated with the degree of authorization deviation may include: the authorizing entity, the resource limit, and the signature information.

[0056] Among them, the basic licensing characteristics that are negatively correlated with the degree of authorization deviation may include: the scope of permitted functions and the license period.

[0057] Among them, host environment characteristics that are positively correlated with the degree of authorization deviation can include: hardware fingerprints, container identifiers, network topology changes, time offsets, and virtualization characteristics.

[0058] Among them, business behavior characteristics that are positively correlated with the degree of authorization deviation may include: request frequency, task issuance mode, task submission frequency and time sequence distribution, abnormally high-frequency task issuance, task submission rhythm characteristics, SolverSpec call mode, SolverSpec call distribution, reduction call distribution characteristics, solver usage mode characteristics, module usage distribution, functional module call sequence characteristics, functional module call mode characteristics, agent call sequence, agent collaboration mode characteristics, agent call order, agent call frequency, knowledge base access rhythm, knowledge base batch access behavior, data export behavior characteristics, cross-environment migration and physical domain distribution characteristics.

[0059] In one embodiment, the multi-agent cooperative behavior includes the calling order and frequency of each agent in the simulation system; the method may further include: The calling order and calling frequency of each agent are mapped to a temporal behavior feature vector; the difference between the temporal behavior feature vector and the preset authorization threshold is calculated to obtain the authorization deviation of the simulation system.

[0060] In addition to calculating the authorization deviation of the simulation system through step S220, the authorization deviation of the simulation system can also be calculated in the following ways: The behavior acquisition module can serialize and encode the multi-agent task flow in the simulation system, mapping the calling order and frequency of each agent into a temporal behavior feature vector. This transforms abstract calling behaviors (such as calling order and frequency) into analyzable numerical combinations, thereby accurately capturing the temporal patterns of agent calls. The evaluation and decision module can calculate the authorization deviation of the simulation system based on the temporal behavior feature vector and static authorization boundaries. Specifically, the static authorization boundaries are pre-defined authorization rules, such as allowed calling order, frequency thresholds, and other preset authorization thresholds. The evaluation and decision module calculates the difference between the temporal behavior feature vector and the preset authorization thresholds; this difference serves as the authorization deviation of the simulation system.

[0061] Compared to monitoring only superficial and singular indicators (such as login frequency, device fingerprint, or total number of interface calls), which makes it impossible to capture the temporal patterns of intelligent agent calls, the embodiments of this application capture the temporal characteristics such as the call order and call frequency of each intelligent agent, which can more accurately and deeply determine whether the authorization is compliant, avoid the problems of missed judgments and misjudgments, and achieve more refined authorization assessment.

[0062] Therefore, the embodiments of this application do not refer to general UEBA (User and Entity Behavior Analysis), risk control, or static license verification schemes, but are preferably limited to: authorization assessment not only relies on the characteristics of the host environment, but also on business behavior characteristics such as task distribution mode, SolverSpec call distribution, proxy call sequence, and knowledge base access rhythm in the simulation system. In this way, business behavior characteristics are introduced into the main link of authorization decision-making, rather than just being used as auxiliary logs, which can enhance the ability to identify abnormal usage behavior.

[0063] S230: Evaluate the authorization status of the simulation system by comparing the authorized deviation degree with the preset deviation threshold.

[0064] Authorization deviation is a metric used to quantify the degree of inconsistency between the actual operating environment and behavior of a simulation system and the scope of the license agreement. It uses the license issued to the system as a baseline constraint and integrates multi-dimensional environmental characteristics such as hardware fingerprints, container identifiers, and network topology changes, as well as multi-dimensional behavioral characteristics such as task scheduling, function calls, resource usage, proxy collaboration, and environment migration. It calculates the degree to which the actual operating environment and behavior deviate from the license agreement to determine whether the simulation system has unauthorized behaviors such as unauthorized use, excessive calls, unauthorized migration, and abnormal access. The larger the authorization deviation, the greater the difference between the actual operating environment or behavior of the simulation system and the license agreement, and the higher the risk of authorization violation and the degree of unauthorized use.

[0065] Based on this, embodiments of this application can compare the degree of authorization deviation with a preset deviation threshold in order to evaluate the authorization status of the simulation system based on the comparison results.

[0066] In one embodiment, the authorization status includes at least one of normal authorization status, suspicious authorization status, and unauthorized authorization status; the preset deviation threshold includes a first deviation threshold and a second deviation threshold, wherein the first deviation threshold is less than the second deviation threshold; evaluating the authorization status of the simulation system based on a comparison of the authorization deviation degree with the preset deviation threshold may include: If the authorization deviation is less than the first deviation threshold, the authorization status of the simulation system is assessed as normal authorization status; or, if the authorization deviation is greater than or equal to the first deviation threshold and less than the second deviation threshold, the authorization status of the simulation system is assessed as suspicious authorization status; or, if the authorization deviation is greater than or equal to the second deviation threshold, the authorization status of the simulation system is assessed as illegal authorization status.

[0067] If the authorization deviation is less than the first deviation threshold, it means that during the operation of the simulation system, its multi-dimensional environmental characteristics and multi-dimensional behavioral characteristics strictly comply with the authorization scope agreed in the license, and there is no unauthorized, excessive or abnormal behavior. The authorization deviation is in the extremely low or normal threshold range, and the system's operating environment and behavior are highly consistent with the license. In this case, the evaluation decision module will evaluate the authorization status of the simulation system as a normal authorization status.

[0068] If the first deviation threshold ≤ authorized deviation < second deviation threshold, it indicates that some environmental or behavioral characteristics of the simulation system are slightly abnormal. The authorized deviation exceeds the normal baseline but does not reach the clear violation threshold. It cannot be directly judged as compliant, but it does not constitute a clear overreach of authority. Further verification, monitoring and early warning are required. In this case, the evaluation decision module will evaluate the authorization status of the simulation system as a suspicious authorization status.

[0069] If the second deviation threshold is less than or equal to the authorized deviation degree, it means that the actual operating environment and behavior of the simulation system significantly exceed the scope agreed upon in the license, the authorized deviation degree reaches or exceeds the violation judgment threshold, and there are clear problems such as authorization abuse / environment migration / mirror copying / abnormal concurrency / unauthorized calls. In this case, the evaluation decision module will evaluate the authorization status of the simulation system as an unauthorized authorization status.

[0070] In one embodiment, the method may further include: Based on the key authorization key stored in trusted hardware, the simulation system performs identity response verification; and / or, license integrity verification; and / or, license validity verification based on clock information from trusted hardware; when the simulation system passes identity response verification, and / or the license passes integrity verification, and / or the license validity verification, the authorization status of the simulation system is assessed as normal authorization status.

[0071] This application embodiment can combine the implementation method of hardware security module to store the key authorization key in external trusted hardware (such as security chip) and ensure authorization security through a three-layer verification mechanism: identity response verification, license integrity verification and authorization timeliness verification.

[0072] For identity response verification, the system can send a random value to the security chip to initiate the response verification process. For example, the security chip uses the key authorization key stored internally to sign the random value and return it. The system verifies the signature result. If the verification is successful, the system confirms that the identity response verification has been passed and basic trusted authentication has been completed.

[0073] For license integrity verification, the license is generated using key encryption or digital signature during the issuance stage. During each authorization assessment, the system decrypts and verifies the license to check whether the license document has been tampered with and to confirm that the information such as the scope of authorization, term of use, and functional boundaries contained therein is complete and valid, ensuring that the authorized content has not been illegally modified.

[0074] For verifying the validity of the license, the system can utilize the anti-tampering mechanism built into the security chip to obtain reliable clock information and compare it with the license period stipulated in the license. By using a reliable hardware clock, the risk of system clock tampering is avoided, effectively preventing attacks that bypass the license period by modifying the system clock, and ensuring that the license is used within the license period.

[0075] After obtaining the verification results of the above three verification mechanisms, if the simulation system passes the identity response verification, and / or the license passes the integrity verification, and / or the license period passes the timeliness verification, the evaluation decision module will evaluate the authorization status of the simulation system as a normal authorization status.

[0076] Preferably, in this embodiment of the application, the verification results of the above three-layer verification mechanism can all be set to indicate that they have passed (i.e., the simulation system passes the identity response verification, the license passes the integrity verification, and the license period passes the timeliness verification). Only then will the evaluation and decision module evaluate the authorization status of the simulation system as a normal authorization status. This can maximize the authorization robustness in the private delivery environment.

[0077] S240 refers to control measures that match the triggering and authorized states of the simulation system.

[0078] This step can be found in the description in S130, and will not be repeated here.

[0079] In one implementation, the control measures include at least one of maintaining normal release, secondary verification, rate limiting, module degradation, and module locking; control measures triggered by the simulation system that match the authorized state may include: When the authorization status is normal, the simulation system is allowed to continue operating normally; or, when the authorization status is suspicious, the simulation system is subject to secondary verification or rate limiting; or, when the authorization status is illegal, the simulation system is downgraded or locked.

[0080] When the authorization status is normal, it means that the authorization evaluation result of the simulation system is normal and there is no abnormal deviation. In this case, the simulation system is allowed to continue operating normally. For example, no intervention is made in the simulation system for tasks, advanced function calls, knowledge base access, etc., and the original operation strategy and service capabilities of the simulation system remain unchanged.

[0081] When the authorization status is "suspicious," it indicates that the authorization evaluation result of the simulation system has a slight anomaly or is questionable. In this case, a secondary verification (or mandatory review) is performed on the simulation system. For example, the identity, permissions, and compliance of the current tasks, access requests, or invocation behaviors in the simulation system are re-verified. The legality is confirmed through manual or automatic review to avoid misjudgment or minor overreach. Alternatively, the simulation system can be rate-limited (e.g., by reducing the concurrency limit). For example, the frequency of task submission, the number of concurrent requests, and the access rate in the simulation system can be constrained to reduce the amount of tasks processed and resources consumed per unit time, and to curb authorization violations and system resource abuse caused by overreach.

[0082] When the authorization status is "unauthorized," it indicates that the authorization evaluation results of the simulation system are severely abnormal. In this case, the simulation system will be downgraded (e.g., restricting some advanced functions). For example, basic simulation functions may be retained, while advanced functions such as solvers, special modules, and batch processing may be turned off or disabled, allowing users to use the simulation system only within the scope of basic permissions. Alternatively, the simulation system may be locked (e.g., suspending critical modules). For example, for critical modules (such as SolverSpec) with serious authorization violations, malicious calls, or significant risks, their operation and call services may be stopped directly to prevent the spread of risks and ensure the system's authorization compliance.

[0083] It should be noted that the trust assessment of the authorization status of the simulation system in this application embodiment is continuous, rather than a one-time process. Therefore, it supports dynamic adjustment of the authorization status and control measures of the simulation system during its operation. For example, when the authorization deviation drops to the normal threshold range (i.e., authorization deviation < first deviation threshold), the assessment system can adjust the authorization status from a suspicious authorization status / illegal authorization status to a normal authorization status, so as to speed up / upgrade / unlock modules in the simulation system.

[0084] In one embodiment, the method may further include: When the system detects that the same authorized entity exhibits abnormally high-frequency task scheduling behavior, cross-environment migration spatial distribution characteristics, or batch access to the knowledge base within a preset time period, the system's authorization status will be assessed as suspicious.

[0085] If the same authorized entity is detected to have abnormally high frequency of task issuance, cross-environment migration and batch access to the knowledge base within a short period of time, the evaluation and decision module determines that the authorization deviation of the simulation system exceeds the first deviation threshold. Therefore, the authorization status of the simulation system is evaluated as a suspicious authorization status, so as to trigger the rate limiting and manual review process.

[0086] It should be noted that both the simulation system and the dedicated certification service can write the assessment results and handling results of each instance into the authorized audit log, so that the two ends can be compared and reviewed in the future, and the strategy can be iterated based on the review results.

[0087] As can be seen from this example, the solution provided in this application, by introducing host environment characteristics and business behavior characteristics (which are dynamic authorization information that can change with the operation of the simulation system) on the basis of basic license characteristics (which belong to static authorization information), can adapt well to virtual machine, container and cluster migration scenarios; furthermore, by dynamically associating the actual system usage behavior (i.e. business behavior characteristics) with the authorization boundary, the protection granularity is refined. Therefore, even if the authorization subject does not change the hardware environment, it can effectively identify abnormal calls, unauthorized use and other situations, thereby improving the authorization robustness in the private delivery environment and enhancing the ability to identify abnormal usage behavior.

[0088] Furthermore, the solution provided in this application, by combining the implementation of a hardware security module, stores the key authorization key in external trusted hardware (such as a security chip), which can greatly improve the robustness of authorization in a private delivery environment.

[0089] Furthermore, the solution provided in this application, by combining the implementation of a trusted execution environment, completes continuous trust assessment of the authorization status within the protected operating area, and can dynamically adjust the authorization status and control measures (such as unlocking critical modules), which can greatly improve the authorization robustness in a private delivery environment.

[0090] Furthermore, the solution provided in this application, by combining a centralized zero-trust gateway-based implementation, externalizes the authorization evaluation decision to a dedicated authentication service and issues control measures to the local simulation system, which can greatly improve the robustness of authorization in a private delivery environment.

[0091] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a simulation authorization evaluation system, electronic device, and corresponding embodiments.

[0092] Figure 3 This is a schematic diagram of the structure of the simulation licensing evaluation system shown in the embodiments of this application.

[0093] See Figure 3 The simulation-based evaluation system of this application may include: The information acquisition module 310 is used to acquire the static authorization information of the simulation system recorded when the license is issued, and to acquire the dynamic authorization information of the simulation system collected during operation; the static authorization information includes basic license characteristics, and the dynamic authorization information includes host environment characteristics and business behavior characteristics; The evaluation and decision module 320 is used to evaluate the authorization status of the simulation system based on basic license characteristics, host environment characteristics, and business behavior characteristics. The execution module 330 is used to control measures that match the triggering and authorized status of the simulation system.

[0094] It should be noted that the information acquisition module 310 may specifically include an authorization registration module 3101, an environment acquisition module 3102, and a behavior acquisition module 3103; wherein, the authorization registration module 3101 is used to record the static authorization information of the simulation system when the license is issued; the environment acquisition module 3102 is used to continuously detect the host environment characteristics of the simulation system during the operation of the simulation system; and the behavior acquisition module 3103 is used to continuously collect the business behavior characteristics of the simulation system during the operation of the simulation system.

[0095] It should be noted that the authorization registration module 3101, the evaluation decision module 320, and the disposal execution module 330 are deployed on the dedicated authentication service, while the environment acquisition module 3102 and the behavior acquisition module 3103 are deployed on the simulation system.

[0096] In one embodiment, the basic licensing features include at least one of the following: the authorizing entity, the scope of permitted functions, the resource limit, the license period, and signature information; the host environment features include at least one of the following: hardware fingerprint, container identifier, network topology change, time offset, and virtualization features; and the business behavior features include at least one of the following: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaborative behavior, knowledge base operation behavior, spatial distribution features, and task attribute features. The evaluation and decision module 320 may include: The authorization deviation calculation submodule is used to calculate the authorization deviation of the simulation system based on basic license characteristics, host environment characteristics, and business behavior characteristics. The authorization status assessment submodule is used to assess the authorization status of the simulation system by comparing the authorization deviation with a preset deviation threshold.

[0097] In one embodiment, the authorization status includes at least one of normal authorization status, suspicious authorization status, and unauthorized authorization status; the preset deviation threshold includes a first deviation threshold and a second deviation threshold, wherein the first deviation threshold is less than the second deviation threshold; the authorization status evaluation submodule may include: The normal authorization status determination unit is used to evaluate the authorization status of the simulation system as normal authorization status if the authorization deviation is less than a first deviation threshold; or, The suspicious authorization status determination unit is used to assess the authorization status of the simulation system as suspicious if the authorization deviation is greater than or equal to a first deviation threshold and less than a second deviation threshold; or, The unauthorized authorization status determination unit is used to evaluate the authorization status of the simulation system as unauthorized if the authorization deviation is greater than or equal to the second deviation threshold.

[0098] In one embodiment, the control measures include at least one of maintaining normal release, secondary verification, rate limiting, module downgrading, and module locking; the handling execution module 330 may include: The first control submodule is used to maintain normal access to the simulation system when the authorization status is normal; or... The second control submodule is used to perform secondary verification or rate limiting on the simulation system when the authorization status is suspicious; or... The third control submodule is used to downgrade or lock the simulation system modules when the authorization status is an unauthorized authorization status.

[0099] In one embodiment, the multi-agent cooperative behavior includes the calling order and frequency of each agent in the simulation system; the authorization deviation calculation submodule can also be used for: The calling order and calling frequency of each agent are mapped into a temporal behavior feature vector; The difference between the temporal behavior feature vector and the preset authorization threshold is calculated to obtain the authorization deviation of the simulation system.

[0100] In one implementation, the authorization evaluation submodule can also be used for: When the system detects that the same authorized entity exhibits abnormally high-frequency task scheduling behavior, cross-environment migration spatial distribution characteristics, or batch access to the knowledge base within a preset time period, the system's authorization status will be assessed as suspicious.

[0101] In one embodiment, the normal authorization status determination unit can also be used for: Based on the key authorization key stored in trusted hardware, the simulation system performs identity verification; and / or, Perform integrity verification on the license; and / or, Based on clock information from trusted hardware, the validity of the license period is verified. When the simulation system passes identity verification, and / or the license passes integrity verification, and / or the license period passes timeliness verification, the simulation system's authorization status is assessed as normal authorization status.

[0102] As can be seen from this example, the solution provided in this application, by introducing host environment characteristics and business behavior characteristics (which are dynamic authorization information that can change with the operation of the simulation system) on the basis of basic license characteristics (which belong to static authorization information), can adapt well to virtual machine, container and cluster migration scenarios; furthermore, by dynamically associating the actual system usage behavior (i.e. business behavior characteristics) with the authorization boundary, the protection granularity is refined. Therefore, even if the authorization subject does not change the hardware environment, it can effectively identify abnormal calls, unauthorized use and other situations, thereby improving the authorization robustness in the private delivery environment and enhancing the ability to identify abnormal usage behavior.

[0103] Regarding the system in the above embodiments, the specific ways in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0104] Figure 4 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0105] See Figure 4 The electronic device 400 includes a memory 410 and a processor 420.

[0106] The processor 420 can 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. The general-purpose processor can be a microprocessor or any conventional processor. Memory 410 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 420 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 410 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 410 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0107] The memory 410 stores executable code, which, when processed by the processor 420, can cause the processor 420 to execute part or all of the methods described above.

[0108] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0109] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0110] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.

[0111] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A simulation licensing evaluation method, characterized in that, include: Obtain the static license information of the simulation system recorded when the license is issued, and obtain the dynamic license information of the simulation system collected during operation; The static authorization information includes basic license characteristics, and the dynamic authorization information includes host environment characteristics and business behavior characteristics; The authorization status of the simulation system is assessed based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics. The simulation system is triggered with control measures that match the authorized state.

2. The method according to claim 1, characterized in that, The basic licensing features include at least one of the following: authorizing entity, permitted functional scope, resource limit, license period, and signature information; the host environment features include at least one of the following: hardware fingerprint, container identifier, network topology change, time offset, and virtualization features; and the business behavior features include at least one of the following: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaboration behavior, knowledge base operation behavior, spatial distribution features, and task attribute features. The step of evaluating the authorization status of the simulation system based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics includes: Based on the basic licensing characteristics, the host environment characteristics, and the business behavior characteristics, the authorization deviation of the simulation system is calculated; The authorization status of the simulation system is evaluated by comparing the authorized deviation with a preset deviation threshold.

3. The method according to claim 2, characterized in that, The authorization status includes at least one of normal authorization status, suspicious authorization status and illegal authorization status, and the preset deviation threshold includes a first deviation threshold and a second deviation threshold, wherein the first deviation threshold is less than the second deviation threshold. The step of evaluating the authorization status of the simulation system based on the comparison between the authorization deviation and a preset threshold includes: If the authorization deviation is less than the first deviation threshold, then the authorization status of the simulation system is assessed as a normal authorization status; or... If the authorization deviation is greater than or equal to the first deviation threshold and less than the second deviation threshold, then the authorization status of the simulation system is assessed as a suspicious authorization status; or, If the authorization deviation is greater than or equal to the second deviation threshold, the authorization status of the simulation system is assessed as an unauthorized authorization status.

4. The method according to claim 3, characterized in that, The control measures include at least one of maintaining normal release, secondary verification, rate limiting, module downgrading, and module locking; the triggering of control measures on the simulation system that match the authorized state includes: When the authorization status is the normal authorization status, the simulation system is maintained in normal operation; or... When the authorization status is the suspicious authorization status, the simulation system undergoes secondary verification or rate limiting; or... When the authorization status is the unauthorized authorization status, the simulation system is downgraded or locked.

5. The method according to claim 2, characterized in that, The multi-agent cooperative behavior includes the calling order and calling frequency of each agent in the simulation system; the method further includes: The calling order and calling frequency of each intelligent agent are mapped into a temporal behavior feature vector; The difference between the time-series behavior feature vector and the preset authorization threshold is calculated to obtain the authorization deviation of the simulation system.

6. The method according to claim 3, characterized in that, The method further includes: When the system detects that the same authorized entity exhibits abnormally high-frequency task issuance in its task scheduling behavior, cross-environment migration in its spatial distribution characteristics, and batch access to the knowledge base in its knowledge base operation behavior within a preset time period, the system's authorization status will be assessed as suspicious.

7. The method according to claim 2, characterized in that, The method further includes: Based on the key authorization key stored in trusted hardware, the simulation system performs identity verification; and / or, Perform integrity verification on the license; and / or, Based on the clock information of the trusted hardware, the validity period of the license is verified. When the simulation system passes the identity response verification, and / or the license passes the integrity verification, and / or the license period passes the timeliness verification, the authorization status of the simulation system is assessed as a normal authorization status.

8. A simulation licensing evaluation system, characterized in that, include: The information acquisition module is used to acquire the static authorization information of the simulation system recorded when the license is issued, and to acquire the dynamic authorization information of the simulation system collected during operation; the static authorization information includes basic license characteristics, and the dynamic authorization information includes host environment characteristics and business behavior characteristics; The evaluation and decision-making module is used to evaluate the authorization status of the simulation system based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics. The execution module is used to trigger control measures on the simulation system that match the authorized state.

9. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-7.

Images