Access control method and device across administrative domains, electronic equipment and readable medium

Abstract

Embodiments of the present application provide a cross-management domain access control method and device, electronic equipment and readable medium, and relate to the technical field of access control. In the method, the local hub receives an access request for accessing a delegate from a trustee. If the trustee and the delegate have both registered with the local hub, the local hub responds to the access request, obtains context data of this access based on the authorization credentials corresponding to the delegate, calculates the risk entropy value corresponding to each dimension based on the risk representation data, risk weight and preset smoothing constant of each dimension, and further determines the comprehensive risk entropy value. If the context data meets the condition corresponding to the rule chain, and the comprehensive risk entropy value hits the preset authorization condition, the trustee is authorized to access the delegate. Otherwise, the trustee is denied access to the delegate. In this way, fine-grained access control across management domains can be achieved.

Description

Technical Field

[0001] This application belongs to the field of access control technology, specifically relating to a cross-administration access control method, apparatus, electronic device, and readable medium. Background Technology

[0002] In an information technology / operations technology environment, services in the information world and production in the physical world intersect within a controllable framework. Because services and production are typically managed by different, independent management platforms, the information technology / operations technology environment is fragmented into unconnected management domains, creating management silos.

[0003] In related technologies, a central hub is established between different management domains to integrate and communicate information from each domain, breaking down management silos and enabling controllable access and hosting between management domains. However, due to the lack of a delegation mechanism, fine-grained hosting and access control between management domains cannot be achieved. Summary of the Invention

[0004] This invention provides a method, apparatus, electronic device, and readable medium for cross-management domain access control, which can solve the problem of the inability to achieve fine-grained hosting and access control between management domains.

[0005] To address the aforementioned problems, this invention discloses a cross-administration domain access control method, the method comprising: Receive access requests from the trustee for accessing the principal.

[0006] If both the trustee and the principal are registered in the local hub, then in response to the access request, the context data for this access is obtained based on the authorization credential corresponding to the principal. The authorization credential is used to authorize the trustee to access the principal. The context data includes risk characterization data of at least one dimension.

[0007] Based on the risk characterization data, risk weights, and preset smoothing constants for each dimension, the risk entropy value corresponding to each dimension is calculated, and the risk entropy value corresponding to each dimension is positively correlated with the risk weight.

[0008] Based on the risk entropy value corresponding to each of the aforementioned dimensions, the comprehensive risk entropy value is determined, and the comprehensive risk entropy value is positively correlated with the risk entropy value corresponding to each of the aforementioned dimensions.

[0009] If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value hits the preset authorization conditions, then the trustee is authorized to access the principal.

[0010] If the context data does not meet any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value hits the preset rejection condition, then the trustee's access to the principal is rejected.

[0011] On the other hand, embodiments of the present invention disclose an access control device across management domains, the device comprising: The receiving module is used to receive access requests sent by the trustee for accessing the principal.

[0012] The acquisition module is configured to, in response to the access request, obtain the context data of this access based on the authorization credential corresponding to the principal if both the trustee and the principal have registered in the local hub. The authorization credential is used to authorize the trustee to access the principal, and the context data includes risk characterization data of at least one dimension.

[0013] The calculation module is used to calculate the risk entropy value corresponding to each dimension based on the risk characterization data, risk weights and preset smoothing constants of each dimension. The risk entropy value corresponding to each dimension is positively correlated with the risk weight.

[0014] The determination module is used to determine the comprehensive risk entropy value based on the risk entropy value corresponding to each of the dimensions, wherein the comprehensive risk entropy value is positively correlated with the risk entropy value corresponding to each of the dimensions.

[0015] The authorization module is used to authorize the trustee to access the principal if the context data satisfies the conditions corresponding to the rule chain and the comprehensive risk entropy value hits the preset authorization conditions.

[0016] The rejection module is used to reject the trustee's access to the principal if the context data does not meet any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value hits a preset rejection condition.

[0017] In another aspect, embodiments of the present invention disclose an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, the executable instruction causing the processor to execute the aforementioned method.

[0018] This invention also discloses a machine-readable medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described above.

[0019] The embodiments of this invention include the following advantages: In this embodiment, the local hub receives the access request sent by the entrusted party for accessing the entrusting party. If both the entrusted party and the entrusting party have registered with the local hub, then in response to the access request, the local hub obtains the context data for this access based on the authorization credential corresponding to the entrusting party. The authorization credential is used to authorize the entrusted party to access the entrusting party. The context data includes risk characterization data of at least one dimension. Based on the risk characterization data of each dimension, risk weights, and preset smoothing constants, the risk entropy value corresponding to each dimension is calculated. The risk entropy value corresponding to each dimension is positively correlated with the risk weights. Based on the risk entropy values ​​corresponding to each dimension, a comprehensive risk entropy value is determined. The comprehensive risk entropy value is positively correlated with the risk entropy values ​​corresponding to each dimension. If the context data meets the conditions corresponding to the rule chain, and the comprehensive risk entropy value hits the preset authorization condition, then the entrusted party is authorized to access the entrusting party. The rule chain includes at least one rule, and one rule corresponds to one authorized access condition. If the context data does not meet any condition corresponding to the rule chain, and / or the comprehensive risk entropy value hits the preset rejection condition, then the entrusted party's access to the entrusting party is rejected. By using a rule chain to determine the acquired context data and ultimately authorize access to the principal, and with multiple rules, each corresponding to an access authorization condition, the context of the access can be precisely measured. Furthermore, by acquiring risk characterization data across various dimensions, accurately assessing the risk weights of each dimension, calculating the risk entropy value for each dimension, and summing these values ​​to obtain the comprehensive risk entropy value for the access, the risk of the access can be accurately quantified. By comprehensively calculating all risks within the context and directly comparing the comprehensive risk entropy value with the preset authorization and denial conditions from the delegation policy, it is possible to accurately measure whether the access meets the principal's pre-set risk requirements, thus achieving fine-grained hosting and access control. Simultaneously, since the trustee and principal communicate through a local hub, which is absolutely isolated from the public cloud, the risk of leakage of the trustee's and principal's permission data through the cloud is completely avoided, effectively protecting data privacy and security. Attached Figure Description

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

