Method and system for detecting and recovering fault related to firewall

Abstract

The present disclosure relates to a method and system for detecting and recovering a fault related to a firewall. The method for detecting and recovering a fault related to a firewall, performed by at least one computing device, according to some embodiments of the present disclosure comprises the steps of: acquiring, from a cloud service server, actual IP information about instances associated with a policy of a firewall; acquiring dynamic IP information about each of the instances referenced by the firewall, wherein the dynamic IP information is provided by an external module; comparing the actual IP information with the dynamic IP information; and determining, on the basis of the result of the comparison, whether fault recovery related to the firewall is required.

Description

Method and system for detecting and recovering failures related to firewalls

[0001] The present disclosure relates to a method and system for detecting and recovering from firewall-related failures. More specifically, the present disclosure relates to a method for detecting and recovering from firewall-related failures using instances associated with a firewall policy and dynamic IP information provided by an external module, and to a system employing the method.

[0002] A firewall can operate based on multiple filtering rules for packets entering the firewall or for packets transmitted from the internal network to the outside. These filtering rules typically define the conditions for packets subject to filtering. For example, filtering may be determined based on IP address range.

[0003] The IP addresses of instances located inside or outside a firewall can dynamically change depending on various circumstances. For example, the IP address of an instance on a cloud service may change due to a reset of the instance, the cloud service's own failure recovery, or software deployment. In such cases, if an instance's IP address changes, existing firewall rules or policies may become invalid. Therefore, conventional techniques utilize a separate IP synchronization module to synchronize the changed IP address of a specific instance, ensuring that the firewall operates normally even when the IP address of an instance related to a firewall rule or policy changes.

[0004] 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 malfunction. This may result in the firewall abnormally blocking packets.

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

[0006] 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 from the failure.

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

[0008] 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.

[0009] 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 of the present disclosure from the description below.

[0010] A method for detecting and recovering a failure related to a firewall according to an embodiment of the present disclosure for solving the above technical problem may include the steps of obtaining actual IP information for an instance associated with a policy of the firewall from a cloud service server, obtaining dynamic IP information for 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.

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

[0012] 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.

[0013] 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.

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

[0015] 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, failure recovery related to the firewall is determined to be necessary.

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

[0017] 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 the steps of obtaining first tag information of a target instance associated with a policy of the firewall from a cloud service server, obtaining second tag information of dynamic IP information of each of the target instances referenced by the firewall, comparing the first tag information with the second tag information, and determining whether or not recovery of a failure 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.

[0018] In one embodiment, the first tag information of the target instance may include information about whether the target instance is scalable.

[0019] 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.

[0020] In one embodiment, the step of comparing the first tag information and the second tag information for each first period may include a step of calculating a 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 a result of the comparison may include a step of determining that a failure recovery related to the firewall is necessary if, in the case where the target instance is an instance capable of being scaled, a difference between the number of target instances and the number of dynamic IP information occurs a reference number of times or more during a first period.

[0021] 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 a 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, the difference between the number of target instances and the number of dynamic IP information occurs a number of times greater than a reference number during a second period. In this case, the second period may be shorter than the first period.

[0022] 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.

[0023] In one embodiment, the step of comparing the first tag information and the second tag information may include 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. In addition, the step of determining whether a failure recovery related to the firewall is necessary may include a 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.

[0024] In one embodiment, the step of comparing the first tag information and the second tag information may include a step of calculating the number of elements of a 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 a 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.

[0025] 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, failure recovery related to the firewall is determined to be necessary.

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

[0027] 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, wherein the instructions, when executed by the processor, may cause the processor to perform the following operations: obtaining actual IP information for an instance associated with a policy of the firewall from a cloud service server, obtaining dynamic IP information for 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.

[0028] 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, wherein the instructions, 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 or not recovery of a failure 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.

[0029] According to this embodiment, it is possible to accurately determine whether a firewall-related failure recovery is necessary by referring to the IP information of the target instance obtained from the cloud service server.

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

[0031] According to this embodiment, the failure recovery process can be automatically executed without manual user intervention, thereby enhancing user convenience and satisfaction. Furthermore, physical and time resources consumed by the user manually performing the failure recovery process can be saved.

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

[0033] 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 guaranteed by automatically executing a failure recovery process using a standby policy.

