Systems utilizing blockchain

Abstract

The system to which the present invention relates is a system for managing the release of developed programs to a formal environment, the system comprising: a plurality of servers on which blockchains are installed; a detection unit for detecting events related to the release of programs; and a generation unit for generating blocks of the blockchain, wherein the blocks of the blockchain include uniqueness information for ensuring the uniqueness of the program when an event is detected and identification information for identifying the detected event.

Description

Technical Field

[0001] The present invention relates to a system utilizing blockchain. Background Art

[0002] In the development of large-scale systems, migrating multiple completed program modules to a production environment is essential. While this requires considerable effort and time, it also creates a breeding ground for various human errors, such as confusing old and new versions. To improve this situation, the present applicant has proposed a program release management system as described in Patent Document 1.

[0003] In the program distribution management system described in Patent Document 1, an approver accesses the development area of ​​a network-attached storage (NAS) from an approver's terminal, confirms that the developed program file contains no illegal logic, and then grants approval to the librarian for the transfer of the program file. The approver then passes specific information such as the program file's file name, file size, and timestamp to the librarian.

[0004] The library administrator who receives the above information accesses the forwarding server, checks the overview information of the program files saved in the development side area on the display of the library administrator terminal, determines the approved program file based on the file name, file size, and timestamp, and issues an instruction requesting its transfer.

[0005] In this way, by having the approver pass the specific information of the program files stored in the development side area to the library administrator, and the library administrator selecting the program files to be forwarded based on this information, it is possible to restrain developers from tampering with the program files stored in the development side area, which is accompanied by changes in file size and timestamps, within a very short period of time from the approver's approval to the completion of forwarding to the formal side area.

[0006] Here, the term "librarian" refers to a dedicated third-party organization that is completely independent of the departments to which developers and approvers belong and has no vested interests. In the program release management system described in Patent Document 1, a librarian is secured within the organization to ensure internal control through program tampering checks and deployment to a production environment.

[0007] Prior art literature

[0008] Patent Literature

[0009] Patent Document 1: Japanese Patent No. 5253336

[0010] Patent Document 2: Japanese Patent Application Publication No. 2019-029019 Summary of the Invention

[0011] Problems to be solved by the invention

[0012] In recent years, systems have become increasingly large-scale and complex, and the frequency of module updates has also increased, increasing the workload of librarians. Document verification requires multiple checks by multiple librarians, which increases the number of personnel required. Furthermore, efforts to improve productivity through teaming have led to a growing number of librarian organizations. During an audit, an auditor visits the company, enters the confidential room, and verifies evidence on paper. The librarian is also responsible for responding to the auditor and providing the documents. Furthermore, while the librarian's work is relatively simple, maintaining employee motivation is crucial because mistakes are a must.

[0013] Therefore, research is underway to systematize the librarian's work. Patent Document 1 describes a technology that automates the file matching and forwarding instructions performed by the librarian. However, the final confirmation ultimately falls to the librarian, limiting this technology to assisting in library management. Patent Document 1 does not describe the concept of replacing the librarian with a system.

[0014] When the librarian is replaced by a system, human oversight becomes impossible, requiring both pre- and post-implementation security measures. For example, the possibility of malicious developers tampering with programs stored in the development area must be addressed between the time the program is approved by the approver and the time it is transferred from the system to the production area.

[0015] Before the system instructs forwarding, it could be considered to ensure security by comparing the file size and hash value of the program being forwarded with the file size and hash value stored in the log at the time of development completion or approval. However, if a malicious developer also rewrites the log, it will be difficult for the system to detect such tampering.

[0016] The present invention has been made in view of such problems, and its object is to provide a program distribution management technology that can save manpower by implementing the functions of a librarian in a system while suppressing or eliminating tampering by malicious developers.

[0017] Means used to solve problems

[0018] One embodiment of the present invention relates to a system for managing the release of developed programs into a production environment, the system comprising: multiple servers equipped with a blockchain; a detection unit for detecting events related to program release; and a generation unit for generating a blockchain block containing uniqueness information for guaranteeing the uniqueness of the program upon detection of the event and identification information for identifying the detected event.

[0019] Furthermore, arbitrary combinations of the above-described constituent elements, and substitutions of constituent elements and expressions of the present invention in the form of apparatuses, methods, systems, computer programs, recording media storing computer programs, and the like may also be practiced as additional modes of the present invention.

[0020] Other features and advantages of the present invention will become clear from the following description with reference to the accompanying drawings. In addition, in the accompanying drawings, the same or similar structures are marked with the same reference numerals.

[0021] Effects of the Invention

[0022] According to the present invention, by realizing the functions of business managers who are responsible for the basic work of business workflow, such as librarians, through a system using blockchain, manpower can be saved and tampering by malicious developers can be suppressed or eliminated. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings are incorporated in and constitute a part of this specification, illustrate embodiments of the present invention, and together with the description, serve to explain the principles of the present invention.

[0024] Figure 1 This is a schematic diagram showing the overall configuration of a program management system including the librarian system according to the first embodiment.

[0025] Figure 2 yes Figure 1 The hardware configuration diagram of the internal server.

[0026] Figure 3 Yes Figure 1 A block diagram showing the functions and composition of the internal server.

[0027] Figure 4A Yes Figure 3 This is a data structure diagram of an example of the ledger holding unit.

[0028] Figure 4B Yes Figure 3 This is a data structure diagram of an example of the ledger holding unit.

[0029] Figure 5 Yes Figure 3 A data structure diagram of an example of a user information storage unit.

[0030] Figure 6 Yes Figure 1 A diagram showing the flow of a series of processes in the library administrator system.

[0031] Figure 7This is a representative screen image of the login screen displayed on the monitor of the developer terminal.

[0032] Figure 8 This is a representative screen image of the approval screen.

[0033] Figure 9 This is a representative screen image of the management screen.

[0034] Figure 10 This is a representative screen image of the selection screen provided by the Audit Support Department.

[0035] Figure 11 This is a representative screen image of the release application count confirmation screen.

[0036] Figure 12 This is a representative screen image of the actual application delay count confirmation screen.

[0037] Figure 13 This is a representative screen image of the developer change count confirmation screen.

[0038] Figure 14 This is a schematic diagram showing the effect of labor saving.

[0039] Figure 15 It is a schematic diagram of the monitoring system involved in the second embodiment.

[0040] Figure 16A This is a diagram showing the flow of processing related to proof (the first requirement) that no illegal operations were performed while the server was down.

[0041] Figure 16B This is a diagram showing the flow of processing related to proof (the first requirement) that no illegal operations were performed while the server was down.

[0042] Figure 17 This is a diagram showing an example of transmission timing.

[0043] Figure 18A This is a diagram showing the flow of processing related to ensuring the legitimacy (first requirement) of resolving resource shortages caused by a CPU surge.

[0044] Figure 18B This is a diagram showing the flow of processing related to ensuring the legitimacy (first requirement) of resolving resource shortages caused by a CPU surge.

[0045] Figure 19A This is a diagram showing the flow of processing related to ensuring the validity of reduction after resolving resource shortages caused by CPU surge (the first requirement).

