Data access control method, data access control device, and data access control program

Abstract

To provide a data access control technology for facilitating the maintenance and management of an access control policy.SOLUTION: A policy determination unit 401 acquires a rule for an access request to data 501 on the basis of a preset access control policy 402, and selects whether to acquire attribute information on an attribute of each record of the data 501 from the outside of a database 500 storing the data 501. If a selection to acquire the attribute information is made as a result of that, the attribute information is acquired, and an evaluation of the rule based on the attribute information is performed, and if a selection not to acquire the attribute information is made, the database 500 is made to execute filtering of the data 501 based on the rule. Then, the record of the data 501 corresponding to the access request is acquired from the database 500 on the basis of a rule evaluation result or a filtering execution result.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a method, an apparatus and a program for controlling data access. [Background technology]

[0002] The following Patent Document 1 is known as a document disclosing the background art of the present invention. Patent Document 1 describes a technology that generates authentication rules according to a specific context based on a policy defined by an external policy service, and evaluates these authentication rules within an application to determine whether or not each user is allowed to access resources such as various databases. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] US Patent Application Publication No. 2020 / 0358823 Summary of the Invention [Problem to be solved by the invention]

[0004] In conventional data access control, when defining an access control policy, depending on the structure of the database to be accessed by users, it is necessary to enumerate and describe for each data set the combinations of users and data to which access is permitted or denied. In such cases, the policy description becomes bloated, and the user-data combinations to be described in the policy are updated daily as the database is updated, which creates the problem of making it difficult to maintain and manage the policy. The technology described in Patent Document 1 does not adequately address these problems.

[0005] Therefore, an object of the present invention is to facilitate the maintenance and management of access control policies in data access control. [Means for solving the problem]

[0006] A data access control method according to the present invention is a data access control method by a computer, the method comprising: From a client operated by a user A rule for an access request to first data is acquired, and the computer selects whether or not to acquire attribute information regarding attributes of each record of the first data from outside a first database in which the first data is stored, and if it is selected to acquire the attribute information, the computer acquires the attribute information. , obtained The attribute information and The aforementioned rules and an access permission decision for deciding whether to permit access to the first data based on the attribute of the user. and generating a first query to request a record of the first data corresponding to the access request from the first database when it is determined in the access permission determination that the access to the first data is permitted; If the user selects not to acquire the attribute information, the computer: generating a second query, without performing the access permission determination, that includes a filtering condition according to an attribute of the user and requests a record of the first data corresponding to the access request from the first database; The computer First query or the above output from the first database in response to a second query. the first data record Take profit and transmits the acquired record of the first data to the client. . The data access control device according to the present invention comprises: From a client operated by a user a policy determination unit that acquires a rule for an access request to first data and selects whether or not to acquire attribute information relating to attributes of each record of the first data from outside a first database in which the first data is stored; an attribute information acquisition unit that acquires the attribute information; Generate a first or second query for a query portion, and retrieving a record of the first data corresponding to the access request from the first database; and transmits the acquired record of the first data to the client. a communication unit, wherein the attribute information acquisition unit acquires the attribute information when the policy determination unit selects to acquire the attribute information, and the policy determination unit If you choose to acquire the attribute information, The attribute information acquired by the attribute information acquisition unit and the rules and the attributes of the users. Based on an access permission determination for determining whether to permit access to the first data; and If it is selected not to acquire the attribute information, the access permission determination is not performed, The query unit If the policy determination unit selects to acquire the attribute information and determines in the access permission determination that access to the first data is permitted, generating the first query to request a record of the first data corresponding to the access request from the first database; When the policy determination unit selects not to acquire the attribute information generates the second query, which includes a filtering condition according to an attribute of the user and requests a record of the first data corresponding to the access request from the first database. , the communication unit output from the first database in response to the first query or the second query the first data record Take profit and transmits the acquired record of the first data to the client. . The data access control program according to the present invention executes the following in a computer based on a preset access control policy: From a client operated by a user A first process for acquiring a rule for an access request to first data; a second process for selecting whether or not to acquire attribute information relating to attributes of each record of the first data from outside a first database in which the first data is stored; and, if it is selected in the second process that the attribute information is acquired, , obtained The attribute information and The aforementioned rules and an access permission decision for deciding whether to permit access to the first data based on the attribute of the user. a third process of performing a fourth process of generating a first query to request a record of the first data corresponding to the access request from the first database when it is determined in the third process that access to the first data is permitted; If it is selected not to acquire the attribute information in the second process, generating a second query that includes a filtering condition according to the attributes of the user and requests a record of the first data corresponding to the access request from the first database; No. 5 Processing and The first query generated in the fourth process or output from the first database in response to the second query generated in the fifth process. the first data record Take profit and transmits the acquired record of the first data to the client. No. 6 The process of and are executed. [Effects of the Invention]

[0007] According to the present invention, it is possible to provide a data access control technology that allows easy maintenance and management of access control policies. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a block diagram showing a configuration of a service providing system including a data access control device according to a first embodiment of the present invention. [Figure 2] FIG. 2 illustrates an example of a hardware configuration of a data access control device. [Figure 3] FIG. 2 is a functional block diagram showing the functional configuration of a query service and an authorization service. [Figure 4] FIG. 10 is a diagram illustrating an example of data stored in a database. [Figure 5] FIG. 2 is a diagram illustrating an example of a metadata table stored in a data catalog in the first embodiment of the present invention. [Figure 6]10 is a diagram showing an example of an attribute information management table created by an attribute information management table creation unit; FIG. [Figure 7] 10 is a flowchart of a process performed by a query service. [Figure 8] 10 is a flowchart of a process performed by an authorization service. [Figure 9] 10 is a flowchart of a process executed when an attribute information management table is created in the authorization service. [Figure 10] FIG. 10 is a block diagram showing a configuration of a service providing system including a data access control device according to a second embodiment of the present invention. [Figure 11] FIG. 10 is a diagram illustrating an example of a metadata table stored in a data catalog in the second embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. For clarity of explanation, the following description and drawings have been omitted or simplified as appropriate. The present invention is not limited to the present embodiment, and any application example that conforms to the concept of the present invention is included in the technical scope of the present invention. Unless otherwise specified, each component may be plural or singular.

