Authorization device, authorization method, and authorization program

Abstract

This authorization device 1 includes: a request discrimination unit 11 that selects an authorization method according to an attribute of a request or external information; and functional units that execute the authorization method, the functional units including an authorization unit 12 that determines whether to authorize the request, a processing unit 15 that executes the request simultaneously with the authorization determination for the request, an authorization result collation unit 16 that determines afterward whether to authorize the execution result of the request using the authorization result of the request, and a post-processing unit 17 that rolls back an execution content of the request when the execution result of the request is not authorized afterward.

Description

Authorization Device, Authorization Method, and Authorization Program

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

[0002] In a big data storage and processing system, in response to a user request, data operations (such as Read, Write, Delete, etc.) are performed. However, in order to prevent unauthorized data operations, before accepting a user request, it is necessary to confirm (authenticate) whether the data operation was executed by the user himself / herself and confirm (authorize) whether the user has the right to execute the data operation.

[0003] In particular, since authorization depends on the data and processing content requested by the user, it is necessary to perform authorization for each request. That is, authorization is performed for a request from a user, and only the requests that have been successfully authorized are transferred to the processing functions that are originally intended to be used.

[0004] However, in the above processing, as long as the authorization is not completed, the subsequent processing is not executed. Therefore, due to the influence of authorization, the processing time of the request increases. In addition, when the authorization rules increase due to the increase in users and data, the collation time with the authorization information database increases, and even if the execution time of the processing function does not change, the overall system performance deteriorates.

[0005] Therefore, as a method for reducing the processing time of requests, speculative execution is widely used (see Non-Patent Document 1). For example, in a conditional branch, both branches are executed before the condition is determined, and after the condition is determined, the result of one of them is used as it is.

[0006] Edmund B. Nightingale, et al., “Speculative Execution in a Distributed File System”, ACM SIGOPS operating systems review 39.5 (2005), p.191 - p.205

[0007] However, in authorization processing, there are characteristics different from conventional speculative execution.

[0008] Traditional speculative execution assumes that the execution is reliable and has no side effects, whereas authorized processing does not trust requests before they are authorized. For example, a user might request to operate on the / userB / folder when they are only authorized to operate on the / userA / folder.

[0009] Furthermore, because data cannot be easily restored once a request to modify it is made to the storage system, authorization processes cannot be executed unconditionally as in the past. For example, if the data operation is a Write or Delete, the target data will be deleted after a single execution.

[0010] In conventional speculative execution, the conditions for speculative execution are predetermined and do not depend on the subsequent execution content. However, in authorization processing, the authorization result may change depending on the content of the request and the execution result. For example, if the authorization rule is "do not allow data containing a specific string in the result," it is not possible to determine whether the authorization condition is met until the request is executed.

[0011] This disclosure is made in view of the circumstances described above, and its purpose is to provide a technology that enables requests to be executed without waiting for the results of authorization and that can accommodate sophisticated authorization rules while maintaining the overall performance of the system.

[0012] An authorization device according to one aspect of the present disclosure includes a request determination unit that selects an authorization method according to the attributes of a request or external information, and a function unit that executes the authorization method, comprising: an authorization unit that determines whether to authorize the request; a processing unit that executes the request simultaneously with the authorization determination of the request; an authorization result verification unit that subsequently determines whether to authorize the execution result of the request using the authorization result of the request; and a post-processing unit that rolls back the execution content of the request if the execution result of the request is not subsequently authorized.

[0013] An authorization method in one aspect of this disclosure is an authorization method performed by an authorization device, in which an authorization method is selected according to the attributes or external information of the request, a determination is made as to whether to authorize the request in the selected authorization method, the request is executed simultaneously with the authorization determination of the request, a subsequent determination is made as to whether to authorize the execution result of the request using the authorization result of the request, and if the execution result of the request is not subsequently authorized, the execution content of the request is rolled back.

[0014] An authorization program in one aspect of the present disclosure causes a computer to perform the following processes: selecting an authorization method according to the attributes or external information of a request; determining whether to authorize the request; executing the request simultaneously with the authorization determination; retrospectively determining whether to authorize the execution result of the request using the authorization result of the request; and, if the execution result of the request is not subsequently authorized, rolling back the execution content of the request.

[0015] According to this disclosure, it is possible to execute requests without waiting for the results of authorization, and a technology can be provided that can accommodate advanced authorization rules while maintaining the overall performance of the system.