[0046] Figure 19BThis is a diagram showing the flow of processing related to ensuring the validity of reduction after resolving resource shortages caused by CPU surge (the first requirement).

[0047] Figure 20A Yes Figure 15 The data structure diagram of an example of a proof-of-operation ledger.

[0048] Figure 20B Yes Figure 15 The data structure diagram of an example of a proof-of-operation ledger.

[0049] Figure 21A This is a diagram showing the flow of processing related to proof (the second requirement) that the program related to the audit has not been illegally tampered with during operation.

[0050] Figure 21B This is a diagram showing the flow of processing related to proof (the second requirement) that the program related to the audit has not been illegally tampered with during operation.

[0051] Figure 22A Yes Figure 15 The data structure diagram of an example of a legitimacy proof ledger.

[0052] Figure 22B Yes Figure 15 The data structure diagram of an example of a legitimacy proof ledger. DETAILED DESCRIPTION

[0053] Hereinafter, the same or equivalent components, parts, and processes shown in the respective drawings are denoted by the same reference numerals, and repeated descriptions are omitted as appropriate. In addition, a portion of the parts not important for the description is omitted in the respective drawings.

[0054] A distributed ledger technology also known as blockchain is known. Blockchain is a technology that centrally stores data in blocks on nodes and manages the same block information in a distributed manner. Because blocks are linked in a time series, they are called "blockchains."

[0055] Blockchain has the following five main characteristics.

[0056] 1. Information sharing among all employees

[0057] All connected nodes in a blockchain form a mechanism to store the same data. This mechanism involves first deciding which node will append a block when data is added to the blockchain. While the method for determining this depends on the blockchain's design, common approaches include proof of work (PoW), where the decision is based on computing power, and PBFT, where the decision is made by a defined group of administrators. The node that appended the block then sends it to all other nodes. After all nodes verify the block's contents, if there are no issues, each node appends the block. As a result, all nodes store the same data. If there are any issues, the block is discarded, and only the blocks that ultimately prove to be correct are appended. In other words, only verified, correct data is stored as a block.

[0058] 2. No Stoppage (Zero Downtime)

[0059] While conventional systems have a dominant computer, blockchains generally lack a centralized node. However, in some blockchains, there are nodes that play a central role. All nodes are equally connected and have identical functions. Therefore, even if a node fails, as long as the remaining nodes are functioning properly, the entire blockchain will continue processing without interruption.

[0060] 3. Cannot be tampered with

[0061] In the blockchain, blocks are added sequentially in chronological order. Furthermore, if past data is tampered with (changed), the tampering cannot be established without changing all subsequent data. The validity of the interaction is verified by all nodes. Specifically, a mechanism is established whereby a hash value, including information from the previous block, is stored in each block. Even the slightest difference in data results in a completely different hash value, making it impossible to match without tampering with all subsequent blocks. Furthermore, unless 51% or more of the nodes coordinate to carry out the tampering, the tampered data will not be stored as a valid block. This makes tampering virtually impossible.

[0062] 4. Traceability

[0063] In blockchain, data that is recognized as correct and cannot be tampered with (changed) is stored as blocks. Furthermore, data loss is prevented through redundancy. Furthermore, data is stored in chronological order, allowing for retrospective reference, resulting in high traceability.

[0064] 5. Low cost

[0065] No database or cluster products are required, so it can be built at a low cost.

[0066] In light of the aforementioned characteristics of blockchain, the inventors independently discovered that the system used to replace librarians has a high affinity with blockchain. In particular, they discovered that by using blockchain to manage audit records related to the release of developed programs into a production environment, the required higher level of security for this system can be achieved. By retaining audit records on the blockchain, malicious developers cannot tamper with these records. Therefore, even if tampering is performed after approval, the system can easily detect the tampering by referencing the records on the blockchain.

[0067] (First embodiment)

[0068] Figure 1 This diagram schematically illustrates the overall configuration of a program management system 10, including a librarian system 100 according to the first embodiment. The program management system 10 includes the librarian system 100, a developer terminal 12 operated by developers, an approver terminal 14 operated by approvers, a distribution terminal 18 operated by developers, a development machine 20 for storing and managing business programs under development, a proxy server 22, a forwarding server 24, a network-attached storage (NAS) 26, an access monitoring server 28, a firewall 30, a distribution server 32, and a production machine 34 on which developed business programs are installed. The distribution terminal 18 is located in a glass-lined distribution terminal room 49.

[0069] The NAS 26 includes a control unit 36, a development area 38, and an official area 40. The control unit 36 ​​is implemented by the NAS 26 CPU operating according to the operating system and control programs stored in the ROM and RAM. The development area 38 and the official area 40 are composed of a hard disk, volatile memory, or non-volatile memory installed in the NAS 26, and are logically separated by the control unit 36. The development area 38 is connected to a development segment 42 via the control unit 36. Furthermore, the official area 40 is connected to a DMZ (Demilitarized Zone) segment 44 via the control unit 36.

[0070] The librarian system 100 is provided in the librarian segment 41 .

[0071] The developer terminal 12 , the approver terminal 14 , and the development machine 20 are provided in the development section 42 .

[0072] The proxy server 22 , the forwarding server 24 , and the access monitoring server 28 are provided on the DMZ segment 44 .

[0073] The distribution terminal 18 is provided in the official access section 48 .

[0074] The publishing server 32 and the official machine 34 are set on the official segment 51.

[0075] The developer of a business program uses the developer terminal 12 to code the business program and completes unit testing and joint testing on the development machine 20. The developer interacts with the librarian system 100 and saves the target file of the tested business program to the development area 38 of the network-attached storage 26.

[0076] Next, the developer communicates with the librarian system 100 to the approver, such as his / her immediate superior, that the developed business program has been stored in the development-side area 38 of the network-attached storage 26. Upon receiving this information, the approver accesses the network-attached storage 26 from the approver terminal 14 and reads the business program stored in the development-side area 38.

[0077] The approver then checks the contents of the business program to confirm that it functions as per the specifications, has completed the required tests, and does not contain any invalid modules. If the approver determines that there are no issues, he or she communicates approval to the developer through interaction with the librarian system 100.

[0078] Whenever an event such as registration or approval of a business program occurs, the librarian system 100 obtains snapshot data such as the hash value, location, and path of the business program at that time, and manages the obtained data using blockchain.

[0079] The librarian system 100 periodically identifies approved but unmoved business programs at predetermined intervals, such as every five minutes. After confirming that the current hash value of the identified business program matches the hash value of the business program stored in the blockchain, the librarian system 100 delegates the transfer of the business program.

[0080] The librarian system 100 accesses the proxy server 22 and issues a forwarding request instruction. The forwarding request instruction includes the IP address of the librarian system 100, the file name of the business program to be forwarded, and the storage location.

[0081] The proxy server 22 that receives the forwarding request instruction checks that the IP address included in the forwarding request instruction is consistent with the preset IP address of the librarian system 100 , and then forwards the forwarding request instruction to the forwarding server 24 .

[0082] Only the librarian system 100 can authenticate the proxy server 22 , and even if access is made from the approver terminal 14 or the approver terminal 14 , the proxy server 22 determines that authentication is unavailable.

