JP7590925B2 - Sensitive data management system and sensitive data management method - Google Patents

Description

The present invention relates to a sensitive data management system and a sensitive data management method.

Data Free Flow with Trust (DFFT), proposed in 2019, focuses on data sharing and utilization between organizations such as countries and companies. As a means to achieve this, the adoption of distributed ledger technology, which allows multiple organizations to operate the system with the same authority, is expected.
Distributed ledger technology can be said to be a technology that replaces transactions that have traditionally been conducted via trusted centralized institutions such as financial institutions and governments with direct peer-to-peer (P2P) transactions between users.

Various derivatives of distributed ledger technology have been proposed and continue to evolve. The main features of distributed ledger technology today are: (1) transactions between participants in the distributed ledger are finalized through consensus building and approval by (any or specific) participants, rather than by a centralized authority; (2) multiple transactions are organized into blocks, which are recorded in a chain in a distributed ledger called a blockchain, and successive blocks are subjected to hash calculations, making tampering virtually impossible; and (3) all participants share the same ledger data, making it possible for all participants to confirm transactions.

DDL technology, which has these characteristics, is being considered for application in a wide range of fields, including finance and manufacturing, as a mechanism for managing and sharing reliable data and executing and managing transactions based on contracts.

On the other hand, with distributed ledger technology, data is shared among all participating organizations through a distributed ledger. This makes it difficult to handle sensitive data that requires privacy protection in order to comply with laws such as the EU General Data Protection Regulation (GDPR).

Note that, as a conventional technology for utilizing data, an information processing device that generates data lineage without modifying data processing tools (see Patent Document 1) has been proposed.

This information processing device has an acquisition unit that acquires an identifier of a process being executed on the device itself, an identification unit that identifies a data processing tool corresponding to the process based on the identifier of the process acquired by the acquisition unit, an analysis unit that analyzes the description contents of a script being executed by the data processing tool identified by the identification unit and identifies input data names and output data names based on the analysis results, and a generation unit that generates data lineage related to the script based on the input data names and output data names identified by the analysis unit.

WO2020/188779

Meanwhile, providers of such sensitive data may request that the organization to which they are entrusted take various actions, such as revoking consent for data utilization or deleting the data itself. However, there is no way to guarantee that such actions have been carried out correctly or to audit them. This situation is problematic from the perspective of protecting personal information, which is sensitive data, and the providers of such data.
Therefore, an object of the present invention is to provide a technology that enables sensitive data to be utilized in a verifiable and correct manner in accordance with the intentions of its provider.

The sensitive data management system of the present invention that solves the above-mentioned problems is a distributed ledger system in which sensitive data is utilized by multiple organizations, wherein each node of the organizations stores metadata of sensitive data owned by each organization in its own distributed ledger, stores actual data of sensitive data owned by that organization in private storage, executes a workflow of application and approval for usage rights for the sensitive data using a smart contract, and stores the results of the workflow related to the usage rights in the distributed ledger, and when a processing request is received for sensitive data stored in the private storage, confirms the usage rights for the sensitive data, executes processing in accordance with the usage rights, stores a log regarding the process of the processing in the distributed ledger, and executes a process of responding to the sender of the processing request with only the result of the processing in accordance with the processing request received for the sensitive data.
In addition, the sensitive data management method of the present invention is characterized in that, in a distributed ledger system in which sensitive data is utilized by a plurality of organizations, a node of each of the organizations stores metadata of the sensitive data owned by each organization in its own distributed ledger, stores actual data of the sensitive data for which the organization is the owner in a private storage, executes a workflow of application and approval for usage rights for the sensitive data using a smart contract, and stores the results of the workflow related to the usage rights in the distributed ledger; and, when a processing request is received for sensitive data stored in the private storage, confirms the usage rights for the sensitive data, executes processing in accordance with the usage rights, stores a log regarding the process of the processing in the distributed ledger, and responds to the sender of the processing request with only the result of the processing in accordance with the processing request received for the sensitive data .

According to the present invention, sensitive data that is utilized can be verifiably and correctly managed in accordance with the intent of the data provider.