[0010] In the following explanation, various types of information may be explained using expressions such as "xxx table" or "xxx table", but the various types of information may also be expressed in data structures other than tables. To indicate that the various types of information do not depend on the data structure, "xxx table" or "xxx table" may be referred to as "xxx information".

[0011] In addition, in the following description, when describing elements of the same type without distinguishing between them, reference signs (or common parts of reference signs) may be used, and when describing elements of the same type with distinction between them, the element ID (or the element reference sign) may be used.

[0012] In the following description, a "service providing system" is a system including one or more computers. Therefore, the "service providing system" may be one computer, multiple computers, or may include devices other than computers in addition to computers. The one or more computers typically include at least one physical computer.

[0013] The one or more computers may include at least one virtual computer.

[0014] In the following description, a "data access control device" or a "client" may be configured from one or more computers.

[0015] In the following explanation, processing may be described using a "program" or its process as the subject, but a program is executed by a processor (e.g., a CPU (Central Processing Unit)) to perform a predetermined process using storage resources (e.g., memory) and / or communication interface devices (e.g., communication ports) as appropriate, so the subject of the processing may also be the processor. A processor operates as a functional unit that realizes a predetermined function by operating in accordance with a program. Devices and systems that include a processor are devices and systems that include these functional units.

[0016] In the following description, a "database" refers to a computer having a physical storage device, and may typically be a computer having a non-volatile storage device (e.g., an auxiliary storage device). The auxiliary storage device may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive). A database may contain a mixture of different types of storage devices.

[0017] [First embodiment] A first embodiment of the present invention will be described below.

[0018] Fig. 1 is a block diagram showing the configuration of a service providing system including a data access control device according to a first embodiment of the present invention. The service providing system 1 shown in Fig. 1 is a system that provides various services to users, and includes a data access control device 100, a client 300, databases 500 and 510, and a data catalog 600. In the service providing system 1, these components are connected to each other via a network such as the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

[0019] The data access control device 100 includes a query service 200 and an authorization service 400. The query service 200 receives a request sent from a client 300 configured by a PC (Personal Computer) or the like when the user operates the client 300, and provides a service according to the content of the request. For example, the query service 200 retrieves part or all of data 501 specified in the request from a database 500 and transmits it to the client 300 as a response to the request. The requests and responses in the query service 200 are typically defined as RESTful APIs.

[0020] The authorization service 400 provides authorization processing for restricting access to data 501 by the query service 200 for each user according to the attributes of the user who sends a request from the client 300. The authorization service 400 can execute authorization processing based on metadata obtained from the data catalog 600 and data 511 stored in the database 510, and provide the results.

[0021] Database 500 stores data 501 and data 502. Data 501 and 502 are information in the form of a table in which a large number of records, each consisting of a plurality of preset data items, are compiled, and different data items are set for each of the data 501 and 502. However, data 502 is not necessarily stored in database 500, and data 502 may not be stored in database 500 due to design or operational reasons of the application used to realize service providing system 1. For this reason, data 502 is indicated by a dashed line in the block diagram of FIG. 1.

[0022] The database 510 stores data 511. Like the data 501 and 502 stored in the database 500, the data 511 is information in the form of a table in which a large number of records, each consisting of a plurality of preset data items, are compiled, and the table is organized based on a schema common to that of the data 502. Typically, the data 511 is the master, and the data 502 is a replica thereof. As mentioned above, the data 502 may not be stored in the database 500. Even in this case, the authorization service 400 can send a request to the database 510 to obtain the data 511 from the database 510 instead of the data 502, and use the data 511 in the authorization process.

[0023] Whether or not to store the data 502 in the database 500 in the service providing system 1 is determined, for example, by a trade-off between the cost required to ensure consistency between the data 502 and the data 511 and the overhead incurred when retrieving the data 511 from the database 510. Which setting state to use may be selected when designing an application for realizing the service providing system 1 or when starting operation, or may be changeable during operation.

[0024] The data catalog 600 collects and stores metadata, which is information about the databases 500 and 510 and the data 501, 502, and 511 stored therein. The authorization service 400 can determine whether to acquire the data 511 from the database 510 by referring to the metadata acquired from the data catalog 600.

[0025] Fig. 2 is a diagram showing an example of the hardware configuration of the data access control device 100. As shown in Fig. 2, the data access control device 100 is configured by a computer including, for example, a processor 101, a memory 102, a storage 103, a network I / F (interface) 104, and a console 105.

[0026] The processor 101 uses the memory 102 as a working area to execute predetermined programs and applications stored in the storage 103, thereby performing calculations to realize the query service 200 and the authorization service 400 shown in Fig. 1. The network I / F 104 is connected to the client 300, databases 500 and 510, and data catalog 600 shown in Fig. 1 via the network 106, and performs information communication with these devices under the control of the processor 101. The console 105 is an input / output device used by an administrator who manages the service providing system 1, and is composed of, for example, a display, a mouse, a keyboard, etc.

[0027] 2 shows an example of a hardware configuration in which the query service 200 and the authorization service 400 are realized by a single data access control device 100, but these services may be realized by separate hardware or by combining multiple pieces of hardware. Any hardware configuration can be used to realize the data access control device 100 that provides the query service 200 and the authorization service 400 to the client 300.

[0028] Fig. 3 is a functional block diagram showing the functional configuration of the query service 200 and the authorization service 400. In Fig. 3, the query service 200 includes the following functional blocks: an API (Application Programming Interface) communication unit 201, an authentication unit 202, a policy enforcement unit 203, a query generation unit 204, a query conversion unit 205, and a DB communication unit 206. The authorization service 400 includes the following functional blocks: a policy determination unit 401, a policy management unit 403, an attribute information acquisition unit 404, and an attribute information management table creation unit 406. These functional blocks are each realized by, for example, arithmetic processing performed by the processor 101 in Fig. 2.