[0021] Figure 1 This is a flowchart of the steps of a cross-management domain access control method provided in an embodiment of the present invention; Figure 2 This is a flowchart of a cross-management domain permission dynamic hosting and access control based on a local central agent, provided by an embodiment of the present invention; Figure 3This is a block diagram of a cross-management domain access control device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0023] Figure 1 This is a flowchart illustrating the steps of a cross-administration domain access control method provided in an embodiment of the present invention, as follows: Figure 1 As shown, the method may include the following steps: Step 101: Receive the access request sent by the trustee for accessing the principal.

[0024] Step 102: If both the trustee and the principal have registered in the local hub, then in response to the access request, the context data of this access is obtained based on the authorization credential corresponding to the principal. The authorization credential is used to authorize the trustee to access the principal. The context data includes risk characterization data of at least one dimension.

[0025] Step 103: Based on the risk characterization data, risk weights, and preset smoothing constants of each dimension, calculate the risk entropy value corresponding to each dimension. The risk entropy value corresponding to each dimension is positively correlated with the risk weight.

[0026] Step 104: Determine the comprehensive risk entropy value based on the risk entropy value corresponding to each dimension. The comprehensive risk entropy value is positively correlated with the risk entropy value corresponding to each dimension.

[0027] Step 105: If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value hits the preset authorization conditions, then the trustee is authorized to access the principal.

[0028] Step 106: If the context data does not satisfy any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value hits the preset rejection condition, then the trustee's access to the principal is rejected.

[0029] In an information technology / operations technology (IT / OT) environment, IT manages the flow of information in the data domain, while OT controls the physical world and production processes. These two aspects intersect within the same organization, forming a cohesive technological ecosystem. The IT environment primarily focuses on management and services, specifically on data storage, processing, transmission, and confidentiality, as well as system availability, security, and iteration speed. Typical IT systems include enterprise applications, infrastructure, and endpoint devices. For example, enterprise applications may include Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Office Automation (OA), and Human Resources (HR) systems; infrastructure may include servers, data centers, cloud platforms, and enterprise networks; and endpoint devices may include office computers, mobile phones, and printers. The OT environment primarily focuses on production control and monitoring, specifically on the real-time nature, determinism, reliability, and security of control. It directly impacts the production site and critical infrastructure. Typical OT systems include industrial control systems, field devices, and industrial networks. For example, industrial control systems may include programmable logic controllers (PLCs), distributed control systems (DCS), and supervisory control and data acquisition (SCADA) systems; field devices may include sensors, actuators, frequency converters, and robots; and industrial networks may include fieldbuses, industrial Ethernet, and proprietary protocol networks. In an IT / OT environment, the IT and OT environments are interconnected, with services and production managed by different management platforms. These platforms are independent of each other, each constituting a separate management domain. To bridge these different management domains, controlled access and delegation are required. For example, the management domain controlling production can delegate some permissions to the management domain controlling services. That is, the production management domain can be the delegating party, and the service management domain can be the delegated party. Because the delegating party grants permissions to the delegated party during delegation, the delegated party can have controlled access to the delegating party. For example, the delegating party could be the access control system of plant A, and the delegated party could be the energy management system of plant B. Plant A can delegate specific permissions to plant B; for example, these specific permissions could be "emergency stop for high-risk equipment" permissions.

[0030] Because different management domains are independent and have different permission semantics, they cannot communicate directly. Deploying a local hub on the user-side local network or edge node, and establishing mappings between each management domain and the local hub, allows the permission semantics of different management domains to be converted and unified within the local hub, thereby enabling communication between management domains. For example, the user-side local network can be an enterprise server room or a home electrical panel. The hardware entity of the local hub can be an industrial-grade edge computing gateway, which can have a trusted platform module. To ensure the privacy of core permission data and avoid data leakage and compliance risks caused by uploading to the cloud, the local hub should ensure physical isolation from the public cloud. The local hub can connect to different management domains from multiple vendors, essentially acting as an intermediate proxy layer.

[0031] For management domains that require hosting and access through a local hub, i.e., the delegator and the delegate, each management domain must pre-register with the local hub. If the delegator has already delegated specific permissions, the local hub stores the authorization credentials and the corresponding rule chain for the delegator. In this case, when the delegate attempts to access the delegator—for example, system B attempting to call the emergency stop interface of device A—it can first send an access request to the local hub. If it is found that both the delegate and the delegate are registered with the local hub, the local hub responds to the delegate's access request, checking whether the current real-time status of the delegator and the delegate conforms to the access policy pre-defined by the delegator.

[0032] The current real-time status of the client and the agent is measured by locally accessed context data. The collection of context data is specifically triggered by the Dynamic Decision Point (PDP) in the local hub and executed by the nearest edge computing node. For example, the context data could be the real-time vibration sensor data stream from equipment in Plant A. The client's pre-defined access strategy is embodied in a rule chain. Each rule in the rule chain is expressed by a conditional expression, and each conditional expression corresponds to an authorized access condition in the access strategy. All conditional expressions together form a conditional expression tree. Each conditional node in the conditional expression tree is labeled with a logical relationship, indicating the effective condition of each conditional expression. For example, the logical relationship can be AND or OR. Each leaf node of the conditional expression tree is bound to the source of the data related to the conditional expression and the evaluation function. Each leaf node can correspond to an event judgment. For example, the event judgment can include "real-time vibration data is greater than 8.0" and "the source IP of factory B is in the whitelist". Each leaf node is connected and summarized through condition nodes. For example, the condition node between "real-time vibration data is greater than 8.0" and "the source IP of factory B is in the whitelist" can be AND. Then, the rule chain can only be determined to be satisfied when both event judgments are satisfied at the same time.

[0033] After obtaining the context data from the local hub, the policy negotiation engine within the local hub dynamically arbitrates the context data based on the rule chain. This means directly substituting data from different sources into the evaluation functions bound to the associated leaf nodes for calculation, completing event determination at the leaf nodes, and then determining whether the current context data satisfies the rule chain. Only if the rule chain is satisfied is all the states associated with this access considered to conform to the access policy, the access is deemed legitimate, and the delegate's access to the delegator is authorized. Otherwise, the access is deemed illegitimate, and the local delegator's access to the delegate is denied.

