JP7629333B2 - Dynamic access authorization system and dynamic access authorization method - Google Patents

Description

The present invention is suitable for use in a dynamic access authorization system and a dynamic access authorization method that dynamically authorizes access from a terminal to a resource.

In recent years, there has been an increase in malicious programs (malware) such as computer viruses, spyware, and bot programs that pose threats such as information leaks and unauthorized access, and targeted attacks against nations and companies are becoming increasingly sophisticated. Information leaks caused by perpetrators within organizations have also become a major social issue.

To deal with this situation, the idea of "zero trust" has been gaining attention. It considers that communication partners' devices and users, whether inside or outside an organization, may have malicious intent, and carefully approves access to important resources owned by an organization, such as servers and databases, from various perspectives, taking into account the risks. The conventional mainstream approach to cybersecurity has been to "deal after the fact" with how quickly cyber attacks can be detected and dealt with, but the idea of zero trust belongs to "deal before the fact" which reduces the risk of an attack occurring by determining whether or not access should be granted based on the authority, importance, relationship, or situation between the access requesting subject and the resource.

Although there is no detailed definition of zero trust, the National Institute of Standards and Technology (NIST), which oversees security policy for the US government, has stated in its guidelines "NIST SP800-207" that, as a guideline for access authorization that contributes to zero trust, "authorization should be performed on a session-by-session basis," and "when granting authorization, in addition to static information such as identifiers of terminals, users, and resources, dynamic information such as behavior should be utilized."

In the technology disclosed in Patent Document 1, an authorization request packet containing user authentication or authorization information is sent from the terminal immediately before a session between the terminal and the server starts, and authorization processing is performed by the server or an authorization device installed between the terminal and the server. Then, the session is established only if authorization is granted by the above authorization processing. Patent Document 2 also discloses a technology in which, when abnormal behavior of a terminal is detected, this is recorded in an email and sent to an access control device, thereby blocking access.

U.S. Pat. No. 8,413,248 JP 2018-191121 A

However, considering the recent increase in the speed of cyber attacks and malware, as well as the increase in internal crimes, there is always the possibility that a terminal and/or user may suddenly turn into a malicious attacker. For this reason, in order to protect resources from malicious access, it is necessary to calculate risks and grant authorization by taking into account dynamic information, such as "subject behavior at the time of access (process or user action)," in addition to static information, such as so-called "terminal identifiers and user identifiers." However, current authorization technology has the problem that it is not possible to realize such "dynamic authorization based on user or terminal behavior on a session-by-session basis."

For example, Patent Document 1 discloses a technology for realizing "pre-authorization before the start of a communication session," but does not disclose a method for realizing "dynamic authorization" based on the behavior of the terminal and/or user immediately before the start of a communication session. Furthermore, the technology disclosed in Patent Document 2 does not provide real-time control, considering the time it takes to send and receive e-mail. Furthermore, the technology disclosed in Patent Document 2 is premised on detecting abnormal behavior on the terminal side, and therefore cannot execute access control that incorporates the importance, attributes, and risks of the accessed resource. In other words, Patent Documents 1 and 2 do not disclose a technology for realizing dynamic authorization by collecting and analyzing the most recent behavior information of the terminal and/or user at the time of a request from a subject to start access to a resource.

Furthermore, in order to achieve "dynamic authorization based on the behavior of users or terminals on a session-by-session basis" while maintaining real-time performance and reducing the load on terminals or networks, it is desirable to store all behavior information that contributes to authorization in one or a small number of IP packets, as disclosed in Patent Document 1. However, user and terminal behavior information is diverse, and it is particularly difficult to store information such as a list of processes running within a terminal as is in one or a small number of packets.

The present invention has been made in consideration of the above points, and aims to propose a dynamic access authorization system and a dynamic access authorization method that can realize dynamic authorization of access requests to resources based on the most recent behavior of the terminal and/or user while reducing the load on the network and terminal.

In order to solve such problems, the present invention provides a dynamic access authorization system that performs authorization judgment for an access request from a terminal used by a user to a resource owned by a resource device based on dynamic information related to the terminal and/or the user of the terminal, the dynamic access authorization system comprising: a terminal-side program and terminal-side data referenced by the terminal-side program, which are stored in the terminal; and a control device-side program and control device-side data referenced by the control device-side program, which are stored in an access control device disposed in a network between the terminal and the resource device, the terminal-side program comprising: a plurality of behavior monitoring units that monitor a plurality of types of behavior related to the user and/or the terminal and periodically output the latest behavior information; and a behavior information list that combines one or more of the behavior information by adjusting the total data size of the plurality of behavior information output from the plurality of behavior monitoring units so that it falls within a predetermined limit range. A dynamic access authorization system is provided that includes a behavior information adjustment unit that creates an authorization request message including a list of the behavior information adjusted by the behavior information adjustment unit, and an authorization request control unit that captures the generation of the access request, creates an authorization request message including a list of the behavior information adjusted by the behavior information adjustment unit, and transmits the authorization request message and the access request to the access control device, and the control device side program includes a policy management unit that manages an access policy script in which a logical formula using the behavior information output by the behavior monitoring unit as an element is described, an authorization request message receiving unit that receives the authorization request message transmitted from the terminal, an access determination unit that performs the authorization determination by applying the authorization request message to the logical formula defined in the access policy script, and an access control unit that controls whether to pass or block the access request received from the authorization request control unit within a predetermined time to the resource depending on the determination result by the access determination unit.

In addition, in order to solve such problems, the present invention provides a dynamic access authorization method using a dynamic access authorization system that performs authorization judgment for an access request from a terminal used by a user to a resource owned by a resource device based on dynamic information related to the terminal and/or the user of the terminal, the dynamic access authorization system having a terminal-side program and terminal-side data referenced by the terminal-side program that are held in the terminal, and a control device-side program and control device-side data referenced by the control device-side program that are held in an access control device disposed in a network between the terminal and the resource device, the dynamic access authorization system having a behavior monitoring step in which the terminal-side program monitors multiple types of behavior related to the user and/or the terminal and periodically outputs the latest behavior information, a behavior information adjustment step in which the terminal-side program adjusts the multiple pieces of behavior information output in the behavior monitoring step so that the total data size falls within a predetermined limited range, and creates a behavior information list combining one or more pieces of behavior information, and the terminal-side program generates a behavior information list for the access request, The dynamic access authorization method includes an authorization request control step of capturing the generation of a request, creating an authorization request message including the list of behavior information adjusted in the behavior information adjustment step, and transmitting the authorization request message and the access request to the access control device; a policy management step of the control device side program managing an access policy script in which a logical expression using the behavior information output in the behavior monitoring step as an element is described; an authorization request message reception step of the control device side program receiving the authorization request message transmitted from the terminal in the authorization request control step; an access determination step of the control device side program applying the authorization request message received in the authorization request message reception step to the logical expression defined in the access policy script to perform the authorization determination; and an access control step of the control device side program controlling whether to pass or block the access request transmitted in the authorization request control step to the resource within a predetermined time period depending on the determination result of the access determination step.

The present invention makes it possible to dynamically authorize requests to access resources based on the most recent behavior of the terminal and/or user while minimizing the load on the network and terminal.

1 is a diagram showing an example of a configuration of a dynamic access authorization system 1 according to an embodiment of the present invention. 2 is a block diagram showing an example of the hardware configuration of a terminal 10, an access control device 20, a resource 30, and a management terminal 40. FIG. 11 is a diagram illustrating an example of terminal setting information. FIG. 11 is a diagram illustrating an example of behavior monitoring unit management information. FIG. 13 illustrates an example of authorization request message history information. FIG. 4 is a diagram illustrating an example of access control setting information. FIG. 13 illustrates an example of an access policy script. FIG. 11 is a diagram illustrating an example of access authorization information. FIG. 5 is a diagram showing an example of a data format of an authorization request message 510. FIG. 5 is a diagram showing an example of an administrator notification message 530. 11 is a sequence diagram showing an example of a processing procedure performed on the terminal 10 side. FIG. 13 is a flowchart illustrating an example of a processing procedure for determining whether an authorization request message is necessary. 13 is a flowchart illustrating an example of a processing procedure for a transmission interval calculation process. 11 is a sequence diagram showing an example of a processing procedure performed on the access control device 20 side. FIG. 13 is a flowchart illustrating an example of a processing procedure for a compression behavior information decompression process.

Below, an embodiment of the present invention will be described in detail with reference to the drawings. In this description, unless otherwise specified, it is assumed that an access request from a terminal to a resource is realized by TCP (Transfer Control Protocol) communication. Furthermore, a session refers to a set of one or more access requests that occur from a terminal to a resource within a certain short period of time. For example, if the certain short period is one second, an access request R1 and another access request R2 that occurs within one second after R1 occurs belong to the same session.

(1) System Configuration Fig. 1 is a diagram showing an example of the configuration of a dynamic access authorization system 1 according to an embodiment of the present invention. The dynamic access authorization system 1 is a system that, when an access request is made from a terminal 10 operated by a user to a resource 30, an access control device 20 performs an authorization decision as to whether to pass or block the access request 520 to the resource 30 based on an authorization request message 510 including behavior information related to the terminal 10 and/or the user, thereby realizing dynamic authorization of the access request 520.

In FIG. 1, the dynamic access authorization system 1 is configured to include a terminal side program 100, a terminal setting DB 310, a behavior monitoring unit device DB 320, an authorization request message history DB 330, a control device side program 200, an access control setting DB 410, an access policy script DB 420, and an access authorization information DB 430. Below, the components shown in FIG. 1 will be described in detail, focusing on the configuration of the dynamic access authorization system 1.

As shown in FIG. 1, the terminal 10 and the access control device 20 are connected by a communication network 41, and the access control device 20 and the resource 30 are connected by a communication network 42. Each of the communication networks 41 and 42 is, for example, a LAN (Local Area Network), but may also be a WAN (Wide Area Network), a mobile phone, or a public line network such as a PHS. One or more terminals 10 and one or more access control devices 20 are connected to the communication network 41, and one or more access control devices 20 and one or more resources 30 are connected to the communication network 42. Note that the communication network 41 and the communication network 42 may be the same network in actuality.

In the dynamic access authorization system 1, when the terminal 10 or its user creates and executes an access request for the resource 30, the terminal 10 transmits an access request 520 to the access control device 20 via the communication network 41. At this time, the terminal 10 captures the creation of the access request, and if an authorization decision is required for the access request, before transmitting the access request 520 to the access control device 20, transmits an authorization request message 510 carrying behavior information of the terminal 10 and/or the user to the access control device 20 and requests an authorization decision. Then, in the access control device 20, an authorization decision for the access request is made based on the authorization request message 510, and if the access request is authorized, the access control device 20 transfers the access request 520 received from the terminal 10 and temporarily buffered to the destination resource 30 via the communication network 42. On the other hand, if the authorization decision results in the access request not being authorized, the access control device 20 blocks the transmission of the access request 520 to the resource 30. At this time, the access control device 20 can also transmit an administrator notification message 530 to the management terminal 40.