[0029] In the query service 200, the API communication unit 201 receives a request sent from the client 300. The authentication unit 202 authenticates the request received by the API communication unit 201 and identifies the user who made the request, thereby identifying the subject of the request. Based on the result of the authorization process provided by the authorization service 400, the policy enforcement unit 203 permits or denies access to data 501 according to the subject of the request, and determines whether query conversion is necessary.

[0030] When access to the data 501 is permitted by the policy enforcement unit 203, the query generation unit 204 generates a query requesting the database 500 to acquire the data 501. When the policy enforcement unit 203 determines that query conversion is necessary, the query conversion unit 205 converts the query generated by the query generation unit 204. The DB communication unit 206 extracts and acquires records of the data 501 corresponding to the request from the database 500 by transmitting the query generated by the query generation unit 204 and further converted by the query conversion unit 205 as necessary to the database 500. The records acquired by the DB communication unit 206 are transmitted by the API communication unit 201 to the client 300 as a response to the request.

[0031] In the authorization service 400, the policy management unit 403 manages the access control policy 402 used in the authorization process executed in the policy determination unit 401. The access control policy 402 is information indicating rules for specifying, for each of various users (subjects) accessing the data 501 using the client 300, which of multiple records included in the data 501 the subject is permitted to access, and is stored in advance in a predetermined file format such as XACML (eXtensible Access Control Markup Language) in the data access control device 100. The policy management unit 403 obtains the access control policy 402 stored and held in, for example, the storage 103 in FIG. 2 and outputs it to the policy determination unit 401.

[0032] The attribute information acquisition unit 404 acquires attribute information relating to the attributes of each record of the data 501 as needed from the data 511 stored in the database 510. Note that if the data 502 common to the data 511 is stored in the database 500, the attribute information acquisition unit 404 does not need to acquire the attribute information from the data 511.

[0033] The attribute information management table creation unit 406 acquires the metadata table 601 stored in the data catalog 600, and creates the attribute information management table 405 based on this. The metadata table 601 is a table of the above-mentioned metadata, and includes information on functions supported by various databases including the databases 500 and 510, and information on the data stored in each database. The attribute information management table creation unit 406 extracts and acquires information on the data 501, 502, and 511 from the metadata table 601, thereby creating the attribute information management table 405 that indicates the storage locations of this data. Details of the attribute information management table 405 will be described later.

[0034] The policy determination unit 401 performs authorization processing for a request from the client 300 based on the access control policy 402 output from the policy management unit 403, the attribute information acquired by the attribute information acquisition unit 404, and the attribute information management table 405 created by the attribute information management table creation unit 406. In this authorization processing, it is determined whether or not to permit access to the data 501 for the request, and if so, which records in the data 501 to permit access to. The result of the authorization processing by the policy determination unit 401 is sent to the policy enforcement unit 203 of the query service 200.

[0035] FIG. 4 shows examples of data 501, 502, and 511 stored in databases 500 and 510, respectively. Database 500 stores, for example, an order slip table and a customer table, each having the data structure shown in FIG. 4, as data 501 and 502, respectively, and database 510 stores a customer table having the same structure as data 502 as data 511. These data are each composed of a plurality of records, and the fields of each record store values ​​of data items set for the corresponding columns. For example, in the order slip table of data 501, values ​​corresponding to data items such as "invoice number," "order recipient," and "order date" are stored in the multiple fields constituting each record. In the customer tables of data 502 and 511, values ​​corresponding to data items such as "customer number," "customer name," and "person in charge" are stored in the multiple fields constituting each record. Of these data items, "order recipient" and "customer number" have a corresponding relationship, and this correspondence links each record of data 501 with each record of data 502 and 511.

[0036] By using the above-described linking, the attribute information acquisition unit 404 can extract and acquire necessary information from the data 502 as attribute information related to the attributes of each record in the data 501. For example, for a record 521 in the data 501 in which the value of "order recipient" is "CUS001", the attribute information acquisition unit 404 can extract from the data 502 a record 522 in which the value of "customer number" is the same "CUS001", and acquire the values ​​of each field of this record 522 as the attribute information of the record 521.

[0037] 5 is a diagram showing an example of a metadata table 601 stored in a data catalog 600 in the first embodiment of the present invention. As described above, data 502 and data 511 stored in databases 500 and 510, respectively, are organized into tables based on a common schema. However, there are cases where data 502 does not exist in database 500 due to application design or operational reasons. Therefore, the configuration of metadata table 601, which is a table of metadata, differs depending on whether data 502 exists. In the example of FIG. 5, an example of metadata table 601 when data 502 exists is shown as metadata table 601A, and an example of metadata table 601 when data 502 does not exist is shown as metadata table 601B.

[0038] The difference between metadata table 601A and metadata table 601B is the presence or absence of records 611 that indicate the characteristics and affiliation of data 502. That is, when data 502 exists, metadata table 601A is configured to include records 611 that represent the metadata of data 502, but when data 502 does not exist, metadata table 601B does not include records 611 that represent the metadata of data 502.

[0039] Fig. 6 is a diagram showing an example of the attribute information management table 405 created by the attribute information management table creation unit 406. As described in Fig. 5, the configuration of the metadata table 601 differs depending on whether or not the data 502 exists. Therefore, the configuration of the attribute information management table 405 created based on the metadata table 601 also differs depending on whether or not the data 502 exists. In the example of Fig. 6, an example of the attribute information management table 405 when the data 502 exists is shown as attribute information management table 405A, and an example of the attribute information management table 405 when the data 502 does not exist is shown as attribute information management table 405B.

