Authorization device, authorization method, and authorization program

Abstract

The authorization device (100) includes a validity condition evaluation unit (180) that determines whether an authorization rule is valid by evaluating whether a validity condition is satisfied. The validity condition is a condition generated based on a countermeasure scenario corresponding to a vulnerability related to access to a target system storing electronic files, and is a condition related to an authorization target that requests authorization for access to the target system. The authorization rule is a rule that corresponds to the validity condition and authorizes access to the target system.

Description

[Technical field]

[0001] The present disclosure relates to an authorization device, an authorization method, and an authorization program. [Background technology]

[0002] There is a technique for analyzing the risk of a system by using information about the vulnerability of the system. Patent Document 1 discloses a technology for generating vulnerability model information including conditions for an attack to be successful or results of an attack by modeling the vulnerabilities (MITRE CWE (registered trademark, Common Weakness Enumeration)) of an example system that has been attacked using the system specifications of a target system, and for analyzing threats in the target system using the generated vulnerability model information. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] International Publication No. 2019-093059 Brochure Summary of the Invention [Problem to be solved by the invention]

[0004] Vulnerabilities regarding access to a system are updated according to technological advances, etc. Therefore, it is desirable to determine whether an authorization rule, which is a rule for authorizing access from an authorization target to a target system, is valid or not, using a validity condition, which is a condition that is dynamically changed according to updates of vulnerabilities regarding access to a system. Here, according to Patent Document 1, since the validity conditions are not used to determine whether an authorization rule is valid or not, there is a problem in that it is not possible to determine whether an authorization rule is valid or not using conditions that are dynamically changed in response to updates to vulnerabilities related to access to the system.

[0005] The present disclosure aims to determine whether an authorization rule is valid using conditions that change dynamically in response to updates to vulnerabilities related to access to a system. [Means for solving the problem]

[0006] The authorization device according to the present disclosure includes: a validity condition evaluation unit that evaluates whether a validity condition, which is a condition generated based on a countermeasure scenario corresponding to a vulnerability related to access to a target system storing an electronic file and is a condition related to an authorization target requesting authorization for access to the target system, is established, thereby determining whether an authorization rule, which is a rule corresponding to the validity condition and is a rule authorizing access to the target system, is valid; Equipped with. Effect of the Invention

[0007] According to the present disclosure, the validity condition evaluation unit determines whether the authorization rule is valid by evaluating whether the validity condition is satisfied. Here, the validity condition is a condition generated based on a countermeasure scenario corresponding to a vulnerability related to access to the target system. Therefore, the validity condition may be dynamically changed according to an update of the vulnerability related to access to the system. Therefore, according to the present disclosure, it is possible to determine whether the authorization rule is valid using a condition that is dynamically changed according to an update of the vulnerability related to access to the system. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of an authorization system 90 according to a first embodiment. [Diagram 2] 1 is a diagram showing an example of a hardware configuration of an authorization device 100 according to a first embodiment. [Diagram 3] 4 is a flowchart showing a risk definition flow according to the first embodiment. [Figure 4] FIG. 4 is a diagram for explaining a risk definition flow according to the first embodiment. [Diagram 5] 4 is a flowchart showing a validity condition determination flow according to the first embodiment. [Figure 6] FIG. 4 is a diagram for explaining a validity condition determination flow according to the first embodiment. [Figure 7] FIG. 13 is a diagram showing an example of a hardware configuration of an authorization device 100 according to a modified example of the first embodiment. [Figure 8] 11 is a flowchart showing a risk definition flow according to the second embodiment. [Figure 9] FIG. 11 is a diagram for explaining a risk definition flow according to the second embodiment. [Figure 10] 11 is a flowchart showing a validity condition determination flow according to the second embodiment. [Figure 11] FIG. 11 is a diagram for explaining a validity condition determination flow according to the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] In the description of the embodiments and the drawings, the same elements and corresponding elements are given the same reference numerals. Descriptions of elements given the same reference numerals are omitted or simplified as appropriate. Arrows in the drawings primarily indicate data flow or processing flow. In addition, "part" may be read as "circuit," "step," "procedure," "processing," or "circuitry" as appropriate.