The authorization request message 510 is a telegram sent from the terminal 10 to the access control device 20 via the communication network 41, and the latest behavior of the terminal 10 and/or the user is encrypted and stored. The access control device 20 judges whether or not the access request 520 can be communicated based on the authorization request message 510. In the present invention, the authorization request message 510 uses UDP (User Datagram Packet) as a communication protocol, which is different from TCP and does not require a control packet for establishing communication. UDP is generally lighter than TCP, and realizes communication with a small burden on the computer and network side and high real-time performance. On the other hand, it has a disadvantage that there is no recovery method when packet loss occurs. In addition, in order to satisfy the access authorization guidelines that contribute to zero trust, it is preferable that the authorization request message 510 is transmitted on a session-by-session basis. FIG. 9, which will be described later, shows a specific example of the data format of the authorization request message 510.

The access request 520 is a telegram sent from the terminal 10 to the access control device 20 via the communication network 41, and if the access control device 20 permits communication, it is sent to the resource 30 via the communication network 42. As described above, the access assumed in this invention is TCP, and the access request 520 is assumed to be a TCP SYN packet sent at the start of TCP.

The administrator notification message 530 is a telegram that notifies the administrator of the communication control status in the access control device 20, and its contents are displayed via the management terminal 40. In FIG. 10, which will be described later, administrator notification messages 530A and 530B are shown as specific examples of the administrator notification message 530.

(1-1) Terminal 10
The terminal 10 is a general-purpose computer such as a personal computer or a server, and requests access to a resource 30, for example, in the course of a user's work using the terminal 10. The terminal 10 includes an OS/application 11, a terminal side program 100, a terminal setting DB 310, a behavior monitoring device DB 320, and an authorization request message history DB 330.

OS/application 11 is a general operating system (OS) and general applications that run on the OS (e.g., document creation software, web browser, database client, etc.).

The terminal-side program 100 realizes dynamic authorization by collecting the most recent behavior of the terminal 10 and/or its user at the timing when the OS/application 11 requests access to the resource 30 and transmitting an authorization request message 510 to the access control device 20 located on the communication path between the terminal 10 and the resource 30. The terminal-side program 100 includes one or more behavior monitoring units 110, a behavior information adjustment unit 120, an authorization request control unit 130, and an authorization request message transmission unit 140, and the behavior information adjustment unit 120 further includes a behavior information compression unit 121 and a behavior information prioritization unit 122.

The behavior monitoring unit 110 is a program that monitors the behavior of the terminal 10 and its user, and periodically outputs the results to the behavior monitoring unit management DB 320. There are multiple behavior monitoring units 110 depending on the type of behavior to be monitored. For example, if it is desired to monitor two types of behavior, process startup and network communication, the number of behavior monitoring units 110 will be two.

The behavior information adjustment unit 120 has the role of adjusting the multiple behavior monitoring results output by the behavior monitoring unit 110 to fit within a data size that can be stored in the authorization request message 510 while minimizing loss of value as much as possible. The behavior information adjustment unit 120 includes two functional units: a behavior information compression unit 121 and a behavior information prioritization unit 122.

The behavior information compression unit 121 has a function of compressing the data size of "list-type" behavior information output by the behavior monitoring unit 110. Examples of list-type behavior information include a list of hash values of all executable programs running on the terminal 10, a list of running service programs, a list of identifiers of terminals that have communicated within a certain period of time, and a list of applications installed on the terminal 10. Compression methods include lossless compression methods such as ZIP, and lossy compression methods such as BloomFilter, which will be described later. When compressing data with a high degree of randomness, such as hash values, lossy compression methods are seen to have a greater compression effect.

When multiple types of behavior information are given, the behavior information prioritization unit 122 has the function of determining a combination of behavior information that maximizes the sum of values within a determined data size based on the value and size of each piece of information.

When the authorization request control unit 130 captures an access request from the terminal 10 to the resource 30, it requests the authorization request message sending unit 140 to issue an authorization request message 510. In addition, the authorization request control unit 130 buffers the access request 520 for a certain period of time based on the processing time of the authorization request message 510 in the access control device 20, and then sends it to the resource 30.

The authorization request message sending unit 140 creates an authorization request message 510 based on an instruction from the authorization request control unit 130, and sends it to the access control device 20. Note that in the following description, the authorization request control unit 130 that sends the access request 520 and the authorization request message sending unit 140 that sends the authorization request message 510 are described as separate functional units, but in the dynamic access authorization system 1 according to this embodiment, for example, the authorization request control unit 130 may be configured to include the function of the authorization request message sending unit 140.

The terminal setting DB310, the behavior monitoring unit management DB320, and the authorization request message history DB330 are data storage units that store various information referenced when the terminal side program 100 runs on the terminal 10.

The terminal setting DB 310 stores terminal setting information as information related to various settings of the terminal side program 100. A specific example of terminal setting information is shown in FIG. 3 described later.

The behavior monitoring unit management DB 320 stores behavior monitoring unit management information as parameters related to the behavior monitoring unit 110 and information related to behavior information observed by the terminal 10. A specific example of behavior monitoring unit management information is shown in FIG. 4, which will be described later.

The authorization request message history DB 330 stores authorization request message history information as information related to the transmission date and time of authorization request messages 510 issued by the terminal 10 in the past. A specific example of authorization request message history information is shown in FIG. 5, which will be described later.

(1-2) Access control device 20
The access control device 20 is a computer that judges whether to grant authorization for an authorization request message 510 and performs a process of passing/blocking an access request 520 based on the result of the judgment, and can be realized by a general computer such as a personal computer or a server. The access control device 20 includes a control device side program 200, an access control setting DB 410, an access policy script DB 420, and an access authorization information DB 430. Although not shown in FIG. 1, the access control device 20 may be considered to include an OS/applications like the terminal 10.

The control device side program 200 makes an access authorization decision for the authorization request message 510 received from the terminal 10 based on dynamic information (specifically, for example, behavior information) observed by the terminal 10, and performs pass/block processing to pass or block the access request 520 based on the decision result. The control device side program 200 includes a policy management unit 210, an authorization request message receiving unit 220, a behavior information decompression unit 230, an access decision unit 240, and an access control unit 250.

The policy management unit 210 manages the access policy script for access authorization. The access policy script is a document in which a logical expression is written in XML (eXtensible Markup Language), JSON (JavaScript Object Notation), or text format. The access policy script is written by an administrator on the management terminal 40, for example, and transmitted to the access control device 20, and is stored in the access policy script DB 420 by the policy management unit 210.

The authorization request message receiving unit 220 has the function of receiving an authorization request message 510 sent from the terminal 10.

The behavior information decompression unit 230 has the role of decompressing the behavior information compressed by the behavior information compression unit 121. In this embodiment, the decompression process executed by the behavior information decompression unit 230 corresponds to a so-called decompression process when the behavior information is compressed in a lossless compression format such as ZIP. On the other hand, when the behavior information is compressed in a lossy compression format, the decompression process determines whether specific data (corresponding to "keywords" and "compressed behavior information keywords" described later in this embodiment) in the compressed behavior information is recorded, and if so, replaces the behavior information with the specific data.

Specifically, for example, if a list of processes such as process A, process B, and process C is recorded in the compressed behavior information X, the behavior information decompression unit 230 determines whether or not a specific process (e.g., process B) is recorded in the behavior information X. If it is determined that process B is recorded, the behavior information X is replaced with process B. This allows the access determination unit 240 in the subsequent process of determining whether or not access is permitted (the authorization determination shown in step S242 in FIG. 14) to determine whether or not access is permitted based on the correspondence between the access policy script and the behavior information.

The access determination unit 240 determines whether or not access is permitted by applying the authorization request message 510 decompressed by the behavior information decompression unit 230 to the access policy script managed by the policy management unit 210 and stored in the access policy script DB 420.

The access control unit 250 performs a pass/block process for the access request 520 depending on the result of the authorization decision made by the access decision unit 240.

The access control setting DB410, the access policy script DB420, and the access authorization information DB430 are data storage units that store various information referenced when the control device side program 200 runs in the access control device 20.

The access control setting DB 410 stores access control setting information as information related to the settings of the access control device 20. A specific example of the access control setting information is shown in FIG. 6, which will be described later.

The access policy script DB 420 records the access policy script for granting access authorization. As described above, the access policy script is managed by the policy management unit 210. A specific example of an access policy script is shown in FIG. 7, which will be described later.

The access authorization information DB 430 records access authorization information as information indicating the result of the authorization decision performed by the access decision unit 240. The access authorization information is used by the access control unit 250. A specific example of the access authorization information is shown in FIG. 8, which will be described later.

(1-3) Resource 30, Management Terminal 40
The resource 30 is a computer that holds a resource that is the target of an access request from the terminal 10, and can be a variety of computers used in business, such as a web server, a database server, a calculation server, an account management server, or a mail server. For simplicity, in this description, unless otherwise specified, the resource as data to which access is requested in the access request 520 and the resource device that holds the resource are not distinguished and are referred to as the resource 30.

The management terminal 40 is a computer used by the administrator. As described above, the administrator accesses the policy management unit 210 of the access control device 20 through the management terminal 40 and creates and edits the access policy script. In addition, the control result of the access request 520 by the access control unit 250 is transmitted to the management terminal 40 as an administrator notification message 530 and is displayed on the display of the management terminal 40, etc.

(2) Hardware Configuration Fig. 2 is a block diagram showing an example of the hardware configuration of the terminal 10, the access control device 20, the resource 30, and the management terminal 40. Each of the above devices can be realized, for example, by an information processing device 50 having the hardware configuration shown in Fig. 2. The information processing device 50 shown in Fig. 2 is a general information processing device, and is configured by connecting a CPU 51, a memory 52, an external storage device 53, an interface (IF) 54, and an input/output device 55 to each other via a bus 56.

The CPU 51 is an example of a processor that performs arithmetic processing, and is, for example, a CPU (Central Processing Unit). In the information processing device 50, the CPU 51 executes a program stored in the memory 52 to realize a predetermined function of the device. Specifically, for example, when the information processing device 50 is a terminal 10, the CPU 51 executes a terminal side program 100 stored in the memory 52 to realize the processing routines of each function (behavior monitoring unit 110, behavior information adjustment unit 120, authorization request control unit 130, authorization request message transmission unit 140). Also, for example, when the information processing device 50 is an access control device 20, the CPU 51 executes a control device side program 200 stored in the memory 52 to realize the processing routines of each function (policy management unit 210, authorization request message reception unit 220, behavior information decompression unit 230, access determination unit 240, access control unit 250).

Memory 52 is a main storage device that stores the execution programs (e.g., terminal-side program 100) necessary to realize each functional unit of the device. Memory 52 is also used for short-term storage of data related to the execution of the above programs.

The external storage device 53 is a non-transient storage device such as a hard disk drive (HDD) or a solid state drive (SSD), and is mainly used for long-term storage of data. Specifically, for example, when the information processing device 50 is a terminal 10, the terminal setting DB 310, the behavior monitoring unit management DB 320, and the authorization request message history DB 330 can be realized by the external storage device 53 of the information processing device 50. Also, for example, when the information processing device 50 is an access control device 20, the access control setting DB 410, the access policy script DB 420, and the access authorization information DB 430 can be realized by the external storage device 53 of the information processing device 50.

