Data management apparatus and data management method

Abstract

To secure authenticity of data.SOLUTION: A virtual sever 31A has a storage 54 for storing log data (access history 71) indicating occurrence (access) of an event relating to a monitoring target file and a dispersion type registry 81, and a processor 51 for updating the dispersion type registry 81. The processor 51 stores transaction data generated from the log data in the dispersion type registry 81.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to a data management apparatus and a data management method, and more particularly, to a data management apparatus and a data management method using distributed ledger technology (DLT).

Background Art

[0002] The log management system disclosed in Japanese Patent Application Laid-Open No. 2013-235408 (Patent Document 1) includes access log registration means. When access is made from a user terminal via a network to file storage means, the access log registration means registers an access log including the identification information of the user terminal, the access date and time, and the operation type in an access log database.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the electronic management of data, it is always required to prevent unauthorized use of data, in other words, to ensure the authenticity of data.

[0005] The present disclosure has been made to solve the above problems, and one of the objects of the present disclosure is to ensure the authenticity of data in a data management apparatus or a data management method to which distributed ledger technology is applied.

Means for Solving the Problems

[0006] In one aspect of the present disclosure, a data management apparatus includes a first storage device that stores log data indicating the occurrence of an event related to a file to be monitored, a second storage device that stores a distributed ledger, and a processor that updates the distributed ledger. The processor stores transaction data generated from the log data in the distributed ledger.

[0007] A data management method in another aspect of the present disclosure uses distributed ledger technology. The data management method includes steps of: obtaining, by a processor, log data indicating the occurrence of an event related to a file to be monitored; generating, by the processor, transaction data from the log data; and storing, by the processor, the transaction data in a distributed ledger.

Advantages of the Invention

[0008] According to the present disclosure, the authenticity of data (files to be monitored) can be ensured.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Mode for Carrying Out the Invention

[0010] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and the description thereof will not be repeated.

[0011] [Embodiment 1] <System Configuration> FIG. 1 is a diagram showing an example of the overall configuration of the data management system in Embodiment 1 of the present disclosure. The data management system 100 is a system that manages data using distributed ledger technology, and more specifically, is a system that monitors the presence or absence of unauthorized use of data using distributed ledger technology. The data to be monitored by the data management system 100 is hereinafter referred to as the "monitoring target file". The type and / or data format of the monitoring target file are not particularly limited. The monitoring target file may be design data of a vehicle (or a component of the vehicle), a control program of the vehicle, or a document file in which technical information (specifications, development know-how, etc.) related to the vehicle is described.

[0012] The data management system 100 includes, for example, a platform server 1, a cloud server 2, a plurality of user terminals 41A to 41D, and a plurality of external servers 9.

[0013] The platform server 1 manages the network NW. The network NW is, for example, a consortium network formed among a plurality of enterprises. The platform server 1 receives an application for participation in the network NW from the cloud server 2. The platform server 1 permits the cloud server 2 to participate in the network NW based on an operation by the administrator of the platform server 1 or based on the determination result of a predetermined condition.

[0014] The cloud server 2 includes, in this example, four databases 21A to 21D and four virtual servers 31A to 31D. However, the number of databases and virtual servers is not particularly limited. The databases 21A to 21D have the same configuration and functions. The same applies to the virtual servers 31A to 31D. Therefore, hereinafter, the database 21A and the virtual server 31A will be typically described.

[0015] The database 21A and the virtual server 31A are connected to be communicable bidirectionally with a plurality of user terminals 41A. Each of the plurality of user terminals 41A is an information processing terminal lent to a user (typically an employee) belonging to Company A in this example, and is a PC (Personal Computer), a smartphone, a tablet, or the like. Note that the user terminal 41A can also function as an input device and / or an output device of the cloud server 2 (virtual server 31A).

[0016] The database 21A is virtual storage. The database 21A is realized by a rewritable storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a flash memory.

[0017] FIG. 2 is a diagram showing an example of the configuration of the database 21A in Embodiment 1. In the database 21A, the data storage area is divided into a plurality of areas. The plurality of areas include, for example, access restriction areas 211 to 213 and a non-access restriction area 214.