[0040] The attribute information management table 405A and the attribute information management table 405B have different contents of records 411A and 411B corresponding to the data 502 and the data 511, respectively. That is, in the attribute information management table 405A when the data 502 exists, the storage location and acquisition method of the attribute information based on the data 502 are recorded in the record 411A, and in the attribute information management table 405B when the data 502 does not exist, the storage location and acquisition method of the attribute information based on the data 511 are recorded in the record 411B.

[0041] 6, "DB01" and "SQL" stored in the "location" and "function" fields of record 411A indicate that data 502 containing the attribute information is stored in database 500 and that the attribute information can be acquired by an SQL command. Also, in attribute information management table 405B, "SV02" and "REST" stored in the "location" and "function" fields of record 411B indicate that the attribute information can be acquired by a service defined by a RESTful API.

[0042] Furthermore, in the attribute information management tables 405A and 405B, the "access path" of each record stores a descriptor for uniquely identifying the source of attribute information in the databases 500 and 510. Specifically, in each record of the attribute information management table 405A and in each record of the attribute information management table 405B except for record 411B, the concatenation of the table name and column name of the data 501 and 502 is stored in the "access path," and in record 411B of the attribute information management table 405B, the path parameters specified in the RESTful API request are stored in the "access path."

[0043] The attribute information management table 405A is generated, for example, by an administrator of the service providing system 1 referring to the metadata table 601A and selecting the data 502 as the attribute information of the accessing subject. On the other hand, the attribute information management table 405B is generated, for example, by an administrator of the service providing system 1 referring to the metadata table 601B and selecting the data 511 as the attribute information of the accessing subject.

[0044] Next, the processing performed by the data access controlling device 100 will be described in detail below with reference to a flowchart.

[0045] 7 is a flowchart of the processing executed by the query service 200 of the data access controlling apparatus 100. When a request instructing access to the data 501 is transmitted from the client 300, the query service 200 starts the processing shown in the flowchart of FIG. 7 (step S700).

[0046] The API communication unit 201 receives a request from the client 300 (step S702). This request includes information indicating which record to acquire from the multiple records that make up the data 501. For example, a request to acquire a record in the data 501 whose "slip number" value is "ORD001" is written as "GET / orders / ORD001 HTTP / 1.1."

[0047] The authentication unit 202 extracts the credentials or token included in the request received by the API communication unit 201 in step S702 and uses them to authenticate the request (step S704). For example, if the received request is an API based on HTTP, the credentials or token are typically included in the header field of the request. If the request is successfully authenticated in step S704, the query service 200 can identify the user (subject) who sent the request.

[0048] The authentication performed in step S704 can be, for example, Basic authentication or JWT authentication. Specific authentication methods include checking the password included in the credentials in the case of Basic authentication, and verifying the token signature in the case of JWT authentication. As described above, the processing content of step S704 may differ depending on the authentication method, but in either case, authentication is successful if the request subject can be identified. If the request subject can be identified in step S704, it is determined that authentication has been successful (step S706: Yes), and the process proceeds to step S708. On the other hand, if the request subject cannot be identified in step S704, it is determined that authentication has failed (step S706: No), and the process proceeds to step S710.

[0049] If the authentication is successful, the policy enforcement unit 203 sends the information about the subject identified by the authentication unit 202 in step S704 and the information about the operation and resource extracted from the received request as an authorization request to the policy determination unit 401 (step S708). On the other hand, if the authentication is unsuccessful, the API communication unit 201 notifies the client 300 that the authentication has failed (step S710), and ends the processing shown in the flowchart in FIG.

[0050] Upon receiving the authorization request transmitted from the policy enforcement unit 203 in step S708, the policy determination unit 401 performs authorization processing and transmits the result as an authorization response to the policy enforcement unit 203. The policy enforcement unit 203 receives the authorization response transmitted from the policy determination unit 401 (step S712).

[0051] The policy enforcement unit 203 determines whether or not to permit access to the data 501 for the request received by the API communication unit 201 from the client 300 in step S702, based on the contents of the authorization response received from the policy determination unit 401 in step S712 (step S714). If the policy determination unit 401 determines that access to the data 501 is permitted and an authorization response indicating the determination result is received in step S714, the policy enforcement unit 203 determines that access is permitted (step S714: Yes), and proceeds to step S716. On the other hand, if the policy determination unit 401 determines that access to the data 501 is denied and an authorization response indicating the determination result is received in step S714, the policy enforcement unit 203 determines that access is denied (step S714: No), and proceeds to step S718.

[0052] When an authorization response permitting access to data 501 is received from the policy determination unit 401, the query generation unit 204 generates a query for retrieving a desired record from data 501 stored in database 500 in response to the request received by the API communication unit 201 from the client 300 in step S702 (step S716). For example, if the database 500 is a database that uses SQL as the query language and a request to retrieve a record in data 501 whose "slip No." value is "ORD001" is sent from the client 300, the query instructing this to the database 500 is written as "select * from orders where voucher No. = 'ORD001';". As a result, the query service 200 generates a query in response to the request for access to data 501 from the client 300. On the other hand, if the policy determination unit 401 receives an authorization response denying access to the data 501, the API communication unit 201 notifies the client 300 that access to the data 501 has been denied (step S718), and terminates the processing shown in the flowchart of Figure 7.

[0053] When the query generation unit 204 generates a query in step S716, the query conversion unit 205 determines whether query conversion is necessary (step S720). Here, the presence or absence of query conversion is determined based on the authorization response received by the policy enforcement unit 203 from the policy determination unit 401 in step S712. That is, if the received authorization response includes a query conversion instruction, the query conversion unit 205 determines that query conversion is necessary (step S720: Yes) and executes the process of step S722. On the other hand, if the received authorization response does not include a query conversion instruction, the query conversion unit 205 determines that query conversion is not necessary (step S720: No) and proceeds to step S724 without executing the process of step S722.