IF54 is a variety of interfaces such as a communication interface and an input/output interface. For example, if the information processing device 50 is a terminal 10, IF54 as a communication interface connects the terminal 10 to the communication network 41. Also, for example, if the information processing device 50 is an access control device 20, IF54 as a communication interface connects the access control device 20 to the communication network 41 and the communication network 42.

The input/output device 55 is an input device that accepts various information input to the information processing device 50 by a user or the like, and an output device that outputs information stored in the information processing device 50 to the outside. The input/output device 55 as an input device is, for example, a keyboard, a mouse, or a touch panel. The input/output device 55 as an output device is, for example, a liquid crystal display device, an organic EL (Electro Luminescence) display, or a printer.

The bus 56 is a communication line that connects each device that constitutes the information processing device 50 (CPU 51, memory 52, external storage device 53, IF 54, input/output device 55) and enables the exchange of information between these devices.

In addition, some or all of the programs executed by the CPU 51 in the information processing device 50 and the data referenced by the programs may be stored in advance in the memory 52 or the external storage device 53, or may be configured to be stored in the external storage device 53 of the information processing device 50 from a non-transient storage device of another device connected via a network or from a non-transient storage medium via the IF 54, as necessary.

(3) Data Configuration (3-1) Terminal Setting DB 310
Fig. 3 is a diagram showing an example of terminal setting information. Terminal setting information 3100 in Fig. 3 is an example of terminal setting information stored in the terminal setting DB 310, and records information on various setting items in the terminal-side program 100. As shown in Fig. 3, the terminal setting information 3100 has items of ID 3101, item 3102, and value 3103.

ID 3101 is a code for uniquely identifying a record within the database. Item 3102 is a code indicating a setting item, and is expressed, for example, as a character string. Value 3103 indicates a value corresponding to item 3102, and the value can be any value, such as a character string or a numeric value.

The specific contents recorded in the terminal setting information 3100 in Figure 3 are explained below.

The "maximum allowed data size" shown in item 3102 of ID 3101 = "1" specifies the maximum data size of behavior information that can be stored in the authorization request message 510. In the case of Figure 3, the value 3103 of the record is set to "1000 bytes."

The "behavior information compression method" shown in item 3102 of ID 3101 = "2" specifies the information compression algorithm executed by the behavior information compression unit 121. In the case of FIG. 3, "BloomFilter" is set in the value 3103 of the record. BloomFilter is a type of lossy compression algorithm, which registers multiple pieces of data in a bit array and can later determine whether any data is registered in the bit array under a certain error rate. In BloomFilter, in the process of registering data in a bit array, the elements of the bit array corresponding to the hash value obtained by applying multiple types of hash functions to the data to be registered are set to "1". Then, in the process of determining whether data is registered in the bit array, it is confirmed whether all the elements of the bit array corresponding to the hash value of the data to be determined are "1". Although BloomFilter achieves a higher compression rate than typical lossless compression methods, due to its mechanism, data that is not actually included (registered) in the bit array may be mistakenly identified as being registered in the bit array during the determination process.

The "Maximum Tolerable Misclassification Rate" shown in item 3102 of ID 3101 = "3" is a parameter that specifies the tolerable value of the misclassification rate of the BloomFilter described in ID 3101 = "2". In the case of Figure 3, the value 3103 of the record in question is set to "0.0001".

The "Estimated average verification time" shown in item 3102 for ID 3101 = "4" specifies an estimate of the time required for the access control device 20 to perform verification processing of the authorization request message 510. This estimate is used when the authorization request control unit 130 calculates the time required to buffer the packet of the access request 520. In the case of Figure 3, the value 3103 of the record in question is set to "200 msec."

The "Estimated communication permission time" shown in item 3102 for ID 3101 = "5" specifies the estimated minimum time that the result of the judgment made by the access control device 20 to permit the access request 520 will continue if the access control device 20 verifies the authorization request message 510. In the case of FIG. 3, the value 3103 of the record is set to "10 sec."

The "behavior information compression unit flag" shown in item 3102 of ID 3101 = "6" specifies whether or not to use the function of the behavior information compression unit 121 when creating the authorization request message 510. In the case of Figure 3, the value 3103 of the record is set to "On", which means that it is used.

The "Behavior information prioritization unit flag" shown in item 3102 of ID 3101 = "7" specifies whether or not to use the function of the behavior information prioritization unit 122 when creating the authorization request message 510. In the case of Figure 3, the value 3103 of the record is set to "On", which means that it is used.

The "Behavior update interval" shown in item 3102 of ID 3101 = "8" specifies the time interval at which the behavior monitoring unit 110 reflects the latest behavior information in the behavior monitoring unit management DB 320 (behavior monitoring unit management information). In the case of Figure 3, the value 3103 of the record is set to "10 sec."

The "Expected maximum packet loss rate" shown in item 3102 for ID 3101 = "9" sets the expected maximum packet loss rate that may occur in communication network 41. In the case of Figure 3, the value 3103 of the record in question is set to "20%."

The "own terminal private key" shown in item 3102 of ID 3101 = "10" specifies the key required to create the electronic signature to be attached to the authorization request message 510. In the case of FIG. 3, the value 3103 of the record is set to "fa31cf31...".

Each record with ID3101="11" to "13" is information related to the public key of the access control device 20, and the authorization request message 510 is encrypted with these public keys. In the dynamic access authorization system 1 according to this embodiment, the access control device 20 to which the authorization request message 510 is sent also changes depending on the resource 30 to which the terminal 10 requests access. In the case of FIG. 3, as an example, it is assumed that three access control devices 20 (individually, access control devices X, Y, and Z) exist in the communication network 41. Note that the correspondence between the resource 30 and the access control device 20 may be predetermined and managed in a database, or the IP address of the corresponding access control device 20 may be uniquely identified based on the IP address of the resource 30. Specifically, for example, when the IP address of the resource 30 is "A.B.C.D", the IP address of the corresponding access control device 20 may be "A.B.C.1".

The "Access control device X public key" shown in item 3102 for ID 3101 = "11" specifies the public key of the access control device X. In the case of FIG. 3, the value 3103 of the record is set to "a381f13...".

The "Access control device Y public key" shown in item 3102 for ID 3101 = "12" specifies the public key of the access control device Y. In the case of Figure 3, the value 3103 of the record is set to "c39ddff1...".

The "Access control device Z public key" shown in item 3102 of ID 3101 = "13" specifies the public key of the access control device Z. In the case of Figure 3, the value 3103 of the record is set to "e390413...".

(3-2) Behavior monitoring unit management DB 320
Fig. 4 is a diagram showing an example of behavior monitoring unit management information. Behavior monitoring unit management information 3200 in Fig. 4 is an example of behavior monitoring unit management information stored in the behavior monitoring unit management DB 320, and records information related to the parameters of the behavior monitoring unit 110 and management of behavior information observed and output by the terminal 10. As shown in Fig. 4, the behavior monitoring unit management information 3200 has the following items: ID 3201, behavior monitoring unit name 3202, type 3203, value 3204, output format 3205, compression target 3206, latest behavior information 3207, output size 3208, post-compression size 3209, and adoption flag 3210.

ID 3201 is a code for uniquely identifying a record within the database. Behavior monitoring unit name 3202 indicates the name of each behavior monitoring unit 110.

The type 3203 is an identifier that classifies the behavior monitoring unit 110 based on the monitored object. In FIG. 4, five types of identifiers are shown as examples: "Process", "Communication", "Sensor", "Insider Crime", and "Communication".

The value 3204 is a value indicating the value of the behavior information output by the behavior monitoring unit 110, with a larger value indicating a higher value. The value of the value 3204 is determined in advance by an administrator before the terminal-side program 100 is installed on the terminal 10. However, in the dynamic access authorization system 1, the value of the value 3204 may be changed during operation of the system.

The output format 3205 is the format of the behavior information output by the behavior monitoring unit 110. In FIG. 4, three types of formats are shown as examples: "integer value", "list", and "binary value".

Compression target 3206 is a flag for determining whether or not the behavior information output by behavior monitoring by the behavior monitoring unit 110 is a target for compression processing by the behavior information compression unit 121. When the value of compression target 3206 is "YES", it indicates that it is a target for compression processing, and when the value is "NO", it indicates that it is not a target for compression processing. However, even if the behavior information has compression target 3206 = "YES", if the data size of the behavior information is larger than the maximum allowable data size indicated by ID 3101 = "1" in the terminal setting information 3100, compression processing may not actually be performed.

The latest behavior information 3207 records the latest behavior information output by the behavior monitoring unit 110. After the behavior information compression unit 121 performs a compression process on the behavior information, the latest behavior information 3207 records the value of the compressed behavior information.

The output size 3208 indicates the data size of the latest behavior information 3207. However, for behavior information that has been compressed by the behavior information compression unit 121, the data size of the behavior information before compression is recorded in the output size 3208. Note that depending on the mechanism of the behavior monitoring unit 110, the behavior information may be of variable length, in which case the value of the output size 3208 may change from time to time.

The compressed size 3209 indicates the data size of the behavior information after compression processing has been performed. Note that if the behavior information is not subject to compression processing, a value indicating invalidity, such as "n/a", is recorded in the compressed size 3209.

The adoption flag 3210 is a flag indicating whether or not the record is subject to processing by the behavior information prioritization unit 122, which determines a combination of multiple pieces of behavior information. In other words, it is a flag indicating the result of the determination as to whether or not the behavior information of the record is to be included in the request message 510. In FIG. 4, the adoption flag 3210 is recorded with a value of "On" or "Off."

The specific contents recorded in the behavior monitoring unit management information 3200 in Figure 4 are explained below.

The record with ID 3201 = "1" holds information about the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "number of suspicious process launches". This monitoring behavior unit 100 records the number of times a process that has never occurred in the past occurred within a certain period of time as behavior information. Note that the above "past" strictly means before the above "certain period of time". This also applies to "past" when other records in the behavior monitoring unit management information 3200 are described later. The above "certain period of time" refers to a certain period of time based on the current time. Specific values of the period of time can be in the range of several seconds to several hours, such as "10 seconds", "1 minute", and "1 hour". The value of the period of time may be set to a common value for multiple behavior monitoring units 110, or may be set to an individual value according to the characteristics of each behavior monitoring unit 110. The value may also be changed during operation through a configuration file or the like. An API provided by the OS/application 11 is used to record the behavior information. In the case of FIG. 4, in the record, the type 3203 is "Process", the value 3204 is "5", the output format 3205 is "Integer value", the compression target 3206 is "NO", the latest behavior information 3207 is "1", the output size 3208 is "4 bytes", the compressed size 3209 is "n/a", and the adoption flag 3210 is "On".

The record with ID 3201 = "2" holds information about the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "Number of suspicious communication destinations". This monitoring behavior unit 100 records, as behavior information, the number of unique destinations with which the terminal 10 has not communicated in the past but has communicated for the first time within a certain period of time. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "communication", the value 3204 is "5", the output format 3205 is "integer value", the compression target 3206 is "NO", the latest behavior information 3207 is "3", the output size 3208 is "4 bytes", the compressed size 3209 is "n/a", and the adoption flag 3210 is "On".

The record with ID 3201 = "3" holds information about the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "Process hash value list". This monitoring behavior unit 100 records a list of hash values of processes running on the terminal 10 as behavior information. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "Process", the value 3204 is "5", the output format 3205 is "List", the compression target 3206 is "YES", the latest behavior information 3207 is "83af, 321d, 415f,...", the output size 3208 is "2000 bytes", the compressed size 3209 is "150 bytes", and the adoption flag 3210 is "On".