[0010] Embodiment 1 Hereinafter, the present embodiment will be described in detail with reference to the drawings. The reliability of authorization rules in dynamic authorization may decrease over time. Therefore, in order to prevent the reliability of the authorization rules from decreasing, it is necessary to make the authorization rules follow risk assessments of cyber attacks in the world. Therefore, the purpose of this embodiment is to maintain or improve the reliability of the authorization rules in consideration of security risks and vulnerabilities recognized in the world.

[0011] ***Configuration Description*** Fig. 1 shows a configuration example of an authorization system 90 according to this embodiment. As shown in Fig. 1, the authorization system 90 includes an authorization device 100, an authentication server 200, a risk / vulnerability DB (Database) 300, and a file server 400. The authorization device 100 is also called an authorization server. The multiple components included in the authorization system 90 may be configured integrally as appropriate. A user accesses the file server 400 from a user system.

[0012] The configuration information 91 is information indicating the configuration of the user system. The configuration information 91 includes, as a specific example, information indicating the network configuration of the user system, security functions of each PC (Personal Computer), each server, and various devices included in the user system, and communication protocols to be used. The authorization device 100 is assumed to be capable of acquiring configuration information 91 .

[0013] The authorization device 100 includes an ontology generation unit 110, an access request receiving unit 120, a policy candidate extraction unit 130, an access policy determination unit 140, a feasibility determination unit 150, a risk definition data generation unit 160, a configuration information collection unit 170, a validity condition evaluation unit 180, an ontology storage unit 190, and a validity condition storage unit 191. The authorization device 100 corresponds to an extended version of the access determination device in [Reference 1]. The ontology generation unit 110, the access request reception unit 120, the policy candidate extraction unit 130, the permission determination unit 150, and the ontology storage unit 190 are each as described in [Reference 1]. The access policy determination unit 140 is the same as the access rule determination unit in [Reference 1]. The following describes the differences between the access determining device of [Reference 1] and the authorization device 100.

[0014] [Reference 1] International Publication No. 2022 / 149226 Brochure

[0015] The risk definition data generation unit 160 acquires risk information and information indicating the conditions for an attack to succeed from the risk / vulnerability DB300, generates risk definition data 161 including valid conditions based on the acquired information, and stores the generated risk definition data 161 in the validity condition storage unit 191. The risk information is information that indicates the content of the risk in the file server 400 . The attack success condition is a condition for a cybersecurity attack against the file server 400 to be successful.

[0016] The validity condition storage unit 191 stores the risk definition data 161 generated by the risk definition data generation unit 160. In addition, the validity condition storage unit 191 provides the stored risk definition data 161 to the validity condition evaluation unit 180 when the validity condition evaluation unit 180 evaluates the validity conditions.

[0017] The risk definition data 161 is data indicating each of a risk content, a countermeasure scenario, a validity condition, and an authorization rule ID (Identification). The data indicating each of the risk content and the validity condition corresponds to metadata corresponding to each authorization rule. The risk definition data 161 is data in which data indicating the validity condition is associated with data indicating the risk content corresponding to the validity condition. The content of the risk is utilized when the administrator of the file server 400 manages the validity conditions. As a specific example, the content of the risk is utilized when the administrator checks whether the validity conditions are appropriate. A countermeasure scenario is a scenario that denies the conditions for an attack to occur, a scenario that corresponds to a method for countering the conditions for an attack to occur, and a scenario that corresponds to vulnerabilities regarding access to the target system. The valid conditions are conditions generated based on the countermeasure scenario, and are conditions related to the authorization target that requests authorization for access to the target system. Specific examples of the authorization target are the entire user system, or a part of the user system that the user uses to access the file server 400. The valid conditions are conditions for realizing the countermeasure scenario, conditions that inhibit the conditions for establishing an attack, conditions that authorize access to the file server 400, and conditions that correspond to each authorization rule. The authorization rule is a rule that corresponds to an access restriction for the file server 400. When a validity condition corresponding to a certain authorization rule is no longer satisfied, the certain authorization rule is discarded or the access corresponding to the certain authorization rule becomes a target for access denial. The authorization rule ID is the identifier of the authorization rule to which the validity condition applies. In addition, by linking the risk definition data 161 to the authorization rule in dynamic authorization, the risk that can actually be eliminated is linked to the authorization rule. By linking the risk to the authorization rule, the administrator of the authorization rule or the like can grasp the importance of the authorization rule.