[0083] The forwarding server 24 that has received the forwarding request instruction checks that the IP address included in the forwarding request instruction is consistent with the preset IP address of the proxy server 22 , and then issues the forwarding request instruction to the network-attached storage 26 .

[0084] Upon receiving the forwarding request, the control unit 36 ​​of the NAS 26 verifies that the IP address included in the forwarding request matches the pre-set IP address of the forwarding server 24. It then forwards the corresponding business program from the development area 38 to the production area 40. After the forwarding is complete, a forwarding completion notification is sent in the following sequence: NAS 26 → forwarding server 24 → proxy server 22 → librarian system 100.

[0085] As will be described later, the business program temporarily transferred to the official-side area 40 does not accept any content other than transfer instructions from the distribution server 32, and all access from the developer terminal 12, approver terminal 14, and librarian system 100 is denied by the control unit 36. Therefore, malicious developers cannot incorporate illegal modules into the pre-release business program stored in the official-side area 40.

[0086] The procedure for distributing a business program in the program management system 10 will be described.

[0087] The developer moves to the publishing terminal room 49 and accesses the access monitoring server 28 from the publishing terminal 18 installed there, issuing a publishing request. Upon receiving the publishing request, the access monitoring server 28 verifies that the IP address included in the publishing request matches the pre-set IP address of the publishing terminal 18 and forwards the publishing request to the publishing server 32. The access monitoring server 28 records the data exchange with the publishing terminal 18 in a log file.

[0088] The publishing server 32 that receives the publishing request instruction from the access monitoring server 28 checks that the IP address included in the publishing request instruction is consistent with the preset IP address of the access monitoring server 28 and then sends the forwarding request of the corresponding business program to the network-attached storage 26.

[0089] The control unit 36 ​​of the network-attached storage 26 that receives the program forwarding request checks that the IP address included in the program forwarding request matches the preset IP address of the distribution server 32 , and then calls the corresponding business program from the official side area 40 and forwards it to the distribution server 32 .

[0090] The distribution server 32 that has received the work program transfers the work program to a predetermined directory of the production machine 34. As a result, the distribution of the work program to the production machine 34 is completed. Thereafter, a distribution completion notification is sent from the distribution server 32 to the librarian system 100.

[0091] The filtering function of firewall 30 allows distribution terminal 18 to send distribution request instructions to distribution server 32 only through access monitoring server 28, rather than directly. Furthermore, since access monitoring server 28 records access logs, malicious developers are prevented from distributing illegal programs to official machines 34 via distribution terminal 18.