[0018] The access restriction areas 211 to 213 are storage areas where access is restricted to only users who have been granted permissions in advance. The access restriction areas 211 to 213 have stronger access restrictions in this order. More specifically, a user granted the highest authority can access all the access restriction areas 211 to 213. A user granted medium-level authority can access the access restriction areas 212 and 213, but cannot access the access restriction area 211. A user granted only the lowest authority can access the access restriction area 213, but cannot access the access restriction areas 211 and 212.

[0019] It is desirable that the files to be monitored are stored in the access restriction area. In this example, the files to be monitored P and Q are stored in the access restriction area 211, the file to be monitored R is stored in the access restriction area 212, and the file to be monitored S is stored in the access restriction area 213. In this way, the access rights to the files to be monitored P to Q can be set for each user.

[0020] Returning to FIG. 1, when a user performs an operation on the user terminal 41A to access any of the files to be monitored, the virtual server 31A determines whether the user has the authority to access the file to be monitored. If the user has the authority, the virtual server 31A outputs a control signal to the database 21A in response to the user operation. The database 21A executes processing (such as file viewing, addition, registration, update, change, deletion, transmission, download, etc.) on the file to be monitored according to the control signal from the virtual server 31A.

[0021] The virtual server 31A has the software of the distributed ledger infrastructure installed. When the software of the distributed ledger infrastructure functions, the virtual server 31A functions as a node. Note that the plurality of external servers 9 also have the software of the distributed ledger infrastructure, similar to the four virtual servers 31A to 31D.

[0022] FIG. 3 is a diagram showing an example of the configuration of the virtual server 31A in the first embodiment. Referring to FIGS. 1 and 3, the virtual server 31A includes a processor 51, a memory 52, a communication device 53, and a storage 54. The components of the virtual server 31A are communicably connected to each other by a bus 55.

[0023] The processor 51 is an arithmetic processing device such as a CPU (Central Processing Unit) or an MPU (Micro-Processing Unit). The memory 52 includes a ROM (Read Only Memory) and a RAM (Random Access Memory). The memory 52 stores a system program including an OS (Operating System) and a control program including computer-readable code necessary for control arithmetic. The processor 51 reads out the system program and the control program, expands them in the memory 52, and executes them to realize various processes. The processor 51 updates the access history 71 to the monitored files P to S and generates transaction data for updating the distributed ledger 81, which will be described in detail later.

[0024] Note that although FIG. 2 shows an example in which the virtual server 31A includes only one processor, the virtual server 31A may include a plurality of processors. That is, the virtual server 31A includes one or more processors. The same applies to the memory 52 and the storage 54. In this specification, the "processor" is not limited to a narrow sense processor that executes processing in a stored program manner, and may include hard-wired circuits such as an ASIC (Application Specific Integrated Circuit) and an FPGA (Field-Programmable Gate Array). Therefore, the term "processor" can also be read as a processing circuit (circuitry or processing circuitry) whose processing is defined in advance by computer-readable code and / or hard-wired circuits.

[0025] The communication device 53 communicates with external devices of the virtual server 31A. The external devices may include the platform server 1, other virtual servers 31B to 31D, a plurality of user terminals 41A, a plurality of external servers 9, and the like.

[0026] The storage 54 is a rewritable storage device, such as an HDD, an SSD, or a flash memory. The storage 54 stores the secret key 61, a plurality of public keys 62, the access history 71, and the distributed ledger 81.

[0027] The private key 61 is the private key managed by Company A. The multiple public keys 62 include the public keys of Companies B to D. The multiple public keys 62 may also include the public key of Company A itself. For example, when the virtual server 31A first joins the network NW, the processor 51 generates a private key and a public key. Then, the processor 51 sends the generated public key to a certification authority (not shown) to receive authentication. The certification authority issues an electronic certificate including the public key information. The processor 51 stores the private key 61 corresponding to the authenticated public key in the storage 54. Also, the processor 51 sends the authenticated public key (electronic certificate) 62 to the virtual servers 31B to 31D of other companies B to D. Similarly, each of the virtual servers 31B to 31D sends its own public key to virtual servers other than itself.

[0028] The access history 71 is data indicating the access history to the monitored files P to S (see FIG. 2). The access history 71 is an example of the "log data" according to the present disclosure. The access history 71 will be described in detail with reference to FIG. 4 later.

