JP7587492B2 - Authentication device, authentication device control method and program - Google Patents

Description

The present invention relates to an authentication device, a control method for an authentication device, and a program.

Traditionally, various systems have been developed to provide information processing services by having computers execute programs, but as the content of information processing services has become more sophisticated, the systems have become larger in scale and more complex in configuration. Changes to systems are also being made more frequently.

For this reason, various technologies have been proposed to support the development of such systems and to enable them to be created more efficiently (for example, see non-patent documents 1 to 3).

RTCA DO-178 Revision C: Software Considerations in Airborne Systems and Equipment Certification1 (https://www.oviss.jp/view/item/000000000110) Introducing SLSA, an End-to-End Framework for Supply Chain Integrity (https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html) Certificate transparency3 (Communications of the ACM, Vol.57, Issue 10, October 2014, pp 40-46, https://dl.acm.org/doi/fullHtml/10.1145/2659897)

As examples of such technologies, new development environments and development methods such as OSS (Open Source Software), public cloud, Agile, and Software Defined Networks have become widespread in recent years.

However, as a result, more people are now involved in system development, and the development process itself is becoming one in which each step of requirements definition, design, development, and testing is repeated multiple times. Furthermore, the computers that execute programs are themselves being virtualized, and entire systems that provide information processing services are being realized as software. As a result, system configurations are also being changed more and more frequently.

Therefore, even in such a situation, configuration management tools such as Software Supply Chain, git, and terraform are used to properly understand the system configuration and to enable tracking of the dependencies between each component of the system. In addition, technologies such as containers and service meshes are also used to optimize the dependencies between system components and make it easier to understand the calling relationships between components.

However, this technology does not allow us to determine whether the system is operating according to specifications.

For example, a developer's mistake or a malicious individual's illegal actions could result in vulnerable code being mixed into a program, causing the system to operate outside of its specifications. Even if the program is in accordance with its specifications, an error in the settings or data could cause the system to operate outside of its specifications. In addition, if malware is running in the environment in which the program is running, even if there are no problems with the deployed program or data, tampering after deployment could cause the system to operate outside of its specifications.

For this reason, various scenario tests are conducted when a program or system is modified or deployed to discover problems in advance.

In addition, there are technologies such as (1) to (3) below that can be used to detect or prevent tampering after deployment.

(1) Use hash values to verify that the programs, systems, and data being deployed have not been tampered with.
(2) A signature is checked when a program is executed to prevent unauthorized programs from running, and (3) A hash chain of an execution program stored in a tamper-resistant area is verified to detect the running of an unauthorized program.

However, users of information processing services cannot obtain the information necessary to use these technologies, and therefore cannot use them to understand the status of the system.

As a result, users of information processing services can only grasp the status of the system through the following means (4) and (5).

(4) Check the system's status by periodically executing the system's API (Application Programming Interface).
(5) Trust the system and its operators as a whole and consider it to be in an appropriate state.

Here, in the case of method (4), the alive monitoring uses a standard response to a standard request, so only limited information can be obtained, such as whether the system outputs the expected results. Therefore, it is not possible to confirm whether the system was built using the appropriate components, and whether it was built by the appropriate person using the appropriate procedures.

On the other hand, in the case of option (5), the user of the information processing service has no prior knowledge of the system's status, and can only grasp the status when using the service.

To solve the problems faced by system users as described above, there are technologies that allow third-party verification and frameworks to verify the completeness and soundness of the system.

First, as described in Non-Patent Document 1, there is a known development methodology for systems that require high safety and reliability, such as aircraft. Non-Patent Document 1 describes how, for parts that require high safety and reliability, the correspondence between requirements and specifications is clarified, a verification plan is formulated in advance, and the development process and environment are standardized, and then certification is obtained from a third-party organization.

In addition, as described in Non-Patent Document 2, there is a methodology for protecting programs and systems from malicious changes. Non-Patent Document 2 describes how to prevent malicious changes by clarifying the origin of the program and verifying the environment related to its construction and deployment.

Furthermore, as described in Non-Patent Document 3, there is a method that makes it possible to detect abnormal certificates from the many certificates that exist on the web. Non-Patent Document 3 describes how a logstore that allows only appending and not rewriting is used to enable anyone to verify certificates and publish the results, making it possible to detect the presence or absence of abnormalities regardless of the chain of trust or root of trust.

However, the method described in Non-Patent Document 1 also verifies the validity of specifications, and requires manual verification of the correspondence between requirements and specifications. As a result, it takes several months to complete the verification, making it difficult to apply to fields where configurations change frequently, such as programs and systems.

The method in Non-Patent Document 2, with the aim of detecting and defending against the inclusion of malicious code and attacks during builds, specifies confirmation of the source of the code and the use of a build and deployment environment that is less susceptible to external disturbances, but it cannot prevent unauthorized states that arise from incorrect operations by persons with proper authorization.

In addition, the method described in Non-Patent Document 3 targets web servers and domain certificates, and therefore cannot be applied to the detection and verification of abnormal states in the systems on which programs are running.

The present invention has been made in consideration of these problems, and aims to provide an authentication device, a control method for the authentication device, and a program capable of authenticating a service providing system that is constructed to provide a specified information processing service by executing a service providing program.

The authentication device that solves the above problem is an authentication device that authenticates a service provision system constructed to provide a specified information processing service by executing a service provision program, and is equipped with a processor and a memory, and is equipped with a data authentication unit that authenticates the legitimacy of data used when constructing the service provision system, including the service provision program, an ID attribute authentication unit that authenticates the legitimacy of a processing entity that constructs the service provision system using the data, a process authentication unit that authenticates the legitimacy of a procedure for constructing the service provision system, and a system authentication unit that, when the legitimacy of the data, the legitimacy of the processing entity, and the legitimacy of the procedure are authenticated , authenticates that the service provision system has been constructed legitimately and outputs a certificate to prove that the service provision system has been constructed legitimately .

Other problems and solutions disclosed in this application will be made clear in the detailed description of the invention and the drawings.

According to the present invention, it is possible to authenticate a service providing system that is constructed to provide a specific information processing service by executing a service providing program.

FIG. 1 is a diagram illustrating an example of an overall configuration. FIG. 11 is a diagram illustrating an example of process log information. FIG. 11 is a diagram illustrating an example of deployment log information. FIG. 11 is a diagram showing an example of ID authentication result information. FIG. 11 is a diagram illustrating an example of attribute authentication result information. FIG. 11 illustrates an example of process authentication result information. FIG. 11 is a diagram showing an example of data authentication result information. FIG. 11 is a diagram showing an example of system authentication result information. FIG. 11 is a diagram illustrating an example of a sequence of attribute authentication. FIG. 11 is a diagram illustrating an example of a process authentication sequence. FIG. 11 is a diagram showing an example of a data authentication sequence. FIG. 11 is a diagram illustrating an example of a system authentication sequence. FIG. 13 illustrates an example of a certificate. FIG. 1 is a diagram illustrating an example of an overall configuration. FIG. 2 is a diagram illustrating an example of the configuration of a construction and deployment device, a system-related device, and an authentication device. FIG. 2 illustrates an example of a storage device of the construction and deployment device. FIG. 2 illustrates an example of a storage device for a system-related device. FIG. 2 illustrates an example of a storage device of the authentication device.

The following describes an embodiment of the present invention with reference to the drawings. Note that the embodiment described below is merely an example, and the embodiment to which the present invention is applicable is not limited to the following embodiment. Furthermore, the embodiment described below may be applied alone, or multiple or all of the embodiments may be applied in combination.

==Overall Configuration==
1 is a diagram logically illustrating the overall configuration of an information processing system A00 including an authentication device A03 according to an embodiment of the present invention. The information processing system A00 is configured with a construction and deployment device A01, a system-related device A02, and an authentication device A03.

The construction and deployment device A01, the system-related device A02, and the authentication device A03 may be configured using a physical computer or a virtual computer.

The construction and deployment device A01 is a computer that has the function of constructing the service provision system A22 described below. The service provision system A22 is constructed to provide a specified information processing service by executing a service provision program.

The construction and deployment device A01 also stores various data used when constructing the service providing system A22. In addition to the above-mentioned service providing programs, this data includes reference data used by the service providing programs when providing information processing services, and a configuration definition file that represents the configuration of the service providing system A22.

As shown in FIG. 1, the construction and deployment device A01 is configured to include a data repository A10, a build A11, a container repository A12, a deployment A13, and a process log A14.

Of these, the data repository A10, container repository A12, and process log A14 store the above-mentioned data used by the construction and deployment device A01 when constructing the service providing system A22. Furthermore, build A11 and deployment A13 are software modules that perform the process of constructing the service providing system A22 using the above-mentioned data.

For example, the build A11 and the deployment A13 are carried out by using various data stored in the data repository A10 and the container repository A12 to provide a service to the service providing system A22.
and deploying it in the system-related device A02. Then, the history of the processing performed when the service providing system A22 is constructed is recorded in the process log A14.

The system-related device A02 is a computer that executes the service providing system A22 to provide information processing services.

In this embodiment, the service providing system A22 is executed on an execution platform constructed by the system-related device A02 executing the system platform A20, and the above-mentioned information processing service is provided. This aspect allows the system-related device A02 to execute the service providing system A22 and provide the information processing service without being restricted by the physical hardware configuration of the processor, memory, network, etc. It also becomes possible to flexibly execute multiple service providing systems A22 depending on the content of the information processing service to be provided.

The system-related device A02 is composed of a system platform A20, a deployment log A21, and a service providing system A22.

Of these, the deployment log A21 records the history of processing when the deployment A13 deploys the service providing system A22 in the system-related device A02. The system platform A20 is a software module for providing an execution infrastructure for executing the service providing system A22.

The authentication device A03 is a computer that authenticates the service providing system A22 deployed in the system-related device A02. For example, the authentication device A03 verifies the soundness of the service providing system A22 from the standpoint of development, construction, and deployment.

The authentication device A03 is configured to include a root authentication unit A30, an ID attribute authentication unit A31, an attribute rule A32, an ID attribute authentication result A33, a process authentication unit A41, a process model A42, a process authentication result A43, a data authentication unit A51, a data quality rule A52, a data authentication result A53, a system authentication unit A61, a system rule A62, and a system authentication result A63.

The root authentication unit A30 functions as a higher-level authentication authority that authenticates the validity of the ID attribute authentication unit A31, the process authentication unit A41, the data authentication unit A51, and the system authentication unit A61. The root authentication unit A30 authenticates itself.

The ID attribute authentication unit A31 authenticates the legitimacy of the processing entity that constructs the service providing system A22. The processing entity may be, for example, a software module that performs the processing to construct the service providing system A22, or a person in charge of constructing the service providing system A22 using a software module. The software module may be, for example, a build A11 or a deployment A13. The person in charge may also include, for example, the developer or operator of the service providing system A22, and an administrator who manages these persons in charge.

In this manner, when the service providing system A22 is constructed, it is possible to authenticate whether or not a software module that has been improperly modified is being used, or whether or not a user without proper authority is using the software module.

The process authentication unit A41 authenticates the validity of the procedure for constructing the service providing system A22. For example, the process authentication unit A41 authenticates the validity of the procedure for constructing the service providing system A22 by using the history of processing recorded in the process log A14.

The data authentication unit A51 authenticates the validity of various data used by the construction and deployment device A01 when constructing the service providing system A22. As described above, for example, the data includes, in addition to the service providing program, reference data that the service providing program references to provide information processing services, and a configuration definition file that represents the configuration of the service providing system A22.

In this manner, it becomes possible to authenticate whether the constructed service providing system A22 has been constructed using unauthorized data.

When the validity of the above-mentioned data, the validity of the processing subject, and the validity of the procedure are authenticated, the system authentication unit A61 certifies that the service providing system A22 has been constructed legitimately. Furthermore, the system authentication unit A61 outputs an electronic certificate to prove that the service providing system A22 has been constructed legitimately.

In this way, the authentication device A03 according to this embodiment makes it possible to authenticate that the construction of the service provision system A22 by the construction and deployment device A01 is being carried out by a legitimate processing entity by processing legitimate data in a legitimate procedure.

In addition, since an electronic certificate is issued to prove that the service providing system A22 has been properly constructed, users of the service providing system A22 can understand the status of the service providing system A22 by checking the electronic certificate issued by the authentication device A03. In this case, the users do not need to perform the verification themselves, and only need to trust the authentication device A03. In particular, in this embodiment, only the root authentication unit A30 needs to be trusted.

Details are explained below.

= Construction and deployment device =
The data repository A10 manages and stores source code of the service providing program that runs on the service providing system A22, data used, configuration definition files of the service providing system A22, etc. The data repository A10 is configured using a software module such as git that manages files in association with repositories, paths, branches, etc., and manages differences when files are changed in association with the date and time, the person who reflected the change, and the hash value of the change content.

Build A11 tests and builds the source code obtained from data repository A10, and also incorporates various data such as middleware into the built image to construct a container image, which is then stored in container repository A12. Build A11 is configured using software modules that combine a CI server such as Jenkins, various language processing systems, and container construction software such as docker.

Container repository A12 manages and stores the container images built by build A11. Container repository A12 is configured using software modules such as dockerhub and Harbor that manage container images by name and tag.

The deployment A13 creates resources such as containers, volumes, and networks (NWs) on the system platform A20 according to the contents of a configuration definition file managed in the data repository A10, and deploys container images obtained from the container repository A12 to build a service providing system A22. The deployment A13 is configured using a software module, such as terraform, that interprets the contents of the configuration definition file and executes the deployment.

The process log A14 includes various commits in the data repository A10 and build A1.
The log records events such as builds and tests in A1, registration, updating, and deletion of container images in the container repository A12, creation, updating, and deletion of resources related to deployment in A13, and deployment of container images.

= System related equipment =
The system platform A20 constructs an execution infrastructure for the service providing system A22 having various resources created in response to an instruction from the deployment A13. This is configured using infrastructure software (software modules) such as Kubernetes.

The deployment log A21 records events such as creating, updating, and deleting resources in the system platform A20 as a log.

The service providing system A22 is a container that the deployment A13 builds based on a configuration definition file, and runs on the system platform A20. Multiple service providing systems A22 are configured for each type of information processing service, and provide various functions to users.

=Authentication Device=
The root authentication unit A30 is a certificate authority that serves as a base of trust and certifies the legitimacy of the ID attribute authentication unit A31, the process authentication unit A41, the data authentication unit A51, and the system authentication unit A61.

The ID attribute authentication unit A31 is a certification authority that is delegated by the root authentication unit A30 to certify the validity of the processing subject's ID and attributes.

For ID authentication, the ID attribute authentication unit A31 uses information such as the ID and credentials stored in the ID attribute authentication result A33 to authenticate processing entities such as developers and operators involved in the service providing system A22, as well as the build A11, deployment A13, and system platform A20.

The ID attribute authentication unit A31 also determines the attributes of developers and operators based on their qualifications and experience, as well as their past behavioral history stored in the process log A14, based on the criteria stored in the attribute rules A32, and determines attributes such as whether they can commit or review code or issue deployment instructions, and stores this in the ID attribute authentication result A33, and also uses this information to authenticate the attributes.

The process authentication unit A41 is a certification authority that receives delegation from the route authentication unit A30 and authenticates the validity of the process that constructs the service providing system A22.

The process authentication unit A41 verifies whether the log sequences of source code and data commits, reviews, tests, system deployment, etc. deviate from the normal process and verifies the role of the person who performed the operations, proving that the operations are problem-free.

The process authentication unit A41 compares the log sequences stored in the process log A14 and the deployment log A21 with the process model stored in the process model A42 to determine the type of the process and calculate the suitability. The process authentication unit A41 stores the result in the process authentication result A43.

The process model is represented in a data structure such as a Petri net, and the process authentication unit A41 uses techniques such as process mining to compare the log sequence with the process model.

The data authentication unit A51 is a certification authority that authenticates data on behalf of the root authentication unit A30.

The data authentication unit A51 verifies the ID and role of the person who committed or reviewed the source code or data, and proves that no unauthorized modifications have been made to the source code or data.

The data authentication unit A51 judges the various data stored in the data repository A10 and the container repository A12 based on the rules stored in the data quality rules A52, and determines whether the data is trustworthy. The data authentication unit A51 stores the result in the data authentication result A53.

The rules are a set of regulations that dictate what kind of data can be trusted. Data quality rules A52 state that if the people involved in creating or modifying the data have valid IDs and attributes, and if the original data has been verified, then the created data can be trusted.

The system authentication unit A61 is an authentication authority that authenticates the service providing system A22 under delegation from the root authentication unit A30.

The system authentication unit A61 authenticates the system platform A20 on which the service providing system A22 runs, and the original container and other images when the service providing system A22 is deployed. In addition, when the service providing system A22 is deployed, it verifies the source code, data, operations, people involved and their attributes, the system platform A20 to which it is deployed, and the images used, and proves that there are no problems that could lead to an unauthorized state in the deployed service providing system A22.

The system authentication unit A61 judges the validity of the deployed service providing system A22 based on the system regulations A62, and judges the soundness of the service providing system A22. The system authentication unit A61 stores the result in the system authentication result A63.

Figure 2 shows an example of the format of process log information B00 stored in process log A14 in this embodiment. Process log information B00 is composed of a list of groups of "process ID", "date and time", "log type", "event name", "log creator", and "context".

Here, "Process ID" is entered the identifier of each process log information (hereinafter also referred to as log) B00.

"Date and time" is the date and time the log was generated.

The "Log type" is used to distinguish the type of log, and lists types such as development-related, operation-related, and module-related such as build and deployment.

The "event name" is used to distinguish logs, such as commits and approvals in development, deployment instructions and approvals in operations, and each log output by a module.

"Log creator" distinguishes the creator of the log and lists the ID of the person or software module that created the log based on the ID attribute authentication result A33.

"Context" is used to help distinguish log sequences, and by extracting logs using the values stored in this column, it is possible to obtain a sequence of related logs.

Figure 3 shows an example of the data format of the deployment log information C00 stored in the deployment log A21 in this embodiment. The deployment log information C00 is composed of a list of groups of "resource ID", "creation date and time", "deletion date and time", "setting value", and "platform ID".

Here, "resource ID" is the identifier of the resource.

"Created" is the date and time the resource was created.

"Deletion date and time" is the date and time when the resource was deleted.

"Setting values" are values set for a resource when it is created, such as capacity and performance.

"Platform ID" is the ID of the system platform A20 on which the resource was created.

Figure 4 shows an example of the format of ID authentication result information D00 stored in ID attribute authentication result A33 in this embodiment. ID authentication result information D00 is composed of a list of groups of "ID", "Name", "Account type", "Credential", "Created date and time", "Updated date and time", "Public key", and "Is valid".

Here, "ID" is the identifier of an account held by a processing entity such as a person or module.

"Name" is a string that allows people to easily distinguish between accounts.

"Account type" is a string used to distinguish the type of account, such as whether it is for a person or for use by a program or module.

"Credential" is information used to identify an account, including a password and a reference to an external IdP.

"Created date and time" is the date and time the account was created.

"Update date and time" is the date and time when the account was updated. Account usage is periodically verified and updated for purposes such as validity verification.

The "public key" is the public key that corresponds to the private key held by the account user.

"IsValid" is a flag to identify whether an account is valid or invalid. Instead of having this column, "IsValid" can be managed and published in the form of a CRL, or managed and published on an OCSP server. When others refer to this content, it is provided in the form of an X.509 public key certificate as specified in RFC5280, for example.

This entry is added when a person wishing to add an entry submits a certificate signing request to the ID attribute authentication unit A31, which verifies the contents of the request and finds that there are no problems with the contents of the certificate signing request. The entry contents are also verified by the ID attribute authentication unit A31, and if the existence of the entry cannot be confirmed, the value of "is valid" becomes false. The value of "is valid" is also set to false upon request from the certificate issuer.

Figure 5 shows an example of the data format of attribute authentication result information E00 stored in ID attribute authentication result A33 in this embodiment. Attribute authentication result information E00 is composed of a list of groups of "ID", "attribute type", "creation date and time", "update date and time", and "is valid".

Here, "ID" is the identifier of the account whose attributes are to be certified.

"Attribute type" is a string indicating the attribute to be certified.

"Created date and time" is the date and time when the attribute certificate was created.

"Update date and time" E04 is the date and time when the attribute certificate was updated. Attributes are updated after investigating the subject's situation, etc., for validity verification, etc.

"IsValid" is a flag to identify whether the target attribute certificate is valid or invalid. Instead of having this column, "IsValid" can be managed and published in the form of a CRL, or managed and published on an OCSP server. When others refer to this content, it is provided in the format of an X.509 attribute certificate as specified in RFC5755, for example.

Figure 6 shows an example of the data format of the process authentication result information F00 stored in the process authentication result A43 in this embodiment. The process authentication result information F00 is composed of a list of groups of "process authentication result ID", "sequence ID", "attribute that can identify a set of process IDs", "judgment result", "judgment date and time", and "is valid".

Here, the "process authentication result ID" is an identifier for distinguishing authentication results.

"Sequence ID" is an identifier assigned to the sequence of the process log to be authenticated.

The "attribute that can identify a set of process IDs" is a value for identifying the process log set to be judged from the process log information B00 stored in the process log A14, and stores a list of process IDs and extraction conditions such as the type, event name, log creator, and period for extraction.

The "judgment result" is a string that indicates what operation the target process log set corresponds to as a result of the judgment, and whether or not it is being performed correctly.

"Determination date and time" is the date and time when the determination was made.

"Is valid" is a flag that indicates whether the judgment result is valid. When this content is referenced by others, it is provided in a format similar to the data validation certificate defined in RFC3029. In this case, it is provided in a form that stores the validation result for the target sequence in the certs field, for example.

Figure 7 shows an example of the data format of data authentication result information G00 stored in data authentication result A53 in this embodiment. Data authentication result information G00 is composed of a list of sets of "data authentication result ID", "file identifiable attribute", "hash value", "judgment result", "judgment date and time", and "is valid".

Here, the "data authentication result ID" is an identifier for distinguishing authentication results.

The "file identifiable attributes" are values for identifying the file to be authenticated, and include a set of the URL, branch name, and version of the file in the data repository A10 and container repository A12.

The "hash value" is the hash value of the file to be authenticated.

"Determination result" is a string that indicates whether the target file was created, updated, and confirmed by an account with proper permissions and roles.

"Determination date and time" is the date and time when the determination was made.

"Is valid" is a flag that indicates whether the judgment result is valid or not. Instead of having this column, "is valid" can be managed and published in the form of a CRL, or managed and published on an OCSP server. When this content is referenced by others, it is provided in a format similar to the data validation certificate specified in RFC3029, for example.

Figure 8 shows an example of the data format of system authentication result information H00 stored in system authentication result A63 in this embodiment. System authentication result information H00 is composed of a list of groups of "system authentication result ID", "system ID", "sequence ID at time of deployment", "judgment result", "judgment date and time", "expiration date", "previous system authentication result ID", and "is valid".

Here, the "system authentication result ID" is an identifier for distinguishing authentication results.

The "system ID" is a value assigned by deployment A13 to each deployed service providing system A22, used to identify each service providing system A22.

The "sequence ID at the time of deployment" is an identifier assigned to the sequence of logs output when the service providing system A22 to be authenticated, stored in the deployment log A21, is deployed.

The "determination result" is a string indicating whether the target service providing system A22 has been deployed to a legitimate system platform A20 using legitimate code, following a legitimate process, and has been confirmed.

"Determination date and time" is the date and time when the determination was made.

"Expiration date" is the date and time until which the judgment is valid.

The "previous system authentication result ID" is the value of the system authentication result ID that was valid up until that point, if authentication of the service providing system A22 is performed again before the expiration date.

"Is Valid" is a flag that indicates whether the judgment result is valid or not. Note that instead of having this column, "Is Valid" can be managed and published in the form of a CRL, or managed and published on an OCSP server.

When this content is referenced by others, it is provided in a format similar to the data verification certificate defined in RFC 3029. For example, the certs field may store the results of verification of the log sequence at the time of deployment, the results of verification of the codes and data used in the service provision system A22, the results of verification of the IDs and attributes of the people involved in deploying the service provision system A22, and information for users of the service provision system A22 to identify the service provision system A22.

Examples of information for identifying the service providing system A22 include the FQDN, IP address, and location where it is installed.

Figure 9 is an activity diagram showing the process related to attribute authentication performed by the ID attribute authentication unit A31. Figure 9 shows the process when the ID attribute authentication unit A31 performs authentication related to the attributes of the processing subject.

In step I01, the ID attribute authentication unit A31 determines the account of the processing subject for which attributes are to be verified, and collects information corresponding to that account. The ID attribute authentication unit A31 collects information from the process log A14, the process authentication result A43, and the like. In addition, for qualifications and experience that cannot be measured solely from the actions taken by the processing subject on the construction and deployment device A01, the ID attribute authentication unit A31 also uses declarations and evidence from the account owner, approval from superiors, and the like.

In step I02, the ID attribute authentication unit A31 compares the collected information with the attribute rules A32. The contents of the rules may include whether the processing entity has experience in deployment, development, or review within a certain period of time in the past, and whether the entity has performed any processes that deviate from the normal range. Other examples include whether the entity has valid qualifications that have evidence, are approved by a superior, and are certified by an external organization.

In step I03, the ID attribute authentication unit A31 determines whether or not to assign or update attributes based on the result of the comparison in step I02. The ID attribute authentication unit A31 then stores the result of the determination in the ID attribute authentication result A33.

The ID attribute authentication unit A31 executes attribute authentication processing when a person who wishes to issue an attribute certificate sends a certificate signing request to the authentication device A03. The ID attribute authentication unit A31 also executes attribute authentication processing periodically.

Figure 10 is an activity diagram showing the process authentication processing performed by the process authentication unit A41. Figure 10 shows the process performed by the process authentication unit A41 when authenticating a process.

In step J01, the process authentication unit A41 acquires a sequence of process logs from the process log A14, compares it with the model, and calculates the conformance rate. The acquisition method may use a date and time range, a log type, a log creator, a context value, or a list of process IDs. The process authentication unit A41 also acquires a process model from the process model A42.

In step J02, the process authentication unit A41 determines which model the sequence of process logs corresponds to based on the result of step J01. The determination method is a procedure that corresponds to the model with the maximum calculated conformance rate that is equal to or greater than a threshold value.

The process authentication unit A41 executes the process authentication process when a person who approved the data merging into the data repository A10 or the container repository A12 or the deployment of the service providing system A22 transmits a certificate signing request to the authentication device A03. The process authentication unit A41 may also execute the process authentication process when a software module that manages the data repository A10 or the container repository A12 or a software module that deployed the service providing system A22 transmits a certificate signing request to the authentication device A03.

Figure 11 is an activity diagram showing the process related to data authentication performed by the data authentication unit A51. Figure 11 shows the process when the data authentication unit A51 performs authentication related to data.

In step K01, the data authentication unit A51 obtains information on the original data, the account and process that performed the commit, review, and test for the data to be verified, and performs verification. At this time, the data authentication unit A51 identifies the data to be verified by using the repository name, path, branch name, hash value, etc.

The data authentication unit A51 also determines the original data based on whether the data was created by a trusted institution and whether a verification result exists in the data authentication result A53. For commit, review, and test, the sequence of process logs is obtained from the process log A14, and verification is performed via the process authentication unit A41. For account information, it is determined whether a valid account exists in the ID attribute authentication result A33 and has the required attributes.

In step K02, the data authentication unit A51 checks the results of step K01 against the data quality rules A52 to determine whether there are any problems, and reflects this in the data authentication result A53. An example of a rule is that there is no problem with trustworthy data if it is modified by a person with valid qualifications or by a software module through a defined process such as commit, review, and test.

The data authentication unit A51 executes data authentication processing when a person who has committed or merged data to the data repository A10 or the container repository A12 creates a certificate signing request and sends it to the data authentication unit A51. The data authentication unit A51 may also execute data authentication processing when management software (software module) for the data repository A10 or the container repository A12 sends a certificate signing request.

Figure 12 is an activity diagram showing the processing related to system authentication performed by the system authentication unit A61. Figure 12 shows the processing when the system authentication unit A61 performs authentication related to the service providing system A22.

In step L01, the system authentication unit A61 verifies the process related to the deployment of the service providing system A22. At this time, the system authentication unit A61 refers to the deployment log A21 and the process model A42, and verifies the compatibility of the process log and the model at the time of deployment.

In step L02, the system authentication unit A61 verifies the data used in the service providing system A22. At this time, the system authentication unit A61 verifies the data by referring to the data authentication result A53 and the verification results of the source code, setting values, reference data, configuration definition files, etc.

In step L03, the system authentication unit A61 refers to the data quality rules A52, data authentication result A53, attribute rules A32, and ID attribute authentication result A33 to verify the system platform A20 to which the data is to be deployed, the validity of the account of the processing entity that instructed the deployment, the validity of the attributes, etc.

If there are no problems in steps L01 to L03, in step L04, the system authentication unit A61 determines that there is no problem with the current service providing system A22.

The system authentication unit A61 executes the system authentication process when the person who approved the deployment execution of the service providing system A22 creates a certificate signing request and sends it to the system authentication unit A61. The system authentication unit A61 may also execute the system authentication process when the deployed software module sends a certificate signing request.

In addition, if it is confirmed that the identification information of the service providing system A22 is being used by another CSR and that the current service providing system A22 has been replaced, the system authentication unit A61 performs processing to revoke the certificate.

Figure 13 shows an example of a certificate chain involved when the system authentication unit A61 verifies the certificate of the service providing system A22.

M01 is the self-signed certificate of the root authentication unit A30.

M02 to M05 are certificates for the ID attribute authentication unit A31, the process authentication unit A41, the data authentication unit A51, and the system authentication unit A61, respectively, and each includes a signature by the root authentication unit A30.

M06 is a certificate related to the ID of processing entities such as people and software modules related to the service provision system A22, and includes the signature of the ID attribute authentication unit A31. Here, the processing entities include those in charge of the development, operation, and deployment of the service provision system A22, and the software modules that operate the construction and deployment device A01 and the system-related device A02.

M07 is a certificate related to the attributes of processing entities such as people and software modules involved in the service provision system A22, and includes the signature of the ID attribute authentication M02.

M08 is a certificate for the process verified by process authentication unit A41 and includes the signature of process authentication unit A41.

M09 is a certificate for data verified by data authentication unit A51 and contains the certification of data authentication unit A51.

M10 is a certificate for a software module related to the construction and deployment of the service providing system A22, verified by the system authentication unit A61, and includes a signature of the system authentication unit A61. Here, the software module includes a software module that causes the construction and deployment device A01 and the system-related device A02 to function.

M11 is a certificate for the second service providing system A22 with which the first service providing system A22 cooperates, verified by the system authentication unit A61, and includes the signature of the system authentication unit A61. Here, the second service providing system A22 is a computer that is relied upon by the first service providing system A22, whose verification result is indicated in M12.

For example, the second service providing system A22 may acquire data from the first service providing system A22 and transmit the processing results to the first service providing system A22, or may provide data to the first service providing system A22 for processing by the first service providing system A22.

Note that if no other service providing system A22 relies on this certificate, this certificate may not exist.

M12 is a certificate for the service providing system A22 verified by the system authentication unit A61. This certificate includes the signature of the system authentication unit A61, the verification result by the system authentication unit A61, the user's system identification means, a group of identifiers for related data, a group of identifiers for related processes, and a group of identifiers for related processing entities. It also includes other extension areas as necessary.

By referring to this certificate, users of the service providing system A22 can check the results of system verification by the system authentication unit A61. Furthermore, if deemed necessary, they can check the results of verification of the people involved in the development, construction, and deployment of the service providing system A22, the processing entities such as modules, processes, and data. Furthermore, if deemed necessary, they can check the results of verification by the certification authority that performed those verifications.

Therefore, a user can determine whether the target service providing system A22 has been verified and is problem-free by trusting only the root certification and verifying the hierarchical certificate chain by following the solid arrows in Figure 13.

Note that Figure 13 shows a certificate chain, and in reality each certificate contains information such as its expiration date.

Next, as an example of the service providing system A22 described in the above embodiment, a case will be described in which content such as information about the line and advertisements is displayed on a monitor inside a vehicle such as a train or bus. In this case, the service providing system A22 updates the content once a day so that the content can be displayed even when the vehicle is moving and not connected to a communication network.

The content is stored in the data repository A10 and then included in a container by the build A11. A container image is also created each time the content is updated.

When updating content, a person with the role to update the content issues a commit request to reflect the updates in the content, and a person with the role to approve the content update checks and approves the content, and the updated content is reflected in data repository A10.

Container deployment is performed at fixed times each day, and also when some unexpected event occurs, at the request of a person with the role to deploy containers and with the approval of a person with the role to approve container deployment.

For the service providing system A22 that provides such information processing services, the authentication device A03 verifies the IDs, roles, etc. of the processing entities involved in these processes, updates, and deployments, and issues certificates.

The authentication device A03 also stores a Uniform Resource Locator (URL) that indicates the storage location of the issued certificate.
The information processing service generates a QR code (registered trademark) by encoding the QR code and transmits it to a display monitor of a terminal (not shown) operated by a user of the information processing service.

By configuring in this way, users can check the health of the service providing system A22.

Next, as another example of the service providing system A22 described in the above embodiment, a case where remote monitoring and usage monitoring are performed on devices such as equipment and vehicles will be described.

In this case, the service providing system A22 issues a device certificate to the device to be monitored and also issues a user certificate to each customer to whom the device is sold.

The service providing system A22 then collects data from the monitored device, signed with the private keys of these two accounts.

The authentication device A03 can verify the signature of the data collected by the service providing system A22 to confirm that the data was collected from a legitimate device used by a legitimate customer.

In addition, by having the authentication device A03 verify the procedures used by the service providing system A22 when analyzing data and creating reports, the customer can also verify that the data obtained from their own device has been correctly processed and reflected in the report.

By configuring in this way, users can check the health of the service providing system A22.

Next, an example of the overall configuration of the information processing system A00 according to this embodiment is shown in FIG.

Figure 14 is a diagram corresponding to the overall configuration example shown in Figure 1, and shows that the construction and deployment device A01, system-related device A02, and authentication device A03 are connected so as to be able to communicate with each other via a network 500 such as the Internet, a LAN (Local Area Network), or a telephone network.

Next, we will explain the hardware configuration when the construction and deployment device A01, system-related device A02, and authentication device A03 are realized by physical computers. Note that the construction and deployment device A01, system-related device A02, and authentication device A03 are not necessarily configured the same, but they share a basic configuration, so they are shown together in Figure 15 to avoid duplication.

Examples of computers that realize the construction and deployment device A01, the system-related device A02, and the authentication device A03 include personal computers, office computers, server devices, smartphones, tablets, general-purpose computers (mainframes), etc.

In addition, all or a part of this computer may be realized using virtual information processing resources provided using virtualization technology, process space separation technology, etc., such as a virtual server provided by a cloud system. In addition, all or a part of the functions provided by this computer may be realized by a service provided by the cloud system via an API or the like, or may be realized by a service provided by a software as a service (SaaS),
It may also be realized using PaaS (Platform as a Service), IaaS (Infrastructure as a Service), etc.

When the construction and deployment device A01, the system-related device A02, and the authentication device A03 are realized by a hypervisor-type virtual computer, a physical computer (not shown) executes virtualization software (not shown) for realizing the configuration shown in FIG. 15 by software. In this case, the configuration of this physical computer is similar to the configuration shown in FIG. 15.

<Authentication device>
The authentication device A 03 is configured to include a CPU (Central Processing Unit) 310 , a memory 320 , a communication device 330 , a storage device 340 , an input device 350 , an output device 360 , and a recording medium reading device 370 .

The CPU 310 is responsible for the overall control of the authentication device A03, and is a processor that realizes the various functions of the authentication device A03 by reading the authentication device control program 630, which is composed of code for performing various operations related to this embodiment stored in the storage device 340, and various data into the memory 320 and executing or processing them.

For example, the authentication device control program 630 and various data are executed or processed by the CPU 310, and by working in cooperation with hardware devices such as the memory 320, the communication device 330, and the storage device 340, the functions of the root authentication unit A30, the ID attribute authentication unit A31, the process authentication unit A41, the data authentication unit A51, and the system authentication unit A61 are realized.

The CPU 310 may be configured using, for example, an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), an AI (Artificial Intelligence) chip, etc.

