JP2007133667A - Device setting control system and device setting control method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To control the setting of validity/invalidity for the use of a device connected to a client in accordance with the state of the client. <P>SOLUTION: The state of a device driver 27 for the device 28 connected to the client 20 is notified from the client 20 to a management server 10. In the management server 10, a policy indicating validity/invalidity for the use of the device 28 is set on the basis of the state of the device driver 27 which is notified from the client 20 and the policy is provided to the client 20 to control the validity/invalidity for the use of the device 28 connected to the client 20. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a device setting control system and a device setting control method for controlling settings for enabling / disabling use of a device connected to a client.

  Recently, in order to share information within a company, an infrastructure called an intranet has been constructed in many companies. Generally, in a document management device provided in a server, a user ID given to each employee Documents are managed by performing access authentication processing using passwords and the like. In this case, confidential information of each company, such as customer information and employee personnel information, is included in the content to be managed. Since it is also available, information leakage due to taking it outside is a problem.

  In recent years, means for preventing external take-out from various approaches to external take-out by these authorized users have been proposed. For example, Patent Document 1 discloses a technique for preventing information leakage by providing a routine for monitoring all APIs (Application Programming Interfaces) necessary for accessing resources. In this API monitoring method, for example, it is necessary to correspond to a hardware-dependent device driver such as a Bluetooth device or an IrDA device. In other words, it is necessary to cover APIs necessary for using a device that may be leaked in order to carry it out to the outside. Although it is possible to monitor the API that controls the driver, it is difficult to control a newly added device because the data needs to be analyzed.

  Further, Patent Document 2 monitors hardware configuration changes by device check, monitors changes in operating environment settings, and incorporates a corresponding device driver when the change content is an addition of a device. A technique is disclosed in which when a change is a failure or removal of an apparatus, the corresponding device driver is invalidated.

Patent Document 3 discloses a technique for setting the validity / invalidation of a peripheral device based on access policy information provided from a server.
JP 2002-288030 A JP 7-64772 A JP 2003-263416 A

  However, in the conventional confidential information take-out prevention system, it has not been possible to perform detailed use restrictions such as control on a device-by-device basis. For example, when printing is controlled, since printing to all printers is controlled, it is impossible to permit only a specific printer. In order to achieve this, it is possible to restrict the installation of device drivers on a client computer basis, but this is not only a problem that takes time and effort, but it also allows or prohibits the use of devices dynamically on a device-by-device basis. Control was difficult. There is also a problem that operation management is complicated.

  Further, even when the techniques described in Patent Documents 2 and 3 described above are combined, for example, a device once validated cannot be invalidated due to a problem such as a vulnerability of a device driver. There is a problem that detailed usage restrictions cannot be performed on the server side.

  The present invention has been made in view of the problems of the conventional technology as described above, and controls the setting for enabling / disabling use of a device connected to a client according to the state of the client. It is an object of the present invention to provide a device setting control system and a device setting control method that can be performed.

