A management and control method, device, medium and product for producing a disaster recovery firewall

Abstract

The application discloses a kind of production disaster recovery firewall management and control method, equipment, medium and product, the method includes: first, obtain two application programs of the firewall policy to be deployed, and according to the inter-visit relationship between two, two application programs are identified as upstream application and downstream application respectively;Subsequently, the network area where upstream application and downstream application are respectively located is obtained, if both are located in the preset disaster recovery support management area, then deploy the first firewall policy between upstream and downstream, further obtain the environmental attribute of two, environmental attribute is divided into production environment and disaster recovery environment;When the environmental attribute of two is same, still deploy the first firewall policy;When the environmental attribute of two is different, then deploy the second firewall policy, the technical scheme of the embodiment of the application can ensure that production and disaster recovery environment daily safety isolation premise, realizes the quick and accurate effect of firewall policy in emergency scene.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a management method, device, medium, and product for a production disaster recovery firewall. Background Technology

[0002] As the digital transformation of the financial industry deepens and business continuity requirements continue to rise, financial institutions have generally built complex IT architectures such as dual-active systems within the same city and disaster recovery systems in different locations. The coexistence of production centers and disaster recovery centers has become the norm, which has dramatically complicated the network access relationships between applications and posed unprecedented challenges to firewall policy management.

[0003] Current technologies primarily rely on manual processes and static configuration management for the aforementioned strategies, which has significant drawbacks. First, policy synchronization is severely lagging. When policies are activated daily to meet production needs, there is a lack of a mandatory mechanism requiring the simultaneous submission of policies equivalent to those in the disaster recovery environment. This results in widespread missing or outdated disaster recovery firewall policies, creating a risk of drill failures. Second, management efficiency is low. Before each disaster recovery drill, significant manpower is required to coordinate upstream and downstream application teams, manually collecting, verifying, and organizing server addresses and port information across environments. This communication cost is enormous and prone to errors. Therefore, an intelligent management method is urgently needed to address the issues of completeness, accuracy, and real-time performance of disaster recovery firewall policies. Summary of the Invention

[0004] This invention provides a method, device, medium, and product for managing production and disaster recovery firewalls, enabling automated hierarchical management and control of production and disaster recovery firewalls, ensuring daily isolation and rapid emergency switching.

[0005] According to one aspect of the present invention, a management method for a production disaster recovery firewall is provided, the method comprising: Obtain the two applications for which the firewall policy to be deployed, and identify the two applications as an upstream application and a downstream application respectively based on the mutual access relationship between the two applications; The network regions where the upstream and downstream applications are located are obtained. If both the upstream and downstream applications are located in a preset disaster recovery support management zone, a first firewall policy is deployed between the upstream and downstream applications. The first firewall policy is used to control the two applications to make normal point-to-point connections. If the upstream or downstream application is not located in the disaster recovery support management area, the environmental attributes of the upstream and downstream applications are obtained respectively, including the production environment or the disaster recovery environment. When the environmental attributes of the upstream application and the downstream application are consistent, a first firewall policy is deployed between the upstream application and the downstream application. When the environmental attributes of the upstream application and the downstream application are inconsistent, a second firewall policy is deployed between the upstream application and the downstream application; wherein, the second firewall policy is used to control the two applications to open connections during the exercise and block connections when the exercise ends.