The authentication device control program 630 is a general term for programs for realizing the functions of the authentication device A03, and includes, for example, application programs, an OS (Operating System), middleware, various libraries, etc., that run on the authentication device A03.

Memory 320 can be configured, for example, by a semiconductor memory device. Memory 320 is a device that stores programs and data, and is, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), or a non-volatile memory (NVRAM (Non Volatile RAM)).

The storage device 340 is a device that provides a physical storage area for storing various programs, data, tables, etc. The storage device 340 is, for example, a solid state drive (SSD).
, a hard disk drive, an optical storage device (such as a CD (Compact Disc), a DVD (Digital Versatile Disc)), a storage system, an IC card, a reader/writer for a non-transitory storage medium such as an SD card or an optical storage medium, a non-transitory storage area of a cloud server, etc. Programs and data can be read into the storage device 340 from other information processing devices equipped with a non-transitory storage medium or a non-transitory storage device via a storage medium reader or communication device 330. The programs and data stored (memorized) in the storage device 340 are read into the memory 320 as needed.

In this embodiment, as shown in FIG. 18, the storage device 340 stores various data such as the authentication device control program 630, attribute rules A32, ID attribute authentication results A33, process models A42, process authentication results A43, data quality rules A52, data authentication results A53, system rules A62, and system authentication results A63.