The record with ID 3201 = "4" holds information about the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "List of running services". This monitoring behavior unit 100 records a list of the names of services running in the terminal 10 as behavior information. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "Service", the value 3204 is "3", the output format 3205 is "List", the compression target 3206 is "YES", the latest behavior information 3207 is "a.service, b.service, ...", the output size 3208 is "1500 bytes", the compressed size 3209 is "400 bytes", and the adoption flag 3210 is "Off".

The record with ID 3201 = "5" holds information about the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "camera enabled or not". This monitoring behavior unit 100 records whether the camera function is enabled in the terminal 10 as behavior information. Specifically, for example, if it is enabled, "True" is recorded in the latest behavior information 3207, and if it is not enabled (disabled), "False" is recorded in the latest behavior information 3207. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "sensor", the value 3204 is "2", the output format 3205 is "binary", the compression target 3206 is "NO", the latest behavior information 3207 is "False", the output size 3208 is "1 byte", the compressed size 3209 is "n/a", and the adoption flag 3210 is "On".

The record with ID 3201 = "6" holds information about the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "microphone enabled or not". This monitoring behavior unit 100 records whether the microphone function is enabled in the terminal 10 as behavior information. Specifically, for example, if it is enabled, "True" is recorded in the latest behavior information 3207, and if it is not enabled (disabled), "False" is recorded in the latest behavior information 3207. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "sensor", the value 3204 is "2", the output format 3205 is "binary", the compression target 3206 is "NO", the latest behavior information 3207 is "True", the output size 3208 is "1 byte", the compressed size 3209 is "n/a", and the adoption flag 3210 is "On".

The record with ID 3201 = "7" holds information related to the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "user idle time". This monitoring behavior unit 100 records the difference between the date and time when the user last operated the terminal 10 through an interface such as a keyboard or mouse and the current date and time as behavior information. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "user", the value 3204 is "2", the output format 3205 is "binary", the compression target 3206 is "NO", the latest behavior information 3207 is "450", the output size 3208 is "4 bytes", the compressed size 3209 is "n/a", and the adoption flag 3210 is "Off".

The record with ID 3201 = "8" holds information related to the behavior monitoring unit 110, whose behavior monitoring unit name 3202 is "Number of print executions". This monitoring behavior unit 100 records the number of times a user prints within a certain period of time as behavior information. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "internal crime", the value 3204 is "3", the output format 3205 is "integer value", the compression target 3206 is "NO", the latest behavior information 3207 is "30", the output size 3208 is "4 bytes", the compressed size 3209 is "n/a", and the adoption flag 3210 is "On".

The record with ID 3201 = "9" holds information related to the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "Whether USB memory is inserted". This monitoring behavior unit 100 records, as behavior information, whether or not a USB memory that has never been used before has been inserted into the terminal 10 within a certain period of time. Specifically, for example, if a USB memory that has never been used before is inserted into the terminal 10, "True" is recorded in the latest behavior information 3207, and if the USB memory has not been inserted into the terminal 10, "False" is recorded in the latest behavior information 3207. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "internal crime", the value 3204 is "4", the output format 3205 is "binary", the compression target 3206 is "NO", the latest behavior information 3207 is "False", the output size 3208 is "1 byte", the compressed size 3209 is "n/a", and the adoption flag 3210 is "Off".

The record with ID 3201 = "10" holds information about the behavior monitoring unit 110 whose behavior monitoring unit name 3202 is "upload traffic volume". This monitoring behavior unit 100 records the maximum amount of data sent to a computer on the Internet within a certain period of time as behavior information. For recording, an API provided by the OS/application 11 is used. In the case of FIG. 4, in the record, the type 3203 is "communication", the value 3204 is "5", the output format 3205 is "", the compression target 3206 is "NO", the latest behavior information 3207 is "1310", the output size 3208 is "4 bytes", the compressed size 3209 is "n/a", and the adoption flag 3210 is "On".

(3-3) Authorization Request Message History DB 330
Fig. 5 is a diagram showing an example of authorization request message history information. The authorization request message history information 3300 in Fig. 5 is an example of authorization request message history information stored in the authorization request message history DB 330, and records information such as a transmission destination and a transmission date and time for an authorization request message 510 issued in the past by the terminal 10. As shown in Fig. 5, the authorization request message history information 3300 has items of an ID 3301, a destination access control device 3302, and an authorization request message transmission date and time 3303.

The ID 3301 is a code for uniquely identifying a record in the database. The destination access control device 3302 is information indicating the access control device 20 that is the destination of the authorization request message 510. The authorization request message transmission date and time 3303 is the date and time when the authorization request message 510 is transmitted to the access control device 20 specified by the destination access control device 3302.

The specific contents recorded in the authorization request message history information 3300 in Figure 5 are explained below.

The record with ID 3301 = "1" means that an authorization request message 510 was sent to access control device X on the dates and times "2021-03-08 15:00:00", "2021-03-08 15:00:01", and "2021-03-08 15:00:02".

The record with ID 3301 = "2" means that an authorization request message 510 was sent to access control device Y on the dates and times "2021-03-08 13:00:00" and "2021-03-08 14:00:00".

The record with ID 3301 = "3" means that an authorization request message 510 was sent to access control device Z on the dates and times "2021-03-08 16:00:00" and "2021-03-08 16:00:10".

(3-4) Access control setting DB 410
Fig. 6 is a diagram showing an example of access control setting information. Access control setting information 4100 in Fig. 6 is an example of access control setting information stored in the access control setting DB 410, and records information on various setting items in the access control device 20. As shown in Fig. 6, the access control setting information 4100 has items of ID 4101, item 4102, and value 4103.

The ID 4101 is a code for uniquely identifying a record within the database. The item 4102 is a code indicating a setting item, and is expressed, for example, as a character string. The value 4103 indicates a value corresponding to the item 4102, and the value can be any value, such as a character string or a numeric value.

The specific contents recorded in the access control setting information 4100 in Figure 6 are explained below.

The "control device private key" shown in item 4102 of ID 4101 = "1" specifies the private key managed by the access control device 20 that holds the access control setting information 4100. In the case of Figure 6, the value 4103 of the record is set to "1cf32d31...".

Each record with ID4101="2" to "4" is information related to the public key of a terminal 10 that may access the access control device 20. Specifically, the "Terminal A Public Key" shown in item 4102 with ID4101="2" specifies the public key of terminal A, and in the case of FIG. 6, the value 4103 of the record is "1deaf13...". The "Terminal B Public Key" shown in item 4102 with ID4101="3" specifies the public key of terminal B, and in the case of FIG. 6, the value 4103 of the record is "f3932cf1...". The "Terminal C Public Key" shown in item 4102 with ID4101="4" specifies the public key of terminal C, and in the case of FIG. 6, the value 4103 of the record is "c3d0436...".

The "information decompression target monitoring unit" shown in item 4102 with ID 4101 = "5" specifies the behavior monitoring unit name 3202 of the behavior monitoring unit 110 for which compression processing may be performed. In the configuration described here, as shown in Figure 6, the value 4103 specifies a "list of process hash values" and a "list of launched services."

The "shutdown mode" shown in item 4102 of ID 4101 = "6" specifies the shutdown mode that is set when the access determination unit 240 determines whether to allow access and the communication is to be shut down. The value 4103 of the record records a selectable shutdown mode flag. Specifically, for example, a shutdown mode flag that completely shuts down access requests 520 after a decision to shut down communication is set to "complete shutdown," and a shutdown mode flag that provides a period during which access requests 520 are unconditionally permitted after a certain shutdown period after a decision to shut down communication is set to "temporary shutdown." When the "temporary shutdown" shutdown mode is selected, even if normal communication is shut down due to an erroneous decision, by providing a certain period of communication permission thereafter, it is possible to avoid a complete stop in business due to the shutdown of the normal communication.

The "Communication cutoff interval" shown in item 4102 of ID 4101 = "7" specifies the length of the cutoff period when the "temporary cutoff" cutoff mode is performed. In the case of Figure 6, the value of value 4103 of the relevant record is "30 sec."

The "communication passing interval" shown in item 4102 of ID 4101 = "8" specifies the length of the period (communication permission period) during which the access request 520 is unconditionally permitted to pass when the access determination unit 240 permits the access request 520 to pass, or when the communication of the access request 520 is temporarily blocked and the communication blocking period has passed. After this communication permission period has passed, the access request 520 is blocked until the authorization request message 510 is approved again. In the case of FIG. 6, the value of the value 4103 of the record is "40 sec". Note that once the authorization request message 510 has been approved for communication, it will not be blocked until the communication ends, regardless of the specification of the communication passing interval.

(3-5) Access Policy Script DB 420
Fig. 7 is a diagram showing an example of an access policy script. An access policy script 4200 in Fig. 7 is an example of an access policy script stored in the access policy script DB 420, and is referenced when the access control unit 250 performs an authorization decision process for an authorization request message 510. As shown in Fig. 7, the access policy script 4200 has items of an ID 4201, a script 4202, and a compression behavior information keyword 4203.

ID4201 is a code that uniquely identifies a record within the database.

The script 4202 describes the access policy script. In the access policy script, logical expressions are described from three perspectives: "subject" indicating the attribute of the terminal 10 that is the access source, "resource" indicating the attribute of the resource 30 that is the access destination, and "behavior" which is behavior information observed by the terminal 10. Then, only if the contents included in the authorization request message 510 satisfy all of the logical expressions, a decision is made to pass or block according to the description of "judgment". Possible attributes of "subject" include the IP address or identifier of the terminal 10, the user name or account ID of the user operating the terminal 10, or the user's job title, the name of the organization to which the user belongs, and the security clearance given. Possible attributes of "resource" include the IP address of the resource 30, the type of service provided, and the like.

The compressed behavior information keyword 4203 indicates a "keyword" that is checked for whether it is recorded in the behavior information that has been subjected to lossy compression processing during the compressed behavior information decompression processing by the behavior information decompression unit 230 (see FIG. 15 described later). The keyword written in the compressed behavior information keyword 4203 is a value extracted from the description of the script 4202 that corresponds to the value 4103 of the information decompression target monitoring unit specified by ID 4101 = "5" in the access control setting information 4100.

The specific contents recorded in the access policy script 4200 in Figure 7 are explained below.

Script 4202 of record with ID 4201 = "1" is an example of an access policy script with "judgment" = "pass". The requirement that the subject must satisfy is stipulated that the user name operating the terminal 10 is "Alice". Next, the requirement that the "resource" must satisfy is stipulated that the IP address of the resource 30 is included in "10.0.0.8/8". Next, logical expressions related to three behavior information are stipulated as "behavior". If multiple logical expressions are stipulated, one or more or all of them must be satisfied. Here, "AND" is used to stipulate that all logical expressions must be satisfied. The first logical expression stipulates that the "number of suspicious process startups" specified by ID 3201 = "1" in the behavior monitoring unit management information 3200 is less than 20. The second logical expression specifies that the "user idle time" specified by ID 3201 = "7" in the behavior monitoring unit management information 3200 is within 120 seconds. The third logical expression specifies that the "list of launched services" specified by ID 3201 = "4" in the behavior monitoring unit management information 3200 includes "antivirus X" and "security service Y." The compressed behavior information keyword 4203 in the record contains "antivirus X" and "security service Y."