[0054] If it is determined that query conversion is necessary, the query conversion unit 205 converts the query generated by the query generation unit 204 in step S716 into a query for combining and filtering the data 501 and data 502 stored in the database 500 (step S722). For example, if the value of "Person in Charge" corresponding to the user (subject) identified by the authentication in step S704 is "1001," the query converted from the SQL query shown in the example above is written as "select * from orders inner join customers on (orders.Orderee = customers.CustomerNo) where customers.Person in Charge = '1001' and orders.SlipNo = 'ORD001';." As a result, the query service 200 combines the data 501 to be accessed and the data 502 including attribute information of the data 501 from the query generated in response to the request in step S716, and generates a query for causing the database 500 to perform filtering based on the rules written in the access control policy 402.

[0055] The DB communication unit 206 transmits to the database 500 the query generated by the query generation unit 204 in step S716 (if the processing of step S722 has not been executed), or the converted query generated by the query conversion unit 205 converting the query generated by the query generation unit 204 in step S722 (step S724).

[0056] The DB communication unit 206 acquires the record of the data 501 output by the database 500 in response to the query sent in step S724 (step S726). The API communication unit 201 outputs the record of the data 501 acquired by the DB communication unit 206 in step S726 as a response to the request received in step S702, and sends it to the client 300 (step S728). Once the API communication unit 201 has sent the response to the request to the client 300, the query service 200 ends the processing flow in FIG. 7.

[0057] Fig. 8 is a flowchart of the processing executed by the authorization service 400 of the data access control device 100. When an authorization request is sent from the policy enforcement unit 203 in step S708 of Fig. 7, the authorization service 400 starts the processing shown in the flowchart of Fig. 8 (step S800).

[0058] The policy determination unit 401 receives an authorization request from the policy enforcement unit 203 of the query service 200 (step S802). As described above, this authorization request includes information on the subject, operation, and resource in the request that the query service 200 received from the client 300.

[0059] The policy determination unit 401 extracts information on the subject, operation, and resource from the authorization request received in step S802. It also obtains the access control policy 402 from the policy management unit 403 and extracts the rules defined in the access control policy 402 to obtain the rules for the access request to the data 501 made by the client 300 (step S804).

[0060] The policy determination unit 401 compares the information on the subject, operation, and resource extracted from the authorization request in step S804 with the rules extracted in step S804, and determines whether or not attribute information other than the attribute information included in the resource is required for evaluation of the rule for the operation (step S806). Here, for example, the determination of whether or not other attribute information is required is performed as follows.

[0061] As described above, assume that a request to retrieve a record whose "Invoice No." value in data 501 is "ORD001" is sent from client 300, and an authorization request for this request is received from query service 200. Also, assume that the rule defined in access control policy 402 is that the value of "Orderee" in the record specified in the request matches the value of "Customer No." corresponding to the person in charge number assigned by client 300 to the user who sent the request. In such a case, to evaluate the rule, it is necessary to determine the attribute of the user who sent the request using the value of "Person in Charge," which is attribute information included in data 502 and 511 other than data 501, which is the resource. Therefore, in such a case, it is determined in step S806 that additional attribute information is required. On the other hand, if comparison of records between other data is not required for rule evaluation, it is determined in step S806 that additional attribute information is not required, and the process proceeds to step S820. Note that the above example is merely an example. For various rules, it is possible to determine in step S806 whether additional attribute information other than the attribute information included in the resource is required for evaluation.

[0062] As a result of the determination in step S806, if it is determined that other attribute information is necessary (step S806: Yes), the process proceeds to step S808, and if it is determined that other attribute information is not necessary (step S806: No), the process proceeds to step S820.

[0063] If it is determined in step S806 that other attribute information is necessary, the policy determination unit 401 refers to the attribute information management table 405 created by the attribute information management table creation unit 406, and acquires information on the location of the attribute information and its function from the attribute information management table 405 (step S808). For example, in the above example, by referring to record 411A in attribute information management table 405A or record 411B in attribute information management table 405B, it is possible to acquire information indicating data 502 stored in database 500 or information indicating data 511 stored in database 510 as the location of the attribute information required for rule evaluation. Furthermore, it is possible to acquire information on the function supported by database 500 or information on the function supported by database 510 as the function of the location of this attribute information.

[0064] The policy determination unit 401 determines whether the content indicated in the condition part of the rule extracted in step S804 is a comparison between attributes (step S810). For example, as described above, in the case of a rule that the value of "Orderee" in the record specified in the request matches the value of "Customer No." corresponding to the person in charge number assigned by the client 300 to the user who sent the request, the condition part of this rule describes a comparison between the attribute indicated by the value of "Orderee" in data 501 and the attribute indicated by the value of "Customer No." in data 502 and 511. Therefore, in this case, it is determined that the content indicated in the condition part of the rule is a comparison between attributes (step S810: Yes), and the process proceeds to step S812. On the other hand, if it is determined that the content indicated in the condition part of the rule is not a comparison between attributes (step S810: No), the process proceeds to step S818.

[0065] Based on the information on the location acquired from the attribute information management table 405 in step S808, the policy determination unit 401 determines whether the location of the attribute information to be compared in rule evaluation is the same (step S812). For example, as described above, by referring to record 411A of the attribute information management table 405A, if information is acquired that the location of the attribute information required for rule evaluation is the same database 500 as the storage location of data 501, the policy determination unit 401 determines that the location is the same (step S812: Yes) and proceeds to step S814. On the other hand, if it is determined that the location is not the same (step S812: No), the process proceeds to step S818.

[0066] Based on the information about the function of the location acquired from the attribute information management table 405 in step S808, the policy determination unit 401 determines whether the function of the location of the attribute information to be compared in rule evaluation supports a join query that joins multiple data tables (step S814). For example, as described above, by referring to record 411A of the attribute information management table 405A, if information is acquired that the database 500, which is the location of the attribute information required for rule evaluation, operates using SQL that can use join queries, the policy determination unit 401 determines that join queries are supported (step S814: Yes), and proceeds to step S816. On the other hand, if it is determined that join queries are not supported (step S814: No), the process proceeds to step S818.