The memory device 340 may be built into the authentication device A03 or may be externally attached.

The recording medium reader 370 reads programs and data recorded on a recording medium 800 such as a CD-ROM or DVD, and stores them in the storage device 340.

The communication device 330 is a device that realizes communication with other devices. The communication device 330 is a wired or wireless communication interface that realizes communication with other devices that comply with a specific communication protocol via the network 500, and is, for example, a NIC (Network Interface Card), a wireless communication module, etc.

For example, the communication device 330 transmits and receives data and programs to and from other computers such as the construction and deployment device A01 and the system-related device A02 via a network 500 such as the Internet or a LAN (Local Area Network). For example, the above-mentioned authentication device control program 630 can be stored in another computer (not shown), and the authentication device A03 can download and execute the authentication device control program 630 from this computer.

In addition, the authentication device A03 may not have a storage device 340, and may instead function as the authentication device A03 using various data such as the above programs and tables stored in another computer (not shown) that is communicatively connected via the network 500.

The input device 350 is a device used by an operator or the like to input data into the authentication device A03, and functions as a user interface. Examples of the input device 350 that can be used include a keyboard, a mouse, a touch panel, a card reader, a pen-input tablet, a microphone, etc.

The output device 360 is a device for outputting information to the outside and functions as a user interface. The output device 360 is, for example, a display device (liquid crystal monitor, LCD (Liquid Crystal Display), graphic card, etc.) that visualizes the various information described above, a device (audio output device (speaker, etc.)) that converts the various information described above into audio, and a device (printer, etc.) that converts the various information described above into text. Note that, for example, the authentication device A03 may be configured to input and output information between it and other devices via the communication device 330.

