Security policy gray release, conflict checking and rollback method and system

Abstract

This invention discloses a method and system for canary deployment, conflict verification, and rollback of security policies, including a policy acceptance module, a device capability template library, a conflict verification module, a shadow pre-compilation module, a small batch release module, an operational indicator observation module, a reverse rollback module, and a version verification module. This invention uses device capability templates to uniformly describe the policy execution capabilities of different types of devices, completing capability matching and command conversion before policy deployment. This ensures that fixed broadband access devices and edge security gateways can correctly parse and execute the same security policy, avoiding security vulnerabilities caused by inconsistent policy execution across heterogeneous devices.

Description

Technical Field

[0001] This invention relates to the fields of network security operation and maintenance of fixed-mobile converged access networks, access device policy release, heterogeneous device policy conflict verification, small-batch gray-scale distribution, and policy rollback, specifically to methods and systems for gray-scale distribution of security policies, conflict verification, and rollback. Background Technology

[0002] With the rapid development of fixed-mobile converged network technology, the deep integration of fixed broadband access and mobile edge computing has become a core feature of next-generation access networks. In fixed-mobile converged access networks, fixed broadband access devices, mobile edge gateways, DNS security gateways, authentication systems, and edge security gateways together constitute a unified system for user access and security protection, requiring coordinated execution of security policies targeting the same user or the same area. Security policy management platforms, network management platforms, SDN controllers, or centralized firewall management systems serve as the core carriers for policy dissemination, typically possessing the ability to issue policies such as ACLs, rate limits, blacklists, whitelists, DNS redirection, isolated VLANs, and traffic mirroring to multiple network devices. Some systems also provide basic operational and maintenance functions such as batch dissemination, configuration backup, manual rollback, and device status query.

[0003] However, existing technologies have several insurmountable technical shortcomings in the security policy distribution scenario of fixed-mobile converged access networks. First, the types of devices in fixed-mobile converged access networks are complex and diverse. Fixed broadband access devices, mobile edge gateways, security gateways, and DNS gateways use different operating systems, command-line syntax, and policy execution engines, resulting in significant differences in the parsing methods, execution priorities, and activation mechanisms for the same security policy. If a traditional batch distribution method is used to directly send a policy in a uniform format to all target devices, it is highly likely that some devices will execute the policy successfully while others will fail, or even that policy actions on different devices will contradict each other, causing security vulnerabilities or service interruptions.

[0004] Secondly, the types of conflicts in security policies are complex and often subtle. The same user or the same business traffic may simultaneously trigger multiple security policies, involving various actions such as allowing, blocking, rate limiting, DNS redirection, and isolation. These actions may conflict directly or indirectly. For example, allowing and blocking policies issued simultaneously for the same IP address will create a hard conflict, preventing the policies from taking effect. A conflict between a DNS redirection policy for a basic business domain name and a basic business reservation rule can prevent users from accessing the network. Current technologies primarily rely on manual policy conflict verification, which is not only inefficient but also prone to overlooking potential conflicts due to human error, failing to guarantee the stability and accuracy of the verification results.

[0005] Third, the reliability of existing policy rollback mechanisms is insufficient. Traditional backup and rollback solutions only save the old configuration text of the device before the policy is issued. When an anomaly occurs during policy issuance, the old configuration is reissued to the device to achieve rollback. This approach has two problems: first, it cannot accurately prove which policy segment was successfully revoked, and the rollback operation may overwrite other normally issued policies at the same time; second, it lacks an effective rollback verification mechanism, making it impossible to confirm whether the device has been restored to the target rollback version, which may result in incomplete rollback and leave security vulnerabilities.

[0006] Fourth, the risk of a one-time full deployment of the policy is extremely high. In fixed-mobile converged access networks, anomalies in security policies can directly affect the normal operation of basic services such as user authentication, DNS resolution, and broadband access. If a full deployment method is adopted, any policy error will lead to large-scale service interruption, affecting all users corresponding to all target devices. Although the generalized canary deployment concept has been widely used in the field of software operation and maintenance, directly transplanting it to the security policy deployment scenario of fixed-mobile converged access networks cannot solve the unique problems such as inconsistent execution of heterogeneous devices, complex policy conflicts, and unverifiable rollbacks. Furthermore, the generalization of the solution can easily lead to a lack of creativity.

[0007] The closest existing technology to this invention involves a management platform generating security policies and then distributing these policies in batches to multiple network devices via a southbound interface. When service anomalies are detected, the policies are rolled back by restoring the devices' old configurations. This type of solution typically does not generate independent shadow pre-compiled results for each type of access device before policy release, nor does it bind each pre-compiled policy fragment to its corresponding reverse rollback fragment, version fingerprint, and small-batch release unit. This fails to form a complete closed loop from policy preprocessing, conflict verification, canary release to verifiable rollback, making it difficult to meet the high reliability and stability requirements of fixed-mobile converged access networks for security policy release. Summary of the Invention