[0018] The configuration information collection unit 170 collects configuration information 91 from the user system, and provides the collected configuration information 91 to the validity condition evaluation unit 180 .

[0019] The validity condition evaluation unit 180 judges whether the authorization rule is valid by evaluating whether the validity condition is satisfied. The authorization rule is a rule that corresponds to the validity condition and that authorizes access to the target system. The validity condition evaluation unit 180 evaluates whether or not the validity condition is satisfied based on the configuration information 91. The configuration information 91 is information that indicates the configuration of the authorization target.

[0020] The authentication server 200 is a server that executes authentication processing.

[0021] The risk / vulnerability DB 300 is a database that stores data on system vulnerabilities. Specific examples of the risk / vulnerability DB 300 include databases that manage security vulnerabilities, such as CVE (Common Vulnerabilities and Exposures, a registered trademark) by MITRE, NVD (National Vulnerability Database) by NIST (National Institute of Standards and Technology), JPCERT / CC (Japan Computer Emergency Response Team Coordination Center), or JVN iPedia managed by the Information-Technology Promotion Agency (IPA). The risk / vulnerability DB 300 may also be a knowledge database on cyber attacks, such as CAPEC (Common Attack Pattern Enumeration and Classification, a registered trademark) by MITRE, or ATT&CK (Adversarial Tactics, Techniques & Common Knowledge). The authorization device 100 is capable of acquiring information indicating security risks, attack scenarios, attack establishment conditions, and the like from the risk / vulnerability DB 300.

[0022] The file server 400 is a server that stores data to be accessed by users, and is a system protected by the authentication server 200 and the authorization device 100, and is also called a target system. The file server 400 may be a cloud server or an on-premise server. The target system is a system that stores electronic files and typically adopts the zero trust model. A specific example of the zero trust model is described in [Reference 2].

[0023] [Reference 2] Kindervag, J., “Build Security Into Your Network's DNA: The Zero Trust Network Architecture”, Forrester Research, 2010

[0024] 2 shows an example of a hardware configuration of the authorization device 100 according to this embodiment. The authorization device 100 is composed of a computer. The authorization device 100 may be composed of multiple computers.

[0025] As shown in the figure, the authorization device 100 is a computer including hardware such as a processor 11, a memory 12, an auxiliary storage device 13, an input / output IF (Interface) 14, and a communication device 15. These pieces of hardware are appropriately connected via signal lines 19.

[0026] The processor 11 is an integrated circuit (IC) that performs arithmetic processing and controls the hardware of the computer. Specific examples of the processor 11 include a central processing unit (CPU), a digital signal processor (DSP), and a graphics processing unit (GPU). The authorization device 100 may include a plurality of processors that replace the processor 11. The plurality of processors share the role of the processor 11.

[0027] The memory 12 is typically a volatile storage device, and a specific example is a RAM (Random Access Memory). The memory 12 is also called a primary storage device or a main memory. Data stored in the memory 12 is saved in the auxiliary storage device 13 as necessary.

[0028] The auxiliary storage device 13 is typically a non-volatile storage device, and specific examples thereof include a ROM (Read Only Memory), an HDD (Hard Disk Drive), or a flash memory. Data stored in the auxiliary storage device 13 is loaded into the memory 12 as necessary. The memory 12 and the auxiliary storage device 13 may be integrated into one unit.