[0034] The context data refers to the background information and data related to this access. Based on the context data, the comprehensive risk entropy value of this access can be calculated as an indicator to comprehensively measure the real-time risk of this access. Whether or not the access is authorized is determined by whether the context data meets the conditions corresponding to the rule chain, and by comparing the comprehensive risk entropy value with the preset authorization conditions and preset denial conditions. The preset authorization conditions and preset denial conditions are independent of the rule chain corresponding to the principal and are stored in the Trusted Execution Environment (TEE). If the context data meets the conditions corresponding to the rule chain and the comprehensive risk entropy value is low enough to meet the preset authorization conditions, the local hub authorizes the trustee to access the principal; otherwise, the local hub denies the trustee's access to the principal. For example, the context data may include the vibration amplitude and the trustee's address. If the dynamic constraint is "vibration amplitude > 8.0 and the trustee's address matches the whitelist", the context data is compared with the parsed rule chain, that is, it is determined whether the vibration amplitude is greater than 8.0 and whether the trustee's address matches the whitelist. The logical AND operation is performed on the two judgment results to determine whether the context data meets the rule chain. For example, the vibration amplitude can be 9.2, the entrusted party address can hit the whitelist, and the context data simultaneously satisfies two rules in the rule chain. By performing a logical AND operation on the above judgment results, the context address satisfies the rule chain.

[0035] The comprehensive risk entropy is a risk representation value calculated by integrating contextual risk representation data from multiple dimensions; that is, the sum of the risk entropy values ​​of all dimensions. For any dimension in the context, based on the obtained risk representation data, risk weights, and a preset smoothing constant, the corresponding risk entropy value can be calculated. This risk entropy value represents the contribution of that dimension to the comprehensive risk entropy value. The preset smoothing constant (…) The settings are determined by relevant technical personnel based on the actual application scenario. This invention does not impose limitations on these settings. For example, the preset smoothing constant can be... If the context data collected by the local hub through the nearest edge computing node includes n dimensions, then the comprehensive risk entropy value is... It can be represented as:

[0036] in, Let be the risk entropy value of the i-th dimension. When the risk entropy values ​​of all dimensions are 0, the comprehensive risk entropy value is... A value of 0 indicates that the visit is in a completely safe state. However, when the risk entropy value of a certain dimension increases, the overall risk entropy value also increases rapidly, and the overall risk rises sharply.

[0037] In summary, in this embodiment, the local hub receives an access request from the entrusted party to access the principal. If both the entrusted party and the principal have registered with the local hub, in response to the access request, the local hub obtains the context data for this access based on the authorization credential corresponding to the principal. The authorization credential is used to authorize the entrusted party to access the principal. The context data includes risk characterization data for at least one dimension. Based on the risk characterization data, risk weights, and preset smoothing constants for each dimension, the risk entropy value corresponding to each dimension is calculated. The risk entropy value corresponding to each dimension is positively correlated with the risk weight. Based on the risk entropy value corresponding to each dimension, a comprehensive risk entropy value is determined. The comprehensive risk entropy value is positively correlated with the risk entropy value corresponding to each dimension. If the context data meets the conditions corresponding to the rule chain, and the comprehensive risk entropy value hits the preset authorization condition, the entrusted party is authorized to access the principal. The rule chain includes at least one rule, and each rule corresponds to one authorized access condition. If the context data does not meet any condition corresponding to the rule chain, and / or the comprehensive risk entropy value hits the preset rejection condition, the entrusted party's access to the principal is rejected. By using a rule chain to determine the acquired context data and ultimately authorize access to the principal, and with multiple rules, each corresponding to an access authorization condition, the context of the access can be precisely measured. Furthermore, by acquiring risk characterization data across various dimensions, accurately assessing the risk weights of each dimension, calculating the risk entropy value for each dimension, and summing these values ​​to obtain the comprehensive risk entropy value for the access, the risk of the access can be accurately quantified. By comprehensively calculating all risks within the context and directly comparing the comprehensive risk entropy value with the preset authorization and denial conditions from the delegation policy, it is possible to accurately measure whether the access meets the principal's pre-set risk requirements, thus achieving fine-grained hosting and access control. Simultaneously, since the trustee and principal communicate through a local hub, which is absolutely isolated from the public cloud, the risk of leakage of the trustee's and principal's permission data through the cloud is completely avoided, effectively protecting data privacy and security.

[0038] In one related technology, dynamic features are added to the traditional Role-Based Access Control (RBAC) model, dividing permissions into static and dynamic permissions. Correspondingly, constraints are also divided into static and dynamic constraints, achieving dynamic control over the access process. Compared to related technologies, in this embodiment, the real-time context data of the current access is determined based on the rule chain corresponding to the delegating party, thus also achieving dynamic control over each access. However, this embodiment achieves fine-grained control over access through a more granular rule chain with more refined constraints than related technologies. Furthermore, this embodiment uses a local hub as an independent proxy hub deployed on the edge, unlike related technologies which use a hub that is absolutely isolated from the cloud. Compared to this, the use of a local hub avoids the risk of data leakage via the cloud, thus ensuring greater data security.

[0039] Optionally, the embodiments of this application may further include the following steps: Step S21: Receive the authorization certificate and hosting policy sent by the principal, wherein the hosting policy includes dynamic constraints.

[0040] Step S22: Parse the received dynamic constraints to generate the rule chain corresponding to the client.

[0041] Step S23: Encrypt the received authorization credential and store the rule chain and the encrypted authorization credential in a pre-built trusted execution environment.

[0042] When managing permissions across management domains, the delegating party delegates specific permissions to the delegate. For example, Factory A might delegate the "high-risk equipment emergency stop" permission to Factory B. The delegating party first sets up the management policy and generates authorization credentials through a local graphical user interface (GUI), then sends the management policy and authorization credentials to the local central hub. The management policy includes static and dynamic constraints. Specifically, static constraints can include Role-Based Access Control (RBAC) attributes, scope, and delegation duration. For example, RBAC attributes can include user attributes, role attributes, permission attributes, and environment attributes. Dynamic constraints could be something like "only effective when equipment vibration amplitude > 8.0 and lasts for more than 5 seconds." Upon receiving the management policy, the local central hub's policy negotiation engine can structurally decompose the management policy and process each type of management policy accordingly. For example, for static constraints in the management policy, the policy negotiation engine can directly write each static constraint into the access control list (ACL) of the policy repository as a static baseline for subsequent access control. For dynamic constraints in the hosting policy, the policy negotiation engine can parse all dynamic constraints into a rule chain. Each rule chain contains multiple rules, and each rule corresponds to an authorized access condition derived from the dynamic constraint. Using rules as leaf nodes, logical relationships (AND / OR) are added to the condition nodes connecting the leaf nodes based on the dynamic constraint, forming a condition expression tree, which is the rule chain. For example, a dynamic constraint could be "vibration amplitude > 8.0 and the entrusted address matches the whitelist." After decomposition, this yields two authorized access conditions: "vibration amplitude > 8.0" and "the entrusted address matches the whitelist." The logical relationship between them is "AND." In the parsed rule chain, "vibration amplitude > 8.0" and "the entrusted address matches the whitelist" correspond to two leaf nodes, and the condition node connecting the two leaf nodes is "AND."

