Zero-trust engine fog deployment authentication system and its anti-down and anti-loss method

Abstract

This invention discloses an authentication system for zero-trust engine fogging deployment and its anti-downtime and anti-fragmentation methods in the field of power security technology. The system includes a cloud layer, a fog layer, and an end layer. The end layer is communicatively connected to the fog layer, and the fog layer is communicatively connected to the cloud layer. The end layer includes several power terminals connected to the 5G power IoT. The fog layer includes several fog computing areas deployed around the power terminals, and each fog computing area includes several fog node servers. The zero-trust engine includes PEP components, PE components, and PA components. The fog node servers are used to implement the master and secondary nodes of each component of the zero-trust engine, and each component of the zero-trust engine is deployed on different fog node servers. After authentication by the zero-trust engine fogging deployment around the power terminal, the power terminal obtains the specified service from the cloud layer. This invention can effectively prevent single-point failures of the zero-trust engine when facing massive terminal access, and improve the authentication efficiency when massive terminal access occurs.

Description

Technical Field

[0001] This invention belongs to the field of power safety technology, specifically relating to an authentication system for zero-trust engine atomization deployment and its methods for preventing downtime and trapping. Background Technology

[0002] With the widespread application of 5G technology in the power industry, the isolation of power terminals scattered across various regions has been broken, and a large number of power terminals are gradually being connected to the network. The increasing exposure of power terminals to the internet is blurring the security boundaries of the 5G power Internet of Things, posing a serious challenge to traditional network security defense systems characterized by boundary isolation.

[0003] In a 5G environment, once power terminals such as smart meters, inspection drones / robots, electricity meters, high-definition cameras, and smart charging piles are connected to the network, they lose the natural protection of physical isolation. Most power terminals often have limited computing and storage resources, are vulnerable to security vulnerabilities, and are located in complex and variable environments. Therefore, attackers can first compromise vulnerable power terminals for remote control, bypassing robust perimeter network security defenses, and then use compromised terminals as a springboard to move into the 5G power IoT, carrying out threats such as user credential abuse, APT attacks, supply chain attacks, unauthorized operations, and malicious code injection.

[0004] To address the shortcomings of perimeter network security defense systems, Zero Trust is gaining increasing attention in the industry. Zero Trust targets both external attackers who have already breached the network and malicious internal personnel. By assuming that compromise is inevitable or has already occurred, it adopts the principle of "never trust, always verify" for any user, terminal, or service, primarily blocking malicious data injection and preventing the theft of sensitive information within the network.

[0005] The draft standard "Zero Trust Network Architecture" released by the National Institute of Standards and Technology (NIST) states that zero trust security architecture is an end-to-end network / data protection approach, encompassing multiple aspects such as identity, credentials, access management, operations, endpoints, host environments, and interconnected infrastructure. For example... Figure 1As shown, the zero-trust security architecture mainly includes subjects, accessed resources, auxiliary systems, and the zero-trust engine. Subjects are user devices or terminals within the network that can access resources. They are configured with zero-trust clients for risk awareness, monitoring the security status of devices in real time. If suspicious behaviors such as unauthorized operations or malicious code injection occur, they will be immediately detected by the zero-trust client and the zero-trust gateway will be notified for interception. Accessed resources are resources that can be accessed and obtained within the network. In the entire zero-trust security architecture, the zero-trust engine is the core, composed of components such as the policy engine (PE), policy administrator (PA), and policy enforcement point (PEP).

[0006] The collaboration of these three zero-trust engine components constitutes the operating mechanism of the zero-trust security architecture, which mainly includes five steps: 1) Data and resource access requests issued by subjects during their activities within the network are packaged into authentication information by the zero-trust client and reported to the PEP component; 2) The PEP component, usually called the zero-trust gateway, forwards the reported authentication information to the PE component; 3) The PE component performs a comprehensive analysis based on the subject's authentication status, combined with factors such as the application, protocol, and encryption used, and authorizes its network activities and access requests, and sends the authorization result to the PA component and the PEP component; 4) For authorized subjects, the PA component generates an authentication token or credential and then gives it to the PEP component; 5) The PEP component decides whether to grant permission based on the authorization result and sends the authentication token or credential to the authorized subject.

[0007] As the core of the zero-trust security architecture, the zero-trust engine will face some technical challenges during deployment, as follows:

[0008] (1) The existing centralized deployment method that focuses on zero-trust engines is not suitable for 5G power Internet of Things. Frequent network activities or resource access requests from power terminals will generate massive amounts of authentication information, which may cause single-point failures in centralized zero-trust engines;

[0009] (2) If the centralized deployment of the zero trust engine is too far away from the power terminal, it is easy to delay the authentication time, which will be difficult to apply to the time-sensitive power environment and will not be conducive to the application of zero trust in the 5G power Internet of Things scenario.

[0010] (3) Regarding the network-wide monitoring responsibilities of the zero-trust engine, the attacker controlled some compromised terminals to generate a large number of normal data packets, which were automatically sent to the zero-trust engine via the zero-trust client. The attacker did not inject any malicious code or instructions into these data packets; the main purpose was to disable the zero-trust engine.

[0011] (4) All components of the zero-trust engine are deployed on a single service, which can easily generate a large workload. Once the system crashes or is controlled by an attacker, the zero-trust security architecture will fail and will be unable to monitor the network activity of the power terminal, thus giving the compromised terminal the opportunity to carry out potential internal threats. Summary of the Invention

[0012] To address the shortcomings of existing technologies, this invention provides an authentication system with zero-trust engine atomization deployment and its anti-downtime and anti-fragmentation methods, which can effectively prevent single-point failures when a large number of terminals access the system and improve authentication efficiency when a large number of terminals access the system.

[0013] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0014] Firstly, an authentication system for a zero-trust engine with fog-based deployment is provided, comprising a cloud layer, a fog layer, and an edge layer. The edge layer is communicatively connected to the fog layer, and the fog layer is communicatively connected to the cloud layer. The edge layer includes several power terminals connected to a 5G power IoT network. The fog layer includes several fog computing areas deployed around the power terminals, and each fog computing area includes several fog node servers. The zero-trust engine includes a PEP component, a PE component, and a PA component. The fog node servers are used to implement the master and slave nodes of each component of the zero-trust engine, and each component of the zero-trust engine is deployed on different fog node servers. After authentication by the zero-trust engine deployed around the power terminal via fog, the power terminal obtains the specified service from the cloud layer.

[0015] Furthermore, each of the power terminals connected to the Internet is configured with a zero-trust client.

[0016] Furthermore, the master node is responsible for responding to authentication information sent by the zero-trust client, intercepting and blocking suspicious access requests within the authorized scope, and submitting suspicious access requests that exceed the authorized scope to the cloud.

[0017] Furthermore, when the master node responsible for a component of the zero-trust engine crashes or becomes paralyzed, the relevant secondary nodes immediately start up.

[0018] Furthermore, the zero-trust engine also includes a policy regulator (PR) for real-time monitoring of the operation of the master nodes of the PEP, PE, and PA components of the zero-trust engine. The policy regulator (PR) accesses and correlates the operation data of all components of the zero-trust engine, and when a master node is found to be down, a new master node is selected from the relevant set of secondary nodes to continue working.

[0019] Furthermore, the PEP, PE, and PA components of the Zero Trust Engine generate three types of blockchains: PEP blockchain, PE blockchain, and PA blockchain, respectively.