The input device 350 and the output device 360 constitute a user interface that realizes interactive processing with the user (receiving information, providing information, etc.).
The authentication device A03 may be implemented with, for example, an operating system, a file system, a DBMS (DataBase Management System) (relational database, NoSQL, etc.), a KVS (Key-Value Store), etc.

<Construction and deployment device>
The construction and deployment device A01 includes a CPU 110, a memory 120, a communication device 130, and a storage device 14.
0, an input device 150, an output device 160 and a recording medium reading device 170.

The CPU 110 is responsible for the overall control of the construction and deployment device A01, and is a processor that realizes the various functions of the construction and deployment device A01 described in this embodiment by reading the construction and deployment device control program 610, which is composed of code for performing various operations related to this embodiment stored in the storage device 140, and various data into the memory 120 and executing or processing them.

For example, the CPU 110 executes or processes the construction and deployment device control program 610 and various data, and by working with hardware devices such as the memory 120, communication device 130, and storage device 140, various functions such as the data repository A10, build A11, container repository A12, deployment A13, and process log A14 are realized.

The construction and deployment device control program 610 is a general term for programs for realizing the functions of the construction and deployment device A01, and includes, for example, application programs, an OS (Operating System), middleware, various libraries, etc. that run on the construction and deployment device A01.

In this embodiment, as shown in FIG. 16, the storage device 140 stores various data such as the construction and deployment device control program 610, a data repository A10, a container repository A12, and a process log A14.

