KR102745167B1 - Method and system for detecting and recovering firewall-related failure - Google Patents

Abstract

The present disclosure relates to a method and system for detecting and recovering from a failure related to a firewall. According to some embodiments of the present disclosure, a method for detecting and recovering from a failure related to a firewall, performed by at least one computing device, may include the steps of: obtaining real IP information for an instance associated with a policy of the firewall from a cloud service server; obtaining dynamic IP information of each of the instances referenced by the firewall, wherein the dynamic IP information is provided by an external module; comparing the real IP information with the dynamic IP information; and determining whether or not failure recovery related to the firewall is necessary based on a result of the comparison.

Description

METHOD AND SYSTEM FOR DETECTING AND RECOVERING FIREWALL-RELATED FAILURE

The present disclosure relates to a method and system for detecting and recovering from a failure related to a firewall. More specifically, the present disclosure relates to a method for detecting and recovering from a failure related to a firewall by using an instance associated with a policy of the firewall and dynamic IP information provided by an external module, and a system to which the method is applied.

A firewall can operate based on multiple filtering rules for packets entering the firewall or packets transmitted from the internal network to the outside. At this time, multiple filtering rules usually define the conditions of packets that are the target of filtering. For example, whether or not to filter can be determined based on the IP band.

The IP of an instance located inside or outside the firewall may change dynamically depending on various situations. For example, the IP of an instance on a cloud service may change due to a reset of the instance, a self-failure recovery of the cloud service, or a software deployment. In this case, if the IP of the instance changes, the existing firewall rule or policy may be invalidated. Accordingly, according to the conventional technology, a process of synchronizing the changed IP address of a specific instance using a separate IP synchronization module is used to ensure that the firewall operates normally even if the IP of an instance related to the firewall rule or policy changes.

However, if a separate IP synchronization module fails, the IP address of the changed instance may not be reflected, which may cause the firewall to not function properly. In other words, the firewall may abnormally block packets.

Accordingly, a technology is required that can support normal operation of the firewall even if a malfunction occurs in the function of the IP synchronization module.

Korean Patent Publication No. 10-2017-0053433 (Published on May 16, 2017)

The technical problem that the present disclosure seeks to solve is to provide a method and system capable of detecting a failure related to a firewall and automatically recovering the failure.

Another technical problem that the present disclosure seeks to solve is to provide a method and system capable of detecting a failure related to a firewall by using IP information of an instance obtained from a cloud service server and dynamic IP information obtained from an external module.

Another technical problem that the present disclosure seeks to solve is to provide a method and system capable of detecting a failure related to a firewall by using tag information of an instance obtained from a cloud service server and tag information of dynamic IP information obtained from an external module.

The technical problems of the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

According to one embodiment of the present disclosure for solving the above technical problem, a method for detecting and recovering a failure related to a firewall may include a step of obtaining actual IP information for an instance associated with a policy of the firewall from a cloud service server, a step of obtaining dynamic IP information for each of the instances referenced by the firewall, a step of comparing the actual IP information with the dynamic IP information, and a step of determining whether or not failure recovery related to the firewall is necessary based on a result of the comparison. In this case, the dynamic IP information may be provided by an external module.

In one embodiment, the dynamic IP information may be information that is periodically updated by an IP information synchronization module.

In one embodiment, the step of comparing the actual IP information and the dynamic IP information may include the step of comparing the actual IP information and the dynamic IP information every first period.

In one embodiment, the first period may be a value that is set differently based on a pre-established priority for a policy to which the instance is associated.

In one embodiment, the first period may be a value set differently based on a priority set in advance for the instance.

In one embodiment, a method for detecting and recovering a failure related to a firewall may further include, after the step of determining whether failure recovery related to the firewall is necessary, a step of automatically executing a failure recovery process if, as a result of the determination, it is determined that failure recovery related to the firewall is necessary.

In one embodiment, the failure recovery process may be performed using a standby policy generated based on an IP band of dynamic IP information of the firewall.

According to another embodiment of the present disclosure for solving the above technical problem, a method for detecting and recovering a failure related to a firewall may include a step of obtaining first tag information of a target instance associated with a policy of the firewall from a cloud service server, a step of obtaining second tag information of dynamic IP information of each of the target instances referenced by the firewall, a step of comparing the first tag information with the second tag information, and a step of determining whether failure recovery related to the firewall is necessary based on a result of the comparison. In this case, the dynamic IP information may be provided by an external module.

In one embodiment, the first tag information of the target instance may include information on whether the target instance is scalable.

In one embodiment, the step of comparing the first tag information and the second tag information may include the step of comparing the first tag information and the second tag information every first period.

In one embodiment, the step of comparing the first tag information and the second tag information for each first period may include the step of calculating the difference between the number of target instances and the number of dynamic IP information for each first period. In addition, the step of determining whether or not a failure recovery related to the firewall is necessary based on the result of the comparison may include the step of determining that a failure recovery related to the firewall is necessary if the time at which a difference between the number of target instances and the number of dynamic IP information occurs more than a reference number of times during a first period when the target instance is an instance capable of being scaled.

In one embodiment, the step of determining whether or not a failure recovery related to the firewall is necessary based on the result of the comparison may further include the step of determining that a failure recovery related to the firewall is necessary if, in the case where the target instance is an instance that cannot be scaled, a difference occurs between the number of target instances and the number of dynamic IP information more than a reference number of times during a second period. In this case, the second period may be shorter than the first period.

In one embodiment, the step of determining whether a failure recovery related to the firewall is necessary may further include a step of determining that a failure recovery related to the firewall is necessary if the network traffic for the first period is below a reference value by further considering the monitoring results for network traffic.

In one embodiment, the step of comparing the first tag information and the second tag information may include the step of calculating the number of elements of the union of the target instance and the dynamic IP information and the number of elements of the intersection of the target instance and the dynamic IP information using the first tag information and the second tag information. In addition, the step of determining whether a failure recovery related to the firewall is necessary may include the step of determining that a failure recovery related to the firewall is necessary if the number of elements of the union and the number of elements of the intersection do not match.

