JP7181491B2 - Information processing system, access control device, access control method and access control program - Google Patents

Description

The present invention relates to an information processing system, an access control device, an access control method and an access control program.

As an information processing system, there is an event processing system that collects event messages from various terminal devices, updates data held by the information processing system according to the event messages, and executes information processing according to the updated data. For example, the information processing system collects event messages including sensor data measured using sensor devices from terminal devices such as smartphones and in-vehicle devices, and holds state data indicating the state of the terminal devices. For example, the information processing system realizes an information service that detects update of state data and provides information according to the current state of the terminal device.

An event transfer method for transferring event messages between a plurality of entity devices has been proposed. In the proposed event forwarding method, each entity device compares the attribute information of the received event message with the filter information registered in the router, and suppresses the forwarding of unnecessary event messages based on the result of the matching. A device management system has also been proposed that allows a server device to access a device connected to a client device. In the proposed device management system, the client device exclusively controls data communication between the client application and the device and data communication between the server device and the device. Also, a method of transmitting an event message between a plurality of IoT (Internet of Things) entity devices has been proposed.

Japanese Patent Application Laid-Open No. 2004-302960 Japanese Unexamined Patent Application Publication No. 2008-4072 WO2014/130568

A new information service using at least part of a plurality of data items may be desired to be added to an information processing system that holds data including a plurality of data items. Therefore, it is conceivable to register a program of a certain user (for example, a certain developer) in the information processing system so that the program is executed according to the update of data.

However, from the viewpoint of information security, among the various data items collected, there may be a mixture of data items to which the user may be permitted to access and data items to which the user should not be permitted to access. Thus, authentication of data access from the user's program becomes a problem. In this regard, a method of referring to authentication information such as an ACL (Access Control List) and determining whether or not to allow access to a data item each time a data item is accessed after program registration is also conceivable. However, if the access authority is confirmed for each data access, data processing may be delayed due to overhead.

An object of the present invention in one aspect is to provide an information processing system, an access control device, an access control method, and an access control program that can suppress delays in data processing using an additional program.

In one aspect, an information processing system is provided having a data processing device and an access control device. A data processing device stores data including a plurality of data items, and when a registered program exists, executes the registered program according to the update of the data. The access control device accepts a registration request including a user's target program, analyzes the target program, detects data items that can be accessed from the target program from among a plurality of data items, and determines data items to which the user has access authority or user access rights. determines whether the user has access authority to the detected data item based on access control information indicating data items to which the user does not have access authority, and registers the target program in the data processing apparatus when it is determined that the user has access authority Allow

Also, in one aspect, an access control device having a storage unit and a processing unit is provided. In one aspect, a computer implemented access control method is also provided. Also, in one aspect, an access control program for execution by a computer is provided.

In one aspect, data processing delays using additional programs are reduced.
The above and other objects, features and advantages of the present invention will become apparent from the following description taken in conjunction with the accompanying drawings which represent exemplary preferred embodiments of the invention.

1 is a diagram illustrating an example of an information processing system according to a first embodiment; FIG. It is a figure which shows the example of the information processing system of 2nd Embodiment. FIG. 3 is a block diagram showing a hardware example of a firewall; FIG. 4 is a block diagram showing an example of functions of a node; FIG. 4 is a block diagram showing an example of functions of a device object; FIG. FIG. 3 is a diagram showing examples of a state table and a plug-in table; FIG. FIG. 4 is a diagram showing a format example of a message; 4 is a block diagram showing an example of functions of a firewall; FIG. FIG. 10 illustrates an example of an access control list and an analysis result table; FIG. FIG. 10 is a diagram showing an analysis example of a plug-in; FIG. 10 is a diagram showing an example of plug-in authentication; FIG. 4 is a diagram showing an example of placement of plug-ins through a firewall; 6 is a flow chart showing an example of a procedure for generating a plug-in; FIG. 11 is a flowchart showing an example of a plug-in authentication procedure; FIG. 6 is a flow chart showing an example of a procedure for adding a plug-in; FIG. 11 is a flowchart illustrating an example procedure for updating an ACL; FIG.

Hereinafter, this embodiment will be described with reference to the drawings.
[First embodiment]
A first embodiment will be described.

FIG. 1 is a diagram illustrating an example of an information processing system according to the first embodiment.
The information processing system of the first embodiment includes a data processing device 10 and an access control device 20. FIG. The data processing device 10 and the access control device 20 are connected to a network. The data processing device 10 and the access control device 20 can also be called a computer, an information processing device, a server computer, a server device, or the like.

The data processing device 10 stores data and performs event-driven information processing by executing a program according to data update. The information processing system of the first embodiment can also be called an event processing system. The information processing system of the first embodiment may be a parallel processing system including two or more data processors. The data processing device 10 can also be called a node. A new program to be executed according to data update can be registered in the data processing device 10 . When registering a new program of a certain user in the data processing apparatus 10, the access control device 20 confirms the user's data access authority and determines whether the program can be registered. The access control device 20 can also be referred to as a firewall, gateway, security device, program checking device, or the like.

The data processing device 10 has a storage section 11 and a processing section 12 . The access control device 20 has a storage section 21 and a processing section 22 . The storage unit 11 and the storage unit 21 may be volatile semiconductor memory such as RAM (Random Access Memory), or may be non-volatile storage such as HDD (Hard Disk Drive) or flash memory. The processing units 12 and 22 are processors such as CPUs (Central Processing Units), GPUs (Graphics Processing Units), and DSPs (Digital Signal Processors), for example. However, the processing units 12 and 22 may include electronic circuits for specific purposes, such as ASICs (Application Specific Integrated Circuits) and FPGAs (Field Programmable Gate Arrays). The processor executes a program stored in memory (which may be storage units 11 and 21). A collection of multiple processors is sometimes called a "multiprocessor" or simply a "processor."

The storage unit 11 stores data 13 . Data 13 includes a plurality of data items such as data items X, Y, and Z. FIG. Multiple data items can also be called multiple records. The data 13 may be key-value format data including a plurality of pairs of key and value. Data 13 may be updated. The data 13 may be state data indicating the state of the terminal device, and may be updated according to an event message transmitted from the terminal device to the data processing device 10 . The storage unit 11 may store programs in association with the data 13 . For example, the storage unit 11 stores programs in association with specific data items.

The processing unit 12 may register programs for the data 13 . This program is detachable from the data and can be called a plug-in. Program registration may be requested by the access control device 20 . Program registration may be performed dynamically while the data processing apparatus 10 is in operation. Also, the processing unit 12 detects an update of the data 13 . For example, the processing unit 12 updates the data 13 according to event messages received from terminal devices. If the registered program exists when the update of the data 13 is detected, the processing unit 12 activates the registered program. If the registered program is associated with a specific data item, the processing unit 12 may activate the registered program when detecting an update of the value of the specific data item.

