WO2022270385A1 - プログラム、情報処理装置、方法 - Google Patents

プログラム、情報処理装置、方法 Download PDF

Info

Publication number
WO2022270385A1
WO2022270385A1 PCT/JP2022/024004 JP2022024004W WO2022270385A1 WO 2022270385 A1 WO2022270385 A1 WO 2022270385A1 JP 2022024004 W JP2022024004 W JP 2022024004W WO 2022270385 A1 WO2022270385 A1 WO 2022270385A1
Authority
WO
WIPO (PCT)
Prior art keywords
system call
call function
container
called
monitoring
Prior art date
Application number
PCT/JP2022/024004
Other languages
English (en)
French (fr)
Inventor
範崇 飯嶋
勉 中島
浩二 大西
Original Assignee
デジタル・インフォメーション・テクノロジー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by デジタル・インフォメーション・テクノロジー株式会社 filed Critical デジタル・インフォメーション・テクノロジー株式会社
Priority to EP22828302.4A priority Critical patent/EP4361860A1/en
Priority to JP2023530378A priority patent/JP7489548B2/ja
Publication of WO2022270385A1 publication Critical patent/WO2022270385A1/ja
Priority to US18/534,919 priority patent/US20240231959A9/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present disclosure relates to programs, information processing devices, and methods.
  • a storage medium for analyzing malware in a virtual computer running on a physical computer having a processor and memory wherein an analysis unit running on a guest OS of the virtual computer acquires a request from the malware to the guest OS a first step, and a second step in which, if the request from the malware includes a request related to a virtual environment, the analysis unit sends a disguised response to the request to the malware.
  • the "security system” "provides a security virtual machine that executes a security program expressed in the instruction set of the security virtual machine.”
  • the security virtual machine uses the data of the security enforcement event to execute the instructions in the instruction store and enforce the security policy.
  • Patent Document 1 if the technology of Patent Document 1 is applied to a container-type virtualization environment, it is believed that security measures can be taken for each container before using the container image.
  • the container image is deployed to the container host, and when the container is created based on the container image and the container is running, the common OS is used, so it is necessary to take security measures for the container image of each container. I have a problem that I can't.
  • Patent Document 2 when the technique of Patent Document 2 is applied to a container-type virtual environment, a system call is simulated by a security virtual machine. The advantage of container-type virtualization that it can be done is lost.
  • a program for operating a computer having a processor wherein the program acquires parameters when a system call function is called by a system call to the processor in a container-type virtualization environment. and if the processing target in the first system call function to be called indicated by the parameter is not a monitoring target that affects the identity of the container image, call the first system call function from the kernel, returning a processing result of a first system call function; and when the target of processing in the first system call function to be called, which is indicated by the parameter, is the one to be monitored, the first system call function is called.
  • a step of returning a result as if the processing by the system call was executed normally or a processing result as an error is executed.
  • FIG. 1 is a diagram showing a configuration of an information processing system 1;
  • FIG. 2 is a block diagram of the information processing device 10;
  • FIG. 1 is a diagram showing an example of a conventional system call flow;
  • FIG. 1 is a diagram showing an example of a conventional system call flow;
  • FIG. 4 is a diagram illustrating processing of system calls of the present disclosure;
  • FIG. 10 is a diagram showing an example of a screen for selecting a container to be monitored; 4 is a flowchart showing a monitoring instruction process of the information processing device 10;
  • 4 is a flowchart showing monitoring processing of the information processing apparatus 10;
  • 4 is a flowchart showing monitoring target designation processing of the information processing apparatus 10;
  • FIG. 4 is a diagram showing an example of an operation image of a container within a container host;
  • FIG. 10 illustrates an example of when an image in a container host is deleted;
  • FIG. 10 is a diagram illustrating an example in which an image in a container host has been tampered with;
  • 2 is a diagram showing a configuration of an information processing system 2;
  • FIG. 3 is a block diagram of an information processing device 50;
  • FIG. 4 is a flowchart showing monitoring processing of the information processing device 50;
  • the present disclosure describes a program, an information processing device, and a method for monitoring parameters when a system call function is called by a system call and protecting a container image in a container-type virtualization environment.
  • the container-type virtualization environment on the container host In order for the container-type virtualization environment on the container host to operate stably, it is necessary to protect the container image directories and files placed on the container host from being tampered with by deleting or overwriting them. At the same time, it is necessary to protect the container image directory path, directory name, file name, etc. from being changed so that the setting information held by the container-related application does not become inconsistent. In order to protect these, from the point of view that the container-type virtualization environment operates by sharing the kernel of the container host unlike the conventional virtual machine, in the present disclosure, the system call of the kernel of the container host is monitored. .
  • a processor rewrites a call target of a system call that may affect the identity of a container image so that a second system call function separately prepared with information in a system call table is called, so that a second system call function is called. Get parameters in the call function. Then, the processor determines whether or not the processing target indicated by the parameter is the monitoring target, and if it is not the monitoring target, the first system call function which is the system call function originally called in the second system call function. and return the result of the processing. On the other hand, when the target of processing indicated by the parameter is the target of monitoring, the processor invalidates the processing of the original system call within the second system call function. In other words, the present disclosure disables only system calls to objects that affect container image identity. Invalidation is performed, for example, by not processing the system call or returning an error.
  • FIG. 1 is a diagram showing the configuration of the information processing system 1. As shown in FIG.
  • the information processing system 1 includes an information processing device 10 , an administrator terminal 20 and a network 30 .
  • the information processing device 10 is, for example, a laptop computer, a rack-mount type or tower type computer, or the like.
  • the information processing device 10 may be configured by a plurality of information processing devices 10 and the like.
  • the information processing device 10 includes a processor 11, a memory 12, a storage 13, a communication IF 14, and an input/output IF 15.
  • the processor 11 is hardware for executing an instruction set described in a program, and is composed of arithmetic units, registers, peripheral circuits, and the like.
  • the memory 12 is for temporarily storing programs, data processed by the programs, etc., and is, for example, a volatile memory such as a DRAM (Dynamic Random Access Memory).
  • DRAM Dynamic Random Access Memory
  • the storage 13 is a storage device for storing data, such as flash memory, HDD (Hard Disc Drive), SSD (Solid State Drive).
  • HDD Hard Disc Drive
  • SSD Solid State Drive
  • the communication IF 14 is an interface for inputting and outputting signals so that the information processing device 10 communicates with an external device.
  • the communication IF 14 is wired or wirelessly connected to a network 30 such as the Internet or wide area Ethernet.
  • the input/output IF 15 functions as an interface with an input device (for example, a pointing device such as a mouse, a keyboard) for accepting input operations, and an output device (display, speaker, etc.) for presenting information.
  • an input device for example, a pointing device such as a mouse, a keyboard
  • an output device for presenting information.
  • the administrator terminal 20 is an information processing device operated by a user who manages the container-type virtual environment executed by the information processing device 10 .
  • the administrator terminal 20 is, for example, a laptop computer or a computer such as a rack-mount type or tower type.
  • the information processing device 10 and the administrator terminal 20 are configured to communicate with each other via the network 30 .
  • FIG. 2 is a block diagram showing the functional configuration of the information processing device 10. As shown in FIG. As shown in FIG. 2, the information processing apparatus 10 includes a communication section 110, a storage section 120, and a control section .
  • the communication unit 110 performs processing for the information processing device 10 to communicate with an external device.
  • the storage unit 120 stores data and programs used by the information processing device 10 .
  • the storage unit 120 stores container-related data, a system call table, a first system call function group, a second system call function group, and the like.
  • the data related to the container is data necessary for the information processing device 10 to realize the container-type virtual environment.
  • the data related to containers are container images, container data, and the like.
  • the system call table is a predetermined system call table in the system.
  • the first system call function group is a set of system call functions predetermined in the system.
  • the second system call function group is a set of system call functions defined in this disclosure. Details will be described later.
  • the control unit 130 includes a reception control unit 131, a transmission control unit 132, a container control unit 133, a monitoring instruction unit 134, a rewriting unit 135, an acquisition unit 136, a monitoring
  • the functions shown in the portion 137 and the display portion 138 are exhibited.
  • the reception control unit 131 controls the process by which the information processing device 10 receives signals from an external device according to a communication protocol.
  • the transmission control unit 132 controls the process of transmitting a signal from the information processing device 10 to an external device according to a communication protocol.
  • the container control unit 133 implements a container-type virtual environment. Specifically, upon receiving the container creation signal, the container control unit 133 creates a container from the container image stored in the storage unit 120 .
  • the container control unit 133 implements a container-type virtual environment using, for example, DOCKER (registered trademark).
  • the monitoring instruction unit 134 instructs each unit to start and end system call monitoring.
  • the timing of starting monitoring is preferably when the container host is activated, when a container is first generated on the container host based on the container image arranged on the container host by the container control unit 133, or the like. It should be noted that the timing of starting and ending the monitoring may be determined by receiving manual instructions, periodically, or the like, or may be performed all the time.
  • the monitoring instruction unit 134 terminates monitoring at the timing when an instruction to terminate monitoring is issued, at the timing when all containers are deleted, or the like.
  • the rewriting unit 135 detects a result or an error such as when the processing by the system call function is normally executed. Rewrite the system call table so that the second system call function that returns a result of Specifically, the rewriting unit 135 rewrites the address of the first system call function to be monitored in the system call table to the address of the second system call function.
  • the second system call function is configured to include the address of the corresponding first system call function. This is because when the parameter is checked in the second system call function, if it is safe, the original first system call function is called for processing. Also, the rewriting unit 135 may be configured to replace the first system call function with the second system call function.
  • a monitoring target is defined in advance as a combination of the contents of processing of a process that calls a system call function and at least one of a target file and target directory of the process processing.
  • An object to be monitored is, for example, at least one of the combinations of directories, files and processes described in (1) to (14) below.
  • hard links are included in the processing of directories, etc. is to prevent tampering with directories, files, etc. via hard links other than under the directory where the container image is stored.
  • the rewriting unit 135 rewrites the system call table at the timing when the kernel is read, when the monitoring instruction unit 134 issues a monitoring start instruction, and so on. Further, the rewriting unit 135 restores the rewritten system call table when the monitoring instruction unit 134 issues a monitoring end instruction.
  • the acquisition unit 136 acquires parameters when the first system call function is called by the system call. Specifically, the acquisition unit 136 acquires the target and process handled by the system call function as parameters when the first system call function is called.
  • the monitoring unit 137 determines whether the processing target of the first system call function to be called is the monitoring target that affects the identity of the container image. Specifically, the monitoring unit 137 first calls the system call function to be called by referring to the rewritten system call table. If it is a system call function that has not been rewritten, the first system call function is called by the system call table. The monitoring unit 137 executes the first system call function and returns the processing result.
  • the monitoring unit 137 will call the second system call function.
  • the monitoring unit 137 uses the parameters acquired by the acquisition unit 136 to determine whether or not it is a monitoring target. Specifically, the monitoring unit 137 determines whether or not the parameter indicates a predetermined process for the directory and file.
  • the monitoring unit 137 determines that the parameter is to be monitored, the monitoring unit 137 returns the result of the second system call function to the second system call function. On the other hand, when the monitoring unit 137 determines that the parameter is not to be monitored, the monitoring unit 137 actually calls the first system call function. In this case, the monitoring unit 137 executes the first system call function and returns the processing result.
  • the second system call function may have a function of determining whether the parameter is a predetermined process for the above directory and file. In this case, if the determination result is the object to be monitored, the second system call function returns a result such as when the actual processing by the first system call function is normally executed or an error processing result. Also, in this case, the second system call function actually calls the first system call function to execute the process and returns the process result if the determination result is not the object to be monitored.
  • FIGS. 3 and 4 are diagrams showing an example of a conventional system call flow.
  • the examples of FIGS. 3 and 4 are for the x86_64 architecture.
  • a user process UserProcess in FIG. 3
  • the kernel is called by the system call handler (System Call Handler in FIG. 4) from the interrupt descriptor table (Interrupt Descriptor Table in FIG. 4).
  • the kernel calls and executes each system call function from the system call table (System Call Table in FIG. 4) based on the system call number within the system call handler. That is, all system call functions are called via the system call table.
  • the present disclosure prepares a second system call function that returns a result such as when the processing by the first system call function is executed normally or an error result.
  • FIG. 5 is a diagram showing the system call processing of the present disclosure. As shown in FIG. 5, by rewriting the system call table, the second system call function (the system call function within the Kernel Module in FIG. 5) is configured to be called.
  • the second system call function the system call function within the Kernel Module in FIG. 5
  • the second system call function By rewriting the address of the first system call function to be monitored in the system call table to the address of the second system call function in this way, the actual first system call function that executes the predetermined processing for the directories and files is Instead, the second system call function will be called.
  • the second system call function returns results or errors as if it had executed successfully, but does not actually perform the processing of the first system call function. Therefore, it is possible to prevent the directory and files from being tampered with, and to protect the container image, whether from the container host side or from the malicious host side. If the first system call function to be monitored does not execute the predetermined processing for the directory and file, the actual first system call function is set to be indirectly called.
  • the display unit 138 displays a screen for receiving specification and cancellation of specification of at least one container image among a plurality of container images in the container-type virtual environment. Specifically, the display unit 138 displays a screen for accepting designation of a container image.
  • the specified container image becomes a parameter acquired by the acquiring unit 136 and a container image to be judged by the monitoring unit 137 .
  • the display unit 138 causes the administrator terminal 20 to display the screen, for example.
  • FIG. 6 is a diagram showing an example of a screen for selecting containers to be monitored.
  • the screen 220 includes container image buttons 222 to 224 , a monitoring start button 226 and a monitoring end button 227 .
  • the container image buttons 222 to 224 are buttons for accepting designation of container images. Also, the container image buttons 222 to 224 display the state of the container indicated by the container image. When the container image button is white, it indicates that the container of the container image indicated by the container image button has been generated. When the container image button is filled, it indicates that the container of the container image indicated by the container image button has not been generated. When the container image button is shaded, it indicates that the container image indicated by the container image button is being monitored. When the container image button is pressed, the container image indicated by the container image button is specified.
  • a monitoring start button 226 is a button for starting monitoring of a specified container image. Specifically, when the monitoring start button 226 is pressed, the monitoring instruction unit 134 starts monitoring the container images of the currently pressed container image buttons 222 to 224 .
  • a monitoring end button 227 is a button for ending monitoring of a specified container image. Specifically, when the monitoring start button 226 is pressed, the monitoring instruction unit 134 terminates monitoring of the container images of the currently pressed container image buttons 222 to 224 .
  • the display unit 138 displays an interface such as the screen 220 so that the user can explicitly give an appropriate instruction.
  • the container-type virtualization environment of the present disclosure can also be configured to perform API linkage with a container orchestration tool such as Kubernetes (registered trademark), and to start monitoring and cancel monitoring of container images placed on the container host. good.
  • a container orchestration tool such as Kubernetes (registered trademark)
  • FIG. 7 is a flowchart showing an example of the flow of monitoring instruction processing by the information processing apparatus 10.
  • the information processing device 10 executes the processing at the timing when the kernel is read into the information processing device 10 .
  • the monitoring is started automatically when the container host is activated, when a container is first generated on the container host based on the container image arranged on the container host by the container control unit 133, and so on. It is good also as a structure which starts.
  • the monitoring may be started when the monitoring instruction unit 134 issues a monitoring start instruction.
  • step S101 the rewriting unit 135 rewrites the address of the first system call function to be monitored in the system call table to the address of the second system call function.
  • step S102 the monitoring instruction unit 134 starts monitoring system calls.
  • step S103 the processor 11 determines whether or not there is an instruction to end monitoring.
  • step S104 the monitoring instruction unit 134 determines whether or not there is a container in operation.
  • step S104 If there is a container in operation (N in step S104 above), the process returns to step S103, and the monitoring instruction unit 134 continues monitoring until an end instruction is received. At this time, if monitoring has been suspended, the monitoring instruction unit 134 resumes monitoring.
  • the monitoring instruction unit 134 stops monitoring in step S105.
  • the monitoring instruction unit 134 issues an instruction to end monitoring of system calls in step S106.
  • FIG. 8 is a flowchart showing an example of the flow of monitoring processing by the information processing apparatus 10. As shown in FIG. The information processing apparatus 10 executes the process at the timing when the second system call function is called by the rewritten system call table in a situation where monitoring is started. When a system call function that has not been rewritten is called, normal system call function calling processing is performed.
  • step S111 the monitoring unit 137 refers to the system call table in which the system call function to be called is rewritten. Thereby, the monitoring unit 137 acquires the address of the second system call function.
  • step S112 the monitoring unit 137 calls the second system call function to be called.
  • step S113 the monitoring unit 137 acquires parameters when the system call function is called by the system call.
  • step S114 the monitoring unit 137 determines whether the parameter is to be monitored.
  • the monitoring unit 137 calls the first system call function in step S115.
  • step S116 the monitoring unit 137 causes the called first system call function to execute processing.
  • step S117 the monitoring unit 137 returns the processing result and terminates the processing.
  • the monitoring unit 137 returns a result as if the processing by the first system call function was normally executed or an error processing result in step 118, End the process.
  • FIG. 9 is a flowchart showing monitoring target designation processing of the information processing apparatus 10 .
  • the information processing apparatus 10 executes the process at arbitrary timing.
  • step S121 the display unit 138 displays a screen for accepting specification and cancellation of specification of at least one container image among a plurality of container images in the container-type virtual environment.
  • step S122 the display unit 138 accepts designation of a container image.
  • step S123 the display unit 138 accepts the start or end of monitoring.
  • step S124 the display unit 138 causes the monitoring instruction unit 134 to start or end monitoring of the currently designated container image, and the process ends.
  • a parameter is obtained when a first system call function is called by a system call, and the first system call to be called indicated by the parameter is obtained. If the processing target in the function is not the monitoring target that affects the identity of the container image, call the first system call function from the kernel, return the processing result of the first system call function, and the parameter indicates , when the target of processing in the first system call function to be called is the one to be monitored, the first system call function is not called and the result is as if the processing by the system call was executed normally. Alternatively, by returning an error processing result, it is possible to protect the running container image.
  • the container-type virtualization environment has the advantage of being much faster to start and using less host OS resources.
  • security measures for container-type virtualization environments often cannot be handled by conventional security measures (for example, NIST (National Institute of Standards and Technology) security measures Application Container Security Guide (Special Publication 800-190)).
  • NIST National Institute of Standards and Technology
  • Security measures Application Container Security Guide (Special Publication 800-190)
  • current security measures for containers emphasize container monitoring, and take measures such as isolating containers when an abnormality is detected.
  • Such security measures require definition, management, updating, etc., depending on the functions of the container and the installed applications, so the load is extremely high, and erroneous detection or non-detection may occur due to omission of definitions.
  • the monitoring software will adopt the container image, which is the origin of the container, as a security measure for the container.
  • the monitoring software scans the container image for vulnerabilities before using it, adds an electronic signature to the container image, and checks if the container image has been tampered with before using it. There is a way.
  • the common OS is used, so it is necessary to take security measures for the container image of each container. Can not.
  • FIG. 11 is a diagram showing an example of an operation image of a container within a container host.
  • a container image 1010 image layer developed in a file system on a container host 1000 stores a file system and meta information required for execution of the container.
  • the file system stores a portion corresponding to the OS such as /etc, /bin, /usr under the root directory, and a directory hierarchy and files such as applications used by the container.
  • each container operates on a container host by using most of the container image 1010 that is the origin of the creation, the part corresponding to the OS, the application part, and the like.
  • the container side can only read the information of the container image, and cannot rewrite it.
  • the container image is just a directory, a group of files, etc. on the OS, and the container host can add/change/delete the container image.
  • FIG. 12 is a diagram showing an example when an image in a container host is deleted. If the container image is deleted from the container host, all containers will be inoperable in an instant because there is no reference to the meta information held on the container side.
  • the container generated from the deleted image is deleted because the reference destination data (data block, etc.) on the container image side stored in the meta information of the container image held on the container side does not exist. It will stop all at once (become unable to operate) at the timing. Also, if it is partially deleted, there is a possibility that the operation of the container will be affected (behavior will become strange).
  • FIG. 13 is a diagram showing an example in which the image in the container host has been tampered with. If you tamper with the container image so that the reference destination of the meta information held on the container side does not change, that is, if you tamper with the container image file by overwriting, when the container side reads that file , stop, or change behavior.
  • the container generated from the deleted image is deleted because the reference destination data (data block, etc.) on the container image side stored in the meta information of the container image held on the container side does not exist. It will stop all at once (become unable to operate) at the timing. Also, if it is partially deleted, there is a possibility that the operation of the container will be affected (behavior will become strange).
  • the above guidelines include ⁇ Use a reliable container image that is not contaminated with malware, etc. ⁇ The container host on which the container operates should have the minimum necessary functions and should not have unnecessary functions. ⁇ Perform access control to container images such as SELinux and AppArmor so that the above-mentioned container images cannot be deleted or tampered with. etc. is described.
  • the technology of this disclosure can be used to By reliably protecting images, it is possible to implement sufficient security measures for containers.
  • the technology of the present disclosure monitors parameters when a system call function is called by a system call, and protects differential data used for backing up a container image as data to be protected. An apparatus and method are described.
  • a technology for example, UnionFS that transparently overlaps files and directories of a file system is used.
  • the container-based virtualization environment may have first-, second-, and third-tier file systems.
  • the first layer is the layer that manages the container image itself. For example, it corresponds to the image layer in FIG.
  • Objects of protection in the first embodiment are container images managed in the first layer.
  • the second layer is a layer that manages the difference data between the container image of the first layer and the current state of the container image according to the operations performed on the container image. For example, it corresponds to the container layer in FIG.
  • the differential data is stored in a storage unit or the like at an arbitrary timing as data used for backup.
  • the third layer is the file system that is visible from inside the container. Specifically, it performs operations on container images according to the authority of the process. For example, when the third layer file system receives a predetermined container image deletion command from a process that has the right to delete container images, it passes the fact that the container image has been deleted to the second layer file system. Then, the second layer file system generates differential data indicating that the container image has been deleted. At this time, the container image is not deleted in the first layer. Layer 3 merges information from layers 1 and 2 to allow processes that reference container images to reference the current container image.
  • FIG. 13 is a diagram showing the configuration of the information processing system 2. As shown in FIG.
  • the information processing system 2 includes an information processing device 50 , an administrator terminal 20 and a network 30 .
  • FIG. 14 is a block diagram showing the functional configuration of the information processing device 50. As shown in FIG. As shown in FIG. 14 , information processing device 50 includes communication section 110 , storage section 520 , and control section 230 .
  • the storage unit 520 stores data and programs used by the information processing device 50 .
  • the storage unit 520 stores container-related data, a system call table, a first system call function group, a second system call function group, and the like.
  • the storage unit 520 has a function as a database that manages data related to containers as a file system including the structures of the first to third layers.
  • the control unit 230 includes a reception control unit 131, a transmission control unit 132, a container control unit 133, a monitoring instruction unit 234, a rewriting unit 235, an acquisition unit 136, a monitoring
  • the functions shown in the section 237, the display section 238, the backup section 239, and the recovery section 240 are exhibited.
  • the monitoring instruction unit 234 instructs each unit to start and end system call monitoring.
  • the monitoring instruction unit 234 can adopt arbitrary timing as the timing for instructing the start of monitoring.
  • the timing at which the monitoring instruction unit 234 instructs the start of monitoring the timing at which the differential data used for backing up the container image is generated, the timing at which the differential data is stored in the storage unit 520, or the like can be used.
  • the timing at which the monitoring instruction unit 234 instructs the start and end of monitoring may be such as receiving manual instructions, periodically, or the like, or may be performed all the time.
  • the monitoring instruction unit 234 terminates monitoring at the timing when the monitoring termination instruction is issued, at the timing when all the containers are deleted, and the like.
  • the rewriting unit 235 is configured to detect a result or an error such as when the processing by the system call function is normally executed. Rewrite the system call table so that the second system call function that returns a result of Specifically, the rewriting unit 235 rewrites the address of the first system call function to be monitored in the system call table to the address of the second system call function.
  • the second system call function is configured to include the address of the corresponding first system call function. This is because when the parameter is checked in the second system call function, if it is safe, the original first system call function is called for processing. Also, the rewriting unit 235 may be configured to replace the first system call function with the second system call function.
  • a monitoring target in the rewriting unit 235 is defined in advance as a combination of at least one of the processing contents of the process that calls the system call function and the target file and target directory of the process processing.
  • An object to be monitored is, for example, at least one of the combinations of directories, files and processes described in (1) to (14) below.
  • hard links are included in the processing of directories, etc. is to prevent tampering with directories, files, etc. via hard links other than under the directory where the container image is stored.
  • the rewriting unit 235 rewrites the system call table at the timing when the kernel is read, when the monitoring instruction unit 234 issues a monitoring start instruction, or the like. Further, the rewriting unit 235 restores the rewritten system call table when the monitoring instruction unit 234 issues a monitoring end instruction.
  • the monitoring unit 237 determines whether or not the processing target of the first system call function to be called is the monitoring target that affects the identity of the difference data. Specifically, the monitoring unit 237 first calls the system call function to be called by referring to the rewritten system call table. If it is a system call function that has not been rewritten, the first system call function is called by the system call table. The monitoring unit 237 executes the first system call function and returns the processing result. As for the function of the monitoring unit 237, the function of the monitoring unit 137 can be applied mutatis mutandis to the difference data.
  • the display unit 238 displays a screen for receiving specification and cancellation of specification of at least one differential data among the plurality of differential data in the container-type virtual environment. Specifically, the display unit 238 displays a screen for receiving specification of a container image.
  • the designated difference data is the parameter to be obtained by the obtaining unit 136 and the difference data to be determined by the monitoring unit 237 .
  • the display unit 238 causes the administrator terminal 20 to display the screen, for example.
  • the parameters acquired by the acquisition unit 136 and the difference data to be determined by the monitoring unit 237 may be all the difference data until they are explicitly selected.
  • the backup unit 239 acquires the differential data of the container image and stores the differential data in the storage unit 520 as a backup file.
  • the backup unit 239 acquires differential data between the second layer container image and the first layer container image at any timing.
  • the arbitrary timing may be regular timing, predetermined timing, or the like.
  • the backup unit 239 acquires differential data at arbitrary backup timing such as once an hour or once a day.
  • the backup unit 239 stores the acquired difference data in the storage unit 520.
  • the difference data stored in the storage unit 520 by the backup unit 239 is data to be protected in the second embodiment.
  • the backup unit 239 stores the differential data in the storage unit 520 at arbitrary timings. At this time, the backup unit 239 may be configured to delete differential data before a predetermined generation.
  • the restoration unit 240 restores the container image up to the determined generation using the container image of the first layer and the difference data in response to receiving the input of the restoration instruction.
  • the recovery unit 240 first accepts input of a recovery instruction.
  • the restoration instruction includes the generation to be restored, the date and time to be restored, and the like.
  • the recovery unit 240 acquires from the storage unit 520 the difference data and the first layer container image according to the information included in the recovery instruction, such as the generation and date.
  • the restoration unit 240 restores the container image using the acquired differential data and the container image of the first layer.
  • the recovery unit 240 generates a container image by merging the acquired differential data and the first layer container image.
  • the restoration unit 240 stores the generated container image in the storage unit 520 as a new container image of the first layer.
  • FIG. 15 is a flowchart showing an example of the flow of monitoring processing by the information processing device 50.
  • the information processing device 50 executes the process at the timing when the second system call function is called by the rewritten system call table in a situation where monitoring is started.
  • step S211 the monitoring unit 237 refers to the system call table in which the system call function to be called is rewritten. Thereby, the monitoring unit 237 acquires the address of the second system call function.
  • step S212 the monitoring unit 237 calls the second system call function to be called.
  • step S213 the monitoring unit 237 acquires parameters when the system call function is called by the system call.
  • step S214 the monitoring unit 237 determines whether the parameter is to be monitored.
  • the monitoring unit 237 calls the first system call function in step S115.
  • step S216 the monitoring unit 237 causes the called first system call function to execute processing.
  • step S217 the monitoring unit 237 returns the processing result and terminates the processing.
  • the monitoring unit 237 returns in step 118 a result as if the processing by the first system call function was normally executed or an error processing result, End the process.
  • a parameter is obtained when a first system call function is called by a system call, and the first system call to be called indicated by the parameter is obtained.
  • the processing target of the function is not a monitoring target that affects the identity of the differential data used for backing up the container image in the container-type virtualization environment
  • the kernel calls the first system call function, and the first system Returns the processing result of the call function, and if the target of processing in the first system call function to be called, indicated by the parameter, is the target to be monitored, the first system call function is not called, and the system call It is possible to protect the difference file of the container image in operation by returning a result such as when the process by is normally executed or a process result as an error.
  • each function of the information processing device 10 may be configured in another device.
  • the storage unit 120 may be constructed as an external database.
  • the data to be protected is a container image or differential data for backup.
  • a file sharing system for example, SAMBA.
  • Data to be protected is not limited to a container-type virtual environment, and can be various data as long as it is data to be protected from malicious operations by ransomware or the like.
  • container images or differential data for backup are data to be protected.
  • the technology of the present disclosure can employ container images and differential data for backup as data to be protected. In this case, simply by combining the technology disclosed in the first embodiment and the technology disclosed in the second embodiment, it is possible to protect both.
  • Appendix 1 A program for operating an information processing device (10) including a processor and executing a container-type virtual environment, wherein the program causes the processor to call a system call function by a system call.
  • the monitoring target is defined in advance as a combination of at least one of the processing content of the process that calls the first system call function and the target file or target directory of the process, ( The program described in appendix 1).
  • the address of the first system call function to be monitored in the system call table is a second system call function that returns a result such as when the process by the first system call function is normally executed or an error result.
  • An information processing device including a processor (11) that executes a container-type virtual environment, in which a step of acquiring parameters when a system call function is called by a system call (S113); If the processing target in the first system call function to be called indicated by the parameter is not a monitoring target that affects the identity of the container image, the first system call function is called from the kernel, and the first system a step of returning a processing result of the call function (S117); First, a step (S118) of returning a result as if the process by the first system call function was normally executed or a process result as an error.
  • a computer for example, an information processing device 10) that executes a container-type virtual environment including a processor (11) acquires parameters when a system call function is called by a system call (S113); , if the processing target in the first system call function to be called indicated by the parameter is not a monitoring target that affects the identity of the container image, the kernel calls the first system call function,
  • An information processing device including a processor (11), a step of acquiring parameters when a system call function is called by a system call (S113); a step (S117) of calling the first system call function from the kernel and returning the processing result of the first system call function if it is not the one to be monitored; and the first system call function to be called, indicated by the parameter. If the object to be processed in is the object to be monitored, the first system call function is not called, and a result such as a normal execution of the process by the first system call function or an error process result is displayed.
  • An information processing apparatus that executes a returning step (S118).
  • the monitoring target is defined in advance as a combination of the processing content of the process that calls the first system call function and at least one of the target file and target directory of the process.
  • the information processing apparatus according to (Appendix 10).
  • a computer for example, an information processing device 10) including a processor (11) acquires a parameter when a system call function is called by a system call (S113); If the object to be processed by the first system call function is not the object to be monitored that affects the identity of the data to be protected, the first system call function is called from the kernel, and the processing result of the first system call function is returned. and a step of returning (S117), when the target of processing in the first system call function to be called, which is indicated by the parameter, is the one to be monitored, the first system call function is not called, and the first system call function is not called. a step (S118) of returning a result such as if the processing by the call function was executed normally or an error processing result.
  • 1 information processing system 2 information processing system, 10 information processing device, 11 processor, 12 memory, 13 storage, 14 communication IF, 15 input/output IF, 20 administrator terminal, 30 network, 50 information processing device, 110 communication unit, 120 storage unit, 130 control unit, 131 reception control unit, 132 transmission control unit, 133 container control unit, 134 monitoring instruction unit, 135 rewriting unit, 136 acquisition unit, 137 monitoring unit, 138 display unit, 230 control unit, 234 monitoring Instruction unit 235 rewriting unit 237 monitoring unit 238 display unit 239 backup unit 240 restoration unit 520 storage unit.