[0067] If all of the determination results in steps S810, S812, and S814 are positive, the policy determination unit 401 generates a query conversion instruction for the query service 200 from the rules extracted in step S804 (step S816). Here, the query conversion instruction is generated to convert the query generated by the query generation unit 204 in step S716 of FIG. 7 into the above-mentioned query including a combined query according to the rules. This instructs the query service 200 to combine data 501 and data 502 and cause the database 500 to perform filtering based on the rules. After the query conversion instruction is generated in step S816, the process proceeds to step S822.

[0068] If the determination result at any of steps S810, S812, and S814 is negative, the policy determination unit 401 acquires attribute information necessary for rule evaluation based on the information acquired at step S808 (step S818). Here, for example, the attribute information is acquired by reading data 511 from database 510 based on information acquired by referring to record 411B of attribute information management table 405B.

[0069] If step S818 has been executed or if the determination result of step S806 is negative, the policy determination unit 401 evaluates the rule extracted in step S804 (step S820). Here, if step S818 has been executed, the rule is evaluated using the attribute information obtained in step S818 together with the information on the subject, operation, and resource obtained from the authorization request in step S804. On the other hand, if it is determined in step S806 that other attribute information is not necessary, the rule is evaluated based on the information on the subject, operation, and resource obtained from the authorization request in step S804. In this way, it is determined whether or not to permit access to the data 501 for the authorization request received from the query service 200. If the rule can be evaluated in step S820, the process proceeds to step S822.

[0070] The policy determination unit 401 sends an authorization response to the authorization request received in step S802 to the query service 200 (step S822). This authorization response includes either the query conversion instruction generated in step S816 or the rule evaluation result performed in step S820. After the policy determination unit 401 sends the authorization response, the authorization service 400 ends the processing flow in FIG. 8.

[0071] In the query service 200, the policy enforcement unit 203 receives the authorization response sent from the policy decision unit 401 in step S822 in Fig. 8 in step S712 in Fig. 7. This allows the query service 200 to proceed to the processing in step S714 and thereafter.

[0072] Fig. 9 is a flowchart of processing executed by the attribute information management table creation unit 406 when creating the attribute information management table 405 in the authorization service 400 of the data access control device 100. The attribute information management table creation unit 406 starts the processing shown in the flowchart of Fig. 9 at a predetermined timing before the authorization service 400 executes the processing of Fig. 8 (step S900).

[0073] The attribute information management table creation unit 406 acquires metadata from the data catalog 600 (step S902). Here, the metadata is acquired by reading the metadata table 601A or the metadata table 601B illustrated in FIG.

[0074] The attribute information management table creating unit 406 selects one of the metadata acquired in step S902 (step S904). Here, the metadata is selected by selecting a record in one of the metadata tables 601A and 601B.

[0075] The attribute information management table creation unit 406 identifies the storage location and acquisition method of the attribute information included in the metadata selected in step S904 (step S906). Here, for example, the storage location and acquisition method of the attribute information can be identified by identifying the identification name of the data including the attribute information represented by the metadata, the database in which that data is stored, the function of that database, etc. from the contents of each item included in the selected record. Alternatively, the storage location and acquisition method of the attribute information may be identified from information input by the administrator of the service providing system 1, or these identification methods may be combined. In addition, the storage location and acquisition method of the attribute information can be identified by any other method.

[0076] Based on the storage location and acquisition method of the attribute information acquired in step S906, the attribute information management table creation unit 406 creates an attribute information record, which is a record representing information related to the attribute information, and stores it in the attribute information management table 405A or the attribute information management table 405B (step S908).

[0077] After storing the attribute information record in the attribute information management table 405A, 405B in step S908, the attribute information management table creation unit 406 determines whether or not all metadata has been selected in step S904 (step S910). If all records have been selected in the metadata tables 601A, 601B, it is determined that all metadata has been selected (step S910: Yes), and the processing flow in Fig. 9 ends. On the other hand, if there are unselected records in the metadata tables 601A, 601B, it is determined that not all metadata has been selected (step S910: No), and the process returns to step S904 to continue selecting metadata.

[0078] By executing the above-described processing, the attribute information management table creation unit 406 can create the attribute information management table 405A from the metadata table 601A, or the attribute information management table 405B from the metadata table 601B.

[0079] According to the first embodiment of the present invention described above, the following advantageous effects are achieved.

[0080] (1) The data access controlling apparatus 100 acquires rules for access requests to the data 501 based on the preset access control policy 402 (step S804), and selects whether or not to acquire attribute information on the attributes of each record of the data 501 from outside the database 500 in which the data 501 is stored (steps S810 to S814). If it selects to acquire the attribute information (step S810: No, step S812: No, or step S814: No), it acquires the attribute information (step S818) and evaluates the rules based on the attribute information (step S820). If it selects not to acquire the attribute information (steps S810, S812, S814: Yes), it causes the database 500 to filter the data 501 based on the rules (steps S816, S822, S824). Then, based on the result of the rule evaluation performed in step S820 or the result of filtering performed by the database 500, a record of the data 501 corresponding to the access request is obtained from the database 500 (step S726). This allows the rule evaluation to be performed reliably regardless of whether the information required for evaluating the rules defined in the access control policy 402 is stored in the database 500. Therefore, it is possible to provide a data access control technology that makes it easy to maintain and manage access control policies.

[0081] (2) If the database 500 stores data 502 including attribute information (step S812: Yes), the data access controlling apparatus 100 selects not to acquire attribute information from outside the database 500, and if the database 500 does not store data 502 (step S812: No), the data access controlling apparatus 100 selects to acquire attribute information from outside the database 500. In this way, it is possible to appropriately select whether or not to acquire attribute information from outside the database 500 depending on whether the data 502 is present.

[0082] (3) If the data access controlling apparatus 100 selects not to acquire attribute information from outside the database 500, it causes the database 500 to execute filtering by combining the data 501 and the data 502 (steps S816, S722, S724). This eliminates the need for the data access controlling apparatus 100 to evaluate rules, thereby reducing overhead when accessing the data 501 and enabling high-speed access control.