In order to achieve the above object, the present invention provides:
A client connected to the device, and a management server for setting a policy indicating enabling / disabling use of the device, and the policy set in the management server is given to the client; In a device setting control system in which enabling / disabling of use of the device is controlled based on the policy by the client,
The client has device management means for notifying the management server of a state of a device driver of a device connected to the client,
The management server includes policy setting means for setting a policy indicating activation / invalidation of device use based on a state of a device driver notified from the client.

  In addition, the device management unit is configured to validate the device drivers of all devices connected to the client when it is designated to cancel the policy.

  In addition, the client includes a change detection unit that controls activation / invalidation of the device based on the policy when the device driver environment setting state of the device connected to the client is changed. Features.

  In the present invention configured as described above, the state of the device driver of the device connected to the client is notified from the client to the management server, and the management server determines the device driver based on the state of the device driver notified from the client. A policy indicating enabling / disabling of usage is set, and this policy is given to the client to control the enabling / disabling of the use of the device connected to the client.

  In this way, in the present invention, since the device driver information of the client can be collectively managed remotely on the management server side, management of taking out confidential information can be facilitated. In addition, since management on the management server is possible on a device driver basis, even if the device driver is once valid, if the driver is updated for reasons such as vulnerability, the vulnerability will be detected from the remote management server. It is possible to disable the use of older drivers with

  Since the present invention is configured as described above, the setting for enabling / disabling use of a device connected to the client can be controlled on the management server side according to the state of the client. Thus, for example, even if a device driver has been validated once, an old driver that is vulnerable in terms of security can be invalidated if the driver is updated.

  Embodiments of the present invention will be described below with reference to the drawings.

  FIG. 1 is a diagram showing an embodiment of a device setting control system of the present invention.

  As shown in FIG. 1, the present embodiment is configured by connecting a management server 10 and a client 20 via a network 30 such as the Internet or an intranet.

  The management server 10 includes an interface unit 11, a communication unit 12, driver information 13, a policy setting unit 14, and a setting GUI unit 15.

  The interface unit 11 is a device that communicates with the client 20, and is, for example, hardware for using Ethernet (registered trademark) standardized by IEEE 802.3. When a policy acquisition request is received from the client 20, the driver information 13 is read out via the communication unit 12 and transmitted to the client 20.

  The communication unit 12 manages communication with the client 20. For example, a data encryption function using SSL (Secure Socket Layer) is added to HTTP (HyperText Transfer Protocol) which is a protocol used for transmitting and receiving data. A protocol HTTPS (Hypertext Transfer Protocol Security) or the like to which is added is used.

  The driver information 13 is a storage device that stores permission / prohibition information such as a device driver as a policy in units of users or groups. For example, a hard disk or the like for storing information such as device type, target driver name, driver file hash value, permission / prohibition for each user or group.

  The policy setting unit 14 saves the policy input via the management GUI unit 15 in the driver information 13, and reads or changes the driver information 13.

  The management GUI unit 15 is for providing a user interface using graphics and inputting a policy in order to display driver information to the system administrator.

  The client 20 includes an interface unit 21, a communication unit 22, a device management unit 23, control target driver information 24, a change detection unit 25, a device change unit 26, a device driver 27, and a device 28. ing.

  The interface unit 21 is a device that communicates with the management server 10 and is the same device as the interface unit 11.

  The communication unit 22 downloads a policy including driver control information from the management server 10 via the interface 21 using a method capable of communicating with the communication function 12 of the management server 10.

  The device management unit 23 has a function of acquiring device driver information set in the client 20 and a function of collating the policy given from the management server 10. Information is acquired from the device driver 27 and checked against the policy given from the management server 10. If the driver is stored in the control target driver information 24 as a control target, the driver is instructed to change the state of the device driver to the device change unit 26 according to the policy, and the driver is not stored in the control target driver information 24 as the control target. If so, the device driver information is stored in the control target driver information 24.

  The device changing unit 26 enables (installs) or disables (uninstalls) the device driver 27 in accordance with an instruction from the device management unit 23 to change the environment of the client machine. Thereby, the use of the device 28 is restricted from various applications.

  The change detection unit 25 detects a change in the environment setting state of the device driver 27. When a change in state is detected on the client 20 such as when a device driver is newly installed or the device driver 27 that has been invalidated by the policy is validated, the corresponding device is detected from the control target driver information 24. The driver information related to the device driver 27 is read out, and the device change function 26 is instructed to change the device driver 27 so as to be in a state that should be originally set. This changes the environment of the client machine.

  The control target driver information 24 is a storage device that stores information before control before the device driver 27 is controlled, and includes a disk and a memory. Also included is driver type information to be controlled when policy information cannot be acquired.

  The device driver 27 is software for operating a device 28 such as a printer or a peripheral device that can take confidential information out of the client 20. There are cases where it is provided by an operating system or by a manufacturer for controlling peripheral devices.

  The device 28 is a peripheral device connected to the client 20.

  Below, the device setting control method in the device setting control system comprised as mentioned above is demonstrated.

  FIG. 2 is a flowchart for explaining a device setting control method in the device setting control system shown in FIG.

  First, when a policy download is requested from the client 20, the management server 10 reads a policy including driver control information from the driver information 13, and this policy is transmitted to the network 30 via the communication unit 12 and the interface unit 11. And is received by the device management unit 23 via the interface unit 21 and the communication unit 22 of the client 20. As a result, the policy is downloaded from the management server 10 to the client (step S1).

  Then, the downloaded policy is analyzed in the device management unit 23.

  FIG. 3 is a diagram illustrating an example of a policy downloaded from the management server 10 illustrated in FIG. 1 to the client 20.

  As shown in FIG. 3, the policy in this example includes a policy that sets a driver type, a driver name, a hash value of a driver file, and permission (validation) / prohibition (invalidation).

  In the device management unit 23, when the policy is successfully downloaded from the management server 10, the policy is stored in the disk of the control target driver information 24, and the driver information validated by the policy is the control target driver. Information 24 is recorded in the memory (step S2).

  If the policy download from the management server 10 fails, all the control target drivers stored as defaults in the disk of the control target driver information 24 in the device management unit 23 are targeted. The control target driver is recorded as being valid in the memory of the control target driver information 24 (step S3). Here, the disk of the control target driver information 24 holds a default state so that only a predetermined device becomes a control target when no policy can be acquired.

  Next, in the device management unit 23, information and states of device drivers installed in the client 20 are acquired one by one from the device driver 27 via the operating system (step S4).

  When the driver information is acquired in the device management unit 23 (step S5), the acquired driver information is checked against the policy acquired from the management server 10 (step S6), and the two match. The following driver information is acquired.

  On the other hand, if the acquired driver information does not match the policy acquired from the management server 10, the acquired driver information is stored in the memory and disk of the control target driver information 24 (step S7). That is, the driver based on the acquired driver information is validated and stored in the control target driver information 24.

  In the device management unit 23, when the control target driver information 24 is referred to and the acquired driver information is that of the control target driver whose state is to be validated (step S8), the device based on the driver information An instruction to validate the driver 27 is issued to the device changing unit 26 (step S9).

  On the other hand, if the acquired driver information is that of the control target driver whose state is to be invalidated (step S8), the device management unit 23 issues an instruction to invalidate the device driver 27 based on the driver information. It is sent to the changing unit 26 (step S10).

  If the device information is no longer acquired by the device management unit 23, the process ends.

  In this way, among the devices 28 connected to the client 28, the device driver 27 of the device 28 invalidated by the policy stored in the control driver information 24 is invalidated. The environment of the client 20 is changed such that the device driver 27 of the device 28 enabled by the stored policy and the device 28 not stored in the control driver information 24 is enabled. Usage will be restricted by various applications.

  Next, a policy cancellation procedure in the client 20 shown in FIG. 1 will be described.

  FIG. 4 is a flowchart for explaining a policy release procedure in the client 20 shown in FIG.

  When the client 20 inputs from the outside that the policy downloaded from the management server 10 and stored in the control target driver information 24 is to be canceled, the device management unit 23 first stores the control target driver information 24 in the control target driver information 24. Driver information is acquired (step S101).

  Next, in the device management unit 23, information and states of device drivers installed in the client 20 are acquired one by one from the device driver 27 via the operating system (step S102).

  In the device management unit 23, when the device driver information and status are acquired from the device driver 27 (step S103), an instruction to validate the device driver 27 based on the driver information is issued to the device change unit 26 (step S103). S104).

  On the other hand, if the device management unit 23 has not acquired the device driver information and status from the device driver 27, the process ends.

  Next, a procedure for preventing the client 20 from taking out when the device driver status is changed will be described.

  FIG. 5 is a flowchart for explaining a take-out prevention procedure when the state of the device driver in the client 20 shown in FIG. 1 is changed.

  In the change detection unit 25, a change in the state of the environment setting of each device driver 27 of the device 28 connected to the client 20 is monitored, and when a change in the state is detected (step S201), a driver to be controlled Driver information related to the corresponding device is read from the information 24 (step S202).

  When the change detection unit 25 reads driver information related to the corresponding device from the control target driver information 24 (step S203), the device driver whose state has been changed according to the policy based on the read driver information Is valid (step S204), an instruction to validate the device driver 27 based on the driver information is issued to the device changing unit 26 (step S205).

  On the other hand, if the device driver whose state has been changed is invalid, an instruction to invalidate the device driver 27 based on the driver information is issued to the device changing unit 26 (step S206).

  If the change detection unit 25 does not read driver information related to the corresponding device from the control target driver information 24, the process ends.

  As a result, the device driver whose state has been changed is controlled so as to be originally set, and the environment of the client machine is changed.

  Next, a procedure for notifying the management server 10 of device driver information in the client 20 will be described.

  FIG. 6 is a flowchart for explaining a procedure for notifying the management server 10 of device driver information in the client 20 shown in FIG.

  First, in the device management unit 23, information on device drivers installed in the client 20 is acquired one by one from the device driver 27 (step S301).

  When information from the device driver 27 is acquired (step S302), the acquired driver information is stored in the device management unit 23 (step S303).

  FIG. 7 is a diagram illustrating an example of information acquired and stored by the device management unit 23 illustrated in FIG.

  As shown in FIG. 7, in this example, the driver type such as printer, IrDA, and Bluetooth, the file name of the target driver, and the hash value of the driver file are acquired and stored by the device management unit 23. As hash values, there are various algorithms such as MD5 and SHA-1, but any of them may be used.

  The acquisition of information from the device driver 27 in the device management unit 23 is repeatedly performed until the driver information cannot be acquired. If the information is not acquired, the driver information stored in the device management unit 23 is stored in the communication unit 22 and The data are transmitted to the management server 10 at once via the interface unit 21 (step S304).

  Thereafter, in the management server 10, information transmitted from the client 20 is stored in the driver information 13 so as to be input to the management GUI unit 15.

  Next, a policy setting procedure in the management server 10 will be described.

  FIG. 8 is a flowchart for explaining a policy setting procedure in the management server 10.

  When the administrator activates the GUI of the management server 10 (step S401), the setting GUI unit 15 acquires the currently set information from the driver information 13 via the policy setting unit 14 and displays it on the GUI. (Step S402). Note that the GUI may be activated via, for example, a Web browser or a dedicated application. At this time, the most common method is to perform administrator authentication using an ID and a password. Further, since the driver information of the client 20 acquired by the procedure shown in FIG. 6 is stored in the driver information 13, this information is displayed.

  When the policy is set by the administrator (step S403), when the setting information is input to the setting GUI unit 15, the setting information is notified to the policy setting unit 14, and the information stored in the driver information 13 is updated. (Step S404).

  If an operation for ending the process is performed (step S405), the process in the setting GUI unit 15 ends (step S406). If the setting action is not an end action, the process returns to the state of step S402. .

  As a result, the management server 10 can set a policy corresponding to the state of the driver of the client 20 notified from the client 20. Thereafter, the policy is downloaded by the client 20, so that a policy corresponding to the state of the driver of the client 20 is given to the client 20.