Landscapes

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

Abstract

プロセッサ（１１）を含む情報処理装置（１０）であって、当該プログラムは、当該プロセッサに、システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップ（Ｓ１１３）と、当該パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、保護対象のデータの同一性に影響を与える監視対象のものでない場合、カーネルから第１システムコール関数を呼び出し、第１システムコール関数の処理結果を返すステップ（Ｓ１１７）と、当該パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、監視対象のものである場合、第１システムコール関数は呼び出さず、第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップ（Ｓ１１８）と、を実行する情報処理装置。

Description

プログラム、情報処理装置、方法
　本開示は、プログラム、情報処理装置、方法に関する。
　従来から、仮想環境におけるセキュリティ対策技術が求められている。「プロセッサとメモリを有する物理計算機上で稼働する仮想計算機でマルウェアを解析する記憶媒体であって、前記仮想計算機のゲストＯＳ上で稼働する解析部が、前記マルウェアから前記ゲストＯＳに対する要求を取得する第１のステップと、前記解析部が、前記マルウェアからの前記要求に仮想化環境に関連する要求が含まれている場合には、当該要求に対して偽装応答を前記マルウェアに対して行う第２のステップと、を含む」技術がある（特許文献１）。
　また、「セキュリティシステム」は、「セキュリティ仮想マシンの命令セット内で表現されたセキュリティプログラムを実行するセキュリティ仮想マシン」を「提供する。セキュリティシステム」は、「セキュリティプログラムをセキュリティ仮想マシン」の「命令ストア」に「格納する。セキュリティ実施イベントが発生するとき、セキュリティ仮想マシン」は、「セキュリティ実施イベントのデータを使用してその命令ストア」の「命令を実行し、セキュリティポリシーを実施する」という技術がある（特許文献２）。
特開２０１８－０８１５１４号公報 特開２００５－３１６９６４号公報
　しかし、特許文献１の技術をコンテナ型仮想化環境に適用すると、コンテナイメージ使用前については、各コンテナのセキュリティ対策ができると考えられる。しかし、コンテナイメージをコンテナホストに展開後、及びコンテナイメージを元にコンテナが生成されてコンテナが稼働中においては、共通のＯＳを用いているため、各コンテナのコンテナイメージに対するセキュリティ対策をすることができない、という問題がある。
　また、特許文献２の技術をコンテナ型仮想化環境に適用すると、セキュリティ仮想マシンにより、システムコールをシミュレーションするが、シミュレーションを実行すると、処理負荷がかかってしまい、システム資源の負担を小さくすることができる、というコンテナ型仮想化のメリットを損なうことになってしまう。
　そこで、本開示において、稼働中のコンテナイメージを保護することができる技術を提供する。
　一実施形態によると、プロセッサを備えるコンピュータを動作させるためのプログラムであって、前記プログラムは、前記プロセッサに、コンテナ型仮想化環境において、システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップと、前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップと、前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記システムコールによる処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップと、を実行させる。
　本開示によれば、稼働中のコンテナイメージを保護することができる。
情報処理システム１の構成を示す図である。 情報処理装置１０のブロック図である。 従来のシステムコールの流れの例を示す図である。 従来のシステムコールの流れの例を示す図である。 本開示のシステムコールの処理を示す図である。 監視対象のコンテナを選択する画面の例を示す図である。 情報処理装置１０の監視指示処理を示すフローチャートである。 情報処理装置１０の監視処理を示すフローチャートである。 情報処理装置１０の監視対象指定処理を示すフローチャートである。 コンテナホスト内のコンテナの動作イメージの例を示す図である。 コンテナホスト内のイメージが削除された場合の例を示す図である。 コンテナホスト内のイメージが改ざんされた場合の例を示す図である。 情報処理システム２の構成を示す図である。 情報処理装置５０のブロック図である。 情報処理装置５０の監視処理を示すフローチャートである。
　以下、図面を参照しつつ、本開示の実施形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称及び機能も同じである。従って、それらについての詳細な説明は繰り返さない。
＜第１の実施形態＞
（本開示の概要）
　本開示は、コンテナ型仮想化環境において、システムコールによるシステムコール関数を呼び出した際のパラメータを監視し、コンテナイメージを保護するプログラム、情報処理装置、及び方法について説明する。
　コンテナホスト上のコンテナ型仮想化環境が安定して稼働する為には、コンテナホスト上に配置されたコンテナイメージのディレクトリ、ファイルに対する削除や、上書きによる改ざんから保護する必要がある。同時に、コンテナ関連のアプリケーションが保持している設定情報に齟齬が発生しないよう、コンテナイメージのディレクトリパス、ディレクトリ名、ファイル名の変更等からも保護する必要がある。これらの保護を行う為に、コンテナ型仮想化環境が従来の仮想マシンと異なりコンテナホストのカーネルを共有して動作するという点から見て、本開示では、コンテナホストのカーネルのシステムコールを監視する。本開示は、プロセッサが、コンテナイメージの同一性に影響を与えうるシステムコールの呼び出し対象を、システムコールテーブルの情報を別途用意した第２システムコール関数が呼び出されるように書き換えることによって、第２システムコール関数内でパラメータを取得する。そして、プロセッサが、パラメータが示す処理の対象が監視対象であるか否かの判定をおこない、監視対象でない場合は、第２システムコール関数内で本来呼び出されるシステムコール関数である第１システムコール関数を呼び出し、その処理結果を返す。一方、プロセッサは、パラメータが示す処理の対象が監視対象であった場合は、第２システムコール関数内で本来のシステムコールの処理を無効化する。すなわち、本開示は、コンテナイメージの同一性に影響を与える監視対象に対してのシステムコールのみを無効化する。無効化は、例えば、システムコールに対して、何も処理しない、エラーを返す等により行う。
＜１．情報処理システム１の構成＞
　図１及び図２を用いて、本開示に係る情報処理システム１について説明する。
　図１は、情報処理システム１の構成を示す図である。情報処理システム１は、情報処理装置１０と、管理者端末２０と、ネットワーク３０とを備える。
　情報処理装置１０は、例えば、ラップトップパソコン又はラックマウント型若しくはタワー型等のコンピュータ等である。情報処理装置１０は、複数の情報処理装置１０等により構成されてもよい。
　情報処理装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信ＩＦ１４と、入出力ＩＦ１５とを含んで構成される。
　プロセッサ１１は、プログラムに記述された命令セットを実行するためのハードウェアであり、演算装置、レジスタ、周辺回路などにより構成される。
　メモリ１２は、プログラム、及び、プログラム等で処理されるデータ等を一時的に記憶するためのものであり、例えばＤＲＡＭ（Dynamic Random Access Memory）等の揮発性のメモリである。
　ストレージ１３は、データを保存するための記憶装置であり、例えばフラッシュメモリ、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）である。
　通信ＩＦ１４は、情報処理装置１０が外部の装置と通信するため、信号を入出力するためのインターフェースである。通信ＩＦ１４は、インターネット、広域イーサネット等のネットワーク３０に有線又は無線により接続する。
　入出力ＩＦ１５は、入力操作を受け付けるための入力装置（例えば、マウス等のポインティングデバイス、キーボード）、及び、情報を提示するための出力装置（ディスプレイ、スピーカ等）とのインターフェースとして機能する。
　管理者端末２０は、情報処理装置１０で実行されるコンテナ型仮想化環境を管理するユーザにより操作される情報処理装置である。管理者端末２０は、例えば、ラップトップパソコン又はラックマウント型若しくはタワー型等のコンピュータ等である。
　情報処理装置１０、及び管理者端末２０は、ネットワーク３０を介して相互に通信可能に構成される。
　図２は、情報処理装置１０の機能構成を示すブロック図である。図２に示すように、情報処理装置１０は、通信部１１０と、記憶部１２０と、制御部１３０とを含む。
　通信部１１０は、情報処理装置１０が外部の装置と通信するための処理を行う。
　記憶部１２０は、情報処理装置１０が使用するデータ及びプログラムを記憶する。記憶部１２０は、コンテナに関するデータ、システムコールテーブル、第１システムコール関数群、第２システムコール関数群等を記憶する。
　コンテナに関するデータは、情報処理装置１０がコンテナ型仮想化環境を実現するために必要なデータである。コンテナに関するデータは、コンテナイメージ、コンテナのデータ等である。
　システムコールテーブルは、システムにおいて、予め定められているシステムコールテーブルである。
　第１システムコール関数群は、システムにおいて、予め定められているシステムコール関数の集合である。第２システムコール関数群は、本開示において定義するシステムコール関数の集合である。詳細は後述する。
　制御部１３０は、情報処理装置１０のプロセッサ１１がプログラムに従って処理を行うことにより、受信制御部１３１、送信制御部１３２、コンテナ制御部１３３、監視指示部１３４、書き換え部１３５、取得部１３６、監視部１３７、及び表示部１３８に示す機能を発揮する。
　受信制御部１３１は、情報処理装置１０が外部の装置から通信プロトコルに従って信号を受信する処理を制御する。
　送信制御部１３２は、情報処理装置１０が外部の装置に対し通信プロトコルに従って信号を送信する処理を制御する。
　コンテナ制御部１３３は、コンテナ型仮想化環境を実現する。具体的には、コンテナ制御部１３３は、コンテナ生成信号を受信すると、記憶部１２０に格納されたコンテナイメージからコンテナを生成する。コンテナ制御部１３３は、例えばＤＯＣＫＥＲ（登録商標）等を用いて、コンテナ型仮想化環境を実現する。
　監視指示部１３４は、システムコールの監視を開始及び終了する指示を各部に行う。
　監視の開始のタイミングは、任意のタイミングを採用することができる。監視は、遅くともコンテナが生成されたタイミングで開始されている方が、コンテナイメージの保護を図ることができる。このため、監視の開始のタイミングは、コンテナホストが起動したとき、コンテナ制御部１３３によりコンテナホスト上に配置されたコンテナイメージに基づいてコンテナホスト上にコンテナが最初に生成されたとき等が好ましい。なお、監視の開始及び終了のタイミングは、人手による指示を受け付ける、定期とする等としてもよく、また、常時行うこととしてもよい。
　また、監視指示部１３４は、監視の終了を、監視終了の指示があったタイミング、コンテナが全て削除されたタイミング等に行う。
　書き換え部１３５は、呼び出し対象のシステムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象である場合に、システムコール関数による処理が正常に実行した場合のような結果又はエラーとする結果を返す第２システムコール関数を読み込ませるように、システムコールテーブルを書き換える。具体的には、書き換え部１３５は、システムコールテーブルの監視対象の第１システムコール関数のアドレスを、第２システムコール関数のアドレスに書き換える。なお、第２システムコール関数には、対応する第１システムコール関数のアドレスが含まれるように構成する。第２システムコール関数において、パラメータをチェックした場合、安全であれば元の第１システムコール関数を呼び出して処理するためである。また、書き換え部１３５は、第１システムコール関数を、第２システムコール関数に置き換える構成としてもよい。
　監視対象は、システムコール関数を呼び出すプロセスの処理の内容と、プロセスの処理の対象ファイル及び対象ディレクトリの少なくとも何れかとの組み合わせとして予め定義される。監視対象は、例えば、下記（１）～（１４）のディレクトリ、ファイルと処理との組み合わせの少なくとも何れかである。
（１）コンテナイメージが格納されているディレクトリ配下のファイルの削除
（２）コンテナイメージが格納されているディレクトリの削除
（３）コンテナイメージが格納されているディレクトリ配下のファイルへの書込みモードでのオープン
（４）コンテナイメージが格納されているディレクトリ配下のファイルの移動
（５）コンテナイメージが格納されているディレクトリの移動
（６）コンテナイメージが格納されているディレクトリ配下のファイル名の変更
（７）コンテナイメージが格納されているディレクトリ名の変更
（８）コンテナイメージが格納されているディレクトリへのハードリンク
（９）コンテナイメージが格納されているディレクトリ配下のファイルへのハードリンク
（１０）コンテナイメージが格納されているディレクトリ配下へのディレクトリの追加
（１１）コンテナイメージが格納されているディレクトリへのシンボリックリンク
（１２）コンテナイメージが格納されているディレクトリ配下のファイルへのシンボリックリンク
（１３）コンテナイメージが格納されているディレクトリの属性変更
（１４）コンテナイメージが格納されているディレクトリ配下のファイルへの属性変更
（１５）コンテナイメージが格納されているディレクトリ及び配下を含むディレクトリパス上への他ファイルシステムのマウント
（１６）コンテナイメージが格納されているファイルシステムのアンマウント
　ディレクトリ等に対する処理に、ハードリンクが含む理由は、コンテナイメージが格納されているディレクトリ配下以外に、ハードリンク経由でディレクトリ、ファイル等に対する改ざんが行われることを防ぐためである。
　また、書き換え部１３５は、カーネルが読み込まれたタイミング、監視指示部１３４により監視開始指示があった場合等に、システムコールテーブルを書き換える。また、書き換え部１３５は、監視指示部１３４により監視終了指示があった場合に、書き換えたシステムコールテーブルを戻す。
　取得部１３６は、システムコールによる第１システムコール関数が呼び出される際のパラメータを取得する。具体的には、取得部１３６は、第１システムコール関数が呼び出される際のパラメータとして、当該システムコール関数が扱う対象及び処理を取得する。
　監視部１３７は、呼び出し対象の第１システムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象のものであるか否かを判定する。具体的には、監視部１３７は、まず、呼び出し対象のシステムコール関数を書き替えられたシステムコールテーブルを参照することで呼び出す。書き換えられていないシステムコール関数である場合、第１システムコール関数が、システムコールテーブルにより呼び出される。監視部１３７は、当該第１システムコール関数を実行させ、処理結果を返す。
　アドレスが書き換えられている場合、監視部１３７は、第２システムコール関数を呼び出すこととなる。監視部１３７は、呼び出したシステムコール関数が第２システムコール関数である場合、取得部１３６が取得したパラメータを用いて、監視対象であるか否かを判定する。具体的には、監視部１３７は、当該パラメータが、上記ディレクトリ、ファイルに対する所定の処理であるか否かを判定する。
　監視部１３７は、当該パラメータが、監視対象であると判定した場合、第２システムコール関数に、第２システムコール関数による結果を返す。一方、監視部１３７は、当該パラメータが、監視対象でないと判定した場合、実際の第１システムコール関数を呼び出す。この場合、監視部１３７は、第１システムコール関数を実行させ、処理結果を返す。
　なお、第２システムコール関数が、当該パラメータが、上記ディレクトリ、ファイルに対する所定の処理であるか否かを判定する機能を有していてもよい。この場合、第２システムコール関数は、判定結果が監視対象であれば、実際の第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返す。また、この場合、第２システムコール関数は、判定結果が監視対象でなければ、実際の第１システムコール関数を呼び出して処理を実行し、処理結果を返す。
　図３及び図４は、従来のシステムコールの流れの例を示す図である。図３及び図４の例は、ｘ８６＿６４アーキテクチャの場合である。ユーザプロセス（図３のＵｓｅｒＰｒｏｃｅｓｓ）がｒｅｎａｍｅという処理要求を出した場合、共有ライブラリ（図３のｇｌｉｂｃ）を経由して、システムコールを実行するためのソフトウェア割り込みが生成される。カーネルは、割り込みディスクリプタテーブル（図４のＩｎｔｅｒｒｕｐｔ　Ｄｅｓｃｒｉｐｔｏｒ　Ｔａｂｌｅ）からシステムコールハンドラ（図４のＳｙｓｔｅｍ　Ｃａｌｌ　Ｈａｎｄｌｅｒ）が呼び出す。カーネルは、システムコールハンドラ内でシステムコール番号をもとにシステムコールテーブル（図４のＳｙｓｔｅｍ　Ｃａｌｌ　Ｔａｂｌｅ）から各システムコール関数を呼び出して実行する。つまり、全てのシステムコール関数は、システムコールテーブルを経由して呼び出される。
　本開示は、上記の監視のために、第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする結果を返す第２システムコール関数を用意する。書き換え部１３５は、監視指示部１３４から監視の開始の指示を受け付けると、システムコールテーブルの監視対象の第１システムコール関数のアドレスを、第２システムコール関数のアドレスに書き換える。
　図５は、本開示のシステムコールの処理を示す図である。図５に示すように、システムコールテーブル書き換えることにより、第２システムコール関数（図５のＫｅｒｎｅｌ　Ｍｏｄｕｌｅ内のシステムコール関数）が呼び出されるように構成される。
　このようにシステムコールテーブルの監視対象の第１システムコール関数のアドレスを、第２システムコール関数のアドレスに書き換えることで、上記ディレクトリ、ファイルに対する所定の処理を実行する実際の第１システムコール関数は呼び出さず、第２システムコール関数が呼び出されることとなる。第２システムコール関数は、正常に実行したような結果又はエラーを返すが、実際の第１システムコール関数の処理は実行しない。このため、コンテナホスト側からであっても、悪意あるホスト側からあっても、上記ディレクトリ、ファイルに対する改ざん等を防ぐことができ、コンテナイメージを保護することができる。なお、監視対象の第１システムコール関数が、上記ディレクトリ、ファイルに対する所定の処理を実行しない場合には、実際の第１システムコール関数を間接的に呼び出すように設定する。
　表示部１３８は、コンテナ型仮想化環境における複数のコンテナイメージのうち、少なくとも１のコンテナイメージの指定及び指定の解除を受け付けるための画面を表示する。具体的には、表示部１３８は、コンテナイメージの指定を受け付ける画面を表示する。指定されたコンテナイメージは、取得部１３６が取得するパラメータ、監視部１３７が判定する対象のコンテナイメージとなる。表示部１３８は、例えば、当該画面を、管理者端末２０に表示させる。
　図６は、監視対象のコンテナを選択する画面の例を示す図である。画面２２０は、コンテナイメージボタン２２２～２２４、監視開始ボタン２２６、監視終了ボタン２２７を含む。
　コンテナイメージボタン２２２～２２４は、コンテナイメージの指定を受け付けるためのボタンである。また、コンテナイメージボタン２２２～２２４は、コンテナイメージが示すコンテナの状態を表示する。コンテナイメージボタンが白抜きの場合、当該コンテナイメージボタンが示すコンテナイメージのコンテナが生成されていることを示す。コンテナイメージボタンが塗りつぶされている場合、当該コンテナイメージボタンが示すコンテナイメージのコンテナが生成されていないことを示す。また、コンテナイメージボタンが網掛けとなっている場合、当該コンテナイメージボタンが示すコンテナイメージが監視対象となっていることを示す。コンテナイメージボタンが押下されると、コンテナイメージボタンが示すコンテナイメージが指定される。
　監視開始ボタン２２６は、指定されたコンテナイメージについて監視を開始するためのボタンである。具体的には、監視開始ボタン２２６が押下されると、監視指示部１３４に、現在押下されているコンテナイメージボタン２２２～２２４のコンテナイメージの監視を開始させる。
　監視終了ボタン２２７は、指定されたコンテナイメージについて監視を終了するためのボタンである。具体的には、監視開始ボタン２２６が押下されると、監視指示部１３４に、現在押下されているコンテナイメージボタン２２２～２２４のコンテナイメージの監視を終了させる。
　コンテナ型仮想化環境は、コンテナイメージの入れ替え等が頻繁に発生する可能性を有する。このため、表示部１３８が、画面２２０のようなインターフェースを表示することにより、ユーザが適宜明示的に指示することを可能とする。
　なお、本開示のコンテナ型仮想化環境は、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）等のコンテナオーケストレーションツールとのＡＰＩ連携を行い、コンテナホスト上の配置されたコンテナイメージの監視開始、監視解除を行う構成としてもよい。
＜２．動作＞
　以下では、情報処理装置１０における処理について図面を参照しながら説明する。
＜２．１．監視指示処理＞
　図７は、情報処理装置１０による監視指示処理を行う流れの一例を示すフローチャートである。情報処理装置１０は、当該処理を、情報処理装置１０にカーネルが読み込まれたタイミングで実行する。なお、監視の開始のタイミングは、コンテナホストが起動したとき、コンテナ制御部１３３によりコンテナホスト上に配置されたコンテナイメージに基づいてコンテナホスト上にコンテナが最初に生成されたとき等に、自動で開始する構成としてもよい。また、監視指示部１３４により監視開始指示があった場合に開始する構成としてもよい。
　ステップＳ１０１において、書き換え部１３５は、システムコールテーブルの監視対象の第１システムコール関数のアドレスを、第２システムコール関数のアドレスに書き換える。
　ステップＳ１０２において、監視指示部１３４は、システムコールの監視を開始する
　ステップＳ１０３において、プロセッサ１１は、監視終了の指示があったか否かを判定する。
　監視終了の指示が無かった場合（上記ステップＳ１０３のＮ）、ステップＳ１０４において、監視指示部１３４は、稼働中のコンテナが有るか否かを判定する。
　稼働中のコンテナがある場合（上記ステップＳ１０４のＮ）、ステップＳ１０３に戻り、監視指示部１３４は、終了指示があるまで監視を継続する。このとき、監視が中止されている場合、監視指示部１３４は、監視を再開する。
　一方、稼働中のコンテナがない場合（上記ステップＳ１０４のＹ）、ステップＳ１０５において、監視指示部１３４は、監視を中止させる。
　一方、監視終了の指示があった場合（上記ステップＳ１０３のＹ）、ステップＳ１０６において、監視指示部１３４は、システムコールの監視終了の指示を出す。
　ステップＳ１０７において、書き換え部１３５は、システムコールテーブルを元に戻し、処理を終了する。
＜２．２．監視処理＞
　図８は、情報処理装置１０による監視処理を行う流れの一例を示すフローチャートである。情報処理装置１０は、当該処理を、監視が開始されている状況において、書き換えられたシステムコールテーブルにより、第２システムコール関数が呼び出されたタイミングで実行する。なお、書き換えられていないシステムコール関数が呼び出される場合は、通常のシステムコール関数の呼び出し処理が行われる。
　ステップＳ１１１において、監視部１３７は、呼び出し対象のシステムコール関数を書き替えられたシステムコールテーブルを参照する。これにより、監視部１３７は、第２システムコール関数のアドレスを取得する。
　ステップＳ１１２において、監視部１３７は、呼び出し対象の第２システムコール関数を呼び出す。
　ステップＳ１１３において、監視部１３７は、システムコールによるシステムコール関数が呼び出される際のパラメータを取得する。
　ステップＳ１１４において、監視部１３７は、パラメータが、監視対象であるか否かを判定する。
　監視対象でない場合（上記ステップＳ１１４のＮ）、ステップＳ１１５において、監視部１３７は、第１システムコール関数を呼び出す。
　ステップＳ１１６において、監視部１３７は、呼び出した第１システムコール関数による処理を実行させる。
　ステップＳ１１７において、監視部１３７は、処理結果を返し、処理を終了する
　一方、監視対象である場合（上記ステップＳ１１４のＹ）、監視部１３７は、ステップ１１８において、第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返し、処理を終了する。
＜２．３．監視対象指定処理＞
　図９は、情報処理装置１０の監視対象指定処理を示すフローチャートである。情報処理装置１０は、当該処理を、任意のタイミングで実行する。
　ステップＳ１２１において、表示部１３８は、コンテナ型仮想化環境における複数のコンテナイメージのうち、少なくとも１のコンテナイメージの指定及び指定の解除を受け付けるための画面を表示する。
　ステップＳ１２２において、表示部１３８は、コンテナイメージの指定を受け付ける。
　ステップＳ１２３において、表示部１３８は、監視の開始又は終了を受け付ける。
　ステップＳ１２４において、表示部１３８は、監視指示部１３４に、現在指定されているコンテナイメージの監視を開始又は終了させ、処理を終了する。
＜３．小括＞
　以上説明したように、本開示によれば、コンテナ型仮想化環境において、システムコールによる第１システムコール関数が呼び出される際のパラメータを取得し、当該パラメータが示す、呼び出し対象の当該第１システムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象のものでない場合、カーネルから当該第１システムコール関数を呼び出し、当該第１システムコール関数の処理結果を返し、当該パラメータが示す、呼び出し対象の当該第１システムコール関数における処理の対象が、当該監視対象のものである場合、当該第１システムコール関数は呼び出さず、当該システムコールによる処理が正常に実行した場合のような結果又はエラーとする処理結果を返すことにより、稼働中のコンテナイメージを保護することができる。
　コンテナ型仮想化環境は、従来のサーバ仮想化環境のようにＯＳ全体を仮想化して起動する場合と比較して、起動が非常に早く、使用するホストＯＳのリソースも少ないという利点がある。コンテナ型仮想化環境のセキュリティ対策は、従来のセキュリティ対策で対応しきれないことが多いことが指摘されている（例えば、ＮＩＳＴ（米国国立標準技術研究所）のセキュリティ対策のアプリケーションコンテナセキュリティガイド（Ｓｐｅｃｉａｌ　Ｐｕｂｌｉｃａｔｉｏｎ　８００－１９０））。例えば、現在のコンテナのセキュリティ対策は、コンテナの監視を重視し、異常が検知された場合に、コンテナを切り離す等の対策をしている。このようなセキュリティ対策は、コンテナの機能、搭載するアプリケーションにより、定義、管理、更新等を行う必要があるため、非常に高負荷であり、定義漏れによる誤検知、不検知が起こり得る。
　これに対し、監視ソフトが、コンテナの生成元であるコンテナイメージを、コンテナのセキュリティ対策として採用することが考えられる。例えば、監視ソフトが、コンテナイメージを使用する前に、脆弱性のスキャンをする、コンテナイメージに電子署名を付与する等しておき、コンテナイメージを使用する前に改ざん等されていないかをチェックする方法がある。しかし、コンテナイメージをコンテナホストに展開後、及びコンテナイメージを元にコンテナが生成されてコンテナが稼働中には、共通のＯＳを用いているため、各コンテナのコンテナイメージに対するセキュリティ対策をすることができない。
　図１１は、コンテナホスト内のコンテナの動作イメージの例を示す図である。図１のように、コンテナホスト１０００上のファイルシステムに展開されるコンテナイメージ１０１０（イメージレイヤ）の中には、コンテナが実行に必要なファイルシステム及びメタ情報が格納されている。当該ファイルシステムは、ルートディレクトリ配下の／ｅｔｃ、／ｂｉｎ、／ｕｓｒ等のＯＳに該当する部分と、コンテナが使用するアプリケーション等のディレクトリ階層及びファイルとを格納している。
　図１１に示すように、各コンテナは、生成元であるコンテナイメージ１０１０の大部分に、ＯＳに該当する部分、アプリケーション部分等を使用して、コンテナホスト上で動作する。コンテナ側は、コンテナイメージの情報を読み取ることしかできず、書き換え等をすることができない。しかし、コンテナホスト側から見ると、コンテナイメージは、ＯＳ上のただのディレクトリ、ファイル群などであり、コンテナホストがコンテナイメージに対して追加／変更／削除を行うことが可能である。
　図１２は、コンテナホスト内のイメージが削除された場合の例を示す図である。コンテナホスト側から、コンテナイメージが削除された場合、コンテナ側で保持しているメタ情報の参照先が無い為、一瞬にして全コンテナは動作不可に陥る。
　コンテナ側で保持しているコンテナイメージのメタ情報に格納されているコンテナイメージ側の参照先のデータ（データブロック等）が存在しない為、削除されたイメージから生成されているコンテナは、削除されたタイミングで一斉に停止（動作できなくなる）してしまう。また、部分的に削除された場合は、コンテナの動作に影響が出る（挙動がおかしくなる）可能性がある。
　図１３は、コンテナホスト内のイメージが改ざんされた場合の例を示す図である。コンテナイメージの改ざんを、コンテナ側で保持しているメタ情報の参照先が変わらないように、つまり上書きでコンテナイメージのファイルに対して改ざんを行った場合、コンテナ側がその当該ファイルを読み込んだタイミングで、停止し、又は動作が変わってしまう可能性がある。コンテナ側で保持しているコンテナイメージのメタ情報に格納されているコンテナイメージ側の参照先のデータ（データブロック等）が存在しない為、削除されたイメージから生成されているコンテナは、削除されたタイミングで一斉に停止（動作できなくなる）してしまう。また、部分的に削除された場合は、コンテナの動作に影響が出る（挙動がおかしくなる）可能性がある。
　上記ガイドラインには、
　・マルウェア等の混入していない信頼できるコンテナイメージを使用する事、
　・コンテナが動作するコンテナホストは、必要最低限の機能を持たせて不要な機能を持たせない事、
　・前述のコンテナイメージへの削除や改ざんが行えないように　ＳＥＬｉｎｕｘ　やＡｐｐＡｒｍｏｒ　等のコンテナイメージへのアクセス制御を行う事、
　等が記載されている。
　ＳＥＬｉｎｕｘの場合、拡張属性によるアクセス制御を行っている関係上、動的で且つ柔軟な設定を行う事が難しく、仮にアクセス制御を行っている拡張属性を変更されても変更を検知する方法がない。また、ＡｐｐＡｒｍｏｒ等の場合は、設定したプログラムからのアクセス制御を行う事はできるが、設定を行っていないプログラムに対するアクセス制御は行う事ができない。
　以上の事、及びガイドラインにも記載されている通り、時間の経過とともにコンテナホスト本体の脆弱性のリスクから逃れられない場合、本開示の技術により、コンテナの元となっているコンテナホスト上のコンテナイメージを確実に保護することで、コンテナに対する十分なセキュリティ対策を実現することができる。
＜第２の実施形態＞
（第２の実施形態の概要）
　上記第１の実施形態において、本開示の技術は、稼働中のコンテナイメージを保護することができることを説明した。第２の実施形態では、本開示の技術が、コンテナイメージ以外のデータの保護することができることを説明する。
　第２の実施形態において、本開示の技術は、システムコールによるシステムコール関数を呼び出した際のパラメータを監視し、保護対象のデータとして、コンテナイメージのバックアップに用いる差分データを保護するプログラム、情報処理装置、及び方法について説明する。
　コンテナ型仮想化環境では、ファイルシステムのファイルやディレクトリを透過的に重ねる技術（例えば、ＵｎｉｏｎＦＳなど）が用いられている。この場合、コンテナ型仮想化環境は、第１層、第２層、及び第３層のファイルシステムを有することができる。
　第１層は、コンテナイメージそのものを管理する層である。例えば、図１０における、イメージレイヤに相当する。第１の実施形態での保護の対象は、第１層で管理されるコンテナイメージである。
　第２層は、コンテナイメージに対してされた操作によって、第１層のコンテナイメージと、当該コンテナイメージの現在のあるべき状態との差分データを管理する層である。例えば、図１０におけるコンテナレイヤに相当する。当該差分データは、バックアップに用いられるデータとして、任意のタイミングで記憶部などに格納される。
　第３層は、コンテナ内部から見えているファイルシステムである。具体的には、プロセスの権限に応じて、コンテナイメージに対する操作を行う。例えば、第３層のファイルシステムは、コンテナイメージを削除する権限を持つプロセスから、所定のコンテナイメージの削除命令が来ると、コンテナイメージが削除された旨を第２層のファイルシステムに渡す。すると、第２層のファイルシステムは、当該コンテナイメージが削除されたことを示す差分データを生成する。このとき、コンテナイメージは第１層において削除されない。第３層は、第１層と第２層の情報をマージすることにより、コンテナイメージを参照するプロセスに、現在のコンテナイメージを参照させる。
　従来、ランサムウェアにより、差分データなどの重要データが暗号化されることにより、正しいデータが復旧できないなどの問題が生じていた。本開示の技術は、このような差分データなどの重要データを保護することを目的とする。
　以下、第２の実施形態について説明する。第１の実施形態と同様の構成について、同一の符号を付して説明を省略する。
＜１．情報処理システム２の構成＞
　図１３及び図１４を用いて、本開示に係る情報処理システム２について説明する。
　図１３は、情報処理システム２の構成を示す図である。情報処理システム２は、情報処理装置５０と、管理者端末２０と、ネットワーク３０とを備える。
　図１４は、情報処理装置５０の機能構成を示すブロック図である。図１４に示すように、情報処理装置５０は、通信部１１０と、記憶部５２０と、制御部２３０とを含む。
　記憶部５２０は、情報処理装置５０が使用するデータ及びプログラムを記憶する。記憶部５２０は、コンテナに関するデータ、システムコールテーブル、第１システムコール関数群、第２システムコール関数群等を記憶する。また、記憶部５２０は、コンテナに関するデータを、上記第１層～第３層の構造を含むファイルシステムとして管理するデータベースとしての機能を有する。
　制御部２３０は、情報処理装置５０のプロセッサ１１がプログラムに従って処理を行うことにより、受信制御部１３１、送信制御部１３２、コンテナ制御部１３３、監視指示部２３４、書き換え部２３５、取得部１３６、監視部２３７、表示部２３８、バックアップ部２３９、及び復旧部２４０に示す機能を発揮する。
　監視指示部２３４は、システムコールの監視を開始及び終了する指示を各部に行う。
　監視指示部２３４は、監視の開始を指示するタイミングとして、任意のタイミングを採用することができる。例えば、監視指示部２３４が監視の開始を指示するタイミングとして、コンテナイメージのバックアップに用いる差分データが生成されたタイミング、当該差分データが記憶部５２０に格納されたタイミングなどを採用することができる。なお、監視指示部２３４が監視の開始及び終了を指示するタイミングは、人手による指示を受け付ける、定期とする等としてもよく、また、常時行うこととしてもよい。
　また、監視指示部２３４は、監視の終了を、監視終了の指示があったタイミング、コンテナが全て削除されたタイミング等に行う。
　書き換え部２３５は、呼び出し対象のシステムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象である場合に、システムコール関数による処理が正常に実行した場合のような結果又はエラーとする結果を返す第２システムコール関数を読み込ませるように、システムコールテーブルを書き換える。具体的には、書き換え部２３５は、システムコールテーブルの監視対象の第１システムコール関数のアドレスを、第２システムコール関数のアドレスに書き換える。なお、第２システムコール関数には、対応する第１システムコール関数のアドレスが含まれるように構成する。第２システムコール関数において、パラメータをチェックした場合、安全であれば元の第１システムコール関数を呼び出して処理するためである。また、書き換え部２３５は、第１システムコール関数を、第２システムコール関数に置き換える構成としてもよい。
　書き換え部２３５における監視対象は、システムコール関数を呼び出すプロセスの処理の内容と、プロセスの処理の対象ファイル及び対象ディレクトリの少なくとも何れかとの組み合わせとして予め定義される。監視対象は、例えば、下記（１）～（１４）のディレクトリ、ファイルと処理との組み合わせの少なくとも何れかである。
（１）差分データが格納されているディレクトリ配下のファイルの削除
（２）差分データが格納されているディレクトリの削除
（３）差分データが格納されているディレクトリ配下のファイルへの書込みモードでのオープン
（４）差分データが格納されているディレクトリ配下のファイルの移動
（５）差分データが格納されているディレクトリの移動
（６）差分データが格納されているディレクトリ配下のファイル名の変更
（７）差分データが格納されているディレクトリ名の変更
（８）差分データが格納されているディレクトリへのハードリンク
（９）差分データが格納されているディレクトリ配下のファイルへのハードリンク
（１０）差分データが格納されているディレクトリ配下へのディレクトリの追加
（１１）差分データが格納されているディレクトリへのシンボリックリンク
（１２）差分データが格納されているディレクトリ配下のファイルへのシンボリックリンク
（１３）差分データが格納されているディレクトリの属性変更
（１４）差分データが格納されているディレクトリ配下のファイルへの属性変更
（１５）差分データが格納されているディレクトリ及び配下を含むディレクトリパス上への他ファイルシステムのマウント
（１６）差分データが格納されているファイルシステムのアンマウント
　ディレクトリ等に対する処理に、ハードリンクが含む理由は、コンテナイメージが格納されているディレクトリ配下以外に、ハードリンク経由でディレクトリ、ファイル等に対する改ざんが行われることを防ぐためである。
　また、書き換え部２３５は、カーネルが読み込まれたタイミング、監視指示部２３４により監視開始指示があった場合等に、システムコールテーブルを書き換える。また、書き換え部２３５は、監視指示部２３４により監視終了指示があった場合に、書き換えたシステムコールテーブルを戻す。
　監視部２３７は、呼び出し対象の第１システムコール関数における処理の対象が、差分データの同一性に影響を与える監視対象のものであるか否かを判定する。具体的には、監視部２３７は、まず、呼び出し対象のシステムコール関数を書き替えられたシステムコールテーブルを参照することで呼び出す。書き換えられていないシステムコール関数である場合、第１システムコール関数が、システムコールテーブルにより呼び出される。監視部２３７は、当該第１システムコール関数を実行させ、処理結果を返す。監視部２３７の機能は、監視部１３７の機能を差分データについて準用することができる。
　表示部２３８は、コンテナ型仮想化環境における複数の差分データのうち、少なくとも１の差分データの指定及び指定の解除を受け付けるための画面を表示する。具体的には、表示部２３８は、コンテナイメージの指定を受け付ける画面を表示する。指定された差分データは、取得部１３６が取得するパラメータ、監視部２３７が判定する対象の差分データとなる。表示部２３８は、例えば、当該画面を、管理者端末２０に表示させる。
　なお、取得部１３６が取得するパラメータ及び監視部２３７が判定する対象の差分データは、明示的に選択されるまで、全ての差分データとしてもよい。
　バックアップ部２３９は、コンテナイメージの差分データを取得し、差分データをバックアップファイルとして記憶部５２０に格納する。
　具体的には、バックアップ部２３９は、任意のタイミングで、第２層のコンテナイメージと、第１層のコンテナイメージとの差分データを取得する。任意のタイミングは、定期的、予め決められたタイミングなどである。バックアップ部２３９は、例えば、１時間に１回、１日に１回など、任意のバックアップのタイミングに、差分データを取得する。
　バックアップ部２３９は、取得した差分データを記憶部５２０に格納する。バックアップ部２３９により記憶部５２０に格納された差分データが、第２の実施形態において保護の対象のデータとなる。
　また、バックアップ部２３９は、差分データを任意のタイミングごとに記憶部５２０に格納する。このとき、バックアップ部２３９は、所定の世代前の差分データを削除する構成としてもよい。
　復旧部２４０は、復旧指示の入力を受け付けることに応じて、第１層のコンテナイメージと、差分データとを用いて、決められた世代までコンテナイメージを復旧する。
　具体的には、復旧部２４０は、まず、復旧指示の入力を受け付ける。復旧指示には、復旧させたい世代、復旧させたい日時などが含まれる。
　次に、復旧部２４０は、復旧指示に含まれる世代、日時などの情報に応じた差分データと第１層のコンテナイメージを、記憶部５２０から取得する。
　そして、復旧部２４０は、取得した差分データと第１層のコンテナイメージとを用いて、コンテナイメージを復旧する。復旧部２４０は、取得した差分データと第１層のコンテナイメージとをマージしたコンテナイメージを生成する。復旧部２４０は、生成したコンテナイメージを、新たな第１層のコンテナイメージとして、記憶部５２０に格納する。
＜２．動作＞
　以下では、情報処理装置５０における処理について図面を参照しながら説明する。なお、差分データについて、第１実施形態の監視指示処理及び監視対象指定処理を準用することができるため、説明を省略する。
＜監視処理＞
　図１５は、情報処理装置５０による監視処理を行う流れの一例を示すフローチャートである。情報処理装置５０は、当該処理を、監視が開始されている状況において、書き換えられたシステムコールテーブルにより、第２システムコール関数が呼び出されたタイミングで実行する。なお、書き換えられていないシステムコール関数が呼び出される場合は、通常のシステムコール関数の呼び出し処理が行われる。
　ステップＳ２１１において、監視部２３７は、呼び出し対象のシステムコール関数を書き替えられたシステムコールテーブルを参照する。これにより、監視部２３７は、第２システムコール関数のアドレスを取得する。
　ステップＳ２１２において、監視部２３７は、呼び出し対象の第２システムコール関数を呼び出す。
　ステップＳ２１３において、監視部２３７は、システムコールによるシステムコール関数が呼び出される際のパラメータを取得する。
　ステップＳ２１４において、監視部２３７は、パラメータが、監視対象であるか否かを判定する。
　監視対象でない場合（上記ステップＳ２１４のＮ）、ステップＳ１１５において、監視部２３７は、第１システムコール関数を呼び出す。
　ステップＳ２１６において、監視部２３７は、呼び出した第１システムコール関数による処理を実行させる。
　ステップＳ２１７において、監視部２３７は、処理結果を返し、処理を終了する
　一方、監視対象である場合（上記ステップＳ２１４のＹ）、監視部２３７は、ステップ１１８において、第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返し、処理を終了する。
＜３．小括＞
　以上説明したように、本開示によれば、コンテナ型仮想化環境において、システムコールによる第１システムコール関数が呼び出される際のパラメータを取得し、当該パラメータが示す、呼び出し対象の当該第１システムコール関数における処理の対象が、コンテナ型仮想化環境におけるコンテナイメージのバックアップに用いる差分データの同一性に影響を与える監視対象のものでない場合、カーネルから当該第１システムコール関数を呼び出し、当該第１システムコール関数の処理結果を返し、当該パラメータが示す、呼び出し対象の当該第１システムコール関数における処理の対象が、当該監視対象のものである場合、当該第１システムコール関数は呼び出さず、当該システムコールによる処理が正常に実行した場合のような結果又はエラーとする処理結果を返すことにより、稼働中のコンテナイメージの差分ファイルを保護することができる。
＜その他の変形例＞
　以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換及び変更を行なって実施することができる。これらの実施形態及び変形例ならびに省略、置換及び変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。
　例えば、情報処理装置１０の各機能は、他の装置に構成してもよい。例えば、記憶部１２０は、外部のデータベースとして構築してもよい。
　また、上記実施形態では、コンテナイメージ又はバックアップのための差分データを保護対象のデータとしたが、コンテナ型仮想化環境に限らずファイルシステムのファイルやディレクトリを透過的に重ねる技術（例えば、ＵｎｉｏｎＦＳなど）と、ファイル共有システム（例えば、ＳＡＭＢＡなど）を組み合わせるなど、これに限定されるものではない。保護対象のデータは、コンテナ型仮想化環境に限らずランサムウェアなどによる悪意のある操作から保護したいデータであれば、様々なデータを対象とすることができる。
　また、上記実施形態では、コンテナイメージ又はバックアップのための差分データを保護対象のデータとした。これらは択一的なものではなく、本開示の技術は、保護対象のデータとして、コンテナイメージとバックアップのための差分データとを採用することができる。この場合、単純には、第１実施形態で開示した技術と、第２実施形態で開示した技術とを組み合わせることにより、何れも保護することを実現することができる。
＜付記＞
　以上の各実施形態で説明した事項を、以下に付記する。
　（付記１）プロセッサを含む、コンテナ型仮想化環境を実行する情報処理装置（１０）を動作させるためのプログラムであって、前記プログラムは、前記プロセッサに、システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップ（Ｓ１１３）と、前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップ（Ｓ１１７）と、前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップ（Ｓ１１８）と、を実行させるプログラム。
　（付記２）前記監視対象は、前記第１システムコール関数を呼び出すプロセスの処理の内容と、前記プロセスの処理の対象ファイル及び対象ディレクトリの少なくとも何れかとの組み合わせとして予め定義されたものである、（付記１）に記載のプログラム。
　（付記３）
前記システムコールテーブルの前記監視対象の前記第１システムコール関数のアドレスを、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする結果を返す第２システムコール関数のアドレスに書き換えるステップ（Ｓ１０１）、を実行させ、前記取得するステップにおいて、システムコールによる前記第２システムコール関数が呼び出される際のパラメータを取得する、（付記１）又は(付記２)に記載のプログラム。
　（付記４）前記コンテナ型仮想化環境における複数のコンテナイメージのうち、少なくとも１以上のコンテナイメージの指定を受け付けるための画面を表示するステップ（Ｓ１２１）、を実行させ、前記取得するステップにおいて、前記指定された１以上のコンテナイメージについての前記システムコールについて、前記パラメータを取得する、（付記１）～（付記３）の何れかに記載のプログラム。
　（付記５）前記コンテナ型仮想化環境おいて、コンテナイメージに基づいてコンテナホスト上にコンテナが生成されたタイミングで、前記取得するステップと、前記処理結果を返すステップとによる前記パラメータの監視を開始させるステップ（Ｓ１０１）、を実行させる（付記１）～（付記４）の何れかに記載のプログラム。
　（付記６）前記コンテナが全て削除された場合、前記取得するステップと、前記処理結果を返すステップとによる前記パラメータの監視を終了させるステップ（Ｓ１０５、Ｓ１０６）、を実行させる（付記５）に記載のプログラム。
　（付記７）プロセッサ（１１）を含む、コンテナ型仮想化環境を実行する情報処理装置（１０）であって、システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップ（Ｓ１１３）と、前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップ（Ｓ１１７）と、前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップ（Ｓ１１８）と、を実行する情報処理装置。
　（付記８）プロセッサ（１１）を含む、コンテナ型仮想化環境を実行するコンピュータ（例えば、情報処理装置１０）が、システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップ（Ｓ１１３）と、前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、コンテナイメージの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップ（Ｓ１１７）と、前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップ（Ｓ１１８）と、を実行する方法。
　（付記９）プロセッサ（１１）を含む情報処理装置（１０）であって、
　システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップ（Ｓ１１３）と、前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、保護対象のデータの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップ（Ｓ１１７）と、前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップ（Ｓ１１８）と、を実行する情報処理装置。
　（付記１０）前記保護対象のデータは、コンテナ型仮想化環境におけるコンテナイメージである、（付記９）に記載の情報処理装置。
　（付記１１）前記監視対象は、前記第１システムコール関数を呼び出すプロセスの処理の内容と、前記プロセスの処理の対象ファイル及び対象ディレクトリの少なくとも何れかとの組み合わせとして予め定義されたものである、
　（付記１０）に記載の情報処理装置。
　（付記１２）前記システムコールテーブルの前記監視対象の前記第１システムコール関数のアドレスを、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする結果を返す第２システムコール関数のアドレスに書き換えるステップ（Ｓ１０１）、を実行し、前記取得するステップにおいて、システムコールによる前記第２システムコール関数が呼び出される際のパラメータを取得する、（付記１０）に記載の情報処理装置。
　（付記１３）前記コンテナ型仮想化環境における複数のコンテナイメージのうち、少なくとも１以上のコンテナイメージの指定を受け付けるための画面を表示するステップ（Ｓ１２１）、を実行させ、前記取得するステップにおいて、前記指定された１以上のコンテナイメージについての前記システムコールについて、前記パラメータを取得する、（付記１０）に記載の情報処理装置。
　（付記１４）前記コンテナ型仮想化環境おいて、コンテナイメージに基づいてコンテナホスト上にコンテナが生成されたタイミングで、前記取得するステップと、前記処理結果を返すステップとによる前記パラメータの監視を開始させるステップ（Ｓ１０１）、を実行する（付記１０）に記載の情報処理装置。
　（付記１５）前記コンテナが全て削除された場合、前記取得するステップと、前記処理結果を返すステップとによる前記パラメータの監視を終了させるステップ（Ｓ１０５、Ｓ１０６）、を実行する（付記１４）に記載の情報処理装置。
　（付記１６）前記保護対象のデータは、コンテナ型仮想化環境におけるコンテナイメージのバックアップに用いる差分データである、（付記９）に記載の情報処理装置。
　（付記１７）前記保護対象のデータは、コンテナ型仮想化環境におけるコンテナイメージ、及び、前記コンテナイメージのバックアップに用いる差分データである、（付記９）に記載の情報処理装置。
　（付記１８）プロセッサ（１１）を含むコンピュータ（例えば、情報処理装置１０）が、システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップ（Ｓ１１３）と、前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、保護対象のデータの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップ（Ｓ１１７）と、前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップ（Ｓ１１８）と、を実行する方法。
　（付記１９）プロセッサを含む情報処理装置（１０）を動作させるためのプログラムであって、前記プログラムは、前記プロセッサに、システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップ（Ｓ１１３）と、前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、保護対象のデータの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップ（Ｓ１１７）と、前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップ（Ｓ１１８）と、を実行させるプログラム。
１　情報処理システム、２　情報処理システム、１０　情報処理装置、１１　プロセッサ、１２　メモリ、１３　ストレージ、１４　通信ＩＦ、１５　入出力ＩＦ、２０　管理者端末、３０　ネットワーク、５０　情報処理装置、１１０　通信部、１２０　記憶部、１３０　制御部、１３１　受信制御部、１３２　送信制御部、１３３　コンテナ制御部、１３４　監視指示部、１３５　書き換え部、１３６　取得部、１３７　監視部、１３８　表示部、２３０　制御部、２３４　監視指示部、２３５　書き換え部、２３７　監視部、２３８　表示部、２３９　バックアップ部、２４０復旧部、５２０　記憶部。