[0016] Figure 1 is a diagram showing an example configuration of the authorization device according to this embodiment. Figure 2 is a diagram showing an example operation of the authorization device according to this embodiment. Figure 3 is a diagram showing an example configuration of the authorization device according to Example 1. Figure 4 is a diagram showing an example operation of the authorization device according to Example 1. Figure 5 is a diagram showing an example operation of the authorization device according to Example 2. Figure 6 is a diagram showing an example configuration of the authorization device according to Example 2. Figure 7 is a diagram showing an example configuration of the authorization device according to Example 3. Figure 8 is a diagram showing an example configuration of the authorization device according to Example 4. Figure 9A is a diagram showing an example operation of the authorization device according to Example 4. Figure 9B is a diagram showing an example operation of the authorization device according to Example 4. Figure 10 is a reference diagram used when explaining Example 5. Figure 11 is a diagram showing an example configuration of the authorization device according to Example 5. Figure 12 is a diagram showing an example operation of the authorization device according to Example 5. Figure 13 is a diagram showing an example hardware configuration of the authorization device.

[0017] Embodiments of this disclosure will be described below with reference to the drawings. In the drawings, the same parts are denoted by the same reference numerals and their descriptions are omitted.

[0018] This disclosure relates to authorization technology in storage systems and data processing systems.

[0019] This disclosure is characterized by controlling authorization after the request has been processed, rather than when the request is entered.

[0020] Figure 1 shows an example of the configuration of the authorization device 1 according to this embodiment.

[0021] The authorization device 1 comprises a request discrimination unit 11, an authorization unit 12, an authorization information database 13, an authorization result database 14, a processing unit 15, an authorization result verification unit 16, and a post-processing unit 17.

[0022] Authorization device 1 performs the following three processes:

[0023] In the first process, the authorization unit 12, authorization information database 13, authorization result database 14, processing unit 15, and authorization result verification unit 16 execute authorization and processing simultaneously. This parallelization of authorization and processing can shorten the processing time for requests.

[0024] The second process involves the request discrimination unit 11 performing a pre-verification of the request and selecting an appropriate authorization method according to the request's attributes and / or external information. This allows for handling untrusted requests before authorization is granted and enables support for complex authorization rules.

[0025] The third process involves the authorization result verification unit 16 and the post-processing unit 17 performing authorization by post-filtering (authorizing retrospectively) on the request execution result, and performing a rollback if an untrusted request is executed before authorization. This allows for handling authorization rules that cannot be authorized in advance.

[0026] To perform the above processing, each functional unit has the following functions.

[0027] The request discrimination unit 11 has a function to select an authorization method according to the attributes of the request and / or external information. For example, the request discrimination unit 11 selects one of the authorization methods of the multiple embodiments 1 to 5 described later.

[0028] As a function common to all authorization methods, each functional unit shall have the following functions:

[0029] The request discrimination unit 11 has the function of forwarding user requests to the authorization unit 12 and the processing unit 15.

[0030] The authorization unit 12 has the function of determining whether to authorize a request (by comparing it with the authorization information) using the authorization information registered in the authorization information database 13, and registering the authorization result of the determined request in the authorization result database 14.

[0031] The processing unit 15 has the function of executing the request at the same time as determining whether the request is authorized. The processing unit 15 is, for example, an existing system (such as storage or a data processing infrastructure) that is subject to authorization.

[0032] The authorization result matching unit 16 has a function to retrospectively determine (match with authorization result) whether to authorize the execution result of a request using the authorization result of the request registered in the authorization result database 14.

[0033] The post-processing unit 17 has a function to output the request execution result to the user if the request execution result is subsequently approved, and to roll back the request execution content if the request execution result is not subsequently approved.

[0034] Figure 2 shows an example of the operation of the authorization device 1 according to this embodiment.

[0035] When a request is received from a user, the request discrimination unit 11 assigns a request identifier to the request according to the attributes of the request (step S101), and forwards the request with the request identifier to the authorization unit 12 and the processing unit 15 (step S102).

[0036] The authorization unit 12 compares the forwarded request with the authorization information in the authorization information database 13 (step S103), and registers the authorization result (success, failure, etc.) in the authorization result database 14, associating it with the request identifier (step S104).

[0037] The processing unit 15 executes the request simultaneously with the authorization by the authorization unit 12 (step S105). The authorization result matching unit 16 uses the request identifier of the executed request to compare it with the authorization result of the request registered in the authorization result database 14 (step S106).