[0029] The distributed ledger 81 includes a plurality of ledgers. Since each ledger has a chain structure (more specifically, a directed acyclic graph (DAG) structure), hereinafter, the ledger is also referred to as a "chain". In Embodiment 1, for ease of understanding, two types of chains described later are prepared for each predetermined monitored file. However, two types of chains may be prepared for each of a plurality of monitored files.

[0030] When an update of the distributed ledger 81 is requested by a user, for example, the virtual server 31A updates one of the two types of chains (the evidence chain 811 described later) based on the latest monitored file. Also, each time the one chain is updated or each time an access to the monitored file is detected, the virtual server 31A updates the other chain (the access history chain 812 described later) based on the access history 71. These chains will be described in detail with reference to FIG. 5 later.

[0031] Note that each of the virtual servers 31A to 31D in the data management system 100 corresponds to the "data management device" according to the present disclosure. The data management system 100 may include a plurality of physical servers (not shown) instead of the virtual servers 31A to 31D. In that case, each physical server corresponds to the "data management device" according to the present disclosure.

[0032] The storage 54 of the virtual server 31A corresponds to both the "first storage device" and the "second storage device" according to the present disclosure. However, the "first storage device" and the "second storage device" may be realized by separate devices.

[0033] Hereinafter, when the virtual servers 31A to 31D are not particularly distinguished, A to D in the reference numerals are omitted and described as "virtual server 31". The same applies to the user terminal and the database.

[0034] <Access history> FIG. 4 is a diagram showing an example of the data structure of the access history 71. Each record of the access history 71 includes, for example, a key, a file ID, a time, a user, and an operation.

[0035] The key is an identifier of a record in the access history 71. The file ID is identification information of the monitored file that has been accessed. The time is the access time to the monitored file. The user is identification information (such as a device ID) of the user device 41 that has accessed the monitored file. The user may be identification information (such as a login name) of the user who has accessed the monitored file. The operation is the type of operation (such as an operation requesting browsing, adding, registering, updating, changing, deleting, transmitting, downloading, etc. of a file) that the user who has accessed the monitored file has performed on the monitored file.

[0036] <Distributed ledger> FIG. 5 is a diagram showing an example of the data structure of the distributed ledger 81 in Embodiment 1. The distributed ledger 81 includes, for example, a plurality of evidence chains 811 and a plurality of access history chains 812. For the convenience of the drawing, only one chain of each of the two types is shown in FIG. 5. In Embodiment 1, one evidence chain 811 and one access history chain 812 are associated with each other. However, a plurality of evidence chains 811 may be associated with one access history chain 812.

[0037] The evidence chain 811 is a ledger in which transaction data regarding the file to be monitored is stored in chronological order. In this example, the evidence chain 811 includes three records R11 to R13. Each record includes a key, a chain ID, an age, data, a nonce value, an electronic signature, a previous record hash value, and a record hash value.

[0038] The key is an identifier of the record in the evidence chain 811.

[0039] The chain ID is identification information for identifying the evidence chain 811. In this example, the chain ID = e1 is assigned to the evidence chain 811. As a result, a record with the chain ID = e1 is stored in the evidence chain 811.

[0040] The age is information indicating the order of the records. The age of the first record is 1. And each time a record is added with the update of the file to be monitored, the age is incremented. Hereinafter, the first (oldest) record will be referred to as the "start record", and the last (newest) record will be referred to as the "end record".

[0041] The data stored in the evidence chain 811 is a hash value obtained by hashing the file to be monitored (hereinafter referred to as "file hash value"). When the file to be monitored is updated, a hash value is generated by hashing the updated file to be monitored using a hash function. Then, the generated hash value is stored in the evidence chain 811 as the file hash value. In this example, file hash values FH1 to FH3 are stored in records R11 to R13, respectively.

[0042] The nonce value is a value indicating the number of the transaction data. The nonce value is used, for example, as the number of the process of storing the file hash value in the evidence chain 811 when the file to be monitored is updated.

[0043] The electronic signature is information for authenticating the virtual server 31 that issued the transaction data. The electronic signature is generated, for example, by encrypting the file hash value with the private key 61 of the virtual server 31 that issued the transaction data.