[0008] The purpose of this invention is to provide a system for the canary distribution, conflict verification, and rollback of security policies, so as to solve the problems existing in the prior art.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a security policy gray-scale distribution, conflict verification, and rollback system, including a policy acceptance module, a device capability template library, a conflict verification module, a shadow pre-compilation module, a small batch release module, an operation indicator observation module, a reverse rollback module, and a version verification module; the system is designed for at least two types of access devices: fixed broadband access devices and edge security gateways; The policy acceptance module receives security policies to be published, converts them into standardized access security policy forms (ASPTs), and sends the ASPTs to the conflict verification module and the shadow pre-compilation module. The ASPT includes policy type, matching conditions, action, scope, fixed access device type, edge security device type, effective time, expiration time, basic service retention identifier, policy version fingerprint, and publication risk level. The action is limited to at least one of the following: ACL allow or block, rate limiting, DNS redirection, VLAN isolation, and traffic mirroring. The device capability template library is used to store device capability templates (DCTs) for various types of access devices; the DCTs record the policy actions, action priorities, command formats, readback commands, rollback capabilities, and basic service retention capabilities supported by each type of device; the device capability template library is communicatively connected to the shadow pre-compilation module; The conflict verification module is communicatively connected to the policy acceptance module and the device capability template library. It is used to receive ASPTs and detect conflicts between ASPTs and existing device policies based on the conflict item matrix CIM. The CIM includes allow / block conflicts, rate limiting / whitelist conflicts, DNS redirection / black hole conflicts, isolated VLAN / normal forwarding conflicts, and basic service reservation conflicts. The conflict verification module sends a pre-compilation license instruction to the shadow pre-compilation module only when there are no hard conflicts in the CIM check and the basic service reservation identifier in the ASPT is not overwritten. The shadow pre-compilation module is communicatively connected to the policy acceptance module, the device capability template library, and the conflict verification module. Upon receiving a pre-compilation license instruction, it generates a shadow pre-compilation result SPR for each target device based on the DCT. The SPR includes a device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, reverse rollback fragment IRF, and policy fragment summary. The IRF is a set of revocation or restoration commands automatically generated based on the current device's old policy and the policy fragment to be issued. The small batch release module is communicatively connected to the shadow pre-compilation module and is used to generate small batch release units (SBRUs) based on the access area, device type, user tag, and policy risk level. Each SBRU is limited to containing no more than a preset number of devices or access accounts. The small batch release module first sends the policy fragment to be released in the SPR to the first SBRU. After receiving the policy version fingerprint readback success signal from the version verification module, it enters the operation indicator observation stage. The operational metrics observation module is communicatively connected to the small-batch release module and the reverse rollback module, and is used to collect operational metrics of the devices corresponding to the released SBRUs within a preset observation period. The operational metrics include at least three of the following: authentication failure rate, DNS resolution failure rate, policy hit rate, number of device readback failures, number of user complaint alarms, and packet loss rate. If any basic business metric exceeds a preset stop threshold, the operational metrics observation module sends a rollback trigger command to the reverse rollback module and a stop subsequent release command to the small-batch release module. If all operational metrics do not exceed the preset threshold, the operational metrics observation module sends a continue release command to the small-batch release module. The reverse rollback module is communicatively connected to the operation indicator observation module, the shadow pre-compilation module, and the version verification module. It is used to send a rollback command to the device with the published policy according to the IRF bound in the SPR after receiving the rollback trigger instruction. The version verification module is communicatively connected to the small batch release module and the reverse rollback module. It is used to execute the expected readback command in SPR and read the current policy version fingerprint of the device. After the policy is issued, if the read version fingerprint is consistent with the policy version fingerprint in SPR, a readback success signal is sent to the small batch release module. After the rollback is executed, if the read version fingerprint is consistent with the rollback target version fingerprint, the rollback is marked as complete. If the read version fingerprint is inconsistent with the target version fingerprint, the corresponding device is added to the manual handling list, and a prohibition on further release is sent to the small batch release module.

[0010] Furthermore, the policy acceptance module specifically includes a policy parsing unit, an ASPT generation unit, and a policy distribution unit; Policy parsing unit: Used to receive security policies to be published from user input or third-party system push, and parse the core parameters of the policy, including the applicable device type, scope of application, matching rules and action. ASPT generation unit: used to convert the parsed policy parameters into a standardized ASPT format, assign a unique policy version fingerprint to each ASPT, determine the release risk level based on the policy's impact scope and the type of action to be taken, and add a basic business retention identifier; Policy distribution unit: Used to send the generated ASPT to the conflict checking module and the shadow pre-compilation module respectively, and record the ASPT generation time and distribution status.

[0011] Furthermore, the device capability template library specifically includes a template storage unit, a template management unit, and a capability matching unit; Template storage unit: used to store the DCT corresponding to all device types connected to the network. Each DCT is associated with a unique device type identifier. Template Management Unit: Used to support the addition, modification, deletion and query operations of DCT. When a new device type is added to the network or the capabilities of an existing device change, the corresponding DCT is updated. Capability matching unit: Used to retrieve the corresponding DCT from the template storage unit according to the fixed access device type and edge security device type specified in the ASPT, and send the DCT to the shadow pre-compilation module and conflict verification module.

[0012] Furthermore, the conflict verification module specifically includes a stock policy acquisition unit, a conflict detection unit, and a conflict processing unit; Existing policy acquisition unit: used to retrieve all currently effective existing policies from the configuration management database of each target device, and extract the matching conditions, handling actions and scope information of the existing policies; Conflict Detection Unit: Used to compare ASPT with all existing policies and detect whether there are hard conflicts and soft conflicts based on CIM; where hard conflicts refer to policy action conflicts that cannot be effective at the same time, and soft conflicts refer to policy priority conflicts that may affect the business experience. Conflict handling unit: When a hard conflict is detected, it generates a conflict detection report and terminates the pre-compilation process; when a soft conflict is detected, it generates a conflict prompt message and submits it for manual confirmation; after receiving the manual confirmation instruction, it sends a pre-compilation license instruction to the shadow pre-compilation module.

[0013] Furthermore, the shadow pre-compilation module specifically includes a device grouping unit, a policy conversion unit, an IRF generation unit, and an SPR encapsulation unit; Device grouping unit: used to divide the target devices into fixed broadband access device group and edge security gateway group according to the scope and device type in ASPT; Policy conversion unit: It is used to convert the general policy description in ASPT into a policy fragment to be issued that can be executed by the corresponding device according to the DCT of each group of devices, and generate an expected readback command for verifying whether the policy has been successfully issued. IRF generation unit: used to compare the policy fragment to be issued with the device's current old policy, and automatically generate an IRF for revoking the policy fragment to be issued and restoring the old policy state; SPR Encapsulation Unit: Used to encapsulate the device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, IRF, and policy fragment summary into an SPR, and send the SPR to the mini-batch release module.

[0014] Furthermore, the small batch release module specifically includes an SBRU generation unit, a policy distribution unit, and a release status management unit; SBRU generation unit: used to divide all target devices into multiple SBRUs based on the geographical division of the access area, the model batch of the device, the user's service tag, and the release risk level of ASPT; Policy delivery unit: Used to sequentially deliver the policy fragments to be delivered in the SPR to the devices in each SBRU according to the release order of the SBRU, and record the delivery time and delivery status of each device; Release Status Management Unit: Used to receive the readback results from the version verification module and the observation results from the operation indicator observation module, and manage the status of the entire release process, including pending release, release in progress, observation in progress, release completed, release terminated, and rollback in progress.