[0020] Secondly, a method for preventing downtime in an authentication system deployed using a zero-trust engine is provided. Based on the zero-trust engine deployment authentication system described in the first aspect, when the policy supervisor (PR) detects that a master node has crashed, an equal random selection algorithm is used to select a new master node from the relevant set of secondary nodes to continue working. This includes: Step 1, Initially, the policy supervisor (PR) assigns a set of nodes to the three components of the zero-trust engine containing... g A set of random numbers containing 3 unique integers. R 1. R 2 and R 3; set R The random numbers in 1 are matched one-to-one with the PEP components. g Individual fog servers; Step 2: Arrange components according to the size of the random number to form a PEP component set. ZC PEP ={ PEP 1,…, PEP k ,…, PEP g};in, PEP 1 is the initial PEP master node, and the rest are in a standby state. g -1 PEP sub-node; similarly, the PE component set can be obtained. ZC PE ={ PE 1,…, PE k ,…, PE g} and PA component collection ZC PA ={ PA 1,…, PA k ,…, PA g Step 3: When the Policy Controller (PR) detects that the master node of a component has crashed, it sends an online notification to the next secondary node in the queue. Step 4: The secondary node in the priority standby state becomes the new master node after receiving the online notification and sends a priority standby command to the next secondary node. Step 5: The Policy Controller (PR) broadcasts the new master node's parent message to all zero-trust clients of power terminals in the fog computing area. Subsequent authentication information will be sent to the new master node. Step 6: After the crashed master node recovers, it is queued into the corresponding component set and becomes the last secondary node in that set.

[0021] Thirdly, a method for preventing the compromise of an authentication system deployed using a zero-trust engine is provided. Based on the zero-trust engine-deployed authentication system described in the first aspect, the method includes: Step 1: When the PEP component receives an access request from a power terminal, it synchronously triggers real-time monitoring by the policy regulator (PR); Step 2: While sending the comprehensive evaluation factors to the PE component, the PEP component also submits a copy of the comprehensive evaluation factors to the policy regulator (PR); Step 3: The authorization result of the PE component is shared with the policy regulator (PR) through the PE blockchain. If the policy regulator (PR) finds an error in the authorization result, the PE component is a compromised component; Step 4: The authorization credential generated by the PA component is shared with the policy regulator (PR) through the PA blockchain. If the policy regulator (PR) finds that the authorization credential does not match the authorization result, the PA component is a compromised component; Step 5: The access decision of the PEP component is shared with the policy regulator (PR) through the PEP blockchain. If the policy regulator (PR) finds that the access decision is not made by the authorization credential, the PEP component is a compromised component; Step 6: When the policy regulator (PR) finds that a component has been compromised, it immediately notifies the relevant component's priority standby secondary node to replace it.

[0022] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0023] (1) This invention deploys the zero trust engine around the power terminal in an atomized manner, while each component of the zero trust engine is deployed on a different fog node server; it shares the zero trust processing load of the centralized deployment and further improves the authentication efficiency of 5G power Internet of Things when facing massive terminal access, effectively preventing single point failures when massive terminal access is faced, and effectively preventing the threat of compromised terminals.

[0024] (2) This invention introduces a strategy supervisor (PR) to monitor the operation of the main nodes of the three components PEP, PE and PA in real time. It can quickly detect the main nodes that have crashed and select a new main node from the set of secondary nodes of the relevant components through an equal random selection algorithm to continue working.

[0025] (3) By introducing a policy monitor (PR), the present invention only views the main node operation data of the three components PE, PA and PEP, and does not receive any interaction and communication data from other users, devices and terminals, thus ensuring the PR's resistance to attacks.

[0026] (4) This invention uses a consortium blockchain to share operational data among the various component nodes and policy supervisors (PR) of the zero-trust engine, which facilitates tracking the operating status of the three components PE, PA and PEP, and allows the secondary nodes that are on standby to quickly replace the primary node and enter the working state in a timely manner, thus avoiding the failure of the zero-trust security architecture. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the security architecture of a zero-trust engine.

[0028] Figure 2 This is a schematic diagram of the system structure of an authentication system for zero-trust engine atomization deployment provided in an embodiment of the present invention;

[0029] Figure 3 This is a flowchart illustrating the equal random selection algorithm in an embodiment of the present invention;

[0030] Figure 4 This is a schematic diagram of the architecture of the zero-trust engine after introducing a policy supervisor in an embodiment of the present invention;

[0031] Figure 5 This is the defective component detection process in this embodiment of the invention. Detailed Implementation

[0032] The present invention will be further described below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of the present invention.

[0033] like Figure 2 As shown, this embodiment provides an authentication system for zero-trust engine atomization deployment for 5G power IoT, including a cloud layer, a fog layer, and an end layer. The end layer is communicatively connected to the fog layer, and the fog layer is communicatively connected to the cloud layer.

[0034] End Layer: The end layer consists of power terminals connected to the five major links of "generation, transmission, transformation, distribution, and consumption" in the 5G power IoT. Each power terminal connected to the Internet is equipped with a zero-trust client, which is responsible for monitoring the network activity and resource access requests of the power terminal. For suspicious behaviors such as unauthorized operations and malicious code injection, the zero-trust client directly notifies the PEP component (also known as the zero-trust gateway) for interception after monitoring and detection; for resource access requests where the suspicious situation cannot be determined, they need to be submitted to the zero-trust engine for comprehensive analysis.