[0029] The input / output IF 14 is a port to which an input device and an output device are connected. A specific example of the input / output IF 14 is a Universal Serial Bus (USB) terminal. Specific examples of the input device are a keyboard and a mouse. A specific example of the output device is a display.

[0030] The communication device 15 is a receiver and a transmitter, and is, for example, a communication chip or a network interface card (NIC).

[0031] Each unit of the authorization device 100 may use the input / output IF 14 and the communication device 15 as appropriate when communicating with other devices.

[0032] The auxiliary storage device 13 stores an authorization program. The authorization program is a program that causes a computer to realize the functions of each unit of the authorization device 100. The authorization program is loaded into the memory 12 and executed by the processor 11. The functions of each unit of the authorization device 100 are realized by software.

[0033] Data used when executing the authorized program and data obtained by executing the authorized program are appropriately stored in a storage device. Each part of the authorization device 100 uses a storage device as appropriate. As a specific example, the storage device is composed of at least one of the memory 12, the auxiliary storage device 13, a register in the processor 11, and a cache memory in the processor 11. Note that the terms "data" and "information" may have the same meaning. The storage device may be independent of the computer. The functions of the memory 12 and the auxiliary storage device 13 may be realized by other storage devices.

[0034] The authorized program may be recorded in a computer-readable non-volatile recording medium. Specific examples of the non-volatile recording medium include an optical disk and a flash memory. The authorized program may be provided as a program product. The hardware configurations of the other components included in the authorization system 90 may be similar to the hardware configuration of the authorization device 100 .

[0035] ***Explanation of Operation*** The operation procedure of the authorization device 100 corresponds to an authorization method, and the program that realizes the operation of the authorization device 100 corresponds to an authorization program.

[0036] 3 is a flowchart showing an example of a risk definition flow. The risk definition flow is a process for generating risk definition data 161. The risk definition flow will be described with reference to FIG. Fig. 4 is a diagram for explaining a risk definition flow. A specific example of each step of the flowchart shown in Fig. 3 will be explained below with reference to Fig. 4. In Fig. 4, it is assumed that the risk / vulnerability DB 300 is MITRE CAPEC.

[0037] (Step S101) The risk definition data generating unit 160 acquires risk information and information indicating attack success conditions from the risk / vulnerability DB 300. As a specific example, the risk definition data generating unit 160 obtains an attack pattern of "misuse of trusted identifiers" defined in "CAPEC-21" from MITRE CAPEC. Here, the risk corresponds to the "exploit" section of CAPEC-21, and the attack establishment condition corresponds to the "Prerequisites" section of CAPEC-21. The process of this step may be performed by the administrator when linking the risk definition data 161 with the authorization rule in step S103.

[0038] (Step S102) The risk definition data generating unit 160 defines a condition that hinders the conditions for establishing an attack as an effective condition. As a specific example, the risk definition data generating unit 160 formats the risk and the attack establishment condition into risk definition data 161 as shown in Fig. 4. At this time, the risk definition data generating unit 160 formats the "validity condition" into "(attribute) = (value)" so that the authorization device 100 can evaluate the "validity condition." Here, the "validity condition" is a condition generated by an administrator or the like based on the "countermeasure scenario."

[0039] (Step S103) When the authorization rules are generated, each generated authorization rule is associated with a risk and a validity condition. The association process is performed by an administrator or the like. As a specific example, when an authorization rule group consisting of a plurality of authorization rules is managed in an ontology format in the authorization device 100, a risk and a validity condition indicated by the risk definition data 161 are linked to a node corresponding to each authorization rule. Information indicating an identifier of a node linked to a risk and a validity condition is stored in the "rule ID" of the risk definition data 161. In FIG. 4, a rule corresponding to each communication method is shown in an ontology format as an authorization rule. In addition, when a user uses RDP (Remote Desktop Protocol) in a company intranet, if a validity condition corresponding to RDP (rule ID) is established, the user can access the file server 400. Note that a user ID of a user who is not participating in AD (Active Directory) and has a weak security may be hijacked by a brute force attack. On the other hand, a user who participates in AD uses a user ID that is strong in security defined by an organization. In addition, the user ID can be verified. The validity condition corresponding to "RDP" corresponds to the nature of the user ID of a user who participates in AD.