[0092] The librarian system 100 is a system for managing the release of developed business programs to the production environment, and has multiple (in Figure 1 In the example, there are five servers. The servers may be physical server devices or virtual servers built on physical server devices. Alternatively, at least one of the five servers may be a virtual server, and the remaining five servers may be physically independent servers.

[0093] Four of the five servers (hereinafter referred to as internal servers 102) are managed by the entity that manages program management system 10, while the remaining server (hereinafter referred to as audit server 104) is managed by an auditing entity, such as an auditing entity or an auditor. A firewall 106 is installed between the four internal servers 102 and the auditing server 106. Audits performed by the auditing entity include internal audits. By including the auditing entity in the blockchain, they share the same audit record ledger, allowing them to review historical records at any time. This reduces the burden of audits.

[0094] In the librarian system 100 , the five servers participating in the blockchain are configured to be able to communicate with each other via a network such as the Internet or an intranet. Furthermore, the four internal servers 102 are configured to be able to communicate with the developer terminal 12 and the approver terminal 14 via the network.

[0095] The vault administrator system 100 is a scalable, decentralized, peer-to-peer system capable of generating and maintaining a blockchain. Since the technology used to construct and manage blockchains is well known, it will not be described in detail in this specification (for example, see Patent Document 2). In this embodiment, security is ensured by automating the vault administrator by focusing on the data recorded in the blockchain blocks.

[0096] Figure 2 yes Figure 1The hardware configuration diagram of the internal server 102. The monitoring server 104, the approver terminal 14, the developer terminal 12, the publishing terminal 18, the development machine 20, the proxy server 22, the forwarding server 24, the access monitoring server 28, the publishing server 32, and the official machine 34 can each have Figure 2 The internal server 102 includes a memory 110 , a processor 112 , a communication interface 114 , a display 116 , and an input interface 1118 . These components are connected to a bus 120 and communicate with each other via the bus 120 .

[0097] The memory 110 is a storage area for storing data and programs. Data and programs can be stored permanently or temporarily in the memory 110. The processor 112 implements the various functions of the internal server 102 by executing the programs stored in the memory 110. The communication interface 114 is an interface for sending and receiving data to and from the outside of the internal server 102. The communication interface 114 is connected to the network and exchanges data with other internal servers 102, the monitoring server 104, the approver terminal 14, the developer terminal 12, and the proxy server 22 via the network. The display 116 is a device for displaying various information. The input interface 118 is a device for receiving input from the administrator of this service.

[0098] Figure 3 Yes Figure 1 The block diagram shows the functions and configuration of the internal server 102. The functional blocks shown here can be implemented in hardware using components such as a computer CPU or mechanical devices, and in software using computer programs, etc. However, the functional blocks implemented through the cooperation of these components are depicted here. Therefore, those skilled in the art will understand that these functional blocks can be implemented in various forms through a combination of hardware and software.

[0099] The internal server 102 includes a ledger storage unit 130, a user information storage unit 132, a blockchain function unit 134, and a librarian function unit 136. The blockchain function unit 134 implements blockchain-related functions. It includes an event detection unit 138, a snapshot acquisition unit 140, a block generation unit 142, a display control unit 144, and an audit support unit 146. The librarian function unit 136 implements functions for automating librarian actions. It includes a developer interface unit 148, an approver interface unit 150, a forwarding target determination unit 152, and a forwarding request unit 154.

[0100] Figure 1 The four internal servers 102 shown have Figure 3In other embodiments, only specific (one or more) of the four internal servers 102 have Figure 3 The structure shown in FIG. 1 is the same as that shown in FIG. 1 , and the other internal server 102 has the function of managing the ledger holding unit 130 and the blockchain. Furthermore, in another embodiment, Figure 3 The blockchain function unit 134 and the vault administrator function unit 136 in the illustrated configuration are implemented by the four internal servers 102 in cooperation. That is, in one example, one internal server 102 has the blockchain function unit 134, and the other internal servers 102 have the vault administrator function unit 136. The monitoring server 104 basically has the functions of managing the ledger holding unit 130 and the blockchain, but does not have the vault administrator function unit 136. However, in other embodiments, the monitoring server 104 may have Figure 3 In short, all servers (internal server 102 and audit server 104 ) participating in the blockchain of the librarian system 100 have the same ledger holding unit 130 .

[0101] Figure 4A 、 Figure 4B Yes Figure 3 This diagram shows an example data structure of the ledger storage unit 130. The ledger storage unit 130 stores blockchain blocks. The ledger storage unit 130 stores multiple blocks 302, 304, 306, 308, 310, 312, 314, and 316, arranged in chronological order from the original block (not shown). Block 302 includes a hash value 318 of the previous block and snapshot data 320 of the business program. The other blocks have the same structure.

[0102] The snapshot data 320 of the business program maintains the number that identifies the business program, the name of the business program, the actor (subject) of the detected event, the hash value of the business program when the event is detected, the status flag that identifies the detected event, the time when the business program moves or the event occurs, the location of the business program when the event is detected, and the file path of the business program when the event is detected in a corresponding manner.

[0103] The actor is recorded by their user ID. The location of the business program is set to either "Development," representing the development area 38 of the network-attached storage 26; "DMZ," representing the production area 40 of the network-attached storage 26; or "Production," representing the production machine 34. The business program's hash value is unique information that ensures the uniqueness of the business program when an event is detected. In other embodiments, the size or number of lines of the business program may be used as unique information in addition to or instead of the hash value.

[0104] connect Figure 1 As described above, in the process from business program development to release in program management system 10, the developed business program is transferred from development-side area 38, which is accessible to developers, to production-side area 40, where developer access is restricted or prohibited. The program is then released by being transferred from production-side area 40 to production machine 34 in a production environment. Events are events related to the release of such business programs. In this embodiment, the following four events are defined.

[0105] (1) The developer registers a completed business program. The status flag is "registration completed." This is hereinafter referred to as a registration event.

[0106] (2) Approval of a business program that has been developed and is stored in the development area 38 by an approver. The status flag is "approved." This is hereinafter referred to as an approval event.

[0107] (3) The business program is automatically transferred from the development area 38 to the production area 40 by the librarian function unit 136. The status flag is "Move Completed." This is hereinafter referred to as a transfer event.

[0108] (4) The developer transfers the business program from the production-side area 40 to the production machine 34. The status flag is "released." This is hereinafter referred to as a release event.

[0109] Regarding login events, Figure 4A The block 302 includes snapshot data 320 when the developer (NRI_001) logs in the created business program (KAIKEI_01) on a login screen described later.

[0110] Regarding approval events, Figure 4A The block 308 includes snapshot data 322 when the approver (NRI_011) approves the same business program (KAIKEI_01) on the approval screen described later, upon request from the developer.

[0111] Regarding forwarding events, Figure 4B The block 312 in includes snapshot data 324 when the librarian function unit 136 finds the same business program (KAIKEI_01) with a status flag = "approved" and moves it to the official side area 40 (DMZ).

[0112] Regarding publishing events, Figure 4B The block 316 includes snapshot data 326 when the developer (NRI_001) deploys (moves) the same business program (KAIKEI_01) to the production machine 34.

[0113] Figure 5 Yes Figure 3 The data structure diagram of the user information storage unit 132 is an example. The user information storage unit 132 stores, in a suggested association, the user ID, user name, user email address, and user position that identify users in the program management system 10. In this embodiment, the position is any one of developer, approver, and librarian (system).

[0114] exist Figure 5 In the embodiment, each block contains one snapshot data, but in other embodiments, a block can contain multiple snapshot data. For example, if multiple business programs are forwarded every five minutes, the snapshot data of the multiple business programs can be saved together in one block.

[0115] Back to Figure 3 The event detection unit 138 detects an event. The event detection unit 138 detects an event based on an event notification provided by the librarian function unit 136 when the event occurs. Alternatively, the event detection unit 138 may detect the occurrence of an event by monitoring the librarian function unit 136.

[0116] When the event detection unit 138 detects an event, the snapshot acquisition unit 140 acquires snapshot data of the business program that is the subject of the event when the event is detected. For example, the event notification can be constructed in a manner that includes all data items contained in the snapshot data. In this case, the snapshot acquisition unit 140 obtains the snapshot data with reference to the event notification. Alternatively, the event notification may at least include the number of the business program that is the subject of the event and the type of event. In this case, the snapshot acquisition unit 140 obtains the missing elements from the various components of the program management system 10. For example, in a case where the event notification does not include the hash value of the business program, the snapshot acquisition unit 140 calculates the hash value of the business program. Alternatively, for example, in a case where the event notification includes the name of the actor, the snapshot acquisition unit 140 can determine the actor's user ID by referring to the user information retention unit 132.

[0117] The block generation unit 142 generates a block in the blockchain that contains the snapshot data acquired by the snapshot acquisition unit 140. Following the prescribed blockchain protocol, the block generation unit 142 appends the block containing the acquired snapshot data to the ledger storage unit 130 and requests other servers participating in the blockchain to append the same block. Generating or appending a new block to the blockchain can be accomplished using, for example, the known blockchain technology described in Patent Document 2.

[0118] The functions of the display control unit 144 and the monitoring support unit 146 will be described later with reference to representative screen diagrams.

[0119] The developer interface unit 148 functions as an interface with the developer terminal 12. The developer interface unit 148 provides the developer terminal 12 with a login screen (described later) and accepts business program logins from developers through input into this screen. Upon accepting a login, the developer interface unit 148 generates an event notification indicating the occurrence of a login event and transmits it to the event detection unit 138. The developer interface unit 148 can confirm that the person operating the developer terminal 12 is a developer by referencing the user information storage unit 132.

[0120] The approver interface 150 functions as an interface with the approver terminal 14. The approver interface 150 provides the approver terminal 14 with an approval screen (described later) and accepts approval of the business program from the approver through input into this screen. Upon accepting approval, the approver interface 150 generates an event notification indicating the occurrence of an approval event and transmits it to the event detection unit 138. The approver interface 150 can verify that the person operating the approver terminal 14 is the approver by referencing the user information storage unit 132.

[0121] The forwarding object determination unit 152 determines the business programs that have been approved but not moved periodically, for example, at a specified time interval such as once every five minutes, by referring to the status flag contained in the block maintained in the ledger maintenance unit 130. The forwarding object determination unit 152 refers to the ledger maintenance unit 130 to determine the business programs whose latest status flag is "approved". For each determined business program, the forwarding object determination unit 152 uses the file path to access the business program and calculates its hash value. The forwarding object determination unit 152 compares the calculated hash value, i.e., the current hash value of the determined business program, with the latest hash value of the business program stored in the ledger maintenance unit 130. If they are consistent, the business program is determined as the forwarding object. If they are different, the business program is not determined and the prescribed warning processing is performed.

[0122] The forwarding request unit 154 automatically generates an instruction for forwarding or moving the business program identified as a forwarding target by the forwarding target identification unit 152 from the development area 38 to the production area 40. The forwarding request unit 154 sends the generated instruction to the proxy server 22 to request the forwarding of the business program.

[0123] The operation of the librarian system 100 based on the above configuration will be described.

[0124] Figure 6 Yes Figure 1FIGURE 1 illustrates a flow chart of a series of processes in the librarian system 100. The librarian function unit 136 receives a business program login request from a developer via the developer terminal 12 (S602). The librarian function unit 136 generates an event notification indicating the occurrence of a login event and sends it to the blockchain function unit 134 (S604). The blockchain function unit 134 receives the event notification of step S604 and detects the business program login event (S606). The blockchain function unit 134 appends a block containing the snapshot data to the blockchain (S608).

[0125] The librarian function unit 136 receives approval of the business program from the approver via the approver terminal 14 (S610). The librarian function unit 136 generates an event notification indicating the occurrence of the approval event and sends it to the blockchain function unit 134 (S612). The blockchain function unit 134 receives the event notification from step S612 and detects the approval event for the business program (S614). The blockchain function unit 134 appends the block containing the snapshot data to the blockchain (S616).

[0126] The librarian function unit 136 forwards the approved business program from the development segment to the DMZ segment at specified intervals (S618). Upon completion of the forwarding process, the librarian function unit 136 generates an event notification indicating the occurrence of the forwarding event and sends it to the blockchain function unit 134 (S620). The blockchain function unit 134 receives the event notification from step S620 and detects the forwarding event for the business program (S622). The blockchain function unit 134 appends the block containing the snapshot data to the blockchain (S624).

[0127] The librarian function unit 136 receives a release completion notification from the publishing server 32 indicating that the business program has been released (S626). The librarian function unit 136 generates an event notification indicating the occurrence of the release event and sends it to the blockchain function unit 134 (S628). The blockchain function unit 134 receives the event notification from step S628 and detects the business program release event (S630). The blockchain function unit 134 appends the block containing the snapshot data to the blockchain (S632).

[0128] Figure 7 1 is a representative screen image of the login screen 500 displayed on the display of the developer terminal 12. Figure 6In step S602, the developer interface unit 148 of the library administrator function unit 136 generates screen information of the login screen 500 and sends it to the developer terminal 12. The developer terminal 12 displays the login screen 500 on the display based on the received screen information. The developer enters the number, name and file path of the business program in the input field 502 of the login screen 500, and presses the login button 504. The developer interface unit 148 receives the information entered into the input field 502. The developer interface unit 148 determines the user who logs into the developer terminal 12 when the login screen 500 is displayed as the actor. The developer interface unit 148 accesses the business program according to the file path of the received business program and calculates its hash value. The developer interface unit 148 selects "Login completed" as the status flag. The developer interface unit 148 determines the moment when the login button 504 is pressed as the moment when the login event occurs. The developer interface unit 148 generates an event notification containing this information, and as shown in FIG. Figure 6 It is sent to the blockchain function unit 134 as in step S604.

[0129] The approver interface unit 150 generates an approval screen 506 requesting approval for the registered business program and sends the URL to the developer via email. The developer requests approval from the approver based on the received URL. When the approver clicks the URL on the approver terminal 14, the approval screen 506 is displayed on the approver terminal 14's display.

[0130] Figure 8 It is a representative screen diagram of the approval screen 506. Based on the information displayed in the approval screen 506, the approver requests the developer to provide the source code, specification sheet, etc. of the business program to confirm the legality of the business program. When the confirmation is completed, the approver presses the approval button 508 of the approval screen 506. When the approver interface unit 150 detects the pressing of the approval button 508, it determines the user who logged into the approver terminal 14 when the approval screen 506 is displayed as the actor. The approver interface unit 150 accesses the business program according to the file path of the business program displayed in the approval screen 506 and calculates its hash value. The approver interface unit 150 selects "approval completed" as the status flag. The approver interface unit 150 determines the moment when the approval button 508 is pressed as the moment when the approval event occurs. The approver interface unit 150 generates an event notification containing this information, and as Figure 6 It is sent to the blockchain function unit 134 as in step S612.

[0131] The display control unit 144 of the blockchain function unit 134 receives a request to display the management screen 510 from the developer terminal 12, the approver terminal 14, or any server in the library administrator system 100. Upon receiving this request, the display control unit 144 generates a management screen 510 that associates an event occurring for a specified business program with a hash value at the time the event was detected, by referring to the block stored in the ledger storage unit 130, and causes the generated management screen 510 to be displayed on the display.

[0132] Figure 9 This is a representative screen image of the management screen 510. The management screen 510 has a program identification information display area 512 that displays the number and name of the business program, and a status display area 514 that displays the status of the business program. In the status display area 514, whether the event is detected, the time when the event is detected, the actor, and the hash value of the business program when the event is detected are displayed for each event. Figure 9 In the example of , since the hash value when the approval event is detected is different from the hash value when the forwarding event is detected, it can be detected that the business program has been rewritten during the period from the completion of approval to the occurrence of forwarding.

[0133] In the audit, for a certain business process, it is an important audit indicator that there are no omissions in the process of logging in, approving, forwarding, and publishing. In the library administrator system 100, due to the traceability of the blockchain, it is possible to provide Figure 9 Furthermore, when the audit server 104 is included in the librarian system 100, the audit can be performed efficiently even if the auditor does not visit the enterprise (the entity that manages the program management system 10). Figure 9 Since the management screen 510 shown is displayed on the display of the terminal itself, further efficiency can be achieved.

[0134] As described above, the library administrator system 100, which includes the audit server 104, eliminates the need for auditors to visit the audited company, thereby reducing the audit burden. Furthermore, the audit support unit 146 generates various screens displaying statistical information related to the release of business programs by referencing the blocks stored in the ledger storage unit 130 and displays these on the monitor of the audit server 104, thereby enabling more efficient and effective audits.

[0135] Traditionally, audits have often involved a scramble to verify whether internal control is maintained across tens of thousands of audited processes. However, this approach makes it difficult to maintain a high level of accuracy in verifying whether control is maintained. In the case of internal control, the following business processes (or modules) may have control issues.

[0136] ・When there are an extremely large number of applications from the same developer within a certain period of time.

[0137] ・The official application tends to stagnate (for example, it does not run even after more than a week, or the application is resubmitted before the official launch).

[0138] · Even if it is the same business process, the developer is changed frequently within a certain period of time.

[0139] In the librarian system 100, by utilizing blockchain traceability, it is possible to record these characteristics as statistical figures. Specifically, the audit support unit 146 accumulates these statistical figures for each business process every other day. This accumulation is performed for a full year. This is because audits are conducted annually. During audits, the audit support unit 146 displays an auxiliary screen containing this information on the auditor's PC, ensuring a consistent level of accuracy in confirming whether unified management is guaranteed.

[0140] Figure 10 This is a representative screen image of a selection screen 516 provided by the audit support unit 146. The selection screen 516 is a screen for the auditor to select a displayed auxiliary screen and includes a release application count confirmation button 518, a formal application delay count confirmation button 520, and a developer change count confirmation button 522.

[0141] When the issuance application count confirmation button 518 is pressed on the selection screen 516 , the audit support unit 146 causes the monitor of the auditor's PC to display the issuance application count confirmation screen 524 . Figure 11 This is a representative screen diagram of the issuance application count confirmation screen 524 .

[0142] When the official application delay count confirmation button 520 is pressed on the selection screen 516 , the inspection support unit 146 causes the official application delay count confirmation screen 526 to be displayed on the monitor of the inspector's PC. Figure 12 This is a representative screen image of the actual application delay count confirmation screen 526 .

[0143] When the developer change count confirmation button 522 is pressed on the selection screen 516 , the audit support unit 146 causes the monitor of the auditor's PC to display a developer change count confirmation screen 528 . Figure 13 This is a representative screen image of the developer change count confirmation screen 528 .

[0144] In the above-mentioned embodiment, examples of the storage unit are a hard disk and a semiconductor memory. In addition, based on the description of this specification, those skilled in the art who have access to this specification should understand that each unit can be implemented by a CPU (not shown), a module of an installed application program, a module of a system program, a semiconductor memory for temporarily storing the content of data read from the hard disk, etc.

[0145] According to the librarian system 100 of this embodiment, the librarian function unit 136 automatically performs tasks previously performed manually by librarians, thereby reducing labor costs. Furthermore, to ensure security, the use of blockchain to manage snapshot data generated for each event provides evidence that is both tamper-proof and traceable. Furthermore, by allowing auditors to participate in the blockchain, auditing becomes more efficient.

[0146] Figure 14 Schematic diagram showing the effect of saving manpower. Figure 14 As shown on the left side of the figure, a relatively large library administrator organization is required. In contrast, when the library administrator system 100 according to this embodiment is adopted, the administrator of the library administrator system 100 only needs one person ( Figure 14 ), the library administrator system 100 then automatically handles the duties of the library administrator, ensures security, responds to auditors, etc.

[0147] In the first embodiment, we described how the librarian system 100 acquires snapshot data of business programs for each event and converts the snapshot data flow into a blockchain. This technical concept can be applied to program distribution management systems compliant with J-SOX regulations, and furthermore, to the overall transaction processing based on business workflows.

[0148] (Second embodiment)

[0149] In the first embodiment, the use of blockchain traceability to improve the efficiency of audit responses was described. In the second embodiment, the implementation of a function to ensure the integrity of the audit system was described.

[0150] The librarian system 100 of the first embodiment can also be called an audit system. The following two elements are important elements for systematizing the audit.

[0151] First requirement: Proof that no illegal operations were performed while the server was down

[0152] When a server is down due to a failure, it is necessary to prove whether any illegal operations were performed during the recovery process. Conventionally, guarantees based on organizational control have been adopted, such as setting the operator as a third-party organization with no vested interests.

[0153] Second requirement: Proof that the audit-related programs have not been illegally tampered with during operation

[0154] It is necessary to prove whether the program being audited has been illegally modified during operation. In the past, the program code was printed out regularly and verified during the audit.

[0155] Conventionally, proof of meeting these two requirements has typically been obtained through written submission, which is labor-intensive. Therefore, in this embodiment, a blockchain-based monitoring system records its own normal operation records in its own blockchain ledger, thereby proving these two requirements. In other words, proof is provided using a blockchain whose normal operation records cannot be tampered with.

[0156] Figure 15 This is a schematic diagram of the monitoring system 800 involved in the second embodiment. The monitoring system 800 is a system that performs monitoring such as the monitoring of the release of the business program described in the first embodiment and manages its records. The monitoring system 800 has multiple (in Figure 15 In the example, there are five) servers 802, 804, 806, 808, and 810.

[0157] In the second embodiment, the fact that multiple ledgers can be managed in the blockchain is utilized. The monitoring system 800 has three ledgers that are managed according to the blockchain protocol. The three ledgers are composed of (1) a ledger of monitoring records as the main ledger (called the monitoring ledger 812), (2) a ledger of operation certification records of the server (called the operation certification ledger 814), and (3) a ledger of legality certification records of monitoring related programs (called the legality certification ledger 816). The monitoring ledger 812 is, for example, a ledger for maintaining information based on the J-SOX law, and can correspond to the ledger maintenance unit 130 of the first embodiment. The operation certification ledger 814 maintains normal operation certification information of the monitoring system 800 itself. The legality certification ledger 816 maintains non-tampering certification information of the main functions.

[0158] The monitoring system 800 is composed of multiple virtual servers built on a single server device. That is, multiple servers 802, 804, 806, 808, and 810 are virtual servers. In the monitoring system 800, as described later, majority decision among servers is used, so the number of virtual servers participating in the blockchain of the monitoring system 800 is set to an odd number of at least three. Figure 15In the example, there are five. Server virtualization is a well-known technology that abstracts and pools computer resources (CPU, memory, network interface, recording device, etc.) to enable multiple virtual servers to operate on a single physical server. The virtual servers of monitoring system 800 are implemented using this well-known server virtualization technology.

[0159] In server virtualization, a hypervisor manages and abstracts physical resources. Virtual resources are allocated to each operating system in a virtual server. Consequently, virtual servers can be deleted or duplicated through relatively simple software operations.

[0160] Figure 16A 、 Figure 16B This diagram illustrates the process flow related to proving that no illegal operations were performed while the server was down (the first requirement). Server 810 of monitoring system 800 verifies the existence of other servers 802, 804, 806, and 808 at a predetermined transmission timing (step 1). Specific examples of transmission timing will be described later. "Transmission" refers to sending information to multiple servers substantially simultaneously or sequentially.

[0161] If all other servers 802, 804, 806, and 808 respond normally, the server 810 that confirmed the source will hand over the process to the next server 802. The next server 802 will then perform the life and death verification in step 1. This life and death verification process continues in this manner for a week. At the end of that cycle, if all life and death verifications are normal, the monitoring system 800 will record the normality of the monitoring system 800 in the operation verification ledger 814 and move on to the next cycle.

[0162] When there is a server 804 that does not respond to the life and death confirmation in step one, or when there is no reply after waiting for a specified time (for example, three seconds), the server 810 that confirmed the source stops the life and death monitoring program and sends a server recovery delegation to the other servers 802, 804, 806, 808 except the server 804 that did not respond (step two).

[0163] After receiving the server recovery request sent in step 2, server 802 confirms the existence of servers 804, 806, 808, and 810 other than itself (step 3). If all servers 804, 806, 808, and 810 respond to the confirmation (if no server has failed to respond), server 802 returns or sends a recovery denial to the requesting server 810. If a server 804 has failed to respond to the confirmation, server 802 returns a recovery approval and the server name of the unresponsive server 804 to the requesting server 810. "Return" can also be referred to as "send" or "send."

[0164] The requesting server 810 counts the responses from the requesting servers 802, 806, and 808 (step 4). This count targets only the server 804 that the requesting server 810 has found to be suspected of being faulty (unresponsive). If the result of the count is a majority rejection, the requesting server 810 suspends the recovery operation, treating it as a false positive, and restarts the life and death monitoring process. If the result of the count is a majority approval, the requesting server 810 begins the recovery operation.

[0165] Follow the steps below to perform the recovery operation in step 5.

[0166] (1) The requesting server 810 disconnects and deletes the server 804 identified as being at risk from the blockchain. The requesting server 810 adds a block containing the disconnection time, the number of servers, the disconnected server name, the reason (= disconnection due to failure), and the status (= abnormality) to the operation proof ledger 814.

[0167] (2) The server 810 that is the source of the request creates a copy of its own (server 810 ) virtual machine, and sets the server name of the created server 818 to the server name of the deleted server 804 .

[0168] (3) When the server replication is complete, the server 810 of the client causes the generated server 818 to join the blockchain network. The server 810 of the client adds a block containing the restoration time, the number of servers, the name of the generated server (= the name of the disconnected server), the reason (= restoration completed), and the status (= abnormal) to the operation proof ledger 814.

[0169] (4) The server 810 of the request source restarts the life and death monitoring program from the time closest to the current time.

[0170] Figure 17This diagram shows an example of transmission timing. The number of cycles repeated per minute varies depending on the number of servers. For example, with three servers, three cycles occur per minute, but with seven servers, only one cycle occurs per minute.

[0171] Figure 18A 、 Figure 18B It is a diagram showing the process flow related to the legality guarantee (first requirement) of eliminating resource shortages caused by CPU surge. The server 810 of the monitoring system 800 confirms the utilization of its own CPU and memory per second (step one). The other servers 802, 804, 806, and 808 also perform the same confirmation. In all servers 802, 804, 806, 808, and 810, when the CPU utilization is less than the threshold value, that is, less than 90%, and the memory utilization is less than 90%, the monitoring system 800 records the normality of the monitoring system 800 in the operation certification ledger 814 at the end of the one-minute cycle, and transfers to the next cycle, thereby continuing to repeat the confirmation.

[0172] If at least one of the CPU utilization and memory utilization of server 810 remains above 90% for two minutes, server 810 stops the life and death monitoring program and the resource monitoring program. Server 810 transmits a resource enhancement request to other servers 802, 804, 806, and 808 (step 2).

[0173] The servers 802, 804, 806, and 808 that receive the resource enhancement request in step 2 check the CPU and memory utilization of the requesting server 810 (step 3). If the result of the confirmation shows that both the CPU and memory utilization are less than 90%, the requesting servers 802, 804, 806, and 808 return a rejection of the resource enhancement operation to the requesting server 810. If the result of the confirmation shows that at least one of the CPU and memory utilization is greater than 90%, the requesting servers 802, 804, 806, and 808 return a resource enhancement approval to the requesting server 810.

[0174] The requesting server 810 counts the responses from the requesting servers 802, 806, and 808 (step 4). If the result of the count is a majority rejection, the requesting server 810 aborts the release enhancement process, treating it as a false positive, and restarts the life and death monitoring and resource monitoring processes. If the result of the count is a majority approval, the requesting server 810 restarts the resource enhancement process.

[0175] Follow the process below to perform the resource enhancement operation in step 5.

[0176] (1) The client server 810 obtains the current number of servers from the operation certificate record 814. If the number of servers has not reached the maximum number of eleven, the client server 810 determines to increase the number of servers by two at a time. Furthermore, the maximum number of eleven servers may be variable based on the performance of the physical server devices, the estimated number of increases, and the like.

[0177] (2) The requesting server 810 creates two virtual servers 820 and 822 by replicating itself. Here, consecutive numbers are assigned to the server names. Since the audit system 800 uses a majority decision system, an odd number of servers is maintained to ensure majority decision-making.

[0178] (3) When the server replication is complete, the client server 810 adds the two servers 820 and 822 generated to the blockchain network. The client server 810 adds a block containing the time of the replication, the number of servers after the replication, the name of the generated server, the reason (=node addition), and the status (=abnormal) to the operation proof ledger 814.

[0179] (4) The server 810 of the request source restarts the life and death monitoring program and the resource monitoring program from the time closest to the current time.

[0180] Figure 19A 、 Figure 19B It is a diagram showing the process flow related to the legality guarantee of the reduction after the elimination of the resource shortage caused by the CPU surge (the first requirement). The server 810 of the monitoring system 800 confirms the utilization of its own CPU and memory per second (step one). The other servers 802, 804, 806, and 808 also perform the same confirmation. In all servers 802, 804, 806, 808, and 810, when the CPU utilization is greater than 5% and less than 90% and the memory utilization is greater than 5% and less than 90% for one minute, the monitoring system 800 records the normality of the monitoring system 800 in the operation certification ledger 814 at the end of the one-minute cycle, and transfers to the next cycle, thereby continuing to repeat the confirmation.

[0181] If at least one of the CPU utilization and memory utilization of server 810 remains below 5% for two minutes, and if the number of servers is five or more, server 810 stops the life and death monitoring program and the resource monitoring program. Server 810 transmits a resource reduction request to other servers 802, 804, 806, and 808 (step 2).

[0182] Upon receiving the resource reduction request in step 2, the servers 802, 804, 806, and 808 check the CPU and memory utilization of the requesting server 810 (step 3). If the CPU and memory utilizations are both greater than 5% and less than 90%, the requesting servers 802, 804, 806, and 808 return a rejection of the resource reduction operation to the requesting server 810. If the CPU and memory utilizations are less than 5%, the requesting servers 802, 804, 806, and 808 return a resource reduction approval to the requesting server 810.

[0183] The requesting server 810 counts the responses from the requesting servers 802, 806, and 808 (step 4). If the result of the count is a majority rejection, the requesting server 810 suspends the resource reduction operation, treating it as a false positive, and restarts the life and death monitoring program and the resource monitoring program. If the result of the count is a majority approval, the requesting server 810 restarts the resource reduction operation.

[0184] Follow the process below to perform the resource reduction operation in step 5.

[0185] (1) The server 810 of the request source obtains the current number of constituent servers from the operation certification record 814. If the number of constituent servers has not reached the minimum number of three, the server 810 of the request source decides to delete two servers at a time.

[0186] (2) The requesting server 810 identifies two servers to be deleted, starting with the server with the largest server name number, and deletes the identified servers 804 and 806. Since the audit system 800 uses a majority decision method, the total number of servers is maintained to be an odd number in order to ensure majority decision.

[0187] (3) When the server is deleted, the server 810 of the entrusting source will add a block containing the deletion time, the number of servers after deletion, the name of the deleted server, the reason (=node deletion), and the status (=abnormal) to the operation proof ledger 814.

[0188] (4) The server 810 of the request source restarts the life and death monitoring program and the resource monitoring program from the time closest to the current time.

[0189] Figure 20A 、 Figure 20B Yes Figure 15This diagram shows an example data structure of an operation proof ledger 814. Operation proof ledger 814 stores blockchain blocks. Operation proof ledger 814 stores multiple blocks 830, 832, 834, 836, and 838, arranged in chronological order from the original block (not shown). Block 830 includes a hash value 840 of the previous block and operation data 842 indicating the operating status of monitoring system 800. Other blocks have the same structure.

[0190] Figure 21A 、 Figure 21B It is a diagram showing the process of processing related to the proof that the program related to the monitoring has not been illegally tampered with during operation (the second requirement). The server 810 of the monitoring system 800 requests other servers 802, 804, 806, and 808 to compare and confirm the number of lines and file size (number of bytes) of the monitoring-related program every second (step one). In addition, either the number of lines or the file size can be used, or the hash value of the monitoring-related program can be used instead or on this basis. When the state in which there is no difference in the number of lines and file size of the monitoring-related program continues for one minute, the monitoring system 800 records the normality of the monitoring-related program in the legality proof ledger 816 at the end of the one-minute cycle, and transfers it to the next cycle, thereby continuing to repeat the confirmation.

[0191] If there are discrepancies (here, since the absence of a response is resolved through the aforementioned fault handling / resource excess or shortage handling, it is not assumed that there will be no response), server 810 verifies the number of lines and file size of the monitoring-related programs sent back from other servers 802, 804, 806, and 808. Server 810 compares the number of lines and file size of its own monitoring-related programs with the number of lines and file size of the monitoring-related programs of the other servers and identifies server 804, which has the monitoring-related program with the discrepancy, as a server with a potential for tampering. Server 810 transmits a program tampering response request to the other servers 802, 804, 806, and 808, excluding server 804, which has a potential for tampering. Server 810 stops the life and death monitoring program, resource monitoring program, and tampering monitoring program (step 2).

[0192] Upon receiving the program tampering response request from step 2, server 802 requests the other servers 804, 806, 808, and 810 to monitor the number of lines in the relevant program and compare and confirm the file size (step 3). If no server is found to have potentially tampered, server 802 returns a denial of the program tampering response to the requesting server 810. If a server is found to have potentially tampered, server 802 returns a approval of the program tampering response and the name of the server found to the requesting server 810.

[0193] The requesting server 810 collects statistics on the responses from the requesting servers 802, 806, and 808 (step 4). The statistics are collected only on the server 804 that the requesting server 810 has discovered to be potentially tampered. If the statistical result is a rejection by a majority decision, the requesting server 810 suspends the program tampering response process, treating it as a false detection, and restarts the life and death monitoring program, resource monitoring program, and tampering monitoring program. If the statistical result is a approval by a majority decision, the requesting server 810 resumes the program tampering response process.

[0194] Follow the process below to handle program tampering in step 5.

[0195] (1) The requesting server 810 disconnects and deletes the server 804 identified as potentially tampered with from the blockchain. The requesting server 810 adds a block containing the disconnection time, the number of servers, the disconnected server name, the reason (= tampering detected), and the status (= abnormality) to the legitimacy proof ledger 816.

[0196] (2) The server 810 that is the source of the request creates a copy of its own (server 810 ) virtual machine, and sets the server name of the created server 844 to the server name of the deleted server 804 .

[0197] (3) When the server replication is complete, the requesting server 810 joins the generated server 844 to the blockchain network. The requesting server 810 adds a block containing the restoration time, the number of servers, the name of the generated server (= the name of the disconnected server), the reason (= restoration completed), and the status (= abnormal) to the legitimacy proof ledger 816.

[0198] (4) The server 810 of the request source restarts the life and death monitoring program, the resource monitoring program, and the tampering monitoring program from the time closest to the current time.

[0199] Figure 22A 、 Figure 22B Yes Figure 15This diagram shows an example data structure of a legitimacy proof ledger 816. The legitimacy proof ledger 816 stores blockchain blocks. The legitimacy proof ledger 816 stores multiple blocks 846, 848, 850, and 852, arranged in chronological order from the original block (not shown). Block 846 includes a hash value 854 of the previous block and status data 856 indicating the status of the audit-related program. The other blocks have the same structure.

[0200] According to the monitoring system 800 of this embodiment, in addition to the monitoring ledger 812, there is also an operation verification ledger 814 and a legality verification ledger 816. This allows verification of the normal operation of the system and the legality of the monitoring-related programs to be performed using a blockchain that cannot be tampered with. Furthermore, by including the auditor's server in the blockchain, the operation verification ledger 814 and the legality verification ledger 816 can be shared with the auditor. This allows the auditor to refer to the operation verification ledger 814 and the legality verification ledger 816 at any time, thereby improving the efficiency of the monitoring process.

[0201] While the configuration and operation of the system according to the embodiments have been described above, those skilled in the art will appreciate that these embodiments are merely examples and that various modifications of the combinations of components and processes are possible, and that such modifications are also within the scope of the present invention.

[0202] In the first embodiment, the hash value of the business program is checked when it is moved from the development side area 38 to the official side area 40. However, the present invention is not limited to this. For example, the hash value may be checked when the approval screen is generated, or after the release is completed.

[0203] In the first embodiment, a case where a business program is developed and distributed has been described, but the present invention is not limited thereto, and the program may be any program or a module of a program.

[0204] In the first and second embodiments, a blockchain of a type in which a block maintains a hash value of a previous block is described, but the present invention is not limited thereto, and other types of blockchains such as a type in which a block maintains a hash value of a portion of a previous block may also be used.

[0205] In the second embodiment, the case of proving the operation of the monitoring system 800 and proving the legitimacy of the monitoring-related procedures through blockchain is described, but it is not limited to this. The technical concept involved in the second embodiment can also be applied to any system using blockchain, such as a (virtual) cryptocurrency system or traceability system using blockchain, a system that manages the overall business workflow of transaction processing through blockchain, etc.

[0206] The technical concept of the second embodiment can be incorporated into the librarian system 100 of the first embodiment. In this variation, the librarian system 100 further includes a ledger corresponding to the operation certification ledger 814 and a ledger corresponding to the legality certification ledger 816 in addition to the ledger holding unit 130 .

[0207] The present invention is not limited to the above-described embodiments, and various changes and modifications can be made without departing from the spirit and scope of the present invention. Therefore, in order to disclose the scope of the present invention, the following claims are attached.

[0208] This application claims priority based on Japanese patent application No. 2019-112105, filed on June 17, 2019, the entire contents of which are incorporated herein by reference.

Claims

1. A system for managing the release of developed programs to a production environment, characterized in that: The system has: Multiple servers with blockchain installed; a detection unit for detecting events related to program release, wherein a developed program is released by being transferred from a first storage area accessible to a developer to a second storage area with restricted access, and further from the second storage area to a third storage area in a production environment, the detected events including approval of a program held in the first storage area, automatic movement of a program from the first storage area to the second storage area, and movement of a program from the second storage area to the third storage area; a generation unit for generating a block of a blockchain, the block of the blockchain including uniqueness information for ensuring uniqueness of a program when an event is detected and confirmation information for confirming the detected event; a determination unit for determining a program that was approved but not moved by referring to determination information included in a block of the blockchain; as well as A moving unit automatically moves a specific program from the first storage area to the second storage area.

2. The system according to claim 1, wherein: The blockchain block also contains information that identifies the subject of the event, the time when the event occurred, the location of the program when the event was detected, and the path of the program when the event was detected. The location of the program is any one of the first storage area, the second storage area, or the third storage area.

3. The system according to claim 1, wherein: In the case where the determination information is determination information for determining the approval of a program maintained in the first storage area, the determination unit compares the uniqueness information of the program contained in the block of the blockchain with the current uniqueness information of the program, and determines the program if they are consistent; and does not determine the program and performs warning processing if they are different.

4. The system according to any one of claims 1 to 3, characterized in that The system further includes a display unit that generates a screen that associates an event occurring for a predetermined program with unique information when the event is detected, by referring to a block of the blockchain, and causes the display to display the generated screen.

5. The system according to any one of claims 1 to 3, characterized in that The plurality of servers include a server of an audit entity, The system further includes a display unit that generates a screen displaying statistical information related to program distribution by referring to a block of the blockchain and causes the display of the server of the monitoring body to display the screen.

Images