[0035] Fog layer: Based on the business scope of the power Internet of Things, it can be divided into: m Each fog computing region (Fog1, Fog2, ..., Fogm) is assigned a fog computing region. nEach fog node server primarily consists of a master node and secondary nodes implementing the various components of the zero-trust engine. The master node is responsible for responding to authentication information sent by zero-trust clients. Suspicious requests identified through comprehensive analysis can be directly blocked. For resource access requests involving sensitive data, the authorization result needs to be submitted to the cloud layer to facilitate power terminal access. When the master node responsible for a component fails or becomes paralyzed, the relevant secondary nodes immediately start, ensuring the normal operation of the zero-trust engine's monitoring functions. The various components of the zero-trust engine are deployed on different fog node servers.

[0036] Cloud: After authentication by the zero-trust engine, power terminals can obtain data storage, resource access, and computing services from the cloud.

[0037] This embodiment deploys the zero-trust engine in a fog-like manner around power terminals to ensure the internal security of the 5G power IoT, and divides the area into multiple fog computing zones according to the scope of power services. Compared with the traditional centralized deployment of the zero-trust engine, the partitioned fog-like deployment can effectively alleviate the cloud authentication pressure. During the fog-like deployment process, the various components of the zero-trust engine are distributed and deployed at multiple points, and each is deployed on a different fog server, running its relevant functions independently. This can effectively prevent single-point failures when a large number of terminals access the network. Deploying the zero-trust engine in a fog-like manner around power terminals can avoid the authentication delay problem caused by the zero-trust engine being too far away from the power terminals. This is suitable for latency-sensitive power environments and is conducive to the application of the zero-trust engine in 5G power IoT scenarios.

[0038] To prevent single points of failure in the zero-trust engine, during fog deployment, each component should not only be deployed in a distributed, multi-point manner but also independently on different fog servers, running its relevant functions independently. Based on this, this embodiment introduces a Policy Regulator (PR) to monitor the real-time operation of the master nodes of the PEP, PE, and PA components. The Policy Regulator (PR) can access and correlate the operational data of all zero-trust engine components. When it detects a master node failure, it uses an equal random selection algorithm to select a new master node from the relevant set of secondary nodes to continue operation.

[0039] This embodiment also provides a method for preventing downtime in an authentication system deployed with a zero-trust engine fog. When the policy monitor (PR) detects that a master node has crashed, it uses an equal random selection algorithm to select a new master node from the relevant set of secondary nodes to continue working. Within a fog computing region, a set of zero-trust engine component nodes is defined. Γ ={ ZC PEP , ZC PE , ZC PA}.like Figure 3 As shown, the execution process of the equal random selection algorithm is as follows:

[0040] Step 1: Initially, the Policy Supervisor (PR) assigns the following to the three components of the Zero Trust Engine: g A set of random numbers containing 3 unique integers. R 1. R 2 and R 3; set R The random numbers in 1 are matched one-to-one with the PEP components. g One fog server;

[0041] Step 2: Arrange the components according to the size of the random number to form a PEP component set. ZC PEP ={ PEP 1,…, PEP k ,…, PEP g};in, PEP 1 is the initial PEP master node, and the rest are in a standby state. g -1 PEP sub-node; similarly, the PE component set can be obtained. ZC PE ={ PE 1,…, PE k ,…, PE g} and PA component collection ZC PA ={ PA 1,…, PA k ,…, PA g};

[0042] Step 3: When the policy monitor (PR) detects that the primary node of a component has crashed, it sends a notification to the subsequent secondary nodes to announce that they are back online; for example... PEP 1. When the system crashes, PEP Node 2 is a priority standby node, continuously awaiting the launch notification from the strategy monitor's PR, while also closely monitoring its status. PEP The operating status of 1; if PEP 2. Before the launch announcement, it was discovered that... PEP If the system is about to crash, you should promptly apply to the PR department of the strategy supervisor for a formal online notification.

[0043] Step 4: The secondary node in the priority standby state becomes the new primary node after receiving the online notification, and sends the priority standby command to its subsequent secondary nodes; for example, the secondary node in the priority standby state... PEP 2. Upon receiving the notification of going live, it becomes the new master node and then... PEP 3. Send a priority standby command to take over. PEP The position of 2;