[0083] (4) However, even if data 502 is stored in database 500, if data 501 and data 502 cannot be joined in database 500 (step S814: No), the system selects to acquire attribute information from outside database 500. By doing so, even if database 500 does not have the function of joining multiple data tables, rule evaluation can be performed reliably.

[0084] (5) The data access control device 100 uses a processor 101, which is, for example, a computer, to provide a query service 200 that generates a query in response to an access request, and an authorization service 400 that performs authorization processing for the access request based on an access control policy 402. In the authorization service 400, the policy determination unit 401 selects whether or not to acquire attribute information from outside the database 500 (steps S810 to S814). If it is selected that attribute information should be acquired, the attribute information is acquired and the rules are evaluated (steps S818 and S820). If it is selected that attribute information should not be acquired, the query service 200 outputs a query to cause the database 500 to perform filtering (steps S816, S722, and S724). In this way, the data access control device 100 can be realized using a computer.

[0085] (6) In the query service 200, the query conversion unit 205 converts the query generated by the query generation unit 204 into a query for causing the database 500 to execute filtering in response to an instruction from the authorization service 400 (step S722). Then, the DB communication unit 206 outputs the query to the database 500 (step S724). This ensures that the database 500 can reliably execute filtering of the data 501 based on the rules.

[0086] (7) The data access controlling device 100 refers to the attribute information management table 405, which indicates the location of attribute information and its function (step S808), and selects whether or not to acquire attribute information from outside the database 500. In this way, the selection of whether or not to acquire attribute information from outside the database 500 can be made reliably and easily.

[0087] (8) The data access controlling apparatus 100 uses the attribute information management table creation unit 406 to acquire metadata relating to the database 500 in which the data 501 is stored and the databases 500, 510 in which the data 502, 511 including attribute information are stored from the metadata tables 601A, 601B (steps S902, S904). Then, the data access controlling apparatus 100 creates attribute information management tables 405A, 405B based on the acquired metadata (steps S906, S908). This makes it possible to reliably and easily create attribute information management tables that indicate the location of attribute information and its function.

[0088] (9) The metadata used to create the attribute information management tables 405A and 405B includes information on the functions supported by the databases 500 and 510, and information on the databases to which the data 501 and 511 belong, as exemplified in the records of the metadata tables 601A and 601B in Fig. 5. This makes it possible to reliably obtain the information necessary to create the attribute information management tables 405A and 405B from the metadata.

[0089] [Second embodiment] Next, a second embodiment of the present invention will be described. Below, differences from the first embodiment will be mainly described, and explanations of commonalities with the first embodiment will be omitted or simplified unless particularly necessary.

[0090] In this embodiment, an example will be described in which a database 500 and a database 510 are each connected to the data access control device 100 via a virtualization layer.

[0091] Fig. 10 is a block diagram showing the configuration of a service providing system including a data access control device according to a second embodiment of the present invention. Similar to the service providing system 1 of Fig. 1 described in the first embodiment, the service providing system 1A shown in Fig. 10 includes a data access control device 100, a client 300, databases 500 and 510, and a data catalog 600. This embodiment differs from the first embodiment in that the databases 500 and 510 are each connected to the data access control device 100 via a virtualization layer 700 and that a metadata table 602 is stored in the data catalog 600. The virtualization layer 700 provides an interface that enables the data access control device 100 to issue queries to the databases 500 and 510 as if the data 501, 502, and 511 stored in the separate databases 500 and 510 were stored in a single database.

[0092] Fig. 11 is a diagram showing an example of a metadata table 602 stored in the data catalog 600 in the second embodiment of the present invention. Compared to the metadata tables 601A and 601B in Fig. 5 described in the first embodiment, the metadata table 602 shown in Fig. 11 has an additional record 612 indicating information about the virtualization layer 700. Furthermore, among the records in the metadata table 602, in the records for the data 501, 502, and 511, information indicating that the connection destination is the virtualization layer 700 has been added to column 613.

[0093] In this embodiment, the attribute information management table creation unit 406 creates the attribute information management table 405 based on the metadata table 602. At this time, the attribute information management table 405 is created so that information on the virtualization layer 700 is included in records indicating the storage location and acquisition method of attribute information based on the data 511.

[0094] 7, the query service 200 converts the query generated by the query generation unit 204 in step S716 into a query for causing the database 500 to execute filtering based on the rules described in the access control policy 402 by combining the data 501 and the data 511 via the virtualization layer 700. As a result, even if the data 501 and the data 511 are stored in different databases 500 and 510, it is possible to combine these data and execute filtering based on the rules.

[0095] As described above, in the service providing system 1A of this embodiment, the database 500 and the database 510 are each connected via the virtualization layer 700 to the data access control device 100, which is a computer that creates the attribute information management table 405. In addition, the metadata table 602 stored in the data catalog 600 further includes information on the virtualization layer 700. The data access control device 100 causes the database 500 to perform filtering by combining the data 501 and the data 511 via the virtualization layer 700. In this way, even if the data 501 and the data 511 are stored in different databases 500 and 510, these data can be combined and filtering based on rules can be performed.

[0096] Each record in the metadata table 602 may further include information indicating the validity of data binding via the virtualization layer 700 and information on the priority of data binding. In this way, it becomes possible to more appropriately determine for each data item whether or not to perform filtering by data binding between different databases via the virtualization layer 700.

[0097] The present invention is not limited to the above-described embodiments and can be implemented using any components without departing from the spirit of the present invention. For example, the functional blocks of the query service 200 and the authorization service 400 shown in FIG. 3 may be implemented by different hardware. Alternatively, any of the functional blocks may be included in the client 300, or in the database 500 or the database 510. Furthermore, some or all of the functional blocks in FIG. 3 may be implemented by hardware such as a field-programmable gate array (FPGA).

