WO2022254823A1 - Système de gestion de données sensibles et procédé de gestion de données sensibles - Google Patents

Système de gestion de données sensibles et procédé de gestion de données sensibles Download PDF

Info

Publication number
WO2022254823A1
WO2022254823A1 PCT/JP2022/007390 JP2022007390W WO2022254823A1 WO 2022254823 A1 WO2022254823 A1 WO 2022254823A1 JP 2022007390 W JP2022007390 W JP 2022007390W WO 2022254823 A1 WO2022254823 A1 WO 2022254823A1
Authority
WO
WIPO (PCT)
Prior art keywords
sensitive data
distributed ledger
data
processing
organization
Prior art date
Application number
PCT/JP2022/007390
Other languages
English (en)
Japanese (ja)
Inventor
航史 池川
直 西島
洋司 小澤
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2022254823A1 publication Critical patent/WO2022254823A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the present invention relates to a sensitive data management system and a sensitive data management method.
  • DFFT Data Free Flow with Trust
  • Distributed ledger technology with these characteristics is being considered for application in a wide range of fields, such as finance and manufacturing, as a mechanism for managing/sharing reliable data and executing/managing transactions based on contracts.
  • Patent Document 1 As a conventional technology related to data utilization, an information processing device (see Patent Document 1) that generates data lineage without modifying the data processing tool has been proposed.
  • This information processing device includes an acquisition unit that acquires an identifier of a process being executed in the own device, and 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 content of the script in operation of the data processing tool identified by the identification unit, and identifies an input data name and an output data name based on the analysis result; and a generating unit that generates data lineage for the script based on the input data name and the output data name specified by.
  • the sensitive data management system of the present invention that solves the above problems is a distributed ledger system that utilizes sensitive data by a plurality of organizations, and each node of the organizations is owned by each organization in its own distributed ledger Metadata of sensitive data is retained, actual data of sensitive data owned by the organization is retained in private storage, and a smart contract is used to execute a workflow for application and approval of usage rights for the said sensitive data.
  • the process of storing the results of the workflow related to the usage authority in the distributed ledger and when receiving a processing request regarding the sensitive data to be stored in the private storage, confirm the usage authority for the sensitive data, and according to the usage authority and stores a log of the process history in a distributed ledger, and executes a process of responding only the result of the process to the originator of the process request.
  • the sensitive data management method of the present invention is a distributed ledger system in which a plurality of organizations utilizes sensitive data, wherein the nodes of the respective organizations store the metadata of the sensitive data owned by each organization in their own distributed ledger.
  • the actual data of the sensitive data owned by the organization is retained, and the workflow for application and approval of usage rights to the sensitive data is executed by smart contract, and
  • the usage authority for the sensitive data is confirmed, and the process is executed according to the usage authority. Then, a process of storing a log relating to the details of the process in a distributed ledger and responding only to the process request originator with the result of the process is executed.
  • sensitive data to be utilized can be verified and correctly managed according to the intention of the provider.
  • FIG. 2 is a diagram showing the hardware configuration of the task processing device of this embodiment;
  • FIG. It is a figure which shows the hardware constitutions of the inspection apparatus of this embodiment.
  • FIG. 1 is a diagram showing a network configuration example of a sensitive data management system 1 in this embodiment.
  • the sensitive data management system 1 of the present embodiment is a distributed ledger system that makes it possible to verify and correctly manage sensitive data to be utilized according to the intention of the provider (hereinafter referred to as the distributed ledger system 1 ).
  • the distributed ledger system 1 in this embodiment consists of an organization 4 system and one or more audit organization 5 systems. Therefore, these may be collectively referred to as the sensitive data management system 1 .
  • the system of the processing requesting organization 3 has a distributed ledger node 10 and a client 50.
  • a user of the processing request organization 3 operates the client 50 to generate and send a processing request for sensitive data.
  • the system of the data holding organization 4 also has 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 processing requests sent from the distributed ledger node 10 or the client 50 of the processing requesting organization 3 by executing processing on the sensitive data held in the distributed ledger.
  • the private storage 30 is a storage device such as a distributed ledger that cannot be synchronized between nodes, and is a storage device that is separated from other organizations.
  • the client 52 is a terminal operated by the user of the data holding organization 4.
  • the system of the auditing organization 5 has a distributed ledger node 15, an auditing server 40, and a client 55.
  • the audit server 40 cooperates with the distributed ledger node 15 and leads the audit work regarding the correctness of the information managed by the distributed ledger node 12 of the data holding organization 4 and the private storage 30, the correctness of the processing history, etc. It is a device.
  • FIG. 2 is a diagram showing the hardware configuration of the distributed ledger node 10. As shown in FIG.
  • the distributed ledger node 10 in this embodiment consists of a storage unit 210, a computing unit 240, a memory 250, and a communication unit 260, which are connected via BUS.
  • the storage unit 210 is composed of an appropriate non-volatile storage element such as an SSD (Solid State Drive) or hard disk drive.
  • the memory 250 is composed of a volatile memory element such as a RAM (Random Access Memory).
  • RAM Random Access Memory
  • calculation unit 240 is a CPU (Central Processing Unit) that reads out the program 211 held in the storage unit 210 into the memory 250 and executes it, performs overall control of the device itself, and performs various determinations, calculations, and control processes. be.
  • CPU Central Processing Unit
  • the storage unit 210 stores a program 211, a distributed ledger 220, and a state database 230.
  • the distributed ledger 220 is a so-called block chain, which is data in which transactions called blocks are connected like a daisy chain.
  • 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.
  • program 211 is loaded into the memory 250 and then subjected to computational processing by the computing unit 240 to implement necessary functions.
  • Such a program 211 has a data management smartphone (smart contract) 212 and a task management smartphone 213.
  • the data management smartphone 212 is a smart contract that manages data (various data including sensitive data).
  • the task management smartphone 213 is a smart contract that manages tasks. This task corresponds to the processing content requested by the processing requesting organization 3 .
  • FIG. 3 is a diagram showing the hardware configuration of the task processing device 30.
  • the task processing device 30 comprises a storage section 310, a computing section 330, a memory 340, and a communication section 350, which are connected via BUS.
  • the storage unit 310 is composed of appropriate non-volatile storage elements such as SSDs (Solid State Drives) and hard disk drives.
  • the memory 340 is composed of a volatile memory element such as a RAM (Random Access Memory).
  • RAM Random Access Memory
  • calculation unit 330 is a CPU (Central Processing Unit) that reads out the program 311 held in the storage unit 310 into the memory 340 and executes it, performs overall control of the device itself, and performs various determinations, calculations, and control processes. be.
  • CPU Central Processing Unit
  • the computing unit 330 also has an encrypted area creating unit 331 called a TEE (Trusted Execution Environment) that encrypts part of the memory 340 area.
  • This encrypted area creation unit 331 can create an encrypted area 341 in the memory 340 .
  • the program 311 By loading and executing the program 311 in the encrypted area 341, the program 311 is protected from attacks and tampering by external attackers. Thereby, the distributed ledger system 1 can guarantee that the program 311 has operated correctly.
  • FIG. 4 is a diagram showing a hardware configuration example 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, which are connected via BUS.
  • the storage unit 410 is composed of appropriate non-volatile storage elements such as SSDs (Solid State Drives) and hard disk drives.
  • the memory 431 is composed of a volatile memory element such as a RAM (Random Access Memory).
  • RAM Random Access Memory
  • calculation unit 430 is a CPU (Central Processing Unit) that reads out the program 411 held in the storage unit 410 into the memory 431 and executes it, performs overall control of the device itself, and performs various determinations, calculations, and control processes. be.
  • CPU Central Processing Unit
  • the program 411 includes a user interface providing program 412 and an audit execution program 413.
  • the user interface providing program 412 distributes a predetermined user interface to the client 55 operated by the user of the audit work, and inputs audit work instructions and outputs audit results.
  • the audit execution program 413 is a program for executing various processes according to audit work.
  • FIG. 5 is a diagram showing the hardware configuration of the client 50.
  • the client 50 is composed of a storage unit 510, a calculation unit 530, a memory 531, and a communication unit 532, which are connected via BUS.
  • the storage unit 510 is composed of appropriate non-volatile storage elements such as SSDs (Solid State Drives) and hard disk drives.
  • the memory 531 is composed of a volatile memory element such as a RAM (Random Access Memory).
  • RAM Random Access Memory
  • calculation unit 530 is a CPU (Central Processing Unit) that reads out the program 511 held in the storage unit 510 into the memory 531 and executes it, performs overall control of the device itself, and performs various determinations, calculations, and control processes. be.
  • CPU Central Processing Unit
  • the program 511 in the storage 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.
  • FIG. 6 shows an example of the data catalog 221 in this embodiment.
  • This data catalog 221 is a table managed by the distributed ledger 220 .
  • the data catalog 221 manages the data name 601, owner 602, consent information 603, access right 604, and hash value 605 of the sensitive data using the data ID 600 that uniquely identifies the sensitive data as a key.
  • the owner 602 is the owner of the sensitive data.
  • 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.
  • the access right 604 is a value that defines an 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.
  • FIG. 7 is a diagram showing a data configuration example of the task list 222 managed by the distributed ledger 220.
  • This task list 222 includes a task ID 700 that uniquely identifies a task as a key, a requester 701 who requested the task, an ID 702 of the original data (substantial data) used for the task, a task content 703, and the task. is managed.
  • FIG. 8 is a diagram showing a configuration example of the data relationship 223 managed by the distributed ledger 220.
  • This data relationship 223 is a table for managing the relationship between each piece of sensitive data.
  • the record ID 800 as a key, the original data 801 indicating the sensitive data to be processed and the result indicating the processing result of the sensitive data.
  • Data 802, task ID 803 indicating the task that caused the processing, and correctness assurance 804 are managed.
  • the guarantee of correctness 804 is a value set when authenticity is recognized by the audit result by the audit server 40 .
  • a check mark is set.
  • FIG. 9A is a flow example of the sensitive data management method in this embodiment, and is a diagram showing an example of the overall flow.
  • each device of the processing requesting organization 3, the data holding organization 4, and the auditing organization 5 is connected by a distributed ledger network.
  • the task processing device 20 of the data holding organization 4 provides data (S10).
  • the data provision here is metadata of sensitive data, and for example, part or all of the data catalog 221 and the data relationship 223 are assumed.
  • the client 50 of the processing requesting organization 3 executes a request for granting access rights to the sensitive data owned in the distributed ledger 220 of the data holding organization 4 (S11).
  • the access right grant approval (S12) process is executed.
  • the client 50 of the processing requesting organization 3 executes a processing request (S13) for analysis of sensitive data for which access rights have been obtained as a result of the above processing (S12).
  • the task processing device 20 of the data holding organization 4 executes the analysis that received the request from the client 50 of the processing requesting organization 3 (S14), and the process ends.
  • FIG. 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.
  • the execution subjects of the processing are the client 52 of the data holding organization 4 and the distributed ledger node 12 .
  • the user 900 who is the person in charge of the data holding organization 4 or the like operates the client 52 and instructs the above-described data provision.
  • the client 52 reads the sensitive data held by its own organization in an appropriate storage device and provides it to the distributed ledger node 12 (901).
  • the data provided in this case will be the actual data of the sensitive data.
  • the distributed ledger node 12 of the data holding organization 4 receives sensitive data from the client 52 (902) and writes this sensitive data to the private storage 30 (903).
  • the distributed ledger node 12 of the data holding organization 4 creates metadata from the sensitive data received from the client 52 (904), writes it to the data catalog 221 of the distributed ledger 220 (905), and ends the process. .
  • FIG. 9C is a diagram showing a processing flow corresponding to an access right request, which is part of the sensitive data management method according to this embodiment.
  • the client 50 of the processing requesting organization 3 and the distributed ledger node 10 cooperate.
  • a user 910 of the processing requesting organization 3 operates the client 50 to execute a request that triggers this flow.
  • the client 50 of the processing requesting organization 3 executes a data list acquisition request (911) and requests the data catalog 221 managed by the distributed ledger 220 from the distributed ledger node 10.
  • 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 transmits it to the client 50 (913).
  • the sensitive data data catalog 221 is delivered to the client 50 .
  • the client 50 receives the data catalog 221 sent from the distributed ledger node 10 (914). Client 50 displays this data catalog 221 and presents it for viewing by user 910 .
  • the user 910 refers to the data catalog 221 and considers sensitive data that he/she wishes to use. Then, they want access to the sensitive data.
  • the client 50 receives an instruction from the user 910 and executes an access right request request (915) in order to request access rights to the sensitive data described above.
  • FIG. 9D is a diagram showing an example flow of access right approval, which is part of the sensitive data management method according to this embodiment.
  • the client 52 of the data holding organization 4 and the distributed ledger node 12 shall cooperate.
  • the user 920 of the data holding organization 4 operates the client 52 and gives a trigger for this flow.
  • the client 52 of the data holding organization 4 executes an access right request list acquisition request (921) and confirms that a request for granting access rights to the sensitive data held by the own organization has been received.
  • This access grant request was stored in distributed ledger 220 at step 916 in the flow of FIG. 9C described above.
  • the distributed ledger node 12 acquires the access right grant application information written in the distributed ledger 220 (922).
  • the distributed ledger node 12 transmits the access right grant application information acquired in step 922 above to the client 52 (923).
  • the client 52 receives the access right grant application information (924) and executes the workflow for approval work (925).
  • the workflow for example, it can be assumed that the client 52 executes an inquiry to the terminal of the provider of the sensitive data as to whether or not access rights can be granted, and acquires the result.
  • FIG. 9E is a diagram showing an example of an analysis request flow, which is part of the sensitive data management method in this embodiment.
  • the client 50 of the data holding organization 4 and the distributed ledger node 10 shall cooperate.
  • the user 930 operates the client 50 to trigger this flow.
  • the client 50 that has received the operation of the user 930 executes a task execution request (931) to the distributed ledger node 10 in order to execute a task that is, for example, a predetermined analysis process for sensitive data that has acquired access rights. do.
  • the distributed ledger node 10 confirms whether or not the task can be executed (932), and whether the processing requesting organization 3 has correctly obtained the access right, and whether the target sensitive data has correctly obtained the consent information from the data provider.
  • Execute confirmation such as whether it is 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 right 604 includes the identification information of the processing requesting organization 3 .
  • FIG. 9F is a diagram showing an example of an analysis execution flow, which is part of the sensitive data management method in this embodiment. In this case, it is assumed that the task processing device 20 of the data holding organization 4 and the distributed ledger node 15 cooperate.
  • the task processing device 20 polls the task list 222 managed by the distributed ledger 220 of the distributed ledger node 12 (941).
  • the distributed ledger node 12 receives the polling described above and there is a task managed by the distributed ledger 220, it passes it to the task processing device 20 (942).
  • the task processing device 20 acquires a task from the distributed ledger node 12 (943), and acquires (944) the actual data of the sensitive data targeted by the task.
  • the actual data acquired here is the actual data managed in the private storage 30 .
  • the task processing device 20 executes task execution determination (945) and confirms whether the actual data obtained in step 944 is correct.
  • the acquired actual data is input to a hash function (same as that held and used by the distributed ledger node 12). It can be assumed that a hash value is calculated using the distributed ledger 220 and compared with the value of the hash value 605 stored in the data catalog 221 of the distributed ledger 220 . As a result of this comparison, if the two match, it can be confirmed that the correct data has been loaded.
  • the task processing device 20 executes task execution (946) and executes processing such as analysis on the actual data read from the private storage 30.
  • the task processing device 20 executes task execution result return (947) and returns the analysis result to the distributed ledger node 12.
  • the distributed ledger node 12 executes task execution result writing (948) and writes whether the analysis succeeded or failed in the result 704 of the task list 222 managed by the distributed ledger 220.
  • FIG. 9G is a diagram showing an example of an audit flow, which is part of the sensitive data management method in this embodiment.
  • client 54 of audit organization 5, audit server 40, and distributed ledger node 14 are assumed to work together.
  • the user 950 of the auditing organization 5 operates the client 54 to trigger this flow.
  • the client 54 executes audit UI connection (951) and requests the audit server 40 for a UI for audit work.
  • the audit server 40 provides an audit UI (952) to the client 54 described above.
  • the UI provided to the client 54 here can be assumed to be, for example, an output screen of an audit UI 500 shown in FIG.
  • FIG. 14 is a diagram showing an example of the audit UI 500 in this embodiment.
  • the user operates an audit type selection interface 510 using the client 54 to select an audit type.
  • the audit types include data integrity audits, data deletion audits, consent information audits, and access right audits, which will be shown later in FIGS. 10-12.
  • the above-described user can select target sensitive data or select all sensitive data as audit targets.
  • the above-described user can operate the audit cycle setting interface 530 using the client 54 to set the audit cycle. Auditing can be set to run periodically or set to run only once.
  • the audit result by the audit server 40 is displayed.
  • the client 54 executes an audit operation instruction (953) for sending an instruction to the audit server 40 regarding the audit content received via the audit UI 500 described above.
  • FIG. 10 shows part of the contents of inspection in the execution of data inspection (954), and shows an example of the flow of data consistency inspection.
  • the audit server 40 acquires (1001) metadata related to sensitive data to be audited from the data catalog 221 .
  • the audit server 40 refers to the task list 222 and acquires (1002) a task using sensitive data to be audited.
  • the audit server 40 confirms whether the result data obtained from the task execution result is correct (1003).
  • the transaction (contents) held regarding the task processing for the sensitive data in the distributed ledger 220 is collated with the result data 802 of the task indicated by the data relationship 223, and it is confirmed whether they match. You can imagine what it does.
  • the audit server 40 writes a value indicating correctness (check in FIG. 8) in the correctness guarantee 804 of the data relationship 223 .
  • FIG. 11 is a part of the contents of inspection in the execution of data inspection (954), and is a diagram showing an example of the flow of data deletion inspection.
  • the audit server 40 acquires the metadata of the sensitive data management system to be audited from the data catalog 221 (1101).
  • the audit server 40 confirms (1102) whether the sensitive data to be audited has been correctly deleted.
  • This confirmation can be assumed, for example, to confirm the existence of (contents of) a transaction held in the distributed ledger 220 regarding the deletion process for the sensitive data and the non-existence of the relevant sensitive data in the data catalog 221 .
  • the audit server 40 searches the task list 222 for a task using sensitive data to be audited, and if there is such a task (1103: YES), returns to 1101 as a new audit target.
  • FIG. 12 is a part of the audit contents in the data audit execution (954), and is a diagram showing an example of the audit flow of the data consent information.
  • the audit server 40 acquires (1201) metadata related to sensitive data to be audited from the data catalog 221 .
  • the audit server 40 acquires (1202) the rewriting history of the access right consent information related to the sensitive data from the transaction in the distributed ledger 220.
  • the audit server 40 audits (1203) the change history of the consent information.
  • this audit for example, it is determined whether the rewrite history (contents) obtained in step 1202 regarding the consent information for the sensitive data in the distributed ledger 220 matches the content of the consent information 603 of the sensitive data in the data catalog 221. You can imagine what it does.
  • the audit server 40 checks whether there is a previous change history (1204), and if there is (1204: YES), the process returns to 1202.
  • FIG. 13 shows a part of the contents of auditing in the execution of data auditing (954), and shows an example of the auditing flow of data access rights.
  • the audit server 40 acquires (1301) metadata related to sensitive data to be audited from the data catalog 221 .
  • the audit server 40 acquires (1302) the rewriting history of the access right items related to the above sensitive data from the transaction in the distributed ledger 220.
  • the audit server 40 audits the access right application and approval information (1303).
  • the rewriting history (contents) obtained in step 1302 regarding granting access rights to the sensitive data in the distributed ledger 220 and the contents of the access rights 604 of the sensitive data in the data catalog 221 are checked. Anything that determines if there is a match can be envisioned.
  • the audit server 40 checks whether there is a previous rewriting history (1304), and if there is (1304: YES), returns the process to 1302.
  • the audit server 40 displays the audit result in the audit result display area 540 of the audit UI 500 (1305), and ends the process.
  • the provider of sensitive data can confirm that the withdrawal of consent information for utilization of the recipient and deletion of data, etc. have been performed correctly, and that the data is stored and utilized correctly and safely. can know that there is In other words, the sensitive data to be utilized can be verified and correctly managed according to the intention of the provider.
  • the nodes of the organization may execute various processes on the sensitive data using the Trusted Execution Environment.
  • the node of the organization as the processing request, the intention of the provider of the sensitive data to the organization to which the sensitive data is provided, Even if a request for deletion or deprivation of usage rights is received, the processing corresponding to the processing request is executed on the Trusted Execution Environment, and a log regarding the history of the processing is stored in the distributed ledger. good.
  • the nodes of the organization disperse the relationship of a series of N-order data, which are sequentially generated by the processing starting from the sensitive data, as a log regarding the history of the processing. It may be managed by a ledger.
  • the audit node related to the utilization of the sensitive data identifies the sensitive data to be audited based on the metadata held in the distributed ledger, and By identifying the transaction of the processing of the sensitive data held in the , and matching the transaction with the history indicated by the log of the sensitive data, the correctness of the relationship based on the sensitive data, or the sensitivity It is also possible to perform an audit process regarding the correctness of the data.
  • the nodes of the organization may execute various processes on the sensitive data using a Trusted Execution Environment.
  • the node of the organization is the intention of the provider of the sensitive data to the organization to which the sensitive data is provided.
  • processing corresponding to the processing request may be executed on the Trusted Execution Environment, and a log regarding the history of the processing may be stored in the distributed ledger.
  • the nodes of the organization disperse the relationship of a series of N-th order data sequentially generated by the processing starting from the sensitive data as a log regarding the history of the processing. It may be managed in a ledger.
  • the node for auditing related to the utilization of the sensitive data identifies the sensitive data to be audited based on the metadata held in the distributed ledger, By identifying the transaction of the processing of the sensitive data held in the , and matching the transaction with the history indicated by the log of the sensitive data, the correctness of the relationship based on the sensitive data, or the sensitivity An audit process for correctness of the data may be performed.
  • 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 node (data holding organization) 15 Distributed Ledger Node (Audit Organization) 20 task processing device 30 private storage 40 audit server 50 client (processing request organization) 52 Clients (data holding organizations) 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 encrypted area creation unit 340 memory 341 encrypted 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Dans un système de gestion de données sensibles (1), un nœud (4) d'une organisation est configuré pour conserver, dans un registre distribué, des métadonnées de données sensibles appartenant à chaque organisation, conserver, dans un stockage privé, des données réelles de données sensibles appartenant à l'organisation associée au nœud (4), exécuter la demande et l'approbation de droits d'utilisation au moyen d'un contrat intelligent, stocker les résultats de l'exécution dans le registre distribué, exécuter, lors de la réception d'une demande de traitement relative aux données sensibles, le traitement en fonction des droits d'utilisation, stocker, dans le registre distribué, un journal appartenant à l'historique du traitement, et renvoyer seulement les résultats du traitement à la demande de traitement.