The storage unit 21 stores access control information 24 . The access control information 24 indicates a data item to which a certain user has access authority or a data item to which a certain user does not have access authority among a plurality of data items such as data items X, Y, and Z. FIG. Access control information 24 may also be referred to as an access control list (ACL). The access control information 24 may be a so-called whitelist or a blacklist. The access control information 24 is created in advance by an administrator, for example.

The processing unit 22 accepts a registration request including the target program 23 of a certain user. A registration request indicates a request for registration of the target program 23 in the data processing apparatus 10 . The target program 23 can also be called a plug-in. The target program 23 is, for example, created by the user who is a developer. The access control device 20 may receive the registration request from the development terminal used by the user. The target program 23 may be source code written in a high-level language, intermediate code converted from the source code and written in an intermediate language, or machine-readable object code.

The processing unit 22 analyzes the target program 23 included in the registration request, and detects data items that can be accessed from the target program 23 among a plurality of data items such as data items X, Y, and Z. For example, the processing unit 22 uses a static program analysis method such as abstract interpretation to extract possible values of variables indicating data items to be accessed, and specifies data items to be accessed. A variable indicating a data item to be accessed is, for example, a variable used as an argument of a function that accesses the data 13 .

Based on the access control information 24, the processing unit 22 determines whether the user has access rights to the detected data item. If there are two or more detected data items, the processing unit 22 determines whether the user has access authority to all of the two or more detected data items. For example, assume that data item Y is detected as an accessible data item from target program 23 . In contrast, access control information 24 indicates that the user has access rights to data items X and Y, but does not have access rights to data item Z. FIG. In that case, the processing unit 22 confirms that the user has access rights to the data item Y that has been detected.

When determining that the user has access authority, the processing unit 22 permits the registration of the target program 23 in the data processing apparatus 10 . In that case, for example, the access control device 20 transfers a registration request including the target program 23 to the data processing device 10 . Thereby, the target program 23 is registered in the data processing device 10 . For example, in the data processing device 10, when the data item Y of the data 13 is updated, the target program 23 is activated. On the other hand, if it is determined that the user does not have access authority, the processing unit 22 refuses to register the target program 23 in the data processing apparatus 10 . In that case, for example, the access control device 20 prevents the registration request including the target program 23 from being transferred to the data processing device 10 . The access control device 20 may send a rejection message to the development terminal.

According to the information processing system of the first embodiment, before the target program 23 is registered in the data processor 10, the target program 23 is analyzed to detect data items that can be accessed. Based on the access control information 24, it is determined whether or not the user has access authority to the detected data item. Registered in device 10 . When the target program 23 accesses the data 13 after registration, the data processing apparatus 10 does not need to check the access authority for the data item to be accessed.

As a result, even if the data 13 contains a mixture of data items to which a certain user may be permitted to access and data items to which access should not be permitted, it is possible to implement access control for each data item. , can improve information security. In addition, after the target program 23 is registered, it is possible to omit confirmation of access authority in the data processing apparatus 10, and the access control information 24 does not have to be referred to for each access. As a result, compared to the method of confirming the access authority at the time of actual access, the overhead of confirming the access authority can be reduced, and the data processing delay of the data processing device 10 can be suppressed.

[Second embodiment]
Next, a second embodiment will be described.
FIG. 2 is a diagram illustrating an example of an information processing system according to the second embodiment.

The information processing system of the second embodiment is a real-time dynamic event processing system that collects event messages from devices to a data center, processes the event messages in real time, and provides event-driven services.

The information processing system of the second embodiment includes a data center 50 connected to a network 52, a plurality of devices such as devices 60, 60a, 60b, 60c, 60d, and 60e, and development devices 70, 70a, and 70b. including multiple development devices of The data center 50 includes a firewall 100 connected to a network 51, a message server 200, multiple nodes such as nodes 300, 300a and 300b, and multiple business servers such as business servers 400, 400a and 400b.

The network 51 is, for example, a data communication network such as a LAN (Local Area Network). Network 52 is, for example, a wide area data communication network such as the Internet. Note that the firewall 100 corresponds to the access control device 20 of the first embodiment, and the node 300 corresponds to the data processing device 10 of the first embodiment.

The devices 60 , 60 a , 60 b , 60 c , 60 d and 60 e are terminal devices that detect the occurrence of events and transmit event messages indicating the events to the message server 200 via the network 52 . Devices 60, 60a, 60b, 60c, 60d, and 60e include sensor data measured using sensors in an event message and transmit the event message.

Devices 60, 60a, and 60b are, for example, mobile terminal devices such as smartphones and tablet terminals. Devices 60c, 60d, and 60e are, for example, in-vehicle devices mounted in vehicles. Devices 60, 60a, 60b, 60c, 60d, and 60e may transmit location information including latitude and longitude measured using GPS (Global Positioning System) in event messages. Also, the devices 60, 60a, 60b, 60c, 60d, and 60e may include the current moving speed in the event message and transmit it.

The development devices 70 , 70 a and 70 b are terminal devices used for developing application software to be run in the data center 50 . The development devices 70, 70a, 70b are used by application software developers and administrators. For example, development device 70 is used by an administrator, development device 70a is used by developer A, and development device 70b is used by developer B who is a different developer from development device 70a.

The development devices 70, 70a, 70b can add plug-ins, which are detachable application programs, to the nodes 300, 300a, 300b without stopping the nodes 300, 300a, 300b. Also, the development devices 70, 70a, 70b can delete plug-ins from the nodes 300, 300a, 300b without stopping the nodes 300, 300a, 300b. At that time, the development devices 70, 70a, 70b transmit to the firewall 100 a control message indicating the addition or deletion of the plug-in. The development device 70 used by the administrator sets control information indicating conditions for plug-ins that can be placed in the nodes 300, 300a, and 300b to the firewall 100. FIG.

The firewall 100 is a server computer that receives control messages from the development devices 70, 70a, and 70b and determines whether plug-ins can be changed. Plug-ins of nodes 300 , 300 a and 300 b are changed via firewall 100 . Firewall 100 may also be referred to as a gateway, security device, or the like. Also, developers and administrators can be referred to as users with respect to plug-ins.

The firewall 100 holds control information indicating conditions for plug-ins that can be placed in the nodes 300, 300a, and 300b. When the firewall 100 receives a control message from the development devices 70, 70a, and 70b, the firewall 100 determines whether a change in plugins such as addition or deletion of plugins requested by the received control message satisfies a predetermined security condition. Firewall 100 forwards the control message to message server 200 if predetermined security conditions are met. On the other hand, if the predetermined security conditions are not satisfied, the firewall 100 refuses transfer of the control message.

The message server 200 is a server computer that transfers messages such as event messages and control messages. The message server 200 has message queues that hold received messages and forwards each message to one of the nodes 300, 300a, 300b. The message server 200 can also be called a load balancer.