[0015] Furthermore, the operational indicator observation module specifically includes an indicator acquisition unit, a threshold judgment unit, and an instruction sending unit; The metrics collection unit is used to collect in real time the authentication failure rate, DNS resolution failure rate, policy hit rate, number of device readback failures, number of user complaint alarms, and packet loss rate of the devices corresponding to the published SBRU through the network management system, device network management interface, and user complaint system. Threshold judgment unit: used to compare the collected index values ​​with the preset stop threshold to determine whether there is any index abnormality; Command sending unit: When there is an abnormal indicator, it sends a rollback trigger command to the reverse rollback module and a stop subsequent release command to the small batch release module; when all indicators are normal, it sends a continue release command to the small batch release module.

[0016] Furthermore, the reverse rollback module specifically includes a rollback instruction generation unit, a rollback execution unit, and a rollback status recording unit; Rollback command generation unit: used to generate a sequence of rollback commands for each published device based on the IRF bound in the SPR; Rollback execution unit: Used to send rollback commands to devices that have published policies in sequence according to device identifier, and record the sending time and sending status of the rollback command for each device; Rollback Status Recording Unit: Used to receive the rollback verification results from the version verification module, record the rollback completion status of each device, and generate a rollback execution report.

[0017] The method for canary deployment of security policies, conflict verification, and system rollback includes the following steps: Step 1: System Initialization and Template Loading Start all system modules, load the DCT of all connected devices into the device capability template library, synchronize the existing policy information of all devices from the configuration management database, and enter standby state after the system completes initialization. Step 2: Generation and parsing of access security policy form The policy acceptance module receives the security policy to be released, parses the core parameters of the policy, generates a standardized ASPT, assigns a unique policy version fingerprint to the ASPT, determines the release risk level, and adds a basic business reservation identifier. Step 3: Policy feasibility verification based on device capability templates The device capability template library retrieves the corresponding DCT based on the fixed access device type and edge security device type specified in the ASPT; the shadow pre-compilation module determines whether the ASPT can be converted into both fixed broadband access device policy fragments and edge security gateway policy fragments based on the DCT; if they cannot be converted simultaneously, the release process is terminated and a capability mismatch report is generated; if they can be converted simultaneously, the conflict verification phase begins. Step 4: Policy Conflict Detection Based on Conflict Item Matrix The conflict verification module obtains the existing policies of all target devices, compares the ASPT with the existing policies, and detects whether there are hard conflicts and soft conflicts based on CIM. If there are hard conflicts, the release process is terminated and a conflict detection report is generated. If there are soft conflicts, manual confirmation is submitted. After receiving the manual confirmation instruction, the process enters the shadow pre-compilation stage. If there are no conflicts, the process directly enters the shadow pre-compilation stage. Step 5: Shadow pre-compilation result generation and binding The shadow pre-compilation module divides the target devices into fixed broadband access device groups and edge security gateway groups. Based on the DCT corresponding to each group of devices, the ASPT is converted into a policy fragment to be issued that can be executed by the corresponding device, and the expected readback command is generated. The policy fragment to be issued is compared with the old policy of the device, and the IRF is automatically generated. The device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, IRF and policy fragment summary are encapsulated into SPR. Step 6: Small-batch release unit division and first round of distribution The small batch deployment module divides all target devices into multiple SBRUs based on access area, device type, user tag, and policy risk level; according to the deployment order, it first sends the policy fragments to be deployed in the SPR to the devices in the first SBRU; Step 7: Strategy Issuance Verification and Operational Indicator Observation The version verification module executes the expected readback command in SPR to read the current policy version fingerprint of the device. If the version fingerprints do not match, the corresponding device is added to the manual handling list. If the version fingerprints match, the operation indicator observation phase begins. The operation indicator observation module collects the operation indicators of the released SBRU within a preset observation period. If any basic business indicator exceeds the stop threshold, the reverse rollback process is triggered. If all indicators are normal, the release process of the next SBRU begins. Step 8: Complete full deployment or reverse rollback. If all SBRUs are successfully published and their operating metrics are normal, the policy publication is marked as complete. If a reverse rollback process is triggered, the reverse rollback module sends a rollback command to the published devices based on the IRF bound in the SPR. The version verification module executes a readback command to read the policy version fingerprint after rollback. If the version fingerprint matches the rollback target version, the rollback is marked as complete. If they do not match, the device is added to the manual handling list and further publication is prohibited.

[0018] Compared with the prior art, the beneficial effects of the present invention are: This invention provides a unified description of the policy execution capabilities of different types of devices through device capability templates. Capability matching and command conversion are completed before policy issuance, ensuring that fixed broadband access devices and edge security gateways can correctly parse and execute the same security policy, thus avoiding security vulnerabilities caused by inconsistent policy execution among heterogeneous devices.

[0019] Based on the conflict item matrix, comprehensive detection of policy action conflicts and basic business retention conflicts can be performed. Potential conflict issues can be discovered before policy release, replacing the traditional manual verification method, improving the efficiency and accuracy of conflict verification, and reducing business anomalies caused by policy conflicts.

[0020] Before the policy is issued, an independent shadow pre-compiled result is generated for each device. The policy fragment to be issued is bound with the corresponding reverse rollback fragment and version fingerprint, which ensures the traceability of policy issuance and the accuracy of rollback, and avoids the impact of traditional full configuration rollback on other normal policies.

[0021] The target device is divided into multiple small batch release units and released sequentially. After each batch is released, the basic service operation indicators are monitored in real time. Once an anomaly is detected, subsequent releases are stopped immediately and a rollback is triggered, minimizing the impact of errors and ensuring the stable operation of basic services in the fixed-mobile converged access network.

[0022] After the policy is issued and rolled back, the policy version fingerprint of the device is read back for verification. This can accurately determine whether the policy was successfully issued or whether the rollback was thorough. This solves the problem that the traditional rollback mechanism cannot verify the rollback effect and ensures the reliability of policy operation and maintenance. Attached Figure Description