[0034] 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.

[0035] Figure 2 is an exemplary diagram for explaining some of the operations illustrated in Figure 1.

[0036] 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.

[0037] Figure 4 is a detailed flowchart for explaining some of the operations illustrated in Figure 3.

[0038] Figure 5 is an exemplary diagram for explaining some of the operations described with reference to Figure 4.

[0039] FIG. 6 is an exemplary diagram illustrating a case where it is determined that a firewall-related failure recovery is required, which may be referenced in some embodiments of the present disclosure.

[0040] Figure 7 is an example diagram for explaining some of the operations described with reference to Figure 6.

[0041] FIG. 8 is a hardware configuration diagram of a failure detection and recovery system related to a firewall according to some embodiments of the present disclosure.

[0042] Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the attached drawings. The advantages and features of the present invention, and methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the attached drawings. However, the technical spirit of the present invention is not limited to the following embodiments and may be implemented in various different forms. The following embodiments are provided only to complete the technical spirit of the present invention and to fully inform those skilled in the art of the present invention of the scope of the present invention, and the technical spirit of the present invention is defined only by the scope of the claims.

[0043] 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.

[0044] Unless otherwise defined, the terms (including technical and scientific terms) used in the following examples may be used with meanings commonly understood by those of ordinary skill in the art to which this disclosure pertains; however, this may vary depending on the intentions of engineers working in the relevant field, precedents, 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.

[0045] In the following examples, singular expressions include plural concepts unless the context clearly specifies that they are singular. Furthermore, plural expressions include singular concepts unless the context clearly specifies that they are plural.

[0046] In addition, terms such as first, second, A, B, (a), (b), etc. used in the following embodiments are only used to distinguish certain components from other components, and the nature, order, or sequence of the components are not limited by the terms.

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

[0048] FIG. 1 is an exemplary diagram illustrating a method for detecting and recovering a firewall-related failure, according to one embodiment of the present disclosure. However, this is merely a preferred embodiment for achieving the objectives of the present disclosure, and it is to be understood that some steps may be added or deleted as needed. For reference, FIG. 1 illustrates steps / operations of the method performed by a first server including a module for detecting a firewall-related failure. Therefore, 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.

[0049] As illustrated in FIG. 1, a method for detecting and recovering a firewall-related failure according to one embodiment of the present disclosure may begin with step S100, which involves obtaining actual IP information for an instance associated with a firewall policy from a cloud service server. The firewall policy may refer to one of multiple policies included in the firewall rules. Furthermore, the instance may include a virtual machine, container, or the like, to which virtualized computing resources are allocated.

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

[0051] In step S200, the first server can obtain dynamic IP information for 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). Furthermore, the dynamic IP information may be information 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 can be understood to be identical.

[0052] In step S300, the first server may compare the actual IP information for the instance acquired through steps S100 and S200 with the dynamic IP information. At this time, the IP information and the dynamic IP information may be compared at a preset first cycle. However, the first cycle may not be a preset fixed value, but may have a different value depending on the situation.

[0053] In one embodiment, the first period may be set to a different value based on a pre-established priority for the policy associated with the instance. For example, a firewall's first policy for allowing packets related to payment services to pass may be assigned a high priority, and the period for comparing actual IP information with dynamic IP information for instances associated with the first policy may be set to a short period.

[0054] In one embodiment, the first period may be a value set differently based on a pre-established priority 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 dynamic IP information for the first instance may be set to a short period.

[0055] Referring to Figure 2, it can be confirmed that priorities are set for each of the multiple instances. As will be explained with reference to the drawings below in Figure 3, each of the multiple instances associated with a firewall policy may include tag information. The tag information may include keywords indicating the attributes of the instance.

[0056] For example, as illustrated in Table 2, the 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, the 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).

[0057] At this time, as illustrated in Table 2d, a high priority (i.e., priority 1) may be assigned to instance #1 (2a) that is tagged with a keyword indicating that it is associated with a payment service, and the cycle for comparing the actual IP information and 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 it is scalable and instance #3 (2c) that is tagged with a keyword not indicating that it is scalable, instance #2 (2b) may be assigned a high priority (i.e., priority 2), and the cycle for comparing the actual IP information and dynamic IP information for instance #2 (2b) may be set short. This is because instances that are scalable have a high probability of occurrence of firewall-related failures, and thus the monitoring cycle needs to be set short.

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