[0040] (Step S104) The risk definition data generating unit 160 stores the generated risk definition data 161 in the validity condition storage unit 191 .

[0041] 5 is a flowchart showing an example of a valid condition determination flow. The valid condition determination flow is a process for determining whether or not a valid condition is established in the authorization of a user regarding access to the file server 400. The valid condition determination flow will be described with reference to FIG. 6 is a diagram for explaining the validity condition determination flow. A specific example of each step of the flowchart shown in FIG.

[0042] (Step S111) The configuration information collection unit 170 collects configuration information 91 as context information up to the file server 400 accessed by the user, and inputs the collected configuration information 91 to the validity condition evaluation unit 180 . When the user system is a control system, a specific example of a method for collecting the configuration information 91 is to use technology related to asset management and monitoring solutions such as Nozomi Networks Guardian. Note that the method for collecting the configuration information 91 may be any method.

[0043] (Step S112) First, the validity condition evaluation unit 180 acquires the validity condition corresponding to the authorization rule selected in response to the user's access (the rule corresponding to "RDP" in FIG. 6) from the validity condition storage unit 191. In FIG. 6, the rule ID of the selected authorization rule is stored in "rule ID". Next, the validity condition evaluation unit 180 judges whether the selected authorization rule is valid or not based on the input configuration information 91 and the acquired validity condition. The evaluation of the validity condition may be performed when the authorization rule is evaluated in response to the user's access, or may be performed periodically by timer processing or the like. The validity condition evaluation unit 180 evaluates the validity condition by comparing the information indicated by the input configuration information 91 (which is assumed to be formatted in the format of "(attribute) = (value)") with "(attribute) = (value)" indicated by the acquired validity condition. If the information indicated by the input configuration information 91 satisfies all the conditional expressions indicated by the acquired validity condition, the acquired validity condition is established. If the validity condition acquired for the input configuration information 91 is satisfied, the validity condition evaluation unit 180 validates the authorization rule corresponding to the validity condition and proceeds to step S114. Otherwise, the validity condition evaluation unit 180 proceeds to step S113.

[0044] (Step S113) The validity condition evaluation unit 180 invalidates the selected authorization rule. As a specific example, the validity condition evaluation unit 180 sets the selected authorization rule to "access denied", or deletes the selected authorization rule itself. In FIG. 6, the validity condition evaluation unit 180 determines that the validity condition corresponding to RDP is not established because the value of FTP (File Transfer Protocol) is TRUE, and invalidates the authorization rule corresponding to RDP.

[0045] (Step S114) When there are a plurality of authorization rules to be evaluated in response to a user's access, the same process is repeated.

[0046] ***Explanation of the Effects of the First Embodiment*** According to this embodiment, the risk content is linked to the validity condition corresponding to the authorization rule in the risk definition data 161. Here, the risk content may be updated. Therefore, according to this embodiment, the administrator of the authorization rule, etc., can detect, by referring to the risk content, when an authorization rule that has been set once becomes ineffective or needs to be improved due to a change in the system environment. Therefore, according to this embodiment, the reliability of the authorization rule is improved. Specific examples of changes in the system environment include the abolition of the security committee, making a system administrator unnecessary, the introduction or abolition of a standard specification, or the change in the length of a secure password from 8 digits to 12 digits due to an improvement in the processing performance of a computer. Furthermore, according to this embodiment, an administrator of the authorization rules can improve the system environment so that it conforms to the validity conditions, and can add validity conditions linked to the authorization rules to the authorization rules. In addition, the effects of the authorization device 100 periodically referring to an external risk / vulnerability DB 300 such as CAPEC and performing maintenance of the authorization rules will be described. Since there is no need to describe rules that are implicitly considered to be "natural" in the authorization rules, the setting of the authorization rules can be simplified. By acquiring data indicating each of the risks and acceptable conditions from the risk / vulnerability DB 300 or the like, it is possible to automatically keep up with the security level generally required in the world.