[0043] The authorization credential is generated by the delegating party and is a digital signature of the authorization statement using the delegating party's private key. The authorization statement can authorize the local hub to issue access tokens on its behalf. After receiving the authorization credential, the local hub uses enclave code running within the Trusted Execution Environment (TEE) to encrypt it. Subsequently, the generated rule chain and the encrypted authorization credential are stored together in the TEE. The TEE resides inside the CPU of the edge computing gateway of the local hub and is a memory area that is forcibly isolated by hardware. After the TEE is built, this memory area is marked as encrypted and inaccessible from the outside by the CPU hardware, thus ensuring that the content stored in the TEE cannot be extracted under any attack scenario, even if the gateway operating system is compromised. Therefore, neither the rule chain nor the encrypted authorization credential stored in the TEE will be leaked.

[0044] In this embodiment, the system receives authorization credentials and a hosting policy from the entrusting party. The hosting policy includes dynamic constraints. The received dynamic constraints are parsed to generate a rule chain corresponding to the entrusting party. The received authorization credentials are encrypted, and the rule chain and the encrypted authorization credentials are stored in a pre-built trusted execution environment. By parsing the dynamic constraints set by the entrusting party into a rule chain, all dynamic constraints and their logical relationships are accurately recorded. This better adapts to dynamic scenarios such as device state standardization and environmental risk fluctuations, and improves the hosting mechanism, achieving fine-grained hosting. Since both the parsed rule chain and the encrypted authorization credentials are stored in the trusted execution environment, the risks that may result from attacks on the gateway operating system are further mitigated, thus strengthening data security.

[0045] Optionally, in the case of the authorized trustee's access to the principal as described above, this embodiment may further include the following step: if any preset failure condition is met during the trustee's access to the principal, the authorization to the trustee is revoked. The preset failure conditions include the principal revoking the hosting and the principal's device being offline for more than an offline threshold.

[0046] Under preset invalidation conditions, the local hub can seamlessly revoke authorization to the entrusted party. Specifically, if the entrusting party withdraws from hosting or the entrusting party's device is offline for more than a preset offline threshold, the local hub can immediately revoke the entrusted party's authorization to access the entrusting party. For example, authorization revocation can be achieved by updating the Certificate Revocation List (CRL). CRL revocation immediately invalidates the original authorization without relying on an internet connection, effectively reducing the latency of authorization invalidation and avoiding the risk of a single point of failure in the cloud. The preset offline threshold can be set by the entrusting party in the hosting policy, and can be determined comprehensively based on the device's criticality level, network stability, historical statistics, and compliance requirements. This embodiment of the invention does not impose any limitations on this.

[0047] In this embodiment, when an authorized trustee is granted access to the principal, if the principal revokes the hosting or the principal's device goes offline for longer than the offline threshold during the trustee's access, the authorization to the trustee is revoked. By immediately revoking the access authorization to the trustee when preset time-limited conditions are met, "hot-swappable" permission management across management domains is achieved. Since the revocation is completed by the local central hub, the entire process does not rely on the Internet, thus greatly reducing the delay in revocation taking effect and the risk of single point of failure in the cloud.

[0048] Optionally, this application embodiment may further include the following steps: updating the weights of the dimensions based on the risk weights, learning rates, and historical risk entropy values ​​of all dimensions within the previous time window.

[0049] The steps described above for calculating the risk entropy value corresponding to each dimension based on the risk characterization data, risk weights, and preset smoothing constants for each dimension may specifically include: Step 1031a1: For risk characterization data of any dimension, calculate the risk component of the dimension based on the risk characterization data of the dimension and the preset risk calculation method of the dimension.

[0050] Step 1031a2: Calculate the risk entropy value corresponding to the dimension based on the risk components of the dimension, the risk weights, and the preset smoothing constant.

[0051] For any dimension, a time window is set independently according to the type of that dimension. Specifically, for continuous dimensions, the data of that dimension can be updated according to a pre-set sliding window, which is the time window. The length of the sliding window can be set by relevant technical personnel according to the specific application scenario, and the embodiments of the present invention do not impose any restrictions on this. For discrete dimensions, values ​​can be taken only when the local hub receives an access request. In this case, the time window for that dimension can be the time interval between two access requests, and the data in the previous time window is the data collected when the last access request was received.

[0052] Risk weights are used to characterize the degree of influence of corresponding dimension risks on overall risk. The sum of the risk weights of all dimensions is always 1. The initial risk weight of each dimension in the first time window can be determined by relevant technical personnel based on experience. This embodiment of the invention does not limit this. For example, the initial risk weight can be determined by uniform distribution, that is, for the case including n dimensions, the initial risk weight of each dimension can be determined as 1 / n. The initial weight can also be determined based on a preset template of equipment type. For example, in the scenario of industrial robots, the vibration weight can be preset to 0.4. The risk weight can be adaptively adjusted according to the recent risk contribution of each dimension so that the dimensions with larger recent fluctuations can obtain higher risk weights. In each time window, the risk weight of each dimension can be determined based on the risk weights of all dimensions in the previous time window, the risk entropy value, and the preset learning rate. For example, in a context including n dimensions, the risk weight of the i-th dimension in the t-th time window. It can be expressed by the following formula:

[0053] in, Let i be the risk entropy value of the i-th dimension within the (t-1)-th time window. Let i be the risk weight of the i-th dimension within the (t-1)-th time window. A preset learning rate is used, the value of which can be set by relevant technical personnel according to the specific application scenario. This embodiment of the invention does not impose any restrictions on this; for example, the preset learning rate can be 0.1. Normalization is performed on the denominator to ensure that the sum of the updated weights is still 1.