FIG. 1 is a diagram illustrating an example of the configuration of a distributed ledger network in this embodiment. FIG. 1 is a diagram illustrating the hardware configuration of a distributed ledger node of this embodiment. FIG. 2 is a diagram illustrating a hardware configuration of a task processing device according to the present embodiment. FIG. 2 is a diagram illustrating a hardware configuration of an auditing device according to the present embodiment. FIG. 2 is a diagram illustrating a hardware configuration of a client according to the present embodiment. FIG. 1 is a diagram showing the configuration of a data catalog managed by a distributed ledger in this embodiment. A diagram showing the configuration of a task list managed in the distributed ledger of this embodiment. FIG. 1 is a diagram showing the configuration of relationships between data managed in a distributed ledger of this embodiment. FIG. 2 is a diagram showing a process flow of the present embodiment. FIG. 11 is a diagram showing data provision in the processing of this embodiment. FIG. 13 is a diagram showing an access right request in the processing of this embodiment. FIG. 11 is a diagram showing access right approval in the processing of this embodiment. FIG. 13 is a diagram showing an analysis request in the processing of this embodiment. FIG. 13 is a diagram showing analysis execution in the processing of this embodiment. FIG. 13 is a diagram showing an audit in the process of this embodiment. FIG. 13 is a diagram showing a data consistency audit in the audit process of the present embodiment. FIG. 13 is a diagram illustrating a data deletion audit in the audit process of the present embodiment. FIG. 13 is a diagram illustrating a data consent information audit in the audit process of the present embodiment. FIG. 13 is a diagram illustrating a data access right audit in the audit process of the present embodiment. FIG. 13 is a diagram illustrating an audit UI according to the present embodiment.

<Network Configuration>
An embodiment of the present invention will be described in detail below with reference to the drawings. Fig. 1 is a diagram showing an example of a network configuration of a sensitive data management system 1 in this embodiment. The sensitive data management system 1 in this embodiment is a distributed ledger system that enables verifiable and correct management of sensitive data to be utilized in accordance with the intention of the provider of the data (hereinafter, described as the distributed ledger system 1).

As shown in FIG. 1, the distributed ledger system 1 in this embodiment is composed of one or more systems of processing requesting organizations 3, one or more systems of data holding organizations 4, and one or more systems of auditing organizations 5, all of which are communicatively connected via a distributed ledger network 2. Therefore, these may be collectively referred to as the sensitive data management system 1.

The system of the processing requesting organization 3 includes a distributed ledger node 10 and a client 50. A user of the processing requesting organization 3 operates the client 50 to generate and transmit a processing request for sensitive data.

The system of the data holding organization 4 also includes a distributed ledger node 12, a task processing device 20, a private storage 30, and a client 52.

The task processing device 20 responds to a processing request sent from a distributed ledger node 10 or client 50 of the processing request organization 3 by executing processing on the sensitive data held in the distributed ledger.

In addition, private storage 30 is a storage device that is not synchronized between nodes like a distributed ledger, and is a storage device that is isolated from other organizations.

Furthermore, the client 52 is a terminal operated by a user of the data holding organization 4.

The system of the audit organization 5 also includes a distributed ledger node 15, an audit server 40, and a client 55. The audit server 40 is a server device that works in cooperation with the distributed ledger node 15 to lead audit work related to the accuracy of information managed in the distributed ledger node 12 and private storage 30 of the data holding organization 4, the accuracy of processing history, etc.

Moreover, the client 55 is a terminal operated by a user of the audit organization 5 .
<<Hardware configuration>>
The hardware configuration of each device constituting the distributed ledger management system 1 of this embodiment is shown below. FIG. 2 is a diagram showing the hardware configuration of the distributed ledger node 10.

In this embodiment, the distributed ledger node 10 is composed of a storage unit 210, a calculation unit 240, a memory 250, and a communication unit 260, each of which is connected via a BUS.

The memory unit 210 is composed of an appropriate non-volatile memory element such as a solid state drive (SSD) or a hard disk drive.

The memory 250 is also composed of a volatile memory element such as a RAM (Random Access Memory).

The calculation unit 240 is a CPU (Central Processing Unit) that executes the program 211 stored in the storage unit 210 by reading it into the memory 250, etc., to perform overall control of the device itself, as well as various judgments, calculations, and control processes.

The memory unit 210 also stores a program 211, a distributed ledger 220, and a state database 230.

Of these, the distributed ledger 220 is a set of data that is a collection of transactions called blocks, strung together like a string of beads, and is known as a blockchain.

In addition, the state database 230 is a database that stores the latest table data at the time of execution of transactions managed by the distributed ledger 220.

After the program 211 is loaded into the memory 250, the calculation unit 240 executes calculations to realize the required functions.

These programs 211 include a data management smart contract (smart contract) 212 and a task management smart contract 213.

Of these, the data management smart contract 212 is a smart contract that manages data (various types of data including sensitive data). The task management smart contract 213 is a smart contract that manages tasks. These tasks correspond to the processing content requested by the processing request organization 3.

