JP5955165B2 - Management apparatus, management method, and management program - Google Patents

Description

  The present invention relates to a management device, a management method, and a management program.

  A monitoring system that monitors the maintenance and operation of a customer system notifies the maintenance center of incidental information such as messages and log information in addition to the content of the failure when a failure occurs in the customer system. The maintenance center attempts to resolve the failure early by troubleshooting the failure content based on the incidental information.

  In the maintenance center, for example, a white list in which a normal system configuration guaranteed by the manufacturer is registered at the timing of hardware shipment, software commercialization, etc., for example, a fault system known by the manufacturer The blacklist that registered the configuration is managed. Then, the maintenance center refers to the white list or black list, and determines the presence or absence of a failure by comparing with the system configuration collected from the customer system.

Special Table 2007-506187 JP 2008-293033 A JP 2008-135004 A Japanese translation of PCT publication No. 2004-513212

  However, the amount of data such as the system configuration and failure contents of each customer system is enormous, and in the first place, failure cases also vary from day to day depending on the number of occurrences of failure and the passage of time. For example, there are many cases that do not exist in the white list or black list, and it is difficult to dynamically change the contents of the list according to changes in the number of occurrences of the cases and the passage of time.

  In one aspect, an object of the present invention is to provide a management device, a management method, and a management program that can dynamically change the contents of a list according to changes in the number of cases and the passage of time.

  One management apparatus includes a receiving unit that periodically receives configuration information of an electronic device, and a storage unit that stores the configuration information in association with time information. Furthermore, the management device has a first list that stores configuration information indicating the first state, and a second list that stores configuration information indicating a second state that is not the first state. Furthermore, the management apparatus stores a third list for storing configuration information indicating a third state, which is unknown whether the first state or the second state, and the first list for each configuration information. And a case list for storing the number of occurrences of cases indicating the state of. Further, the management device can determine whether the first list and the second list are based on the configuration information and time information stored in the storage unit, and the configuration information and occurrence count stored in the case list. And an update unit that moves the configuration information and updates the list between the second list and the third list, or between the third list and the first list.

  In the disclosed aspect, the contents of the list can be dynamically changed according to changes in the number of cases and the passage of time.