[0054] For each dimension, there is a pre-defined risk calculation method. By substituting the obtained risk representation data for that dimension, the corresponding risk component can be calculated. Then, by combining the risk weight of that dimension and a pre-defined smoothing constant, the risk entropy value corresponding to that dimension can be calculated. For example, for the risk entropy value of the i-th dimension... , can be represented as:

[0055] in, Let i be the real-time risk weight for the i-th dimension. For the real-time risk component of the i-th dimension, The preset smoothing constant can take the following values: .

[0056] In this embodiment, the weight of a dimension is updated based on the risk weights, learning rates, and historical risk entropy values ​​of all dimensions within the previous time window. For risk representation data of any dimension, the risk component of that dimension is calculated based on the risk representation data and the preset risk calculation method for that dimension. Based on the risk component, risk weight, and preset smoothing constant, the corresponding risk entropy value of that dimension is calculated. By updating the current risk weight based on the risk contribution of that dimension within the previous time window and controlling the sum of the risk weights of all dimensions to be 1, the risk weights can be adaptively adjusted so that they can better reflect the degree of influence of each dimension on the total risk. This ensures that dimensions with large recent fluctuations receive higher weights, allowing them to contribute more to the comprehensive risk entropy value, thereby better expressing the real-time risk situation and ensuring more accurate judgments in access authorization, achieving fine-grained access control.

[0057] Optionally, the risk characterization data for at least one dimension may include vibration amplitude, sudden occurrence rate, equipment status, and trustee address. The step of calculating the risk component of the dimension based on the risk characterization data for that dimension and a preset risk calculation method for that dimension may specifically include: Step 1031a11: When the risk characterization data is the vibration amplitude, calculate the risk component corresponding to the vibration amplitude based on the vibration amplitude, the preset maximum amplitude, and the preset minimum amplitude.

[0058] Step 1031a12: When the risk characterization data is the suddenness ratio, calculate the risk component corresponding to the suddenness ratio based on the suddenness ratio and the preset suddenness threshold.

[0059] Step 1031a13: When the risk characterization data is the equipment status, calculate the risk component corresponding to the equipment status based on the equipment status.

[0060] Step 1031a14: If the risk characterization data is the trustee's address, calculate the risk component corresponding to the trustee's address based on the trustee's address and a preset whitelist.