Next, FIG. 3 shows the hardware configuration of the task processing device 30. This task processing device 30 is composed of a storage unit 310, a calculation unit 330, a memory 340, and a communication unit 350, each of which is connected via a BUS.

The memory unit 310 is composed of an appropriate non-volatile memory element such as a solid state drive (SSD) or a hard disk drive.

In addition, memory 340 is composed of a volatile memory element such as RAM (Random Access Memory).

The calculation unit 330 is a CPU (Central Processing Unit) that executes the program 311 stored in the storage unit 310 by reading it into the memory 340, thereby controlling the device itself and performing various judgments, calculations, and control processes.

The calculation unit 330 also has an encrypted area creation unit 331 called a Trusted Execution Environment (TEE) that encrypts a portion of the area of the memory 340. This encrypted area creation unit 331 can generate an encrypted area 341 in the memory 340.

By loading and executing the program 311 in such an encrypted area 341, the program 311 is protected from attacks and tampering by external attackers. This allows the distributed ledger system 1 to guarantee that the program 311 has operated correctly.

Next, FIG. 4 shows an example of the hardware configuration of the audit server 40. The audit server 40 is composed of a storage unit 410, a calculation unit 430, a memory 431, and a communication unit 432, each of which is connected via a BUS.

The memory unit 410 is composed of an appropriate non-volatile memory element such as a solid state drive (SSD) or a hard disk drive.

In addition, memory 431 is composed of a volatile memory element such as RAM (Random Access Memory).

The calculation unit 430 is a central processing unit (CPU) that executes the program 411 stored in the storage unit 410 by reading it into the memory 431, thereby controlling the device itself and performing various judgments, calculations, and control processes.

The program 411 includes a user interface providing program 412 and an audit execution program 413. The user interface providing program 412 delivers a specified user interface to a client 55 operated by a user of the audit work, and inputs instructions for the audit work and outputs the audit results. The audit execution program 413 is a program for executing various processes according to the audit work.

Figure 5 shows the hardware configuration of client 50. Client 50 is composed of a storage unit 510, a calculation unit 530, a memory 531, and a communication unit 532, each of which is connected via a BUS.

The memory unit 510 is composed of an appropriate non-volatile memory element such as a solid state drive (SSD) or a hard disk drive.

The memory 531 is also composed of a volatile memory element such as a RAM (Random Access Memory).

The calculation unit 530 is a CPU (Central Processing Unit) that executes the program 511 stored in the storage unit 510 by reading it into the memory 531, thereby controlling the device itself and performing various judgments, calculations, and control processes.

The program 511 in the memory unit 510 has a client interface 512 and a user command transmission/reception unit 513. The client interface 512 is an input/output screen distributed from the audit server 40 described above.

In addition, the user command transmission/reception unit 513 transmits instructions received from the user via the above-mentioned client interface 512 to the audit server 40, and also receives the processing results in response to those instructions, i.e., the audit results, from the audit server 40.
<Data structure example>
Next, a description will be given of various types of information used in the sensitive data management system 1 of this embodiment. An example of a data catalog 221 in this embodiment is shown in FIG. 6. This data catalog 221 is a table managed in the distributed ledger 220.

The data catalog 221 uses a data ID 600 that uniquely identifies sensitive data as a key, and stores the data name 601, owner 602, consent information 603, and access right 604 of the sensitive data.
4, and a hash value 605 are managed.

Of these, the owner 602 is the holder of the sensitive data.

In addition, the consent information 603 is a value indicating whether the provider of the sensitive data has consented to the utilization of the sensitive data by the owner 602 described above.

In addition, the access right 604 is a value that specifies the organization that is permitted to access the sensitive data.

The hash value 605 is a hash value obtained by inputting the sensitive data into a hash function.

Figure 7 is a diagram showing an example of the data structure of the task list 222 managed by the distributed ledger 220. This task list 222 uses a task ID 700 that uniquely identifies a task as a key to manage the requester 701 who requested the task, the ID 702 of the original data (sensitive data) used for the task, the task content 703, and the execution result 704 of the task.

Figure 8 is a diagram showing an example of the configuration of data relationships 223 managed by the distributed ledger 220. This data relationship 223 is a table that manages the relationships between each piece of sensitive data, and manages, using a record ID 800 as a key, original data 801 indicating the sensitive data to be processed, result data 802 indicating the processing result of the sensitive data, task ID 803 indicating the task that caused the processing, and correctness guarantee 804.