[0044] The previous record hash value is the record hash value of the record of the previous generation of the said record (in other words, the parent record).

[0045] The record hash value is the hash value of the said record. The record hash value is generated by hashing information of records other than the record hash value (part or all of the key, chain ID, generation, data, nonce value, electronic signature, and previous record hash value) using a hash function.

[0046] The record hash value of the end record (record with Age = 3) R13 of the evidence chain 811 is "h3". The previous record hash value of the end record R13 is the "h2" of the record hash value of the parent record (record with Age = 2) R12. The previous record hash value of record R12 is the "h1" of the record hash value of the parent record (record with Age = 1) R11. Thus, in the evidence chain 811, multiple records are chained by each of the multiple records including the previous record hash value.

[0047] The access history chain 812 is a ledger in which transaction data regarding the access history 71 is stored in chronological order. In this example, the access history chain 812 includes seven records R21 to R27. Similar to the records of the evidence chain, each record includes a key, a chain ID, a generation, data, a nonce value, an electronic signature, a previous record hash value, and a record hash value.

[0048] While the data in the evidence chain 811 is the file hash value generated from the monitored file, the data in the access history chain 812 is the history hash value or the end hash value.

[0049] The history hash value is the hash value obtained by hashing the access history 71 when transaction data is stored in the evidence chain 811 (when a record is added), or when an access to the monitored file is detected. In this example, the history hash values AH1, AH2, AH3, and AH4 are stored in four records R22, R24, R25, and R27 respectively. The history hash value corresponds to the "log hash value" according to the present disclosure. However, if the data generated by the data conversion of the access history 71 is stored in the access history chain 812, the method of the data conversion is not limited to hashing.

[0050] The terminal hash value is, for example, the record hash value of the terminal record of the evidence chain 811 after data processing (such as addition, registration, modification, update, deletion, etc. of the file to be monitored) is executed on the file to be monitored, and the evidence chain 811 is updated accordingly. In this example, the record hash value "h1" of the record R11 of the evidence chain 811 is stored in the record R21. The record hash value "h2" of the record R12 of the evidence chain 811 is stored in the record R23. The record hash value "h3" of the record R13 of the evidence chain 811 is stored in the record R26.

[0051] Since the data other than the above included in the access history chain 812 is the same as the corresponding data of the evidence chain 811, detailed description will not be repeated. The evidence chain 811 corresponds to the "first ledger" according to the present disclosure. The access history chain 812 corresponds to the "second ledger" according to the present disclosure.

[0052] In this way, the virtual server 31A generates transaction data so that the history hash value is associated with the terminal hash value of the evidence chain 811, and stores the generated transaction data in the access history chain 812. Thereby, the evidence chain 811 and the access history chain 812 are linked to each other. Hereinafter, the relationship between the two chains will be described in detail by explaining the processing in the above two chains in chronological order.

[0053] <Relationship between the two chains> FIG. 6 is a conceptual diagram for explaining the relationship between the records stored in the evidence chain 811 and the access history chain 812.

[0054] ≪Evidence chain, Age = 1≫ First, assume that the monitored file P shown in FIG. 2 (hereinafter abbreviated as "file P") is registered in the database 21A according to the operations of a certain user belonging to Company A. The virtual server 31A generates transaction data for adding the record R11 of the first generation (Age = 1) to the evidence chain 811. The record R11 includes the file hash value FH1 generated by hashing the file P and the record hash value h1 generated by hashing various information of the record R11.

[0055] The virtual server 31A transmits the generated transaction data to the network NW. By executing the process (transaction process) for executing the transaction data in the virtual servers 31A to 31D, the record R11 is added to the evidence chains 811 of each of the virtual servers 31A to 31D and the plurality of external servers 9. Since these processes involving all the virtual servers 31A to 31D are the same in subsequent generations (and access history chain 812) of the evidence chain 811, the description will not be repeated.

[0056] ≪Access History Chain with Age = 1, 2≫ In response to the update of the evidence chain 811 or the detection of access to the file P such as the registration of the file P, the virtual server 31A generates transaction data for adding the record R21 of the first generation to the access history chain 812. The record R21 includes the terminal hash value of the evidence chain 811 at that time (the record hash value of the record R11 which is the terminal record of the evidence chain 811) h1 and the record hash value H1 generated by hashing the information of the record R21.