The message server 200 receives event messages from the devices 60, 60a, 60b, 60c, 60d and 60e and distributes the event messages to the nodes 300, 300a and 300b. Also, the message server 200 receives control messages from the firewall 100 and distributes the control messages to the nodes 300, 300a, and 300b. Control messages are subject to security inspection by the firewall 100 . Therefore, the message server 200 rejects control messages that do not pass through the firewall 100, such as control messages directly sent to the message server 200 from the development devices 70, 70a, and 70b.

Nodes 300, 300a, 300b are server computers that distribute and process event messages of devices 60, 60a, 60b, 60c, 60d, 60e. Nodes 300, 300a and 300b distribute and hold state data indicating the states of devices 60, 60a, 60b, 60c, 60d and 60e.

When nodes 300, 300a, and 300b receive an event message from a device managed by another node, they transfer the event message to the other node. When the nodes 300, 300a, and 300b receive the event message of the device managed by their own node, they update the state data of the device. For example, the nodes 300, 300a, and 300b overwrite the sensor data included in the event message with the state data. If a plugin is associated with the updated state data, nodes 300, 300a, and 300b activate the associated plugin.

Nodes 300, 300a, 300b execute plug-ins to process state data and invoke event-driven information services. For example, nodes 300, 300a, and 300b detect mobile terminal devices existing in a predetermined area according to updated location information including latitude and longitude. Also, for example, the nodes 300, 300a, and 300b detect an in-vehicle device caught in a traffic jam according to the update of speed information indicating the moving speed. Event-driven information services can be realized by adding plug-ins. The nodes 300, 300a, and 300b may call the business servers 400, 400a, and 400b forming an external business system according to the execution result of the plug-in.

Nodes 300 , 300 a and 300 b also receive control messages from message server 200 . When the nodes 300, 300a, and 300b receive the control message indicating that the plug-in change target is another node, they transfer the control message to the other node. When the nodes 300, 300a, and 300b receive the control message indicating that the change target of the plug-in is their own node, they add or delete the plug-in according to the control message. The binary program, which is the plug-in itself, is distributed in the control message. Therefore, it is possible to suppress the concentration of accesses from a plurality of nodes to the common repository.

Business servers 400, 400a, and 400b are server computers forming a business system external to real-time dynamic event processing. The business servers 400, 400a, 400b receive event processing results from the nodes 300, 300a, 300b, execute business applications based on the event processing results, and provide business services.

For example, the business server 400 forms a personnel management system. The business server 400a forms a dashboard system that organizes various types of information. In that case, the business server 400a may provide various information to the devices 60, 60a, 60b, 60c, 60d, and 60e, or may provide various information to a predetermined administrator. The business server 400b forms an operation management system. In that case, business server 400b may provide road traffic information to other systems, and may realize automatic operation control of each vehicle.

FIG. 3 is a block diagram showing a hardware example of a firewall.
Firewall 100 has CPU 101 , RAM 102 , HDD 103 , image interface 104 , input interface 105 , media reader 106 and communication interface 107 . The above units of firewall 100 are connected to a bus. Note that the CPU 101 corresponds to the processing unit 22 of the first embodiment. The RAM 102 or HDD 103 corresponds to the storage section 21 of the first embodiment. Devices 60, 60a, 60b, 60c, 60d, 60e, development devices 70, 70a, 70b, message server 200, nodes 300, 300a, 300b, and business servers 400, 400a, 400b also have hardware similar to firewall 100. .

The CPU 101 is a processor that executes program instructions. The CPU 101 loads at least part of the programs and data stored in the HDD 103 into the RAM 102 and executes the programs. Note that the CPU 101 may include multiple processor cores, and the firewall 100 may include multiple processors. A collection of multiple processors is sometimes called a "multiprocessor" or simply a "processor."

The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used by the CPU 101 for calculation. Note that the firewall 100 may be provided with a type of memory other than the RAM, and may be provided with a plurality of memories.

The HDD 103 is a nonvolatile storage that stores an OS (Operating System), software programs such as middleware and application software, and data. Note that the firewall 100 may include other types of storage such as flash memory and SSD (Solid State Drive), or may include multiple storages.

The image interface 104 outputs an image to the display device 111 connected to the firewall 100 according to commands from the CPU 101 . As the display device 111, any type of display device can be used, such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD: Liquid Crystal Display), an organic EL (OEL: Organic Electro-Luminescence) display, or a projector. . Also, an output device other than the display device 111, such as a printer, may be connected to the firewall 100. FIG.

Input interface 105 receives an input signal from input device 112 connected to firewall 100 . Input device 112 can be any type of input device such as a mouse, touch panel, touch pad, keyboard, or the like. Also, multiple types of input devices may be connected to the firewall 100 .

The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 113 . Any type of recording medium can be used as the recording medium 113, such as magnetic disks such as flexible disks (FDs) and HDDs, optical disks such as CDs (Compact Discs) and DVDs (Digital Versatile Discs), and semiconductor memories. can be done. The medium reader 106 copies, for example, programs and data read from the recording medium 113 to other recording media such as the RAM 102 and the HDD 103 . The read program is executed by the CPU 101, for example. Note that the recording medium 113 may be a portable recording medium, and may be used for distribution of programs and data. Also, the recording medium 113 and the HDD 103 may be referred to as a computer-readable recording medium.

The communication interface 107 is connected to the network 51 and communicates with other information processing apparatuses. The communication interface 107 is, for example, a wired communication interface connected to a wired communication device such as a switch or router.

Next, real-time dynamic event processing will be described.
FIG. 4 is a block diagram showing an example of functions of a node.
Nodes 300, 300a, 300b have the following software modules. Node 300 has a plurality of message transfer units such as message transfer units 310 and 310a, a plurality of device objects such as device objects 320 and 320a, and one or more service objects such as service object 330. FIG. Node 300a has a plurality of message transfer units such as message transfer units 310b and 310c, a plurality of device objects such as device objects 320b and 320c, and one or more service objects such as service object 330a. Node 300b has a plurality of message transfer units such as message transfer units 310d and 310e, a plurality of device objects such as device objects 320d and 320e, and one or more service objects such as service object 330b.

The message server 200 receives event messages, distributes the event messages to the message transfer units 310, 310a, 310b, 310c, 310d, and 310e and transfers them. Event messages are distributed by, for example, a round-robin method. The message transfer units 310, 310a, 310b, 310c, 310d, and 310e determine the device object corresponding to the device that transmitted the event message, and transfer the event message to the determined device object. At this time, it is assumed that the message transfer units 310, 310a, 310b, 310c, 310d, and 310e know which device object is placed in which node. The transfer destination device object may be in the same node or in another node.

Device objects 320, 320a, 320b, 320c, 320d, and 320e manage state data indicating device states. One device object corresponds to one device. Specifically, device object 320 corresponds to device 60 . Device object 320a corresponds to device 60a. Device object 320b corresponds to device 60b. Device object 320c corresponds to device 60c. Device object 320d corresponds to device 60d. Device object 320e corresponds to device 60e.