[0023] Figure 1 This is a system module diagram of the present invention; Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0024] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0025] Please see Figure 1-2 This invention provides a security policy canary deployment, conflict verification, and rollback system, including a policy acceptance module, a device capability template library, a conflict verification module, a shadow pre-compilation module, a small-batch release module, an operational indicator observation module, a reverse rollback module, and a version verification module. The system is designed for at least two types of access devices: fixed broadband access devices and edge security gateways. Fixed broadband access devices include, but are not limited to, optical line terminals (OLTs), optical network units (ONUs), and broadband access servers (BRAS); edge security gateways include, but are not limited to, mobile edge computing (MEC) gateways, edge firewalls, and DNS security gateways. The policy acceptance module receives security policies to be published, converts them into standardized access security policy forms (ASPTs), and sends the ASPTs to the conflict verification module and the shadow pre-compilation module. An ASPT includes policy type, matching conditions, action, scope, fixed access device type, edge security device type, effective time, expiration time, basic service reserved identifier, policy version fingerprint, and publication risk level. Actions are limited to at least one of the following: ACL allow or block, rate limiting, DNS redirection, VLAN isolation, and traffic mirroring. The Device Capability Template Library stores Device Capability Templates (DCTs) for various types of access devices. Each DCT records the policy actions, action priorities, command formats, readback commands, rollback capabilities, and basic service retention capabilities supported by each type of device. The Device Capability Template Library communicates with the Shadow Pre-compilation Module. The conflict verification module communicates with the policy acceptance module and the device capability template library to receive ASPTs and detect conflicts between ASPTs and existing policies of the device based on the conflict item matrix CIM. CIM includes allow / block conflicts, rate limiting / whitelist conflicts, DNS redirection / black hole conflicts, isolated VLAN / normal forwarding conflicts, and basic service reservation conflicts. The conflict verification module sends a pre-compilation license instruction to the shadow pre-compilation module only when there are no hard conflicts in the CIM check and the basic service reservation identifier in the ASPT is not overwritten. The shadow pre-compilation module communicates with the policy acceptance module, the device capability template library, and the conflict verification module. It is used to generate a shadow pre-compilation result SPR for each target device based on the DCT after receiving the pre-compilation license instruction. The SPR includes device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, reverse rollback fragment IRF, and policy fragment summary. The IRF is a set of revocation or restoration commands automatically generated based on the current device's old policy and the policy fragment to be issued. The small batch release module communicates with the shadow pre-compilation module to generate small batch release units (SBRUs) based on the access area, device type, user tag, and policy risk level. Each SBRU is limited to containing no more than a preset number of devices or access accounts. The small batch release module first sends the policy fragment to be released in the SPR to the first SBRU. After receiving the policy version fingerprint readback success signal from the version verification module, it enters the operation indicator observation stage. The operational metrics observation module communicates with the mini-batch release module and the reverse rollback module to collect operational metrics of the devices corresponding to the released SBRUs within a preset observation period. The operational metrics include at least three of the following: authentication failure rate, DNS resolution failure rate, policy hit rate, number of device readback failures, number of user complaint alarms, and packet loss rate. If any basic business metric exceeds the preset stop threshold, the operational metrics observation module sends a rollback trigger command to the reverse rollback module and a stop subsequent release command to the mini-batch release module. If all operational metrics do not exceed the preset threshold, the operational metrics observation module sends a continue release command to the mini-batch release module. The reverse rollback module communicates with the operation metric observation module, shadow pre-compilation module, and version verification module. It is used to send rollback commands to devices with published policies based on the IRF bound in SPR after receiving the rollback trigger instruction. The version verification module communicates with the mini-batch release module and the reverse rollback module. It is used to execute the expected readback command in SPR and read the current policy version fingerprint of the device. After the policy is issued, if the read version fingerprint is consistent with the policy version fingerprint in SPR, a readback success signal is sent to the mini-batch release module. After the rollback is executed, if the read version fingerprint is consistent with the rollback target version fingerprint, the rollback is marked as complete. If the read version fingerprint is inconsistent with the target version fingerprint, the corresponding device is added to the manual handling list, and a prohibition on further release is sent to the mini-batch release module.

[0026] The policy acceptance module specifically includes a policy parsing unit, an ASPT generation unit, and a policy distribution unit; Policy parsing unit: Used to receive security policies to be published from user input or third-party system push, and parse the core parameters of the policy, including the applicable device type, scope of application, matching rules and action. ASPT generation unit: used to convert the parsed policy parameters into a standardized ASPT format, assign a unique policy version fingerprint to each ASPT, determine the release risk level based on the policy's impact scope and the type of action to be taken, and add a basic business retention identifier; Policy distribution unit: Used to send the generated ASPT to the conflict checking module and the shadow pre-compilation module respectively, and record the ASPT generation time and distribution status.

[0027] The equipment capability template library specifically includes a template storage unit, a template management unit, and a capability matching unit; Template storage unit: used to store the DCT corresponding to all device types connected to the network. Each DCT is associated with a unique device type identifier. Template Management Unit: Used to support the addition, modification, deletion and query operations of DCT. When a new device type is added to the network or the capabilities of an existing device change, the corresponding DCT is updated. Capability matching unit: Used to retrieve the corresponding DCT from the template storage unit according to the fixed access device type and edge security device type specified in the ASPT, and send the DCT to the shadow pre-compilation module and conflict verification module.

[0028] The conflict verification module specifically includes a stock policy acquisition unit, a conflict detection unit, and a conflict processing unit; Existing policy acquisition unit: used to retrieve all currently effective existing policies from the configuration management database of each target device, and extract the matching conditions, handling actions and scope information of the existing policies; Conflict Detection Unit: Used to compare ASPT with all existing policies and detect whether there are hard conflicts and soft conflicts based on CIM; where hard conflicts refer to policy action conflicts that cannot be effective at the same time, and soft conflicts refer to policy priority conflicts that may affect the business experience. Conflict handling unit: When a hard conflict is detected, it generates a conflict detection report and terminates the pre-compilation process; when a soft conflict is detected, it generates a conflict prompt message and submits it for manual confirmation; after receiving the manual confirmation instruction, it sends a pre-compilation license instruction to the shadow pre-compilation module.