Claims (11)

  1. 　プロセッサを含む情報処理装置であって、
    　システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップと、
    　前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、保護対象のデータの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップと、
    　前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップと、
    　を実行する情報処理装置。
  2. 　前記保護対象のデータは、コンテナ型仮想化環境におけるコンテナイメージである、
    　請求項１に記載の情報処理装置。
  3. 　前記監視対象は、前記第１システムコール関数を呼び出すプロセスの処理の内容と、前記プロセスの処理の対象ファイル及び対象ディレクトリの少なくとも何れかとの組み合わせとして予め定義されたものである、
    　請求項２に記載の情報処理装置。
  4. 　前記システムコールテーブルの前記監視対象の前記第１システムコール関数のアドレスを、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする結果を返す第２システムコール関数のアドレスに書き換えるステップ、
    　を実行し、
    　前記取得するステップにおいて、システムコールによる前記第２システムコール関数が呼び出される際のパラメータを取得する、
    　請求項２に記載の情報処理装置。
  5. 　前記コンテナ型仮想化環境における複数のコンテナイメージのうち、少なくとも１以上のコンテナイメージの指定を受け付けるための画面を表示するステップ、
    　を実行し、
    　前記取得するステップにおいて、前記指定された１以上のコンテナイメージについての前記システムコールについて、前記パラメータを取得する、
    　請求項２に記載の情報処理装置。
  6. 　前記コンテナ型仮想化環境おいて、コンテナイメージに基づいてコンテナホスト上にコンテナが生成されたタイミングで、前記取得するステップと、前記処理結果を返すステップとによる前記パラメータの監視を開始させるステップ、
    　を実行する請求項２に記載の情報処理装置。
  7. 　前記コンテナが全て削除された場合、前記取得するステップと、前記処理結果を返すステップとによる前記パラメータの監視を終了させるステップ、
    　を実行させる請求項６に記載の情報処理装置。
  8. 　前記保護対象のデータは、コンテナ型仮想化環境におけるコンテナイメージのバックアップに用いる差分データである、
    　請求項１に記載の情報処理装置。
  9. 　前記保護対象のデータは、コンテナ型仮想化環境におけるコンテナイメージ、及び、前記コンテナイメージのバックアップに用いる差分データである、
    　請求項１に記載の情報処理装置。
  10. 　プロセッサを含むコンピュータが、
    　システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップと、
    　前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、保護対象のデータの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップと、
    　前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップと、
    　を実行する方法。
  11. 　プロセッサを含む情報処理装置を動作させるためのプログラムであって、前記プログラムは、前記プロセッサに、
    　システムコールによるシステムコール関数が呼び出される際のパラメータを取得するステップと、
    　前記パラメータが示す、呼び出し対象の第１システムコール関数における処理の対象が、保護対象のデータの同一性に影響を与える監視対象のものでない場合、カーネルから前記第１システムコール関数を呼び出し、前記第１システムコール関数の処理結果を返すステップと、
    　前記パラメータが示す、呼び出し対象の前記第１システムコール関数における処理の対象が、前記監視対象のものである場合、前記第１システムコール関数は呼び出さず、前記第１システムコール関数による処理が正常に実行した場合のような結果又はエラーとする処理結果を返すステップと、
    　を実行させるプログラム。