[0057] In addition, the virtual server 31A generates transaction data for adding the second-generation record R22 to the access history chain 812. The record R22 includes a history hash value AH1 generated from the access history 71 containing information regarding the registration of the file P, the previous record hash value H1, and a record hash value H2 generated by hashing various information of the record R22.

[0058] ≪Proof Chain with Age = 2≫ Subsequently, assume that the file P is updated on the database 21A. This update may be performed by the user who registered the file P (the above-mentioned user of Company A), or may be performed by a user different from the said user (for example, another user within Company A or a user of other companies B to D). The virtual server 31A generates transaction data for adding the second-generation record R12 to the proof chain 811. The record R12 includes a file hash value FH2 generated from the updated file P, the previous record hash value h1, and a record hash value h2 generated by hashing various information of the record R12.

[0059] ≪Access History Chain with Age = 3, 4≫ In response to the update of the proof chain 811 or the detection of an access to the file P in the form of an update of the file P, the virtual server 31A generates transaction data for adding the third-generation record R23 to the access history chain 812. The record R23 includes the terminal hash value of the proof chain 811 at that time (the record hash value of the record R12 in the proof chain 811) h2, the previous record hash value H2, and a record hash value H3 generated by hashing various information of the record R23.

[0060] In addition, the virtual server 31A generates transaction data for adding the fourth-generation record R24 to the access history chain 812. The record R24 includes a history hash value AH2 generated from the access history 71 containing information regarding the update of the file P, the previous record hash value H3, and a record hash value H4 generated by hashing various information of the record R24.

[0061] ≪Access history chain, Age = 5≫ Furthermore, assume that the file P is viewed on the database 21A (however, the file P itself is not modified). In response to detecting the access to the file P, i.e., the viewing of the file P, the virtual server 31A generates transaction data for adding the fifth-generation record R25 to the access history chain 812. The record R25 includes a history hash value AH3 generated from the access history 71 containing information regarding the viewing of the file P, the previous record hash value H4, and a record hash value H5 generated by hashing various information of the record R25.

[0062] ≪Evidence chain, Age = 3≫ After that, assume that the file P is deleted on the database 21A. The virtual server 31A generates transaction data for adding the third-generation record R13 to the evidence chain 811. The record R13 includes a file hash value FH3 regarding the file P after deletion, the previous record hash value h2, and a record hash value h3 generated by hashing various information of the record R13.

[0063] ≪Access history chain, Age = 6, 7≫ In response to the update of the evidence chain 811 or the detection of access to file P such as deletion of file P, the virtual server 31A generates transaction data for adding the sixth-generation record R26 to the access history chain 812. The record R26 includes the terminal hash value of the evidence chain 811 at that time (the record hash value of the record R13 in the evidence chain 811) h3, the previous record hash value H5, and the record hash value H6 generated by hashing various information of the record R26.

[0064] In addition, the virtual server 31A generates transaction data for adding the seventh-generation record R27 to the access history chain 812. The record R27 includes the history hash value AH4 generated from the access history 71 including information regarding the deletion of file P, the previous record hash value H6, and the record hash value H7 generated by hashing various information of the record R27.

[0065] Thus, in the first embodiment, in the evidence chain 811, each of the plurality of records (except the start record) includes the previous record hash value, so that all the records are chained. Therefore, in order to tamper with the file hash in any record, it is necessary to tamper with all the records added after that record. However, such tampering is practically difficult. The same applies to the access history chain 812. Therefore, according to the first embodiment, it is possible to prove that the monitored file has not been tampered with and that the access history 71 has not been tampered with.

[0066] If someone attempts to misuse a monitored file (such as false input, rewriting, deletion, confusion, transmission, download, etc.), this will be recorded in the access history 71. Since the access history 71 is substantially tamper-proof, the traces of misuse cannot be erased. Therefore, the authenticity of the monitored file and the access history 71 can be ensured. Also, by making it known that the authenticity of the access history 71 is ensured, a deterrent effect against the misuse of the monitored file P is exerted, thus reducing the possibility of misuse of the monitored file P.