When the device objects 320, 320a, 320b, 320c, 320d, and 320e receive the event message, they update their own state data using the sensor data included in the event message. State data is key-value format data in which keys and values are associated with each other. The device objects 320, 320a, 320b, 320c, 320d, and 320e overwrite the state data with the value corresponding to the key when the event message includes a key-value pair.

In device objects 320, 320a, 320b, 320c, 320d, and 320e, plug-ins can be associated with state data keys. The control message to add the plug-in specifies the target device object and the target key. Therefore, different plug-ins may be arranged depending on the device object. Also, two or more plug-ins may be placed in the same device object. These two or more plug-ins may be associated with the same key or with different keys. A single plug-in may be associated with more than one key.

The device objects 320, 320a, 320b, 320c, 320d, and 320e activate the plug-in when the key whose value has been updated is associated with the plug-in. Device objects 320, 320a, 320b, 320c, 320d, and 320e may reference or update state data, and may generate and send other event messages to any of the service objects, depending on the plug-in. .

Service objects 330, 330a, and 330b are objects corresponding to information services. For example, the service objects 330, 330a, and 330b detect devices existing in a predetermined area, detect devices whose moving speed is less than a threshold value, detect devices whose moving speed exceeds a threshold value, and the like. The service objects 330, 330a, 330b may receive event messages from the device objects 320, 320a, 320b, 320c, 320d, 320e as the plug-ins are executed.

The device object that sent the event message may be in the same node or in another node. Which device object sends the event message to which service object depends on the implementation of the plug-in. Service objects 330, 330a, 330b may hold state data. Service objects 330, 330a, 330b perform data processing based on received event messages and state data. As a result, service objects 330, 330a, 330b may send messages to any business server.

Also, the message server 200 receives control messages from the firewall 100, distributes the control messages to the message transfer units 310, 310a, 310b, 310c, 310d, and 310e and transfers them. The message transfer units 310, 310a, 310b, 310c, 310d, and 310e determine the device object to be changed in the plug-in, and transfer the control message to the determined device object.

When the device objects 320, 320a, 320b, 320c, 320d, and 320e receive the plug-in addition control message, they store the plug-in included in the control message in association with the key specified by the control message. This will cause the plugin to be executed when the value corresponding to that key is updated. When the device objects 320, 320a, 320b, 320c, 320d, and 320e receive the plug-in deletion control message, they delete the plug-in specified by the control message. In this way, developers can dynamically add or remove plug-ins.

FIG. 5 is a block diagram showing an example of functions of a device object.
The device object 320 has a state storage section 321 , a plug-in storage section 322 , a message determination section 323 , a state management section 324 , a plug-in management section 325 and a plug-in execution section 326 . Other device objects have similar modules. For the state storage unit 321 and the plug-in storage unit 322, for example, a storage area allocated to the device object 320 in the RAM storage area is used. The message determination unit 323, the state management unit 324, the plug-in management unit 325, and the plug-in execution unit 326 are implemented using programs, for example.

The state storage unit 321 stores state data in key-value format. State data includes one or more pairs of key and value. The plug-in storage unit 322 stores plug-ins in association with keys included in state data. Control messages received by the device object 320 contain compiled plug-in programs. A plug-in is placed executable on the device object 320 .

The message determination unit 323 receives a message from any message transfer unit and determines the type of the received message. Message types include events, plugin additions, and plugin deletions. The message determination section 323 outputs the event message to the state management section 324 . Also, the message determination unit 323 outputs a control message indicating plug-in addition or plug-in deletion to the plug-in management unit 325 .

The state management unit 324 acquires event messages from the message determination unit 323 . The state management unit 324 then extracts a key-value pair from the event message. A single event message may contain more than one key-value pair. The state management unit 324 searches the state data stored in the state storage unit 321 for the key extracted from the event message, and updates the value of the state data corresponding to the key to the value extracted from the event message. . If the key extracted from the event message does not exist in the state data, the state management unit 324 may add the extracted key-value pair to the state data.

The plug-in management unit 325 acquires a plug-in addition control message from the message determination unit 323 . Then, the plug-in management unit 325 stores the plug-in included in the control message in the plug-in storage unit 322 in association with the key specified by the control message. The plug-in management unit 325 also acquires a plug-in deletion control message from the message determination unit 323 . The plug-in management unit 325 then deletes the plug-in specified by the control message from the plug-in storage unit 322 .

When adding a plug-in, the plug-in management unit 325 may convert the plug-line program included in the control message so that the plug-in is executed immediately in response to the update of the state data. . For example, the plug-in program included in the control message may be bytecode compiled from source code and written in a predetermined low-level language. In that case, the plug-in management unit 325 may use a class loader to convert the bytecode into an executable class, and register the converted plug-in in a ready-to-call state.

The plug-in execution unit 326 detects that the value corresponding to the state data key has been updated by the state management unit 324 . Then, the plug-in execution unit 326 searches for a plug-in associated with the key whose value has been updated. The plug-in execution unit 326 executes the plug-in if the corresponding plug-in exists. Note that even if the value corresponding to a certain key is overwritten in response to an event message, if the value has not changed since before the overwriting, it may be considered that the value has not been updated.

FIG. 6 is a diagram showing examples of a state table and a plug-in table.
State table 327 is stored in state storage unit 321 . One or more records that associate keys and values are registered in the state table 327 . Keys include, for example, speed, latitude, longitude, and so on. Values corresponding to these keys are measured by the device 60 using a sensor and transmitted in an event message. For example, device 60 periodically sends event messages containing these values.

When the device object 320 receives an event message containing the value of “speed”, it overwrites the value in the state table 327 in association with “speed”. Similarly, when the device object 320 receives an event message containing the value of “latitude”, it overwrites the value in the state table 327 in association with “latitude”. When the device object 320 receives an event message containing the value of “longitude”, it overwrites the value in the state table 327 in association with “longitude”. Plugins can be added for speed, latitude and longitude.

A plug-in table 328 is stored in the plug-in storage unit 322 . Plug-in binary programs (plug-in binaries) are registered in the plug-in table 328 in association with one or more keys. The plugin table 328 can register plugin binaries created by different developers. For example, plug-in A1 created by developer A is registered for "speed", and plug-in B1 created by developer B is registered for "latitude" and "longitude".

In this case, when the "speed" value in the state table 327 is updated, the device object 320 will activate plug-in A1. If the "latitude" value in the state table 327 is updated, the device object 320 will activate plug-in B1. If the "longitude" value in the state table 327 is updated, the device object 320 will activate plug-in B1.

FIG. 7 is a diagram showing a format example of a message.
The message determination unit 323 may receive an event message 61 , a plug-in addition control message 71 , and a plug-in deletion control message 72 .