In one embodiment, the step of comparing the first tag information and the second tag information may include the step of calculating the number of elements of the difference set between the target instance and the dynamic IP information using the first tag information and the second tag information. In addition, the step of determining whether a failure recovery related to the firewall is necessary may include the step of determining that a failure recovery related to the firewall is necessary if the number of elements of the difference set is greater than or equal to a threshold value.

In one embodiment, a method for detecting and recovering a failure related to a firewall may further include, after the step of determining whether failure recovery related to the firewall is necessary, a step of automatically executing a failure recovery process if, as a result of the determination, it is determined that failure recovery related to the firewall is necessary.

In one embodiment, the failure recovery process may be performed using a standby policy generated based on an IP band of dynamic IP information of the firewall.

According to another embodiment of the present disclosure for solving the above technical problem, a system for detecting and recovering a failure related to a firewall may include a processor and a memory storing instructions, which, when executed by the processor, may cause the processor to perform operations of obtaining actual IP information for an instance associated with a policy of the firewall from a cloud service server, obtaining dynamic IP information of each of the instances referenced by the firewall, comparing the actual IP information with the dynamic IP information, and determining whether or not failure recovery related to the firewall is necessary based on a result of the comparison. In this case, the dynamic IP information may be provided by an external module.

According to another embodiment of the present disclosure for solving the above technical problem, a system for detecting and recovering a failure related to a firewall may include a processor and a memory storing a command, wherein the command, when executed by the processor, may cause the processor to perform an operation of obtaining first tag information of a target instance associated with a policy of the firewall from a cloud service server, an operation of obtaining second tag information of dynamic IP information of each of the target instances referenced by the firewall, an operation of comparing the first tag information with the second tag information, and an operation of determining whether failure recovery related to the firewall is necessary based on a result of the comparison. In this case, the dynamic IP information may be provided by an external module.

According to this embodiment, it can be accurately determined whether a firewall-related failure recovery is necessary by referring to the IP information of the target instance obtained from the cloud service server.

According to this embodiment, it can be accurately determined whether a firewall-related failure recovery is necessary by referring to the tag information of the target instance obtained from the cloud service server.

According to this embodiment, the user's convenience and satisfaction can be improved because the failure recovery process is automatically executed without the user's manual intervention. In addition, physical resources and time resources consumed due to the user manually performing the failure recovery process can be saved.

According to this embodiment, the monitoring cycle can be set differently based on information on whether scale-out is possible, which is obtained by referencing tag information of the instance, and in the case of an instance for which scale-out is not possible, the monitoring period associated with the instance can be set short, thereby saving system resources consumed by unnecessary monitoring.

According to this embodiment, when a firewall policy related to a payment service is applied, even if a failure related to the firewall occurs, the continuity of the payment service can be ensured by automatically executing a failure recovery process using a standby policy.

FIG. 1 is an exemplary diagram illustrating a method for detecting and recovering a failure related to a firewall according to one embodiment of the present disclosure.
Figure 2 is an exemplary diagram for explaining some of the operations illustrated in Figure 1.
FIG. 3 is an exemplary diagram illustrating a method for detecting and recovering a failure related to a firewall according to another embodiment of the present disclosure.
Figure 4 is a detailed flowchart for explaining some of the operations illustrated in Figure 3.
Figure 5 is an example diagram for explaining some of the operations described with reference to Figure 4.
FIG. 6 is an exemplary diagram illustrating a case where it is determined that a firewall-related failure recovery is necessary, which may be referenced in some embodiments of the present disclosure.
Figure 7 is an example diagram for explaining some of the operations described with reference to Figure 6.
FIG. 8 is a hardware configuration diagram of a fault detection and recovery system related to a firewall according to some embodiments of the present disclosure.

Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. The advantages and features of the present invention, and the methods for achieving them, will become apparent with reference to the embodiments described in detail below together with the accompanying drawings. However, the technical idea of the present invention is not limited to the following embodiments, but may be implemented in various different forms, and the following embodiments are provided only to complete the technical idea of the present invention and to fully inform a person having ordinary skill in the art to which the present invention pertains of the scope of the present invention, and the technical idea of the present invention is defined only by the scope of the claims.

In describing the present disclosure, if it is determined that a detailed description of a related known configuration or function may obscure the gist of the present invention, the detailed description will be omitted.

Unless otherwise defined, terms (including technical and scientific terms) used in the following examples may be used with a meaning that can be commonly understood by a person of ordinary skill in the art to which this disclosure belongs, but this may vary depending on the intention of a technician engaged in the relevant field, case law, the emergence of new technologies, etc. The terminology used in this disclosure is for the purpose of describing the embodiments and is not intended to limit the scope of this disclosure.

In the examples below, singular expressions used include plural concepts unless the context clearly specifies that they are singular. In addition, plural expressions include singular concepts unless the context clearly specifies that they are plural.

In addition, terms such as first, second, A, B, (a), (b), etc. used in the following embodiments are only used to distinguish one component from another, and the nature, order, or sequence of the corresponding component is not limited by the terms.

Hereinafter, various embodiments of the present disclosure will be described in detail with reference to the attached drawings.

FIG. 1 is an exemplary diagram for explaining a method for detecting and recovering a failure related to a firewall according to an embodiment of the present disclosure. However, this is only a preferred embodiment for achieving the purpose of the present disclosure, and it is to be understood that some steps may be added or deleted as necessary. For reference, FIG. 1 shows steps/operations of a method performed by a first server including a module for detecting a failure related to a firewall. Therefore, in the following descriptions, if a subject of a specific step/operation is omitted, it can be understood that it is performed by the first server.

As illustrated in FIG. 1, a method for detecting and recovering a failure related to a firewall according to an embodiment of the present disclosure may begin with step S100 of obtaining actual IP information for an instance associated with a policy of the firewall from a cloud service server. At this time, the policy of the firewall may mean one of a plurality of policies included in a rule of the firewall. In addition, the instance may include a virtual machine, a container, etc. to which virtualized computing resources are allocated.