Script 4202 of record with ID 4201 = "2" is an example of an access policy script with "judgment" = "blocked". The requirement satisfied by "subject" specifies that the security clearance of the user operating terminal 10 is "H". Next, the requirement satisfied by "resource" specifies that the type of service provided by resource 30 is "database". Next, "behavior" specifies that "3abe4b2" or "ffa3bf23" is included in the "process hash value list" specified by ID 3201 = "3" in behavior monitoring unit management information 3200. And, "3abe4b2" and "ffa3bf23" are written in compression behavior information keyword 4203 in the record.

(3-6) Access Authorization Information DB 430
Fig. 8 is a diagram showing an example of access authorization information. Access authorization information 4300 in Fig. 8 is an example of access authorization information stored in the access authorization information DB 430, and information indicating the determination result of the authorization determination performed by the access determination unit 240 is recorded. The access control unit 250 performs a pass/block process for the access request 520 in accordance with the access authorization information. As shown in Fig. 8, the access authorization information 4300 has the following items: ID 4301, terminal IP address 4302, resource IP address 4303, message timestamp 4304, communication blockage period 4305, and communication pass period 4306.

The ID 4301 is a code for uniquely identifying a record in the database. The terminal IP address 4302 indicates the IP address of the terminal 10 that is to be passed or blocked. The resource IP address 4303 indicates the IP address of the resource 30 to which the terminal 10 requests access. The message timestamp 4304 indicates the date and time when the authorization decision for the authorization request message 510 was made.

The communication cutoff period 4305 indicates the period for which communication is cut off if the result of the authorization decision is "temporary cutoff". If the result of the authorization decision is "complete cutoff" or "pass", "N/A" is entered in the communication cutoff period 4305. The difference between the start date and time and the end date and time of the communication cutoff period is specified in the "communication cutoff interval" record with ID 4101 = "7" in the access control setting information 4100.

The communication passing period 4306 indicates the period during which an access request 520 is permitted to pass from the terminal IP address 4302 to the resource IP address 4303. If this period has elapsed, the access request 520 is necessarily blocked. The difference between the start date and time and the end date and time of the communication passing period is specified in the "communication passing interval" record with ID 4101 = "8" in the access control setting information 4100.

In the access authorization information 4300 illustrated in FIG. 8, the destination port number of the resource 30 is not included as an item. However, as a modified example, the access authorization information may include the destination port number, making it possible to control whether communication passes or is blocked depending on the destination port number. In this case, it is possible to control communication to port 80, for example, but to block communication to port 443.

The specific contents recorded in the access authorization information 4300 in Figure 8 are explained below.

The record with ID 4301 = "1" has terminal IP address 4302 = "10.0.0.1", resource IP address 4303 = "20.0.0.1", message timestamp 4304 = "20:23:10", communication cutoff period 4305 = "20:23:10 to 20:23:40", and communication pass period 4306 = "20:23:40 to 20:24:20".

The record with ID 4301 = "2" has terminal IP address 4302 = "10.0.0.1", resource IP address 4303 = "20.0.0.2", message timestamp 4304 = "21:00:00", communication cutoff period 4305 = "N/A", and communication pass period 4306 = "21:00:00 to 21:00:40".

The record with ID 4301 = "3" has terminal IP address 4302 = "10.0.0.2", resource IP address 4303 = "20.0.0.2", message timestamp 4304 = "22:12:03", communication cutoff period 4305 = "22:12:03 to 22:12:33", and communication pass period 4306 = "22:12:33 to 22:13:13".

(3-7) Various Messages Fig. 9 is a diagram showing an example of the data format of the authorization request message 510. A data format 5100 shown in Fig. 9 is an example of the data format of the authorization request message 510, and the data format 5100 is configured to have an ID 5101 and items 5102.

The ID 5101 is a code for uniquely identifying each item 5102 in the authorization request message 510. The items 5102 are codes indicating each item and are represented, for example, by a character string.

The following describes the details of each item in the data format 5100 in Figure 9.

The "timestamp" shown in item 5102 for ID 5101 = "1" indicates the date and time when the authorization request message 510 was created. This information is used to prevent a replay attack in which an attacker attempts to perform fraudulent authorization by repeatedly transmitting an intercepted authorization request message 510 to the access control device 20.

The "Terminal Identifier/Attributes" shown in item 5102 of ID 5101 = "2" indicates a terminal identifier for identifying the terminal 10 and attribute information of the terminal 10. For example, an IP address or a computer name can be used as the terminal identifier, and for example, information regarding the type or use of the terminal 10 can be used as the attribute information.

The "User Identifier/Attributes" shown in item 5102 for ID 5101 = "3" indicates a user identifier for identifying the user operating the terminal 10, and the user's attribute information. The user identifier may be, for example, a user name or an employee number, and the attribute information may be, for example, the user's security clearance or affiliation.

The "destination resource identifier/attributes" shown in item 5102 for ID 5101 = "4" indicates the destination resource identifier for identifying the resource 30 (destination resource) to which access request 520 corresponding to authorization request message 510 requests access, and the attribute information of the destination resource. For example, the destination resource identifier may be the IP address or computer name of the destination resource. The destination resource identifier may also include the port number provided by the service of the resource 30. For example, information regarding the type or use of the resource 30 may be used as the attribute information.

The "Behavior Information List" shown in item 5102 of ID 5101 = "5" lists the behavior information included in the authorization request message 510. In other words, the "Behavior Information List" shown in item 5102 of ID 5101 = "5" lists behavior information for which the adoption flag 3210 becomes "On" at a certain timing in the behavior monitoring unit management information 3200. Note that the behavior information listed in the "Behavior Information List" is listed for each identifier of the behavior monitoring unit 110, and it is possible to extract only the behavior information related to a specific behavior monitoring unit 110 later.

The "shared key" shown in item 5102 of ID 5101 = "6" describes the shared key code for encrypting each item of ID 5101 = "1" to "5". In addition, the shared key itself is encrypted with the public key of the access control device 20 recorded in ID 3101 = "11" to "13" of the terminal setting information 3100.

The "Terminal side electronic signature" shown in item 5102 of ID 5101 = "7" contains an electronic signature calculated using the terminal's own private key recorded in ID 3101 = "10" of the terminal setting information 3100.

When transmitting the authorization request message 510, it is preferable that all items ID 5101 = "1" to "6" are transmitted in an encrypted state.

Figure 10 is a diagram showing an example of an administrator notification message 530. In Figure 10, administrator notification message 530A and administrator notification message 530B are shown as specific examples of administrator notification message 530.

In administrator notification messages 530A and 530, the reason for the determination that the access request from terminal 10 to resource 30 was "completely blocked" is stated from the perspective of the behavior of terminal 10 or the user. More specifically, administrator notification message 530A states that the reason is that the behavior information for "user idle time" specified by ID 3201 = "7" in behavior monitoring unit management information 3200 exceeded a prescribed value. On the other hand, administrator notification message 530A states that the behavior information for "startup service list" specified by ID 3201 = "4" in behavior monitoring unit management information 3200 did not satisfy the conditions.

(4) Processing The following describes in detail the processing executed by the dynamic access authorization system 1 when a request for access to the resource 30 is made from the terminal 10 in response to a user operation or the like.

(4-1) Processing by the terminal 10 Fig. 11 is a sequence diagram showing an example of a processing procedure performed on the terminal 10 side. Note that in Fig. 11, the processing by the behavior information compression unit 121 and the behavior information prioritization unit 122 is described as processing by the behavior information adjustment unit 120.

The behavior monitoring units 110 shown in FIG. 11 correspond to the behavior monitoring units described in each record of the behavior monitoring unit management information 3200 stored in the behavior monitoring unit management DB 320. As shown in FIG. 11, each of these behavior monitoring units 110 monitors the behavior of the terminal 10 and the user (step S101).

Then, the behavior monitoring unit 110 updates the latest behavior information 3207 of the behavior monitoring unit management information 3200 based on the monitoring result in step S101, and periodically notifies the behavior information adjustment unit 120 of the behavior information update (step S102). After notifying the update in step S102, the behavior monitoring unit 110 returns to step S101 and repeats behavior monitoring.

The update interval of the behavior monitoring unit management information 3200 in step S102 follows the behavior update interval described in the record with ID 3101 = "8" in the terminal setting information 3100 stored in the terminal setting DB 310. With these configurations, it is possible to adjust the balance between the computational load on the terminal side program 100 and the real-time nature of the behavior information.

The behavior information adjustment unit 120 receives the update notification of the behavior information sent from the behavior monitoring unit 110 in step S102 (step S111). Next, the behavior information adjustment unit 120 sums up the data size of each piece of behavior information listed in the output size 3208 of the behavior monitoring unit management information 3200, and checks whether the sum exceeds the maximum allowable data size (see the record with ID = "1" in the terminal setting information 3100) (step S112). In step S112, if the sum of the behavior information exceeds the maximum allowable data size (YES in step S112), the process proceeds to step S113, and if the sum of the behavior information is equal to or smaller than the maximum allowable data size (NO in step S112), the process proceeds to step S115.

In step S113, the behavior information compression unit 121, which is a part of the behavior information adjustment unit 120, performs compression processing on behavior information that satisfies the predetermined conditions described below. In detail, the behavior information compression unit 121 checks the "behavior information compression unit flag" specified by ID 3101 = "6" in the terminal setting information 3100, and if the flag is "On", performs compression processing on the latest behavior information 3207 of the behavior information to be compressed (behavior information for which compression target 3206 = "YES" in the behavior monitoring unit management information 3200) according to the compression method specified by ID 3101 = "2" in the terminal setting information 3100. On the other hand, if the "behavior information compression unit flag" is "Off", the behavior information compression unit 121 ends the processing of step S113 and proceeds to step S114.

In addition, in step S113, the behavior information compression unit 121 reflects the results of the compression process in the latest behavior information 3207 and the compressed size 3209. Then, if the total value of the data size of the behavior information after the compression process exceeds the maximum allowable data size, the process proceeds to step S114.

The mechanism of the compression process in step S113 depends on the "behavior information compression method" specified by ID 3101 = "2" in the terminal setting information 3100. Here, when BloomFiler is used as the behavior information compression method, the bit array element at the position corresponding to the hash value of each piece of behavior information is set to "1". For example, when the behavior monitoring unit 110 corresponding to the behavior information to be compressed is the "list of launched services" indicated by ID 3201 = "4" in the behavior monitoring unit management information 3200, the bit array is manipulated based on the hash values of "a.service" and "b.service".

In step S114, the behavior information prioritization unit 122, which is part of the behavior information adjustment unit 120, performs a prioritization process to calculate a combination of behavior information to be included in the authorization request message 510, using the procedure described in detail below.

In the prioritization process, the behavior information prioritization unit 122 first checks the "behavior information prioritization unit flag" specified by ID 3101 = "7" in the terminal setting information 3100. If the "behavior information prioritization unit flag" is "Off", this means that no actual prioritization process is required, so the behavior information prioritization unit 122 sets all adoption flags 3210 to "On" and proceeds to step S115.