FIG. 1 is an explanatory diagram illustrating an example of the monitoring system according to the embodiment. FIG. 2 is an explanatory diagram illustrating an example of the configuration information. FIG. 3 is an explanatory diagram schematically showing an example of a table configuration of a big DB. FIG. 4 is an explanatory diagram illustrating an example of a table configuration of the storage DB. FIG. 5 is an explanatory diagram illustrating an example of a failure determination process executed by the CPU in the server. FIG. 6 is an explanatory diagram showing an example of a list update process executed by the CPU in the server. FIG. 7 is a flowchart illustrating an example of the processing operation of the CPU in the server related to the configuration change check process. FIG. 8 is a flowchart illustrating an example of the processing operation of the CPU in the server involved in the failure determination process. FIG. 9 is a flowchart illustrating an example of the processing operation of the CPU in the server involved in the unknown list determination process. FIG. 10 is a flowchart showing an example of the processing operation of the CPU in the server related to the yellow list determination process. FIG. 11 is a flowchart illustrating an example of the processing operation of the CPU in the server related to the verified list determination process. FIG. 12 is an explanatory diagram illustrating an information processing apparatus that executes a management program.

  Hereinafter, embodiments of a management device, a management method, and a management program disclosed in the present application will be described in detail with reference to the drawings. The disclosed technology is not limited by the present embodiment. Moreover, you may combine suitably each Example shown below in the range which does not cause contradiction.

  FIG. 1 is an explanatory diagram illustrating an example of the monitoring system according to the embodiment. A monitoring system 1 shown in FIG. 1 has a plurality of customer systems 2 and a monitoring center 3. For example, the monitoring center 3 remotely monitors the states of a plurality of customer systems 2 at remote locations. The monitoring center 3 includes a server 4, a database (hereinafter simply referred to as “DB”) device 5, and a failure monitoring device 6.

  The customer system 2 is composed of, for example, an electronic device such as a computer device, and includes a communication interface (hereinafter simply referred to as IF) 11, a display unit 12, an operation unit 13, and a TPM (Trusted Platform Module) chip 14. Have. Further, the customer system 2 includes an HDD (Hard Disk Drive) 15, a RAM (Random Access Memory) 16, a CPU (Control Processing Unit) 17, and a bus 18. The communication IF 11 is an IF that manages communication with the server 4. The display unit 12 is an output IF that displays various types of information. The operation unit 13 is an input IF for inputting various information. The HDD 15 is a non-volatile storage area that stores various types of information. The RAM 16 is a volatile storage area that stores various types of information. The CPU 17 controls the customer system 2 as a whole. The bus 18 is a transmission path for transmitting data among the communication IF 11, the display unit 12, the operation unit 13, the TPM chip 14, the HDD 15, the RAM 16, and the CPU 17.

  Here, the features of the TPM chip will be described. The TPM chip is a chip that employs TCG (Trusted Computing Group) technology. In recent years, devices connected to the Internet have always been exposed to security threats, and there is a risk that viruses, spyware, other malicious scripts, unauthorized access, etc. will cause unexpected changes to the software structure that constitutes the platform. is there. TCG realizes a secure computing environment by guaranteeing platform reliability. The platform is, for example, hardware, an OS (Operating System), an application, or the like. For example, with respect to the threat of software tampering, there are limits to conventional security measures that rely only on software. Therefore, TCG embeds a TPM chip in the platform, and uses this TPM chip as a root of trust to build a highly reliable computing environment that is difficult to falsify. Further, TCG uses a TPM chip to realize hardware-based data and certificate protection and secure encryption processing.

  The TPM chip is a chip having tamper resistance, and is physically mounted on a main component part of the electronic device such as a mother board so that it cannot be removed from the electronic device. The functions of the TPM chip include a RSA (Rivest Shamir Adleman) private key / public key pair generation and storage function, and a RSA private key signature, encryption, and decryption function. In addition, the functions of the TPM chip include a function for calculating a hash value of SHA-1 (Secure Hash Algorithm 1), a function for holding environment information of an electronic device, and the like.

  TCG defines a software stack and a software interface in order to use a TPM chip as a hardware device from a higher-level application or library. The software stack is called TSS (TCG Software Stack), and is composed of software modules that store the functions of the TPM chip whose resources are limited. Further, the CPU application in the electronic device accesses the function of the TPM chip using an interface provided by the TSS.

  Also, the TPM chip acquires software code in the boot process to the BIOS (Basic Input / Output System), OSloader, and OS kernel when the CPU of the electronic device is activated. The TPM chip hashes the acquired software code to obtain a hash value of the software configuration. Then, the TPM chip registers the hash value of the software configuration in a register inside the TPM chip. In addition, the TPM chip obtains hardware configuration information of the electronic device, and hashes the hardware configuration information to obtain a hardware configuration hash value. Then, the TPM chip registers the hash value of the hardware configuration in a register inside the TPM chip. That is, in the TPM chip, the hash value of the software configuration and the hash value of the hardware configuration of the electronic device are registered in the register.

  FIG. 2 is an explanatory diagram illustrating an example of the configuration information. The software information, software setting values, OS information, OS setting values, and the like shown in FIG. 2 are software codes of the customer system 2. The hardware information is hardware information of the customer system 2. The TPM chip 14 hashes the software information to obtain a hash value A1. The TPM chip 14 hashes the software setting value to obtain the hash value A2. The TPM chip 14 hashes the OS information to obtain a hash value A3. The TPM chip 14 hashes the OS setting value to obtain a hash value A4. The TPM chip 14 hashes the hardware information to obtain a hash value A5. Further, the TPM chip 14 hashes the software information hash value A1, the software setting value hash value A2, the OS information hash value A3, the OS setting value hash value A4, and the hardware information hash value A5 to represent the hash value. The value A is obtained. The configuration information includes software configuration hash values A1, A2, A3, and A4 and / or hardware configuration hash value A5, and representative hash value A.

  Next, the server 4 is configured by, for example, a computer device, and includes a communication IF 21, a display unit 22, an operation unit 23, a TPM chip 24, an HDD 25, a RAM 26, a CPU 27, and a bus 28. The TPM chip 24 on the server 4 side ensures the validity of hash value collection by managing the rules for collecting hash values with the TPM chip 14 on the customer system 2 side by hashing and assigning a signature. is there. Moreover, the TPM chip 24 proves the non-falsification of the rule by checking the current rule and signature as necessary. As a result, the TPM chip 14 ensures that there is no falsification in the rules for collecting hash values by referring to the rules that have been proved to be non-falsified on the TPM chip 24 side. Moreover, it can be ensured that the workers in the monitoring center 3 dispatched to the customer system 2 have not been tampered with.

  The DB device 5 includes a comparison DB 30 and an accumulation DB 40. The comparison DB 30 stores a list used for determining the configuration change of the customer system 2, failure, normality, and the like. The comparison DB 30 stores a white list 31, a black list 32, a yellow list 33, a verified list 34, an unknown list 35, and a big DB 36.

  In the white list 31, for example, configuration information of normal system configurations that can be combined and guaranteed by the manufacturer at the timing of hardware shipment, software commercialization, patch provision, or the like is registered. The configuration information registered in the white list 31 includes a hash value corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the white list 31 to determine whether the system configuration on the customer system 2 side is a normal system configuration.

  In the black list 32, for example, configuration information corresponding to the system configuration of the failure case verified by the manufacturer is registered. The configuration information registered in the black list 32 includes a hash value corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the black list 32 to determine whether or not the system configuration on the customer system 2 side is the system configuration of the failure case. The verified failure case may include a case in which a verified failure is likely to occur.

  In the yellow list 33, configuration information corresponding to the system configuration of a failure case that does not correspond to the black list 32 but whose cause is unknown and unverified is registered. The configuration information registered in the yellow list 33 includes a hash value corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the yellow list 33 to determine whether or not the system configuration on the customer system 2 side is the system configuration of the failure case whose cause is unknown. In addition, the failure case of unknown cause may include a case where the failure of unknown cause is likely to occur. An example of the first list is a yellow list 33, for example.

  In the verified list 34, configuration information corresponding to a system configuration verified in operation is registered. The configuration information registered in the verified list 34 includes hash values corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the verified list 34 to determine whether or not the system configuration on the customer system 2 side is a verified system configuration in a normal state. An example of the second list is a verified list 34.

  In the unknown list 35, configuration information corresponding to an unknown system configuration that does not correspond to any of the white list 31, the black list 32, the yellow list 33, and the verified list 34 is registered. An example of the third list is an unknown list 35, for example.

  FIG. 3 is an explanatory diagram illustrating an example of a table configuration of the big DB 36. In the big DB 36 shown in FIG. 3, the configuration information 36A collected from each customer system 2 is associated with a system ID 36B for identifying the customer system 2 and time information 36C such as a date when the configuration information 36A is collected. Data is stored. An example of the storage unit is a big DB 36, for example.

  The storage DB 40 is a DB that sequentially stores configuration information collected from each customer system 2 for each customer system 2. FIG. 4 is an explanatory diagram illustrating an example of a table configuration of the storage DB 40. The storage DB 40 illustrated in FIG. 4 stores a date 41, a system ID 42, a location ID 43, a representative hash value 44, and a hash value 45 in association with each other. The date 41 is, for example, the date when the configuration information is collected from the customer system 2 on the server 4 side. The system ID 42 is an ID for identifying the customer system 2 that is the transmission source of the configuration information. The location ID 43 is an ID indicating the installation location of the customer system 2 that is the transmission source. The representative hash value 44 is a representative hash value in the configuration information. The hash value 45 is a hash value of the software configuration and the hardware configuration in the configuration information.

  The failure monitoring device 6 is a device that notifies the server 4 of failure case information. The failure case information includes the failure content and, for example, a hash value of a software configuration and / or a hardware configuration corresponding to the system configuration of the failure.

  The CPU 17 of the customer system 2 acquires the configuration information obtained by the TPM chip 14 from the certificate authority for the public key of the TPM chip 24 on the server 4 side, and encrypts the configuration information using the acquired public key. Further, the CPU 17 transmits the encrypted configuration information to the server 4 through the communication IF 11. Further, the CPU 27 of the server 4 receives configuration information from the customer system 2 through the communication IF 21. Then, the TPM chip 24 in the server 4 decrypts the configuration information of the customer system 2 received with the private key held by itself. The customer system 2 transmits information such as a system ID and a location ID for identifying the customer system 2 to the server 4 in addition to the configuration information.

  FIG. 5 is an explanatory diagram illustrating an example of a failure determination process executed by the CPU 27 in the server 4. The CPU 27 reads out a failure determination program stored in the HDD 25, executes a failure determination process based on the failure determination program, and performs a configuration information collection unit 51, a configuration change determination unit 52, a configuration change notification unit 53, a failure determination unit 54, a failure The notification unit 55 is executed as a function. The configuration information collection unit 51 collects the configuration information of the customer system 2 decrypted by the TPM chip 24. The configuration information collection unit 51 stores the collected configuration information 36A in the big DB 36 in association with the system ID 36B and acquisition date (time information) 36C of the customer system 2.

  The configuration change determination unit 52 includes a representative hash comparison unit 52A. The representative hash comparison unit 52A refers to the storage DB 40 and determines whether or not there is the same system ID 42 and the same representative hash value 44 as the representative hash value in the decrypted configuration information.

  The configuration change determination unit 52 refers to the storage DB 40 based on the comparison result of the representative hash comparison unit 52A. If there is the same system ID 42 as the corresponding representative hash value and the same representative hash value, the configuration change determination unit 52 includes the current configuration information. It is determined that there is no configuration change of the customer system 2 concerned. The configuration change determination unit 52 refers to the storage DB 40 based on the comparison result of the representative hash comparison unit 52A. If the system ID 42 is the same as the representative hash value and there is no same representative hash value, the configuration change determination unit 52 includes the current configuration information. It is determined that there is a configuration change of the customer system 2 concerned.

  When there is a configuration change, the configuration change notification unit 53 notifies the display unit 22 that there is a configuration change. The administrator of the server 4 can recognize the configuration change of the customer system on the display unit 22.

  The failure determination unit 54 includes a hash comparison unit 54A. The hash comparison unit 54A refers to the comparison DB 30 and determines whether there is a hash value identical to the hash value in the decrypted configuration information. The failure determination unit 54 determines whether the hash value in the configuration information is in the white list 31 through the hash comparison unit 54A. If the hash value is in the white list 31, the customer system 2 is in a normal state system. It is determined as a configuration. The failure determination unit 54 determines whether or not the hash value in the configuration information is in the black list 32 through the hash comparison unit 54A. If the hash value is in the black list 32, the customer system 2 is the system of the failure case. It is determined as a configuration. The failure determination unit 54 determines whether or not the hash value in the configuration information is in the yellow list 33 through the hash comparison unit 54A. If the hash value is in the yellow list 33, the customer system 2 has a failure whose cause is unknown. Determine the system configuration of the case.

  The failure determination unit 54 determines whether the hash value in the configuration information is in the verified list 34 through the hash comparison unit 54A. If the hash value is in the verified list 34, the customer system 2 has been verified. It is determined that the system configuration is normal. When the hash value in the configuration information is not in any of the white list 31, the black list 32, the yellow list 33, and the verified list 34, the failure determination unit 54 determines this configuration information as an unknown system configuration.

  When determining that the hash value in the configuration information is an unknown system configuration, the failure determination unit 54 registers the configuration information in the unknown list 35.

  In addition, the failure notification unit 55 notifies and outputs a black warning on the display unit 22 when the failure determination unit 54 determines that the system configuration is a verified failure case. Further, the failure notification unit 55 notifies and outputs a yellow warning on the display unit 22 when the failure determination unit 54 determines that the system configuration is a failure case whose cause is unknown.

  FIG. 6 is an explanatory diagram showing an example of a list update process executed by the CPU 27 in the server 4. The CPU 27 reads the list update program stored in the HDD 25, executes the list update process based on the list update program, and executes the list update unit 61, the failure information acquisition unit 62, and the condition policy management unit 63 as functions.

  The failure information acquisition unit 62 acquires failure case information from the failure monitoring device 6. When the configuration information corresponding to the configuration information in the failure case information is in the unknown list 35, the list update unit 61 counts the number of cases for each configuration information and stores the number of cases in the case list 35A. When the configuration information corresponding to the configuration information in the failure case information is in the verified list 34, the list update unit 61 counts the number of cases for each configuration information and stores the number of cases in the case list 34A. When the configuration information corresponding to the configuration information in the failure case information is in the yellow list 33, the list update unit 61 counts the number of cases for each configuration information and stores the number of cases in the case list 33A.

  The list update unit 61 is an example of an update unit, and includes an unknown determination unit 61A, a verified determination unit 61B, and a yellow determination unit 61C. The unknown determination unit 61A refers to the case list 35A in the unknown list 35 and determines whether or not the configuration information in the unknown list 35 satisfies a condition for shifting to the verified list 34. When the configuration information in the unknown list 35 satisfies the condition for shifting to the verified list 34, the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the verified list 34. The condition for shifting from the unknown list 35 to the verified list 34 is when the number of cases of failure (number of occurrences) of the configuration information in the unknown list 35 is less than the second specified number of times within a predetermined period.

  The unknown determination unit 61A refers to the case list 35A in the unknown list 35 and determines whether or not the configuration information in the unknown list 35 satisfies the condition for shifting to the yellow list 33. When the configuration information in the unknown list 35 satisfies the condition for shifting to the yellow list 33, the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the yellow list 33. The condition for shifting from the unknown list 35 to the yellow list 33 is when the number of cases (number of occurrences) of failure cases in the configuration information in the unknown list 35 exceeds the first specified number of times within a predetermined period. The first specified number of times is equal to or greater than the second specified number of times. The first specified number of times is, for example, a number of times corresponding to 20% of the number of failure cases of the configuration information with respect to the total number of the same configuration information registered in the unknown list 35 within a predetermined period.

  The verified determination unit 61B refers to the case list 34A in the verified list 34 and determines whether or not the configuration information in the verified list 34 satisfies the condition for shifting to the yellow list 33. When the configuration information in the verified list 34 satisfies the condition for shifting to the yellow list 33, the verified determination unit 61B deletes the corresponding configuration information from the verified list 34 and registers it in the yellow list 33. The condition for shifting from the verified list 34 to the yellow list 33 is when the number of cases (occurrence number) of the configuration information in the verified list 34 exceeds the first specified number of times within a predetermined period. .

  The yellow determination unit 61C refers to the case list 33A in the yellow list 33 and determines whether or not the configuration information in the yellow list 33 satisfies a condition for shifting to the verified list 34. When the configuration information in the yellow list 33 satisfies the condition for shifting to the verified list 34, the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the verified list 34. The condition for shifting from the yellow list 33 to the verified list 34 is when the number of cases (occurrence number) of the configuration information in the yellow list 33 is less than the second specified number of times within a predetermined period.

  The yellow determination unit 61C refers to the case list 33A in the yellow list 33 and determines whether or not the configuration information in the yellow list 33 satisfies a condition for shifting to the black list 32. When the configuration information in the yellow list 33 satisfies the condition for shifting to the black list 32, the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the black list 32. The condition for shifting from the yellow list 33 to the black list 32 is when the number of cases (occurrence number) of the configuration information in the yellow list 33 exceeds the third specified number of times within a predetermined period. The third specified number of times is greater than the first specified number of times.

  The condition policy management unit 63 manages conditions for transferring configuration information among the unknown list 35, the yellow list 33, and the verified list 34.

  Next, the operation of the monitoring system 1 of this embodiment will be described. FIG. 7 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the configuration change check process. The configuration change check process shown in FIG. 7 is a process of checking whether there is a configuration change of the customer system 2 based on the representative hash value in the configuration information collected from the customer system 2. In FIG. 7, the configuration information collection unit 51 in the CPU 27 determines whether or not configuration information has been collected from the customer system 2 (step S11). When collecting the configuration information (Yes at Step S11), the configuration information collecting unit 51 acquires a representative hash value from the configuration information (Step S12).

  The representative hash comparison unit 52A determines whether or not the same system ID as the acquired representative hash value and the same representative hash value exist in the storage DB 40 (step S13). When there is the same system ID and the same representative hash value (Yes at Step S13), the configuration change determination unit 52 determines that there is no configuration change of the system configuration related to the representative hash value (Step S14). Further, if the configuration change determination unit 52 determines that there is no configuration change of the system configuration, the configuration change determination unit 52 registers the configuration information of the customer system 2 in the storage DB 40 (step S15), and ends the processing operation illustrated in FIG.

  Also, the representative hash comparison unit 52A determines that there is a configuration change in the system configuration when the system ID is the same as the acquired representative hash value and the same representative hash value is not in the storage DB 40 (No in step S13). (Step S16). When the configuration change notification unit 53 determines that there is a configuration change in the system configuration, the configuration change notification unit 53 notifies the display unit 22 of the configuration change (step S17), and registers the configuration information of the system configuration in the storage DB 40. The process proceeds to step S15. As a result, the administrator of the server 4 can recognize that there is a configuration change by looking at the notification content on the display unit 22, for example.

  Further, when the configuration information acquisition unit 51 does not acquire the configuration information (No at Step S11), the processing operation illustrated in FIG.

  When the CPU 27 of the configuration change check process shown in FIG. 7 acquires the representative hash value in the configuration information from the customer system 2, the same system ID as the representative hash value and the same representative hash value are in the storage DB 40. It is determined whether or not. If the same system ID and the same representative hash value are in the storage DB 40, the CPU 27 determines that there is no configuration change in the system configuration of the customer system 2.

  Further, when the system ID that is the same as the acquired representative hash value and the same representative hash value is not in the storage DB 40, the CPU 27 determines that the system configuration of the customer system 2 has been changed, and notifies that the configuration has changed. Output. As a result, the administrator of the server 4 can recognize that there is a configuration change in the system configuration of the customer system 2 based on the notification content.

  FIG. 8 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 involved in the failure determination process. The notification process shown in FIG. 8 is a process for notifying the presence or absence of a failure according to the determination result of the failure determination unit 54. In FIG. 8, the configuration information collection unit 51 determines whether or not configuration information has been collected from the customer system 2 (step S21). When the configuration information is collected (Yes at Step S21), the configuration information collection unit 51 acquires the hash value of the software configuration and the hardware configuration in the configuration information (Step S22). The failure determination unit 54 determines whether or not the acquired hash value is in the white list 31 (step S23).

  If the hash value is in the white list 31 (Yes at Step S23), the failure determination unit 54 ends the processing operation illustrated in FIG. 8 because the system configuration is normal. If the hash value is not in the white list 31 (No at Step S23), the failure determination unit 54 determines whether the hash value is in the verified list 34 (Step S24). If the hash value is in the verified list 34 (Yes at step S24), the failure determination unit 54 ends the processing operation illustrated in FIG. 8 because the system configuration is in a verified normal state.

  The failure determination unit 54 determines whether or not the acquired hash value is in the yellow list 33 (step S25). If the hash value is in the yellow list 33 (Yes at Step S25), the failure determination unit 54 outputs a yellow warning through the failure notification unit 55 because the system configuration is a failure case whose cause is unknown (Step S26). The processing operation shown in FIG. Note that the administrator of the server 4 can recognize that the system configuration of the customer system 2 is an unknown failure case in response to the yellow warning.

  If the hash value is not in the yellow list 33 (No at Step S25), the failure determination unit 54 determines whether the hash value is in the black list 32 (Step S27). If the hash value is in the black list 32 (Yes at Step S27), the failure determination unit 54 outputs a black warning through the failure notification unit 55 because the system configuration is a verified failure case (Step S28). The processing operation shown in FIG. The administrator of the server 4 can recognize that the system configuration of the customer system 2 has been verified according to the black warning.

  If the hash value is not in the black list 32 (No at Step S27), the failure determination unit 54 registers the configuration information acquired at Step S21 in the unknown list 35 (Step S29), and performs the processing operation illustrated in FIG. finish.

  The CPU 27 of the notification process shown in FIG. 8 determines that the system configuration of the customer system 2 is normal when the hash value in the configuration information collected from the customer system 2 is in the white list 31.

  When the hash value in the configuration information collected from the customer system 2 is in the verified list 34, the CPU 27 determines that the system configuration of the customer system 2 is in a verified normal state.

  If the hash value in the configuration information collected from the customer system 2 is in the yellow list 33, the CPU 27 determines that the system configuration of the customer system 2 is a failure case whose cause is unknown, and outputs a yellow warning. As a result, the administrator of the server 4 can recognize that the system configuration of the customer system is an unknown failure case based on the yellow warning.

  When the hash value in the configuration information collected from the customer system 2 is in the black list 32, the CPU 27 determines that the system configuration of the customer system 2 is a verified failure case and outputs a black warning. As a result, the administrator of the server 4 can recognize the system configuration of the customer system as a failure case based on the black warning.

  FIG. 9 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the unknown list determination process. The unknown list determination process shown in FIG. 9 is a process of deleting the configuration information registered in the unknown list 35 and registering it in the yellow list 33 or the verified list 34 in accordance with the migration condition.

  In FIG. 9, the unknown determination unit 61A in the CPU 27 determines whether or not the number of cases of the configuration information in the unknown list 35 has exceeded the first specified number of times within a predetermined period (step S31). When the number of case examples of the configuration information exceeds the first specified number of times within a predetermined period (Yes at Step S31), the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the yellow list 33 ( Step S32), the processing operation shown in FIG.

  When the number of case examples of the configuration information does not exceed the first specified number of times within a predetermined period (No at Step S31), the unknown determination unit 61A determines that the number of case examples of the configuration information in the unknown list 35 is within the predetermined period. It is determined whether or not the number is less than the prescribed number (step S33). When the number of case examples of the configuration information is less than the second specified number of times within a predetermined period (Yes at Step S33), the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the verified list 34 ( Step S34), the processing operation shown in FIG.

  When the number of case examples of the configuration information is not less than the second specified number of times within a predetermined period (No at Step S33), the unknown determination unit 61A ends the processing operation illustrated in FIG.

  The CPU 27 of the unknown list determination process shown in FIG. 9 deletes the corresponding configuration information from the unknown list 35 and deletes the yellow list when the number of cases of the configuration information in the unknown list 35 exceeds the first specified number of times within a predetermined period. 33. As a result, the configuration information can be dynamically transferred between the unknown list 35 and the yellow list 33.

  When the number of cases of the configuration information in the unknown list 35 is less than the second specified number of times within a predetermined period, the CPU 27 deletes the corresponding configuration information from the unknown list 35 and registers it in the verified list 34. As a result, the configuration information can be dynamically transferred between the unknown list 35 and the verified list 34.

  FIG. 10 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the yellow list determination processing. The yellow list determination process shown in FIG. 10 is a process for deleting the configuration information registered in the yellow list 33 and registering it in the verified list 34 or the black list 32 in accordance with the migration condition.

  In FIG. 10, the yellow determination unit 61C in the CPU 27 determines whether or not the number of cases of the configuration information in the yellow list 33 has exceeded the third specified number within a predetermined period (step S41). When the number of case examples of the configuration information exceeds the third specified number of times within a predetermined period (Yes at Step S41), the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the black list 32 ( Step S42), the processing operation shown in FIG.

  In addition, when the number of case examples of the configuration information does not exceed the third specified number of times within the predetermined period (No at Step S41), the yellow determination unit 61C determines that the number of case examples of the configuration information in the yellow list 33 is within the predetermined period. It is determined whether or not the number is less than the prescribed number of times 2 (step S43). When the number of case examples of the configuration information is less than the second specified number of times within a predetermined period (Yes at Step S43), the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the verified list 34 ( Step S44), the processing operation shown in FIG.

  When the number of case examples of the configuration information is not less than the second specified number of times within a predetermined period (No at Step S43), the yellow determination unit 61C ends the processing operation illustrated in FIG.

  The CPU 27 of the yellow list determination process shown in FIG. 10 deletes the corresponding configuration information from the yellow list 33 when the number of cases of the configuration information in the yellow list 33 is less than the second specified number of times within a predetermined period. 34. As a result, the configuration information can be dynamically transferred between the verified list 34 and the yellow list 33.

  When the number of cases of the configuration information in the yellow list 33 exceeds the third specified number of times within a predetermined period, the CPU 27 deletes the corresponding configuration information from the yellow list 33 and registers it in the black list 32. As a result, configuration information can be dynamically transferred between the black list 32 and the yellow list 33.

  FIG. 11 is a flowchart illustrating an example of the processing operation of the CPU 27 in the server 4 related to the verified list determination process. The verified list determination process shown in FIG. 11 is a process of deleting the configuration information registered in the verified list 34 and registering it in the yellow list 33 according to a predetermined condition.

  In FIG. 11, the verified determination unit 61B in the CPU 27 determines whether or not the number of cases of the configuration information in the verified list 34 has exceeded the first specified number of times within a predetermined period (step S51). The verified determination unit 61B deletes the corresponding configuration information from the verified list 34 and registers it in the yellow list 33 when the number of cases of the configuration information exceeds the first specified number of times within a predetermined period (Yes in step S51). Then (step S52), the processing operation shown in FIG.

  The verified determination unit 61B ends the processing operation illustrated in FIG. 11 when the number of case examples of the configuration information does not exceed the first specified number of times within a predetermined period (No in step S51).

  The CPU 27 of the verified list determination process shown in FIG. 11 deletes the corresponding configuration information from the verified list 34 when the number of cases of the configuration information in the verified list 34 exceeds the first specified number of times within a predetermined period. Is registered in the yellow list 33. As a result, the configuration information can be dynamically transferred between the verified list 34 and the yellow list 33.

  In the embodiment, system configuration on the customer system 2 side, for example, configuration information including a hash value for each software configuration and hardware configuration is periodically collected, and configuration information for each customer system 2 is stored in the storage DB 40. As a result, the server 4 can grasp the system configuration for each customer system 2 in time series with reference to the storage DB 40.

  In the embodiment, since the configuration information including the hash value of the software configuration and the hardware configuration is transmitted to the server 4 as the system configuration on the customer system 2 side, the data amount of the system configuration can be a minimum fixed length data amount. Therefore, the bandwidth used for the communication path can be reduced.

  In the embodiment, the presence / absence of the configuration change on the customer system 2 side is checked by referring to the accumulation DB 40 with the representative hash value in the configuration information. As a result, the presence / absence of the configuration change of the customer system 2 can be checked at high speed.

  In the embodiment, the content of the failure is detected by comparing the hash value corresponding to the system configuration of the customer system 2 with the hash value registered in each list. As a result, it is possible to realize prior prediction of failure occurrence and early solution after failure occurrence.

  When the hash value in the configuration information collected from the customer system 2 is in the yellow list 33, the server 4 of the embodiment determines that the customer system 2 has a system configuration related to a failure case whose cause is unknown. As a result, the server 4 identifies the customer system 2 as a system configuration related to a failure whose cause is unknown.

  When the hash value in the configuration information collected from the customer system 2 is in the verified list 34, the server 4 according to the embodiment determines that the customer system 2 has a verified normal system configuration. As a result, the server 4 identifies the system configuration as a normal state verified by the customer system 2.

  The server 4 according to the embodiment can confirm the presence / absence of a configuration change by comparing the previous configuration information of the customer system 2 stored in the storage DB 40 with the collected current configuration information using a representative hash value. In addition, when it is confirmed that a failure has occurred due to the current configuration change, the server 4 can recover the failure early by returning to the previous configuration information.

  In the embodiment, since the hash value collection rule and the encryption rule used by the TPM chip 14 on the customer system 2 side and the TPM chip 24 on the server 4 side conform to the internationally published standard specifications, their evidence is high. , Third parties can verify autonomously.

  The CPU 27 of the embodiment, based on the configuration information 36A and time information 36C stored in the big DB 36, and the number of failure cases for each configuration information 36A in the case list, the unknown list 35, the yellow list 33, and the verified list 34, the configuration information is transferred. As a result, the CPU 27 can dynamically update the list by moving the configuration information among the unknown list 35, the yellow list 33, and the verified list 34.

  When the number of failure cases related to the configuration information stored in the unknown list 35 exceeds the first specified number of times within a predetermined period, the CPU 27 deletes the configuration information from the unknown list 35 and enters the yellow list 33. Store. As a result, the configuration information registered in the unknown list 35 can be moved to the yellow list 33 and dynamically updated.

  When the number of failure cases related to the configuration information stored in the unknown list 35 is less than the second specified number of times within a predetermined period, the CPU 27 deletes the configuration information from the unknown list 35 and confirms the verified list 34. To store. As a result, the configuration information registered in the unknown list 35 can be moved to the verified list 34 to dynamically update the list.

  When the number of failure cases related to the configuration information stored in the verified list 34 exceeds the first specified number of times within a predetermined period, the CPU 27 deletes the configuration information from the verified list 34 and deletes the yellow list 33. As a result, the configuration information registered in the verified list 34 can be moved to the yellow list 33 to dynamically update the list.

  When the number of failure cases related to the configuration information stored in the yellow list 33 is less than the second specified number of times within a predetermined period, the CPU 27 deletes the configuration information from the yellow list 33 and verifies the verified list 34. To store. As a result, the configuration information registered in the yellow list 33 can be moved to the verified list 34 to dynamically update the list.

  The CPU 27 of the embodiment compares the configuration information received from the customer system 2 with the configuration information stored in the yellow list 33, and is there a possibility that a failure of unknown cause may occur in the electronic device that transmitted the configuration information? Determine whether or not.

  When the received configuration information is different from the previous configuration information stored in the storage DB 40, the CPU 27 according to the embodiment compares the configuration information with the configuration information registered in the comparison DB 30.

  Further, the server 4 registers a hash value corresponding to the patch in the white list 31 and determines whether or not there is a patch hash value registered in the white list 31 in the configuration information collected from the customer system 2. May be. In this case, the server 4 can confirm the presence / absence of patch application for each customer system 2.

  For example, the server 4 collects configuration information before applying the patch to the customer system 2 and configuration information after applying the patch, and compares the configuration information before applying the patch with the configuration information after applying the patch to determine whether the patch is applied. Can be confirmed. Moreover, since the server 4 knows the configuration information before applying the patch, it can be returned to the original system configuration by rollback.

  For example, the server 4 registers the white list 31 of the system configuration after completion of the maintenance work, and determines whether or not the hash value in the configuration information collected from the customer system 2 is in the white list 31. As a result, the server 4 can confirm whether or not the maintenance work is completed for each customer system 2.

  In the above embodiment, the hardware configuration and the software configuration are included as the system configuration of the customer system 2. However, it is proved that the two combinations are correctly maintained in the operation of changing the software version number when replacing the hardware parts. Therefore, a combination hash value may be collected.

  In the failure determination unit 54 of the above embodiment, since the configuration information registered in each list 31 to 35 is a hash value, the state of the system configuration is determined using the hash value, but the representative hash value is included in each list 31 to 35. May be determined by the representative hash value.

  In the above embodiment, a computer device is illustrated as an example of the electronic device of the customer system 2. The electronic device may be, for example, a server, a printer, a network device, an external storage, a mobile phone, a smartphone, a refrigerator, a washing machine, a television, a stereo component, a medical device, a machine tool, or the like.

  The configuration information corresponding to the system configuration of the failure case is registered in the yellow list 33 of the above embodiment. At this time, the configuration information is displayed for each risk level corresponding to the failure state of the failure case. You may register within. The degree of risk corresponding to the failure status is, for example, a plurality of ranks according to the range of influence of the failure caused by the failure case and the amount of damage. At this time, the failure determination unit 54 determines whether the received configuration information has a hash value for each risk level in the yellow list 33, and notifies the yellow warning corresponding to the risk level corresponding to the hash value. Output. As a result, the administrator of the server 4 can recognize a failure case corresponding to the degree of risk.

  In addition, each component of each part illustrated does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each part is not limited to the one shown in the figure, and all or a part thereof may be functionally or physically distributed / integrated in arbitrary units according to various loads and usage conditions. Can be configured.

  Furthermore, various processing functions performed in each device are performed on a CPU (Central Processing Unit) (or a microcomputer such as an MPU (Micro Processing Unit), MCU (Micro Controller Unit), etc.) in whole or in part. You may make it perform. Various processing functions may be executed entirely or arbitrarily on a program that is analyzed and executed by a CPU (or a microcomputer such as an MPU or MCU) or hardware based on wired logic. Needless to say.

  By the way, the various processes described in the present embodiment can be realized by executing a program prepared in advance by the information processing apparatus. Therefore, in the following, an example of an information processing apparatus that executes a program having the same function as in the above embodiment will be described. FIG. 12 is an explanatory diagram illustrating an information processing apparatus that executes a management program.

  The information processing apparatus 100 that executes the management program illustrated in FIG. 12 includes a ROM 110, a RAM 120, an HDD 130, a processor 140, an operation unit 150, a display unit 160, and a communication unit 170.

  The ROM 110 stores in advance a management program that exhibits the same functions as those in the above embodiment. The management program may be recorded on a recording medium that can be read by a drive (not shown) instead of the ROM 110. Further, as the recording medium, for example, a portable recording medium such as a CD-ROM, a DVD disk, a USB memory, an SD card, or a semiconductor memory such as a flash memory may be used. As shown in FIG. 12, the management program is a reception program 110A and an update program 110B. Note that the programs 110A and 110B may be appropriately integrated or distributed.

  Then, the processor 140 reads these programs 110A and 110B from the ROM 110, and executes each of the read programs. As shown in FIG. 12, the processor 140 functions the programs 110A and 110B as a reception process 140A and an update process 140B.

  The HDD 130 stores a first list 130A, a second list 130B, and a third list 130C. The first list 130A stores configuration information indicating a first state among the configuration information of the electronic device. The second list 130B stores configuration information indicating a second state that is not the first state. The third list 130C stores configuration information indicating a third state in which it is unknown whether the first state or the second state.

  The processor 140 periodically receives the configuration information of the electronic device. Furthermore, the processor 140 stores the received configuration information in the storage unit in association with the time information. Further, the processor 140 stores the number of occurrences of cases indicating the first state in the case list for each configuration information. The processor 140, based on the configuration information and time information in the HDD 130, and the number of occurrences of the configuration information in the case list, between the first list and the second list, between the second list and the third list, The configuration information is moved and the list is updated between the third list and the first list. As a result, the contents of the list can be dynamically changed according to changes in the number of cases and the passage of time.