Among these, the guarantee of authenticity 804 is a value that is set when authenticity is recognized as a result of the audit by the audit server 40. In the example of Fig. 8, a check mark is set.
<Flow example: Main flow>
The actual procedure of the sensitive data management method in this embodiment will be described below with reference to the drawings. The various operations corresponding to the sensitive data management method described below are realized by a program that each device constituting the sensitive data management system 1 reads into its respective memory and executes. This program is composed of codes for performing the various operations described below.

Figure 9A is a diagram showing an example of the flow of the sensitive data management method in this embodiment, and an example of the overall flow. Note that in this embodiment, the processing requesting organization 3, the data holding organization 4, and the auditing organization 5 are connected by a distributed ledger network.

First, the task processing device 20 of the data holding organization 4 provides data (S10). However, the data provided here is metadata of sensitive data, and for example, some or all of the data catalog 221 and data relationships 223 are assumed.

Next, the client 50 of the processing requesting organization 3 executes a request to grant access rights to the sensitive data held in the distributed ledger 220 of the data holding organization 4 described above (S11).

Next, the task processing device 20 of the data holding organization 4 executes the process of approving the grant of the access right (S12) in response to the access right grant request received from the client 50 of the processing request organization 3 described above.

Next, the client 50 of the processing requesting organization 3 executes a processing request (S13) for analysis of the sensitive data for which access rights have been granted as a result of the above processing (S12).

Next, the task processing device 20 of the data holding organization 4 executes the analysis requested by the client 50 of the processing request organization 3 (S14), and ends the processing.

On the other hand, the audit server 40 of the audit organization 5 executes a predetermined audit process (S 15 ) on the processing results etc. in the task processing device 20 of the data holding organization 4 .
<Flow example: Data provision>
9B is a flow diagram showing a detailed example of data provision (S10), which is part of the sensitive data management method in this embodiment. In this case, the execution subjects of the process are the client 52 of the data holding organization 4 and the distributed ledger node 12.

The user 900, who is a person in charge of operations at the data-holding organization 4, operates the client 52 to give the above-mentioned data provision instruction. Upon receiving this instruction, the client 52 reads out the sensitive data held by its own organization in an appropriate storage device, and provides this data to the distributed ledger node 12 (901). The data provided in this case is the actual sensitive data.

Next, the distributed ledger node 12 of the data holding organization 4 receives the sensitive data from the client 52 (902) and writes the sensitive data to the private storage 30 (903).

Next, the distributed ledger node 12 of the data holding organization 4 creates metadata from the sensitive data received from the client 52 (904), writes this to the data catalog 221 of the distributed ledger 220 (905), and terminates the process.

The metadata to be written here is data including a data name 601 , an owner 602 , consent information 603 , access rights 604 , and a hash value 605 .
<Flow example: Access authority processing>
9C is a diagram showing a processing flow corresponding to an access right request, which is part of the sensitive data management method in this embodiment. Here, it is assumed that a client 50 of the processing requesting organization 3 and a distributed ledger node 10 cooperate with each other. Also, it is assumed that a user 910 of the processing requesting organization 3 operates the client 50 to execute a request that triggers the processing flow.

First, the client 50 of the processing requesting organization 3 executes a data list acquisition request (911) and requests the data catalog 221 managed in the distributed ledger 220 from the distributed ledger node 10.

Then, the distributed ledger node 10 of the processing requesting organization 3 executes data list acquisition (912), acquires the data catalog 221 from the distributed ledger 220, and sends it to the client 50 (913). As a result, the data catalog 221 of the sensitive data is passed to the client 50.

Meanwhile, the client 50 receives the data catalog 221 sent from the distributed ledger node 10 (914). The client 50 displays this data catalog 221 and presents it for viewing by the user 910. The user 910 refers to the data catalog 221 and considers the sensitive data he or she wishes to use. Then, the user 910 requests access rights to that sensitive data.

Then, in response to an instruction from the user 910, the client 50 executes an access right request (915) to request access rights to the above-mentioned sensitive data.

On the other hand, the distributed ledger node 10 receives an access right request from the client 50, writes the application information for granting access right to the above-mentioned sensitive data to the distributed ledger 220 (916), and terminates the processing.
<Flow example: Access right approval>
9D is a diagram showing an example of a flow of access right approval, which is part of the sensitive data management method in this embodiment. In this case, the client 52 of the data holding organization 4 and the distributed ledger node 12 cooperate with each other. In addition, a user 920 of the data holding organization 4 operates the client 52 to trigger this flow.