PCT/JP2022/007390 2021-05-31 2022-02-22 Système de gestion de données sensibles et procédé de gestion de données sensibles WO2022254823A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-091003 2021-05-31
JP2021091003A JP2022183596A (ja) 2021-05-31 2021-05-31 機微データ管理システムおよび機微データ管理方法

Publications (1)

Publication Number Publication Date
WO2022254823A1 true WO2022254823A1 (fr) 2022-12-08

Family

ID=84324158

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/007390 WO2022254823A1 (fr) 2021-05-31 2022-02-22 Système de gestion de données sensibles et procédé de gestion de données sensibles

Country Status (2)

Country Link
JP (1) JP2022183596A (fr)
WO (1) WO2022254823A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018132931A (ja) * 2017-02-15 2018-08-23 富士通株式会社 承認システム、承認方法および承認プログラム
WO2021009789A1 (fr) * 2019-07-12 2021-01-21 日本電信電話株式会社 Dispositif de commande, système d'enregistrement de données et programme de commande

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018132931A (ja) * 2017-02-15 2018-08-23 富士通株式会社 承認システム、承認方法および承認プログラム
WO2021009789A1 (fr) * 2019-07-12 2021-01-21 日本電信電話株式会社 Dispositif de commande, système d'enregistrement de données et programme de commande

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HIROSHI NAGANO, TAKU SHIMOZAWA, ATSUSHI SHIMAMURA, NORIHISA KOMODA: "IS-20-53 Implementation of cross organizational workflow on blockchain", INSTITUTE OF ELECTRICAL ENGINEERS OF JAPAN STUDY GROUP MATERIALS. INFORMATION SYSTEMS (IS), 12 October 2020 (2020-10-12) - 13 October 2020 (2020-10-13), JP, pages 91 - 95, XP009542038 *
IKEGAWA, KOSHI; NISHIJIMA, NAO: "Trust Data Sharing and Utilization Infrastructure for Sensitive Data using Hyperledger Avalon", HYPERLEDGER GLOBAL FORUM 2021; [VIRTUAL]; JUNE 8-10, 2021, pages 1 - 31, XP009541764, Retrieved from the Internet <URL:https://static.sched.com/hosted_files/hgf2021/aa/HGF2021.pdf> *
TOSHIHIKO KURITA, DAI SUZUKI, MASATO YAMAGUCHI, SATOSHI IMAI: "Enhancement of Interoperability for Data Exchange Networks Using Blockchain", IEICE TECHNICAL REPORT, NS, vol. 118, no. 465 (NS2018-253), 1 March 2019 (2019-03-01), JP, pages 355 - 360, XP009541763 *
YEVGENIY Y. YARMOSH: "Hyperledger Avalon Architecture Overview, Revision 0.3", GITHUB, pages 1 - 21, XP009541747, Retrieved from the Internet <URL:https://github.com/hyperledger/avalon/blob/main/docs/avalon-arch.pdf> *