Event message 61 includes an object ID, type and sensor data. An object ID is an identifier that identifies a device object. An object ID can also be said to be an identifier that identifies a device. The object ID is assigned by the device that generates the event message 61 and is referenced to identify the destination device object of the event message 61 . The type of the event message 61 is "event". Sensor data includes one or more key-value pairs.

Control message 71 includes object ID, type, user ID, key, plugin ID and plugin binary. The object ID is an identifier that identifies the object to which the plug-in is added. The object ID is referenced to specify the destination device object of the control message 71 . The type of the control message 71 is "add". A user ID is an identifier that identifies a developer or administrator who created a plug-in. The key indicates the key to which the plug-in is added. A plug-in ID is an identifier that identifies a plug-in. The plugin ID may be an identifier calculated from the plugin itself, such as a hash value of the plugin binary. A plugin binary is a compiled binary program of the plugin.

Control message 72 includes object ID, type, user ID, key and plug-in ID. The object ID is an identifier that identifies an object whose plug-in is to be deleted. The object ID is referenced to identify the device object to which the control message 72 is directed. The type of the control message 72 is "deletion". A user ID is an identifier that identifies a developer or administrator who deletes a plug-in. The key indicates the target key for deleting the plug-in. However, when a plug-in is associated with two or more keys, the association with some keys may be canceled and the association with other keys may remain. A plug-in ID is an identifier that identifies a plug-in.

Next, the security of state data possessed by the device objects 320, 320a, 320b, 320c, 320d, and 320e will be described.
As described above, plug-ins of different users can be mixed and arranged for the same device object. A plug-in may read values from state data and write values to state data. At this time, from the viewpoint of information security, the state data may contain a value to which a certain user is permitted to access and a value to which the user should not be permitted to access. Therefore, it is preferable to control access to state data from plug-ins in units of keys.

As an access control method, a centralized management server that holds an access control list (ACL) is provided outside the real-time dynamic event processing system, and an access permission inquiry is made to the centralized management server each time a plug-in accesses state data. is also conceivable. However, this method may increase the overhead of checking access rights and reduce the throughput of real-time dynamic event processing.

Also, as an access control method, a method of copying the ACL to the nodes 300, 300a, and 300b and confirming the access authority within the node each time the plug-in accesses the state data is also conceivable. However, even with this method, the overhead of checking access rights increases, and the throughput of real-time dynamic event processing may decrease. Also, when updating ACLs, it may be difficult to keep the ACLs of multiple nodes consistent.

Therefore, in the second embodiment, the firewall 100 analyzes the plug-in and confirms that it conforms to the ACL before placing the plug-in on the nodes 300, 300a, and 300b. After it is confirmed that the plug-in conforms to the ACL, the checking of the access authority is omitted when the plug-in accesses the state data. As a result, the overhead of access control during plug-in execution can be reduced, and the throughput of real-time dynamic event processing can be improved.

However, since the access authority check is omitted when accessing, if the security policy indicated by the ACL is changed after the fact by the administrator, the existing plugins that have already been deployed may not be compatible with the updated ACL. . Therefore, the firewall 100 automatically revalidates the existing plug-ins when the administrator updates the ACL.

FIG. 8 is a block diagram showing an example of firewall functions.
Firewall 100 has ACL storage unit 121 , analysis result database 122 , message communication unit 123 , plug-in analysis unit 124 , authentication unit 125 and ACL update unit 126 . The ACL storage unit 121 and the analysis result database 122 are implemented using storage areas of the RAM 102 or the HDD 103, for example. The message communication unit 123, the plug-in analysis unit 124, the authentication unit 125, and the ACL update unit 126 are implemented using programs executed by the CPU 101, for example.

The ACL storage unit 121 stores an access control list (ACL) in which users, objects, and access-permitting keys are associated with each other. ACLs are created in advance by an administrator. ACLs may also be updated after the fact by an administrator. If a user develops a plugin and tries to add it to an object, the addition of the plugin is allowed if all of the keys that can be accessed by the plugin match the ACL. will be In the second embodiment, a whitelist ACL indicating keys for which access is permitted is used, but a blacklist ACL indicating keys for which access is not permitted may be used.

The analysis result database 122 is a history database that stores analysis results of existing plug-ins added to the nodes 300, 300a, and 300b. The analysis results stored in the analysis result database 122 are referenced to suppress reanalysis of existing plug-ins when updating the ACL. However, the firewall 100 may not have the analysis result database 122 and re-analyze existing plug-ins when updating the ACL.

Message communication unit 123 receives control messages from development devices 70, 70a, and 70b. Message communication unit 123 outputs a plug-in addition control message to plug-in analysis unit 124 and acquires a plug-in authentication result from authentication unit 125 . If the authentication is successful, that is, if the plug-in addition is permitted, the message communication section 123 transfers the control message to the message server 200 . On the other hand, if the authentication fails, that is, if the addition of the plug-in is rejected, the message communication unit 123 does not transfer the control message to the message server 200 and notifies the development device that transmitted the control message of an error.

Note that the firewall 100 may transfer the plug-in deletion control message to the message server 200 without performing authentication. Further, the firewall 100 may transfer the plug-in deletion control message to the message server 200 after confirming deletion authority. The firewall 100 may delete the analysis result of the plugin to be deleted from the analysis result database 122 .

The plug-in analysis unit 124 acquires a plug-in addition control message from the message communication unit 123 . The plug-in analysis unit 124 then analyzes the plug-in binary included in the control message and extracts keys that may be accessed from the plug-in. Key extraction uses static program analysis methods such as abstract interpretation. For example, the plug-in analysis unit 124 detects a variable that is used as an argument of a function that accesses state data, and extracts possible values of that variable as keys that may be accessed.

Plug-in analysis unit 124 outputs the analysis result to authentication unit 125 . Further, when the authentication unit 125 determines that the authentication is successful, the plug-in analysis unit 124 saves in the analysis result database 122 the authentication result in which the user, the object, the plug-in, and the access destination key are associated with each other.

Authentication unit 125 acquires the analysis result from plug-in analysis unit 124 . Then, the authentication unit 125 determines whether or not all keys that may be accessed match the ACL stored in the ACL storage unit 121 . That is, the authentication unit 125 searches the ACL for an access permission key corresponding to the user who created the plug-in and the target object. The authentication unit 125 determines whether each key extracted by the plug-in analysis unit 124 belongs to the range of access permission keys indicated by the ACL. If all of the extracted keys match the ACL, the authentication unit 125 permits plug-in addition and notifies the message communication unit 123 of authentication success. On the other hand, if any of the extracted keys does not match the ACL, the authentication unit 125 rejects the plug-in addition and notifies the message communication unit 123 of authentication failure.

The ACL updater 126 receives an ACL update message including a new ACL from the development device 70 used by the administrator. Then, the ACL updating unit 126 reads the analysis results of the existing plug-ins already arranged in the nodes 300, 300a, and 300b from the analysis result database 122. FIG. The ACL updating unit 126 uses the same method as the authenticating unit 125 to determine whether a key that may be accessed by an existing plug-in matches the new ACL.