[0059] A detailed description of the tag information attached to an instance and the process of determining whether a failure recovery is necessary using the tag information will be described later with reference to the drawings below in FIG. 3.

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

[0061] 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 change range of the instance, as a subnet-based policy in preparation for a failure situation related to the firewall. In other words, the preliminary policy may mean a policy for allowing traffic to be allowed so that normal services can be provided even if an instance is automatically created or deleted through scale-in or scale-out.

[0062] 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.

[0063] In summary, firewall-related failures can be detected based on a comparison of the actual IP information of instances associated with the firewall policy obtained from the cloud service server with the dynamic IP information for each instance referenced by the firewall (i.e., provided by an external module). Furthermore, if firewall-related failure recovery is determined to be necessary, a failure recovery process utilizing a standby policy can be automatically executed.

[0064] Accordingly, by referencing the actual IP information of the instance obtained 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.

[0065] Meanwhile, the process of detecting a firewall-related failure 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 firewall-related failure 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 provided below with reference to FIGS. 3 to 7.

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

[0067] For reference, FIG. 3, like FIG. 1, illustrates steps / operations of a method performed by a first server, which includes a module for detecting firewall-related failures. Therefore, 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.

[0068] 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 begin with step S1000 of acquiring first tag information of a target instance associated with a firewall policy 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 identical to step S100 described with reference to FIG. 1, and therefore, description of overlapping content will be omitted.

[0069] In step S2000, the first server may obtain second tag information of the dynamic IP information of each target instance referenced by the firewall. At this time, the dynamic IP information may be provided by an external module, and the second tag information may be understood to be 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 attributes of the instance or dynamic IP information, as described with reference to FIG. 2. Meanwhile, since step S2000 is identical or similar to step S200 described with reference to FIG. 1, description of overlapping content will be omitted.

[0070] In step S3000, the first server may compare the first tag information of the target instance acquired 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 may 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.

[0071] 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.

[0072] In step S4000, the first server can determine whether a firewall-related failure recovery is necessary based on the comparison result between the first tag information and the second tag information through step S3000. At this time, whether a firewall-related failure recovery is necessary can be determined using various methods. For example, whether a firewall-related failure recovery 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 firewall-related failure recovery is necessary can be determined based on the results of periodic monitoring of network traffic. Furthermore, whether a firewall-related failure recovery is necessary can be determined based on the number of elements in 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.

[0073] Although not illustrated in FIG. 3, if, as determined in step S4000, a firewall-related failure recovery is required, a failure recovery process may be automatically executed. At this time, the failure recovery process may be performed using a pre-generated preliminary policy based on the IP band of the firewall's dynamic IP information. A detailed description thereof is identical to that described with reference to FIG. 1, and therefore, any redundant explanation will be omitted.

[0074] In summary, firewall-related failures can be detected based on a comparison of the first tag information of target instances associated with the firewall policy obtained from the cloud service server with the second tag information (i.e., provided by an external module) of each target instance referenced by the firewall. Furthermore, if firewall-related failure recovery is determined to be necessary, a failure recovery process utilizing a standby policy can be automatically executed.

[0075] Accordingly, by referencing the tag information of the target instance obtained from the cloud service server, it is possible to accurately determine whether firewall-related failure recovery is necessary. Furthermore, the failure recovery process can be automatically executed without manual user intervention, thereby enhancing user convenience and satisfaction. Furthermore, this saves physical and time resources that would otherwise be consumed by manually performing the failure recovery process.

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

[0077] Below, a specific process for determining whether 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.

[0078] 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 to be understood that some steps may be added or deleted as necessary.

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

[0080] Meanwhile, the first tag information may be tag information corresponding to a single target instance, and the second tag information may be tag information corresponding to a single dynamic IP information. Therefore, the number of first tag information items and the number of target instances may be the same, and the number of second tag information items and the number of dynamic IP information items may be understood to be the same.

[0081] For scalable target instances, the number of target instances may increase due to scale-out. In such cases, if the IP information synchronization module encounters a problem or error, synchronization may not be performed properly, resulting in a discrepancy between the number of dynamic IPs and the number of target instances. Conversely, for instances that are not scalable, the number of target instances cannot increase, and even if the IP information synchronization module encounters a problem or error, the likelihood of a discrepancy between the number of dynamic IPs and the number of target instances is low.