[0044] Step 5: The Policy Controller (PR) broadcasts the new master node's parent node message to all zero-trust clients of the power terminals in the fog computing region. Subsequent authentication information will be sent to the new master node. For example, the Policy Controller (PR) broadcasts the parent node message to all zero-trust clients of the power terminals in the fog computing region. PEP 2. Message from the higher-level administrator: Subsequent authentication information will be sent to... PEP 2.

[0045] Step 6: After the failed master node recovers, it is added to the corresponding component set and becomes the last secondary node in that set. For example... PEP 1. After restoration, it will be placed into the collection. ZC PEP It becomes the last PEP sub-node.

[0046] To ensure that secondary nodes can quickly enter a working state after going online, a blockchain-assisted method is used to achieve data sharing between the primary and secondary nodes of the zero-trust engine component.

[0047] This embodiment introduces a policy monitor (PR) to monitor the operation of the master nodes of the three components PEP, PE, and PA in real time. It can quickly detect the failed master nodes and select a new master node from the set of secondary nodes of the relevant components through an equal random selection algorithm to continue working. The policy monitor (PR) introduced in this embodiment only views the operation data of the master nodes of the three components PE, PA, and PEP, and does not receive any interaction and communication data from other users, devices, or terminals, which can ensure the PR's resistance to attacks.

[0048] like Figure 4 As shown, three types of blockchains are generated from the PE component, PA component, and PEP component: PE blockchain (Per-blockchain), PA blockchain (Par-blockchain), and PEP blockchain (Pepr-blockchain). All of them have the characteristics of decentralized, traceable, tamper-proof, and pre-defined consensus nodes of consortium blockchains.

[0049] Per-blockchain is governed by the policy regulator PR and collection ZC PEPAll nodes jointly maintain the system. The PEP master node acts as the consensus head of the Per-blockchain, creating a new block from newly generated runtime data within a fixed time interval and broadcasting it to the Policy Supervisor (PR) and the remaining secondary nodes. In a similar manner, a joint maintenance and block generation mechanism for the Par-blockchain and the Pepr-blockchain can be achieved. Furthermore, to ensure the normal operation of the PR's monitoring function, the Policy Supervisor (PR) can consist of one compute-intensive fog server and three storage-intensive servers.

[0050] This embodiment also provides a method for preventing compromise in an authentication system deployed using a zero-trust engine with atomization. Combined with a blockchain-assisted data sharing method for zero-trust engine components, the policy regulator (PR) can detect compromised components controlled by attackers. For example... Figure 5 As shown, the compromised component detection process of the zero-trust engine is as follows:

[0051] Step 1: When the PEP component receives an access request initiated by the power terminal, it synchronously triggers the real-time monitoring of the policy regulator (PR).

[0052] Step 2: While sending the comprehensive evaluation factors to the PE component, the PEP component also submits a copy of the comprehensive evaluation factors to the policy regulator PR.

[0053] Step 3: The authorization result of the PE component is shared with the policy supervisor (PR) through the PE blockchain. If the policy supervisor (PR) finds that the authorization result is incorrect, the PE component is a compromised component.

[0054] Step 4: The authorization certificate generated by the PA component is shared with the policy supervisor (PR) through the PA blockchain. If the policy supervisor (PR) finds that the authorization certificate does not match the authorization result, then the PA component is a compromised component.

[0055] Step 5: The access decision of the PEP component is shared with the Policy Controller (PR) through the PEP blockchain. If the Policy Controller (PR) finds that the access decision is not made by the authorization credential, then the PEP component is a compromised component.

[0056] Step 6: When the policy monitor PR detects that a component has failed, it immediately notifies the relevant component's priority standby secondary node to be replaced.

[0057] This embodiment generates three types of blockchains—Per-blockchain, Par-blockchain, and Pepr-blockchain—for the PE, PA, and PEP components, respectively, and shares the data with the PR to enable the PR's monitoring function. Through the consortium blockchain, operational data is shared between the various component nodes of the zero-trust engine and the PR, facilitating the tracking of the operating status of the PE, PA, and PEP components. It also allows secondary nodes with priority to standby to quickly replace the primary node and promptly enter a working state, thus preventing the failure of the zero-trust security architecture.