PCT/JP2022/024004 2021-06-22 2022-06-15 プログラム、情報処理装置、方法 WO2022270385A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP22828302.4A EP4361860A1 (en) 2021-06-22 2022-06-15 Program, information processing device, and method
JP2023530378A JP7489548B2 (ja) 2021-06-22 2022-06-15 プログラム、情報処理装置、方法
US18/534,919 US20240231959A9 (en) 2021-06-22 2023-12-11 Apparatus, and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-103220 2021-06-22
JP2021103220 2021-06-22

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/534,919 Continuation US20240231959A9 (en) 2021-06-22 2023-12-11 Apparatus, and method

Publications (1)

Publication Number Publication Date
WO2022270385A1 true WO2022270385A1 (ja) 2022-12-29

Family

ID=84544291

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/024004 WO2022270385A1 (ja) 2021-06-22 2022-06-15 プログラム、情報処理装置、方法

Country Status (3)

Country Link
EP (1) EP4361860A1 (ja)
JP (1) JP7489548B2 (ja)
WO (1) WO2022270385A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030115458A1 (en) * 2001-12-19 2003-06-19 Dongho Song Invisable file technology for recovering or protecting a computer file system
JP2005316964A (ja) 2004-04-27 2005-11-10 Microsoft Corp セキュリティ仮想マシンを介してセキュリティポリシーを実施するための方法およびシステム
JP2008165325A (ja) * 2006-12-27 2008-07-17 Internatl Business Mach Corp <Ibm> アプリケーションプログラムによるリソースアクセスを制御するための情報処理装置、方法、及びプログラム
WO2009102006A1 (ja) * 2008-02-14 2009-08-20 Nec Corporation アクセス制御装置、その方法及び情報記録媒体
JP2018081514A (ja) 2016-11-17 2018-05-24 株式会社日立ソリューションズ マルウェアの解析方法及び記憶媒体

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030115458A1 (en) * 2001-12-19 2003-06-19 Dongho Song Invisable file technology for recovering or protecting a computer file system
JP2005316964A (ja) 2004-04-27 2005-11-10 Microsoft Corp セキュリティ仮想マシンを介してセキュリティポリシーを実施するための方法およびシステム
JP2008165325A (ja) * 2006-12-27 2008-07-17 Internatl Business Mach Corp <Ibm> アプリケーションプログラムによるリソースアクセスを制御するための情報処理装置、方法、及びプログラム
WO2009102006A1 (ja) * 2008-02-14 2009-08-20 Nec Corporation アクセス制御装置、その方法及び情報記録媒体
JP2018081514A (ja) 2016-11-17 2018-05-24 株式会社日立ソリューションズ マルウェアの解析方法及び記憶媒体