[0038] If the authorization result is not determined in advance, the post-processing unit 17 performs post-filtering on the request execution result (waiting until the authorization result is registered) and confirms the authorization result (step S107). If the authorization result is a failure, it performs a rollback and deletes the request execution content of the corresponding processing unit 15 (step S108). If the authorization is successful, it outputs the request execution result to the user.

[0039] (Example 1) Typical storage systems support not only reading data, but also writing and deleting it. Authorization generally utilizes either role-based access control (RBAC) or attribute-based access control (ABAC).

[0040] Here, as an example, we assume that user information, operation content, and target of operation are considered authorization information. User information consists of the username and user attributes. The target of operation is the file name. The operation content is one of the following: reading, writing, or deleting data.

[0041] Figure 3 shows an example of the configuration of the authorized device 1 according to Example 1.

[0042] The authorization information database 13 and the authorization result database 14 are attribute-based access control databases. The authorization information database 13 contains pre-registered authorization information for user X.

[0043] When user X requests a write operation to / A / 1.txt, the request is assigned the number 1. However, since user X is only permitted to read / A / 1.txt, the authorization result indicates that it is not permitted.

[0044] Also, in the case of a read operation, the request is transferred to the authorization unit 12 and the processing unit 15 to perform authorization and processing simultaneously. In the case of a write operation, the request is sent only to the authorization unit 12, and after the request is authorized as before, the request is processed.

[0045] FIG. 4 is a diagram showing an operation example of the authorization device 1 according to the first embodiment.

[0046] When receiving a request from a user, the request discrimination unit 11 assigns a unique number (for example, a monotonically increasing numerical value) to the request (step S201).

[0047] The request discrimination unit 11 determines whether the request is an operation to change data (step S202).

[0048] If the request is an operation to change data such as writing or deleting, the request discrimination unit 11 does not transfer the request to the processing unit 15 but only to the authorization unit 12. Thereafter, it operates in series to execute the request only when the authorization is successful (steps S203 to S204).

[0049] That is, first, the authorization unit 12 collates the request with the authorization information in the authorization information database 13 (step S203). Thereafter, when the authorization is successful, the processing unit 15 executes the request (step S204), and when the authorization fails, without executing the request, it outputs the authorization failure of the request to the user.

[0050] If the request is an operation that does not change data such as reading, the request discrimination unit 11 transfers the request to the authorization unit 12 and the processing unit 15 (step S205), and performs parallel execution of authorization and processing (steps S206 to S211).

[0051] In other words, after the authorization is completed (step S206), the authorization unit 12 registers the request number and authorization result in the authorization result database 14 (step S207).

[0052] The processing unit 15 executes the request simultaneously with the authorization by the authorization unit 12 (step S208). The authorization result matching unit 16 uses a select syntax such as "select authorization result where request number=..." and matches the request number with the authentication result of the request registered in the authorization result database 14 (step S209). If no matching data is found during the matching process, the matching is retried until an authentication result is registered (step S210).

[0053] The authorization result verification unit 16 outputs the execution result of the request to the user if authorization is successful, and outputs the authorization failure of the request to the user if authorization fails (step S211).

[0054] When using an SQL database as the authorization information database 13 and the authorization result database 14, it is possible to register and verify results using SQL search statements, but it is also acceptable to use a Key-Value Store or external files.

[0055] Furthermore, if the writing operations are not performed in parallel, there is no need to roll back, so the post-processing unit 17 may be omitted, as shown in Figure 3.

[0056] (Example 2) Example 2 describes data modification using commitment control.

[0057] Example 1 is compatible with all systems, but operations that modify data, such as writing and deleting, will be processed in the same way as before (sequential operations that are processed after authorization). However, in systems where data changes can be rolled back, data modification operations can be executed asynchronously, and an example of this operation is shown in Figure 5.

[0058] Unlike Example 1, after the request processing is completed and it is determined whether the authorization result is successful (steps S305 to S308), it is determined whether the request is an operation to modify data (step S309). Then, only if the authorization result is a failure and the operation modifies data, the executed operation is rolled back (step S310). In this case, to facilitate rollback, only a part of the processing of the request is executed, and additional processing may be executed depending on the authorization result.

[0059] For example, in a distributed system employing two-phase commit, the process is divided into two phases: (1) data modification and (2) confirmation of the data modification. As long as (2) is not performed, (1) can be easily rolled back by operations such as deletion. Therefore, when applying this embodiment, when a request is executed, (1) is performed, (2) is performed if the authorization result is successful, and a rollback of (1) is performed if authorization fails.