[0006] According to another aspect of the present invention, a management and control device for a production disaster recovery firewall is provided, the device comprising: The application acquisition module is used to acquire two applications for the firewall policy to be deployed, and to identify the two applications as an upstream application and a downstream application respectively based on the mutual access relationship between the two applications. The management zone determination module is used to obtain the network zones where the upstream application and the downstream application are located respectively. If both the upstream application and the downstream application are located in the preset disaster recovery support management zone, a first firewall policy is deployed between the upstream application and the downstream application. The first firewall policy is used to control the two applications to conduct normal point-to-point connections. The non-management area determination module is used to obtain the environmental attributes of the upstream application and the downstream application respectively if the upstream application or the downstream application is not located in the disaster recovery support management area. The environmental attributes include production environment or disaster recovery environment. The same environment policy deployment module is used to deploy a first firewall policy between the upstream application and the downstream application when the environment attributes of the upstream application and the downstream application are consistent. The cross-environment policy deployment module is used to deploy a second firewall policy between the upstream application and the downstream application when the environment attributes of the upstream application and the downstream application are inconsistent; wherein, the second firewall policy is used to control the two applications to open connections during the exercise and block connections when the exercise ends.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the management method of the production disaster recovery firewall according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the management method of the production disaster recovery firewall as described in any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0010] The technical solution of this invention involves acquiring two applications for which a firewall policy needs to be deployed, and identifying them as an upstream application and a downstream application based on their mutual access relationship. The network areas where the upstream and downstream applications are located are then acquired. If both applications are located in a preset disaster recovery support management area, a first firewall policy is deployed between them. This first firewall policy controls the two applications to maintain normal point-to-point connections. If neither application is located in the disaster recovery support management area, the environmental attributes of the upstream and downstream applications are acquired, including production or disaster recovery environments. When the environmental attributes of the upstream and downstream applications are consistent, the first firewall policy is deployed between them. When their environmental attributes are inconsistent, a second firewall policy is deployed between them. This second firewall policy controls the two applications to open connections during drills and to block connections at the end of the drills. This solution addresses the complexity of disaster recovery firewall policy management and achieves beneficial effects such as improved management efficiency, ensuring daily security isolation, and rapid emergency connectivity.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0013] Figure 1 This is a flowchart of a management method for a production disaster recovery firewall provided according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of another management method for a production disaster recovery firewall provided according to Embodiment 2 of the present invention; Figure 3 This is an automated flowchart of external connection management for a production disaster recovery firewall in a specific scenario applicable to the embodiments of the present invention; Figure 4This is a schematic diagram of a cross-environment access strategy logic in a specific scenario applicable to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a management and control device for a production disaster recovery firewall provided according to Embodiment 3 of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device that implements a management method for a production disaster recovery firewall according to an embodiment of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of 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 skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1 This is a flowchart of a management and control method for a production disaster recovery firewall provided in Embodiment 1 of the present invention. This embodiment is applicable to scenarios where firewall policies between production and disaster recovery environments are automatically and hierarchically managed. The method can be executed by a management and control device for the production disaster recovery firewall, which can be implemented in hardware and / or software and is generally configured in an electronic device.

[0017] Correspondingly, such as Figure 1 As shown, the method includes: S110. Obtain the two applications for which the firewall policy is to be deployed, and identify the two applications as an upstream application and a downstream application respectively based on the mutual access relationship between the two applications.

[0018] In this embodiment, the roles of the two applications are first determined based on their registered or requested service calls, transaction requests, and other mutual access relationships. The party that actively initiates the access request is identified as the upstream application, while the party that receives and responds to the request is identified as the downstream application.

[0019] Furthermore, based on the above embodiments, before obtaining the firewall policy to be deployed from the two applications, the following may also be included: Based on the business attributes and communication link complexity of each application, select all applications from among them that require firewall policies to be deployed.

[0020] Generally, before deploying specific firewall policies for inter-application communication, it's necessary to pre-identify key applications requiring granular control from among numerous applications. The selection criteria primarily include two aspects: first, the application's own business attributes, i.e., its criticality and importance in business operations; and second, the complexity of the application's communication links, i.e., the quantity and complexity of its interactions with upstream and downstream applications in the overall business transaction chain. By comprehensively evaluating these two dimensions, applications that carry core business functions, would have a significant impact if interrupted, and are tightly coupled with numerous other applications will be selected as the primary targets for subsequent granular firewall policy deployment and management in both production and disaster recovery environments.

[0021] S120. Obtain the network areas where the upstream application and the downstream application are located respectively. If both the upstream application and the downstream application are located in a preset disaster recovery support management area, then deploy a first firewall policy between the upstream application and the downstream application. The first firewall policy is used to control the two applications to conduct normal point-to-point connections.

[0022] In this embodiment, after identifying the upstream and downstream applications, it is necessary to further verify their respective pre-assigned network areas. If both the upstream and downstream applications are located in a specific area dedicated to managing and supporting applications, namely the disaster recovery support management area, it indicates that this mutual access falls within the scope of operation and maintenance management. For such access, in order to ensure the continuity of cross-environment management functions, a long-term effective point-to-point primary firewall policy will be directly deployed for it, allowing it to communicate normally without additional scenario-based control.

[0023] Furthermore, based on the above embodiments, before obtaining the network area attributes where the upstream and downstream applications are located, the following may also be included: Obtain multiple predefined network area attributes, including: production critical base area, production non-critical base area, disaster recovery critical base area, disaster recovery non-critical base area, disaster recovery support management area, and management application area; Among them, the production critical infrastructure area is used to carry critical infrastructure applications for the production environment, the production non-critical infrastructure area is used to carry non-critical infrastructure applications for the production environment, the disaster recovery critical infrastructure area is used to carry critical infrastructure applications for the disaster recovery environment, the disaster recovery non-critical infrastructure area is used to carry non-critical infrastructure applications for the disaster recovery environment, the disaster recovery support and management area is used to carry independent disaster recovery environment applications that support the operation and management functions of the disaster recovery environment, and the management application area is used to carry management support applications. Based on the environment attributes of each application and the rules for dividing each network zone, the network zone where each application is located is determined.

[0024] Generally, before implementing specific firewall policies, it is necessary to first establish a logically clear and standardized network architecture model. This model is achieved by pre-defining multiple logical network zones, each with its specific functions and carrying requirements. These zones form the foundational framework for all subsequent automated judgments and policy enforcement.