[0067] <Flow related to the access history chain> FIG. 7 is a flowchart showing an example of the processing procedure for updating the access history chain 812 in Embodiment 1. The processing shown in this flowchart is called and executed from the main routine when a predetermined condition is satisfied (for example, every predetermined control period). Each step is realized by software processing by the virtual server 31 (processor 51), but may also be realized by hardware (electric circuit) arranged in the virtual server 31. Hereinafter, the steps are abbreviated as S.

[0068] In S11, the virtual server 31 determines whether an access to the monitored file has been detected. If no access is detected (NO in S11), the virtual server 31 returns the processing to the main routine. If an access is detected (YES in S11), the virtual server 31 proceeds with the processing to S12.

[0069] In S12, the virtual server 31 determines whether the evidence chain 811 corresponding to the monitored file for which the access has been detected has been updated. If the evidence chain 811 has been updated due to registration, change, deletion, etc. of the monitored file (YES in S12), the virtual server 31 proceeds with the processing to S13.

[0070] In S13, the virtual server 31 obtains the terminal hash value of the updated evidence chain 811. Then, in S14, the virtual server 31 generates a record (see R21, R23, R26 in FIGS. 5 and 6) of the access history chain 812 that includes the terminal hash value obtained in S13, together with the previous record hash value and the new record hash value (S14). However, the start record does not include the previous record hash value. After that, the virtual server 31 proceeds with the process to S15.

[0071] If only the viewing, transmission, and downloading of the file to be monitored have been performed and the evidence chain 811 has not been updated in S12 (NO in S12), the virtual server 31 skips the processes of S13 and S14 and proceeds with the process to S15.

[0072] In S15, the virtual server 31 generates a history hash value from the access history 71. Then, the virtual server 31 generates a record (see R22, R24, R25, R27 in FIGS. 5 and 6) of the access history chain 812 that includes the history hash value generated in S15, together with the previous record hash value and the new record hash value (S16). However, the start record does not include the previous record hash value.

[0073] In S17, the virtual server 31 updates the access history chain 812 by adding the newly generated one or two records to the access history chain 812.

[0074] As described above, in Embodiment 1, each of the evidence chain 811 and the access history chain 812 is substantially tamper-proof. Therefore, traces of unauthorized use of the file to be monitored are surely left in the access history 71. Thus, unauthorized use of the file to be monitored can be suppressed, and the authenticity of the access history 71 can be ensured.

[0075] In addition, since all records in the evidence chain 811 are chained, the order of all records stored in the evidence chain 811 is uniquely determined. Therefore, according to Embodiment 1, the sequentiality of the monitored file can be proven. Similarly, for the access history chain 812, the sequentiality of the access history 71 can be proven.

[0076] [Embodiment 2] In Embodiment 1, an example in which the distributed ledger 81 (access history chain 812) is generated based on the user's access history to the monitored file has been described. In Embodiment 2, an example in which the distributed ledger is generated based on the data collection history (log) from the device will be described.

[0077] [System Configuration] FIG. 8 is a diagram showing an example of the overall configuration of the data management system in Embodiment 2 of the present disclosure. The data management system 200 is different from the data management system 100 (see FIG. 1) in Embodiment 1 in that the cloud server 2 includes databases 22A to 22D and virtual servers 32A to 32D instead of databases 21A to 21D and virtual servers 31A to 31D, and the cloud server 2 is connected to a plurality of inspection devices 42A to 42D instead of a plurality of user terminals 41A to 41D.

[0078] Each of the plurality of inspection devices 42A to 42D is used, for example, by an operator who performs vehicle inspections (maintenance). The inspection device 42A generates inspection data indicating the inspection results of the vehicle to be inspected, and stores the generated inspection data in the database 22A. The same applies to the other inspection devices 42B to 42D.

[0079] FIG. 9 is a diagram showing an example of the configuration of the database 22A in Embodiment 2. The database 22 includes an access-restricted area 221 in which a plurality of inspection data K to L are stored, and a non-access-restricted area 222. A plurality of access-restricted areas with different access restriction levels may be provided.