[0060] For example, a simple example is a file system-based 2-Phase Commit as shown in Figure 6. Instead of directly writing the processing result of the request to / A / 1.txt in the file system 18, the processing unit 15 writes the processing result of the request to a temporary file / A / 1.txt.2 (a provisional execution).

[0061] If authorization is successful, the authorization result verification unit 16 confirms the write by renaming the temporary file to the original file (confirming the provisional execution). If authorization fails, the authorization result verification unit 16 notifies the post-processing unit 17 of this fact, and the post-processing unit 17 rolls back by deleting the temporary file.

[0062] (Example 3) In Examples 1 and 2, discrimination is performed solely based on the attributes of the request. However, in this example, we will show an example of advanced processing by the request discrimination unit 11 in cases where systems with different characteristics exist simultaneously (for example, a system that can be rolled back and a system that cannot be rolled back exist simultaneously), or where there are multiple types of user operations in the request (for example, there are write and read operations).

[0063] Figure 7 shows an example of the configuration of the approved device 1 according to Example 3.

[0064] Processing unit / A / 15A is rollback-enabled, while processing unit / B / 15B is not. If a user requests operations on both / A / and / B / simultaneously, the request determination unit 11 uses the rollback capability information of each processing unit 15 and the request content to extract the processes that can be executed before authorization as subrequests and send them to the corresponding processing unit 15.

[0065] In other words, the request discrimination unit 11 generates speculatively executable or non-executable tasks depending on the content of the request and the target of the operation. Write operation tasks are transferred to the rollback-enabled processing unit / A / 15A, and read operation tasks are transferred to the non-rollback-enabled processing unit / B / 15B.

[0066] Tasks that are speculative and impossible to execute are also forwarded to the authorization unit 12, regardless of the operation content. In the case of write operation tasks, authorization may be performed first, as in the conventional process (sequential operation where processing is performed after authorization), and processing may be performed after successful authorization. If authorization is successful, rollback is not necessary, so the task may be forwarded to processing unit / A / 15A or processing unit / B / 15B.

[0067] (Example 4) Authorization and processing may reside on different devices. In particular, in Example 2, when this method is applied to an existing system, it is necessary to modify the write flow to the file system 18, which makes modification and maintenance difficult due to tight coupling and causes performance degradation due to the addition of unexpected processing. Therefore, authorization-related functions can be implemented without modifying the existing system by executing them on an external device.

[0068] In particular, by utilizing network cards (SmartNICs) with processing functions such as FPGAs and general-purpose CPUs, the processing functions of the relevant devices can be leveraged, resulting in higher performance. Figure 8 shows an example configuration of the authorized device 1 according to Example 4.

[0069] The authorization unit 12 operates within the network card 100. The processing unit 15 operates within the host server 200. The network card 100 and the server 200 are connected to each other via their respective communication interfaces.

[0070] In response to a user request, the packet flow control unit 11', which corresponds to the request discrimination unit 11, assigns an identifier to the request.

[0071] If the request is a read operation, the packet flow control unit 11' forwards the request as is to the authorization unit 12 in the network card 100 and the processing unit 15 in the server 200. In this case, the flow is the same as in Embodiment 2, except that the authorization unit 12 is operated in the network card 100.

[0072] If the request is a write operation, the packet flow control unit 11' forwards the request to the authorization unit 12 and the Write processing unit 15' in the network card 100.

[0073] To avoid modifying the processing functions of the existing system, operations equivalent to 2-Phase Commit are performed by the Write processing unit 15' and the write processing unit 15''. The Write processing unit 15' executes the request (temporarily executes it) and saves the executed temporary data to the file system 18 in the network card 100.

[0074] The authorization unit 12 performs authorization processing by referring to the authorization information database 13, and registers the authorization result in the authorization result database 14 only if authorization is successful. What happens if authorization fails will be described later. The authorization result verification unit 16 obtains the authorization result from the authorization result database 14 and passes the obtained authorization result to the write processing unit 15'' in the network card 100.

[0075] If authorization is successful, the write processing unit 15'' reads temporary data from the file system 18 and writes it to the processing unit 15 of the server 200. Note that since only normal write and read operations can be performed on the existing system, there is no need to modify the processing unit 15.

[0076] If authorization fails, in order to reduce delay, the authorization unit 12 outputs an authorization failure response without registering the authorization result in the authorization information database 13 and without waiting for the Write processing unit 15' to process (save temporary data). Of course, the authorization result of the authorization failure may also be registered in the authorization information database 13. Subsequently, if the processing result of the Write processing unit 15' arrives at the packet flow control unit 11', that processing result is not processed and is discarded.