[0025] Generally, the defined network zones are clearly divided. The production critical zone is specifically designed to host the most critical infrastructure applications in the production environment, which form the cornerstone of business operations. The production non-critical zone hosts non-critical infrastructure applications of relatively lower importance in the production environment. Correspondingly, the disaster recovery critical zone hosts copies of critical infrastructure applications in the disaster recovery environment that are equivalent to those in the production critical zone, while the disaster recovery non-critical zone hosts disaster recovery copies of non-critical applications. In addition, a separate disaster recovery support management zone is established, specifically for running the various management platforms and tools required to support the entire disaster recovery environment. Simultaneously, a management application zone is established to host common management support applications that need to serve both the production and disaster recovery environments.

[0026] Generally, after defining network zones, each specific application instance needs to be assigned to its corresponding logical zone. This assignment is primarily based on two core elements: first, the environmental attributes of the application instance, i.e., whether it belongs to a production environment or a disaster recovery environment; and second, the application's importance level within the business architecture. For example, a critical infrastructure application running in a production environment would be designated as the Production Critical Infrastructure Zone. In this way, a clear and standardized location identifier is established for each application instance.

[0027] S130. If the upstream application or the downstream application is not located in the disaster recovery support management area, then obtain the environmental attributes of the upstream application and the downstream application respectively. The environmental attributes include the production environment or the disaster recovery environment.

[0028] In this embodiment, if either the upstream or downstream application is not located in the disaster recovery support management area, it indicates that the mutual access involves actual business applications. In this case, it is necessary to further determine the runtime environment category of each of the two applications, that is, to determine whether each application instance is currently deployed and running in a production environment processing real transactions, or deployed in a disaster recovery environment used for backup and takeover.

[0029] S140. When the environmental attributes of the upstream application and the downstream application are consistent, deploy a first firewall policy between the upstream application and the downstream application.

[0030] In this embodiment, when the upstream and downstream applications are in the same runtime environment—that is, both in the production environment or the disaster recovery environment—it means that the access occurs within a logically isolated environment. For example, this could be application interaction within the production environment or a closed-loop transaction formed for business-level drills within the disaster recovery environment. For such internal accesses, to support daily business operations or verification activities within the disaster recovery environment, firewall policies allowing for routine point-to-point access will be deployed to ensure network connectivity within the environment.

[0031] S150. When the environmental attributes of the upstream application and the downstream application are inconsistent, a second firewall policy is deployed between the upstream application and the downstream application; wherein, the second firewall policy is used to control the two applications to open connections during the exercise and to block connections when the exercise ends.

[0032] In this embodiment, when the upstream and downstream applications reside in different runtime environments—one in the production environment and the other in the disaster recovery environment—a special access scenario exists that crosses the production and disaster recovery environments. Such access must be strictly prohibited during routine business operations to prevent interference between production and disaster recovery transactions. Therefore, a second firewall policy will be deployed for this scenario. This policy remains isolated for most of the time, only being temporarily activated upon receiving a drill instruction matching the drill tag, thus enabling emergency network connectivity between the production center and the disaster recovery center. Isolation is restored immediately after the drill concludes.

[0033] The technical solution of this invention obtains the two applications to which the firewall policy is to be deployed, identifies the upstream and downstream applications based on their mutual access relationship, and then obtains the network area attributes corresponding to each. If both the upstream and downstream applications are located in a preset disaster recovery support management area, a firewall policy that allows normal point-to-point access is deployed between them. If neither the upstream nor the downstream application is located in the disaster recovery support management area, the environmental attributes of each application are obtained. When both environmental attributes are production environments or both are disaster recovery environments, a firewall policy that allows normal point-to-point access is deployed. When the environmental attributes are inconsistent, a firewall policy that is only enabled during drills and remains isolated during daily operation is deployed. This solves the problems of disaster recovery firewall policies being easily overlooked in daily operations, low efficiency of manual review before drills, and inability to meet the requirements for rapid switching. It achieves significant beneficial effects such as ensuring policy integrity and accuracy, greatly reducing operation and maintenance communication and management costs, and realizing secure isolation and rapid emergency connectivity between production and disaster recovery environments.

[0034] Example 2 Figure 2 This is a flowchart of another management method for a production disaster recovery firewall provided in Embodiment 2 of the present invention. This embodiment is based on and optimized from the above embodiments. Specifically, the operation of "identifying the two applications as an upstream application and a downstream application respectively according to the mutual access relationship between the two applications" has been refined.

[0035] Correspondingly, such as Figure 2 As shown, the method includes: S210, two applications that obtain the firewall policy to be deployed.

[0036] S220. In the metadata management system, filter the application service call relationship and business interaction link data that match the two applications.