[0080] FIG. 10 is a diagram showing an example of the configuration of the virtual server 32A in the second embodiment. The virtual server 32A is different from the virtual server 31A (see FIG. 3) in the first embodiment in that it includes a storage 54 in which inspection logs 72 and a distributed ledger 82 are stored instead of access histories 71 and a distributed ledger 81.

[0081] Since the other configurations of the data management system 200 are the same as the corresponding configurations of the data management system 100 in the first embodiment, the description will not be repeated.

[0082] Note that the inspection data is an example of the "monitored file" according to the present disclosure, and the inspection devices 42A to 42D are examples of the "devices" according to the present disclosure. The "device" is not particularly limited as long as it is a device (so-called IoT (Internet of Things) device) that can acquire some data and output the acquired data to the outside. The "device" may be, for example, an inspection device for industrial products other than vehicles, an inspection device for food (agricultural products, livestock products, fishery products, etc.), or a medical diagnostic device.

[0083] <Inspection Log> FIG. 11 is a diagram showing an example of the data structure of the inspection log 72. Each record of the inspection log 72 includes, for example, a key, a device ID (Dev ID), a device type (Dev Type), a collection time (Time), a data ID (Data ID), and a process.

[0084] A key is an identifier of a record in the inspection log 72. A device ID is identification information (ID) of the inspection devices 42A to 42D. A device type is information indicating the type of the inspection device (such as the model number or model of the inspection device). A collection time is the time when inspection data is collected from the inspection devices 42A to 42D to the database 22A. The record of the inspection log 72 may include, instead of or in addition to the collection time, the inspection time of the vehicle by the inspection devices 42A to 42D (i.e., the generation time of the inspection data). A data ID is identification information of the inspection data. A process is the type of data process executed on the inspection data (such as addition, registration, change, update, deletion, etc. of the inspection data).

[0085] In the inspection log 72, inspection results may be managed separately for each inspection device. In the example shown in FIG. 11, the inspection log 72 includes three histories 721 to 723. The histories 721 to 723 store information regarding inspection devices given device IDs of dev1, dev2, or dev3, respectively. The inspection log 72 is another example of the "log data" according to the present disclosure.

[0086] <Distributed ledger> FIG. 12 is a diagram showing an example of the data structure of the distributed ledger 82 in Embodiment 2. The distributed ledger 81 includes, for example, a plurality of inspection data chains 821 and a plurality of inspection log chains 822.

[0087] The inspection data chain 821 is a ledger in which transaction data related to inspection data is stored in chronological order. Each record of the inspection data chain 821 includes, similar to each record of the evidence chain 811 (see FIG. 5), for example, a key, a chain ID, a generation, data, a nonce value, an electronic signature, a previous record hash value, and a record hash value.

[0088] The data in the inspection data chain 821 is a hash value generated from the inspection data (hereinafter referred to as "inspection hash value"). When the inspection data is updated, a hash value is generated by hashing the updated inspection data, and the generated hash value is stored in the inspection data chain 821 as the inspection hash value.

[0089] The inspection log chain 822 is a ledger in which transaction data related to the inspection log 72 of the inspection data is stored in chronological order. The inspection log chain 822 is preferably provided for each inspection device (for each inspection data managed separately for each inspection device). Each record of the inspection log chain 822 includes a key, a chain ID, a generation, data, a nonce value, an electronic signature, a previous record hash value, and a record hash value, similar to the records of the inspection data chain 821.

[0090] The data in the inspection log chain 822 is a log hash value or an end hash value. The log hash value is a hash value generated from the inspection log 72 when the inspection data chain 821 is updated or when data processing (such as addition, registration, change, update, deletion, etc.) of the inspection data is detected. The end hash value is, for example, the record hash value of the end record of the inspection data chain 821 at the time when a user operation requesting an update of the inspection data chain 821 is performed after the execution of data processing on the inspection data.

[0091] Since the information other than the above included in the inspection log chain 822 is the same as the corresponding information of the inspection data chain 821, detailed description will not be repeated. The inspection data chain 821 corresponds to the "first ledger" according to the present disclosure. The inspection log chain 822 corresponds to the "second ledger" according to the present disclosure.