The client 52 of the data-holding organization 4 executes a request to obtain a list of access rights requests (921) and confirms that a request for granting access rights to sensitive data held by the organization has been received. This request for granting access rights was stored in the distributed ledger 220 in step 916 in the flow of Figure 9C described above.

The distributed ledger node 12 obtains the application information for granting access rights written in the distributed ledger 220 (922).

Next, the distributed ledger node 12 sends the access right grant application information obtained in step 922 described above to the client 52 (923).

Meanwhile, the client 52 receives the information on the access right grant application (924) and executes a workflow for approval of the request (925). This workflow can be envisioned, for example, as a case in which the client 52 queries the terminal of the provider of the sensitive data about whether or not to grant the access right and obtains the result of the query.

Next, the distributed ledger node 12 writes (926) the access right approval information in the distributed ledger 220, and also writes the access right approval information for the sensitive data in the access right 604 item of the data catalog 221 of the distributed ledger 220, and terminates the processing.
<Flow example: Analysis request>
9E is a diagram showing an example of an analysis request flow, which is part of the sensitive data management method in this embodiment. In this case, the client 50 of the data holding organization 4 and the distributed ledger node 10 cooperate with each other. In addition, a user 930 operates the client 50 to trigger this flow.

The client 50, which receives the operation of the user 930, executes a task execution request (931) to the distributed ledger node 10 to execute a task, for example, a specified analysis process, on the sensitive data to which the client has acquired access rights.

Meanwhile, the distributed ledger node 10 executes a task execution confirmation (932) to check whether the processing requesting organization 3 has correctly obtained access rights, and whether the consent information for the sensitive data in question has been correctly obtained from the data provider. This confirmation is a process of checking whether the consent information 603 in the data catalog 221 is "Agree" and whether the value of the access rights 604 includes the identification information of the processing requesting organization 3.

Next, the distributed ledger node 10 writes the contents of the task in the task list 222 of the distributed ledger 220 (933), and ends the process. The contents written here are the requester 701, the original data 702, and the task contents 703. Of these, the original data 702 is the ID of the sensitive data that was the subject of analysis.
<Flow example: Task processing>
9F is a diagram showing an example of an analysis execution flow, which is a part of the sensitive data management method in this embodiment. In this case, the task processing device 20 and the distributed ledger node 15 of the data holding organization 4 cooperate with each other.

First, the task processing device 20 polls the task list 222 managed in the distributed ledger 220 of the distributed ledger node 12 (941).

On the other hand, if the distributed ledger node 12 receives the above-mentioned polling and finds a task managed in the distributed ledger 220, it passes it to the task processing device 20 (942).

Next, the task processing device 20 acquires (943) the task from the distributed ledger node 12, and acquires (944) the actual data for the sensitive data that is the subject of the task. The actual data acquired here is the actual data managed in the private storage 30.

Next, the task processing device 20 executes a task execution determination (945) to check whether the actual data obtained in step 944 is correct.

As a method for confirming whether the actual data is correct in this task execution determination (945), for example, one possible method is to input the acquired actual data into a hash function (the same one that is held and used by the distributed ledger node 12) to calculate a hash value, and then compare this with the hash value 605 stored in the data catalog 221 of the distributed ledger 220. If the comparison shows that the two match, it can be confirmed that the correct data has been loaded.

Next, the task processing device 20 executes the task (946) and performs processing such as analysis on the actual data read from the private storage 30.

Next, the task processing device 20 executes a task execution result return (947) and responds with the analysis result to the distributed ledger node 12.

The distributed ledger node 12 also executes task execution result writing (948) and writes whether the analysis was successful or unsuccessful in the result 704 of the task list 222 managed by the distributed ledger 220.

The result data obtained by returning the task execution result (947) is added as new data to the data catalog 221 in the private storage 30 and the distributed ledger 220 by the same process as in providing data (S10). Also, the original data 801, result data 802, and task ID 803 are written as new items to the data relationship 223 managed in the distributed ledger 220.
<Flow example:>
9G is a diagram showing an example of an audit flow, which is part of the sensitive data management method in this embodiment. In this case, the client 54 of the audit organization 5, the audit server 40, and the distributed ledger node 14 cooperate with each other. In addition, a user 950 of the audit organization 5 operates the client 54 to trigger this flow.

First, the client 54 executes an audit UI connection (951) and requests a UI for audit operations from the audit server 40.