[0037] In this embodiment, to accurately determine the access relationship between two applications, it is necessary to query and filter information directly related to these two specific applications in the metadata management repository. This information mainly includes the registered application service call relationships between the two, as well as more macro-level business transaction interaction link data. By obtaining this predefined and managed metadata, authoritative and accurate factual basis can be provided for subsequent determination of the master-slave access direction between applications, avoiding errors that may arise from relying on human memory or ad-hoc communication.

[0038] S230. Based on the application service call relationship and business interaction link data, the application that actively initiates service calls or transaction requests in the two applications is identified as the upstream application, and the application that passively receives requests or provides service responses is identified as the downstream application.

[0039] In this embodiment, after understanding the specific service calls and business interactions between two applications, their roles in each specific access event can be clearly identified. By analyzing the acquired call relationships and interaction chains, it is possible to determine which party is the initiator of the transaction or the caller of the service in a specific business scenario or service request; this party is identified as the upstream application. Correspondingly, which party is the recipient of the request, the provider of the service, or the responder of the transaction is identified as the downstream application. This identification method based on actual data records ensures the objectivity and accuracy of upstream and downstream roles, laying the foundation for subsequently deploying differentiated firewall control strategies for different directions.

[0040] S240. Obtain the network areas where the upstream application and the downstream application are located respectively. If both the upstream application and the downstream application are located in a preset disaster recovery support management area, then deploy a first firewall policy between the upstream application and the downstream application. The first firewall policy is used to control the two applications to conduct normal point-to-point connections.

[0041] S250. If the upstream application or the downstream application is not located in the disaster recovery support management area, then the environmental attributes of the upstream application and the downstream application are obtained respectively. The environmental attributes include the production environment or the disaster recovery environment.

[0042] S260. When the environmental attributes of the upstream application and the downstream application are consistent, deploy a first firewall policy between the upstream application and the downstream application.

[0043] S270. When the environmental attributes of the upstream application and the downstream application are inconsistent, a second firewall policy is deployed between the upstream application and the downstream application; wherein, the second firewall policy is used to control the two applications to open connections during the exercise and to block connections when the exercise ends.

[0044] Optionally, based on the above embodiments, deploying a second firewall policy between the upstream application and the downstream application may include: Obtain the first network region where the source network address of the upstream application is located, and the second network region where the destination network address of the downstream application is located; Based on the first network region, the second network region, and the preset tag mapping rules, determine the exercise tags that match the upstream and downstream applications; A second firewall policy is constructed based on the exercise label, and the second firewall policy is submitted to the firewall server; wherein, the exercise label is used to guide the firewall server to activate the configuration of the second firewall policy when it receives an exercise instruction that matches the exercise label.

[0045] Generally, after determining that an exercise label needs to be added to a cross-environment firewall policy, the first step is to parse the network addresses of the initiator and receiver involved in the policy. By comparing these network addresses with the address ranges of predefined logical network zones, it is possible to determine which network zone the communication source is located in and which network zone the communication destination is located in.

[0046] Generally, after identifying the network regions where the source and destination regions are located, a set of predefined tagging rules will be used to automatically match and add a specific type of exercise tag to the strategy based on different combinations of the source and destination regions. For example, if the source region belongs to the production critical base region or the production non-critical base region, and the destination region belongs to the disaster recovery critical base region, then a critical base region exercise tag will be added; if the destination region belongs to the disaster recovery non-critical base region, then a non-critical base region exercise tag will be added; if the source region comes from the disaster recovery environment and the destination region points to the production environment, then the corresponding exercise tag will also be added according to the type of the destination region.

[0047] Generally, after tagging is completed, the firewall policy assigned a specific exercise tag enters the pending execution state. This policy is submitted to the firewall server and configured with a special activation mode: for the vast majority of daily operation, the policy is essentially in an isolated state, not allowing any network traffic to pass through; only when the firewall server receives a formal exercise instruction that exactly matches the tag type it carries will the policy be temporarily activated, allowing point-to-point network communication, and the isolation will be restored after the instruction ends.

[0048] Optionally, based on the above embodiments, determining the exercise tags matching the upstream and downstream applications according to the first network region, the second network region, and preset tag mapping rules may include: If the first network region is a production critical base region or a production non-critical base region, and the second network region is a disaster recovery critical base region, then the exercise tag will be determined as a critical base load exercise tag. If the first network region is a production-critical region or a production-non-critical region, and the second network region is a disaster recovery-non-critical region, then the exercise tag is determined to be a non-critical load exercise tag. If the first network region is a disaster recovery critical base region or a disaster recovery non-critical base region, and the second network region is a production critical base region or a production non-critical base region, then the exercise tag will be determined as a critical base load exercise tag or a non-critical base load exercise tag.

[0049] Generally, when a communication originates from any production area and is destined for a critical infrastructure area in the disaster recovery environment, it indicates that the access may be an application in the production environment attempting to access a core application of equal importance in the disaster recovery environment. To manage such cross-environment access involving critical business operations, a critical infrastructure takeover exercise tag is added to this firewall policy. This tag is specifically used to mark and control exercise traffic related to critical infrastructure takeover.