Meanwhile, the actual IP information for the instance can be distinguished from the dynamic IP information of the instance described below in that it is information obtained directly from the cloud service server. That is, if the actual IP information obtained from the cloud service server is different from the dynamic IP information of the instance described below, it can be determined that there is a problem or error in the dynamic IP information.

In step S200, the first server can obtain dynamic IP information of each instance referenced by the firewall. At this time, the dynamic IP information may be provided by an external module. More specifically, the external module may be a module that synchronizes IP information (i.e., an IP information synchronization module). In addition, the dynamic IP information may be information that is periodically updated by the IP information synchronization module. That is, unless a specific problem occurs in the IP information synchronization module, the dynamic IP information is periodically updated, so the actual IP information of the instance obtained from the cloud service server and the dynamic IP information may be understood to be the same.

In step S300, the first server can compare the actual IP information for the instance obtained through steps S100 and S200 with the dynamic IP information. At this time, the IP information and the dynamic IP information can be compared at each first cycle set in advance. However, the first cycle may not be a fixed value set in advance, but may be a different value depending on the case.

In one embodiment, the first period may be a value set differently based on a priority set in advance for a policy associated with an instance. For example, a first policy of a firewall for passing packets related to a payment service may be assigned a high priority, and a period for comparing actual IP information and dynamic IP information for an instance associated with the first policy may be set short.

