JP2013093058A - Apparatus, history information recording method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To properly record log information on processing to be executed by an application.SOLUTION: An apparatus capable of executing an application program, includes history information recording means, and processing execution means. In response to a processing execution request from the application program, the history information recording means records, in a storage, history information on the processing including identification information on the execution request. If the history information can be recorded in the storage, the processing execution means executes processing based on the execution request.

Description

  The present invention relates to a device, a history information recording method, and a program, and more particularly, to a device, history information recording method, and program for recording history information related to processing executed by an application.

  In recent years, there are some image forming apparatuses that are mainly called multifunction peripherals or multi-functional peripherals, and that are capable of developing and installing new applications using published API (Application Program Interface) after shipment. (For example, patent document 1). In such an image forming apparatus, it is possible to install not only an application developed by the vendor of the image forming apparatus but also an application developed by a third vendor, thereby significantly improving the expandability of the functions of the image forming apparatus. Can do.

  However, the installation of an unspecified application may reduce the security of the image forming apparatus. This is because it is difficult to determine in advance whether or not each application is an unauthorized application. In particular, recent image forming apparatuses include a large-scale storage device, and various kinds of confidential information (user personal information, scanned confidential document image data, etc.) can be managed in the large-scale storage device. It is not preferable that such confidential information is illegally accessed by an unspecified application.

  Recording of log information is effective as a means for detecting the presence of such an unauthorized application. However, conventionally, some implementation (for example, a call of a log recording function) is required for an application in order to realize recording of log information. However, in the case of such a mechanism, if the implementation is not properly performed in the application, the log information may be missed. As a result, there is a problem that the presence of an unauthorized application cannot be detected.

  The present invention has been made in view of the above points, and an object of the present invention is to provide a device, a history information recording method, and a program that can appropriately record history information related to processing executed by an application.

  Accordingly, in order to solve the above-described problem, the present invention is a device capable of executing an application program, and in response to a process execution request from the application program, includes history information related to the process including identification information related to the execution request. Is recorded in a storage device, and when the history information can be recorded in the storage device, a process execution unit that executes a process based on the execution request is provided.

  In such a device, history information relating to processing executed by the application can be appropriately recorded.

  According to the present invention, it is possible to provide a device, a history information recording method, and a program that can appropriately record history information related to processing executed by an application.