[0092] <Relationship between the two chains> FIG. 13 is a conceptual diagram for explaining the relationship between the records stored in the inspection data chain 821 and the inspection log chain 822. The processes shown in this conceptual diagram are equivalent to the processes in Embodiment 1 (see FIG. 6) if the access to the monitored file is regarded as data processing for the inspection data, and thus detailed descriptions will not be repeated.

[0093] <Flow related to the inspection log chain> FIG. 14 is a flowchart showing an example of the processing procedure for updating the inspection log chain 822 in Embodiment 2. The processes shown in this flowchart are also equivalent to the processes in Embodiment 2 (see FIG. 7) if the access to the monitored file is regarded as data processing for the inspection data, and thus detailed descriptions will not be repeated.

[0094] As described above, also in Embodiment 2 as in Embodiment 1, since the inspection data chain 821 and the inspection log chain 822 are substantially tamper-proof, the inspection log 72 is also tamper-proof. If someone attempts unauthorized use (such as rewriting) of the inspection data, this will be recorded in the inspection log 72, and the traces of unauthorized use cannot be erased. Therefore, unauthorized use of the inspection data can be suppressed, and the authenticity of the inspection log 72 can be ensured.

[0095] The embodiments disclosed this time should be considered as illustrative in all respects and not restrictive. The scope of the present disclosure is indicated by the scope of claims rather than the description of the above embodiments, and it is intended that all modifications within the meaning and scope equivalent to the scope of claims be included.

Description of reference numerals

[0096] 100,200 Data Management System, 1 Platform Server, 2 Cloud Servers, 21(21A~21D),22(22A~22D) Databases, 211~213,221 Access Restricted Areas, 214,222 Non-Access Restricted Areas, 31(31A~31D),32(32A~32D) Virtual Servers, 41A~41D User Terminals, 42A~42D Inspection Devices, 51 Processor, 52 Memory, 53 Communication Device, 54 Storage, 55 Bus, 61 Secret Key, 62 Public Key, 71 Access History, 72 Inspection Log, 721~723 History, 81,82 Distributed Ledgers, 811 Evidence Chain, 812 Access History Chain, 821 Inspection Data Chain, 822 Inspection Log Chain, 9 External Server, NW Network.

Claims

1. A first storage device that stores log data indicating the occurrence of an event related to a file to be monitored, A second storage device that stores a distributed ledger, A processor that updates the distributed ledger, and The processor stores transaction data generated from the log data in the distributed ledger, a data management device.

2. The processor includes a log hash value obtained by hashing the log data in the transaction data, the data management device according to claim 1.

3. The distributed ledger includes a first ledger and a second ledger, The processor, Stores other transaction data including a file hash value obtained by hashing the file to be monitored in the first ledger, Generates the transaction data so that the log hash value is associated with a hash value obtained by hashing data included in the other transaction data, and stores the generated transaction data in the second ledger, the data management device according to claim 2.

4. The processor generates the transaction data and stores it in the second ledger every time the other transaction data is stored in the first ledger, the data management device according to claim 3.

5. The processor generates the transaction data and stores it in the second ledger every time the occurrence of the event is detected, the data management device according to claim 3.

6. The event is an access to the file to be monitored, The log data is data indicating an access history to the file to be monitored, the data management device according to any one of claims 1 to 5.

7. The access history includes user information indicating a user who accessed the file to be monitored and an access time to the file to be monitored, the data management device according to claim 6.

8. The access history further includes a type of operation on the file to be monitored by the user, the data management device according to claim 7.

9. The processor, Restricts access to a specific area in the storage area of the log data in the first storage device, Grants access rights to the specific area for each user distinguished by the user information, the data management device according to claim 7.

10. The monitored file is data collected from a device, The log data is data indicating the collection history of the monitored file, the data management device according to any one of claims 1 to 5. **Claim 11** The collection history includes the identification information of the device and the data collection time from the device, the data management device according to claim 10. **Claim 12** The processor manages the distributed ledger for each device distinguished by the identification information, the data management device according to claim 11. **Claim 13** A data management method using a distributed ledger technology, Obtaining, by a processor, log data indicating the occurrence of an event related to a monitored file; Generating, by the processor, transaction data from the log data; and Storing, by the processor, the transaction data in the distributed ledger, the data management method.

Images