[0029] The shadow pre-compilation module specifically includes a device grouping unit, a policy conversion unit, an IRF generation unit, and an SPR encapsulation unit; Device grouping unit: used to divide the target devices into fixed broadband access device group and edge security gateway group according to the scope and device type in ASPT; Policy conversion unit: It is used to convert the general policy description in ASPT into a policy fragment to be issued that can be executed by the corresponding device according to the DCT of each group of devices, and generate an expected readback command for verifying whether the policy has been successfully issued. IRF generation unit: used to compare the policy fragment to be issued with the device's current old policy, and automatically generate an IRF for revoking the policy fragment to be issued and restoring the old policy state; SPR Encapsulation Unit: Used to encapsulate the device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, IRF, and policy fragment summary into an SPR, and send the SPR to the mini-batch release module.

[0030] The small batch release module specifically includes an SBRU generation unit, a policy distribution unit, and a release status management unit; SBRU generation unit: used to divide all target devices into multiple SBRUs based on the geographical division of the access area, the model batch of the device, the user's service tag, and the release risk level of ASPT; Policy delivery unit: Used to sequentially deliver the policy fragments to be delivered in the SPR to the devices in each SBRU according to the release order of the SBRU, and record the delivery time and delivery status of each device; Release Status Management Unit: Used to receive the readback results from the version verification module and the observation results from the operation indicator observation module, and manage the status of the entire release process, including pending release, release in progress, observation in progress, release completed, release terminated, and rollback in progress.

[0031] The operational indicator observation module specifically includes an indicator acquisition unit, a threshold judgment unit, and an instruction sending unit; The metrics collection unit is used to collect in real time the authentication failure rate, DNS resolution failure rate, policy hit rate, number of device readback failures, number of user complaint alarms, and packet loss rate of the devices corresponding to the published SBRU through the network management system, device network management interface, and user complaint system. Threshold judgment unit: used to compare the collected index values ​​with the preset stop threshold to determine whether there is any index abnormality; Command sending unit: When there is an abnormal indicator, it sends a rollback trigger command to the reverse rollback module and a stop subsequent release command to the small batch release module; when all indicators are normal, it sends a continue release command to the small batch release module.

[0032] The reverse rollback module specifically includes a rollback instruction generation unit, a rollback execution unit, and a rollback status recording unit; Rollback command generation unit: used to generate a sequence of rollback commands for each published device based on the IRF bound in the SPR; Rollback execution unit: Used to send rollback commands to devices that have published policies in sequence according to device identifier, and record the sending time and sending status of the rollback command for each device; Rollback Status Recording Unit: Used to receive the rollback verification results from the version verification module, record the rollback completion status of each device, and generate a rollback execution report.

[0033] A method for the canary distribution, conflict verification, and rollback of security policies in a fixed-mobile converged access network includes the following steps: Step 1: System Initialization and Template Loading Start all system modules, load the DCT of all connected devices into the device capability template library, synchronize the existing policy information of all devices from the configuration management database, and enter standby state after the system completes initialization. Step 2: Generation and parsing of access security policy form The policy acceptance module receives the security policy to be released, parses the core parameters of the policy, generates a standardized ASPT, assigns a unique policy version fingerprint to the ASPT, determines the release risk level, and adds a basic business reservation identifier. Step 3: Policy feasibility verification based on device capability templates The device capability template library retrieves the corresponding DCT based on the fixed access device type and edge security device type specified in the ASPT; the shadow pre-compilation module determines whether the ASPT can be converted into both fixed broadband access device policy fragments and edge security gateway policy fragments based on the DCT; if they cannot be converted simultaneously, the release process is terminated and a capability mismatch report is generated; if they can be converted simultaneously, the conflict verification phase begins. Step 4: Policy Conflict Detection Based on Conflict Item Matrix The conflict verification module obtains the existing policies of all target devices, compares the ASPT with the existing policies, and detects whether there are hard conflicts and soft conflicts based on CIM. If there are hard conflicts, the release process is terminated and a conflict detection report is generated. If there are soft conflicts, manual confirmation is submitted. After receiving the manual confirmation instruction, the process enters the shadow pre-compilation stage. If there are no conflicts, the process directly enters the shadow pre-compilation stage. Step 5: Shadow pre-compilation result generation and binding The shadow pre-compilation module divides the target devices into fixed broadband access device groups and edge security gateway groups. Based on the DCT corresponding to each group of devices, the ASPT is converted into a policy fragment to be issued that can be executed by the corresponding device, and the expected readback command is generated. The policy fragment to be issued is compared with the old policy of the device, and the IRF is automatically generated. The device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, IRF and policy fragment summary are encapsulated into SPR. Step 6: Small-batch release unit division and first round of distribution The small batch deployment module divides all target devices into multiple SBRUs based on access area, device type, user tag, and policy risk level; according to the deployment order, it first sends the policy fragments to be deployed in the SPR to the devices in the first SBRU; Step 7: Strategy Issuance Verification and Operational Indicator Observation The version verification module executes the expected readback command in SPR to read the current policy version fingerprint of the device. If the version fingerprints do not match, the corresponding device is added to the manual handling list. If the version fingerprints match, the operation indicator observation phase begins. The operation indicator observation module collects the operation indicators of the released SBRU within a preset observation period. If any basic business indicator exceeds the stop threshold, the reverse rollback process is triggered. If all indicators are normal, the release process of the next SBRU begins. Step 8: Complete full deployment or reverse rollback. If all SBRUs are successfully published and their operating metrics are normal, the policy publication is marked as complete. If a reverse rollback process is triggered, the reverse rollback module sends a rollback command to the published devices based on the IRF bound in the SPR. The version verification module executes a readback command to read the policy version fingerprint after rollback. If the version fingerprint matches the rollback target version, the rollback is marked as complete. If they do not match, the device is added to the manual handling list and further publication is prohibited.

[0034] Example 1: Gray-scale distribution and normal release process of ACL blocking policies This embodiment describes the complete process of issuing ACL blocking policies against malicious IP addresses in a fixed-mobile converged access network according to the present invention.

[0035] First, the system completes initialization, the device capability template library loads the DCTs of the OLT, ONU, BRAS and MEC gateways, the conflict verification module synchronizes the existing policy information of all devices, and the system enters standby mode.