[0047] ***Other configurations*** <Variation 1> FIG. 7 shows an example of the hardware configuration of the authorization device 100 according to this modified example. The authorization device 100 includes a processing circuit 18 in place of the processor 11 , the processor 11 and the memory 12 , the processor 11 and the auxiliary storage device 13 , or the processor 11 , the memory 12 , and the auxiliary storage device 13 . The processing circuit 18 is hardware that realizes at least a part of each unit of the authorization device 100. The processing circuitry 18 may be dedicated hardware, or may be a processor that executes programs stored in the memory 12 .

[0048] When processing circuitry 18 is dedicated hardware, processing circuitry 18 may be, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination thereof. The authorization device 100 may include a plurality of processing circuits that replace the processing circuit 18. The plurality of processing circuits share the role of the processing circuit 18.

[0049] In the authorization device 100, some of the functions may be realized by dedicated hardware, and the remaining functions may be realized by software or firmware.

[0050] Processing circuitry 18 is illustratively implemented in hardware, software, firmware, or a combination thereof. The processor 11, the memory 12, the auxiliary storage device 13, and the processing circuit 18 are collectively referred to as the "processing circuitry." In other words, the functions of the functional components of the authorization device 100 are realized by the processing circuitry. The authorization device 100 according to other embodiments may also have a similar configuration to this modified example.

[0051] Embodiment 2 The following mainly describes the differences from the above-described embodiment with reference to the drawings.

[0052] ***Configuration Description*** The configuration of the authorization system 90 according to this embodiment is the same as that of the authorization system 90 according to the first embodiment. In this embodiment, even if a validity condition corresponding to a certain authorization rule is not satisfied, if an offsetting condition that offsets the validity condition is set for the certain authorization rule and the offsetting condition is satisfied, the certain authorization rule is not invalidated. The offsetting condition is a condition corresponding to the validity condition, and is a condition for exceptionally regarding the authorization rule corresponding to the validity condition as valid when the validity condition is not satisfied. The offsetting condition is a condition corresponding to a case where there is no security risk or an extremely low security risk. The risk definition data 161 according to this embodiment includes a "setoff condition." The risk definition data generating unit 160 according to this embodiment appropriately sets the "offsetting condition" when executing the risk definition flow and generating the risk definition data 161. Note that there may be an authorization rule for which a corresponding "offsetting condition" does not exist. The validity condition evaluation unit 180 according to this embodiment judges that an authorization rule is valid when a countervailing condition corresponding to a validity condition is satisfied when the validity condition is not satisfied. Specifically, when a countervailing condition corresponding to a validity condition is set during execution of the validity condition judgment flow, the validity condition evaluation unit 180 does not invalidate the authorization rule corresponding to the validity condition if the countervailing condition is satisfied, even if it is judged that the validity condition is not satisfied.

[0053] ***Explanation of Operation*** 8 is a flowchart showing an example of a risk definition flow according to the present embodiment. The risk definition flow will be described with reference to FIG. 9 is a diagram for explaining a risk definition flow. A specific example of each step in the flowchart shown in FIG.

[0054] (Step S201) The risk definition data generating unit 160 sets the "offsetting condition" of the risk definition data 161. The "offsetting condition" may be set by an administrator of the authorization rules or the like. As a specific example, the risk definition data generating unit 160 sets, as an offsetting condition, a condition for permitting access to the file server 400 when a user is attempting to access the file server 400 from a private network. Here, it is assumed that there is no security risk when the file server 400 is accessed from a private network.

[0055] 10 is a flowchart showing an example of a validity condition determination flow according to the present embodiment. The validity condition determination flow will be described with reference to FIG. 11 is a diagram for explaining the validity condition determination flow. A specific example of each step of the flowchart shown in FIG.