It is a figure which shows the system configuration example in embodiment of this invention. It is a figure which shows the hardware structural example of the apparatus in embodiment of this invention. It is a figure which shows the software structural example of the apparatus in 1st embodiment. It is a flowchart for demonstrating the process outline | summary of the apparatus in 1st embodiment. It is a sequence diagram for demonstrating the process sequence of the apparatus in 1st embodiment. It is a figure which shows the software structural example of the apparatus in 2nd embodiment. It is a flowchart for demonstrating the process outline | summary of the apparatus in 2nd embodiment. It is a sequence diagram for demonstrating the process sequence of the apparatus in 2nd embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing an example of a system configuration in the embodiment of the present invention. In FIG. 1, a log collection server 10 and devices 20a, 20b, and 20c (hereinafter collectively referred to as “device 20”) are a network 15 (wired or wireless) such as a LAN (Local Area Network) in an office. The connection is not limited.)

  The device 20 is an image forming apparatus (multifunction machine) that realizes a plurality of functions such as copying, facsimile, printer, and scanner in a single casing.

  The log collection server 10 is a computer that collects and centrally manages various types of log information generated in the device 20. A plurality of log collection servers 10 may exist.

  FIG. 2 is a diagram illustrating a hardware configuration example of a device according to the embodiment of the present invention. In FIG. 2, the device 20 includes hardware such as a controller 201, a scanner 202, a printer 203, a modem 204, a network interface 205, and an operation panel 206.

  The controller 201 includes a CPU 211, a RAM 212, a ROM 213, an HDD 214, and the like. The ROM 213 stores various programs and data used by the programs. The RAM 212 is used as a storage area for loading a program, a work area for the loaded program, and the like. The CPU 211 realizes functions to be described later by processing a program loaded in the RAM 212. The HDD 214 is used to store various data (for example, scanned image data).

  The scanner 202 is hardware for reading image data from a document. The printer 203 is hardware for printing image data on printing paper. The modem 204 is hardware for connecting to a telephone line, and is used to execute transmission / reception of image data by FAX communication. The network interface 205 is hardware for connecting to the network 15. The operation panel 206 is hardware including a button, a liquid crystal panel, and the like for receiving input from the user and notifying the user of information.

  FIG. 3 is a diagram illustrating a software configuration example of the device according to the first embodiment. In the first embodiment, recording of a communication log (communication history) will be described. In FIG. 3, the device 20 includes software such as an SDK application 30, an SDK platform 40, a log service 51, and a socket library 52. Each of these software is loaded into the RAM 212 and realizes its function by causing the CPU 211 to execute processing.

  The log service 51 records a log related to communication (particularly encrypted communication) performed by the SDK application 30 described later in the log storage area 60. The log service 51 also controls transfer of logs recorded in the log storage area 60 to the log collection server 10. The log storage area 60 is a log recording area provided in the RAM 212 or the HDD 214. The socket library 52 is a so-called socket library, and provides an API used in TCP / IP communication to the upper module.

  The SDK platform 40 is a software platform that provides an execution environment for the SDK application 30. In the drawing, an SDK common processing module 401, a JVM (Java (registered trademark) Virtual Machine) 402, a JSSE 403, a communication service 404, a communication log service 405, and the like are included in the SDK platform 40.

  The JVM 402 converts a Java (registered trademark) bytecode into a native code operable on the OS and executes it. The software illustrated above the JVM 402 is implemented by Java (registered trademark) bytecode. JSSE403 is a framework and implementation of Java (registered trademark) standard encrypted communication (SSL (Secure Socket Layer), etc.).

  The communication service 404 and the communication log service 405 are bundles that operate on an OSGi (Open Service Gateway initiative) framework. The OSGi framework is a standardized technology by the OSGi Alliance, and is a software platform that provides an execution environment for software components created based on an open software componentization technology based on the Java (registered trademark) language. On the OSGi framework, Java (registered trademark) language software is implemented in the form of software components called “bundles”. One bundle is constituted by one JAR (Java (registered trademark) ARchive) file, and can be installed dynamically independently (without restarting the apparatus). The communication service 404 controls communication processing related to a communication protocol of a so-called application layer such as HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol), SNMP (Simple Network Management Protocol), and LDAP (Lightweight Directory Access Protocol). An interface related to the communication processing is provided to the SDK application 30. The communication service 404 performs encrypted communication using the JSSE 403 when the SDK application 30 requests encrypted communication. The communication log service 405 controls a log (communication log) recording process when a communication request is generated from the SDK application 30.

  In addition, the SDK platform 40 includes a standard class of Java (registered trademark), a class library related to a class extended for the device 20, and the like. For example, in the figure, a security manager 406 is shown as part of the JVM 402. The security manager 406 is implemented by a class that extends the Java (Registered Trademark) standard SecurityManager class. Accordingly, the security manager 406 restricts access to resources such as files, network sockets, and printers by the SDK application 30 based on access control information defined in advance in the policy file. That is, the SDK platform 40 is configured such that a call to the security manager 406 occurs when access to various resources occurs. The security manager 406 determines whether to access the resource according to the call. Using this mechanism, in this embodiment, the security manager 406 detects execution of encrypted communication by the SDK application 30.

  The SDK application 30 is an application (hereinafter referred to as “SDK application”) created using a dedicated SDK (software development kit) published on the SDK platform 40. A plurality of SDK applications 30 can be installed on the SDK platform 40.

  Hereinafter, the processing procedure of the device 20 in the first embodiment will be described. FIG. 4 is a flowchart for explaining an outline of processing of the device in the first embodiment.

  In the device 20, the SDK application 30 that starts communication makes a communication processing execution request to the SDK platform 40 (S101). Subsequently, the device 20 determines whether or not the communication performed by the SDK application 30 is encrypted communication (S102). If it is encrypted communication (YES in S102), the device 20 prepares for recording log information (S103). Specifically, the value of an item to be recorded as log information is determined. For example, a communication protocol and an encryption protocol used for communication are determined. Subsequently, the device 20 opens a communication socket (S106) and records log information (S107). Subsequently, the device 20 performs communication processing using a protocol specified by the SDK application 30 (S109).

  On the other hand, if it is not encrypted communication (NO in S102), the device 20 determines whether it is intra-device communication (S104). In-device communication refers to communication between programs within the device 20 (for example, inter-process communication). If it is not intra-device communication (NO in S104), the device 20 determines a communication protocol used for communication as preparation for recording log information (S105). Since it is not encrypted communication, the value of the encryption protocol is “none”. Subsequently, steps S106 to S109 are executed.

  In the case of intra-device communication (YES in S104), the device 20 opens a socket (S108), and performs communication processing according to the protocol specified by the SDK application 30 (S109). Therefore, log information is not recorded in the case of intra-device communication. This is because the in-device communication is considered to be less important from the viewpoint of security (that is, the communication with the outside of the device 20 is considered to be more important). In addition, when log information is recorded for all intra-device communications, the log storage area 60 is consumed in a short period of time. If it is desired to further suppress consumption of the log storage area 60, log information may be recorded only for encrypted communication. Encrypting the communication content is considered to be important. Therefore, by recording log information only for encrypted communication, it is possible to record log information related to important communication while suppressing consumption of the log storage area 60.

  Next, the processing procedure whose outline has been described with reference to FIG. 4 will be described in more detail. FIG. 5 is a sequence diagram for explaining the processing procedure of the device in the first embodiment.

  When the SDK application 30 requests the communication service 404 to execute encrypted communication using a desired communication protocol (HTTP, FTP, SNMP, LDAP, etc.), the communication service 404 requests the JSSE 403 to execute encrypted communication. (S201). In the figure, the communication service 404 is omitted for convenience. A request for the communication service 404 from the SDK application 30 is realized, for example, by calling a method of a class corresponding to a desired communication protocol. That is, a class exists for each communication protocol in the communication service 404.

  A request from the communication service 404 to the JSSE 403 is realized by calling a method of a class corresponding to the communication requested by the SDK application 30 among the classes included in the JSSE 403. For example, the class (JSSE 403 class) to be called differs depending on the desired communication protocol of the SDK application 30, the communication as a client or the communication as a server, and the like.

  The class called in JSSE 403 notifies the security manager 406 that it has been called (generation of a communication request) (S202). Subsequently, the security manager 406 determines a communication protocol and an encryption protocol used for communication (S203). This determination is made by stack trace. That is, the call relationship between classes (call hierarchy state) is recorded in a stack (call stack) formed in the RAM 212. The security manager 406 refers to the call stack and traces the call path from the JSSE 403 to grasp the class (class name) called in the JSSE 403 and the class (class name) called in the communication service 404. The communication protocol used by the class name called in the communication service 404 is determined. The class name called in the JSSE 403 determines that the encrypted communication is requested and the encryption protocol used for the encrypted communication. Is done. When encrypted communication is not requested, no call is made to the JSSE 403 class. Therefore, the security manager 406 determines that it is not encrypted communication when the class (JSSE403 class) related to encrypted communication is not included in the call stack.

  In the case of encrypted communication, the security manager 406 notifies the communication log service 405 of the determined communication protocol and identification information (eg, protocol name) of the encrypted protocol as log information (S204). The communication log service 405 requests the log service 51 to record the log information via the SDK common processing module 401 (S205, S206).

  Subsequently, the log service 51 checks the free capacity of the log storage area 60, and determines whether or not log information can be recorded (written) (S207). When the log storage area 60 has sufficient free space, the log service 51 records log information in the log storage area 60 (S208). At this time, the log service 51 records time information, a log ID, and the like in addition to the identification information of the communication protocol and the encryption protocol. The log ID is a unique ID for each log (log for one write). Subsequently, the log service 51 responds to the SDK common processing module 401 that the log information has been successfully recorded (S209). The SDK common processing module 401 notifies the security manager 406 that communication processing is possible because the log information has been successfully recorded (S210). Upon receiving the notification, the security manager 406 sends a response to the JSSE 403 to permit the processing related to the communication request notified in step S202 (S211). The JSSE 403 receives the permission from the security manager 406 and executes communication processing (communication start, data transmission / reception, communication end, etc.) requested by the SDK application 30 using the socket library 52 (S212). When information indicating the processing result (success / failure of processing) is returned from the socket library 52 (S213), the JSSE 403 returns the information to the SDK application 30 (S214).

  On the other hand, when the log service 51 determines in step S207 that the log storage area 60 is in a log full or near full state (the free capacity is equal to or less than a predetermined value) and log information cannot be written or is not appropriate, Response to the SDK common processing module 401 (S221). The SDK common processing module 401 notifies the security manager 406 that the communication processing is impossible because the log information recording has failed (S222). Upon receiving the notification, the security manager 406 makes a response to the JSSE 403 that the process related to the communication request notified in step S202 is not permitted (S223). In response to the non-permission response from the security manager 406, the JSSE 403 responds to the SDK 30 that the requested communication process cannot be executed (S224).

  Incidentally, when the log storage area 60 is in a log full or near full state, the log service 51 may transfer the log information recorded in the log recording area 60 to the log collection server 10. In this case, by deleting the transferred log information from the log storage area 60, the free capacity of the log storage area 60 can be secured and the communication process can be executed. However, if the log collection server 10 side is log full or near full, the processing from step S221 is executed.

  Note that the transfer of log information to the log collection server 10 may be performed periodically or sequentially each time the log information is recorded. The timing at which data is transferred may be set by an administrator or the like via the operation panel 206. In this case, the setting content (information indicating the transfer timing) is stored in the HDD 214. The log service 51 refers to the setting content and determines the transfer timing of the log information.

  As described above, according to the device 20 of the first embodiment, log information can be forcibly recorded even when there is no explicit log information recording request from the SDK application 30 regarding encrypted communication. it can. Therefore, it is possible to prevent a log record from being missed and to improve the possibility of detecting the presence of an unauthorized SDK application 30.

  Further, since log information is recorded for encrypted communication, it is possible to record log information related to communication important for security while suppressing rapid enlargement of the amount of accumulated log information. In addition, when log information cannot be recorded, execution of communication processing is not permitted, and therefore, it is possible to prevent the occurrence of a situation in which the unauthorized processing is performed without leaving a trace of unauthorized processing. .

  Next, recording of a job log (job history) will be described as a second embodiment. In the second embodiment, differences from the first embodiment will be described. Accordingly, the points not particularly mentioned may be the same as those in the first embodiment.

  FIG. 6 is a diagram illustrating a software configuration example of the device according to the second embodiment. In FIG. 6, the same parts as those in FIG.

  The SDK platform 40 shown in the figure includes a job service 407, an application manager 408, a job control module 409, an authentication manager 410, a job log manager 411, and the like.

  The job service 407 controls the hardware of the device 20 with respect to a job requested to be executed (printing, scanning, copying, FAX transmission, etc.). The application manager 408 manages information (application information) related to the SDK application 30. For example, when the SDK application 30 is installed, correspondence information between the product ID of the SDK application 30 and the identification name (application name) of the SDK application 30 is registered in the application manager 408. The application manager 408 manages the correspondence information by recording it in the HDD 214. The product ID is an ID assigned to each product of the SDK application 30.

  The job control module 409, the authentication manager 410, and the job log manager 411 are bundles that operate on the OSGi framework. The job control module 409 receives a job execution request from the SDK application 30. The authentication manager 410 performs authentication when the user of the device 20 logs in. User information (for example, a user name and password) is recorded in the HDD 214 of the device 20, and the authentication manager 410 is based on information (user name, password, and the like) input on the login screen displayed on the operation panel 206. Authentication is performed, and the user name or user ID of the authenticated user is stored in the RAM 212. The authenticated user can cause the device 20 to execute a job using the SDK application 30 of the device 20 as a login user. The job log manager 411 controls log (job log) recording processing when a job execution request is generated from the SDK application 30.

  Hereinafter, the processing procedure of the device 20 in the second embodiment will be described. FIG. 7 is a flowchart for explaining an outline of processing of the device in the second embodiment.

  In the device 20, the SDK application 30 issues an execution request to the SDK platform 40 for a job (such as printing, scanning, copying, or FAX transmission) instructed to be executed by the user via the operation panel 206 (S301). In response to the job execution request, the job service 407 generates job information to be output to the job log (S311). The job information includes, for example, information (parameters) related to job execution conditions. The parameter relating to the job execution condition is input by the user when the job execution instruction is given, for example. If the job information is successfully generated (YES in S312), the job service 407 notifies the job log manager 411 of the generated job information (S313).

  Further, the authentication manager 410 acquires user information (user name and the like) of the login user at the time of job execution request from the RAM 212 (S321). When acquisition of user information is successful (YES in S322), the authentication manager 410 notifies the job log manager 411 of user information (S323).

  In addition, the application manager 408 acquires application information (product ID) of the SDK application 30 that is the job execution request source (S331). If acquisition of the product ID is successful (YES in S332), the application manager 408 notifies the job log manager 411 of the product ID (S333).

  Upon receiving the job information, user information, and product ID notification, the job log manager 411 generates log information including the received information (S341). Subsequently, the log service 51 confirms the free capacity of the log storage area 60, and checks whether or not log information can be recorded (S342). If log information can be recorded (YES in S343), the job service 407 controls the execution of the requested job (S344). Further, the log service 51 records log information in the log storage area 60 (S345). The log information includes job information, user information, and product ID. Therefore, information indicating “who (user information) what was used (product ID) and what was done (job information)” is recorded as a job log.

  If job information generation has failed (NO in S312), user information acquisition has failed (NO in S322), product ID acquisition has failed (NO in S332), or log information has been recorded. If it is not possible (NO in S343), job execution and log information recording are not executed.

  Next, the processing procedure whose outline has been described with reference to FIG. 7 will be described in more detail. FIG. 8 is a sequence diagram for explaining the processing procedure of the device in the second embodiment.

  In step S <b> 401, the SDK application 30 outputs an execution request for a job (such as printing, scanning, copying, or FAX transmission) instructed to be executed by the user via the operation panel 206 to the job control module 409. The execution request includes a parameter related to a job execution condition (job condition). Subsequently, the job control module 409 requests the job service 407 to execute the job by setting the job condition parameter in the job service 407 (S402).

  Subsequently, the job service 407 notifies the authentication manager 410 and the application manager 408 that the job execution is started (job execution notification) (S403, S405). Further, the job service 407 generates job information including job conditions, and notifies the job log manager 411 of the job information (S408).

  Upon receiving the job execution notification (S403), the authentication manager 410 acquires user information (user name, etc.) of the current login user from the RAM 212, and notifies the job log manager 411 (S404).

  The application manager 408 that has received the job execution notification (S405) acquires the product ID of the JSDK application 30 that is the job request source based on the thread attribute information related to the job execution notification (S406). In this embodiment, a thread group is used as thread attribute information. A thread group (ThreadGroup) is a Java (registered trademark) standard mechanism, and is a set of threads and thread groups. One or more threads can be associated with a thread group. A name (thread group name) can be added to the thread group. In each thread, the thread group to which the thread belongs can be identified.

  In the present embodiment, a thread and a thread group are generated for each SDK application 30. That is, one thread group is assigned to one SDK application 30, and the identification name (application name) of the SDK application 30 is set as the thread group name of the thread group. In this embodiment, the job control module 409, the job service 407, and the application manager 408 are not programs that operate as independent processes or threads, but program modules (functions or functions) that operate on the same thread as the SDK application 30. Class set). Therefore, the application manager 408 acquires the application name of the SDK application 30 that is the job request source based on the thread group name of the thread group to which its own thread belongs. Also, the application manager 408 acquires the product ID of the SDK application 30 that is the job request source, based on the acquired application name and the correspondence information between the application name generated when the SDK application 30 is installed and the product ID. . The application manager 408 notifies the job log manager 411 of the acquired product ID as identification information of the SDK application 30 that is the job request source (S407).

  Upon receiving the job information, user information, and product ID notification, the job log manager 411 generates log information including the received information (S409). Subsequently, the job log manager 411 requests the log service 51 to record the generated log information via the SDK common processing module 401 (S410, S411). Subsequently, the log service 51 confirms the free capacity of the log storage area 60 and the like, and determines whether log information can be recorded (written) (S412). When the log storage area 60 has sufficient free space, the log service 51 records log information in the log storage area 60 (S413). At this time, the log service 51 records time information, log ID, and the like in addition to job information, user information, product ID, and the like.

  Subsequently, the log service 51 responds to the SDK common processing module 401 that the log information has been successfully recorded (S414). The SDK common processing module 401 notifies the job service 407 that the job can be executed because the log information has been successfully recorded (S415). Upon receiving the notification, the job service 407 controls the execution of the job requested by the SDK application 30 (S416). Subsequently, the job service 407 returns information indicating the execution state (execution result) of the job to the SDK application 30 via the job control module 409 (S417, S418).

  In step S412, if the log service 51 determines that writing of log information is impossible or inappropriate, the log information recorded in the log recording area 60 is collected as in the first embodiment. The log information transferred to the server 10 may be deleted from the log recording area 60. Also, the timing for transferring the log information may be selectable as in the first embodiment.

  As described above, according to the device 20 of the second embodiment, log information can be forcibly recorded even when there is no explicit log information recording request from the SDK application 30 regarding job execution. . Therefore, it is possible to prevent a log record from being missed and to improve the possibility of detecting the presence of an unauthorized SDK application 30. Further, when log information cannot be recorded, the job is not executed, so that it is possible to prevent a situation in which the illegal process is executed without leaving a trace of the illegal process.

  In the first embodiment, the log-in user at the time of encrypted communication processing, the identification name of the SDK application 30 requesting the encrypted communication processing, and the like are also logged by the same mechanism as in the second embodiment. Information may be included and recorded.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