[0036] The operations and maintenance personnel input the ACL blocking policy to be published through the system interface. The policy content is: block all traffic from the source IP address 192.168.1.100, with a scope covering all fixed broadband access devices and edge security gateways in area A, effective immediately, and expiration after 30 days. The policy parsing unit of the policy acceptance module parses the core parameters of the policy, determining that the policy type is an access control policy, the matching condition is the source IP address 192.168.1.100, the action is ACL blocking, the applicable fixed access device types are OLT and ONU, the applicable edge security device type is MEC gateway, and the scope is area A. The ASPT generation unit converts these parameters into a standardized ASPT, generates a unique policy version fingerprint, determines the publication risk level to be medium, and adds a basic service retention identifier, indicating that this policy will not affect basic services. The policy distribution unit sends the ASPT to the conflict verification module and the shadow pre-compilation module.

[0037] The capability matching unit of the device capability template library retrieves the DCTs of the OLT, ONU, and MEC gateways based on the device type in the ASPT. The policy conversion unit of the shadow pre-compilation module checks the DCTs and confirms that all three types of devices support ACL blocking actions, thus passing the policy feasibility verification.

[0038] The conflict verification module's existing policy acquisition unit obtains the existing policies of all OLTs, ONUs, and MEC gateways in Area A. The conflict detection unit compares the ASPT with the existing policies and detects conflicts based on CIM. The detection finds no hard or soft conflicts, such as allow / block conflicts or rate-limiting / whitelist conflicts. The conflict handling unit sends a pre-compilation license instruction to the shadow pre-compilation module.

[0039] The device grouping unit of the shadow pre-compilation module divides the target devices in Area A into a fixed broadband access device group (OLT and ONU) and an edge security gateway group (MEC gateway). The policy conversion unit converts the ASPT into executable ACL blocking command fragments based on the command format in the DCT corresponding to the OLT, ONU, and MEC gateway, and generates corresponding readback commands. The IRF generation unit compares the ACL blocking command to be issued with the old policies of each device to generate an IRF for revoking the ACL blocking command. The SPR encapsulation unit encapsulates each device's identifier, device type, ACL command to be issued, readback command, policy version fingerprint, IRF, and policy fragment digest into an SPR, and sends it to the mini-batch release module.

[0040] The SBRU generation unit of the small-batch deployment module divides all target devices into 5 SBRUs based on the access area division of Region A, device models, and deployment risk level (medium). Each SBRU contains no more than 5% of the total number of target devices. The deployment order follows the principle of edge to core, prioritizing ONU devices, then OLT devices, and finally MEC gateway devices. The policy distribution unit first sends the corresponding ACL blocking command fragment from the SPR to the ONU devices in the first SBRU.

[0041] The version verification module executes the expected readback command for each ONU device, reads the policy version fingerprint, and after verifying that the version fingerprints of all devices are consistent, sends a readback success signal to the small batch release module. The performance indicator observation module collects the authentication failure rate, DNS resolution failure rate, number of user complaint alarms, and packet loss rate of the device corresponding to the first SBRU within a preset 15-minute observation period. After testing, if all indicators do not exceed the preset stop threshold, a continue release command is sent to the small batch release module.

[0042] The batch deployment module sequentially distributes policies to the second through fifth SBRUs. After deployment to each SBRU, version verification and operational metrics are observed. Once all SBRUs have successfully deployed and their operational metrics are normal, the system marks the policy deployment as complete and generates a deployment report for submission to operations personnel.

[0043] Example 2: Process of DNS redirection policy issuance exception triggering rollback This embodiment describes the complete process of triggering a reverse rollback when an anomaly occurs during the distribution of a DNS redirection policy.

[0044] After system initialization, the operations and maintenance personnel input the DNS redirection policy to be published. The policy content is: redirect traffic accessing the domain name test.example.com to the security alert page, with a scope of all fixed broadband access devices and edge security gateways in Zone B, and an effective time of immediately. The policy acceptance module generates the corresponding ASPT, assigns a policy version fingerprint, determines the publication risk level to be medium, and adds a basic service reservation identifier.

[0045] The device capability template library retrieves the DCTs of the BRAS and DNS security gateway. The shadow pre-compilation module confirms that both types of devices support DNS redirection actions, and the feasibility verification is passed.

[0046] The conflict verification module detected conflicts between ASPT and existing policies. No hard conflicts were found, only one soft conflict: the domain name is partially similar to a basic business domain name, which may lead to false redirects. The conflict handling unit generated a conflict warning message, and after the operations and maintenance personnel confirmed that it could be published, the conflict verification module sent a pre-compiled license instruction.

[0047] The shadow pre-compilation module generates the SPR corresponding to each target device, which includes DNS redirection command fragments, readback commands, IRFs, and policy version fingerprints.

[0048] The small-batch release module divides the target devices in region B into four SBRUs, and first sends the policy to the BRAS devices in the first SBRU. The version verification module reads back the policy version fingerprint to confirm that the policy has been successfully released to all devices, and then enters the operational metric observation phase.

[0049] The operational metrics monitoring module collected operational metrics during the observation period and found that the DNS resolution failure rate exceeded the preset stop threshold. Analysis revealed that a policy configuration error caused some basic business domain names to be mistakenly redirected, leading to user DNS resolution failures. The operational metrics monitoring module immediately sent a rollback trigger command to the reverse rollback module and a stop subsequent release command to the small batch release module.

[0050] The rollback command generation unit of the reverse rollback module generates a rollback command sequence based on the IRF in the SPR corresponding to the device in the first SBRU. The rollback execution unit sends rollback commands to all BRAS devices with published policies. The version verification module executes a readback command to read the policy version fingerprint after rollback. After comparing the version fingerprints of all devices, if they are consistent with the rollback target version, the rollback is marked as complete. The system generates a rollback execution report, recording the triggering reason and result of the rollback, and submits it to the operations and maintenance personnel for policy correction.