[0061] For different dimensions, there are different types of risk characterization data, and corresponding preset risk calculation methods to convert the risk characterization data into risk components. When the risk characterization data is vibration amplitude, it can be based on vibration amplitude (v) and a preset maximum vibration amplitude (v). ) and preset minimum vibration amplitude ( ), calculate the corresponding risk components ( For example, the risk component corresponding to the vibration amplitude can be expressed as:

[0062] The preset maximum vibration amplitude and preset minimum vibration amplitude can be preset by relevant technicians according to the actual application scenario. The embodiments of the present invention do not limit this. For example, the preset maximum vibration amplitude... You can set it to 10 to preset the minimum vibration amplitude. It can be set to 0. In this scenario, if the real-time vibration amplitude v is 9.2, substituting it into the above formula will yield the risk component corresponding to the vibration amplitude. It is 0.92.

[0063] When the risk characterization data is the burst ratio, the corresponding risk component can be calculated based on the burst ratio (burst_ratio) and the preset burst threshold (burst_threshold). For example, the risk component corresponding to the suddenness ratio. The following formula can be used for calculation:

[0064] The preset burst threshold can be set by relevant technical personnel according to the relevant application scenario, and the embodiments of the present invention do not impose any restrictions on this. This preset risk calculation method ensures that when the proportion of network micro-bursts exceeds the preset burst threshold, the corresponding risk component can be 1, thus maximizing the risk component value.

[0065] When the risk characterization data is equipment status, specifically, the equipment status can be normal or under maintenance. In this case, the corresponding risk components can be calculated using the following risk calculation methods. :

[0066] This assignment method ensures that when the equipment is in maintenance mode, the corresponding risk component value reaches its maximum, directly maximizing the risk.

[0067] When the risk characterization data is the address of the entrusted party, the value of the corresponding risk component depends on whether the entrusted party address is in a preset whitelist. If the entrusted party address is not in the whitelist, it indicates that the current address has a high risk. For example, the risk component corresponding to the entrusted party address... It can be represented as follows:

[0068] If the entrusted party's address is not on the whitelist, although there is a higher risk, it only increases the risk level without blocking the process.

[0069] In this embodiment, when the risk characterization data is vibration amplitude, the risk component corresponding to the vibration amplitude is calculated based on the vibration amplitude, a preset maximum vibration amplitude, and a preset minimum vibration amplitude. When the risk characterization data is burst ratio, the risk component corresponding to the burst ratio is calculated based on the burst ratio and a preset burst threshold. When the risk characterization data is device status, the risk component corresponding to the device status is calculated based on the device status. When the risk characterization data is the entrusted party address, the risk component corresponding to the entrusted party address is calculated based on the entrusted party address and a preset whitelist. By adopting risk calculation methods corresponding to each dimension, the risks brought by each dimension are reasonably quantified, thereby obtaining the risk components corresponding to each dimension. The reasonable conversion from risk characterization data to risk components in this step lays the foundation for the subsequent accurate calculation of the risk entropy value of each dimension and the comprehensive risk entropy value corresponding to this access, thereby realizing fine-grained access control.

[0070] Optionally, the step of authorizing the trustee to access the principal if the context data satisfies the conditions corresponding to the rule chain and the comprehensive risk entropy value hits the preset authorization conditions may specifically include: Step 1032a: If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value is less than the security threshold, then the trustee is authorized to access the principal.

[0071] Step 1032b: If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value is not less than the security threshold, and the comprehensive risk entropy value is less than the blocking threshold, then the trustee is authorized to have restricted access to the principal.

[0072] The step of denying the trustee's access to the principal if the context data does not meet any condition corresponding to the rule chain and / or the comprehensive risk entropy value hits a preset rejection condition may specifically include: if the context data does not meet any condition corresponding to the rule chain and / or the comprehensive risk entropy value is not less than the blocking threshold, then blocking the trustee's access to the principal and triggering a security alarm.

[0073] When the context data meets the conditions corresponding to the rule chain and the comprehensive risk entropy value is less than the blocking threshold, the preset authorization conditions are met. Specifically, when the preset authorization conditions are met, the entrusted party can be granted tiered access to the principal based on the comparison between the comprehensive risk entropy value and the security threshold. That is, if the comprehensive risk entropy value is less than the security threshold, the entrusted party is authorized to access the principal; if the comprehensive risk entropy value is less than the blocking threshold but not less than the security threshold, the entrusted party is authorized to access the principal, but the access permission is downgraded, allowing only restricted access to the principal. If the context data does not meet any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value is not less than the blocking threshold, the comprehensive risk entropy value of this access is determined to meet the preset denial conditions, directly blocking the entrusted party's access to the principal and triggering a security alarm. Specifically, the security alarm can be sent to the principal, the entrusted party, or the local hub according to the alarm type. For example, when the blockage is caused by maintenance mode, a security alarm is sent to the principal; when the blockage is caused by device offline, a security alarm is sent to both the principal and the entrusted party.

[0074] The security threshold (τ_safe) and blocking threshold (τ_block) are set by the entrusting party in the hosting policy. The specific values ​​can be determined by relevant technical personnel based on actual needs. This embodiment of the invention does not impose such limitations. For example, the security threshold can be 0.3, and the blocking threshold can be 0.7. After the hosting policy is parsed, the security threshold and blocking threshold are independently stored in the trusted execution environment as policy-level parameters and do not participate in the condition node logic of the rule chain. However, it is worth noting that the result of judging the comprehensive risk entropy value based on the security threshold and blocking threshold participates in the final arbitration of the access control result using an AND logic calculation. For example, according to the rule chain, the access control arbitration logic may include: if the real-time vibration data is greater than 8.0, the entrusted party's address is within the whitelist, and the comprehensive risk entropy value is less than the security threshold, then the access is deemed legitimate, and the entrusted party is authorized to access the entrusting party. The access control arbitration logic read from the rule chain may also include: if the device is in maintenance mode, or the comprehensive risk entropy value is greater than or equal to the blocking threshold, then the entrusted party's access to the entrusting party is blocked.

[0075] In this embodiment, if the comprehensive risk entropy value is less than the security threshold, the entrusted party is authorized to access the principal. If the comprehensive risk entropy value is not less than the security threshold and is less than the blocking threshold, the entrusted party is authorized to have restricted access to the principal. If the comprehensive risk entropy value is not less than the blocking threshold, the entrusted party's access to the principal is blocked, and a security alarm is triggered. By classifying access control according to the numerical range of the comprehensive risk entropy value, fine-grained control of access permissions is achieved, thereby effectively realizing fine-grained access control. Furthermore, by triggering a security alarm when access is blocked, relevant parties can promptly perceive anomalies and risks.

[0076] Optionally, the above-described step of authorizing the trustee to access the principal may specifically include: dynamically generating an access token and sending the access token to the trustee, wherein the access token has a validity period of a preset duration, the preset duration being no longer than the authorization period, and the authorization period being part of the hosting policy sent by the principal.

[0077] The steps described above for authorizing the trustee to have restricted access to the principal may specifically include: generating a restricted token and sending the restricted token to the trustee, wherein the access scope indicated by the restricted token is smaller than the access scope indicated by the access token.

[0078] Figure 2 This is a flowchart illustrating a cross-domain permission dynamic hosting and access control process based on a local central agent, as provided in an embodiment of the present invention. Figure 2As shown, local central access authorization can be achieved through token issuance. When the local central access center needs to authorize a trustee to access a principal, it can dynamically generate an access token and send it to the trustee through the Policy Enforcement Point (PEP) in the local central access center. After receiving the access token, the trustee can use it to access the principal. The scope of the access token's permissions is strictly limited to the range allowed by the authorization credentials and cannot be exceeded. The access token has a preset validity period, which should not exceed the delegation time limit set in the managed policy. For example, if the delegation time limit is set to 30 seconds in the managed policy set by the principal, the access token's validity period can also be 30 seconds. When issuing an access token, the PEP marks the access token and records the used marks, thereby preventing replay of the access token.

[0079] When the local central authority needs to authorize a trustee to grant restricted access to a principal, the local central authority can generate a restricted token and send it to the trustee, enabling the trustee to use the restricted token to complete the restricted access to the principal. Specifically, the restricted token can be a read-only token or a token with permissions less than the access token. The access scope and validity period of the restricted token can both be less than those of the access token.

[0080] In this embodiment, access tokens are dynamically generated and sent to the entrusted party. These tokens have a preset validity period, no longer than the entrusted time limit, which is part of the hosting policy set by the entrusting party. A restricted token is also generated and sent to the entrusted party. The access scope indicated by the restricted token is smaller than that indicated by the access token. By issuing access tokens through a local central control system, the entrusted party is authorized to access the entrusting party. By issuing restricted tokens, the entrusted party is authorized to have restricted access to the entrusting party. The access scope indicated by the access tokens is completely limited to the hosting policy set by the entrusting party, thus accurately implementing the entrusting party's access policy. In cases of high risk but without complete blocking, restricted access is authorized by issuing restricted tokens, achieving hierarchical access control and effectively realizing fine-grained access control.

[0081] Optionally, the embodiments of this application may further include the following steps: Step S31: In response to the two-way authentication process initiated by the principal and the trustee based on the pre-recorded asymmetric key, establish two-way authentication with the principal and the trustee respectively.

[0082] Step S32: After completing the two-way authentication, receive the static attribute information sent by the principal and the agent respectively to complete the registration.

[0083] Before implementing cross-domain permission hosting and access control, all delegators and delegates participating in cross-domain access must register with the local hub. For any delegate or delegator, a bidirectional Transport Layer Security (mTLS) authentication is first established with the local hub using a pre-recorded asymmetric key. This ensures the security of data transmitted between the delegate and delegate's respective management domains and the local hub. After mTLS authentication, both the delegator and delegate send static attribute information to the local hub. The local hub's standardized semantics are used to map this static attribute information from the delegator or delegate to the local hub, thus unifying the permission semantics across different management domains, including the delegator and delegate. This static attribute information may include user ID, department, authentication strength, etc. During the delegation and access control process, after receiving a delegation policy or access request, the local hub first obtains the delegator information carried by the delegation policy or the delegate information carried by the access request, and compares it with the existing mapped static attribute information in the local hub. If the delegator information or delegate information already exists in the local hub, it is determined that the delegator or delegate has completed registration in the local hub.

[0084] In this embodiment, in response to the two-way authentication process initiated by the principal and the trustee based on pre-recorded asymmetric keys, two-way authentication is established with both the principal and the trustee. Upon completion of two-way authentication, static attribute information sent by both the principal and the trustee is received to complete registration. By establishing two-way authentication, secure information transmission is ensured. Furthermore, during registration, the semantic mapping of static attribute information standardizes the semantics of this information, breaking down communication barriers between different management domains and enabling efficient cross-management domain access.

[0085] Reference Figure 3 This diagram illustrates a block diagram of a cross-administration domain access control device provided by an embodiment of the present invention, such as... Figure 3 As shown, the device may specifically include: The receiving module 201 is used to receive the access request sent by the trustee for accessing the principal.

[0086] The acquisition module 202 is used to, in response to the access request, obtain the context data of this access based on the authorization credential corresponding to the principal if both the trustee and the principal have registered in the local hub. The authorization credential is used to authorize the trustee to access the principal. The context data includes risk characterization data of at least one dimension.

[0087] The calculation module 203 is used to calculate the risk entropy value corresponding to each dimension based on the risk characterization data, risk weights and preset smoothing constants of each dimension. The risk entropy value corresponding to each dimension is positively correlated with the risk weight.

[0088] The determining module 204 is used to determine the comprehensive risk entropy value based on the risk entropy value corresponding to each of the dimensions, wherein the comprehensive risk entropy value is positively correlated with the risk entropy value corresponding to each of the dimensions.

[0089] The authorization module 205 is used to authorize the trustee to access the principal if the context data satisfies the conditions corresponding to the rule chain and the comprehensive risk entropy value hits the preset authorization conditions.

[0090] The rejection module 206 is used to reject the trustee's access to the principal if the context data does not meet any condition corresponding to the rule chain, and / or the comprehensive risk entropy value hits a preset rejection condition.

[0091] Optionally, the above-mentioned device may further include: The second receiving module is used to receive the authorization certificate and the hosting policy sent by the principal, wherein the hosting policy includes dynamic constraints.

[0092] The parsing module is used to parse the received dynamic constraints and generate the rule chain corresponding to the client.

[0093] The storage module is used to encrypt the received authorization credential and store the rule chain and the encrypted authorization credential in a pre-built trusted execution environment.

[0094] Optionally, the above-mentioned device may further include: The revocation module is used to revoke the authorization of the trustee if any preset invalidation condition is met during the process of the trustee accessing the principal.

[0095] The preset failure conditions include the client withdrawing the hosting and the client's device being offline for more than the offline threshold.

[0096] Optionally, the above-mentioned device may further include: The update module is used to update the weights of the dimensions based on the risk weights, learning rates, and historical risk entropy values ​​of all dimensions within the previous time window.

[0097] The aforementioned decision module 203 can also be used for: For any dimension of risk characterization data, the risk component of the dimension is calculated based on the risk characterization data of the dimension and the preset risk calculation method of the dimension.

[0098] Based on the risk components of the dimension, the risk weights, and the preset smoothing constant, the risk entropy value corresponding to the dimension is calculated.

[0099] Optionally, the decision module 203 described above can also be used for: When the risk characterization data is the vibration amplitude, the risk component corresponding to the vibration amplitude is calculated based on the vibration amplitude, the preset maximum amplitude, and the preset minimum amplitude.

[0100] When the risk characterization data is the suddenness ratio, the risk component corresponding to the suddenness ratio is calculated based on the suddenness ratio and a preset suddenness threshold.

[0101] When the risk characterization data is the device status, the risk component corresponding to the device status is calculated based on the device status.

[0102] When the risk characterization data is the trustee's address, the risk component corresponding to the trustee's address is calculated based on the trustee's address and a preset whitelist.

[0103] Optionally, the aforementioned decision module 203 can also be used for... If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value is less than the security threshold, then the trustee is authorized to access the principal.

[0104] If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value is not less than the security threshold, and the comprehensive risk entropy value is less than the blocking threshold, then the trustee is authorized to have restricted access to the principal.

[0105] If the context data does not meet any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value is not less than the blocking threshold, then the trustee's access to the principal is blocked, and a security alarm is triggered.

[0106] Optionally, the decision module 203 described above can also be used for: An access token is dynamically generated and sent to the trustee. The access token has a preset validity period, which is no longer than the entrusted validity period, which is part of the hosting policy sent by the entrusting party.

[0107] A restricted token is generated and sent to the trustee, wherein the access scope indicated by the restricted token is smaller than the access scope indicated by the access token.

[0108] Optionally, the above-mentioned device may further include: The authentication module is used to respond to the two-way authentication process initiated by the principal and the trustee based on the pre-recorded asymmetric key, and to establish two-way authentication with the principal and the trustee respectively.

[0109] The registration module is used to receive static attribute information sent by the principal and the agent respectively after the two-way authentication is completed, so as to complete the registration.

[0110] In summary, in this embodiment, the local hub receives the access request from the entrusted party to access the principal party. If both the entrusted party and the principal party are registered with the local hub, in response to the access request, it obtains the context data of this access based on the authorization credentials corresponding to the principal party. The authorization credentials are used to authorize the entrusted party's access to the principal party. Based on the context data and the rule chain corresponding to the principal party, it authorizes or denies the entrusted party's access to the principal party. The rule chain includes at least one rule, and each rule corresponds to an access authorization condition. Because the obtained context data is judged through the rule chain, and the final decision on whether to authorize the entrusted party's access to the principal party is made, and the rule chain contains multiple rules, each corresponding to an access authorization condition, the context of this access can be finely measured, thus achieving fine-grained hosting and access control. Furthermore, since the entrusted party and the principal party communicate through the local hub, and the local hub is absolutely isolated from the public cloud, the risk of leakage of the entrusted party's and principal party's permission data through the cloud is completely avoided, effectively protecting data privacy and security.

[0111] Reference Figure 4 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Figure 4 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus.

[0112] The processor, the memory, and the communication interface communicate with each other via the communication bus; the memory stores at least one executable instruction, which causes the processor to execute the code optimization method of the aforementioned embodiment. The executable instructions can form a program.

[0113] This invention provides a machine-readable medium storing instructions that, when executed by one or more processors, enable the processors to perform the code optimization method described in the foregoing embodiments. The machine-readable medium can be one or more.

[0114] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0115] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0116] It should be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0117] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0118] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0119] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0120] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0121] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0122] Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0123] The foregoing has provided a detailed description of a cross-domain access control method, a cross-domain access control device, an electronic device, and a readable medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A cross-administration access control method, characterized in that, Applied to a local hub, the method includes: Receive access requests from the trustee for accessing the principal; If both the trustee and the principal are registered in the local hub, then in response to the access request, the context data for this access is obtained based on the authorization credential corresponding to the principal; the authorization credential is used to authorize the trustee to access the principal; the context data includes risk characterization data of at least one dimension; Based on the risk characterization data, risk weights, and preset smoothing constants for each dimension, the risk entropy value corresponding to each dimension is calculated; the risk entropy value corresponding to each dimension is positively correlated with the risk weight. The comprehensive risk entropy value is determined based on the risk entropy value corresponding to each of the aforementioned dimensions; the comprehensive risk entropy value is positively correlated with the risk entropy value corresponding to each of the aforementioned dimensions. If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value hits the preset authorization condition, then the trustee is authorized to access the principal; the rule chain includes at least one rule, and one rule corresponds to one authorized access condition; If the context data does not meet any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value hits the preset rejection condition, then the trustee's access to the principal is rejected.