When the old ACL is updated to the new ACL, existing plug-ins that conform to the old ACL may no longer conform to the new ACL. If there is an existing incompatible plug-in, the ACL updater 126 sends a warning message to the development device 70 used by the administrator. Then, the ACL updating unit 126 replaces the old ACL in the ACL storage unit 121 with the new ACL.

FIG. 9 is a diagram showing examples of an access control list and an analysis result table.
The access control list 127 is stored in the ACL storage unit 121. FIG. One or more records including user IDs, object IDs, and keys are registered in the access control list 127 . A user ID is an identifier that identifies a user, including developers and administrators. The object ID is an identifier that identifies the device object to which the plug-in is to be placed. An identifier of one device object such as "car001" may be specified as the object ID. Also, as the object ID, a class name representing the type of device, such as "car", may be used to specify the range of device object identifiers. A wild card (*) representing an arbitrary character string may be used in the object ID.

The key is an access permission key that allows access from plugins. A specific key, such as "speed", may be specified as an access permission key. Also, in the access permission key, a regular expression may be used, or a wildcard (*) may be used to specify the key range. A trailing wildcard allows you to specify a key prefix for which access is allowed. For example, by writing "a*", all keys beginning with "a" such as "a", "aa", and "ab" can be specified.

Note that in some real-time dynamic event processing systems, a plug-in located in one object may access state data in another object by sending messages to the other object. In that case, the access control list 127 may be expanded to include user IDs, access source object IDs, access destination object IDs, and keys. The access source object ID is an identifier that identifies the object in which the plug-in is arranged. The access destination object ID is an identifier that identifies the object to which the access destination state data belongs.

The analysis result table 128 is stored in the analysis result database 122. FIG. One or more records including user IDs, object IDs, plug-in IDs, and analysis results are registered in the analysis result table 128 . The user ID is an identifier that identifies the user who created the plug-in. The object ID is an identifier that identifies the device object in which the plug-in is arranged. The plug-in ID is an identifier that identifies the placed plug-in. The analysis result indicates a key that may be accessed from the plug-in and whether the access method is to read the value (read) or write the value (write).

Note that the analysis result table 128 may not include the plug-in ID from the viewpoint of verifying whether the existing plug-in conforms to the new ACL. The plug-in ID may be used to remove the non-conforming existing plug-in when an existing plug-in that does not conform to the new ACL is detected. Further, the analysis result table 128 may be normalized by dividing it into a table in which plug-in IDs, keys, and access methods are associated with each other, and a table in which user IDs, object IDs, and plug-in IDs are associated with each other.

Next, an analysis example and an authentication example of a plug-in will be described.
FIG. 10 is a diagram illustrating an example of plug-in analysis.
For ease of explanation, the plug-in is written in source code format. The plug-in analysis unit 124 actually analyzes compiled plug-in binaries.

The plug-in program 131 is an example of a plug-in. In the plug-in program 131, the initial value of the variable namespace is set to the character string "exampleSumPlugin". Next, while the loop variable i changes from 0 to 9, the value of the loop variable i added to the end of the variable namespace is substituted into the variable field, and the state data is read from and added to the variable sum. Next, it is determined whether the value of the variable sum is an even number, and if it is even, ".output.even" is added to the ending of the variable namespace, and if it is odd, ".output.odd" is added to the ending of the variable namespace. Finally, the state data is updated using the value of the variable namespace as a key and the value of the variable sum as a value.

The plug-in analysis unit 124 analyzes the plug-in program 131 by abstract interpretation. In abstract interpretation, the plug-in analysis unit 124 detects an assignment instruction that assigns a value to a variable, and adds an annotation indicating the possible values that the variable can take at that time for each assignment instruction. A variable in the source code corresponds to a register in the bytecode, and an annotation is added to each assignment instruction that assigns a value to the register in the analysis of the plug-in binary.

A plug-in program 132 with annotations is generated from the plug-in program 131 . In the plug-in program 132, the value range of the variable namespace when initializing the variable namespace is "exampleSumPlugin". The value range of the variable field when assigning a value to the variable field within the loop is "exampleSumPlugin.*". Here, "*" is a wildcard representing any character string. The value range of the variable namespace when the value of the variable sum is determined to be an even number is "exampleSumPlugin.output.even". The value range of the variable namespace when the value of the variable sum is determined to be an odd number is "exampleSumPlugin.output.odd". The value range of the final variable namespace is "exampleSumPlugin.output.*".

Next, the plug-in analysis unit 124 detects a function getState that reads a value from state data and a function setState that writes a value to state data. The plug-in analysis unit 124 extracts an argument indicating a key from the function getState and function setState, and specifies the possible values of the argument at that time.

A plug-in program 133 is generated from the plug-in program 132 . In the plug-in program 133, a value is read from the state data using the value of the variable field as a key. The value range of the variable field at this time is "exampleSumPlugin.*". Therefore, in the plug-in program 131, it is determined that the read process is performed for the key "exampleSumPlugin.*". In the plug-in program 133, a value is written in the state data using the value of the variable namespace as a key. At this point, the value range of the variable namespace is "exampleSumPlugin.output.*". Therefore, in the plug-in program 131, it is determined that the write process is performed for the key "exampleSumPlugin.output.*".

FIG. 11 is a diagram illustrating an example of plug-in authentication.
Wildcards can be used to specify keys in the plug-in analysis results and the access control list 127 . Therefore, the authentication unit 125 determines the inclusion relationship of the key range. If the entire key range indicated by the plug-in analysis result is included in the key range indicated by the access control list 127, the plug-in is permitted to be added. On the other hand, if at least part of the key range indicated by the plug-in analysis result is not included in the key range indicated by the access control list 127, the addition of the plug-in is rejected.

Plug-in programs 134, 135, and 136 are examples of plug-ins. The plug-in program 134 designates a specific character string "a" as the key. Thus, the key that can be accessed by the plug-in program 134 is "a". The plug-in program 135 may specify a specific character string "a" as a key, and may specify a character string with one or more "c"s added as a key. Thus, the key that can be accessed by plug-in program 135 is "a*". The plug-in program 136 uses function return values as keys. Thus, the key that can be accessed by the plug-in program 136 is "*" and is unknown.

The user who created the plug-in is developer A, the device object to which it is added is "car001", and the access control list 127 has an access permission key "a*" associated with the user ID and object ID. Assume that it is registered. Since "a" is included in "a*", the addition of plug-in program 134 is permitted. Also, since "a*" is included in "a*", addition of the plug-in program 135 is permitted. On the other hand, since "*" is not included in "a*", the addition of plug-in program 136 is rejected. In this way, whether or not a plug-in can be added is determined based on the key range inclusion relationship.