[0050] Generally, when a communication source is identified as originating from any production area, while the destination points to a non-critical infrastructure area in the disaster recovery environment, this indicates that an application in the production environment is attempting to access an application of relatively lower importance in the disaster recovery environment. For such cross-environment accesses that are not core business operations, a "non-baseband-related exercise" tag will be added to the policy. This tag is used to distinguish and manage exercise traffic related to non-critical infrastructure, enabling tiered control.

[0051] Generally, when it's identified that the communication originates from a region within the disaster recovery environment and points to a region within the production environment, this typically corresponds to a scenario where the disaster recovery environment attempts to take over production operations or perform a write-back during a drill. Although the access direction is reversed, the necessity for control and the scenario classification are similar. Therefore, a corresponding drill tag is added based on the disaster recovery region type of the destination: if the destination is a disaster recovery critical zone, a critical zone with load drill tag is added; if the destination is a disaster recovery non-critical zone, a non-critical zone with load drill tag is added. This ensures that cross-environment access of the same service level, regardless of direction, is subject to unified control using the same type of tag.

[0052] Based on the above embodiments, after deploying a first firewall policy or a second firewall policy between the upstream application and the downstream application, the method may further include: Continuously acquire the environmental attributes of the upstream and downstream applications; When the environmental attributes of the upstream application and / or downstream application change, return to execute the operation of obtaining the environmental attributes of the upstream application and downstream application respectively; After successfully deploying the new firewall policy between the upstream and downstream applications, a firewall policy change notification is sent to the application stakeholders of the upstream and downstream applications.

[0053] Generally, to ensure that all deployed firewall policies remain consistent with the actual application environment, a continuous information synchronization mechanism is needed. This mechanism continuously monitors or periodically checks the runtime environment attributes of upstream and downstream applications, determining whether each application instance is currently in a production or disaster recovery environment. This continuous acquisition aims to detect any changes in application environment attributes in real-time or near real-time, such as an application switching from a production environment to a disaster recovery environment, thus providing the latest data foundation for subsequent automatic adjustments.

[0054] Generally, once the above mechanism detects a change in the environmental attributes of an upstream or downstream application—for example, if an application changes from a production environment to a disaster recovery environment—the entire firewall policy judgment process will be automatically triggered and re-executed. This means that the platform will re-obtain the environmental attributes of the application and its associated applications based on the new environmental attributes after the application's change, and then re-perform subsequent policy judgments and deployments according to the latest environmental attributes to ensure that all affected firewall policies are updated in a timely and accurate manner.

[0055] Generally, after the automated redeployment of all affected firewall policies is completed, to ensure management transparency and collaborative efficiency, a notification will be proactively sent to relevant personnel. Specifically, the notification will be sent to the responsible party of the application whose environment attributes have changed, as well as to the responsible parties of all other related applications that have mutual access relationships with this application and whose firewall policies have been updated accordingly. The notification aims to inform them that due to the change in application environment attributes, the relevant access control policies have been automatically adjusted by the platform, enabling them to be promptly informed of the changes and make corresponding business or operational preparations.

[0056] The technical solution of this invention involves: acquiring two applications for which a firewall policy needs to be deployed; filtering application service call relationships and business interaction link data that match the two applications in a metadata management system; identifying the application that actively initiates service calls or transaction requests as the upstream application and the application that passively receives requests or provides service responses as the downstream application based on the application service call relationships and business interaction link data; acquiring the network areas where the upstream and downstream applications are located respectively; if both are located in a preset disaster recovery support management area, deploying a first firewall policy between the upstream and downstream applications, wherein the first firewall policy is used to control the two applications to conduct normalized point-to-point connections; if the upstream or downstream application is not located in the disaster recovery support management area, acquiring their environmental attributes respectively; deploying the first firewall policy when the environmental attributes are consistent; deploying a second firewall policy when the environmental attributes are inconsistent, wherein the second firewall policy is used to control the two applications to open connections during the exercise and block connections at the end of the exercise, thereby solving the problem of low efficiency and error-proneness caused by relying on manual sorting of application call relationships, and achieving the beneficial effect of automatically and objectively identifying upstream and downstream roles based on metadata and improving the accuracy and efficiency of policy generation.

[0057] In this specific embodiment, to address the problems faced by large financial institutions due to the complexity of their dual-active architecture for production and disaster recovery, which leads to a surge in the number of cross-environment firewall policies, easy omissions in manual management, low coordination efficiency before drills, and inability to meet the requirements for rapid disaster recovery switchover, existing technologies have limitations in policy synchronization, sorting, and activation. These limitations include high reliance on manual processes, static and fragmented workflows, and a lack of intelligent prediction and dynamic control capabilities. Consequently, these technologies suffer from pain points such as difficulty in ensuring policy consistency, high operation and maintenance costs, and slow emergency response. This embodiment of the invention designs a complete hierarchical collaborative control method for production and disaster recovery firewalls based on intelligent network area identification, automated policy splitting, and dynamic management of drill tags.