Also Published As

Publication number Publication date
EP4361860A1 (en) 2024-05-01
US20240134720A1 (en) 2024-04-25
JPWO2022270385A1 (ja) 2022-12-29
JP7489548B2 (ja) 2024-05-23

Similar Documents

Publication Publication Date Title
US10009360B1 (en) Malware detection and data protection integration
US10607007B2 (en) Micro-virtual machine forensics and detection
US9769199B2 (en) Centralized storage and management of malware manifests
US9501310B2 (en) Micro-virtual machine forensics and detection
US9292328B2 (en) Management of supervisor mode execution protection (SMEP) by a hypervisor
US9922192B1 (en) Micro-virtual machine forensics and detection
CN104662552B (zh) 安全的盘访问控制
US9069955B2 (en) File system level data protection during potential security breach
CN109074450B (zh) 威胁防御技术
CN110647744B (zh) 文件系统中的取证分析的方法、装置、介质和系统
US8843926B2 (en) Guest operating system using virtualized network communication
US20100199351A1 (en) Method and system for securing virtual machines by restricting access in connection with a vulnerability audit
US20100175108A1 (en) Method and system for securing virtual machines by restricting access in connection with a vulnerability audit
US20180060588A1 (en) Operating system
US10783041B2 (en) Backup and recovery of data files using hard links
US9250940B2 (en) Virtualization detection
Vokorokos et al. Application security through sandbox virtualization
US9104876B1 (en) Virtual file-based tamper resistant repository
Vasudevan MalTRAK: Tracking and eliminating unknown malware
WO2022270385A1 (ja) プログラム、情報処理装置、方法
Mankin et al. Dione: a flexible disk monitoring and analysis framework
US20240231959A9 (en) Apparatus, and method
US20220035920A1 (en) Systems and methods for automatically generating malware countermeasures
KR102309695B1 (ko) 호스트 침입 탐지를 위한 파일 기반 제어방법 및 장치
KR20220068850A (ko) 인공 신경망에 기반한 악성 데이터 분류 모델을 활용하여 분할된 파일 시스템 사이의 파일 접근을 제어하는 방법 및 클라우드 시스템

Legal Events

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

Ref document number: 22828302

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023530378

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2022828302

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022828302

Country of ref document: EP

Effective date: 20240122