FIG. 12 is a diagram showing an example of placement of plug-ins through a firewall.
Firewall 100 receives plug-in addition control messages 141 and 142 . The control message 141 requests that the plug-in 143 (plug-in B1) created by the developer B be added to the device object "car001". Control message 142 requests that plug-in 144 (plug-in B2) created by developer B be added to device object "car001."

The firewall 100 analyzes the plug-in 143 and determines that the keys that may be accessed from the plug-in 143 are "latitude" and "longitude". Firewall 100 also analyzes plug-in 144 and determines that the key that may be accessed from plug-in 144 is "speed." On the other hand, the access control list 127 of the firewall 100 describes that access by the developer B to the key "latitude" of the device object "car001" is permitted. The access control list 127 also describes that access by the developer B to the key "longitude" of the device object "car001" is permitted.

Firewall 100 then allows plug-in 143 to be added to device object “car001” and forwards control message 141 to node 300 via message server 200 . Device object 320 of node 300 receives control message 141 and registers plug-in 143 included in control message 141 . For example, the device object 320 registers the plug-in 143 in association with the keys “latitude” and “longitude” of the state table 327 . As a result, the plug-in 143 is executed when the value of "latitude" or "longitude" is updated. When the plug-in 143 accesses the state table 327, confirmation of access authority is unnecessary.

On the other hand, firewall 100 denies adding plug-in 144 to device object “car001”. In this case, control message 142 is not forwarded to node 300 and plug-in 144 is not registered with device object 320 .

Next, a procedure example of the information processing system according to the second embodiment will be described.
FIG. 13 is a flow chart showing an example of a plug-in generation procedure.
Plug-in generation is executed by development devices such as development devices 70, 70a, and 70b. Here, description will be given assuming that the development device 70 executes it as a representative.

(S10) The development device 70 receives an input from the user and creates a plug-in source code according to the input from the user. However, the development device 70 may receive a plug-in source code file from another information processing device.

(S11) The development device 70 compiles the plug-in source code created in step S10 to generate a plug-in binary. For example, the development device 70 converts the plug-in source code into bytecode written in an intermediate language.

(S12) The development device 70 generates a plug-in addition control message including the plug-in binary generated in step S11. The object ID of the control message is the identifier of the device object at the placement destination, and is specified by the user. The user ID of the control message is the identifier of the user who uses development device 70 . The key of the control message is a key used as a plug-in execution condition and is specified by the user. The plugin ID of the control message may be automatically generated from the plugin binary.

(S13) The development device 70 transmits the control message generated in step S12 to the firewall 100. FIG. If the control message is directly transmitted to the message server 200, the message server 200 rejects the control message, and the message server 200 notifies the development device 70 of an error.

FIG. 14 is a flow chart showing an example procedure for plug-in authentication.
Plugin authentication is performed at firewall 100 .
(S20) The message communication unit 123 receives a control message for plug-in addition.

(S21) The plugin analysis unit 124 extracts the plugin binary from the control message. The plug-in analysis unit 124 analyzes the plug-in binary using a static program analysis method such as abstract analysis, and performs semantic analysis of the plug-in. For example, the plug-in analysis unit 124 detects a read function that reads a value from state data and a write function that writes a value to state data from the plug-in binary. The plug-in analysis unit 124 determines possible values (value ranges) of the arguments of the read function and the write function.

(S22) The plug-in analysis unit 124 extracts keys that may be subject to read or write in the plug-in based on the analysis result of step S21.
(S23) The authentication unit 125 selects one key extracted in step S22.

(S24) The authentication unit 125 extracts the user ID and object ID from the control message. Authentication unit 125 searches access control list 127 using the extracted user ID and object ID, and the key selected in step S23. At this time, the authentication unit 125 searches the access control list 127 for a record that satisfies the conditions. A record that satisfies the conditions is a record that includes the specified user ID and object ID, and an access permission key that includes the specified key.

(S25) The authentication unit 125 determines whether access to the key selected in step S23 is permitted under the specified user ID and object ID. If the corresponding record is retrieved from the access control list 127 in step S24, it is determined that access is permitted. If no corresponding record is retrieved from the access control list 127, it is determined that access is not permitted. If access to the selected key is permitted, the process proceeds to step S26; otherwise, the process proceeds to step S30.

(S26) In step S23, the authentication unit 125 determines whether all the keys extracted in step S22 have been selected. If all keys have been selected, the process proceeds to step S27, and if there are unselected keys, the process returns to step S23.

(S27) The authentication unit 125 refers to the analysis result of step S21 and determines whether the plug-in uses a predetermined prohibited API (Application Programming Interface). Forbidden APIs are library functions that are not desirable for plug-ins to use from the security point of view, and are defined in advance by the administrator. For example, prohibited APIs include functions that access the local file system. If the prohibited API is used, the process proceeds to step S30, and if the prohibited API is not used, the process proceeds to step S28.

(S28) The plug-in analysis unit 124 registers the analysis result of step S21 in the analysis result table 128 included in the analysis result database 122. FIG.
(S29) The message communication unit 123 transfers the control message received in step S20 to the message server 200. FIG. Then, plug-in authentication ends.

(S30) The message communication unit 123 discards the received control message and notifies the development apparatus that transmitted the control message of the plug-in addition refusal.
FIG. 15 is a flow chart showing an example procedure for adding a plug-in.

Addition of the plug-in is performed by cooperation between the message server 200 and the nodes 300, 300a, and 300b. Here, it is assumed that the node 300 is the representative and that the plug-in addition destination is the device object 320 .

(S40) The message server 200 receives the plug-in addition control message. Note that the message server 200 accepts control messages from the firewall 100, but does not accept control messages from other information processing devices.

( S<b>41 ) The message server 200 transfers the control message to the message transfer section 310 of the node 300 . The message server 200 may select forwarding destinations in a round-robin fashion. The message transfer unit 310 transfers the control message to the device object 320 by referring to the object ID included in the control message.

(S42) The plug-in manager 325 of the device object 320 extracts the plug-in binary from the control message. The plug-in management unit 325 performs plug-in binary conversion processing. For example, the plug-in manager 325 converts plug-in bytecodes into executable classes using a class loader.

(S43) The plug-in management unit 325 registers the plug-in so that the plug-in is called when the value corresponding to the key specified by the control message is updated. The plugin management unit 325 registers plugins in the plugin table 328 .

FIG. 16 is a flowchart illustrating an example procedure for updating an ACL.
ACL updates are performed at firewall 100 .
(S50) The ACL updating unit 126 receives the new access control list (new ACL). The new access control list is sent, for example, from the development device 70 used by the administrator.

(S51) The ACL updating unit 126 temporarily suspends plug-in authentication performed by the authenticating unit 125. FIG. Control messages arriving in the meantime will be held.
(S52) The ACL updating unit 126 selects one existing plug-in record from the analysis result table 128 included in the analysis result database 122. FIG.