[0098] The above-described embodiments and modifications are merely examples, and the present invention is not limited to these details as long as the features of the invention are not impaired. Furthermore, although various embodiments and modifications have been described above, the present invention is not limited to these details. Other aspects that can be considered within the scope of the technical idea of ​​the present invention are also included within the scope of the present invention. [Explanation of symbols]

[0099] 1,1A...service providing system, 100...data access control device, 101...processor, 102...memory, 103...storage, 104...network I / F, 105...console, 106...network, 200...query service, 201...API communication unit, 202...authentication unit, 203...policy enforcement unit, 204...query generation unit, 205...query conversion unit, 206...DB communication unit, 300...client, 400...authorization service, 401...policy judgment unit, 402...access control policy, 403...policy management unit, 404...attribute information acquisition unit, 405...attribute information management table, 406...attribute information management table creation unit, 500...database, 501,502...data, 510...database, 511...data, 600...data catalog, 601,602...metadata table, 700...virtualization layer

Claims

1. A data access control method by a computer, comprising: The computer acquires a rule for an access request to the first data from a client operated by a user based on a preset access control policy; selecting whether or not to acquire attribute information relating to attributes of each record of the first data from outside the first database in which the first data is stored, by the computer; When it is selected to acquire the attribute information, the computer acquires the attribute information, performs an access permission decision to determine whether to permit access to the first data based on the acquired attribute information, the rule, and an attribute of the user, and when it is determined in the access permission decision that access to the first data is permitted, generates a first query to request a record of the first data corresponding to the access request from the first database; If the user selects not to acquire the attribute information, the computer generates a second query, without making the access permission determination, that includes a filtering condition according to the user's attribute and requests a record of the first data corresponding to the access request from the first database; acquiring, by the computer, the first data record output from the first database in response to the first query or the second query, and transmitting the acquired first data record to the client; Data access control methods.

2. If second data including the attribute information is stored in the first database, selecting not to acquire the attribute information; If the second data is not stored in the first database, selecting to acquire the attribute information. The data access control method according to claim 1 .

3. if it is selected not to acquire the attribute information, generating the second query including an instruction to combine the first data and the second data and extract records of the first data according to the filtering condition; The data access control method according to claim 2 .

4. Even if the second data is stored in the first database, if the first data and the second data cannot be combined in the first database, selecting to acquire the attribute information. The data access control method according to claim 3 .

5. providing a query service that generates the first query or the second query in response to the access request, and an authorization service that performs authorization processing for the access request based on the access control policy, by the computer; In the authorization service, selecting whether or not to acquire the attribute information from outside the first database; When it is selected to acquire the attribute information, the attribute information is acquired and the access permission is determined, and the first query is output from the query service; If the user selects not to acquire the attribute information, the second query is output from the query service. The data access control method according to claim 1 .

6. the query service converts the generated first query into the second query in response to an instruction from the authorization service and outputs the second query to the first database; The data access control method according to claim 5 .

7. referring to an attribute information management table indicating the location of the attribute information and its function, and selecting whether or not to acquire the attribute information from outside the first database; The data access control method according to claim 1 .

8. acquiring, by the computer, metadata relating to the first database in which the first data is stored and the second database in which second data including the attribute information is stored, and creating the attribute information management table based on the acquired metadata; The data access control method according to claim 7.

9. The metadata includes information on functions supported by the first database and the second database, and information on databases to which the first data and the second data belong. The data access control method according to claim 8.

10. the first database and the second database are each connected to the computer that creates the attribute information management table via a virtualization layer; The metadata further includes information of the virtualization layer. The data access control method according to claim 9.

11. combining the first data and the second data via the virtualization layer, thereby causing the first database to extract records of the first data according to the filtering condition; The data access control method according to claim 10.

12. the metadata further includes information about validity and priority of data binding through the virtualization layer; The data access control method according to claim 11.

13. a policy determination unit that acquires a rule for an access request to first data from a client operated by a user based on a preset access control policy, and selects whether or not to acquire attribute information relating to attributes of each record of the first data from outside a first database in which the first data is stored; an attribute information acquisition unit that acquires the attribute information; a query unit that generates a first query or a second query to the first database; a communication unit that acquires a record of the first data corresponding to the access request from the first database and transmits the acquired record of the first data to the client; the attribute information acquisition unit acquires the attribute information when the policy determination unit selects to acquire the attribute information; The policy determination unit When it is selected to acquire the attribute information, an access permission determination is performed to determine whether or not to permit access to the first data based on the attribute information and the rule acquired by the attribute information acquisition unit and the attribute of the user; If it is selected not to acquire the attribute information, the access permission determination is not performed, The query unit If the policy determination unit selects to acquire the attribute information and determines in the access permission determination that access to the first data is permitted, generating the first query to request a record of the first data corresponding to the access request from the first database; If the policy determination unit selects not to acquire the attribute information, the second query is generated, which includes a filtering condition according to the attribute of the user and requests a record of the first data corresponding to the access request from the first database; the communication unit acquires a record of the first data output from the first database in response to the first query or the second query, and transmits the acquired record of the first data to the client; Data access control device.

14. On the computer, a first process of acquiring a rule for an access request to the first data from a client operated by a user based on a preset access control policy; a second process of selecting whether or not to acquire attribute information relating to attributes of each record of the first data from outside the first database in which the first data is stored; a third process of acquiring the attribute information when it is selected in the second process, and performing an access permission determination to determine whether or not to permit access to the first data based on the acquired attribute information, the rule, and an attribute of the user; a fourth process of generating a first query to request a record of the first data corresponding to the access request from the first database when it is determined in the third process that access to the first data is permitted; a fifth process of generating a second query, when it is selected in the second process not to acquire the attribute information, which includes a filtering condition according to the attribute of the user and requests a record of the first data corresponding to the access request from the first database; a sixth process of acquiring a record of the first data output from the first database in response to the first query generated in the fourth process or the second query generated in the fifth process, and transmitting the acquired record of the first data to the client; Data access control program.

Images