[0077] Examples of operation of this embodiment are shown in Figures 9A and 9B.

[0078] When a request is received from a user, the packet flow control unit 11' assigns a unique number to the request (step S401) and forwards the request to the authorization unit 12 (step S402).

[0079] The authorization unit 12 compares the forwarded request with the authorization information in the authorization information database 13 (step S403), and registers the authorization result (success, failure, etc.) in the authorization result database 14, associating it with the request identifier (step S404). The authorization result comparison unit 16 determines the authorization result and, if authorization is successful, terminates the authentication process; if authorization fails, outputs an authorization failure for the request to the user (step S405).

[0080] After step S402, the packet flow control unit 11' determines whether the request is a read operation or a write operation (step S406). If the request is a read operation, it forwards the request to the processing unit 15 in the server 200 (step S407). The processing unit 15 then executes the request (step S408).

[0081] If the request is a write operation, the packet flow control unit 11' forwards the request to the Write processing unit 15' in the network card 100 (step S409). The Write processing unit 15' then executes the request and saves the executed temporary file to the file system 18 in the network card 100 (step S410).

[0082] After step S408 or S410, the authorization result matching unit 16 uses the request number to match the authentication result of the request registered in the authorization result database 14 (step S411). If no matching data is found during the matching process, the matching is retried until an authentication result is registered (step S412).

[0083] The authorization result verification unit 16 determines the authorization result (step S413). If the request is a read operation and authorization is successful, the authorization result verification unit 16 outputs the processing result of the request to the user. If the request is a write operation and authorization is successful, the write processing unit 15'' reads the temporary file from the file system 18 and writes it to the processing unit 15 of the server 200 (step S414). If authorization fails, the request is discarded (step S415).

[0084] (Example 5) As shown in Figure 10, in authorization rules that depend on the request and processing content, the authorization result may not be determined before the request is executed. For example, the authorization result for user X may change due to the actions of user Y.

[0085] Furthermore, if there is an authorization rule that prohibits writing to data containing "XXX," when a user sends a request to write data to file A, the authorization result cannot be determined at the time of authorization processing because it is unknown whether file A contains "XXX." Authorization can be determined by checking the contents of file A after the request has been executed.

[0086] Figure 11 shows an example configuration of the authorization device 1 according to Example 5. This is an example configuration for an authorization system in which such authorization rules exist.

[0087] The authorization unit 12 uses external information attached to the user request (for example, authorization information in Example 1) to extract all authorization rules related to the request from the authorization information database 13 and convert them into an executable authorization program.

[0088] An authorization program is a binary, script, or command that takes arbitrary data as input and determines whether it matches all of the permission rules of the source data. For example, an authorization rule that "does not contain the string "foo"" will generate a binary that converts it to the regular expression ".*foo.*". It can also be converted into a script that is executed by a data processing framework.

[0089] The processing unit 15 receives a request from the data storage 19 or processing system and executes the request. Then, the processing unit 15 retrieves the authorization result registered in the authorization result database 14, executes the authorization program using the retrieved authorization result as input, and determines whether authorization was successful or unsuccessful based on the output result from the authorization program. After that, the processing unit 15 outputs either the authorization failure or the request execution result to the user.

[0090] An example of operation in this embodiment is shown in Figure 12.

[0091] When a request is received from a user, the request discrimination unit 11 assigns a unique number to the request (step S501) and forwards the request to the authorization unit 12 and the processing unit 15 (step S502).

[0092] The authorization unit 12 compares the forwarded request with the authorization information in the authorization information database 13 (step S503), converts the authorization rule related to the request from the authorization information database 13 into an executable authorization program (step S504), and registers the authorization result (success, failure, etc.) in the authorization result database 14, associating it with the request identifier (step S505).

[0093] The processing unit 15 executes the request (step S506). The authorization result matching unit 16 uses the request number to match it with the authentication result of the request registered in the authorization result database 14 (step S507). If no matching data is found during the matching process, the matching is retried until an authentication result is registered (step S508).

[0094] The processing unit 15 retrieves the authorization result registered in the authorization result database 14, inputs the retrieved authorization result into the authorization program and executes it (step S509), and determines whether authorization is successful or unsuccessful based on the output result from the authorization program (step S510).

[0095] If authorization is successful, the processing unit 15 outputs the result of the request execution to the user; if authorization fails, it discards the request (step S511).