As mentioned above, the construction and deployment device A01 has a common configuration with the authentication device A03, so duplicate explanations will be omitted.

<System-related equipment>
The system-related device A02 is configured to include a CPU 210, a memory 220, a communication device 230, a storage device 240, an input device 250, an output device 260, and a recording medium reading device 270.

The CPU 210 is responsible for the overall control of the system-related device A02, and is a processor that realizes the various functions of the system-related device A02 described in this embodiment by reading into the memory 220 and executing or processing the system-related device control program 620, which is composed of code for performing various operations related to this embodiment stored in the storage device 240, and various data.

For example, the CPU 210 executes or processes the system-related device control program 620 and various data, and by working with hardware devices such as the memory 220, communication device 230, and storage device 240, the functions of the system platform A20, deployment log A21, service provision system A22, etc. are realized.

The system-related device control program 620 is a general term for programs for realizing the functions of the system-related device A02, and includes, for example, application programs, an OS (Operating System), middleware, various libraries, etc., that run on the system-related device A02.

In this embodiment, as shown in FIG. 17, the storage device 240 stores various data such as the system-related device control program 620, the system platform A20, the deployment log A21, and the service providing system A22.

As mentioned above, the system-related device A02 has a common configuration with the authentication device A03, so duplicate explanations will be omitted.