When the "behavior information prioritization unit flag" is "On", the behavior information prioritization unit 122 derives a combination of behavior information that maximizes the total value of the value 3204 of the behavior information to be transmitted, under the constraint that the total value of the behavior information to be transmitted is equal to or less than the maximum allowable data size. After deriving the above combination, proceed to step S115.

Mathematical processing such as genetic algorithms and linear programming can be used to derive the above combinations of behavior information. For example, when using a genetic algorithm, a fixed number of candidates for combinations (sets) of behavior information to be transmitted are randomly generated. Then, among these, operations such as random operations and multiplication with other sets are repeatedly performed on sets whose total size is equal to or less than the maximum allowable data size and whose total value 3204 is relatively high, to sequentially find sets with higher value. Then, when the number of repetitions exceeds a prescribed number, a combination of behavior information is derived with the latest behavior information 3207 included in the most valuable set as the transmission target.

In addition, in terms of performing dynamic authorization from various viewpoints, it is desirable to combine sets including behavior information of different types 3203 as much as possible. Therefore, the types of types included in the set may be used as parameters when deriving the optimal set. For example, in the example of a genetic algorithm, the total value of value 3204 may be multiplied by the types of types 3203 included in the set and used as the value of the set. Specifically, for example, when behavior information of IDs 3201 = "2" and "10" in the behavior monitoring unit management information 3200 is combined, the types of types 3203 are the same, so the value of this combination is (5 + 5) x 1 = 10, and the total value of output size 3208 is 8 bytes. On the other hand, when behavior information of IDs 3201 = "1" and "2" is combined, the types of types 3203 are different, so the value of this combination is (5 + 5) x 2 = 20, and the total value of output size 3208 is 8 bytes. Therefore, in this case, even if the total output size is the same, it is more valuable and desirable to combine the behavior information for ID3201="1" and "2".

In step S115, the behavior information adjustment unit 120 determines the behavior information to be adopted in the authorization request message 510 based on the processing results of steps S112 to S114. In more detail, if the judgment result of step S112 is "NO" (in other words, if the prioritization processing of step S114 was not performed), the behavior information adjustment unit 120 sets the adoption flag 3210 of all records in the behavior monitoring unit management information 3200 to "On" and sets all behavior information to be transmitted by the authorization request message 510. On the other hand, if the judgment result of step S112 is "YES" (in other words, if the prioritization processing of step S114 was performed), the behavior information adjustment unit 120 sets the adoption flag 3210 corresponding to the behavior information included in the set selected in step S114 in the behavior monitoring unit management information 3200 to "On" and sets the adoption flag 3210 corresponding to the other behavior information to "Off".

By carrying out the above processing of steps S111 to S115, the behavior information of the record in which the adoption flag 3210 is set to "On" in the behavior monitoring unit management information 3200 is finally determined as the behavior information to be included in and sent in the authorization request message 510. Then, after the processing of step S115 is completed, the process returns to step S111, and the behavior information adjustment unit 120 waits for a notification of an update to the behavior information.

The authorization request control unit 130 monitors the creation of an access request 520 by the terminal 10 or a user, and captures the access request 520 when it is created (step S121).

When the authorization request control unit 130 captures the creation of an access request 520 in step S121, it determines whether or not an authorization request message 510 needs to be created for the access request 520 (step S122).

The simplest method for determining whether or not an authorization request message 510 needs to be created is to create an authorization request message 510 for each of the captured access requests 520. On the other hand, when a large number of access requests 520 are created in a short period of time, it is not necessary to create an authorization request message 510 for each of the access requests 520. In addition, since there is always a possibility of packet loss occurring on the communication network 41, there is also the problem that not all authorization request messages previously transmitted from the terminal 10 are necessarily accepted by the access control device 20. Therefore, in step S122, the authorization request control unit 130 of this embodiment determines whether or not an authorization request message 510 needs to be created by executing an authorization request message necessity determination process described in detail in FIG. 12.

Figure 12 is a flowchart showing an example of the processing procedure for determining whether an authorization request message is necessary. As described above, the authorization request message necessity determination process is executed by the authorization request control unit 130.

According to FIG. 12, first, the authorization request control unit 130 counts the number of times that the authorization request message 510 was sent to the access control device 20 corresponding to the resource 30 to which the access request 520 was sent within the "estimated communication permission time" specified by ID 3101 = "5" in the terminal setting information 3100, starting from the current date and time, and determines whether or not a transmission was made (step S141). The number of transmissions can be counted by referring to the authorization request message history information 3300 held in the authorization request message history DB 330. If the number of transmissions is other than "0" (YES in step S141), the process proceeds to step S142. On the other hand, if the number of transmissions is "0" (NO in step S141), the process proceeds to step S143.

In step S142, the authorization request control unit 130 calculates the "transmission probability" by a predetermined function that takes as arguments the number of transmissions (number of authorization request message transmissions) counted in step S141 and the "expected maximum packet loss rate" specified by ID 3101 = "9" in the terminal setting information 3100. This calculated value is set in an internal parameter indicating the "transmission probability." One example of a function for calculating the transmission probability is a function that raises the number of authorization request message transmissions to the power of the "expected maximum packet loss rate." After processing in step S142, the process proceeds to step S144.

On the other hand, if the process proceeds to step S143, the authorization request control unit 130 sets the internal parameter "transmission probability" to "1.0" and proceeds to step S144.

In step S144, the authorization request control unit 130 determines whether or not it is necessary to transmit the authorization request message 510 in proportion to the "transmission probability" set in step S142 or step S143. For example, if the "transmission probability" = "1.0", it is determined that it is necessary to transmit the authorization request message 510, and therefore the authorization request message 510 is always transmitted in step S132, which will be described later.

By executing the processes in steps S141 to S144, the authorization request control unit 130 can determine whether or not it is necessary to create an authorization request message 510 for the captured access request 520.

Returning to the explanation of FIG. 11, after the processing of step S122 is completed, the authorization request control unit 130 checks whether it has been determined in step S122 that the authorization request message 510 needs to be created (in other words, whether it has been decided to transmit the authorization request message 510) (step S123). If it has been determined that the authorization request message 510 needs to be created (YES in step S123), the process proceeds to step S124, and if it has been determined that the authorization request message 510 does not need to be created (NO in step S123), the process returns to step S121.

In step S124, the authorization request control unit 130 sends a request to create the authorization request message 510 to the authorization request message sending unit 140. The processing on the authorization request message sending unit 140 side will be described later.

After processing step S124, the authorization request control unit 130 calculates the time interval (transmission interval) to wait from the last transmission of the authorization request message 510 until the transmission of the access request 520 captured in step S121 (step S125).

Here, if the transmission interval is too short, the access request 520 will be transmitted from the terminal 10 and will arrive at the access control device 20 before the authorization decision for the authorization request message 510 in the access control device 20 is completed, and communication will not be established normally in the access control device 20. On the other hand, if the transmission interval is too long, communication efficiency will deteriorate. Therefore, in step S125, the authorization request control unit 130 of this embodiment executes a transmission interval calculation process described in detail in FIG. 13 to calculate a "transmission interval" equivalent to the waiting time until the access request 520 is transmitted.

Figure 13 is a flowchart showing an example of the processing procedure for the transmission interval calculation process. As described above, the transmission interval calculation process is executed by the authorization request control unit 130.

According to FIG. 13, first, the authorization request control unit 130 judges whether or not the authorization request message 510 has been transmitted within the "estimated communication permitted time" specified by ID 3101 = "5" in the terminal setting information 3100 (step S151). The transmission history of the past authorization request message 510 can be confirmed by referring to the authorization request message history information 330 held in the authorization request message history DB 330. If there is a history of transmitting the authorization request message 510 within the estimated communication permitted time (YES in step S151), the process proceeds to step S152. On the other hand, if there is no history of transmitting the authorization request message 510 within the estimated communication permitted time (NO in step S151), the process proceeds to step S153.

In step S152, the authorization request control unit 130 calculates the "transmission interval" by a predetermined function that takes as arguments the "estimated average verification time" specified by ID 3101 = "4" in the terminal setting information 3100 and the elapsed time from the date and time of the last transmission of the authorization request message 510 to the current date and time. This calculated value is set in an internal parameter indicating the "transmission interval". As an example of a function for calculating the transmission interval, the transmission interval may be calculated from the formula "transmission interval = elapsed time x EXP (-1 x elapsed time / estimated average verification time)" by utilizing the fact that the distribution of processing time is often represented by an exponential distribution in queuing theory. When the processing of step S152 is completed, the authorization request control unit 130 ends the transmission interval calculation processing.

On the other hand, if the process proceeds to step S153, the authorization request control unit 130 sets the internal parameter of the "transmission interval" to the "estimated average verification time" and terminates the transmission interval calculation process.

By executing the processes of steps S151 to S153 as described above, the authorization request control unit 130 can calculate the time interval (transmission interval) to wait before transmitting the captured access request 520.

Returning to the explanation of FIG. 11, after the processing of step S125 is completed, the authorization request control unit 130 waits until the transmission interval calculated in step S125 has elapsed (step S126).

After the transmission interval has elapsed, the authorization request control unit 130 transmits the access request 520 that was captured and kept waiting in step S121 to the access control device 20, and then returns to step S121.

Next, the processing of the authorization request message sending unit 140 will be described. The authorization request message sending unit 140 first receives a request to create the authorization request message 510 sent from the authorization request control unit 130 in step S124 (step S131).

Then, the authorization request message sending unit 140 creates an authorization request message 510 by placing the behavior information for which the adoption flag 3210 is set to "On" in the behavior monitoring unit management information 3200 in the data format 5100 shown in FIG. 9, and sends the created message to the access control device 20 (step S132). Note that when creating the authorization request message 510 in step S132, the behavior information is written in a record of the "behavior information list" specified by ID 5101 = "5" in the data format 5100. More specifically, each piece of behavior information for which the adoption flag 3210 is set to "On" is represented by a pair of the ID 3210 of the corresponding record in the behavior monitoring unit management information 3200 and the latest behavior information 3207, and information summarizing all the corresponding behavior information is incorporated into the authorization request message 510 as the "behavior information list".

After transmitting the authorization request message 510, the authorization request message transmitting unit 140 updates the authorization request message history information 3300 stored in the authorization request message history DB 330, and specifically, in the corresponding record, adds the transmission date and time of the authorization request message 510 to the authorization request message transmission date and time 3303. After the above processing is completed, the authorization request message transmitting unit 140 returns to the processing of step S131.

(4-2) Processing by the Access Control Device 20 Fig. 14 is a sequence diagram showing an example of a processing procedure performed by the access control device 20. The sequence shown in Fig. 14 is divided into a setting phase in which preparations are made for performing authorization processing of an access request, and an operation phase in which the authorization processing is actually performed, and the setting phase is completed at least before the operation phase is started.

First, we will explain the processes included in the setting phase, namely, steps S201 to S202 executed by the policy management unit 210, and steps S211 to S212 executed by the behavior information decompression unit 230.

In the setting phase, the policy management unit 210 provides the administrator with a user interface for creating the access policy script 4200 (step S201). In the above user interface, the administrator may directly create the script text written in the script 4202, or may create the script in a simpler manner using known automatic input assistance, etc.