(Other embodiments)
In the management server 10 shown in FIG. 1, by acquiring information of a plurality of clients 20, the management server 10 can manage the driver version of the clients 20.

  By using the procedure for notifying device driver information from the client 20 to the management server 10 as described above, the setting GUI unit 15 of the management server 10 can acquire driver information of a plurality of clients. Thus, by having a list of the latest driver hashes and previous version hashes, it is possible to check with the management server which version of the driver is installed in the client 20.

It is a figure which shows one Embodiment of the device setting control system of this invention. 4 is a flowchart for explaining a device setting control method in the device setting control system shown in FIG. 1. It is a figure which shows an example of the policy downloaded to the client from the management server shown in FIG. 3 is a flowchart for explaining a policy release procedure in the client shown in FIG. 1. FIG. 2 is a flowchart for explaining a procedure for preventing take-out when changing a state of a device driver in the client shown in FIG. 1. FIG. 6 is a flowchart for explaining a procedure for notifying a management server of device driver information in the client shown in FIG. 1. It is a figure which shows an example of the information acquired and preserve | saved in the device management part shown in FIG. It is a flowchart for demonstrating the policy setting procedure in a management server.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Management server 11, 21 Interface 12, 22 Communication part 13 Driver information 14 Policy setting part 15 Setting GUI part 20 Client 23 Device management part 24 Control object driver information 25 Change detection part 26 Device change part 27 Device driver 28 Device 30 Network