[0058] Specifically, Figure 3 The flowchart for the automated management of external connections to the production disaster recovery firewall provided in this embodiment of the invention is as follows: Figure 3As shown, this process covers the entire chain from rule base construction to policy final implementation and result feedback. First, in the rule base construction phase, the system forms a baseline rule base based on production firewall policies and uses traffic probes and business inter-visibility data from the production environment for big data modeling and cleaning to accurately identify high-level application sets that need to be included in management. Next, in the rule conversion and disaster recovery mapping phase, the system verifies the data center affiliation of the identified applications and intelligently determines the policy's effective period based on application attributes (distinguishing between daily operations and drills). Based on this, the system verifies the compliance of policy communication relationships and further identifies the corresponding mapped applications and specific network area attributes on the disaster recovery side to ensure the accuracy of cross-environment policies. Finally, in the policy orchestration and distribution phase, the system generates native firewall configuration scripts, which are manually reviewed and confirmed before being distributed to core switches and firewall devices for execution, and the policy view is updated synchronously. Finally, the implementation results are fed back to the disaster recovery management end, achieving closed-loop management throughout the entire process.

[0059] Specifically, Figure 4 This is a schematic diagram of the cross-environment access strategy logic provided in an embodiment of the present invention, such as... Figure 4 As shown in the diagram, this visually illustrates the infrastructure of the production and disaster recovery environments under network isolation, as well as the data flow during drill takeover. The left side shows the network topology under normal isolation. The disaster recovery area to the left of the red line carries disaster recovery application C and the disaster recovery management terminal, while the production area to the right carries production application A and production application B. Direct connections are blocked by physical or logical isolation devices. Based on this, the system constructs dedicated secure communication channels, such as a control channel allowing the disaster recovery management terminal to unidirectionally access disaster recovery application C, and a dedicated drill link connecting production application A and disaster recovery application C. The right side shows the policy logic when a drill is triggered. When a drill command is received, the firewall policy takes effect, establishing a link between production and disaster recovery. This allows disaster recovery application C to cross the isolation boundary and take over some functions or data interactions of production application B, while the disaster recovery management terminal maintains global visibility. This achieves the goal of meeting the needs for rapid business takeover and verification in disaster recovery drill scenarios while ensuring daily security isolation.

[0060] Example 3 Figure 5 This is a schematic diagram of the structure of a management and control device for a production disaster recovery firewall provided in Embodiment 4 of the present invention, as shown below. Figure 5 As shown, the device includes: Application acquisition module 510 is used to acquire two applications for the firewall policy to be deployed, and to identify the two applications as an upstream application and a downstream application respectively based on the mutual access relationship between the two applications. The management area judgment module 520 is used to obtain the network areas where the upstream application and the downstream application are located respectively. If both the upstream application and the downstream application are located in the preset disaster recovery support management area, a first firewall policy is deployed between the upstream application and the downstream application. The first firewall policy is used to control the two applications to make normal point-to-point connections. The non-management area judgment module 530 is used to obtain the environmental attributes of the upstream application and the downstream application respectively if the upstream application or the downstream application is not located in the disaster recovery support management area. The environmental attributes include the production environment or the disaster recovery environment. The same environment policy deployment module 540 is used to deploy a first firewall policy between the upstream application and the downstream application when the environment attributes of the upstream application and the downstream application are consistent. The cross-environment policy deployment module 550 is used to deploy a second firewall policy between the upstream application and the downstream application when the environment attributes of the upstream application and the downstream application are inconsistent; wherein, the second firewall policy is used to control the two applications to open connections during the exercise and block connections when the exercise ends.

[0061] The technical solution of this invention involves acquiring two applications for which a firewall policy needs to be deployed, and identifying them as an upstream application and a downstream application based on their mutual access relationship. The network areas where the upstream and downstream applications are located are then acquired. If both applications are located in a preset disaster recovery support management area, a first firewall policy is deployed between them. This first firewall policy controls the two applications to maintain normal point-to-point connections. If neither application is located in the disaster recovery support management area, the environmental attributes of the upstream and downstream applications are acquired, including production or disaster recovery environments. When the environmental attributes of the upstream and downstream applications are consistent, the first firewall policy is deployed between them. When their environmental attributes are inconsistent, a second firewall policy is deployed between them. This second firewall policy controls the two applications to open connections during drills and to block connections at the end of the drills. This solution addresses the complexity of disaster recovery firewall policy management and achieves beneficial effects such as improved management efficiency, ensuring daily security isolation, and rapid emergency connectivity.