[0082] 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 during the first period in step S43, it can be determined that a firewall-related failure recovery is required.

[0083] For example, let's assume that the difference between the number of target instances and the number of dynamic IPs is calculated seven times during the first period. In this case, if the difference is greater than or equal to 1 twice among the seven calculated differences during a specific period, it may be determined that a firewall-related failure has occurred and recovery is necessary. 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 the need for failure recovery may be determined based on various periods and numbers of times.

[0084] 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 may be calculated in step S44. Thereafter, if the difference exceeds the reference number of times during the second period in step S45, it may be determined that a firewall-related failure recovery is required. In this case, the second period may be shorter than the first period.

[0085] 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 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 firewall-related failure 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 firewall-related failure has occurred and recovery is necessary.

[0086] 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.

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

[0088] 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 the process for determining whether or not a failure recovery is necessary, described with reference to FIG. 4.

[0089] First, we will describe a case where the target instance can be scaled out based on the first tag information of the target instance. In one embodiment, the process for determining the need for 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 multiple points in time (5a, 5b, 5c, 5d, 5e) during a first period, and a step of determining whether the number of points in time where the difference occurred exceeds a predetermined number of times.

[0090] 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.

[0091] If, among the five differences calculated during the first period, there are three times when the difference is greater than or equal to 1, and it is determined that a failure recovery is necessary, then there are three times when the difference is greater than or equal to 1 during the first period, and thus it can be determined that a failure recovery related to the firewall is necessary. In addition, if, among the five differences calculated during the first period, there are three times when the difference is greater than or equal to 3, and it is determined that a failure recovery related to the firewall is not necessary, then it can be determined that a failure recovery related to the firewall is necessary.

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

[0093] That is, as illustrated in FIG. 5, since scaling 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, the process for determining the need for disaster recovery related to the 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 more than a reference number of times.

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

[0095] Accordingly, for target instances that cannot be scaled out, the monitoring period associated with the target instance can be set shorter to save system resources consumed by unnecessary monitoring.

[0096] Hereinafter, 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.

[0097] Figure 6 is an exemplary diagram illustrating a case where a firewall-related failure recovery is determined to be necessary, which may be referenced in some embodiments of the present disclosure. However, this is merely 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 needed.

[0098] First, we will describe the process of determining whether firewall-related failure recovery is necessary based on the results of periodic monitoring of network traffic.

[0099] As illustrated in FIG. 6, network traffic may be periodically monitored in step S61. Thereafter, if the network traffic for a first period is below a threshold in step S62, it may be determined that a firewall-related failure recovery is necessary. At this time, it should be noted that the process of determining whether a firewall-related failure recovery 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. In other words, the step of determining whether a firewall-related failure recovery is necessary as illustrated in FIG. 3 should be understood to further include a step of additionally acquiring results for separately performed network traffic monitoring, and a step of determining whether a firewall-related failure recovery is necessary by considering whether the network traffic for a specific period is below a threshold based on the acquired results.

[0100] Next, we describe a process for determining whether firewall-related failure recovery is necessary based on the number of elements in the union, intersection, and difference sets of the target instance and dynamic IP information. The process described below can be performed if the target instance is a scalable instance.

[0101] As described above 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 that corresponds one-to-one to one target instance or dynamic IP information, the number of elements in the union and 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 in 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.

[0102] In one embodiment, 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 in step S63. Thereafter, if the number of elements in the union and the number of elements in the intersection do not match in step S64, it may be determined that a firewall-related failure recovery is required.

[0103] This is because, if the target instance and dynamic IP information are identical, 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 may be determined that a firewall-related failure has occurred and recovery is required.

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

[0105] 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. Therefore, 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 necessarily 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 threshold (e.g., 2), it may be determined that recovery from a firewall-related failure is required.

[0106] 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.

[0107] In one embodiment, a process for determining whether a failure recovery related to a firewall is necessary may include a step of calculating the number of elements of 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 of the union and the number of elements of the intersection match.