Claims (6)

A client connected to the device, and a management server for setting a policy indicating enabling / disabling use of the device, and the policy set in the management server is given to the client; In a device setting control system in which enabling / disabling of use of the device is controlled based on the policy by the client,
The client has device management means for notifying the management server of a state of a device driver of a device connected to the client,
The device management control system according to claim 1, wherein the management server includes policy setting means for setting a policy indicating validation / invalidation of device use based on the status of the device driver notified from the client. The device setting control system according to claim 1,
The device management control system, wherein the device management unit validates device drivers of all devices connected to the client when the policy is to cancel the policy. In the device setting control system according to claim 1 or 2,
The client includes a change detection unit that controls activation / invalidation of the device based on the policy when a state of a device driver environment setting of the device connected to the client is changed. Device setting control system. In a device setting control system comprising a client to which a device is connected and a management server for setting a policy indicating enabling / disabling of use of the device, the policy set by the management server Is a device setting control method for controlling enabling / disabling of use of the device based on the policy at the client,
The client notifies the management server of a device driver status of a device connected to the client;
A device setting control method in which the management server displays and outputs information for setting a policy indicating validation / invalidation of device use based on the status of a device driver notified from the client. In the device setting control method according to claim 4,
A device setting control method, wherein when the client is designated to cancel the policy, device drivers of all devices connected to the client are validated. In the device setting control method according to claim 4 or 5,
A device setting control method, wherein when the environment setting state of a device driver of a device connected to the client is changed, the client controls validation / invalidation of the device based on the policy .

Images