In one embodiment, the first period may be a value set differently based on a priority set in advance for the instance. For example, if a tag attached to the first instance includes a high priority keyword (e.g. #PAYMENT), the first instance may be assigned a high priority, and the period for comparing the actual IP information and the dynamic IP information for the first instance may be set short.

Referring to Fig. 2, it can be confirmed that a priority is set for each of the multiple instances. As will be described with reference to the drawings below Fig. 3, each of the multiple instances associated with the firewall policy may include tag information. At this time, the tag information may include a keyword indicating the properties of the instance.

For example, as illustrated in Table 2, tag information of instance #1 (2a) may include keywords indicating that it is associated with a payment service (e.g. #PAYMENT) and keywords indicating that scale change is possible (e.g. #SCALE). In addition, tag information of instance #2 may include keywords indicating that it is associated with a delivery service (e.g. #PAYMENT) and keywords indicating that scale change is possible (e.g. #SCALE-xxx-ooo).

At this time, as illustrated in Table 2d, a high priority (i.e., 1st priority) may be assigned to instance #1 (2a) that is tagged with a keyword indicating that it is associated with a payment service, and a period for comparing the actual IP information and the dynamic IP information for instance #1 (2a) may be set short. In addition, among instance #2 (2b) that is tagged with a keyword indicating that scale change is possible and instance #3 (2c) that is tagged with a keyword not indicating that scale change is possible, instance #2 (2b) may be assigned a high priority (i.e., 2nd priority), and a period for comparing the actual IP information and the dynamic IP information for instance #2 (2b) may be set short. This is because, in the case of instances that are capable of scale change, the probability of occurrence of a firewall-related failure is high, and therefore, the monitoring period needs to be set short.

Meanwhile, tag information does not necessarily include a keyword consisting of a single word, and may include a keyword consisting of a combination of letters, numbers, symbols, etc.

A detailed description of the tag information attached to an instance and the process for determining whether a failure recovery is necessary using the tag information is provided below with reference to the drawings in FIG. 3 and below.

Referring back to FIG. 1, in step S400, the first server may determine whether a failure related to the firewall requires recovery based on the comparison result between the actual IP information and the dynamic IP information through step S300. More specifically, if the actual IP information for the instance associated with the firewall policy obtained from the cloud service server does not match the dynamic IP information of the instance obtained from an external module (e.g., IP information synchronization module), it may be determined that a failure related to the firewall has occurred and a recovery process needs to be performed.

Thereafter, although not illustrated in FIG. 1, if it is determined in step S400 that a failure recovery related to the firewall is necessary, a failure recovery process may be automatically executed. At this time, the failure recovery process may be performed using a preliminary policy previously created based on the IP band of the dynamic IP information of the firewall. In addition, the preliminary policy may be a preliminary policy set in consideration of the scale fluctuation range of the instance as a subnet-based policy in case a failure situation related to the firewall occurs. In other words, the preliminary policy may mean a policy for allowing traffic to be allowed so that normal service can be provided even if an instance is automatically created or deleted through scale-in or scale-out.

Accordingly, when a firewall policy related to payment services is applied, even if a firewall-related failure occurs, the continuity of payment services can be guaranteed by automatically executing a failure recovery process using a standby policy.

In summary, based on the result of comparing the actual IP information of the instance associated with the firewall policy acquired from the cloud service server and the dynamic IP information of each instance referenced by the firewall (i.e. provided by an external module), a failure related to the firewall can be detected. In addition, if it is determined that a failure recovery related to the firewall is necessary, a failure recovery process using a standby policy can be automatically executed.

Accordingly, by referring to the actual IP information of the instance acquired from the cloud service server, it can be accurately determined whether a firewall-related failure recovery is necessary, and the failure recovery process can be automatically executed without manual intervention by the user, thereby improving user convenience and satisfaction.

Meanwhile, the process of detecting a failure related to a firewall can be performed using the actual IP information of the instance acquired from the cloud service server and the dynamic IP information acquired from an external module, as illustrated in Fig. 1, but is not limited to this method. That is, the process of detecting a failure related to a firewall can also be performed using the tag information of the instance acquired from the cloud service server and the tag information of the dynamic IP information acquired from an external module. A detailed description thereof will be described later with reference to Figs. 3 to 7.

FIG. 3 is an exemplary diagram for explaining a method for detecting and recovering a failure related to a firewall according to another embodiment of the present disclosure. However, this is only a preferred embodiment for achieving the purpose of the present disclosure, and it is obvious that some steps may be added or deleted as needed.

For reference, FIG. 3, similarly to FIG. 1, illustrates steps/operations of a method performed by a first server including a module for detecting a failure related to a firewall. Accordingly, in the following descriptions, if the subject of a specific step/operation is omitted, it can be understood that it is performed by the first server.

As illustrated in FIG. 3, a method for detecting and recovering a failure related to a firewall according to another embodiment of the present disclosure may start with step S1000 of obtaining first tag information of a target instance associated with a policy of the firewall from a cloud service server. At this time, the first tag information of the target instance may include information on whether the instance can be scaled out. For example, the first tag information may be tag information including a specific keyword (e.g. #SCALE), as described with reference to FIG. 2. Meanwhile, step S1000 is the same as step S100 described with reference to FIG. 1, and therefore, description of overlapping content will be omitted.

In step S2000, the first server can obtain second tag information of each dynamic IP information of target instances referenced by the firewall. At this time, the dynamic IP information may be provided by an external module, and it may be understood that the second tag information is attached to the dynamic IP information and obtained together with the dynamic IP information. In addition, the first tag information and the second tag information may include keywords indicating properties of the instance or dynamic IP information, as described with reference to FIG. 2. Meanwhile, step S2000 is the same as or similar to step S200 described with reference to FIG. 1, and therefore, description of overlapping content will be omitted.

In step S3000, the first server can compare the first tag information of the target instance obtained through steps S1000 and S2000 with the second tag information of the dynamic IP information. At this time, the first tag information and the second tag information can be compared at each first cycle set in advance. However, the first cycle may be a different value depending on the case, rather than being a fixed value set in advance.

For example, if the tag information of the target instance includes a high priority keyword (e.g. #PAYMENT), the first instance may be assigned a high priority and the first period may be set short.

In step S4000, the first server can determine whether a failure recovery related to a firewall is necessary based on the comparison result of the first tag information and the second tag information through step S3000. At this time, whether a failure recovery related to a firewall is necessary can be determined using various methods. For example, whether a failure recovery related to a firewall is necessary can be determined based on the difference between the number of target instances and the number of dynamic IP information. In addition, whether a failure recovery related to a firewall is necessary can be determined based on the result of periodically monitoring network traffic. Furthermore, whether a failure recovery related to a firewall is necessary can be determined based on the number of elements of the union, intersection, and difference sets of the target instances and the dynamic IP information. A detailed description thereof will be described later with reference to FIGS. 4 to 7.

Afterwards, although not shown in Fig. 3, if it is determined in step S4000 that a failure recovery related to the firewall is necessary, a failure recovery process may be automatically executed. At this time, the failure recovery process may be performed using a preliminary policy previously generated based on the IP band of the dynamic IP information of the firewall. Since a detailed description thereof is the same as that described with reference to Fig. 1, a description of the overlapping content will be omitted.

In summary, based on the result of comparing the first tag information of the target instance associated with the firewall policy acquired from the cloud service server and the second tag information of each target instance referenced by the firewall (i.e. provided from an external module), a failure related to the firewall can be detected. In addition, if it is determined that a failure recovery related to the firewall is necessary, a failure recovery process using a standby policy can be automatically executed.

Accordingly, by referring to the tag information of the target instance acquired from the cloud service server, it can be accurately determined whether a failure recovery related to the firewall is necessary, and since the failure recovery process is automatically executed without manual intervention of the user, convenience and satisfaction of the user can be improved. In addition, physical resources and time resources consumed due to the user manually performing the failure recovery process can be saved.

Furthermore, when a firewall policy related to payment services is applied, even if a firewall-related failure occurs, the continuity of the payment service can be guaranteed by automatically executing a failure recovery process using the standby policy.

Below, a specific process for determining whether or not a firewall-related failure recovery is necessary based on the results of comparing the number of target instances with the number of dynamic IP information is described in detail with reference to FIGS. 4 and 5.

FIG. 4 is a detailed flowchart for explaining some of the operations illustrated in FIG. 3. However, this is only a preferred embodiment for achieving the purpose of the present disclosure, and it is obvious that some steps may be added or deleted as needed.

As illustrated in FIG. 4, in step S41, it may be determined whether the target instance is scalable using the first tag information of the target instance. For example, if the first tag information includes a keyword indicating scale variation (e.g. #SCALE), the target instance may be determined to be scalable, and if the first tag information does not include a keyword indicating scale variation (e.g. #SCALE), the target instance may be determined to be non-scalable.

Meanwhile, the first tag information may be tag information corresponding to one target instance, and the second tag information may be tag information corresponding to one dynamic IP information. Accordingly, it can be understood that the number of the first tag information and the number of target instances are the same, and the number of the second tag information and the number of dynamic IP information are the same.

For target instances that can be scaled, the number of target instances may increase due to scale-out. In this case, if a problem or error occurs in the IP information synchronization module, synchronization may not be performed properly, and the number of dynamic IP information and the number of target instances may not match. Conversely, for instances that cannot be scaled, the number of target instances cannot be increased, and even if a problem or error occurs in the IP information synchronization module, the number of dynamic IP information and the number of target instances may be less likely to match.

First, if the target instance is determined to be scalable based on the first tag information of the target instance, the difference between the number of target instances and the number of dynamic IP information can be calculated in step S42. Then, if the difference exceeds the reference number of times during the first period in step S43, it can be determined that a failure recovery related to the firewall is required.

For example, it can be assumed that the difference between the number of target instances and the number of dynamic IPs is calculated 7 times during the first period. At this time, if a difference value greater than or equal to 1 occurs twice among the 7 differences calculated during a specific period, it can be determined that a firewall-related failure has occurred and recovery is required. However, it should be noted that the firewall failure detection and recovery method according to the present disclosure is not limited to the above-described example, and whether recovery is required can be determined based on various periods and numbers of times.

Next, if it is determined that the scale of the target instance cannot be changed based on the first tag information of the target instance, the difference between the number of target instances and the number of dynamic IP information can be calculated in step S44. Thereafter, if a difference greater than the reference number occurs during the second period in step S45, it can be determined that a failure recovery related to the firewall is necessary. In this case, the second period may be shorter than the first period.

That is, if it is determined that the scale of the target instance is impossible, calculating the difference between the number of target instances and the number of dynamic IP information does not have much meaning, so the criteria for determining whether or not a failure recovery is necessary need to be applied differently. That is, if the scale of the target instance is possible, if two out of seven differences between the number of target instances and the number of dynamic IPs calculated during the first period are greater than or equal to 1, it is determined that a failure related to the firewall has occurred and recovery is necessary. However, if the scale of the target instance is impossible, if one out of three differences between the number of target instances and the number of dynamic IPs calculated during the second period is greater than or equal to 1, it may be determined that a failure related to the firewall has occurred and recovery is necessary.

Meanwhile, it should be noted that the firewall failure detection and recovery method according to the present disclosure is not limited to the above-described examples, and it goes without saying that the need for failure recovery can be determined based on various periods and numbers of times.

In addition, according to the content described above with reference to FIG. 4, the case where the difference between the number of target instances and the number of dynamic IP information is 1 or more is counted to determine whether or not a failure related to the firewall needs to be recovered, but the difference value may be set to various values as needed. For example, in step S43, if there are two difference values that are 3 or more among the seven difference values calculated during the first period, it may be determined that a failure related to the firewall has occurred and recovery is necessary.

FIG. 5 is an exemplary diagram illustrating some of the operations described with reference to FIG. 4. More specifically, FIG. 5 is an exemplary diagram schematically illustrating a process for determining whether or not a failure recovery is necessary, described with reference to FIG. 4.

First, let's explain a case where the target instance can be scaled out based on the result of referencing the first tag information of the target instance. In one embodiment, a process for determining the necessity of failure recovery related to a firewall may include a step of calculating the difference between the number of target instances and the number of dynamic IP information at each of a plurality of points in time (5a, 5b, 5c, 5d, 5e) during a first period, and a step of determining whether the points in time where the difference occurs exist a standard number or more.

As illustrated in FIG. 5, at the first time point (5a) and the second time point (5b), the difference between the number of target instances and the number of dynamic IP information may be 0, at the third time point (5c) and the fourth time point (5d), the difference between the number of target instances and the number of dynamic IP information may be 2, and at the fifth time point (5e), the difference between the number of target instances and the number of dynamic IP information may be 5.

If, among the five differences calculated during the first period, three differences greater than or equal to 1 occur and it is determined that a failure recovery is necessary, then it can be determined that a failure recovery related to the firewall is necessary since there are three points in total where the difference is greater than or equal to 1 during the first period. In addition, if, among the five differences calculated during the first period, three differences greater than or equal to 3 occur and it is determined that a failure recovery related to the firewall is not necessary since there is one point in time where the difference is greater than or equal to 3 during the first period.

Next, we will explain a case where the scale-out of the target instance is impossible based on the first tag information of the target instance. As described with reference to Fig. 4, if the scale of the target instance is impossible, the number of target instances cannot be increased unless special circumstances arise, so even if a problem or error occurs in the IP information synchronization module, there may be no case where the number of dynamic IP information and the number of target instances do not match.

That is, as illustrated in FIG. 5, since scale-out of target instances is impossible, the difference between the number of target instances calculated at the first time point (50a) to the fifth time point (50e) and the number of dynamic IP information may all be 0. Therefore, in one embodiment, a process for determining the necessity of disaster recovery related to a firewall may include a step of calculating the difference between the number of target instances and the number of dynamic IP information at time points (50a, 50b) during a second period shorter than the first period, and a step of determining whether the number of times at which the difference occurs exists exceeds a reference number of times.

In summary, by referring to the tag information of the target instance, the period for comparing the first tag information and the second tag information (e.g., the first period, the second period) can be set differently depending on whether scale-out is possible.

Accordingly, for target instances that cannot be scaled out, system resources consumed by unnecessary monitoring can be saved by setting a shorter monitoring period associated with the target instance.

Below, with reference to FIGS. 4 and 5, a process for determining whether or not a failure recovery related to a firewall is necessary using various methods other than the above-described method will be described in detail with reference to FIGS. 6 and 7.

FIG. 6 is an exemplary diagram for explaining a case where it is determined that a failure recovery related to a firewall is necessary, which may be referenced in some embodiments of the present disclosure. However, this is only a preferred embodiment for achieving the purpose of the present disclosure, and it is obvious that some steps may be added or deleted as needed.

First, we will describe the process for determining whether a firewall-related failure requires recovery based on the results of periodic monitoring of network traffic.

As illustrated in FIG. 6, network traffic may be monitored periodically in step S61. Thereafter, if the network traffic for the first period is below a reference value in step S62, it may be determined that a failure recovery related to the firewall is necessary. At this time, it should be noted that the process of determining whether a failure recovery related to the firewall is necessary by considering the network traffic is an additional step/operation performed in addition to the operations/steps illustrated in FIG. 3 in that it does not consider the first tag information of the target instance and the second tag information of the dynamic IP information. That is, it should be understood that the step of determining whether a failure recovery related to the firewall illustrated in FIG. 3 further includes a step of additionally acquiring a result of monitoring network traffic that is performed separately, and a step of determining whether a failure recovery is necessary by considering whether the network traffic for a specific period is below a reference value based on the acquired result.

Next, we will describe a process for determining whether a firewall-related failure recovery is necessary based on the number of elements in the union, intersection, and difference sets of the target instance and the dynamic IP information. Meanwhile, the process described below can be performed when the target instance is an instance that can be scaled out.

According to the above-described with reference to FIG. 4, the first tag information may be tag information corresponding to one target instance, and the second tag information may be tag information corresponding to one dynamic IP information. Accordingly, since tag information is a concept corresponding one-to-one to one target instance or dynamic IP information, the number of elements of the union and the number of elements of the intersection of the target instance and the dynamic IP information can be calculated using the first tag information and the second tag information. Furthermore, the number of elements of the difference between the target instance and the dynamic IP information can also be calculated using the first tag information and the second tag information.

According to one embodiment, in step S63, the number of elements in the union of the target instance and the dynamic IP information and the number of elements in the intersection of the target instance and the dynamic IP information may be calculated. Thereafter, in step S64, if the number of elements in the union and the number of elements in the intersection do not match, it may be determined that a firewall-related failure recovery is required.

This is because, if the target instance and the dynamic IP information are the same, the number of elements in the union will be calculated as the total number of target instances, and the number of elements in the intersection will also be calculated as the total number of target instances. Therefore, if the number of elements in the union of the target instance and the dynamic IP information and the number of elements in the intersection of the target instance and the dynamic IP information do not match, it can be determined that a firewall-related failure has occurred and recovery is required.

According to one embodiment, the number of elements of the difference set between the target instance and the dynamic IP information may be calculated in step S65. Thereafter, if the number of elements of the difference set is greater than or equal to a threshold value in step S66, it may be determined that a failure recovery related to the firewall is required.

If the target instance and the dynamic IP information are the same, the number of elements in the difference set should be calculated as 0. Accordingly, if the number of elements in the difference set between the target instance and the dynamic IP information is not calculated as 0, it may be determined that a firewall-related failure has occurred and recovery is required. However, it is not necessary to determine that recovery from a firewall-related failure is required only when the number of elements in the difference set is 0. That is, considering the possibility that an error may occur during the process of counting the number of elements or the process of calculating the difference set, if the number of elements in the difference set is greater than a criterion (e.g. 2), it may be determined that recovery from a firewall-related failure is required.

FIG. 7 is an exemplary diagram illustrating some of the operations described with reference to FIG. 6. More specifically, FIG. 7 is an exemplary diagram schematically illustrating some of the process for determining whether or not a failure recovery is necessary, described with reference to FIG. 6.

In one embodiment, a process for determining whether a failure recovery is necessary in relation to a firewall may include a step of calculating the number of elements in a union and an intersection of target instances and dynamic IP information using tag information, and a step of determining whether a failure recovery is necessary based on whether the number of elements in the union and the number of elements in the intersection match.

First, it can be assumed that a process is performed to determine whether a failure recovery related to a firewall is necessary by using the number of elements of the union and the number of elements of the intersection of the target instance (7a) and the dynamic IP information (7b) illustrated in Fig. 7. Meanwhile, since the target instance A1 and the dynamic IP information a1 illustrated in Fig. 7 correspond to the same instance or tag information, they can be regarded as one in the process of calculating the number of elements.

At this time, referring to Table 7c, the union of the target instance (7a, {A1, A2, A3, A4, B1, B2, C1, D1}) and the dynamic IP information (7b, {a1, a2, a3, a4, b1, b2, c1, d1}) can be {A1, A2, A3, A4, B1, B2, C1, D1}, and the number of elements of the union can be calculated as 8. Similarly, the intersection of the target instance (7a, {A1, A2, A3, A4, B1, B2, C1, D1}) and the dynamic IP information (7b, {a1, a2, a3, a4, b1, b2, c1, d1}) can be {A1, A2, A3, A4, B1, B2, C1, D1}, and the number of elements in the intersection can be calculated as 8. Accordingly, since the number of elements in the union and the number of elements in the intersection are equal to 8, it can be determined that there is no need to repair a firewall-related failure.

Meanwhile, it should be noted that the union and intersection illustrated in Table 7c may have differences in uppercase and lowercase letters for each element, such as {a1, a2, a3, a4, b1, b2, c1, d1}, {A1, a2, A3, a4, B1, B2, c1, D1}, but the number of elements is always the same, 8. Similarly, it should be understood that elements that have differences in uppercase letters among the elements that compose the union and intersection illustrated in Table 7f are treated as the same elements, and the number of elements is calculated.

Next, it may be assumed that a process is performed to determine whether or not a failure recovery related to a firewall is necessary by using the number of elements of the union and intersection of the target instance (7d) and dynamic IP information (7e) illustrated in Fig. 7.

At this time, referring to Table 7f, the union of the target instance (7d, {A1, A2, A3, A4, B1, B2, C1, D1}) and the dynamic IP information (7e, {a1, a2, a3, b1, c1, d1}) can be {A1, A2, A3, A4, B1, B2, C1, D1}, and the number of elements of the union can be calculated as 8. On the other hand, since there is no corresponding A4 instance and B2 instance in the dynamic IP information (7e), the intersection of the target instance (7d, {A1, A2, A3, A4, B1, B2, C1, D1}) and the dynamic IP information (7e, {a1, a2, a3, b1, c1, d1}) can be {A1, A2, A3, B1, C1, D1}, and the number of elements in the intersection can be calculated as 6. Accordingly, since the number of elements in the union is 8 and the number of elements in the intersection is 6, it can be determined that it is necessary to repair a failure related to the firewall.

Meanwhile, the necessity of failure recovery related to a firewall may be determined based on whether the number of elements in the union and intersection are the same, but the necessity of failure recovery related to a firewall may also be determined based on whether the difference between the number of elements in the union and the number of elements in the intersection is greater than or equal to a threshold. For example, if the number of elements in the union and intersection is 3 or more, failure recovery related to a firewall may be determined to be necessary. In this case, since the number of elements in the difference between the target instance (7d) and the dynamic IP information (7e) illustrated in FIG. 7 is 2, failure recovery related to a firewall may be determined not to be necessary.

In one embodiment, a process for determining whether a failure recovery is necessary in relation to a firewall may include a step of calculating a number of elements of a difference set between a target instance and dynamic IP information using tag information, and a step of determining whether a failure recovery is necessary based on the number of elements of the difference set.

First, it can be assumed that a process is performed to determine whether or not a failure recovery related to a firewall is necessary by using the number of elements of the difference set of the target instance (7a) and the dynamic IP information (7b) illustrated in Fig. 7.

At this time, referring to Table 7c, since each element of the target instance (7a, {A1, A2, A3, A4, B1, B2, C1, D1}) and the dynamic IP information (7b, {a1, a2, a3, a4, b1, b2, c1, d1}) corresponds, the difference between the target instance and the dynamic IP information can be an empty set, and the number of elements in the difference set can be calculated as 0. Accordingly, since the number of elements in the difference set is 0, it can be determined that there is no need to repair a failure related to the firewall.

Next, it may be assumed that a process is performed to determine whether or not a failure recovery related to a firewall is necessary by using the number of elements of the difference set of the target instance (7d) and the dynamic IP information (7e) illustrated in Fig. 7.

At this time, referring to Table 7f, the difference between the target instance (7d, {A1, A2, A3, A4, B1, B2, C1, D1}) and the dynamic IP information (7e, {a1, a2, a3, b1, c1, d1}) can be {A4, B2}, and the number of elements in the difference can be calculated as 2. Accordingly, since the number of elements in the difference is 2, it can be determined that it is necessary to repair a failure related to the firewall.

Meanwhile, the necessity of failure recovery related to a firewall may be determined based on whether the number of elements in the difference set is 0 or not, but the necessity of failure recovery related to a firewall may also be determined based on whether the number of elements in the difference set is greater than or equal to a criterion. For example, if the number of elements in the difference set is 3 or more, it may be determined that failure recovery related to a firewall is necessary. In this case, since the number of elements in the difference set of the target instance (7d) and the dynamic IP information (7e) illustrated in FIG. 7 is 2, it may be determined that failure recovery related to a firewall is not necessary.

In summary, by referring to the tag information of the target instance and the tag information of the dynamic IP information, the number of elements in the union and intersection of the target instance and the dynamic IP information can be calculated, and the necessity of failure recovery related to the firewall can be determined based on the calculated result. In addition, the number of elements in the difference between the target instance and the dynamic IP information can be calculated, and the necessity of failure recovery related to the firewall can be determined based on the calculated result.

Accordingly, by referencing one or more of the union, intersection, and difference sets of the target instance and dynamic IP information, it can be accurately determined whether a firewall-related failure recovery is required.

Hereinafter, a method for detecting and recovering a failure related to a firewall according to some embodiments of the present disclosure has been described with reference to FIGS. 1 to 7. According to a method for detecting and recovering a failure related to a firewall according to some embodiments of the present disclosure, a failure related to a firewall can be detected based on a result of comparing actual IP information of an instance associated with a policy of a firewall acquired from a cloud service server with dynamic IP information of each instance referenced by the firewall (i.e. provided from an external module), or based on first tag information of a target instance associated with the policy of the firewall and second tag information of each target instance referenced by the firewall. In addition, if it is determined that failure recovery related to the firewall is necessary, a failure recovery process using a standby policy can be automatically executed.

Accordingly, by referring to the IP information or tag information of the target instance obtained from the cloud service server, it can be accurately determined whether a firewall-related failure recovery is necessary.

In addition, user convenience and satisfaction can be improved because the failure recovery process is automatically executed without the user's manual intervention. In addition, physical and time resources consumed due to the user manually performing the failure recovery process can be saved.

Furthermore, when a firewall policy related to payment services is applied, even if a firewall-related failure occurs, the continuity of the payment service can be guaranteed by automatically executing a failure recovery process using the standby policy.

FIG. 8 is a hardware configuration diagram of a fault detection and recovery system related to a firewall according to some embodiments of the present disclosure. The fault detection and recovery system (1000) related to a firewall illustrated in FIG. 8 may include one or more processors (1100), a system bus (1600), a communication interface (1200), a memory (1400) that loads a computer program (1500) executed by the processor (1100), and a storage (1300) that stores the computer program (1500).

The processor (1100) controls the overall operation of each component of the fault detection and recovery system (1000) related to the firewall. The processor (1100) can perform operations for at least one application or program for executing methods/operations according to various embodiments of the present disclosure. The memory (1400) stores various data, commands, and/or information. The memory (1400) can load one or more computer programs (1500) from the storage (1300) to execute methods/operations according to various embodiments of the present disclosure. The system bus (1600) provides a communication function between components of the fault detection and recovery system (1000) related to the firewall. The communication interface (1200) supports Internet communication of the fault detection and recovery system (1000) related to the firewall. The storage (1300) can non-temporarily store one or more computer programs (1500). The computer program (1500) may include one or more instructions implementing methods/operations according to various embodiments of the present disclosure. When the computer program (1500) is loaded into the memory (1400), the processor (1100) may perform the methods/operations according to various embodiments of the present disclosure by executing the one or more instructions.

In some embodiments, the fault detection and recovery system (1000) related to the firewall described with reference to FIG. 8 may be configured using one or more physical servers included in a server farm based on cloud technology such as a virtual machine. In this case, at least some of the processor (1100), memory (1400), and storage (1300) among the components illustrated in FIG. 9 may be virtual hardware, and the communication interface (1200) may also be configured as a virtualized networking element such as a virtual switch.

Various embodiments of the present disclosure and effects according to the embodiments have been described with reference to FIGS. 1 to 8 so far. The effects according to the technical idea of the present disclosure are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

The technical idea of the present disclosure described so far can be implemented as a computer-readable code on a computer-readable medium. The computer program recorded on the computer-readable recording medium can be transmitted to another computing device through a network such as the Internet and installed on the other computing device, thereby allowing it to be used on the other computing device.

Although the operations are depicted in the drawings in a particular order, it should not be understood that the operations must be performed in the particular order depicted or in a sequential order, or that all depicted operations must be performed to achieve the desired results. In certain circumstances, multitasking and parallel processing may be advantageous. While the embodiments of the present disclosure have been described above with reference to the accompanying drawings, those skilled in the art will appreciate that the present disclosure can be implemented in other specific forms without changing the technical spirit or essential characteristics thereof. Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive. The scope of protection of the present invention should be interpreted by the claims below, and all technical ideas within a scope equivalent thereto should be interpreted as being included in the scope of the technical ideas defined by the present disclosure.

Claims (19)

In a method performed by at least one computing device,
A step of obtaining actual IP information for an instance associated with a firewall policy from a cloud service server;
A step of obtaining dynamic IP information of each instance referenced by the above firewall, wherein the dynamic IP information is provided by an external module;
A step of comparing the above actual IP information with the above dynamic IP information; and
Based on the results of the above comparison, a step of determining whether a failure recovery related to the firewall is necessary is included.
The above external module is a module that periodically updates dynamic IP information of each instance based on tag information of each instance.
How to detect and recover from firewall related failures. delete In the first paragraph,
The step of comparing the above actual IP information and the above dynamic IP information is:
Comprising a step of comparing the actual IP information and the dynamic IP information at each first cycle;
How to detect and recover from firewall related failures. In the third paragraph,
The above first cycle is,
The above instance is a value that is set differently based on a pre-established priority for the policy associated with it.
How to detect and recover from firewall related failures. In the third paragraph,
The above first cycle is,
A value that is set differently based on a priority set in advance for the above instance.
How to detect and recover from firewall related failures. In the first paragraph,
After the step of determining whether or not a failure recovery related to the above firewall is necessary,
As a result of the above judgment, if it is determined that a failure recovery related to the firewall is necessary, a step of automatically executing a failure recovery process is further included.
How to detect and recover from firewall related failures. In Article 6,
The above failure recovery process is,
It is performed using a preliminary policy generated based on the IP band of the dynamic IP information of the above firewall.
How to detect and recover from firewall related failures. In a method performed by at least one computing device,
A step of obtaining first tag information of a target instance associated with a firewall policy from a cloud service server;
A step of obtaining second tag information of dynamic IP information of each of the target instances referenced by the firewall, wherein the dynamic IP information is provided by an external module;
A step of comparing the first tag information and the second tag information; and
Including a step of determining whether or not a failure recovery related to the firewall is necessary based on the result of the above comparison,
The above external module is a module that periodically updates dynamic IP information of each instance based on tag information of each instance.
How to detect and recover from firewall related failures. In Article 8,
The first tag information of the above target instance is:
Contains information about whether the instance can be scaled out.
How to detect and recover from firewall related failures. In Article 8,
The step of comparing the first tag information and the second tag information is:
Comprising a step of comparing the first tag information and the second tag information at each first period,
How to detect and recover from firewall related failures. In Article 10,
The step of comparing the first tag information and the second tag information at each first period is:
Including a step of calculating the difference between the number of target instances and the number of dynamic IP information for each of the first periods,
The step of determining whether or not a failure recovery related to the firewall is necessary based on the results of the above comparison is as follows:
If the target instance is an instance capable of scalability, a step of determining that a failure recovery related to the firewall is necessary is included when the difference between the number of target instances and the number of dynamic IP information occurs more than a standard number of times during a first period.
How to detect and recover from firewall related failures. In Article 11,
The step of determining whether or not a failure recovery related to the firewall is necessary based on the results of the above comparison is as follows:
If the target instance is an instance that cannot be scaled, the step of determining that a failure recovery related to the firewall is necessary is further included when the difference between the number of target instances and the number of dynamic IP information occurs more than a standard number of times during a second period.
The above second period is shorter than the above first period,
How to detect and recover from firewall related failures. In Article 8,
The steps for determining whether or not the above firewall-related failure recovery is necessary are:
Further considering the monitoring results of network traffic, if the network traffic during the first period is below the reference value, the step of determining that a failure recovery related to the firewall is necessary is further included.
How to detect and recover from firewall related failures. In Article 8,
The step of comparing the first tag information and the second tag information is:
A step of calculating the number of elements of the union of the target instance and the dynamic IP information and the number of elements of the intersection of the target instance and the dynamic IP information using the first tag information and the second tag information,
The steps for determining whether or not the above firewall-related failure recovery is necessary are:
A step of determining that a failure recovery related to the firewall is required when the number of elements of the union and the number of elements of the intersection do not match,
How to detect and recover from firewall related failures. In Article 8,
The step of comparing the first tag information and the second tag information is:
Comprising a step of calculating the number of elements of the difference set between the target instance and the dynamic IP information using the first tag information and the second tag information,
The steps for determining whether or not the above firewall-related failure recovery is necessary are:
Including a step of determining that a failure recovery related to the firewall is necessary when the number of elements of the above difference set is greater than or equal to a criterion.
How to detect and recover from firewall related failures. In Article 8,
After the step of determining whether or not a failure recovery related to the above firewall is necessary,
As a result of the above judgment, if it is determined that a failure recovery related to the firewall is necessary, a step of automatically executing a failure recovery process is further included.
How to detect and recover from firewall related failures. In Article 16,
The above failure recovery process is,
It is performed using a preliminary policy generated based on the IP band of the dynamic IP information of the above firewall.
How to detect and recover from firewall related failures. processor; and
Contains memory for storing instructions,
The above instructions, when executed by the processor, cause the processor to:
The act of obtaining real IP information for instances associated with a firewall policy from a cloud service server;
An operation for obtaining dynamic IP information of each instance referenced by the above firewall, wherein the dynamic IP information is provided by an external module;
An operation of comparing the above actual IP information with the above dynamic IP information; and
Based on the results of the above comparison, an operation is performed to determine whether a failure recovery related to the firewall is necessary.
The above external module is a module that periodically updates dynamic IP information of each instance based on tag information of each instance.
A fault detection and recovery system related to firewalls. processor; and
Contains memory for storing instructions,
The above instructions, when executed by the processor, cause the processor to:
An action of obtaining first tag information of a target instance associated with a firewall policy from a cloud service server;
An operation for obtaining second tag information of dynamic IP information of each of the target instances referenced by the firewall, wherein the dynamic IP information is provided by an external module;
An operation of comparing the first tag information and the second tag information; and
Based on the results of the above comparison, an operation is performed to determine whether a failure recovery related to the firewall is necessary.
The above external module is a module that periodically updates dynamic IP information of each instance based on tag information of each instance.
A fault detection and recovery system related to firewalls.

Images