Meanwhile, the audit server 40 provides an audit UI (952) to the above-mentioned client 54. The UI provided to the client 54 here can be, for example, the output screen of the audit UI 500 shown in FIG. 14.

Figure 14 is a diagram showing an example of an audit UI 500 in this embodiment. In this audit UI 500, the user operates an audit type selection interface 510 via the client 54 to select an audit type. The audit types include a data integrity audit, a data deletion audit, a consent information audit, and an access rights audit, which will be shown later in Figures 10 to 12.

In addition, in the audit target setting 520, the user can select the sensitive data to be audited or select all sensitive data to be audited.

The user can also set the audit period by operating the audit period setting interface 530 on the client 54. It is possible to set the audit to be performed periodically or only once.

In addition, the audit results displayed in the audit result display area 540 are displayed by the audit server 40.

Next, the client 54 executes an audit operation instruction (953) that sends instructions to the audit server 40 regarding the audit content received via the above-mentioned audit UI 500.

Meanwhile, the audit server 40 and distributed ledger node 14 that received the audit operation instruction communicate with each other to perform the audit (954). The contents of this audit will be described later with reference to Figures 10 to 13.

Next, the audit server 40 responds with the audit results to the client 54, while the client 54 displays the audit results in the audit result display area 540 of the above-mentioned audit UI 500 (FIG. 14) (955), and ends the process.
<Flow example: Integrity audit>
FIG. 10 shows a part of the audit content in the data audit execution (954), and is a diagram showing an example of the flow of a data consistency audit.

First, the audit server 40 obtains (1001) metadata related to the sensitive data to be audited from the data catalog 221.

Next, the audit server 40 refers to the task list 222 and obtains (1002) the tasks that use the sensitive data to be audited.

Next, the audit server 40 checks (1003) whether the result data obtained from the task execution result is correct. As a method of this check, for example, a transaction (contents) held in the distributed ledger 220 regarding the task processing for the sensitive data is compared with the result data 802 of the task indicated by the data relationship 223, and whether they match can be assumed.

Next, if the result of 1003 indicates that the data is correct, the audit server 40 writes a value indicating that the data is correct (check in FIG. 8) to the correctness guarantee 804 of the data relationship 223.

The audit server 40 also checks in the task list 222 and data relationship 223 whether further analysis has been performed using the result data, and if so (1004: YES), returns to 1001 with that data as the audit target. On the other hand, if not (1004: NO), the audit server 40 displays the audit results in the audit result display area 540 of the audit UI 500 (1005), and ends the process.
<Flow example: Reduction audit>
FIG. 11 shows a part of the audit content in the data audit execution (954), and is a diagram showing an example of the flow of a data deletion audit.

First, the audit server 40 obtains (1101) metadata of the sensitive data management system to be audited from the data catalog 221.

Next, the audit server 40 checks (1102) whether the sensitive data to be audited has been correctly deleted. This check can be assumed to, for example, check the existence of a transaction (contents) stored in the distributed ledger 220 regarding the deletion process for the sensitive data, and the absence of the sensitive data in question in the data catalog 221.

Next, the audit server 40 searches the task list 222 for a task that uses the sensitive data to be audited, and if such a task is found (1103: YES), it returns to 1101 as a new audit target.

On the other hand, if there is no such result (1103: NO), the audit server 40 displays the audit result in the audit result display area 540 of the audit UI 500 (1104), and ends the process.
<Flow example: Consent information audit>
FIG. 12 shows a part of the audit content in the data audit execution (954), and is a diagram showing an example of the audit flow of data consent information.

First, the audit server 40 obtains (1201) metadata related to the sensitive data to be audited from the data catalog 221.

Next, the audit server 40 obtains (1202) the history of changes to the consent information for access rights related to the sensitive data from transactions in the distributed ledger 220.

Next, the audit server 40 audits (1203) the change history of the consent information. This audit can be assumed to determine, for example, whether the (contents of) the rewrite history obtained in step 1202 regarding the consent information for the sensitive data in the distributed ledger 220 matches the contents of the consent information 603 for the sensitive data in question in the data catalog 221.

Next, the audit server 40 checks (1204) whether there is any earlier change history, and if there is (1204: YES), the process returns to 1202.

On the other hand, if there is no such result (1204: NO), the audit server 40 displays the audit result in the audit result display area 540 of the audit UI 500 (1205), and ends the process.
<Flow example: Data access right audit>
FIG. 13 shows a part of the audit contents in the data audit execution (954), and is a diagram showing an example of the audit flow of data access rights.

First, the audit server 40 obtains (1301) metadata related to the sensitive data to be audited from the data catalog 221.