10 log collection server 15 network 20 device 30 SDK application 40 SDK platform 51 log service 52 socket library 60 log storage area 201 controller 202 scanner 203 printer 204 modem 205 network interface 206 operation panel 211 CPU
212 RAM
213 ROM
214 HDD
401 SDK common processing module 402 JVM
403 JSSE
404 Communication service 405 Communication log service 406 Security manager 407 Job service 408 Application manager 409 Job control module 410 Authentication manager 411 Job log manager

JP 2005-269619 A

Claims (6)

A device capable of executing an application program,
In response to a process execution request from the application program, history information recording means for recording history information regarding the process including identification information related to the execution request in a storage device;
Processing execution means for executing processing based on the execution request when the history information can be recorded in the storage device;
A device characterized by comprising:   The device according to claim 1, wherein the history information recording means includes user identification information related to the execution request in the history information.   The device according to claim 1, wherein the history information recording unit includes identification information of an application program related to the execution request in the history information.   The device according to claim 1, wherein the history information recording unit includes a parameter of the process in the history information. A history information recording method executed by a device capable of executing an application program,
In response to a process execution request from the application program, a history information recording procedure for recording history information regarding the process including identification information related to the execution request in a storage device;
A process execution procedure for executing a process based on the execution request when the history information can be recorded in the storage device;
A history information recording method comprising: To a device that can execute application programs,
In response to a process execution request from the application program, a history information recording procedure for recording history information regarding the process including identification information related to the execution request in a storage device;
A process execution procedure for executing a process based on the execution request when the history information can be recorded in the storage device;
A program for running

Images