Information processing device and control method for information processing device
The information processing device accurately determines access request legitimacy by using an analyzer and management unit to update rules and correspondence information, addressing the challenge of new applications lacking security OS protection in conventional systems.
Patent Information
- Application Number
- JP2022051601
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-03-28
- Publication Date
- 2025-11-07
- Estimated Expiration
- 2042-03-28
AI Technical Summary
Conventional information processing devices struggle to accurately determine the legitimacy of access requests when new applications are added to the service OS, as the security OS lacks necessary rules to protect related files.
An information processing device with an operating system and control system that includes an analyzer to generate access data linking sector numbers and identifiers, a monitor to determine invalid requests, and a management unit to update rules and correspondence information based on application changes, ensuring accurate access validation.
The solution enables high-accuracy determination of access request legitimacy, even when the access control function is disabled or tampered with, by updating rules and correspondence information in response to application additions, deletions, or updates.
Smart Images

Figure 0007765871000001 
Figure 0007765871000002 
Figure 0007765871000003
Abstract
Description
[Technical Field]
[0001] The present disclosure relates to an information processing device and a control method for an information processing device. [Background technology]
[0002] An information processing device is known that includes a service operating system (hereinafter referred to as a "service OS"), a security operating system (hereinafter referred to as a "security OS"), and a control program that controls the execution of the service OS and the security OS (see, for example, Patent Document 1).
[0003] The service OS hooks (acquires) access requests from server programs to files on the magnetic disk and requests the security OS to determine the legitimacy of the hooked access requests. The security OS determines whether the access request from the server program is invalid based on rules specified for each file. If the security OS determines that the access request from the server program is invalid, the service OS generates an error code based on the determination result from the security OS.
[0004] On the other hand, if the security OS determines that the access request from the server program is not fraudulent, the service OS executes access to the file in the magnetic disk based on the access request from the server program, based on the determination result from the security OS. [Prior art documents] [Patent documents]
[0005] [Patent Document 1] Patent No. 4177957 Summary of the Invention [Problem to be solved by the invention]
[0006] In the conventional information processing device described above, when a new application is added to the service OS, the security OS does not have rules to protect files related to that application, and the legitimacy of the access request cannot be accurately determined.
[0007] Therefore, the present disclosure provides an information processing device and a method for controlling the information processing device that can accurately determine the validity of an access request. [Means for solving the problem]
[0008] an information processing device according to one aspect of the present disclosure, the information processing device comprising: an operating system having an application storage area in which an application is stored, the operating system executing the application; and a control system accessing a sector group stored in a storage device in response to an access request from the operating system, the control system comprising: an analyzer that generates, from the access request, access data linking the sector number and the sector group identifier included in the access request by referencing correspondence information indicating a correspondence relationship between a sector number and a sector group identifier of the sector group stored in a storage area of the storage device corresponding to the sector number; a monitor that determines whether the access request is invalid based on the access data and rule information indicating a rule for accessing the sector group stored in the storage device; a determiner that determines, based on the access data, whether the access request is a request for access to the sector group related to the application stored in the storage device; and a management unit that, when it is determined that the access request is a request for access to the sector group related to the application and the application storage area has been changed by the operating system, acquires application information related to the application and updates the rule information and the correspondence information based on the acquired application information.
[0009] These comprehensive or specific aspects may be realized as a system, a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM (Compact Disc-Read Only Memory), or may be realized as any combination of a system, a method, an integrated circuit, a computer program, and a recording medium. [Effects of the Invention]
[0010] According to an information processing device and the like according to an aspect of the present disclosure, the legitimacy of an access request can be determined with high accuracy. [Brief explanation of the drawings]
[0011] [Figure 1] 1 is a block diagram showing a configuration of an information processing device according to an embodiment; [Figure 2] FIG. 10 is a diagram illustrating an example of a device access log according to the embodiment. [Figure 3] FIG. 10 is a diagram illustrating an example of a sector group database according to the embodiment. [Figure 4] FIG. 10 is a diagram illustrating an example of a sector group access log according to the embodiment. [Figure 5] FIG. 10 is a diagram illustrating an example of sector group access information according to the embodiment. [Figure 6] FIG. 10 is a diagram illustrating an example of a sector group access rule database according to the embodiment. [Figure 7] FIG. 2 is a block diagram showing a functional configuration of a management unit according to the embodiment. [Figure 8] FIG. 4 is a diagram illustrating an example of an application database according to the embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of a developer-defined policy according to an embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of a directory creation destination policy according to the embodiment. [Figure 11] 10 is a flowchart showing the overall operation flow of a host OS according to an embodiment. [Figure 12]10 is a flowchart showing the flow of operations of an access log analysis unit according to the embodiment. [Figure 13] 10 is a flowchart showing the flow of operations of a sector group access determination unit according to the embodiment; [Figure 14] 14 is a flowchart specifically showing the process of step S305 in the flowchart of FIG. 13. [Figure 15] 14 is a flowchart specifically showing the process of step S305 in the flowchart of FIG. 13. [Figure 16] 10 is a flowchart showing the flow of operations of a sector group access determination unit and a management unit according to the embodiment. [Figure 17] 17 is a flowchart specifically showing the process of step S602 in the flowchart of FIG. 16. [Figure 18] 17 is a flowchart specifically illustrating the process of step S603 in the flowchart of FIG. 16 when an application is added by the guest OS. [Figure 19] 10A and 10B are diagrams illustrating an example of the sector group access rule database before and after updating when an application is added by a guest OS. [Figure 20] 10A and 10B are diagrams illustrating an example of the sector group database before and after updating when an application is added by a guest OS. [Figure 21] 17 is a flowchart specifically illustrating the process of step S603 in the flowchart of FIG. 16 when an application is deleted by the guest OS. [Figure 22] 10A and 10B are diagrams illustrating an example of the sector group access rule database before and after updating when an application is deleted by the guest OS. [Figure 23] 10A and 10B are diagrams illustrating an example of the sector group database before and after updating when an application is deleted by a guest OS. [Figure 24]17 is a flowchart specifically illustrating the process of step S603 in the flowchart of FIG. 16 when an application is updated by the guest OS. [Figure 25] 10A and 10B are diagrams illustrating an example of the sector group access rule database before and after update when an application is updated by a guest OS. [Figure 26] 10A and 10B are diagrams illustrating an example of the sector group database before and after update when an application is updated by a guest OS. DETAILED DESCRIPTION OF THE INVENTION
[0012] an information processing device according to one aspect of the present disclosure, the information processing device comprising: an operating system having an application storage area in which an application is stored, the operating system executing the application; and a control system accessing a sector group stored in a storage device in response to an access request from the operating system, the control system comprising: an analyzer that generates, from the access request, access data linking the sector number and the sector group identifier included in the access request by referencing correspondence information indicating a correspondence relationship between a sector number and a sector group identifier of the sector group stored in a storage area of the storage device corresponding to the sector number; a monitor that determines whether the access request is invalid based on the access data and rule information indicating a rule for accessing the sector group stored in the storage device; a determiner that determines, based on the access data, whether the access request is a request for access to the sector group related to the application stored in the storage device; and a management unit that, when it is determined that the access request is a request for access to the sector group related to the application and the application storage area has been changed by the operating system, acquires application information related to the application and updates the rule information and the correspondence information based on the acquired application information.
[0013] According to this aspect, the rule information and correspondence information are updated in response to changes made to the application storage area by the operating system. As a result, for example, when a new application is added to the operating system, even if the access control function of the operating system is disabled or tampered with by an unauthorized computer program, the validity of the access request from the operating system can be accurately determined based on the updated rule information and correspondence information.
[0014] For example, the change to the application storage area may be configured to be any one of adding, deleting, and updating the application.
[0015] According to this aspect, the rule information and the correspondence information can be updated in response to the addition, deletion, or update of an application by the operating system.
[0016] For example, the management unit may be configured to have an application database relating to the application stored in the application storage area, and when it is determined that the access request requests access to the group of sectors relating to the application, to determine whether the application has been added, deleted, or updated by the operating system by comparing the application storage area with the application database.
[0017] According to this aspect, by comparing the application storage area with the application database, it is possible to easily determine whether an application has been added, deleted, or updated by the operating system.
[0018] For example, the management unit may be configured to, when an application is added by the operating system, add the rule regarding the added application to the rule information, and add the correspondence relationship regarding the added application to the correspondence information.
[0019] According to this aspect, when an application is added by the operating system, the rule information and the correspondence information can be updated appropriately.
[0020] For example, the management unit may be configured to, when the operating system deletes the application, delete the rule relating to the deleted application from the rule information, and delete the correspondence relationship relating to the deleted application from the correspondence information.
[0021] According to this aspect, when an application is deleted by the operating system, the rule information and the correspondence information can be updated appropriately.
[0022] For example, the management unit may be configured to change the rules relating to the application updated in the rule information when the application is updated by the operating system, and to change the correspondence relationship relating to the application updated in the correspondence information.
[0023] According to this aspect, when an application is updated by the operating system, the rule information and the correspondence information can be updated appropriately.
[0024] For example, the management unit may be configured to update the rule information and the correspondence information based on a developer-defined policy that defines conditions for protecting the application, or protection rules established to protect the application, as the application information.
[0025] According to this aspect, the rule information and correspondence information can be easily updated based on developer-defined policies or protection rules.
[0026] a step of generating access data from the access request linking the sector number and the sector group identifier included in the access request by referencing correspondence information indicating a correspondence relationship between a sector number and a sector group identifier of the sector group stored in a storage area of the storage device corresponding to the sector number; a step of determining whether the access request is fraudulent based on the access data and rule information indicating a rule for accessing the sector group stored in the storage device; a step of determining whether the access request is a request for access to the sector group related to the application stored in the storage device based on the access data; and a step of obtaining application information related to the application when the access request is determined to be a request for access to the sector group related to the application and the application storage area has been changed by the operating system, and updating the rule information and the correspondence information based on the obtained application information.
[0027] According to this aspect, the rule information and correspondence information are updated in response to changes made to the application storage area by the operating system. As a result, for example, when a new application is added to the operating system, even if the access control function of the operating system is disabled or tampered with by an unauthorized computer program, the validity of the access request from the operating system can be accurately determined based on the updated rule information and correspondence information.
[0028] These comprehensive or specific aspects may be realized as a system, a method, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, or may be realized as any combination of a system, a method, an integrated circuit, a computer program, or a recording medium.
[0029] Hereinafter, the embodiments will be specifically described with reference to the drawings.
[0030] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, component placement and connection configurations, steps, and step order shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components that are not described in the independent claims that represent the highest concepts are described as optional components.
[0031] (Embodiment) [1. Configuration of information processing device] First, the configuration of an information processing device 2 according to an embodiment will be described with reference to FIGS. 1 to 6. FIG. 1 is a block diagram showing the configuration of an information processing device 2 according to an embodiment. FIG. 2 is a diagram showing an example of a device access log 36 according to an embodiment. FIG. 3 is a diagram showing an example of a sector group database 30 according to an embodiment. FIG. 4 is a diagram showing an example of a sector group access log 38 according to an embodiment. FIG. 5 is a diagram showing an example of sector group access information 32 according to an embodiment. FIG. 6 is a diagram showing an example of a sector group access rule database 34 according to an embodiment.
[0032] 1, an information processing device 2 according to an embodiment includes hardware 4, a virtualization control system 6, a plurality of guest operating systems 8 (hereinafter referred to as "guest OSs 8"), and a host operating system 10 (hereinafter referred to as "host OSs 10"). The information processing device 2 is a device for determining unauthorized access in a vehicle such as an automobile.
[0033] An external storage device 12 is electrically connected to the information processing device 2. The external storage device 12 is an example of a storage device, and is configured, for example, by a hard disk drive (HDD). The external storage device 12 has a plurality of storage areas for storing sector groups (data). A plurality of sector numbers are assigned to each of these storage areas. As will be described later, when the host OS 10 accesses a sector group stored in the external storage device 12 in response to an access request from the guest OS 8, the sector number is used to specify the storage area of the external storage device 12 in which the sector group is stored, and is configured, for example, by a four-digit number.
[0034] In this specification, a sector group refers to the file itself, information describing file information (for example, Linux (registered trademark) i-node information, etc.), and file system information. A sector group includes, for example, files related to an application 15 (described later). A sector group name is an example of a sector group identifier, and refers to a file name representing the file itself, or a specific name of information describing file information (for example, a directory name). File information refers to meta-information including the file name, file size, access permissions, change history, information required for the access control system, etc.
[0035] The hardware 4 includes a processor having, for example, a CPU (Central Processing Unit) or an ECU (Electronic Control Unit), and provides an execution environment for multiple computer programs. Note that the hardware 4 may be configured with one processor or multiple processors.
[0036] The virtualization control system 6 is virtualization software that runs on the hardware 4 and controls the execution of multiple guest OSs 8 and a host OS 10, and is an example of a control system. This virtualization control system 6 makes it possible to virtualize and install multiple different OSs (multiple guest OSs 8 and a host OS 10) on a single piece of hardware 4. In this embodiment, the virtualization control system 6 is a so-called Type 1 (bare metal) hypervisor. Here, the virtualization control system 6 refers to a system that receives I / O information from the guest OSs 8 running on the virtualization system via the hypervisor and exchanges I / O information with the actual external storage device 12.
[0037] Each of the multiple guest OSs 8 is a front-end VM (Virtual Machine) such as Linux that runs on the virtualization control system 6, and is an example of an operating system. Each of the multiple guest OSs 8 has multiple processes 14, applications 15, an access control function 16, and a front-end device driver 18. For convenience of explanation, only one guest OS 8 is illustrated in FIG. 1. Note that, in this embodiment, multiple guest OSs 8 are configured to run on the virtualization control system 6, but the present invention is not limited to this, and only one guest OS 8 may be configured to run on the virtualization control system 6.
[0038] Each of the multiple processes 14 is a computer program for executing various functions of the guest OS 8. To execute various functions of the guest OS 8, each of the multiple processes 14 generates an access request for accessing a group of sectors stored in the external storage device 12 (e.g., writing to or reading from a group of sectors). Furthermore, each of the multiple processes 14 modifies the application storage area, specifically, adds (installs), deletes (uninstalls), and updates (upgrades, etc.) an application 15, based on, for example, a user operation. For convenience of explanation, only one process 14 is illustrated in FIG. 1 . Here, the application storage area refers to a directory for storing the application 15, or a group of sectors dedicated to the application in the external storage device, etc.
[0039] The application 15 is application software downloaded from an application distribution platform to the guest OS 8 and stored in an application storage area within the guest OS 8. The application 15 is, for example, an application capable of executing a navigation function and an application capable of executing a function for playing content such as music or video. A directory storing files related to the application 15 is stored in the application storage area within the guest OS 8. This directory stores, as files related to the application 15, developer-defined policies 15a that define conditions for protecting the application 15, for example. The developer-defined policies 15a are an example of application information related to the application 15. Note that, for convenience of explanation, only one application 15 is shown in FIG. 1, but multiple applications 15 may be stored in the application storage area.
[0040] The access control function 16 is a security function for monitoring access requests generated by each of the multiple processes 14. For example, when an unauthorized computer program such as malware is executed on the guest OS 8 and attempts to unauthorizedly access a group of sectors stored in the external storage device 12, the access control function 16 discards the access request generated by the unauthorized computer program.
[0041] The front-end device driver 18 is a virtual device driver (VirtIO) for driving a virtual network interface configured in the guest OS 8. The front-end device driver 18 transmits access requests generated by each of the multiple processes 14 to a back-end device driver 20 (described later) of the host OS 10 via the virtualization control system 6. The front-end device driver 18 also receives access responses (described later) from the back-end device driver 20 of the host OS 10 via the virtualization control system 6.
[0042] The host OS 10 is a backend VM, such as Linux, that runs on the virtualization control system 6 and is an example of a control system. The host OS 10 includes a backend device driver 20, a memory unit 22, an access log analysis unit 24, a sector group access determination unit 26, and a control response unit 28.
[0043] The backend device driver 20 is a virtual device driver (VirtIO) for driving a virtual network interface configured in the host OS 10. The backend device driver 20 acquires (receives) an access request from the frontend device driver 18 of the guest OS 8 via the virtualization control system 6, and outputs the acquired access request to the access log analysis unit 24.
[0044] Furthermore, as will be described later, if the sector group access determination unit 26 determines that the access request is not invalid, the backend device driver 20 accesses the sector group stored in the external storage device 12 in response to the access request. In this case, the backend device driver 20 transmits an access response indicating the result of accessing the sector group stored in the external storage device 12 to the frontend device driver 18 of the guest OS 8 via the virtualization control system 6.
[0045] The storage unit 22 is a memory that stores a sector group database 30, sector group access information 32, and sector group access rule database 34. The sector group database 30, sector group access information 32, and sector group access rule database 34 will be described later.
[0046] The access log analyzer 24 is an example of an analyzer, and acquires a device access log 36 as a log of access requests acquired by the backend device driver 20. Here, the device access log 36 is a database in a table format, for example, as shown in FIG. 2. As shown in FIG. 2, the device access log 36 associates a timestamp, an operation target VM, an operation type, a sector number, and a payload. The timestamp is information indicating the date and time when the frontend device driver 18 of the guest OS 8 sent an access request. The operation target VM is information indicating the guest OS 8 that is the sender of the access request, and is, for example, a sequential number such as "1," "2," . . . , "n" assigned to each of multiple guest OSs 8. The operation type is information indicating the type of operation on the sector group due to the access request, such as "read" (reading the sector group) or "write" (writing to the sector group). The sector number is information for specifying the storage area of the sector group in the external storage device 12. The payload is information indicating the content of the operation request (for example, information on what content to write, etc.).
[0047] 2, the first line of the device access log 36 stores a) timestamp "2021 / 9 / 3 18:39:01.032", b) operation target VM "1", c) operation type "read", d) sector number "1111", and e) payload "e38182 (omitted)". In other words, the first line of the device access log 36 means that on the date and time "2021 / 9 / 3 18:39:01.032", the guest OS 8 assigned the number "1" sent an access request to request reading of a group of sectors stored in the storage area of the external storage device 12 corresponding to sector number "1111".
[0048] The access log analysis unit 24 also generates a sector group access log 38 from the device access log 36 based on the sector group database 30 stored in the storage unit 22. The sector group database 30 is a database in a table format, such as that shown in FIG. 3, and is an example of correspondence information. As shown in FIG. 3, the sector group database 30 is a database that indicates the correspondence between sector numbers and the sector group names of sector groups stored in the storage area of the external storage device 12 that corresponds to the sector numbers. This sector group database 30 is generated, for example, when the information processing device 2 is started up for the first time. Note that FIG. 3 shows an example in which sector group names and sector groups correspond one-to-one, but this is not limiting, and multiple sector groups may correspond to one sector group name.
[0049] 3, the first line of the sector group database 30 stores a) the sector group name " / home / key / secret.dat" and b) the sector number "1111." That is, the name of this line in the sector group database 30 means that the sector group with the sector group name " / home / key / secret.dat" is stored in the storage area of the external storage device 12 corresponding to the sector number "1111." Note that when a sector number is added due to an increase in the access request log, the sector group database 30 is updated.
[0050] The access log analysis unit 24 first extracts only logs related to the guest OS 8 to be monitored (for example, the guest OS 8 assigned the number "1") from the device access log 36. Next, the access log analysis unit 24 references the sector group database 30 stored in the storage unit 22 and generates a sector group access log 38 by linking the sector numbers included in the extracted device access log 36 with the sector group names corresponding to the sector numbers. The access log analysis unit 24 outputs the generated sector group access log 38 to the sector group access determination unit 26.
[0051] Here, the sector group access log 38 is a database in a table format, such as that shown in Fig. 4, and is an example of access data. As shown in Fig. 4, the sector group access log 38 associates a timestamp, an operation type, a sector number, a sector group name, and a payload.
[0052] 4, the first line of the sector group access log 38 stores a) the timestamp "September 3, 2021, 18:39:01.032," b) the operation type "read," c) the sector number "1111," d) the sector group name " / home / key / secret.dat," and e) the payload "e38182 (omitted below)." In other words, the first line of the sector group access log 38 indicates that on the date and time "September 3, 2021, 18:39:01.032," the guest OS 8 assigned the number "1" sent an access request to request the reading of the sector group with the sector group name " / home / key / secret.dat" stored in the storage area of the external storage device 12 corresponding to the sector number "1111."
[0053] The access log analysis unit 24 also updates the sector group access information 32 stored in the storage unit 22 based on the generated sector group access log 38. Here, the sector group access information 32 is a database in a table format, for example, as shown in Fig. 5. As shown in Fig. 5, the sector group access information 32 associates the sector group name, the last access date and time, the last access process, the last operation, and the last sector number.
[0054] 5, the first line of the sector group access information 32 stores a) the sector group name " / var / log / system.log", b) the last access date and time "2021 / 9 / 17 04:43:21.213", c) the last accessing process "systemlogd", d) the last operation "write", and e) the last sector number "1234". In other words, the first line of the sector group access information 32 means that the last access to the sector group with the sector group name " / var / log / system.log" was a write of the sector group by the process "systemlogd" to the storage area of the external storage device 12 corresponding to sector number "1234" on the date and time "2021 / 9 / 17 04:43:21.213".
[0055] The sector group access determination unit 26 is an example of a monitoring unit, and determines whether an access request from the guest OS 8 is invalid based on the sector group access information 32 and the sector group access rule database 34 stored in the memory unit 22, and the sector group access log 38.
[0056] Here, the sector group access rule database 34 is a database that indicates, for each sector group stored in the external storage device 12, the correspondence between the sector group name of the sector group and the rule for accessing the sector group. Specifically, the sector group access rule database 34 is a database in the form of a table, for example, as shown in FIG. 6, and is an example of rule information. As shown in FIG. 6, the sector group access rule database 34 associates the sector group name with an access permission process, an access permission operation, and a sector group type. The access permission process is information (rule) indicating a process that is permitted to access a sector group. The access permission operation is information (rule) indicating an operation that is permitted to access a sector group. The sector group type is information indicating the type of sector group (personal information, log, i-node).
[0057] 6, the first line of the sector group access rule database 34 stores a) sector group name " / home / key / secret.dat," b) access permitted process "updateservice," c) access permitted operation "read," and d) sector group type "personal information." That is, the first line of the sector group access rule database 34 means that for the sector group with the sector group name " / home / key / secret.dat" that includes "personal information," the process permitted to access is "updateservice," and the operation permitted to access is read.
[0058] In this embodiment, the sector group access rule database 34 includes the processes and operations that are permitted to access the sector group stored in the external storage device 12 as rules for accessing the sector group, but is not limited to this and may include only either the processes or the operations.
[0059] The sector group access determination unit 26 compares the sector group access rule database 34 with the sector group access log 38 to determine whether the process and operation attempting to access a sector group stored in the external storage device 12 conforms to the rules defined by the sector group access rule database 34. The sector group access determination unit 26 also compares the sector group access information 32 with the sector group access log 38 to determine whether the behavior of the guest OS 8 in accessing a sector group is permitted. The sector group access determination unit 26 outputs the determination result to the control response unit 28.
[0060] The permitted behaviors include, for example, a) an operation of adding to a log file (a group of sectors indicating a log) and b) an operation of reading a group of sectors at the initial startup of the information processing device 2. Regarding the former, even if write permission is granted to a log file, generally, only additions to the log file occur, so an operation attempting to modify or delete part of the log file can be determined to be unauthorized access. Regarding the latter, generally, a group of sectors indicating the policy of the access control function 16 of the guest OS 8, for example, is read only at the initial startup of the information processing device 2, so an operation attempting to read the group of sectors after a considerable amount of time has passed since the initial startup can be determined to be unauthorized access.
[0061] The sector group access determination unit 26 is an example of a determination unit, and determines whether an access request from the guest OS 8 is a request for access to a sector group related to the application 15 stored in the external storage device 12, based on the sector number included in the sector group access log 38. The sector group access determination unit 26 outputs the determination result to a management unit 42 (described later).
[0062] The control response unit 28 controls the response based on the determination result of the sector group access determination unit 26. Specifically, if the sector group access determination unit 26 determines that the access request is fraudulent, the control response unit 28 notifies an external server 40 having a SIEM (Security Information and Event Management) function of an error, etc. Furthermore, if the sector group access determination unit 26 determines that the access request is not fraudulent, the control response unit 28 instructs the backend device driver 20 to access the sector group stored in the external storage device 12 in response to the access request.
[0063] As shown in FIG. 1, the host OS 10 further includes a management unit 42. The functional configuration of the management unit 42 will be described below with reference to FIGS. 7 to 10. FIG. 7 is a block diagram showing the functional configuration of the management unit 42 according to an embodiment. FIG. 8 is a diagram showing an example of an application database 44 according to an embodiment. FIG. 9 is a diagram showing an example of a developer-defined policy 15a according to an embodiment. FIG. 10 is a diagram showing an example of a directory generation destination policy 52 according to an embodiment.
[0064] As shown in FIG. 7, the management unit 42 includes an application database 44, a change type determination unit 46, an acquisition unit 48, and an update unit 50.
[0065] The application database 44 is a database related to the applications 15 stored in the application storage area of the guest OS 8. Specifically, the application database 44 is a database in the form of a table, for example, as shown in FIG. 8. As shown in FIG. 8, the application database 44 associates the application name, the name of the sector group to be monitored and protected, the sector group attribute, and the last update date and time. The application name is the name of the application 15. The sector group name to be monitored and protected is the name of the sector group related to the application 15 stored in a directory in the application storage area of the guest OS 8. The sector group attribute is information indicating the attribute of the sector group (application itself, application components, developer-defined policy). The last update date and time is the date and time when the sector group was last updated. The application database 44 is updated, for example, periodically to be synchronized with the application storage area of the guest OS 8.
[0066] The change type determination unit 46 searches the application storage area of the guest OS 8 when the sector group access determination unit 26 determines that the access request is a request for access to a sector group related to the application 15. The change type determination unit 46 then compares the application storage area with the application database 44 to determine whether the application 15 has been added, deleted, or updated by the guest OS 8. The change type determination unit 46 outputs the determination result to the acquisition unit 48 and the update unit 50.
[0067] Based on the determination result from the change type determination unit 46, the acquisition unit 48 acquires the developer-defined policy 15a of the application 15 from the application storage area of the guest OS 8 via the virtualization control system 6. The acquisition unit 48 outputs the acquired developer-defined policy 15a to the update unit 50.
[0068] Here, developer-defined policy 15a is a database in a table format, for example, as shown in Fig. 9. As shown in Fig. 9, developer-defined policy 15a associates a destination directory ID, a sector group name, an access permission process, an access permission operation, and a type.
[0069] In addition, a directory creation destination policy 52 is stored in the application save area of the guest OS 8 together with the developer-defined policy 15a. The directory creation destination policy 52 is a policy for generating a directory that is a save destination of the developer-defined policy 15a, and is, for example, a database in a table format as shown in FIG. 10. As shown in FIG. 10, the directory creation destination policy 52 associates a directory ID, a directory creation location, a directory name, an access permission operation, and a type. The directory ID of the directory creation destination policy 52 corresponds to the save destination directory ID of the developer-defined policy 15a. In addition, the application-related file save area at the directory creation location may have a file path different from that of the application save area, or may have the same file path as that of the application save area.
[0070] The update unit 50 updates the sector group database 30 and the sector group access rule database 34 when the sector group access determination unit 26 determines that the access request is a request for access to a sector group related to the application 15 and the change type determination unit 46 determines that the guest OS 8 has added, deleted, or updated the application 15.
[0071] [2. Operation of information processing device] [2-1. Overall operation of the host OS] The overall operation of the host OS 10 according to the embodiment will be described with reference to Fig. 11. Fig. 11 is a flowchart showing the flow of the overall operation of the host OS 10 according to the embodiment.
[0072] As shown in FIG. 11, first, the access log analysis unit 24 acquires the device access log 36 as a log of access requests acquired by the backend device driver 20 (S101).
[0073] Next, the access log analysis unit 24 extracts only the logs related to the guest OS 8 to be monitored from the device access log 36, and then refers to the sector group database 30 stored in the memory unit 22 to link the sector numbers included in the extracted logs with the sector group names corresponding to those sector numbers, thereby generating a sector group access log 38 (S102).
[0074] Next, the sector group access determination unit 26 determines whether the access request from the guest OS 8 is invalid based on the sector group access information 32 and the sector group access rule database 34 stored in the storage unit 22, and the sector group access log 38 (S103). The sector group access determination unit 26 outputs the determination result to the control response unit 28.
[0075] If the sector group access determination unit 26 determines that the access request is invalid (YES in S103), the control response unit 28 determines the type of sector group that is the target of the access request based on the sector group name included in the sector group access log 38 (S104).
[0076] If the type of sector group is "log" ("log" in S104), the control response unit 28 notifies the external server 40 of an error (S105). In this case, the control response unit 28 notifies the external server 40 of the error at predetermined regular intervals (for example, every five minutes). At this time, the sector group access determination unit 26 erases the content related to the unauthorized access request from the sector group access information 32. Thereafter, the flowchart of FIG. 11 ends.
[0077] On the other hand, if the type of the sector group is "personal information" ("personal information" in S104), the control response unit 28 notifies the external server 40 of the error and instructs the backend device driver 20 to stop access to the sector group in response to the access request (S106). In this case, the control response unit 28 notifies the external server 40 of the error and stops access to the sector group immediately. When notifying the external server 40 of the error, the control response unit 28 may also notify the external server 40 of the sector group access log 38 that was determined to be invalid. At this time, the sector group access determination unit 26 erases the content related to the invalid access request from the sector group access information 32. Thereafter, the flowchart of FIG. 11 ends.
[0078] Returning to step S103, if the sector group access determination unit 26 determines that the access request is not invalid (NO in S103), the control response unit 28 instructs the backend device driver 20 to access the sector group stored in the external storage device 12 in response to the access request (S107). At this time, the sector group access determination unit 26 updates the sector group access information 32 based on the content of the access request. Thereafter, the flowchart of FIG. 11 ends.
[0079] [2-2. Operation of the access log analysis unit] The operation of the access log analysis unit 24 will be specifically described with reference to Fig. 12. Fig. 12 is a flowchart showing the flow of the operation of the access log analysis unit 24 according to the embodiment.
[0080] 12, the access log analysis unit 24 first acquires the latest log from the device access log 36 (S201). Next, the access log analysis unit 24 determines whether the operation target VM included in the acquired latest log is the guest OS 8 to be monitored (S202). If the operation target VM included in the acquired latest log is not the guest OS 8 to be monitored (NO in S202), the flowchart in FIG. 12 ends.
[0081] On the other hand, if the VM to be operated included in the latest acquired log is the guest OS 8 to be monitored (YES in S202), the access log analysis unit 24 determines whether the sector number included in the latest acquired log is registered in the sector group database 30 (S203).
[0082] If the sector number included in the latest acquired log is registered in the sector group database 30 (YES in S203), the access log analysis unit 24 generates the sector group access log 38 by linking the sector number included in the latest acquired log with the sector group name corresponding to that sector number registered in the sector group database 30 (S204). Then, the flow chart of FIG. 12 ends.
[0083] On the other hand, if the sector number included in the latest acquired log is not registered in the sector group database 30 (NO in S203), the access log analysis unit 24 determines whether the operation type included in the latest acquired log is "write" (S205). If the operation type included in the latest acquired log is not "write" (NO in S205), the flowchart in Fig. 12 ends.
[0084] On the other hand, if the operation type included in the latest acquired log is "write" (YES in S205), the access log analysis unit 24 determines (S206) whether the latest acquired log is an operation on a sector group registered in the sector group access rule database 34. If the latest acquired log is not an operation on a sector group registered in the sector group access rule database 34 (NO in S206), the flowchart in Fig. 12 ends.
[0085] On the other hand, if the latest acquired log is an operation on a sector group registered in the sector group access rule database 34 (YES in S206), the access log analysis unit 24 registers the sector number and the sector group name corresponding to the sector number in the sector group database 30 (S207), and proceeds to step S204.
[0086] [2-3. Operation of Sector Group Access Determination Unit] The operation of the sector group access determination unit 26 will be specifically described with reference to Fig. 13. Fig. 13 is a flowchart showing the flow of the operation of the sector group access determination unit 26 according to the embodiment.
[0087] As shown in FIG. 13, the sector group access determination unit 26 first acquires the latest log from the sector group access log 38 (S301). Next, the sector group access determination unit 26 determines whether the operation type included in the acquired latest log is an access permission operation corresponding to the sector group name of the latest log, which is included in the sector group access rule database 34 (S302). That is, the sector group access determination unit 26 determines whether the access request is unauthorized based on rule information regarding read / write permissions granted to the sector group. If the operation type included in the acquired latest log is not an access permission operation (NO in S302), the sector group access determination unit 26 determines that the access request from the guest OS 8 is unauthorized (S303). Then, the flowchart of FIG. 13 ends.
[0088] On the other hand, if the operation type included in the acquired latest log is an access permission operation (YES in S302), the sector group access determination unit 26 determines whether the process is an access permission process corresponding to the sector group name of the latest log, which is included in the sector group access rule database 34 (S304). If the process is not an access permission process (NO in S304), the sector group access determination unit 26 determines that the access request from the guest OS 8 is invalid (S303). Then, the flowchart of FIG. 13 ends.
[0089] On the other hand, if the process is an access-permitted process (YES in S304), the sector group access determination unit 26 determines whether the behavior of the access to the sector group stored in the external storage device 12 is permitted based on the sector group access information 32 (S305). If the behavior is not permitted (NO in S305), the sector group access determination unit 26 determines that the access request from the guest OS 8 is invalid (S303). Thereafter, the flowchart of FIG. 13 ends.
[0090] On the other hand, if the behavior is permitted (YES in S305), the sector group access determination unit 26 determines that the access request from the guest OS 8 is not illegal (S306), and then ends the flow chart of FIG.
[0091] The process of step S305 in the flowchart of Fig. 13 will now be described in detail with reference to Fig. 14 and Fig. 15. Fig. 14 and Fig. 15 are flowcharts specifically showing the process of step S305 in the flowchart of Fig. 13.
[0092] The sector group access determining unit 26 determines, based on the first to Nth behavior rules, whether or not the behavior is permitted by each of the first to Nth behavior rules.
[0093] 14, in cases other than those described above, the sector group access determination unit 26 determines whether the behavior is permitted by the first behavior rule (S401). If the behavior is not permitted by the first behavior rule (NO in S401), the sector group access determination unit 26 determines that the access request from the guest OS 8 is invalid (S402). Then, the flowchart in FIG. 14 ends.
[0094] On the other hand, if the behavior is permitted by the first behavior rule (YES in S401), the sector group access determination unit 26 determines whether the behavior is permitted by the second behavior rule (S403). If the behavior is not permitted by the second behavior rule (NO in S403), the sector group access determination unit 26 determines that the access request from the guest OS 8 is invalid (S402). Then, the flowchart of FIG. 14 ends.
[0095] Similarly, if the behavior is permitted by the second behavior rule (YES in S403), the sector group access determination unit 26 determines whether the behavior is permitted by the Nth behavior rule (S404). If the behavior is not permitted by the Nth behavior rule (NO in S404), the sector group access determination unit 26 determines that the access request from the guest OS 8 is invalid (S402). Then, the flowchart of FIG. 14 ends.
[0096] If the behavior is permitted by the Nth behavior rule (YES in S404), the sector group access determination unit 26 determines that the access request from the guest OS 8 is not illegal (S405). Then, the flowchart in FIG. 14 ends.
[0097] Next, a method of determining behavior using the first behavior rule will be described with reference to Fig. 15. The first behavior rule is a rule regarding the behavior of access to a group of sectors, for example, when the information processing device 2 is started up for the first time.
[0098] 15, if access to the sector group is not prohibited except at the time of the initial startup of the information processing device 2 (NO in S501), the flowchart in Fig. 15 ends. On the other hand, if access to the sector group is prohibited except at the time of the initial startup of the information processing device 2 (YES in S501), the sector group access determination unit 26 determines whether or not an access request from the guest OS 8 is stored in the sector group access information 32 (S502).
[0099] If the access request from the guest OS 8 is stored in the sector group access information 32 (YES in S502), the sector group access determination unit 26 determines that the access request from the guest OS 8 is invalid (S503). Then, the flowchart in FIG. 15 ends.
[0100] On the other hand, if the sector group access information 32 does not store an access request from the guest OS 8 (NO in S502), the sector group access determination unit 26 determines whether the timestamp of the access request is within the expected initial startup time (e.g., one minute) (S504). If the timestamp of the access request is not within the expected initial startup time (NO in S504), the sector group access determination unit 26 determines that the access request is invalid (S503). Then, the flowchart of FIG. 15 ends.
[0101] On the other hand, if the timestamp of the access request is within the expected initial startup time (YES in S504), the sector group access determination unit 26 determines that the behavior is permitted by the first behavior rule (S505). In this case, the sector group access determination unit 26 stores the access request from the guest OS 8 in the sector group access information 32. Thereafter, the flowchart of FIG. 15 ends.
[0102] [2-4. Operation of Sector Group Access Judgment Unit and Management Unit] The operations of the sector group access determining unit 26 and the management unit 42 will be specifically described with reference to Fig. 16. Fig. 16 is a flowchart showing the flow of operations of the sector group access determining unit 26 and the management unit 42 according to the embodiment.
[0103] The following describes a case where the guest OS 8 requests access to a group of sectors related to the application 15, among a plurality of groups of sectors stored in the external storage device 12.
[0104] 16, the sector group access determination unit 26 determines that the access request from the guest OS 8 is a request for access to a sector group related to the application 15 based on the sector number included in the sector group access log 38 (S601). The sector group access determination unit 26 outputs the determination result to the change type determination unit 46 of the management unit 42.
[0105] The change type determination unit 46 of the management unit 42 mounts the application storage area on the host OS 10, references it, and compares the application storage area with the application database 44 to determine whether the guest OS 8 has added, deleted, or updated the application 15 (S602). The change type determination unit 46 outputs the determination result to the acquisition unit 48 and the update unit 50.
[0106] The update unit 50 of the management unit 42 updates the sector group database 30 and the sector group access rule database 34 (S603).
[0107] Here, the process of step S602 in the flowchart of Fig. 16 will be described in detail with reference to Fig. 17. Fig. 17 is a flowchart specifically showing the process of step S602 in the flowchart of Fig. 16.
[0108] As shown in FIG. 17, the change type determination unit 46 of the management unit 42 searches the application storage area of the guest OS 8 when the sector group access determination unit 26 determines that the access request is a request for access to a sector group related to the application 15 (S701).
[0109] When the change type determination unit 46 determines, by comparison with the application database 44, that the number of applications 15 has increased in the application storage area (YES in S702), it determines (S703) that the guest OS 8 has added an application 15. For example, if data relating to the applications 15 of "navigation" and "Music Store" is stored in the application database 44 shown in Fig. 8, while the applications 15 of "navigation", "Music Store", and "Coupon Storage" are stored in the application storage area, the change type determination unit 46 determines that the guest OS 8 has added the application 15 of "Coupon Storage".
[0110] Returning to step S702, if the change type determination unit 46 determines, by comparison with the application database 44, that the number of applications 15 has decreased in the application storage area (NO in S702, YES in S704), it determines that the guest OS 8 has deleted the applications 15 (S705). For example, if data relating to the applications 15 of "navigation," "Music Store," and "Coupon Storage" is stored in the application database 44 shown in FIG. 8, while the applications 15 of "navigation" and "Music Store" are stored in the application storage area, the change type determination unit 46 determines that the guest OS 8 has deleted the application 15 of "Coupon Storage."
[0111] Returning to step S704, if the change type determination unit 46 determines, by comparing with the application database 44, that the developer-defined policy 15a in the application storage area has been updated (NO in S704, YES in S706), it determines that the application 15 has been updated by the guest OS 8 (S707). For example, in the application database 44 shown in FIG. 8, if the last update date and time of the developer-defined policy 15a for "Coupon Storage" is "September 25, 2021, 14:25:04.067," while the last update date and time of the developer-defined policy 15a for "Coupon Storage" in the application storage area is "September 30, 2021, 12:10:03.127," the change type determination unit 46 determines that the application 15 for "Coupon Storage" has been updated by the guest OS 8. Note that in step S706, it may be determined not only whether the developer-defined policy 15a has been updated, but also whether the sector information for each application 15 has changed.
[0112] In this embodiment, the developer-defined policy 15a is used as the application information, but this is not limiting. If an OEM or supplier has its own protection rules for files with a specific extension, the file name and extension may be acquired as application information, and access rules that comply with the protection rules established by the OEM or supplier may be automatically generated and added to the file.
[0113] For example, if the file has the log data extension (.log), a protection rule for appending only is applied, and if the file has the executable application extension (.exe), a protection rule for prohibiting writing is applied. In addition, protection rules may be set according to information such as permission information (Read, Write, Execute) for each file defined in the application 15.
[0114] This allows the application 15 to be appropriately protected in accordance with the protection policy defined in the control system (host OS 10, hypervisor, etc.).
[0115] Returning to step S706, if change type determination unit 46 determines, by comparison with application database 44, that developer-defined policy 15a in the application storage area has not been updated (NO in S706), the flow chart of Fig. 17 is terminated. In this case, steps S103 to S107 of the flow chart of Fig. 11 described above are executed.
[0116] 18 to 20, the process of step S603 in the flowchart of FIG. 16 when it is determined by the change type determination unit 46 that the guest OS 8 has added an application 15 will be specifically described. FIG. 18 is a flowchart specifically showing the process of step S603 in the flowchart of FIG. 16 when the guest OS 8 has added an application 15. FIG. 19 is a diagram showing an example of the sector group access rule database 34 before and after updating when the guest OS 8 has added an application 15. FIG. 20 is a diagram showing an example of the sector group database 30 before and after updating when the guest OS 8 has added an application 15.
[0117] 18, based on the determination result from the change type determination unit 46 (the determination result that the application 15 has been added by the guest OS 8), the acquisition unit 48 of the management unit 42 acquires the developer-defined policy 15a of the application 15 from the application storage area of the guest OS 8 via the virtualization control system 6 (S801). The acquisition unit 48 outputs the acquired developer-defined policy 15a to the update unit 50.
[0118] The update unit 50 of the management unit 42 adds a rule related to the added application 15 (e.g., "Coupon Storage") to the sector group access rule database 34 shown in Fig. 19(a) based on the developer-defined policy 15a from the acquisition unit 48 (S802). As a result, the sector group access rule database 34 is updated as shown in Fig. 19(b), for example.
[0119] Furthermore, the update unit 50 adds the sector group name and sector number related to the added application 15 to the sector group database 30 shown in (a) of Fig. 20 (S803). As a result, the sector group database 30 is updated as shown in (b) of Fig. 20, for example.
[0120] 21 to 23, the process of step S603 in the flowchart of FIG. 16 when it is determined by the change type determination unit 46 that the guest OS 8 has deleted the application 15 will be specifically described. FIG. 21 is a flowchart specifically showing the process of step S603 in the flowchart of FIG. 16 when the guest OS 8 has deleted the application 15. FIG. 22 is a diagram showing an example of the sector group access rule database 34 before and after updating when the guest OS 8 has deleted the application 15. FIG. 23 is a diagram showing an example of the sector group database 30 before and after updating when the guest OS 8 has deleted the application 15.
[0121] 21, the update unit 50 of the management unit 42 deletes the rule related to the deleted application 15 (e.g., "Coupon Storage") from the sector group access rule database 34 shown in Fig. 22(a) based on the determination result from the change type determination unit 46 (determination result that the application 15 has been deleted by the guest OS 8) (S901). As a result, the sector group access rule database 34 is updated as shown in Fig. 22(b), for example.
[0122] Furthermore, the update unit 50 deletes the sector group name and sector number related to the deleted application 15 from the sector group database 30 shown in (a) of Fig. 23 (S902). As a result, the sector group database 30 is updated as shown in (b) of Fig. 23.
[0123] Next, with reference to Figures 24 to 26, the processing of step S603 in the flowchart of Figure 16 when the guest OS 8 updates the application 15 using the change type determination unit 46 will be described in detail. Figure 24 is a flowchart specifically showing the processing of step S603 in the flowchart of Figure 16 when the guest OS 8 updates the application 15. Figure 25 is a diagram showing an example of the sector group access rule database 34 before and after updating when the guest OS 8 updates the application 15. Figure 26 is a diagram showing an example of the sector group database 30 before and after updating when the guest OS 8 updates the application 15.
[0124] 24, based on the determination result from the change type determination unit 46 (determination result that the application 15 has been updated by the guest OS 8), the acquisition unit 48 of the management unit 42 acquires the developer-defined policy 15a of the application 15 from the application storage area of the guest OS 8 via the virtualization control system 6 (S1001). The acquisition unit 48 outputs the acquired developer-defined policy 15a to the update unit 50.
[0125] The update unit 50 of the management unit 42 changes the rule related to the updated application 15 (e.g., "Coupon Storage") in the sector group access rule database 34 based on the developer-defined policy 15a from the acquisition unit 48 (S1002). More specifically, the update unit 50 deletes the rule related to the application 15 before the update from the sector group access rule database 34 shown in FIG. 25(a), and then adds the rule related to the updated application 15 to the sector group access rule database 34. As a result, the sector group access rule database 34 is updated as shown in FIG. 25(b), for example.
[0126] Furthermore, the updating unit 50 changes the sector group name and sector number for the updated application 15 in the sector group database 30 (S1003). More specifically, the updating unit 50 deletes the sector group name and sector number for the application 15 before the update from the sector group database 30 shown in Fig. 26(a), and then adds the sector group name and sector number for the updated application 15. As a result, the sector group database 30 is updated as shown in Fig. 26(b), for example.
[0127] [3.Effects] As described above, in this embodiment, the sector group database 30 and the sector group access rule database 34 are updated in response to the guest OS 8 adding, deleting, or updating the application 15. As a result, even if the access control function 16 of the guest OS 8 is disabled or tampered with by an unauthorized computer program, the validity of the access request from the guest OS 8 can be accurately determined based on the updated sector group database 30 and sector group access rule database 34.
[0128] (Other variations) While the information processing device and the control method for the information processing device according to one or more aspects have been described based on the above-mentioned embodiments, the present disclosure is not limited to the above-mentioned embodiments. As long as they do not deviate from the spirit of the present disclosure, various modifications conceivable by those skilled in the art to the above-mentioned embodiments and forms constructed by combining components of different embodiments may also be included within the scope of one or more aspects.
[0129] In the above-described embodiments, each component may be configured with dedicated hardware, or may be realized by executing a computer program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a computer program recorded on a recording medium such as a hard disk or semiconductor memory.
[0130] In addition, in the above embodiment, a hypervisor (TYPE 1 type) is used as the virtualization control system 6, but this is not limited to this, and an application (TYPE 2 type) including a hypervisor that runs on a certain operating system may also be used.
[0131] Furthermore, in the above embodiment, the virtualization control system 6 and the host OS 10 are configured separately, but this is not limiting, and the virtualization control system 6 may have the functions of the host OS 10. In this case, the virtualization control system 6 having the functions of the host OS 10 constitutes a control system.
[0132] Furthermore, some or all of the functions of the information processing device according to the above-described embodiment may be realized by a processor such as a CPU executing a computer program.
[0133] Some or all of the components constituting each of the above devices may be configured as an IC card or a standalone module that can be attached to each device. The IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned ultra-multifunctional LSI. The IC card or module achieves its functions when the microprocessor operates according to a computer program. The IC card or module may be tamper-resistant.
[0134] The present disclosure may be the above-described methods. It may also be a computer program for implementing these methods on a computer, or a digital signal including the computer program. The present disclosure may also be a computer program or a digital signal recorded on a computer-readable non-transitory recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark) Disc), semiconductor memory, etc. It may also be a digital signal recorded on such a recording medium. The present disclosure may also be a computer program or a digital signal transmitted via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, etc. The present disclosure may also be a computer system including a microprocessor and a memory, in which the memory stores the computer program, and the microprocessor operates according to the computer program. The present disclosure may also be implemented by another independent computer system by recording the computer program or the digital signal on the recording medium and transferring it, or by transferring the computer program or the digital signal via the network, etc. [Industrial Applicability]
[0135] The information processing device according to the present disclosure is applicable to, for example, a virtual ECU having a function of detecting an abnormality in inter-VM communication. [Explanation of symbols]
[0136] 2. Information processing equipment 4. Hardware 6 Virtualization Control System 8 Guest OS 10 Host OS 12 External Storage Devices 14 Process 15 Applications 15a Developer-Defined Policies 16 Access Control Function 18 Front-end Device Drivers 20 Backend - Device Drivers 22 Memory section 24 Access log analysis section 26 Sector group access determination unit 28 Control Response Section 30 Sector Group Database 32 Sector Group Access Information 34 Sector Group Access Rule Database 36 Device Access Log 38 Sector Group Access Log 40 External Servers 42 Management Department 44 Application Database 46 Change type determination section 48 Acquisition Department 50 Update section 52 Directory Destination Policy
Claims
1. an operating system having an application storage area in which applications are stored and for executing the applications; a control system that accesses a group of sectors stored in the storage device in response to an access request from the operating system; The control system includes: an analysis unit that generates, from the access request, access data that links the sector number and the sector group identifier included in the access request by referencing correspondence information that indicates a correspondence relationship between a sector number and a sector group identifier of the sector group stored in a storage area of the storage device that corresponds to the sector number; a monitoring unit that determines whether the access request is invalid based on the access data and rule information that indicates rules for accessing the group of sectors stored in the storage device; a determination unit that determines, based on the access data, whether the access request requests access to the group of sectors related to the application stored in the storage device; a management unit that, when it is determined that the access request is a request for access to the group of sectors related to the application and the application storage area is changed by the operating system, acquires application information related to the application and updates the rule information and the correspondence information based on the acquired application information. Information processing device.
2. The change in the application storage area is one of adding, deleting, and updating the application. The information processing device according to claim 1 .
3. The management unit has an application database relating to the application stored in the application storage area, and when it is determined that the access request is a request for access to the group of sectors relating to the application, it compares the application storage area with the application database to determine whether the application has been added, deleted, or updated by the operating system. The information processing device according to claim 2 .
4. When the application is added by the operating system, the management unit adds the rule related to the added application to the rule information and adds the correspondence relationship related to the added application to the correspondence information.
4. The information processing device according to claim 2 or 3.
5. When the application is deleted by the operating system, the management unit deletes the rule related to the deleted application from the rule information, and deletes the correspondence related to the deleted application from the correspondence information.
4. The information processing device according to claim 2 or 3.
6. When the application is updated by the operating system, the management unit changes the rule related to the application updated in the rule information and changes the correspondence relationship related to the application updated in the correspondence information.
4. The information processing device according to claim 2 or 3.
7. The management unit updates the rule information and the correspondence information based on a developer-defined policy that defines conditions for protecting the application, or a protection rule that is established to protect the application, as the application information. The information processing device according to any one of claims 1 to 6.
8. A control method for an information processing device having an application storage area in which an application is stored, an operating system that executes the application, and a control system that accesses a group of sectors stored in a storage device in response to an access request from the operating system, comprising: the control system includes an analysis unit, a monitoring unit, a determination unit, and a management unit; The control method includes: the analyzing unit refers to correspondence information indicating a correspondence relationship between a sector number and a sector group identifier of the sector group stored in a storage area of the storage device corresponding to the sector number, thereby generating access data from the access request that links the sector number and the sector group identifier included in the access request; a step in which the monitoring unit determines whether the access request is invalid based on the access data and rule information that indicates rules for accessing the group of sectors stored in the storage device; a step of determining, based on the access data, whether the access request is a request for access to the group of sectors related to the application stored in the storage device; and when the management unit determines that the access request is a request for access to the group of sectors related to the application and the operating system has changed the application storage area, the management unit acquires application information related to the application and updates the rule information and the correspondence information based on the acquired application information. A method for controlling an information processing device.
Citation Information
Patent Citations
recorder
JP1992064985A
Access control system
JP2008204468A
Improved data control and access method and system
JP2021521575A
access control system
JP4177957B2
System and Methods for Enforcing Software License Compliance with Virtual Machines
US20090328225A1