Also Published As

Publication number Publication date
JP2022183596A (ja) 2022-12-13

Similar Documents

Publication Publication Date Title
US11451530B2 (en) Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment
AU2020200682B2 (en) Systems and methods of secure provenance for distributed transaction databases
CN110620810B (zh) 在区块链上的连续资产转移的非链接所有权
US11257073B2 (en) Systems, methods, and apparatuses for implementing machine learning models for smart contracts using distributed ledger technologies in a cloud based computing environment
US11611560B2 (en) Systems, methods, and apparatuses for implementing consensus on read via a consensus on write smart contract trigger for a distributed ledger technology (DLT) platform
US20190236562A1 (en) Systems, methods, and apparatuses for implementing document interface and collaboration using quipchain in a cloud based computing environment
US20190236606A1 (en) Systems, methods, and apparatuses for implementing a virtual chain model for distributed ledger technologies in a cloud based computing environment
US20190236559A1 (en) Systems, methods, and apparatuses for implementing smart flow contracts using distributed ledger technologies in a cloud based computing environment
EP3785199A1 (fr) Vérification décentralisée des données
RU2730899C1 (ru) Отслеживание объектов между различными сторонами
Perwej A pervasive review of Blockchain technology and its potential applications
TW201913494A (zh) 基於區塊鏈智能合約的去中心化kyc系統及其方法
WO2022254823A1 (fr) Système de gestion de données sensibles et procédé de gestion de données sensibles
Tan et al. Blockchain for Decentralized Know Your Customer (KYC) and Customer Due Diligence (CDD) Pipelines in the Metaverse
WO2021142541A1 (fr) Systèmes et procédés pour la sécurité des actifs numériques
KR20220094013A (ko) 블록 체인의 뉴럴 블록 클러스터 기반의 스마트 컨트랙트 가시화 응용 플랫폼 제공 장치 및 그 동작 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22815582

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22815582

Country of ref document: EP

Kind code of ref document: A1