[0062] Based on the above embodiments, a management and control device for a production disaster recovery firewall may further include: The filtering module is used to filter out all applications for which firewall policies need to be deployed, based on the business attributes and communication link complexity of each application, before obtaining the two applications for which firewall policies need to be deployed.

[0063] Based on the above embodiments, a management and control device for a production disaster recovery firewall may further include: The module for obtaining multiple network regions is used to obtain multiple predefined network region attributes before obtaining the network region attributes where the upstream application and the downstream application are located, respectively. The network region attributes include: production critical base area, production non-critical base area, disaster recovery critical base area, disaster recovery non-critical base area, disaster recovery support management area, and management application area. Among them, the production critical infrastructure area is used to carry critical infrastructure applications for the production environment, the production non-critical infrastructure area is used to carry non-critical infrastructure applications for the production environment, the disaster recovery critical infrastructure area is used to carry critical infrastructure applications for the disaster recovery environment, the disaster recovery non-critical infrastructure area is used to carry non-critical infrastructure applications for the disaster recovery environment, the disaster recovery support and management area is used to carry independent disaster recovery environment applications that support the operation and management functions of the disaster recovery environment, and the management application area is used to carry management support applications. The network zone determination module is used to determine the network zone where each application is located based on the environment attributes of each application and the network zone division rules.

[0064] Optionally, based on the above embodiments, the application module 510 is obtained, specifically used for: In the metadata management system, filter application service call relationships and business interaction link data that match the two applications; Based on the application service call relationship and business interaction link data, the application that actively initiates service calls or transaction requests in the two applications is identified as the upstream application, and the application that passively receives requests or provides service responses is identified as the downstream application.

[0065] Furthermore, based on the above embodiments, the cross-environment policy deployment module 550 includes: The regional positioning submodule is used to obtain the first network region where the source network address of the upstream application is located, and the second network region where the destination network address of the downstream application is located; The tag determination submodule is used to determine the exercise tags that match the upstream and downstream applications based on the first network region, the second network region, and preset tag mapping rules. The policy construction submodule is used to construct a second firewall policy based on the exercise labels and submit the second firewall policy to the firewall server. The exercise label is used to instruct the firewall server to activate the second firewall policy configuration when it receives an exercise instruction that matches the exercise label.

[0066] Optionally, based on the above embodiments, the label determination submodule is specifically used for: If the first network region is a production critical base region or a production non-critical base region, and the second network region is a disaster recovery critical base region, then the exercise tag will be determined as a critical base load exercise tag. If the first network region is a production-critical region or a production-non-critical region, and the second network region is a disaster recovery-non-critical region, then the exercise tag is determined to be a non-critical load exercise tag. If the first network region is a disaster recovery critical base region or a disaster recovery non-critical base region, and the second network region is a production critical base region or a production non-critical base region, then the exercise tag will be determined as a critical base load exercise tag or a non-critical base load exercise tag.

[0067] Furthermore, based on the above embodiments, a management and control device for a production disaster recovery firewall may further include: The continuous acquisition module is used to continuously acquire the environmental attributes of the upstream and downstream applications after deploying the first firewall policy or the second firewall policy between the upstream and downstream applications. The environment change backtracking module is used to return and execute the operation of obtaining the environment attributes of the upstream application and / or downstream application respectively when the environment attributes of the upstream application and / or downstream application change; The change notification sending module is used to send firewall policy change notifications to the application affiliates of the upstream and downstream applications after successfully deploying a new firewall policy between the upstream and downstream applications.

[0068] The production disaster recovery firewall management and control device provided in the embodiments of the present invention can execute the production disaster recovery firewall management and control method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0069] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0070] Example 4 Figure 6 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0071] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0072] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0073] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as performing a management method for a production disaster recovery firewall as described in any embodiment of the present invention, namely: Obtain the two applications for which the firewall policy to be deployed, and identify the two applications as an upstream application and a downstream application respectively based on the mutual access relationship between the two applications; The network regions where the upstream and downstream applications are located are obtained. If both the upstream and downstream applications are located in a preset disaster recovery support management zone, a first firewall policy is deployed between the upstream and downstream applications. The first firewall policy is used to control the two applications to make normal point-to-point connections. If the upstream or downstream application is not located in the disaster recovery support management area, the environmental attributes of the upstream and downstream applications are obtained respectively, including the production environment or the disaster recovery environment. When the environmental attributes of the upstream application and the downstream application are consistent, a first firewall policy is deployed between the upstream application and the downstream application. When the environmental attributes of the upstream application and the downstream application are inconsistent, a second firewall policy is deployed between the upstream application and the downstream application; wherein, the second firewall policy is used to control the two applications to open connections during the exercise and block connections when the exercise ends.