The authentication device A03, the control method and the program for the authentication device A03 according to this embodiment have been described in detail above. According to this embodiment, it becomes possible to authenticate the service providing system A22 constructed to provide an information processing service. For example, it becomes possible to authenticate that the construction of the service providing system A22 is performed by a legitimate processing entity processing legitimate data in a legitimate procedure.

In addition, by enabling a third party to verify, through a chain of trust, the appropriateness of the process used when building and modifying the service provision system A22 and whether or not elements have been tested, it becomes possible to determine whether the service provision system A22 is likely to return the expected results.

In addition, by issuing an electronic certificate to prove that the service providing system A22 is legitimately constructed, users of the service providing system A22 can understand the status of the service providing system A22 by checking the electronic certificate issued by the authentication device A03. In this case, the users do not need to perform the verification themselves, and only need to trust the authentication device A03. In particular, in this embodiment, only the root authentication unit A30 needs to be trusted.

The above-described embodiment is intended to facilitate understanding of the present invention, and is not intended to limit the present invention. The present invention may be modified or improved without departing from its spirit, and equivalents are also included in the present invention.

In addition, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as a program, table, file, etc. that realizes each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

In addition, the control lines and information lines shown are those considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be assumed that almost all components are interconnected.

A00 Information processing system A01 Construction and deployment device 110 CPU
120 Memory 130 Communication device 140 Storage device 150 Input device 160 Output device 170 Recording medium reading device A10 Data repository A11 Build A12 Container repository A13 Deployment A14 Process log A02 System related device 210 CPU
220 Memory 230 Communication device 240 Storage device 250 Input device 260 Output device 270 Recording medium reading device A20 System platform A21 Deployment log A22 Service providing system A03 Authentication device 310 CPU
320 Memory 330 Communication device 340 Storage device 350 Input device 360 Output device 370 Recording medium reading device A30 Root authentication unit A31 ID attribute authentication unit A32 Attribute rules A33 ID attribute authentication result A41 Process authentication unit A42 Process model A43 Process authentication result A51 Data authentication unit A52 Data quality rules A53 Data authentication result A61 System authentication unit A62 System rules A63 System authentication result B00 Process log information C00 Deployment log information D00 ID authentication result information E00 Attribute authentication result information F00 Process authentication result information G00 Data authentication result information H00 System authentication result information M00 Certificate chain 500 Network 610 Construction and deployment device control program 620 System-related device control program 630 Authentication device control program 800 Recording medium