2 Customer system 4 Server 5 DB device 14 TPM chip 24 TPM chip 27 CPU
33 Yellow List 34 Verified List 35 Unknown List 36 Big DB
40 Storage DB
52 configuration change determination unit 52A representative hash comparison unit 53 configuration change notification unit 54 failure determination unit 54A hash comparison unit 55 failure notification unit 61 list update unit 61A unknown determination unit 61B verified determination unit 61C yellow determination unit

Claims (12)

A receiving unit for periodically receiving configuration information of the electronic device;
A storage unit for storing the configuration information in association with time information;
A first list for storing configuration information indicating a first state;
A second list for storing configuration information indicating a second state that is not the first state;
A third list for storing configuration information indicating a third state that is unknown whether the first state or the second state;
For each of the configuration information, a case list that stores the number of occurrences of failure cases indicating the first state;
Based on the configuration information and time information stored in the storage unit, and the configuration information and number of occurrences stored in the case list, the second list is between the first list and the second list. And an update unit that updates the list by moving the configuration information between the third list and the third list or between the third list and the first list. apparatus. The update unit
When the number of occurrences related to the configuration information stored in the third list exceeds the first specified number of times within a predetermined period, the configuration information is deleted from the third list and the first list The management device according to claim 1, wherein the management device is stored in the management device. The update unit
If the number of occurrences related to the configuration information stored in the third list is less than a second specified number of times within a predetermined period, the configuration information is deleted from the third list and the second list The management device according to claim 1, wherein the management device is stored in the management device. The update unit
If the number of occurrences related to the configuration information stored in the second list exceeds the first prescribed number within a predetermined period, the configuration information is deleted from the second list and the first list is deleted. The management device according to claim 1, wherein the management device is stored in the storage device. The update unit
If the number of occurrences related to the configuration information stored in the first list is less than a second specified number of times within a predetermined period, the configuration information is deleted from the first list and the second list The management device according to claim 1, wherein the management device is stored in the storage device. The update unit
The management according to any one of claims 1 to 5, wherein the configuration information is stored in the first list for each risk of failure cases related to the configuration information received by the reception unit. apparatus.   The configuration information received by the receiving unit may be compared with the configuration information stored in the first list, and a failure state indicating the first state may occur in the electronic device that transmitted the configuration information. The management device according to claim 1, further comprising a determination unit that determines whether or not. The determination unit
If the configuration information received by the receiving unit is different from the previous configuration information stored in the storage unit, the configuration information is compared with the configuration information stored in the first list. The management device according to claim 7. The storage unit
Further storing a representative value of the configuration information in association with the configuration information,
The determination unit
When the representative value of the configuration information received by the receiving unit is different from the previous representative value stored in the storage unit, the configuration information is compared with the configuration information stored in the first list. The management apparatus according to claim 8, wherein the management apparatus is characterized in that: The receiver is
The configuration information of the electronic device collected by a tamper-resistant chip mounted on each electronic device and approved by a third-party device is received. The management device described. Information processing device
Receives electronic device configuration information periodically,
The received configuration information is stored in a storage unit in association with time information,
For each configuration information, store the number of occurrences of failure cases indicating the first state in the case list,
Based on the configuration information and time information stored in the storage unit, the configuration information stored in the case list and the number of occurrences, a first list for storing configuration information indicating the first state, and the first list It is unknown whether the second list and the first state or the second state are between the second list storing the configuration information indicating the second state that is not the state of the third state. The configuration information is moved to update the list between the third list storing the configuration information indicating the state or between the third list and the first list. A management method characterized by that. In the processor of the information processing device,
Receives electronic device configuration information periodically,
The received configuration information is stored in a storage unit in association with time information,
For each configuration information, store the number of occurrences of failure cases indicating the first state in the case list,
Based on the configuration information and time information stored in the storage unit, the configuration information stored in the case list and the number of occurrences, a first list for storing configuration information indicating the first state, and the first list It is unknown whether the second list and the first state or the second state are between the second list storing the configuration information indicating the second state that is not the state of the third state. The configuration information is moved to update the list between the third list storing the configuration information indicating the state or between the third list and the first list. A management program characterized by that.

Images