Next, the audit server 40 obtains (1302) the history of changes to the access rights items related to the above-mentioned sensitive data from transactions in the distributed ledger 220.

Next, the audit server 40 audits (1303) the application for access rights and the approval information. In this case, the audit can be assumed to determine whether the rewrite history (contents) obtained in step 1302 regarding the granting of access rights to the sensitive data in the distributed ledger 220 matches the contents of the access rights 604 for the sensitive data in the data catalog 221, for example.

Next, the audit server 40 checks (1304) whether there is any earlier rewrite history, and if there is (1304: YES), returns the process to 1302.

On the other hand, if not (1304: NO), the audit server 40 displays the audit results in the audit result display area 540 of the audit UI 500 (1305) and ends the process.

The above describes in detail the best mode for carrying out the present invention, but the present invention is not limited to this, and various modifications are possible without departing from the spirit of the present invention.

According to this embodiment, the provider of sensitive data can confirm that the revocation of consent information for utilization related to the recipient and the deletion of data have been performed correctly, and can know that the data is being stored and utilized correctly and securely. In other words, sensitive data to be utilized can be verifiable and managed correctly in accordance with the provider's intentions.

The description in this specification makes clear at least the following. That is, in the sensitive data management system of this embodiment, the nodes of the organization may execute various processes on the sensitive data using a Trusted Execution Environment.

This will ensure secure and authentic processing. Ultimately, sensitive data that is utilized can be managed more verifiably and correctly in line with the intent of the data provider.

In addition, in the sensitive data management system of this embodiment, when the node of the organization receives, as the processing request, a request to delete or revoke the right to use the sensitive data, which is the intention of the provider of the sensitive data to the organization to which the sensitive data is provided, the node of the organization executes processing corresponding to the processing request on the Trusted Execution Environment and stores a log of the process of the processing in the distributed ledger.

This makes it possible to perform processes such as deleting sensitive data and revoking usage permissions securely and with authenticity. Ultimately, sensitive data that is utilized can be managed more verifiably and correctly in accordance with the intent of its provider.

In addition, in the sensitive data management system of this embodiment, the organizational node may manage the relationships of a series of Nth-order data that are generated sequentially by the processing starting from the sensitive data in a distributed ledger as a log of the process history.

This makes it possible to manage the data relationships that arise sequentially during processing of sensitive data in a way that makes it impossible to tamper with them. Ultimately, sensitive data that is utilized can be managed more verifiably and correctly in line with the intentions of its provider.

In addition, in the sensitive data management system of this embodiment, the node for auditing the utilization of the sensitive data may identify the sensitive data to be audited based on the metadata held in the distributed ledger, identify a transaction for processing the sensitive data held on the distributed ledger, and compare the transaction with the process indicated in the log of the sensitive data, thereby performing audit processing regarding the correctness of the relationship starting from the sensitive data or the correctness of the sensitive data.

This will enable various audits to be performed based on the unalterable relationship information described above. Ultimately, sensitive data that is utilized can be managed more verifiably and correctly in line with the intent of the data provider.

In addition, in the sensitive data management method of this embodiment, the nodes of the organization may execute various processes on the sensitive data using a Trusted Execution Environment.

In addition, in the sensitive data management method of this embodiment, when a node of the organization receives, as the processing request, a request to delete or revoke the use authority of the sensitive data, which is the intention of the provider of the sensitive data to the organization to which the sensitive data is provided, the node may execute processing corresponding to the processing request on the Trusted Execution Environment and store a log of the process of the processing in the distributed ledger.

In addition, in the sensitive data management method of this embodiment, the node of the organization may manage the relationships of a series of Nth-order data that are generated sequentially by the processing starting from the sensitive data in a distributed ledger as a log of the process history.

In addition, in the sensitive data management method of this embodiment, a node for auditing the utilization of the sensitive data may identify the sensitive data to be audited based on the metadata held in the distributed ledger, identify a transaction for processing the sensitive data held in the distributed ledger, and compare the transaction with the history indicated in the log of the sensitive data, thereby performing an audit process regarding the correctness of the relationship starting from the sensitive data or the correctness of the sensitive data.