[0074] In some embodiments, a management method for a production disaster recovery firewall as described in any one of the embodiments of the present invention can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the management method for a production disaster recovery firewall as described above as described in any one of the embodiments of the present invention can be performed. Alternatively, in other embodiments, processor 11 can be configured by any other suitable means (e.g., by means of firmware) to perform the management method for a production disaster recovery firewall as described in any one of the embodiments of the present invention.

[0075] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0076] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0077] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0078] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0079] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0080] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0081] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0082] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A management and control method for a production disaster recovery firewall, characterized in that, The method includes: Obtain the two applications for which the firewall policy to be deployed, and identify the two applications as an upstream application and a downstream application respectively based on the mutual access relationship between the two applications; The network regions where the upstream and downstream applications are located are obtained. If both the upstream and downstream applications are located in a preset disaster recovery support management zone, a first firewall policy is deployed between the upstream and downstream applications. The first firewall policy is used to control the two applications to make normal point-to-point connections. If the upstream or downstream application is not located in the disaster recovery support management area, the environmental attributes of the upstream and downstream applications are obtained respectively, including the production environment or the disaster recovery environment. When the environmental attributes of the upstream application and the downstream application are consistent, a first firewall policy is deployed between the upstream application and the downstream application. When the environmental attributes of the upstream application and the downstream application are inconsistent, a second firewall policy is deployed between the upstream application and the downstream application; wherein, the second firewall policy is used to control the two applications to open connections during the exercise and block connections when the exercise ends.

2. The method according to claim 1, characterized in that, Before the two applications obtain the firewall policy to be deployed, the following are also included: Based on the business attributes and communication link complexity of each application, select all applications from among them that require firewall policies to be deployed.

3. The method according to claim 1, characterized in that, Before obtaining the network region attributes where the upstream and downstream applications are located, the process also includes: Obtain multiple predefined network area attributes, including: production critical base area, production non-critical base area, disaster recovery critical base area, disaster recovery non-critical base area, disaster recovery support management area, and management application area; Among them, the production critical infrastructure area is used to carry critical infrastructure applications for the production environment, the production non-critical infrastructure area is used to carry non-critical infrastructure applications for the production environment, the disaster recovery critical infrastructure area is used to carry critical infrastructure applications for the disaster recovery environment, the disaster recovery non-critical infrastructure area is used to carry non-critical infrastructure applications for the disaster recovery environment, the disaster recovery support and management area is used to carry independent disaster recovery environment applications that support the operation and management functions of the disaster recovery environment, and the management application area is used to carry management support applications. Based on the environment attributes of each application and the rules for dividing each network zone, the network zone where each application is located is determined.

4. The method according to claim 1, characterized in that, Based on the mutual access relationship between the two applications, the two applications are identified as an upstream application and a downstream application, respectively, including: In the metadata management system, filter application service call relationships and business interaction link data that match the two applications; Based on the application service call relationship and business interaction link data, the application that actively initiates service calls or transaction requests in the two applications is identified as the upstream application, and the application that passively receives requests or provides service responses is identified as the downstream application.

5. The method according to claim 3, characterized in that, Deploy a second firewall policy between upstream and downstream applications, including: Obtain the first network region where the source network address of the upstream application is located, and the second network region where the destination network address of the downstream application is located; Based on the first network region, the second network region, and the preset tag mapping rules, determine the exercise tags that match the upstream and downstream applications; A second firewall policy is constructed based on the exercise labels, and the second firewall policy is submitted to the firewall server. The exercise label is used to instruct the firewall server to activate the second firewall policy configuration when it receives an exercise instruction that matches the exercise label.

6. The method according to claim 5, characterized in that, Based on the first network region, the second network region, and preset tag mapping rules, determine the exercise tags that match the upstream and downstream applications, including: If the first network region is a production critical base region or a production non-critical base region, and the second network region is a disaster recovery critical base region, then the exercise tag will be determined as a critical base load exercise tag. If the first network region is a production-critical region or a production-non-critical region, and the second network region is a disaster recovery-non-critical region, then the exercise tag is determined to be a non-critical load exercise tag. If the first network region is a disaster recovery critical base region or a disaster recovery non-critical base region, and the second network region is a production critical base region or a production non-critical base region, then the exercise tag will be determined as a critical base load exercise tag or a non-critical base load exercise tag.

7. The method according to any one of claims 1-6, characterized in that, After deploying a first firewall policy or a second firewall policy between the upstream application and the downstream application, the method further includes: Continuously acquire the environmental attributes of the upstream and downstream applications; When the environmental attributes of the upstream application and / or downstream application change, return to execute the operation of obtaining the environmental attributes of the upstream application and downstream application respectively; After successfully deploying the new firewall policy between the upstream and downstream applications, a firewall policy change notification is sent to the application stakeholders of the upstream and downstream applications.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the management method of the production disaster recovery firewall according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the management method of the production disaster recovery firewall as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the management method of the production disaster recovery firewall according to any one of claims 1-7.

Images