(S53) The ACL updating unit 126 selects one key that may become a read target or write target from the analysis results included in the record selected in step S52.
(S54) The ACL updating unit 126 extracts the user ID and object ID from the record of the existing plug-in selected in step S52. The ACL updating unit 126 searches the new access control list received in step S50 using the extracted user ID and object ID and the key selected in step S53. At this time, the ACL updating unit 126 searches the new access control list for a record that satisfies the conditions. A record that satisfies the conditions is a record that includes the specified user ID and object ID, and an access permission key that includes the specified key.

(S55) The ACL updating unit 126 determines whether access to the key selected in step S53 is permitted under the specified user ID and object ID. If the corresponding record is retrieved from the new access control list in step S54, it is determined that access is permitted. If the corresponding record is not retrieved from the new access control list, it is determined that access is not permitted. If access to the selected key is permitted, the process proceeds to step S56; otherwise, the process proceeds to step S57.

(S56) The ACL updating unit 126 determines whether all the keys included in the analysis result have been selected in step S53. If all keys have been selected, the process proceeds to step S58, and if there are unselected keys, the process returns to step S53.

(S57) The ACL updating unit 126 notifies the development device that transmitted the new access control list of the existing plug-in selected in step S52 as an incompatible plug-in. For example, the ACL updating unit 126 transmits the plug-in ID to the development device 70. FIG.

(S58) The ACL updating unit 126 determines whether or not all existing plug-in records have been selected from the analysis result table 128 in step S52. If all have been selected, the process proceeds to step S59, and if there are unselected items, the process returns to step S52.

(S59) The ACL updating unit 126 replaces the old access control list stored in the ACL storage unit 121 with the new access control list received in step S50.
(S60) The ACL updating unit 126 cancels suspension of plug-in authentication in step S51. This resumes processing of the pending control message.

According to the information processing system of the second embodiment, event messages are collected from devices, and state data indicating device states are held in device objects corresponding to the devices. A plug-in placed in the device object is activated according to the update of state data, and event-driven data processing is performed. This allows real-time dynamic event processing to be performed efficiently. Also, plug-ins can be added to the device object without stopping the device object. As a result, it is possible to dynamically add or update services that use state data, and to suppress stoppage of real-time dynamic event processing.

Also, plug-ins from different developers can be placed in the same device object. Therefore, it becomes possible to implement various application software on the real-time dynamic event processing system. In addition, access control can be performed to limit data accessible from plug-ins in units of keys included in state data. Therefore, state data collected from the device can be protected.

Also, checking for access rights is done by parsing the plugin before adding it to the device object, and omitted after the plugin is deployed. Therefore, it is not necessary to confirm the access authority each time the plug-in accesses the state data, thereby reducing the overhead of access control and improving the throughput of real-time dynamic event processing. For example, communication overhead can be reduced compared to a method of inquiring a centralized management server holding an access control list each time state data is accessed. Also, for example, compared to the method of distributing the access control list to a plurality of nodes, it becomes easier to maintain the consistency of the access control list when updating the access control list.

Semantic analysis such as abstract interpretation is performed in the plug-in analysis. Therefore, it is possible to reduce the risk of overlooking that the plug-in accesses unauthorized keys. For example, as a plug-in, it is possible to create a program that writes an initial value to a variable indicating a key, and then rewrites the value of that variable ex post facto to change the access destination key. Even for such plugins, the risk of accessing unauthorized keys can be assessed compared to simple static program analysis methods that trace source code descriptions.

In addition, the analysis results when plug-ins are added are saved in the history database, and when the access control list is updated, existing plug-ins are automatically checked to see if they are compatible with the new access control list. Then, if there is an existing incompatible plug-in, a warning is sent to the administrator who created the new access control list. Therefore, plug-ins that no longer conform to the access control list can be detected ex post facto without confirming the access authority each time the state data is accessed, and the security of the state data can be maintained.

The foregoing merely illustrates the principles of the invention. Furthermore, many variations and modifications will occur to those skilled in the art, and the present invention is not limited to the precise construction and applications shown and described above, and all corresponding variations and equivalents are and the equivalents thereof.

REFERENCE SIGNS LIST 10 data processing device 11, 21 storage unit 12, 22 processing unit 13 data 20 access control device 23 target program 24 access control information

Claims (8)

a data processing device that stores data including a plurality of data items, and executes the registered program in accordance with an update of the data when the registered program exists;
receiving a registration request including a user's target program, analyzing the target program to detect a data item that can be accessed from the target program from among the plurality of data items, and detecting a data item to which the user has access authority or the user determining whether the user has access authority to the detected data item based on access control information indicating data items to which the user does not have access authority; an access control device that permits registration with a device;
An information processing system having After permitting registration of the target program, the access control device accepts a request to update the access control information, and the user has access authority to the detected data item based on the updated access control information. re-determine whether or not, and output a warning message when it is determined that you no longer have access privileges,
The information processing system according to claim 1. The access control device stores an analysis history indicating the detected data items, and uses the analysis history to perform re-determination based on the updated access control information.
3. The information processing system according to claim 2. The access control device receives the registration request, transfers the registration request to the data processing device when permitting registration of the target program, and transfers the registration request when rejecting registration of the target program. suppress the
The information processing system according to claim 1. The data processing device generates a plurality of objects corresponding to a plurality of terminal devices, causes each of the plurality of objects to hold the data and the registered program,
the registration request includes designation of a registration destination object, the access control information indicates whether or not there is access authority for a set of an object and a data item;
The access control device determines whether the user has access rights to the detected data item of the registration destination object, based on the access control information.
The information processing system according to claim 1. a storage unit for storing access control information indicating a data item to which a user has access authority or a data item to which the user does not have access authority among a plurality of data items;
receiving a registration request including the user's target program, analyzing the target program to detect a data item that can be accessed from the target program from among the plurality of data items, and determining the detected data item based on the access control information determining whether the user has the access authority to the data item, and if it is determined that the user has the access authority, the target program is executed in accordance with the update of the data including the plurality of data items; a processing unit that permits registration in an information processing system;
an access control device having the computer
receiving a registration request including a user's target program, analyzing the target program and detecting data items that can be accessed from the target program among a plurality of data items;
whether the user has access authority to the detected data item based on access control information indicating data items to which the user has access authority or data items to which the user does not have access authority among the plurality of data items; judge,
If it is determined that the access authority is granted, the target program is permitted to be registered in the information processing system so that the target program is executed in accordance with the update of the data including the plurality of data items.
Access control method. to the computer,
receiving a registration request including a user's target program, analyzing the target program and detecting data items that can be accessed from the target program among a plurality of data items;
whether the user has access authority to the detected data item based on access control information indicating data items to which the user has access authority or data items to which the user does not have access authority among the plurality of data items; judge,
If it is determined that the access authority is granted, the target program is permitted to be registered in the information processing system so that the target program is executed in accordance with the update of the data including the plurality of data items.
The access control program that causes the action to take place.

Images