[0051] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A security policy canary deployment, conflict verification, and rollback system, characterized by: The system includes a policy acceptance module, a device capability template library, a conflict verification module, a shadow pre-compilation module, a small batch release module, an operational indicator observation module, a reverse rollback module, and a version verification module; the system is designed for at least two types of access devices: fixed broadband access devices and edge security gateways; The policy acceptance module receives security policies to be published, converts them into standardized access security policy forms (ASPTs), and sends the ASPTs to the conflict verification module and the shadow pre-compilation module. The ASPT includes policy type, matching conditions, handling actions, scope, fixed access device type, edge security device type, effective time, expiration time, basic service retention identifier, policy version fingerprint, and publication risk level. The action is limited to at least one of the following: ACL allow or block, rate limiting, DNS redirection, VLAN isolation, and traffic mirroring. The device capability template library is used to store device capability templates (DCTs) for various types of access devices. The DCT records the policy actions, action priorities, command formats, readback commands, rollback capabilities, and basic service retention capabilities supported by each type of device; the device capability template library is communicatively connected to the shadow pre-compilation module. The conflict verification module is communicatively connected to the policy acceptance module and the equipment capability template library. It is used to receive ASPT and detect the conflict between ASPT and the equipment stock policy based on the conflict item matrix CIM. The CIM includes conflicts such as allow / block conflicts, rate limiting / whitelist conflicts, DNS redirection / black hole conflicts, isolated VLAN / normal forwarding conflicts, and basic service reservation conflicts. The conflict verification module sends a pre-compilation license instruction to the shadow pre-compilation module only when the CIM checks for no hard conflicts and the basic service reservation identifier in the ASPT is not overwritten. The shadow pre-compilation module is communicatively connected to the policy acceptance module, the device capability template library, and the conflict verification module. Upon receiving a pre-compilation license instruction, it generates a shadow pre-compilation result SPR for each target device based on the DCT. The SPR includes a device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, reverse rollback fragment IRF, and policy fragment summary. The IRF is a set of revocation or restoration commands automatically generated based on the current device's old policy and the policy fragment to be issued. The small batch release module is communicatively connected to the shadow pre-compilation module and is used to generate small batch release units (SBRUs) based on the access area, device type, user tag, and policy risk level. Each SBRU is limited to containing no more than a preset number of devices or access accounts. The small batch release module first sends the policy fragment to be released in the SPR to the first SBRU. After receiving the policy version fingerprint readback success signal from the version verification module, it enters the operation indicator observation stage. The operational metrics observation module is communicatively connected to the small-batch release module and the reverse rollback module, and is used to collect operational metrics of the devices corresponding to the released SBRUs within a preset observation period. The operational metrics include at least three of the following: authentication failure rate, DNS resolution failure rate, policy hit rate, number of device readback failures, number of user complaint alarms, and packet loss rate. If any basic business metric exceeds a preset stop threshold, the operational metrics observation module sends a rollback trigger command to the reverse rollback module and a stop subsequent release command to the small-batch release module. If all operational metrics do not exceed the preset threshold, the operational metrics observation module sends a continue release command to the small-batch release module. The reverse rollback module is communicatively connected to the operation indicator observation module, the shadow pre-compilation module, and the version verification module. It is used to send a rollback command to the device with the published policy according to the IRF bound in the SPR after receiving the rollback trigger instruction. The version verification module is communicatively connected to the small batch release module and the reverse rollback module. It is used to execute the expected readback command in SPR and read the current policy version fingerprint of the device. After the policy is issued, if the read version fingerprint is consistent with the policy version fingerprint in SPR, a readback success signal is sent to the small batch release module. After the rollback is executed, if the read version fingerprint is consistent with the rollback target version fingerprint, the rollback is marked as complete. If the read version fingerprint is inconsistent with the target version fingerprint, the corresponding device is added to the manual handling list, and a prohibition on further release is sent to the small batch release module.

2. The security policy gray-scale distribution, conflict verification, and rollback system according to claim 1, characterized in that: The policy acceptance module specifically includes a policy parsing unit, an ASPT generation unit, and a policy distribution unit; Policy parsing unit: Used to receive security policies to be published from user input or third-party system push, and parse the core parameters of the policy, including the applicable device type, scope of application, matching rules and action. ASPT generation unit: used to convert the parsed policy parameters into a standardized ASPT format, assign a unique policy version fingerprint to each ASPT, determine the release risk level based on the policy's impact scope and the type of action to be taken, and add a basic business retention identifier; Policy distribution unit: Used to send the generated ASPT to the conflict checking module and the shadow pre-compilation module respectively, and record the ASPT generation time and distribution status.

3. The security policy gray-scale distribution, conflict verification, and rollback system according to claim 1, characterized in that: The device capability template library specifically includes a template storage unit, a template management unit, and a capability matching unit; Template storage unit: used to store the DCT corresponding to all device types connected to the network. Each DCT is associated with a unique device type identifier. Template Management Unit: Used to support the addition, modification, deletion and query operations of DCT. When a new device type is added to the network or the capabilities of an existing device change, the corresponding DCT is updated. Capability matching unit: Used to retrieve the corresponding DCT from the template storage unit according to the fixed access device type and edge security device type specified in the ASPT, and send the DCT to the shadow pre-compilation module and conflict verification module.

4. The security policy gray-scale distribution, conflict verification, and rollback system according to claim 1, characterized in that: The conflict verification module specifically includes a stock policy acquisition unit, a conflict detection unit, and a conflict processing unit; Existing policy acquisition unit: used to retrieve all currently effective existing policies from the configuration management database of each target device, and extract the matching conditions, handling actions and scope information of the existing policies; Conflict detection unit: Used to compare ASPT with all existing strategies, and detect whether there are hard and soft conflicts based on CIM; Hard conflicts refer to conflicting strategies that cannot be implemented simultaneously, while soft conflicts refer to conflicting strategy priorities that may affect the business experience. Conflict handling unit: When a hard conflict is detected, it generates a conflict detection report and terminates the pre-compilation process; when a soft conflict is detected, it generates a conflict prompt message and submits it for manual confirmation; after receiving the manual confirmation instruction, it sends a pre-compilation license instruction to the shadow pre-compilation module.