2. The method according to claim 1, characterized in that, The method further includes: Receive the authorization certificate and hosting policy sent by the principal; the hosting policy includes dynamic constraints. The received dynamic constraints are parsed to generate a rule chain corresponding to the principal. The received authorization credential is encrypted, and the rule chain and the encrypted authorization credential are stored in a pre-built trusted execution environment.

3. The method according to claim 1, characterized in that, When authorizing the trustee to access the principal, the method further includes: If any preset invalidation condition is met during the process of the entrusted party accessing the principal, the authorization to the entrusted party will be revoked. The preset failure conditions include the client withdrawing the hosting and the client's device being offline for more than the offline threshold.

4. The method according to claim 1, characterized in that, The method further includes: Based on the risk weights, learning rates, and historical risk entropy values ​​of all dimensions within the previous time window, update the weights of the aforementioned dimensions. The calculation of the risk entropy value corresponding to each dimension based on the risk characterization data, risk weights, and preset smoothing constants for each dimension includes: For any dimension of risk characterization data, the risk component of the dimension is calculated based on the risk characterization data of the dimension and the preset risk calculation method of the dimension. Based on the risk components of the dimension, the risk weights, and the preset smoothing constant, the risk entropy value corresponding to the dimension is calculated.

5. The method according to claim 4, characterized in that, The risk characterization data for at least one dimension includes vibration amplitude, sudden occurrence rate, equipment status, and the address of the trustee. The calculation of the risk components of the dimension based on the risk characterization data of the dimension and the preset risk calculation method of the dimension includes: When the risk characterization data is the vibration amplitude, the risk component corresponding to the vibration amplitude is calculated based on the vibration amplitude, the preset maximum amplitude, and the preset minimum amplitude. When the risk characterization data is the suddenness ratio, the risk component corresponding to the suddenness ratio is calculated based on the suddenness ratio and the preset suddenness threshold. When the risk characterization data is the device status, the risk component corresponding to the device status is calculated based on the device status. When the risk characterization data is the trustee's address, the risk component corresponding to the trustee's address is calculated based on the trustee's address and a preset whitelist.