Then, the policy management unit 210 stores the access policy script created by the administrator using the user interface provided in step S201 in the access policy script DB 420 (step S202).

In the setting phase, the behavior information decompression unit 230 reads each record of the access policy script 4200 stored in the access policy script DB 420 (step S211).

Then, the behavior information decompression unit 230 searches for a description related to the "information decompression target monitoring unit" specified by ID 4101 = "5" in the access control setting information 4100 from the access policy script 4200 (script 4202) read in step S211, extracts elements used for access control, and records them in the compressed behavior information keyword 4203 of the record (step S212). Specifically, in the case of the record with ID 4201 = "1" in Figure 7, "antivirus X" and "security service Y" included in the "startup service list" described in the "information decompression target monitoring unit" are applicable. Similarly, in the case of the record with ID 4201 = "2", "3abe4b2..." and "ffa3bf23..." included in the "process hash value list" are applicable.

Below, the processes included in the operation phase are described as steps S221 to S225 executed by the authorization request message receiving unit 220, steps S231 to S233 executed by the behavior information decompression unit 230, steps S241 to S243 executed by the access determination unit 240, and steps S251 to S252 executed by the access control unit 250.

First, the authorization request message receiving unit 220 receives the authorization request message 510 sent from the authorization request message sending unit 140 of the terminal 10 in step S132 of FIG. 11 (step S221).

Next, the authorization request message receiving unit 220 decrypts the authorization request message 510 received in step S221 using the "control device private key" indicated by ID 4101 = "1" in the access control setting information 4100 and the "common key" indicated by ID 5101 = "6" in the authorization request message 510, and verifies the "terminal side electronic signature" indicated by ID 5101 = "7" in the authorization request message 510 to confirm that it has not been tampered with (step S222). Furthermore, in step S222, the authorization request message receiving unit 220 compares the "timestamp" indicated by ID 5101 = "1" in the authorization request message 510 with the current date and time to confirm that the authorization request message 510 is not a replay attack.

Next, the authorization request message receiving unit 220 sends the "behavior information list" for ID 5101 = "5" contained in the authorization request message 510 decrypted in step S222 to the behavior information decompression unit 230, requesting decompression of the compressed behavior information (step S223).

Next, the authorization request message receiving unit 220 receives from the behavior information decompression unit 230 the behavior information (behavior information list) after the behavior information requested in step S223 has been decompressed, and replaces the value of the "behavior information list" for ID 5101 = "5" in the authorization request message 510 with the decompressed behavior information (step S224).

Next, the authorization request message receiving unit 220 transmits the authorization request message 510 after the processing of step S224 to the access determination unit 240 and requests an authorization determination (step S225). After the processing of step S225, the process returns to step S221.

When the behavior information decompression unit 230 is requested to decompress the behavior information list by the authorization request message receiving unit 220 in step S223, the behavior information decompression unit 230 receives the behavior information list (step S231). Note that in the following description, the behavior information list received in step S231 is assumed to include behavior information that has been subjected to compression processing, but compression processing is not necessarily required for all behavior information, and it is also possible that not all behavior information has been compressed. However, if not all behavior information included in the behavior information list has been compressed, the processing of steps S231 to S233 is substantially unnecessary, and therefore, for example, the authorization request message receiving unit 220 may skip the processing of steps S223 to S224.

Next, the behavior information decompression unit 230 executes a compressed behavior information decompression process for one or more pieces of behavior information included in the behavior information list received in step S231 to decompress the compressed behavior information (step S232).

Figure 15 is a flowchart showing an example of the processing procedure for the compressed behavior information decompression process. As described above, the compressed behavior information decompression process is executed by the behavior information decompression unit 230.

According to FIG. 15, first, the behavior information decompression unit 230 accesses the access policy script 4200 stored in the access policy script DB 420 and collects the compressed behavior information keywords 4203 (step S261).

Next, the behavior information decompression unit 230 selects, one by one, from among the behavior information included in the "behavior information list" received from the authorization request message receiving unit 220, behavior information by the behavior monitoring unit 110 corresponding to the "information decompression target monitoring unit" specified in ID 4101 = "5" of the access control setting information 4100, and performs the processing of the following steps S263 to S265 (step S262).

In step S263, the behavior information decompression unit 230 selects one keyword for each of the keywords corresponding to the behavior information selected in step S262 from the compressed behavior information keywords 4203 collected in step S261, and performs the processes of steps S264 to S265. When the access policy script 4200 shown in FIG. 7 is used, "antivirus X", "security service Y", "3abe4b2...", and "ffa3bf3bf23..." correspond to the above keywords.

In step S264, the behavior information decompression unit 230 checks whether the behavior information selected in step S262 includes the keyword selected in step S263. If the behavior information includes the keyword (YES in step S264), the process proceeds to step S265. On the other hand, if the behavior information does not include the keyword (NO in step S264), the process returns to step S263, and the next keyword is selected.

The method of checking the keyword in step S264 differs depending on the "behavior information compression method" specified by ID 3101 = "2" in the terminal setting information 3100. For example, if the behavior information compression method is BloomFilter, the compressed behavior information is a bit array. Therefore, in step S264, the behavior information decompression unit 230 can determine whether the keyword is included in the bit array of the behavior information by determining whether the element corresponding to the hash value of the keyword is "1", similar to the process when the behavior information adjustment unit 120 compresses the behavior information using BloomFilter in step S113 of FIG. 11. Specifically, for example, if the behavior information corresponding to the "behavior service list" is a bit array and the element corresponding to the hash value of the character string "antivirus X" is "1", then the behavior information includes "antivirus X".

In step S265, the behavior information extension unit 230 adds the keyword selected in step S263, for example in plain text, to the behavior information selected in step S262.

After processing in step S265, the process returns to step S263, and the next keyword is selected. When the processes in steps S264 to S265 are completed for all keywords, the process returns to step S262, and the next behavior information is selected. When the processes in steps S263 to S265 are completed for all behavior information, the behavior information decompression unit 230 ends the compressed behavior information decompression process.

By performing the compressed behavior information decompression process as described above, the keywords contained in the behavior information compressed using a lossy compression method cannot be directly referenced, but by adding the keywords in step S265, the keywords contained in the behavior information after decompression can be directly referenced.

Returning to the explanation of FIG. 14, after the processing of step S232 is completed, the behavior information decompression unit 230 returns the behavior information list decompressed in step S232 (more specifically, the behavior information list consisting of the behavior information to which the keyword has been added) to the authorization request message receiving unit 220 (step S233). After the processing of step S233 is completed, the process returns to step S231.

The access determination unit 240 receives a request for authorization determination for the authorization request message 510 sent from the authorization request message receiving unit 220 in step S225 (step S241).

Next, the access determination unit 240 determines the contents of the authorization request message 510 received in step S241 based on the script 4202 of the access policy script 4200 stored in the access policy script DB 420, and performs an authorization determination to determine whether access is permitted (step S242).

In step S242, the access judgment unit 240 applies the scripts in the access policy script 4200 in order starting from the script with the smallest ID 4201 value. Then, if the authorization request message 510 satisfies all the conditions of "subject", "resource", and "behavior" in the script 4202, the contents of "judgment" are finally used as the judgment result of the access authorization judgment. Note that if there is no script 4202 in the access policy script 4200 that satisfies all of the above conditions, a predetermined default judgment result is applied. The default judgment result is either "pass" or "block".

Next, the access determination unit 240 updates the access authorization information 4300 stored in the access authorization information DB 430 based on the determination result of step S242 (step S243).

In step S243, if the result of the authorization decision is "pass," as shown in ID 4301 = "2" of the access authorization information 4300 in Figure 8, the communication cutoff period 4305 is not specified (N/A is set) and the communication pass period 4306 is set.

On the other hand, in step S243, if the result of the authorization decision is "blocked", the access authorization information 4300 is updated with different contents according to the setting contents ("complete block" or "temporary block") of the "blocking mode" specified in ID 4301 = "6" of the access authorization information 4300. Specifically, when the blocking mode is "temporary block", the communication blocking period 4305 and the communication passing period 4306 are set as shown in ID 4301 = "1" or "3" of the access authorization information 4300 in FIG. 8. Also, when the blocking mode is "complete block", at least the communication blocking period 4305 is set. At this time, the communication passing period 4306 may be set to a predetermined long period, or may not be specified (N/A is set).

In addition, in step S243, if the result of the authorization decision is "blocked" and the blocking mode is "complete blocking," the access decision unit 240 creates an administrator notification message 530 notifying that an authorization decision to block access has been made (see FIG. 10) and sends this to the management terminal 40. As a result, the administrator can view the administrator notification message 530 via the management terminal 40 and recognize that a decision to block access has been made.

After the processing of step S243 has been performed as described above, the process returns to step S241.

The access control unit 250 receives the access request 520 sent from the authorization request control unit 130 of the terminal 10 in step S127 of FIG. 11 (step S251).

Next, the access control unit 250 compares the access request 520 received in step S251 with each record in the access authorization information 4300 stored in the access authorization information DB 430, determines whether the access request 520 should be passed or blocked, and controls the access request 520 according to the result of the determination (step S252).

To explain in detail the pass/block decision in step S252, the access control unit 250 selects from each record of the access authorization information 4300 a record that matches the combination of the terminal 10 that is the sender of the access request 520 and the resource 30 that is the destination, based on the terminal IP address 4302 and the resource IP address 4303, and further compares the transmission date and time (or the current date and time) of the access request 520 with the communication cutoff period 4305 or the communication pass period 4306 in the selected record, thereby making a pass/block decision for the access request 520. That is, if the transmission date and time (or the current date and time) of the access request 520 is included in the communication pass period 4306 in the selected record, it is decided to pass the access request 520. On the other hand, if the transmission date and time (or the current date and time) of the access request 520 is included in the communication cutoff period 4305 in the selected record, it is decided to block the access request 520.

Then, in step S252, if the access control unit 250 decides to pass the access request 520, it forwards the access request 520 to the destination resource 30. On the other hand, if it decides to block the access request 520, it does not forward the access request 520 to the resource 30. After the processing of step S252 is completed, the process returns to step S251.

As described above, in the dynamic access authorization system 1, when an access request to the resource 30 occurs from the terminal 10, the terminal 10 transmits an authorization request message 510 including behavior information of the user and the terminal 10 to the access control device 20 on a session basis. The access control device 20 compares the authorization request message 510 with the access policy script 4200 to determine whether to allow the access request to pass through to the resource 30 or block it, and controls the access request 520 based on the determination result. In addition, the authorization request message 510 transmitted to the access control device 20 can be compressed and prioritized in the terminal 10 to have an appropriate security level and data size. As a result, the dynamic access authorization system 1 according to this embodiment can realize dynamic authorization of the access request 520 to the resource 30 in real time based on the most recent behavior of the terminal 10 and/or the user while suppressing the load on the communication networks 41, 42 and the terminal 10.

(5) Modifications The present invention is not limited to the above-described embodiment, but includes various modifications.

(5-1) Modification 1
1, the access control device 20 is shown as an independent device separate from the resource 30, but as a modified example of the dynamic access authorization system 1, the access control device 20 may be realized in a form that is included in the resource 30. In this case, the control device-side program 200 shown in FIG. 1 takes the form of software and is provided in the resource 30, receives an authorization request message 510 and an access request 520 transmitted from the terminal 10 to the resource 30, and performs processing as the control device-side program 20 described above.