5. The security policy gray-scale distribution, conflict verification, and rollback system according to claim 1, characterized in that: The shadow pre-compilation module specifically includes a device grouping unit, a policy conversion unit, an IRF generation unit, and an SPR encapsulation unit; Device grouping unit: used to divide the target devices into fixed broadband access device group and edge security gateway group according to the scope and device type in ASPT; Policy conversion unit: It is used to convert the general policy description in ASPT into a policy fragment to be issued that can be executed by the corresponding device according to the DCT of each group of devices, and generate an expected readback command for verifying whether the policy has been successfully issued. IRF generation unit: used to compare the policy fragment to be issued with the device's current old policy, and automatically generate an IRF for revoking the policy fragment to be issued and restoring the old policy state; SPR Encapsulation Unit: Used to encapsulate the device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, IRF, and policy fragment summary into an SPR, and send the SPR to the mini-batch release module.

6. The security policy gray-scale distribution, conflict verification, and rollback system according to claim 1, characterized in that: The small batch release module specifically includes an SBRU generation unit, a policy distribution unit, and a release status management unit; SBRU generation unit: used to divide all target devices into multiple SBRUs based on the geographical division of the access area, the model batch of the device, the user's service tag, and the release risk level of ASPT; Policy delivery unit: Used to sequentially deliver the policy fragments to be delivered in the SPR to the devices in each SBRU according to the release order of the SBRU, and record the delivery time and delivery status of each device; Release Status Management Unit: Used to receive the readback results from the version verification module and the observation results from the operation indicator observation module, and manage the status of the entire release process, including pending release, release in progress, observation in progress, release completed, release terminated, and rollback in progress.

7. The security policy gray-scale distribution, conflict verification, and rollback system according to claim 1, characterized in that: The operational indicator observation module specifically includes an indicator acquisition unit, a threshold judgment unit, and an instruction sending unit; Metrics collection unit: Used to collect in real time the authentication failure rate, DNS resolution failure rate, policy hit rate, number of device readback failures, number of user complaint alarms, and packet loss rate of devices corresponding to the published SBRU through the network management system, device network management interface, and user complaint system. Threshold judgment unit: used to compare the collected index values ​​with the preset stop threshold to determine whether there is any index abnormality; Command sending unit: When there is an abnormal indicator, it sends a rollback trigger command to the reverse rollback module and a stop subsequent release command to the small batch release module; when all indicators are normal, it sends a continue release command to the small batch release module.

8. The security policy gray-scale distribution, conflict verification, and rollback system according to claim 1, characterized in that: The reverse rollback module specifically includes a rollback instruction generation unit, a rollback execution unit, and a rollback status recording unit; Rollback command generation unit: used to generate a sequence of rollback commands for each published device based on the IRF bound in the SPR; Rollback execution unit: Used to send rollback commands to devices that have published policies in sequence according to device identifier, and record the sending time and sending status of the rollback command for each device; Rollback Status Recording Unit: Used to receive the rollback verification results from the version verification module, record the rollback completion status of each device, and generate a rollback execution report.

9. The method for the security policy gray-scale distribution, conflict verification, and rollback system according to any one of claims 1-8, characterized in that: Includes the following steps: Step 1: System Initialization and Template Loading Start all system modules, load the DCT of all connected devices into the device capability template library, synchronize the existing policy information of all devices from the configuration management database, and enter standby state after the system completes initialization. Step 2: Generation and parsing of access security policy form The policy acceptance module receives the security policy to be released, parses the core parameters of the policy, generates a standardized ASPT, assigns a unique policy version fingerprint to the ASPT, determines the release risk level, and adds a basic business reservation identifier. Step 3: Policy feasibility verification based on device capability templates The device capability template library retrieves the corresponding DCT based on the fixed access device type and edge security device type specified in the ASPT; the shadow pre-compilation module determines whether the ASPT can be converted into both fixed broadband access device policy fragments and edge security gateway policy fragments based on the DCT; if they cannot be converted simultaneously, the release process is terminated and a capability mismatch report is generated. If both can be converted simultaneously, then proceed to the conflict verification phase; Step 4: Policy Conflict Detection Based on Conflict Item Matrix The conflict verification module obtains the existing policies of all target devices, compares the ASPT with the existing policies, and detects whether there are hard conflicts and soft conflicts based on CIM. If a hard conflict exists, the release process is terminated and a conflict detection report is generated; if a soft conflict exists, manual confirmation is submitted, and the process proceeds to the shadow pre-compilation stage after receiving manual confirmation; if there is no conflict, the process proceeds directly to the shadow pre-compilation stage. Step 5: Shadow pre-compilation result generation and binding The shadow pre-compilation module divides the target devices into fixed broadband access device groups and edge security gateway groups. Based on the DCT corresponding to each group of devices, the ASPT is converted into a policy fragment to be issued that can be executed by the corresponding device, and the expected readback command is generated. Compare the policy fragment to be issued with the old policy of the device, and automatically generate an IRF; encapsulate the device identifier, device type, policy fragment to be issued, expected readback command, policy version fingerprint, IRF and policy fragment summary into an SPR; Step 6: Small-batch release unit division and first round of distribution The small batch deployment module divides all target devices into multiple SBRUs based on access area, device type, user tag, and policy risk level; according to the deployment order, it first sends the policy fragments to be deployed in the SPR to the devices in the first SBRU; Step 7: Strategy Issuance Verification and Operational Indicator Observation The version verification module executes the expected readback command in SPR to read the current policy version fingerprint of the device; if the version fingerprint does not match, the corresponding device is added to the manual handling list; if the version fingerprint matches, the operation indicator observation stage is entered. The operational metrics observation module collects operational metrics of the released SBRU within a preset observation period. If any basic business metric exceeds the stop threshold, a reverse rollback process is triggered; if all metrics are normal, the release process of the next SBRU begins. Step 8: Complete full deployment or reverse rollback. If all SBRUs are successfully published and their operating metrics are normal, the policy publication is marked as complete. If a reverse rollback process is triggered, the reverse rollback module sends a rollback command to the published devices based on the IRF bound in the SPR. The version verification module executes a readback command to read the policy version fingerprint after rollback. If the version fingerprint matches the target version, the rollback is marked as complete. If they do not match, the device is added to the manual handling list and further release is prohibited.

Images