[0056] (Step S112) When an offsetting condition corresponding to the selected authorization rule exists together with the validity condition corresponding to the selected authorization rule, the validity condition evaluation unit 180 acquires the offsetting condition from the validity condition storage unit 191. Moreover, the validity condition evaluation unit 180 proceeds to step S211 instead of proceeding to step S113. The other steps are the same as those in step S112 according to the first embodiment.

[0057] (Step S211) When an offsetting condition corresponding to the selected authorization rule is set, the validity condition evaluation unit 180 evaluates whether or not the set offsetting condition is satisfied. If an offsetting condition corresponding to the selected authorization rule is set and if the set offsetting condition is satisfied, the validity condition evaluation unit 180 proceeds to step S114. Otherwise, the validity condition evaluation unit 180 proceeds to step S113. In FIG. 11, the validity condition evaluation unit 180 evaluates whether or not the network used by the user is a private network, and since the network is a private network, the process proceeds to step S114.

[0058] ***Explanation of the Effects of the Second Embodiment*** According to this embodiment, by setting offsetting conditions taking into account security risks that do not occur under certain circumstances, it is possible to increase the availability of data stored in file server 400 while maintaining the security of file server 400.

[0059] ***Other embodiments*** The above-described embodiments may be freely combined, or any of the components in each embodiment may be modified, or any of the components in each embodiment may be omitted. Moreover, the embodiments are not limited to those shown in the first and second embodiments, and various modifications are possible as necessary. The procedures explained using the flowcharts and the like may be modified as appropriate. [Explanation of symbols]

[0060] 11 processor, 12 memory, 13 auxiliary storage device, 14 input / output IF, 15 communication device, 18 processing circuit, 19 signal line, 90 authorization system, 91 configuration information, 100 authorization device, 110 ontology generation unit, 120 access request receiving unit, 130 policy candidate extraction unit, 140 access policy determination unit, 150 feasibility determination unit, 160 risk definition data generation unit, 161 risk definition data, 170 configuration information collection unit, 180 validity condition evaluation unit, 190 ontology storage unit, 191 validity condition storage unit, 200 authentication server, 300 risk / vulnerability DB, 400 file server.

Claims

1. a validity condition evaluation unit that evaluates whether a validity condition, which is a condition generated based on a countermeasure scenario corresponding to a vulnerability related to access to a target system storing an electronic file and is a condition related to an authorization target requesting authorization for access to the target system, is established, thereby determining whether an authorization rule, which is a rule corresponding to the validity condition and is a rule authorizing access to the target system, is valid; An authorization device comprising:

2. The authorization device according to claim 1 , wherein the validity condition evaluation unit evaluates whether the validity condition is satisfied based on configuration information indicating a configuration of the authorization target.

3. The authorization device according to claim 1 or 2, wherein the target system is a system that adopts a zero trust model.

4. The authorization device further comprises: a validity condition storage unit that stores risk definition data in which data indicating the validity condition is associated with data indicating the content of the risk corresponding to the validity condition; The authorization device according to claim 1 or 2, comprising:

5. The authorization device according to claim 1 , wherein the validity condition evaluation unit determines that the authorization rule is valid when the validity condition is not satisfied and a countervailing condition corresponding to the validity condition is satisfied.

6. An authorization method in which a computer determines whether an authorization rule that corresponds to a valid condition and that authorizes access to a target system is valid by evaluating whether a valid condition is established, the valid condition being a condition generated based on a countermeasure scenario that corresponds to a vulnerability regarding access to the target system that stores electronic files, and the condition being a condition regarding an authorization target that requests authorization for access to the target system.

7. A valid condition evaluation process for determining whether an authorization rule that is a rule that authorizes access to a target system that stores electronic files and that corresponds to a valid condition and that is a condition related to an authorization target that requests authorization for access to the target system is valid by evaluating whether the valid condition is satisfied or not, the valid condition being a condition generated based on a countermeasure scenario that corresponds to a vulnerability related to access to the target system, and determining whether the authorization rule is valid or not, the rule corresponding to the valid condition and that is a rule that authorizes access to the target system. An authorization program that causes an authorization device, which is a computer, to execute the above.

Images