1 Sensitive data management system 2 Distributed ledger network 3 Processing requesting organization 4 Data holding organization 5 Auditing organization 10 Distributed ledger node (processing requesting organization)
12. Distributed ledger nodes (data holding organizations)
15. Distributed ledger node (auditory organization)
20 Task processing device 30 Private storage 40 Audit server 50 Client (processing request organization)
52 Client (data-holding organization)
55 Client (audit organization)
210 Storage unit 211 Program 212 Data management smart computer 213 Task management smart computer 220 Distributed ledger 221 Data catalog 222 Task list 223 Data relationship 230 State DB
240 Calculation unit 250 Memory 310 Storage unit 311 Program 330 Calculation unit 331 Encryption area creation unit 340 Memory 341 Encryption area 350 Communication unit 410 Storage unit 411 Program 412 User interface providing program 413 Audit execution program 430 Calculation unit 431 Memory 432 Communication unit 510 Storage unit 511 Program 512 Client user interface 513 User command transmission/reception unit 530 Calculation unit 531 Memory 532 Communication unit

Claims (10)

A distributed ledger system that allows multiple organizations to utilize sensitive data,
Each node of the organizations stores metadata of the sensitive data owned by the organization in its own distributed ledger, stores actual data of the sensitive data owned by the organization in its private storage,
a process of executing a workflow for application and approval of usage rights for the sensitive data by a smart contract, and storing the results of the workflow related to the usage rights in the distributed ledger; and, when a processing request is received for sensitive data stored in the private storage, a process of confirming the usage rights for the sensitive data, executing processing in accordance with the usage rights, storing a log regarding the process history in the distributed ledger, and responding to the sender of the processing request with only the results of the processing in accordance with the processing request received for the sensitive data .
A sensitive data management system comprising: The organizational node may include:
The various processes for the sensitive data are executed using a Trusted Execution Environment.
The sensitive data management system according to claim 1 . The organizational node may include:
When the processing request is an intention of a provider of the sensitive data to the organization to which the sensitive data is provided, and a request for deletion of the sensitive data or revocation of the usage authority of the sensitive data is received, a process corresponding to the processing request is executed on the Trusted Execution Environment, and a log regarding the process is stored in the distributed ledger.
The sensitive data management system according to claim 2 . The organizational node may include:
The sensitive data is used as a starting point , and a series of N-th order data is sequentially generated by the processing in response to the processing request received regarding the sensitive data . The relationship between the series of N-th order data is managed in a distributed ledger as a log regarding the history of the processing.
The sensitive data management system according to claim 2 . The node for auditing the utilization of the sensitive data is:
The system identifies sensitive data to be audited based on the metadata held in a distributed ledger, identifies transactions of the processing of the sensitive data held in the distributed ledger, and compares the transactions with the history indicated in the log of the sensitive data, thereby executing an audit process regarding the correctness of the relationship starting from the sensitive data or the correctness of the sensitive data.
The sensitive data management system according to claim 4 . In a distributed ledger system where multiple organizations utilize sensitive data,
a node of each of the organizations,
Each organization will store metadata of sensitive data owned by that organization in its own distributed ledger, and store the actual data of sensitive data owned by that organization in private storage.
a process of executing a workflow for application and approval of usage rights for the sensitive data by a smart contract and storing the result of the workflow related to the usage rights in the distributed ledger; and a process of, when receiving a processing request for sensitive data stored in the private storage, confirming the usage rights for the sensitive data, executing processing in accordance with the usage rights, storing a log regarding the history of the processing in the distributed ledger, and responding to the sender of the processing request with only the result of the processing in accordance with the processing request received for the sensitive data ;
A sensitive data management method comprising the steps of: The organizational node comprises:
Various processes on the sensitive data are executed using a Trusted Execution Environment;
The sensitive data management method according to claim 6 . The organizational node comprises:
When the processing request is an intention of a provider of the sensitive data to the organization to which the sensitive data is provided, and a request to delete the sensitive data or revoke the use authority of the sensitive data is received, the Trusted Execution Environment executes a process corresponding to the processing request, and stores a log of the process in the distributed ledger;
The sensitive data management method according to claim 7 . The organizational node comprises:
Starting from the sensitive data , a series of N-th order data is sequentially generated by the processing in response to the processing request received regarding the sensitive data . The relationship between the series of N-th order data is managed in a distributed ledger as a log regarding the history of the processing.
The sensitive data management method according to claim 7 . The node for auditing the utilization of the sensitive data is:
Identifying sensitive data to be audited based on the metadata held in the distributed ledger, identifying transactions of the processing of the sensitive data held in the distributed ledger, and comparing the transactions with the history indicated in the log of the sensitive data, thereby executing an audit process regarding the correctness of the relationship starting from the sensitive data or the correctness of the sensitive data;
The sensitive data management method according to claim 9 .

Images