[0108] First, let us assume a case where a process is performed to determine whether or not a firewall-related failure recovery is necessary using the number of elements in the union and intersection of the target instance (7a) and dynamic IP information (7b) illustrated in Fig. 7. Meanwhile, since the target instance A1 and dynamic IP information a1 illustrated in Fig. 7 correspond to the same instance or tag information, they can be considered as one in the process of calculating the number of elements.

[0109] 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.

[0110] 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} and {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 and lowercase 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.

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

[0112] 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 firewall-related failure.

[0113] Meanwhile, the necessity of firewall-related failure recovery may be determined based on whether the number of elements in the union and intersection are the same, but the necessity of firewall-related failure recovery 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 three or more, it may be determined that firewall-related failure recovery is 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 two, it may be determined that firewall-related failure recovery is not necessary.

[0114] 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 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 in the difference set.

[0115] 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.

[0116] 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 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.

[0117] Next, it may be assumed that a process is performed to determine whether or not a failure related to a firewall is required 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.

[0118] 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}) may be {A4, B2}, and the number of elements in the difference may be calculated as 2. Accordingly, since the number of elements in the difference is 2, it may be determined that it is necessary to repair a firewall-related failure.

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

[0120] In summary, by referencing 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 firewall-related failure recovery can be determined based on this calculated result. Furthermore, the number of elements in the difference between the target instance and the dynamic IP information can be calculated, and the necessity of firewall-related failure recovery can be determined based on this calculated result.

[0121] 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 or not a firewall-related failure recovery is required.

[0122] 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 the firewall may be detected based on a result of comparing the actual IP information of an instance associated with a firewall policy acquired from a cloud service server with dynamic IP information (i.e., provided from an external module) of each instance referenced by the firewall, or based on first tag information of a target instance associated with the firewall policy 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 may be automatically executed.

[0123] 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 or not a firewall-related failure recovery is required.

[0124] Furthermore, user convenience and satisfaction can be enhanced by automatically executing the disaster recovery process without manual intervention. Furthermore, this saves physical and time resources that would otherwise be consumed by users manually performing the disaster recovery process.

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

[0126] 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) for loading a computer program (1500) executed by the processor (1100), and a storage (1300) for storing the computer program (1500).

[0127] The processor (1100) controls the overall operation of each component of the firewall-related failure detection and recovery system (1000). The processor (1100) can perform operations on 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 firewall-related failure detection and recovery system (1000). The communication interface (1200) supports Internet communication of the firewall-related failure detection and recovery system (1000). 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 execute the one or more instructions to perform the methods / operations according to various embodiments of the present disclosure.

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

[0129] Various embodiments of the present disclosure and the effects thereof have been described with reference to FIGS. 1 through 8 so far. The effects of the technical concept of the present disclosure are not limited to the effects described above, and other effects not mentioned will be readily apparent to those skilled in the art from the description below.

[0130] The technical concepts of the present disclosure described so far can be implemented as 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 via a network such as the Internet, installed on the other computing device, and thus used on the other computing device.

[0131] Although the operations are depicted in a specific order in the drawings, it should not be understood that the operations must be performed in the specific 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. Although the embodiments of the present disclosure have been described above with reference to the attached drawings, those skilled in the art to which the present disclosure pertains will understand that the present invention 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

1. 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 or not a failure recovery related to the firewall is necessary is included. How to detect and recover from firewall related failures.

2. In paragraph 1, The above dynamic IP information is, Information that is periodically updated by the IP information synchronization module. How to detect and recover from firewall related failures.

3. In paragraph 1, 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.

4. In paragraph 3, 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.

5. In paragraph 3, 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.

6. In paragraph 1, 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.

7. In paragraph 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.

8. 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 Comprising a step of determining whether or not a failure recovery related to the firewall is necessary based on the result of the above comparison, How to detect and recover from firewall related failures.

9. In paragraph 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.

10. In paragraph 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.

11. 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 being scaled, 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.

12. In paragraph 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.

13. In paragraph 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.

14. In paragraph 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.

15. In paragraph 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.

16. In paragraph 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.

17. In paragraph 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.

18. 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 or not a failure recovery related to the firewall is necessary. A fault detection and recovery system related to firewalls.

19. 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 To perform an operation for determining whether or not a failure recovery related to the firewall is necessary based on the result of the above comparison. A fault detection and recovery system related to firewalls.

Images