(5-2) Modification 2
11, as the processing in the behavior information adjustment unit 120, the behavior information compression unit 121 performs a compression process of the behavior information in step S113, and then the behavior information prioritization unit 122 performs a prioritization process of calculating a combination of behavior information to be included in the authorization request message 510 in step S114. However, as a modified example of the dynamic access authorization system 1, the behavior information adjustment unit 120 may execute only one of the compression process in step S113 and the prioritization process in step S114. In addition, when both the compression process and the prioritization process are executed, the order of execution of the processes may be interchanged. In other words, the prioritization process by the behavior information prioritization unit 122 (step S114) may be executed before the compression process by the behavior information compression unit 121 (step S113).

When the prioritization process is performed after the compression process as shown in FIG. 11, the behavior information whose "behavior information compression unit flag" specified by ID 3101 = "6" in the terminal setting information 3100 is "On" is compressed before the prioritization process, so that the effect of making the data size of the behavior information list finally included in the authorization request message 510 as small as possible can be expected regardless of the data size of the total value of the behavior information. On the other hand, when the prioritization process is performed before the compression process as in the above modified example, for example, the total value of the data size of the behavior information is calculated at the end of the prioritization process, and if this total value falls within the maximum allowable data size (see the record with ID = "1" in the terminal setting information 3100) (if it is sufficiently small), the compression process may be skipped. Also, if the maximum allowable data size is exceeded at the end of the prioritization process, the compression process is performed, and the behavior information within the range of the maximum allowable data size after the compression process is selected (taking into account the result of the prioritization process), so that the behavior information list to be included in the behavior information authorization request message 510 can be determined. As described above, when compression processing is skipped, not only can the increase in processing load due to compression processing be suppressed, but decompression processing is also unnecessary, which is expected to further suppress the processing load.

(5-3) Modification 3
7 illustrates an access policy script 4200 to be compared in the authorization decision for the authorization request message 510 at the time of an access request, and the script 4202 describes dynamic information related to behavior such as "number of unnecessary processes running" and "user idle time" as a judgment criterion, but as a modified example of the dynamic access authorization system 1, the elements to be compared in the authorization decision are not limited to the information related to the behavior described above, and may include other types of information. Specifically, for example, elements such as date and time, day of the week, or holiday/weekday may also be described in the script 4202.

In the above embodiment, the behavior information by the behavior monitoring unit 110 specified by the behavior monitoring unit name 3202 of the behavior monitoring unit management information 3200 in FIG. 4 is information that may be written in the authorization request message 510 (in other words, information to be compared in the authorization decision). However, as a modified example of the dynamic access authorization system 1, relatively static information such as patch programs and OS/application version information installed in the terminal 10 may be written in the authorization request message 510 (or may be written in combination with the dynamic behavior information described above), and access control may be performed by referring to these. In this case, for example, by describing a logical expression using the static information as an element in the access policy script 4200, the access decision unit 240 can execute an authorization decision that also takes the static information into consideration. Thus, the dynamic access authorization system 1 can realize authorization decision and access control for an access request by combining not only dynamic information but also static information used in existing technologies.

The above-mentioned embodiment has been described in detail to clearly explain the present invention, and is not necessarily limited to having all of the configurations described. In addition, it is possible to add, delete, or replace part of the configuration of the embodiment with other configurations.

Furthermore, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in hardware, in part or in whole, for example by designing them as integrated circuits. Furthermore, the above-mentioned configurations and functions, etc. may be realized in software, by a processor interpreting and executing a program that realizes each function. Information such as the programs, tables, and files that realize each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

In addition, the control lines and information lines shown in the drawings are those that are considered necessary for explanation, and do not necessarily show all control lines and information lines on the product. In reality, it can be assumed that almost all components are interconnected.

REFERENCE SIGNS LIST 1 Dynamic access authorization system 10 Terminal 11 OS/application 20 Access control device 30 Resource 40 Management terminal 41, 42 Communication network 50 Information processing device 51 CPU
52 Memory 53 External storage device 54 Interface (IF)
55 Input/Output device 56 Bus 100 Terminal side program 110 Behavior monitoring unit 120 Behavior information adjustment unit 121 Behavior information compression unit 122 Behavior information prioritization unit 130 Authorization request control unit 140 Authorization request message transmission unit 200 Control device side program 210 Policy management unit 220 Authorization request message reception unit 230 Behavior information decompression unit 240 Access determination unit 250 Access control unit 310 Terminal setting DB
320 Behavior monitoring unit management DB
330 Authorization request message history DB
410 Access control setting DB
420 Access policy script DB
430 Access authorization information DB
510 Authorization request message 520 Access request 530, 530A, 530B Administrator notification message 3100 Terminal setting information 3200 Behavior monitoring unit management information 3300 Authorization request message history information 4100 Access control setting information 4200 Access policy script 4300 Access authorization information 5100 Data format

Claims (13)

1. A dynamic access authorization system for determining authorization of an access request from a terminal used by a user to a resource owned by a resource device, based on dynamic information related to the terminal and/or a user of the terminal, comprising:
A terminal-side program and terminal-side data referenced by the terminal-side program, both of which are stored in the terminal;
A control device side program and control device side data referenced by the control device side program, which are held in an access control device disposed in a network between the terminal and the resource device;
Equipped with
The terminal side program is
A plurality of behavior monitoring units that monitor a plurality of types of behavior related to the user and/or the terminal and periodically output the latest behavior information;
a behavior information prioritization unit that performs a prioritization process to calculate a combination of the behavior information output from the behavior information output from the behavior monitoring units that maximizes a total value of a value assigned to each of the behavior information within a predetermined limit range of total data size, and a behavior information adjustment unit that creates a behavior information list combining the behavior information that maximizes the total value ;
an authorization request control unit that captures generation of the access request, creates an authorization request message including the list of behavior information adjusted by the behavior information adjustment unit, and transmits the authorization request message and the access request to the access control device;
having
The control device side program
a policy management unit that manages an access policy script in which a logical expression using the behavior information output by the behavior monitoring unit as an element is written;
an authorization request message receiving unit that receives the authorization request message transmitted from the terminal;
an access decision unit that makes the authorization decision by applying the authorization request message to a logical expression defined in the access policy script;
an access control unit that is capable of executing a temporary blocking access control for blocking the access request for a first predetermined time and then permitting passage of the access request for a second predetermined time when the access request is not authorized in the authorization determination by the access determination unit;
A dynamic access authorization system comprising: The behavior information adjustment unit is
A behavior information compression unit that performs a compression process to compress the data size of the behavior information using a lossy compression method,
The control device side program
2. The dynamic access authorization system according to claim 1, further comprising a behavior information decompression unit that executes a decompression process for determining whether or not a keyword specified in the access policy script is recorded in the behavior information compressed by the behavior information compression unit, for one or more of the behavior information constituting the behavior information list included in the authorization request message received by the authorization request message receiving unit. The behavior information decompression unit
3. The dynamic access authorization system according to claim 2, wherein in the decompression process, as a result of judging whether or not a keyword specified in the access policy script is recorded in the behavior information compressed by the behavior information compression unit, if it is judged that the keyword is recorded, the keyword is added to the behavior information. The behavior information adjustment unit is
The dynamic access authorization system according to claim 3, characterized in that the behavior information list is created by performing the compression process by the behavior information compression unit on the plurality of behavior information output from the plurality of behavior monitoring units, and then performing the prioritization process by the behavior information prioritization unit on the plurality of behavior information output from the plurality of behavior monitoring units. The behavior information adjustment unit is
The dynamic access authorization system according to claim 3, characterized in that the behavior information prioritization unit performs the prioritization process on the plurality of pieces of behavior information output from the plurality of behavior monitoring units, and if a total data size of all of the plurality of pieces of behavior information after the prioritization process exceeds the predetermined limit range, the behavior information compression unit performs the compression process to create the behavior information list. The authorization request control unit,
2. The dynamic access authorization system according to claim 1, further comprising: estimating a time required for the control device side program to process the authorization request message; and delaying transmission of the access request to the access control device until the estimated time has elapsed. a plurality of the access control devices are provided corresponding to a plurality of the resource devices;
The authorization request control unit,
The dynamic access authorization system according to claim 1 , wherein the determination as to whether or not to transmit a new authorization request message is made based on the number of authorization request messages transmitted to the same access control device within a certain period of time. 2. The dynamic access authorization system according to claim 1, wherein when a determination result of complete block that completely blocks the access request thereafter is obtained in the authorization determination, the access determination unit creates an administrator notification message notifying that the access request will be blocked, and transmits the message to an administration terminal used by an administrator. the authorization request control unit creates the authorization request message including predetermined static information regarding the terminal and/or the user in addition to the behavior information list, and transmits the created authorization request message to the access control device;
2. The dynamic access authorization system according to claim 1, wherein the policy management unit manages an access policy script in which a logical expression using the behavior information and the predetermined static information as elements is written. The dynamic access authorization system according to claim 1 , wherein the behavior information prioritization unit calculates the combination of the behavior information by using a genetic algorithm. The dynamic access authorization system according to claim 2 , wherein the lossy compression method is a BloomFilter algorithm. The dynamic access authorization system according to claim 1 , wherein the access control device is configured to be included in the resource device. A dynamic access authorization method for a dynamic access authorization system that performs authorization decision for an access request from a terminal used by a user to a resource owned by a resource device, based on dynamic information related to the terminal and/or a user of the terminal, comprising:
The dynamic access authorization system includes:
A terminal-side program and terminal-side data referenced by the terminal-side program, both of which are stored in the terminal;
A control device side program and control device side data referenced by the control device side program, which are held in an access control device disposed in a network between the terminal and the resource device;
having
a behavior monitoring step of monitoring a plurality of types of behavior related to the user and/or the terminal by executing the terminal-side program by the terminal , and periodically outputting the latest behavior information;
a behavior information adjustment step in which the terminal executes the terminal-side program to calculate a combination of the behavior information outputted in the behavior monitoring step that maximizes the total value of the value assigned to each of the behavior information while keeping the total data size within a predetermined limit range, and to create a behavior information list combining the behavior information that maximizes the total value ;
an authorization request control step of the terminal executing the terminal-side program to capture generation of the access request, create an authorization request message including the list of behavior information adjusted in the behavior information adjustment step, and transmit the authorization request message and the access request to the access control device;
a policy management step of managing an access policy script in which a logical expression using the behavior information outputted in the behavior monitoring step as an element is described by the dynamic access authorization system executing the control device side program;
an authorization request message receiving step of receiving the authorization request message transmitted from the terminal in the authorization request control step by the dynamic access authorization system executing the control device side program;
an access determination step of performing the authorization determination by applying the authorization request message received in the authorization request message receiving step to a logical expression defined in the access policy script by the dynamic access authorization system executing the control device-side program;
an access control step in which, when the access request is not authorized in the authorization decision made by the access decision step, the dynamic access authorization system executes the control device-side program , thereby enabling execution of a temporary blocking access control in which the access request is blocked for a first predetermined time and then permitted to pass for a second predetermined time;
A dynamic access authorization method comprising:

Images