[0096] As described above, according to this embodiment, the authorization device 1 includes a request determination unit 11 that selects an authorization method according to the attributes of the request or external information, and as a functional unit that executes the authorization method, the authorization device 1 includes an authorization unit 12 that determines whether to authorize the request, a processing unit 15 that executes the request simultaneously with the authorization determination of the request, an authorization result verification unit 16 that subsequently determines whether to authorize the execution result of the request using the authorization result of the request, and a post-processing unit 17 that rolls back the execution content of the request if the execution result of the request is not subsequently authorized. As a result, requests can be executed without waiting for the authorization result, untrusted requests before authorization can be handled, complex authorization rules can be handled, and authorization rules that cannot be authorized in advance can be handled.

[0097] This disclosure is not limited to the embodiments described above. This disclosure can be modified in numerous ways within the scope of its essence.

[0098] The authorization device 1 of this embodiment described above can be realized using a general-purpose computer system, for example, as shown in Figure 13, which includes a CPU 901, a memory 902, a storage 903, a communication device 904, an input device 905, and an output device 906. The memory 902 and the storage 903 are storage devices. In this computer system, each function of the authorization device 1 is realized when the CPU 901 executes a predetermined program loaded onto the memory 902.

[0099] The authorization device 1 may be implemented on a single computer. The authorization device 1 may be implemented on multiple computers. The authorization device 1 may be a virtual machine implemented on a computer.

[0100] The program for authorization device 1 can be stored on a computer-readable recording medium such as an HDD, SSD, USB memory, CD, or DVD. A computer-readable recording medium is, for example, a non-transitory recording medium. The program for authorization device 1 can also be distributed via a communication network.

[0101] 1 Authorization device 11 Request discrimination unit 11' Packet flow control unit 12 Authorization unit 13 Authorization information database 14 Authorization result database 15 Processing unit 15' Write processing unit 15'' Writing processing unit 16 Authorization result verification unit 17 Post-processing unit 18 File system 19 Data storage 901 CPU 902 Memory 903 Storage 904 Communication device 905 Input device 906 Output device

Claims

1. An authorization device comprising: a request determination unit that selects an authorization method according to the attributes or external information of a request; an authorization unit that determines whether to authorize the request; a processing unit that executes the request simultaneously with the authorization determination of the request; an authorization result verification unit that subsequently determines whether to authorize the execution result of the request using the authorization result of the request; and a post-processing unit that rolls back the execution content of the request if the execution result of the request is not subsequently authorized.

2. An authorization device according to claim 1, wherein, as one authorization method, the authorization unit and the processing unit authorize the request and then execute the request if the request is an operation that modifies data, and simultaneously verify and execute the request if the request is an operation that does not modify data.

3. An authorization device according to claim 1, wherein, as one authorization method, the processing unit provisionally executes the request before the request is authorized, and the authorization result verification unit or the post-processing unit confirms the provisional execution of the request after the request has been authorized.

4. An authorization device according to claim 1, wherein the processing unit comprises a rollbackable processing unit and a non-rollbackable processing unit, and the request determination unit transfers the request to the rollbackable processing unit if the request is an operation that modifies data, and transfers the request to the non-rollbackable processing unit if the request is an operation that does not modify data.

5. An authorization device according to claim 1, wherein, as one authorization method, the authorization unit is located in a first device, and the processing unit is located in a second device different from the first device, and the first device comprises: a processing unit that provisionally executes the request when the request is an operation to change data, and a processing unit that, when the request is authorized, transmits the data of the provisionally executed request to the processing unit located in the second device.

6. An authorization device according to claim 1, wherein, as one authorization method, the authorization unit converts the authorization rules related to the request into an executable authorization program, and the processing unit inputs the authorization result of the request into the authorization program and executes it, and determines whether to authorize the execution result of the request using the execution result of the authorization program.

7. An authorization method performed by an authorization device, comprising: selecting an authorization method according to the attributes or external information of the request; determining whether to authorize the request; executing the request simultaneously with the authorization determination; retrospectively determining whether to authorize the execution result of the request using the authorization result of the request; and, if the execution result of the request is not subsequently authorized, rolling back the execution content of the request.

8. An authorization program that causes a computer to perform the following: a process of selecting an authorization method according to the attributes or external information of a request; a process of determining whether to authorize the request; a process of executing the request simultaneously with the authorization determination of the request; a process of retrospectively determining whether to authorize the execution result of the request using the authorization result of the request; and a process of rolling back the execution content of the request if the execution result of the request is not subsequently authorized.

Images