6. The method according to claim 1, characterized in that, If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value matches the preset authorization conditions, then authorizing the trustee to access the principal includes: If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value is less than the security threshold, then the trustee is authorized to access the principal. If the context data satisfies the conditions corresponding to the rule chain, and the comprehensive risk entropy value is not less than the security threshold, and the comprehensive risk entropy value is less than the blocking threshold, then the trustee is authorized to have restricted access to the principal. If the context data does not satisfy any condition corresponding to the rule chain, and / or the comprehensive risk entropy value hits a preset rejection condition, then the trustee's access to the principal is rejected, including: If the context data does not meet any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value is not less than the blocking threshold, then the trustee's access to the principal is blocked, and a security alarm is triggered.

7. The method according to claim 6, characterized in that, The authorization of the trustee to access the principal includes: An access token is dynamically generated and sent to the trustee; the access token has a validity period of a preset duration, which is no longer than the entrusted validity period, which is part of the hosting policy sent by the entrusting party; The authorization of the trustee to have restricted access to the principal includes: A restricted token is generated and sent to the trustee; the access scope indicated by the restricted token is smaller than the access scope indicated by the access token.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: In response to the two-way authentication process initiated by the principal and the trustee based on the pre-recorded asymmetric key, two-way authentication is established with the principal and the trustee respectively; Upon completion of the two-way authentication, static attribute information sent by both the principal and the agent is received to complete the registration.

9. A cross-administration access control device, characterized in that, The device includes: The receiving module is used to receive access requests sent by the trustee for accessing the principal. The acquisition module is used to, in response to the access request, obtain the context data of this access based on the authorization credential corresponding to the principal if both the trustee and the principal have registered in the local hub; the authorization credential is used to authorize the trustee to access the principal; the context data includes risk characterization data of at least one dimension; The calculation module is used to calculate the risk entropy value corresponding to each of the said dimensions based on the risk characterization data, risk weights, and preset smoothing constants for each of the said dimensions; the risk entropy value corresponding to each of the said dimensions is positively correlated with the risk weights. The determination module is used to determine the comprehensive risk entropy value based on the risk entropy value corresponding to each of the dimensions; the comprehensive risk entropy value is positively correlated with the risk entropy value corresponding to each of the dimensions. An authorization module is used to authorize the trustee to access the principal if the context data satisfies the conditions corresponding to the rule chain and the comprehensive risk entropy value hits a preset authorization condition; the rule chain includes at least one rule, and one rule corresponds to one authorized access condition; The rejection module is used to reject the trustee's access to the principal if the context data does not meet any of the conditions corresponding to the rule chain, and / or the comprehensive risk entropy value hits a preset rejection condition.

10. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store executable instructions that cause the processor to perform the method as described in any one of claims 1 to 8.

11. A machine-readable medium, characterized in that, It stores instructions that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1 to 8.

Images