[0058] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An authentication system for zero-trust engine atomization deployment, characterized in that, It includes a cloud layer, a fog layer, and an end layer, wherein the end layer is communicatively connected to the fog layer, and the fog layer is communicatively connected to the cloud layer; The end layer includes several power terminals that are connected to the 5G power Internet of Things; The fog layer includes several fog computing areas deployed around the power terminal, and each fog computing area includes several fog node servers; the zero trust engine includes PEP components, PE components and PA components, and the fog node servers are used to implement the master node and secondary node functions of each component of the zero trust engine, and each component of the zero trust engine is deployed on different fog node servers. The power terminal obtains the specified service from the cloud after authentication by a zero-trust engine deployed around it. The master node is responsible for responding to authentication information sent by the zero-trust client, blocking suspicious access requests within the authorized scope, and submitting suspicious access requests that exceed the authorized scope to the cloud. When the master node responsible for a component of the zero-trust engine crashes or becomes paralyzed, the relevant secondary nodes immediately start up.

2. The authentication system for zero-trust engine atomization deployment according to claim 1, characterized in that, Each of the power terminals connected to the Internet is configured with a zero-trust client.

3. The authentication system for zero-trust engine atomization deployment according to claim 1, characterized in that, The zero-trust engine also includes a policy supervisor (PR), which is used to monitor the operation of the master nodes of the PEP, PE, and PA components of the zero-trust engine in real time. The policy supervisor (PR) accesses and correlates the operation data of all components of the zero-trust engine. When a master node is found to be down, a new master node is selected from the relevant set of secondary nodes to continue working.

4. The authentication system for zero-trust engine atomization deployment according to claim 3, characterized in that, The Zero Trust Engine's PEP, PE, and PA components generate three types of blockchains: PEP blockchain, PE blockchain, and PA blockchain.

5. A method for preventing downtime in an authentication system deployed using a zero-trust engine atomization, characterized in that, Based on the zero-trust engine atomization deployment authentication system described in claim 3, when the policy supervisor (PR) detects that a master node has crashed, it activates an equal random selection algorithm to select a new master node from the relevant set of secondary nodes to continue working, including: Step 1: Initially, the Policy Supervisor (PR) assigns the following to the three components of the Zero Trust Engine: g A set of random numbers containing 3 unique integers. R 1. R 2 and R 3; set R The random numbers in 1 are matched one-to-one with the PEP components. g One fog server; Step 2: Arrange the components according to the size of the random number to form a PEP component set. ZC PEP ={ PEP 1,…, PEP k ,…, PEP g };in, PEP 1 is the initial PEP master node, and the rest are in a standby state. g -1 PEP sub-node; similarly, the PE component set can be obtained. ZC PE ={ PE 1,…, PE k ,…, PE g } and PA component collection ZC PA ={ PA 1,…, PA k ,…, PA g }; Step 3: When the Policy Monitor (PR) detects that the master node of a component has crashed, it sends an online notification to the subsequent secondary nodes. Step 4: The secondary node in the priority standby state becomes the new primary node after receiving the online notification, and sends the priority standby command to the subsequent secondary nodes. Step 5: The Policy Regulator (PR) broadcasts the new master node's parent message to all zero-trust clients of the power terminals in the fog computing region. Subsequent authentication information will be sent to the new master node. Step 6: After the crashed master node is restored, it is placed into the corresponding component set and becomes the last secondary node in that set.

6. A method for preventing compromise in an authentication system deployed using a zero-trust engine atomization, characterized in that, An authentication system based on a zero-trust engine atomization deployment as described in claim 4 includes: Step 1: When the PEP component receives an access request initiated by the power terminal, it synchronously triggers the real-time monitoring of the policy regulator (PR). Step 2: While sending the comprehensive evaluation factors to the PE component, the PEP component also submits a copy of the comprehensive evaluation factors to the policy regulator PR. Step 3: The authorization result of the PE component is shared with the policy supervisor (PR) through the PE blockchain. If the policy supervisor (PR) finds that the authorization result is incorrect, the PE component is a compromised component. Step 4: The authorization certificate generated by the PA component is shared with the policy supervisor (PR) through the PA blockchain. If the policy supervisor (PR) finds that the authorization certificate does not match the authorization result, then the PA component is a compromised component. Step 5: The access decision of the PEP component is shared with the Policy Controller (PR) through the PEP blockchain. If the Policy Controller (PR) finds that the access decision is not made by the authorization certificate, then the PEP component is a compromised component. Step 6: When the policy monitor PR detects that a component has failed, it immediately notifies the relevant component's priority standby secondary node to be replaced.

Images