Claims (10)

An authentication device that performs authentication of a service providing system that is configured to provide a predetermined information processing service by executing a service providing program,
A processor and a memory,
a data authentication unit that authenticates the validity of data used when constructing the service providing system, the data including the service providing program;
an ID attribute authentication unit that authenticates the legitimacy of a processing entity that constructs the service providing system using the data;
a process authentication unit that authenticates the validity of a procedure for constructing the service providing system;
a system authentication unit that authenticates that the service providing system has been properly constructed when the authenticity of the data, the authenticity of the processing entity, and the authenticity of the procedure have been authenticated, and outputs a certificate for proving that the service providing system has been properly constructed ;
An authentication device comprising: 2. The authentication device according to claim 1,
a route authentication unit that authenticates the authenticity of the data authentication unit, the ID attribute authentication unit, the process authentication unit, and the system authentication unit;
The authentication device further comprises: 2. The authentication device according to claim 1,
An authentication device, wherein the processing entity includes a software module that performs processing to construct the service provision system using the data, and a person in charge of performing work to construct the service provision system using the software module. 2. The authentication device according to claim 1,
An authentication device, wherein the data includes, in addition to the service providing program, reference data used by the service providing program when providing the information processing service, and a configuration definition file that represents the configuration of the service providing system. A method for controlling an authentication device that performs authentication on a service providing system that is configured to provide a predetermined information processing service by executing a service providing program, comprising the steps of:
The authentication device,
Authenticating the authenticity of data used in constructing the service providing system, including the service providing program;
authenticating the legitimacy of a processing entity that constructs the service providing system using the data;
Authenticating the validity of a procedure for constructing the service providing system;
certifying that the service providing system has been legitimately constructed when the legitimacy of the data, the legitimacy of the processing entity, and the legitimacy of the procedure have been authenticated ;
outputting a certificate for proving that the service providing system is legitimately constructed ;
A method for controlling an authentication device. A method for controlling an authentication device according to claim 5 ,
A control method for an authentication device, wherein the processing entity includes a software module that performs processing to construct the service provision system using the data, and a person in charge of performing work to construct the service provision system using the software module. A method for controlling an authentication device according to claim 5 ,
A control method for an authentication device, wherein the data includes, in addition to the service providing program, reference data used by the service providing program when providing the information processing service, and a configuration definition file that represents the configuration of the service providing system. A program for causing a computer having a processor and a memory to execute authentication of a service providing system configured to provide a predetermined information processing service by executing a service providing program,
The computer includes:
a step of authenticating the validity of data used in constructing the service providing system, the data including the service providing program;
a step of authenticating the legitimacy of a processing entity that constructs the service providing system using the data;
a step of authenticating the validity of a step of constructing the service providing system;
a step of authenticating that the service providing system is legitimately constructed when the authenticity of the data, the authenticity of the processing entity, and the authenticity of the procedure are authenticated;
a step of outputting a certificate for proving that the service providing system is legitimately constructed;
A program for executing. The program according to claim 8 ,
A program, wherein the processing entity includes a software module that performs processing to construct the service provision system using the data, and a person in charge of performing the work of constructing the service provision system using the software module. The program according to claim 8 ,
The data includes, in addition to the service providing program, reference data used by the service providing program when providing the information processing service, and a configuration definition file that represents the configuration of the service providing system.

Images