WO2012176922A1 - ポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法 - Google Patents

ポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法 Download PDF

Info

Publication number
WO2012176922A1
WO2012176922A1 PCT/JP2012/066304 JP2012066304W WO2012176922A1 WO 2012176922 A1 WO2012176922 A1 WO 2012176922A1 JP 2012066304 W JP2012066304 W JP 2012066304W WO 2012176922 A1 WO2012176922 A1 WO 2012176922A1
Authority
WO
WIPO (PCT)
Prior art keywords
policy
resource
resource identifier
software
identifier
Prior art date
Application number
PCT/JP2012/066304
Other languages
English (en)
French (fr)
Inventor
隆一 小川
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US13/819,641 priority Critical patent/US9183009B2/en
Priority to JP2013508708A priority patent/JP5273327B2/ja
Publication of WO2012176922A1 publication Critical patent/WO2012176922A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management

Definitions

  • the present invention relates to a technology for managing a software policy that is setting information for a resource.
  • Patent Document 1 A technique for managing a software policy that is setting information for a resource is known.
  • the technique described in Patent Document 1 distributes and applies an environment definition file to computers based on environment definition parameter value input by an operator. This environment definition file is collectively managed as a system setting file.
  • Patent Document 1 does not include means for responding to the configuration change. Therefore, in the system and method using the technology, even if the configuration of the computer to which the environment definition file is applied is changed, it is based on the previous system setting file managed by the system. Updates will be made. Then, in response to a change in the system configuration, the operator must update the system setting file based on the system setting file applied before the change in the configuration. For this reason, the update operation of the system setting file when the configuration is changed is a complicated operation. In particular, in an environment such as a cloud, increase / decrease of virtualized servers, increase / decrease of storage, physical movement (migration) of virtual servers, and accompanying change of resource access authority may frequently occur.
  • an environment such as a cloud
  • increase / decrease of virtualized servers increase / decrease of storage, physical movement (migration) of virtual servers, and accompanying change of resource access authority may frequently occur.
  • An object of the present invention is to provide a policy update device, a policy management system, a policy update method, and a policy management method that appropriately update a software policy in accordance with a change in the configuration of resources.
  • the first policy update device associates a software policy, which is resource setting information, with a resource identifier indicating the resource and an installation destination resource identifier indicating a resource in which the resource is installed.
  • the policy storage means for storing, the resource identifier is received, and the resource identifier is received from the resource management means for storing the resource identifier and the installation destination resource identifier indicating the resource in which the resource identified by the resource identifier is installed.
  • a search unit updates the read software policy, associates the updated software policy with the received resource identifier and the read installation destination resource identifier, and stores the policy storage unit.
  • policy updating means for storing the data.
  • the first policy management system associates a software policy, which is resource setting information, with a resource identifier indicating the resource and an installation destination resource identifier indicating a resource in which the resource is installed.
  • Policy storage means for storing, resource management means for storing a resource identifier and an installation destination resource identifier indicating a resource in which a resource identified by the resource identifier is installed, and a resource identifier received and received
  • An installation destination resource identifier associated with the received resource identifier is read from the resource management means, and the software associated with the received resource identifier and the read installation destination resource identifier is read out.
  • a policy search means for reading a policy, updating the read software policy, and associating the updated software policy with the received resource identifier and the read installation destination resource identifier, Policy updating means stored in the policy storage means.
  • a software policy which is resource setting information, is associated with a resource identifier indicating the resource and an installation destination resource identifier indicating a resource in which the resource is installed.
  • the policy storage means receiving the resource identifier, and received from the resource management means for storing the resource identifier and the installation destination resource identifier indicating the resource in which the resource identified by the resource identifier is installed in association with each other Reading an installation destination resource identifier associated with the received resource identifier, reading out the software policy associated with the received resource identifier and the read installation destination resource identifier, Updates the Desa see software policies, the updated software policies, in association with the destination resource identifier read the said received resource identifier, stored in the policy storage unit.
  • a software policy that is resource setting information is associated with a resource identifier indicating the resource and an installation destination resource identifier indicating a resource in which the resource is installed.
  • the resource storage unit stores the resource identifier in association with the resource identifier and the installation destination resource identifier indicating the resource in which the resource identified by the resource identifier is installed, receives the resource identifier, and receives the received resource identifier.
  • An installation destination resource identifier associated with the received resource identifier is read from the resource management means, and the software policy associated with the received resource identifier and the read installation destination resource identifier is read out.
  • the first policy update program recorded on the non-volatile medium is configured to store a software policy, which is resource setting information, a resource identifier indicating the resource, and a resource in which the resource is installed.
  • An example of the effect of the present invention is that the software policy can be updated appropriately in accordance with a change in the resource configuration.
  • FIG. 1 is a block diagram showing a configuration of a policy update apparatus according to the first embodiment.
  • FIG. 2 is a diagram illustrating an example of information stored in the policy storage unit.
  • FIG. 3 is a diagram illustrating an example of a software policy.
  • FIG. 4 is a block diagram illustrating another example of the configuration of the policy update apparatus according to the first embodiment.
  • FIG. 5 is a diagram illustrating a hardware configuration of the policy update device and its peripheral devices according to the first embodiment.
  • FIG. 6 is a flowchart showing an outline of the operation of the policy updating apparatus according to the first embodiment.
  • FIG. 7 is a diagram illustrating an example of information stored in the policy storage unit according to the second embodiment.
  • FIG. 8 is a diagram illustrating an example of information stored in the policy storage unit according to the third embodiment.
  • FIG. 9 is a flowchart showing an outline of the operation of the policy update apparatus according to the third embodiment.
  • FIG. 10 is a block diagram showing the configuration of the policy update apparatus according to the fourth embodiment.
  • FIG. 11 is a diagram illustrating an example of information stored in the policy storage unit.
  • FIG. 12 is a diagram illustrating an example of information output by the policy update unit.
  • FIG. 13 is a diagram illustrating an example of information output by the policy update unit.
  • FIG. 14 is a flowchart showing an outline of the operation of the policy update apparatus according to the fourth embodiment.
  • FIG. 15 is a block diagram illustrating a configuration of a policy management system according to the fifth embodiment.
  • FIG. 16 is a diagram illustrating an example of information stored in the policy storage unit.
  • FIG. 17 is a diagram illustrating an example of a cluster policy.
  • FIG. 18 is a diagram illustrating an example of a cluster policy output by the policy update unit.
  • FIG. 19 is a diagram illustrating an example of information stored in the resource management unit.
  • FIG. 20 is a flowchart showing an outline of the operation of the policy management system in the fifth embodiment.
  • FIG. 1 is a block diagram showing a configuration of a policy update apparatus 100 according to the first embodiment of this invention.
  • the policy update device 100 includes a policy storage unit 101, a policy search unit 102, and a policy update unit 103.
  • the policy update apparatus 100 is connected to, for example, a resource management unit that manages resources in a network system, and generates, sets, or updates a policy for controlling software settings included in the resources.
  • the network system may be a large-scale computing system, for example.
  • the resources are, for example, a virtual machine in the network system, application software operating on the virtual machine, an operating system, a database system, files referred to by the software, a database table, and the like.
  • software setting information included in the resource is called a software policy.
  • the software policy may be setting information including environment setting information essential for software operation, software administrator information, permission of access to resources (Allow), and denial (Deny).
  • a software policy may itself be managed as a file.
  • the other resource in which the resource is installed is, for example, an operating system in which application software is installed.
  • the policy update device 100 identifies the software policy associated with the resource identifier and the installation destination resource identifier. Then, the policy update device 100 updates the identified software policy. Then, the policy update apparatus 100 stores the updated software policy in association with the resource identifier and the installation destination resource identifier described above. That is, when at least a part of the configuration of the system changes, the policy update apparatus 100 according to the first embodiment identifies the resource identifier and the installation destination resource identifier of the resource in which the configuration change has occurred. By doing so, the policy update device 100 can identify the associated software policy.
  • the policy update device 100 identifies a set of a resource and an installation destination resource. By doing so, the policy update apparatus 100 can select the correct software policy even when the setting information (software policy) differs depending on the OS (Operating System) of the installation destination, even for the same application software, for example. Therefore, the policy update apparatus 100 according to the first embodiment can appropriately update the software policy in accordance with the change in the resource configuration.
  • each component provided in the policy update apparatus 100 according to the first embodiment will be described.
  • FIG. 2 is a diagram illustrating an example of information stored in the policy storage unit 101.
  • the policy storage unit 101 stores a software policy A1, a resource identifier A2, and an installation destination resource identifier A3 in association with each other.
  • a software policy is setting information for a resource. For example, ACL (Access Control List) for resources, environment information for resources, and the like can be mentioned.
  • FIG. 3 is a diagram illustrating an example of a software policy. The software policy shown in FIG. 3 includes the following information, for example.
  • the software policy A1 in FIG. 2 is, for example, a reference address or a file name for storing the software policy.
  • Resources are various resources for operating a computer.
  • the resource includes a VM (Virtual Machine), an OS (Operating System), middleware, a reference monitor, and the like.
  • the reference monitor is software that monitors access to a specific resource and performs access control.
  • the resource identifier is an identifier for identifying a resource.
  • the installation destination resource identifier is an identifier for identifying the resource in which the corresponding resource is installed.
  • the corresponding resource is a resource identified by a resource identifier corresponding to the installation destination resource identifier.
  • the policy search unit 102 may receive a resource identifier from an external device (not shown). Alternatively, the administrator of the policy update device 100 may input a resource identifier. This resource identifier is an identifier indicating the software whose software policy is to be changed.
  • FIG. 5 is a diagram showing a hardware configuration of the policy update device 100 and its peripheral devices in the first embodiment of the present invention.
  • the policy update device 100 includes a CPU 191 (Central Processing Unit), a network connection communication I / F 192 (communication interface 192), a memory 193, a hard disk for storing programs, and the like.
  • the policy update device 100 is connected to an input device 195 and an output device 196 via a bus 197.
  • the CPU 191 operates the operating system to control the entire policy update apparatus 100 according to the first embodiment of the present invention. Further, the CPU 191 reads programs and data from the recording medium 198 mounted on the drive device or the like to the memory 193, for example.
  • the CPU 191 executes various processes as the policy storage unit 101, the policy search unit 102, and the policy update unit 103 in the first embodiment according to the read programs and data.
  • the storage device 194 is, for example, an optical disk, a flexible disk, a magnetic optical disk, an external hard disk, or a semiconductor memory, and records a computer program so that it can be read by a computer.
  • the computer program may be downloaded from an external computer (not shown) connected to the communication network.
  • the policy storage unit 101 may be realized by the storage device 194.
  • the input device 195 is realized by, for example, a mouse, a keyboard, a built-in key button, and the like, and is used for an input operation.
  • the input device 195 is not limited to a mouse, a keyboard, and a built-in key button, but may be a touch panel, an accelerometer, a gyro sensor, a camera, or the like.
  • the output device 196 is realized by a display, for example, and is used for confirming the output. Note that the block diagram (FIG. 1) used in the description of the first embodiment shows functional unit blocks, not hardware unit configurations.
  • the means for realizing each unit included in the policy update apparatus 100 is not particularly limited.
  • the policy update device 100 may be realized by a single physically connected device, or by connecting two or more physically separated devices by wire or wirelessly, and realized by these multiple devices.
  • the CPU 191 may read a computer program recorded in the storage device 194 and operate as the policy storage unit 101, the policy search unit 102, and the policy update unit 103 according to the program.
  • a recording medium (or storage medium) in which the above-described program code is recorded may be supplied to the policy updating apparatus 100, and the policy updating apparatus 100 may read and execute the program code stored in the recording medium.
  • the present invention also includes a recording medium 198 that temporarily or non-temporarily stores software (information processing program) to be executed by the policy update apparatus 100 according to the first embodiment.
  • FIG. 6 is a flowchart showing an outline of the operation of the policy update apparatus 100 according to the first embodiment.
  • the policy search unit 102 receives a resource identifier from the resource management unit (step S101).
  • the policy search unit 102 reads the installation destination resource identifier associated with the resource identifier received in step S101 (step S102).
  • the policy search unit 102 reads a software policy associated with the resource identifier received in step S101 and the installation destination resource identifier read in step S102 from the policy storage unit 101 (step S103).
  • the policy update unit 103 updates the software policy read by the policy search unit 102 (step S104).
  • the policy update unit 103 stores the resource identifier, the installation destination resource identifier, and the software policy in association with each other in the policy storage unit 101 (step S105).
  • the resource identifier is the resource identifier received by the policy search unit 102 in step S101.
  • the installation destination resource identifier is the installation destination resource identifier read by the policy search unit 102 in step S102.
  • the software policy is a software policy updated by the policy update unit 103 in step S104.
  • the policy update apparatus 100 When the policy update apparatus 100 according to the first embodiment receives a resource identifier indicating a resource, the policy update apparatus 100 specifies the resource identifier and an installation destination resource identifier indicating a resource in which the resource is installed. Then, the policy update device 100 identifies the software policy associated with the resource identifier and the installation destination resource identifier. Then, the policy updating apparatus 100 updates the identified software policy, and stores the updated software policy in association with the resource identifier and the installation destination resource identifier described above. That is, even when the configuration of at least a part of the system changes, the policy update apparatus 100 according to the first embodiment appropriately sets the software policy associated with the resource identifier and the installation destination resource identifier according to the change. Can be specified.
  • the policy updating apparatus 100 can appropriately update the software policy in accordance with the change in the resource configuration.
  • the system configuration is changed by migration, scale out, or the like. Therefore, in such an environment, the system may not operate correctly even if the software policy is distributed collectively to each server constituting the system.
  • the system administrator needs to set a software policy by using a privileged account.
  • This setting operation is a setting that depends on the environment (hardware / network configuration in which the virtual server is arranged, administrator authority, etc.) corresponding to the OS or middleware.
  • the system administrator must manually modify a portion of the software policy.
  • the policy updating apparatus 100 reads a software policy corresponding to the changed resource configuration when updating the software policy. That is, when a virtual server is added and the middleware is initialized, the policy update apparatus 100 designates the resource identifier of the middleware to be initialized. In a cloud environment, when there is only one type of OS to which middleware is installed, the corresponding software policy is immediately identified.
  • the administrator may select a software policy corresponding to the OS of the middleware to be initialized.
  • the identification of software resources when the versions of the same software are different, the resource identifiers may be different. In this case, the inconvenience that the same setting is applied to different versions of software can be avoided.
  • the software policy of the OS is associated with a set of “OS identifier, installation destination virtual server (VM) identifier”.
  • VM virtual server
  • the policy updating apparatus 100 can update the software policy suitable for the installation destination environment. In this way, the system administrator can reduce the possibility of flaws in correction when individual settings are made according to different types of middleware or OSs.
  • the policy storage unit 101 may store a resource identifier, a software identifier that is an identifier for identifying corresponding software, and a software policy in association with each other.
  • FIG. 7 is a diagram illustrating an example of information stored in the policy storage unit 101 according to the second embodiment.
  • the policy storage unit 101 stores a software policy B1, a resource identifier B2, a software identifier B3, and an installation destination resource identifier B4 in association with each other.
  • the policy search unit 102 may operate as follows. That is, the policy search unit 102 may perform the following processing instead of the processing in steps S101 and S103 of the operation of the policy update apparatus 100 in the first embodiment.
  • the policy search unit 102 receives a resource identifier and a software identifier from the resource management unit (step S101-2).
  • the policy search unit 102 reads an installation destination resource identifier associated with the received resource identifier (step S102).
  • the policy search unit 102 reads out the software policy associated with the received resource identifier, software identifier, and read installation destination resource identifier from the policy storage unit 101 (step S103-2).
  • the policy update apparatus 100 stores a software policy for each software applied to a resource. Therefore, even if the software applied to the resource changes, the policy update device 100 can specify the software policy corresponding to the change and update the specified software policy. That is, the policy update apparatus 100 according to the second embodiment can appropriately update the software policy in accordance with a change in software applied to the resource.
  • the policy updating apparatus 100 may receive a software identifier from the resource management unit instead of receiving the software identifier.
  • the resource management unit stores a resource identifier, a software identifier, and an installation destination resource identifier in association with each other.
  • the software identifier is a software identifier indicating software applied to the resource identified by the resource identifier.
  • the installation destination resource identifier is an installation destination resource identifier indicating a resource in which the resource identified by the resource identifier is installed.
  • the policy search unit 102 may operate as follows. That is, the policy search unit 102 may perform the following processing instead of the processing in step S102 and step S103 of the operation of the policy update apparatus 100 in the first embodiment.
  • the policy search unit 102 receives a resource identifier from the resource management unit (step S101). Then, the policy search unit 102 reads the software identifier and the installation destination resource identifier associated with the received resource identifier (step S102-2). Next, the policy search unit 102 reads out the software policy associated with the received resource identifier, the read software identifier, and the installation destination resource identifier from the policy storage unit 101 (step S103-3).
  • the policy update device 100 has the same effects as the policy update device 100 according to the second embodiment.
  • the policy storage unit 101 may store a software policy as a default policy in association with a software identifier.
  • FIG. 8 is a diagram illustrating an example of information stored in the policy storage unit 101 according to the third embodiment. Referring to FIG. 8, the policy storage unit 101 stores a software policy C1 and a software identifier C2 in association with each other.
  • FIG. 9 is a flowchart showing an outline of the operation of the policy update apparatus 100 according to the third embodiment.
  • the policy search unit 102 receives a resource identifier and a software identifier from the resource management unit (step S101-2).
  • the policy search unit 102 reads the installation destination resource identifier associated with the resource identifier received in step S101-2 (step S102).
  • the policy search unit 102 determines whether or not a software policy associated with the resource identifier and the installation destination resource identifier is stored in the policy storage unit 101 (step S301).
  • the resource identifier is the resource identifier received in step S101-2.
  • the installation destination resource identifier is the installation destination resource identifier read in step S102.
  • the policy search unit 102 reads out the corresponding software policy from the policy storage unit 101 (step S103-2).
  • the corresponding software policy is a software policy associated with the resource identifier and software identifier received in step S101 and the installation destination resource identifier read in step S102. Then, the operation of the policy update device 100 proceeds to step S104.
  • the policy search unit 102 reads the default policy (step S302).
  • the default policy is the default policy associated with the software identifier received in step S101-2. Then, the operation of the policy update device 100 proceeds to step S104.
  • the policy update unit 103 updates the software policy read by the policy search unit 102 (step S104).
  • the policy update unit 103 stores the resource identifier, the installation destination resource identifier, and the software policy in association with each other in the policy storage unit 101 (step S105).
  • the resource identifier is the resource identifier received by the policy search unit 102 in step S101-2.
  • the installation destination resource identifier is the installation destination resource identifier read by the policy search unit 102 in step S102.
  • the software policy is a software policy updated by the policy update unit 103 in step S104.
  • the policy update apparatus 100 reads the default (uncustomized) software policy even when the previous software policy no longer matches the current resource configuration.
  • FIG. 10 is a block diagram illustrating a configuration of the policy update device 400 according to the fourth embodiment.
  • the policy update device 400 includes a policy storage unit 401, a policy search unit 402, a policy update unit 403, and a verification unit 404.
  • FIG. 11 is a diagram illustrating an example of information stored in the policy storage unit 401.
  • the policy storage unit 401 stores a software policy D1, a resource identifier D2, an installation destination resource identifier D3, and a software policy update history D4 in association with each other.
  • the policy search unit 402 passes the update history associated with the software policy read from the policy storage unit 401 to a policy update unit 403 and a verification unit 404 described later.
  • the policy update unit 403 outputs the software policy read by the policy search unit 402 and the update history received from the policy search unit 402 in association with each other.
  • 12 and 13 are diagrams illustrating examples of information output by the policy update unit 403.
  • the policy update unit 403 may output information (difference) on a portion where the software policy indicated by the update history has been changed. For example, when the update history includes information indicating that the user name has been changed to “aaa @ localhost” and the path name has been changed to “/ home / * / public_html”, as shown in FIG. The name and information indicating that the path name has been changed may be output. As shown in FIG.
  • the policy update unit 403 displays the appearance frequency (for example, “user name (updated twice)”, “path name (updated four times)) of the changed part indicated in the update history.
  • the policy update unit 403 may output not only the latest update results but also past update histories. As illustrated in FIG. 13, the policy update unit 403 may output the software policy read by the policy search unit 402 and the update history together. Referring to FIG. 13, the portion indicated by the underlined portion is information (difference) of the portion where the software policy is changed, which is indicated by the update history.
  • the policy update unit 403 receives input of information indicating software policy update processing based on the output information. Then, the policy update unit 403 passes the software policy updated based on the information indicating the update process to the verification unit 404 described later.
  • the verification unit 404 may verify whether or not the software policy is correct based on whether or not the past user name indicated by the update history matches the user name included in the received software policy.
  • the verification unit 404 queries the user's authority to a server or the like that manages the user's authority. May be.
  • the authority of the user is the authority of the user identified by the user name included in the software policy.
  • the verification unit 404 may verify whether the software policy is correct based on the authority of the user. For example, when the user has a management role, it may be verified that the software policy is correct.
  • the verification unit 404 stores the software policy verified as correct, the update history to which the newly updated difference information is added, the resource identifier, and the installation destination resource identifier in association with each other in the policy storage unit 401.
  • This resource identifier is a resource identifier received by the policy search unit 402.
  • the installation destination resource identifier is an installation destination resource identifier read by the policy search unit 402 from the resource management unit.
  • FIG. 14 is a flowchart illustrating an outline of the operation of the policy update apparatus 400 according to the fourth embodiment.
  • the policy search unit 402 receives a resource identifier from the resource management unit (step S101). Next, the policy search unit 402 reads the installation destination resource identifier associated with the resource identifier received in step S101 (step S102).
  • the policy search unit 402 reads out the software policy and the update history associated with the resource identifier and the installation destination resource identifier from the policy storage unit 401 (step S401).
  • the resource identifier is the resource identifier received in step S101.
  • the installation destination resource identifier is the installation destination resource identifier read in step S102.
  • the policy search unit 402 passes the read update history to the policy update unit 403 and the verification unit 404.
  • the policy update unit 403 outputs information based on the software policy read by the policy search unit 402 and the update history (step S402).
  • the policy update unit 403 updates the software policy based on the information indicating the update process of the software policy input based on the output information (step S403).
  • the policy update unit 403 passes the updated software policy and the newly updated location information (difference information) to the verification unit 404.
  • the verification unit 404 verifies whether or not the software policy is correct based on the degree of coincidence between the software policy received from the policy update unit 403 and the update history received from the policy search unit 402 (step S404).
  • the verification unit 404 stores the software policy verified as correct, the update history to which the information of the newly updated part is added, the resource identifier, and the installation destination resource identifier in association with each other (step S405).
  • the resource identifier is the resource identifier received by the policy search unit 402 in step S101.
  • the installation destination resource identifier is the installation destination resource identifier read by the policy search unit 402 in step S102.
  • the policy update device 400 according to the fourth embodiment stores the software policy verified by the verification unit 404 as correct. Therefore, when updating the software policy, the correct software policy corresponding to the changed resource configuration is read out. The system administrator performs an update operation based on the software policy. Therefore, it is possible to reduce the possibility of flaws in correction when the system administrator individually sets different types of middleware or OSs. Therefore, the policy update device 400 according to the fourth embodiment can appropriately update the software policy in accordance with the change in the resource configuration.
  • the verification unit 404 may verify whether the software policy is correct based on the verification rule received from the policy search unit 402.
  • the policy search unit 402 passes the verification rule to the verification unit 404.
  • the verification rule is a verification rule specified based on at least one of the software policy read from the policy storage unit 401, the resource identifier associated with the software policy, or the installation destination resource identifier.
  • the validation rule may be a software policy syntax rule.
  • the verification rule may be a user name as an administrator who can be described in the software policy, or a path name that can be described in the software policy.
  • the verification rule may be information indicating a range of values set by the software policy. This information may be, for example, a resource amount (disk capacity, memory usage, etc.) necessary for software operation.
  • FIG. 15 is a block diagram showing the configuration of the policy management system 50 according to the fifth embodiment.
  • the policy management system 50 according to the fifth embodiment includes a policy update device 500, a resource management unit 511, and a policy distribution unit 512.
  • the policy management system 50 according to the fifth embodiment can collectively set software policies for resource groups in which virtual servers having the same software configuration are clustered by introducing the concept of cluster.
  • the policy update device 500 includes a policy storage unit 501, a policy search unit 502, a policy update unit 503, and a verification unit 504.
  • FIG. 16 is a diagram illustrating an example of information stored in the policy storage unit 501. Referring to FIG.
  • the policy storage unit 501 stores a cluster policy E1, a resource identifier E2, an installation destination resource identifier E3, a cluster group identifier E4, and an intra-cluster server identifier E5 in association with each other.
  • a cluster policy is setting information for computers belonging to a cluster. Since the virtual servers constituting the cluster share the same hardware / software configuration and change mode, the software setting information and update locations in the server are very similar. Therefore, the cluster policy includes environment information (common settings) common to the virtual servers in the cluster and environment information (individual settings) unique to each virtual server. For example, assuming a virtual server cluster including the same kind of operating system and the same kind of database, for example, a configuration of a cluster policy including information on the following items can be considered.
  • ⁇ Cluster policy> -Common settings (administrator user name, storage path name, etc.), for example “Aaa @ localhost / usr / local / xxx / conf” ⁇ Individual setting (IP (Internet Protocol) address etc.), for example, "192.168.10.10", "192.168.10.25", "192.168.10.100”
  • a list of software policy identifiers for the OS in the cluster eg "OSXX1config1, OSXX1config2”
  • a list of software policy identifiers for the DB in the cluster eg "DBXX1config1, DBxx1config2”
  • the software policy identifier is an identifier of a software policy corresponding to each OS or DB in the cluster.
  • the cluster policy includes a common setting E101, an individual setting E102, a software policy identifier list E103 of the intra-cluster OS, and a software policy identifier list E104 of the intra-cluster DB.
  • the cluster group identifier is an identifier for identifying a cluster.
  • the intra-cluster server identifier is an identifier for identifying each computer included in the cluster.
  • the policy update unit 503 updates the cluster policy read by the policy search unit 502. At this time, the policy update unit 503 outputs the cluster policy read by the policy search unit 502.
  • FIG. 18 is a diagram illustrating an example of a cluster policy output by the policy update unit 503. Referring to FIG.
  • the policy updating unit 503 outputs common settings (for example, “user name”, “path name”, etc.) and individual settings (for example, IP address, etc.). Based on the output information, the policy update unit 503 receives input of information indicating update processing of at least one of the software policy and the cluster policy. Then, the policy update unit 503 passes at least one of the software policy and the cluster policy updated based on the information indicating the update process to the verification unit 504 described later. For example, when the administrator name that is the common setting information is updated, the policy update unit 503 reflects this update on all the software policies in the related cluster. For example, when a plurality of virtual servers are added and batch setting is performed, the policy update unit 503 may operate as follows.
  • the policy update unit 503 adds individual setting information corresponding to the additional resource, and creates a new software policy that overwrites the individual setting information using the existing software policy as a model.
  • the policy update unit 503 adds the created software policy identifier (software policy identifier) to the cluster policy.
  • the verification unit 504 may verify the cluster policy by the same method as the software policy verification.
  • the resource management unit 511 stores a resource group identifier associated with a plurality of resource identifiers, the plurality of resource identifiers, and a software identifier in association with each other.
  • a resource group may be defined as a logical group for an arbitrary resource set. For example, a resource set mounted on a certain virtual server may be defined as a resource group, or a resource set configuring the same cluster may be defined as a resource group.
  • FIG. 19 is a diagram illustrating an example of information stored in the resource management unit 511. Referring to FIG. 19, the resource management unit 511 stores a resource group identifier F1 and a plurality of resource identifiers F2.
  • the resource management unit 511 stores a resource identifier associated with the resource group identifier F1 as member information F101. That is, “RID1, RID2, Mon1, Mon2” as member information F101 is stored in the resource management unit 511 in association with the resource group identifier F1.
  • RID1, RID2, Mon1, and Mon2 are resource identifiers F2 associated with the resource group identifier F1, respectively.
  • the resource management unit 511 stores a resource identifier F2 in association with a software identifier F201, a reference monitor identifier F202, and an installation destination resource identifier F203.
  • the software identifier F201 is information indicating the software applied to the resource indicated by the associated resource identifier (hereinafter referred to as “corresponding resource”).
  • the reference monitor identifier F202 indicates a reference monitor that monitors the corresponding resource.
  • the reference monitor is software that executes access control to resources to be monitored (VM, file, database table, etc.).
  • the installation destination resource identifier F203 is information indicating a resource in which the corresponding resource is installed.
  • FIG. 19 shows a relationship in which a database (RID2) and reference monitors (Mon1, Mon2) are installed in a resource RID1, which is an OS, and Mon1 performs access control of RID1 and Mon2 respectively.
  • the resource management unit 511 may store the software identifier F201, the monitoring destination resource identifier F204, and the installation destination resource identifier F203 in association with each other when the resource identifier F2 indicates a reference monitor.
  • the resource includes a reference monitor.
  • the resource management unit 511 may manage the cluster as a resource group.
  • the resource group identifier is the same as the cluster group identifier.
  • the policy search unit 502 may read a cluster policy corresponding to the cluster group identifier.
  • the policy distribution unit 512 distributes at least one of the above-described software policy and cluster policy to the identified resource.
  • the resource that has received the cluster policy has a function of overwriting and updating the software policy of the related software in the cluster based on the cluster policy information (that is, having a cluster manager function).
  • the distribution destination resource of the software policy may include a reference monitor that is access control software.
  • the policy storage unit 501 may store a resource identifier and an identifier (intra-cluster server identifier) indicating a computer including the resource indicated by the resource identifier in association with each other. In this case, the policy search unit 502 reads the cluster policy from the policy storage unit 501.
  • the cluster policy is a cluster policy associated with the installation destination resource identifier read from the resource management unit 511, the received resource identifier, and the intra-cluster server identifier associated with the resource identifier. is there.
  • FIG. 20 is a flowchart showing an outline of the operation of the policy management system 50 according to the fifth embodiment.
  • the policy search unit 502 receives a resource identifier from the resource management unit 511 (step S101). Next, the policy search unit 502 reads the installation destination resource identifier associated with the resource identifier received in step S101 (step S501).
  • the policy search unit 502 reads the cluster policy and the update history associated with the resource identifier received in step S101 and the installation destination resource identifier read in step S501 from the policy storage unit 501 (step S502). ). The policy search unit 502 passes the read update history to the policy update unit 503 and the verification unit 404. Next, the policy search unit 502 reads out the software policy and update history associated with the resource identifier and the installation destination resource identifier from the policy storage unit 501 (step S503).
  • the resource identifier is the resource identifier received in step S101.
  • the installation destination resource identifier is the installation destination resource identifier read in step S501.
  • the policy search unit 502 may read the software policy and its update history associated with the cluster policy read in step S502 from the policy storage unit 501. Specifically, the policy search unit 502 may read out the software policy indicated by the software policy identifier included in the cluster policy from the policy storage unit 501. Next, the policy update unit 503 outputs information based on the software policy read by the policy search unit 502 and the update history (step S402). Next, the policy update unit 503 outputs information based on the cluster policy read by the policy search unit 502 (step S504). Next, the policy update unit 503 updates at least one of the software policy and the cluster policy based on the information indicating the update process (step S403).
  • the information indicating the update process is at least one of software policy and cluster policy input based on the output information. That is, when the policy update unit 503 receives input of information indicating update processing for a software policy, the policy update unit 503 updates the software policy. When the policy update unit 503 receives input of information indicating an update process for the cluster policy, the policy update unit 503 updates the clusterware policy. When the policy update unit 503 receives information indicating update processing for each of the software policy and the cluster policy, the policy update unit 503 updates the software policy and the cluster policy. The policy update unit 503 passes at least one of the updated software policy and cluster policy to the verification unit 504.
  • the verification unit 504 verifies whether or not the software policy is correct based on the degree of matching between the software policy received from the policy update unit 503 and the update history received from the policy search unit 502 (step S404).
  • the verification unit 504 verifies whether or not the cluster policy is correct based on the cluster policy received from the policy update unit 503 and the verification rule received from the policy search unit 502 (step S505).
  • the verification unit 504 stores the software policy verified as correct, the resource identifier, and the installation destination resource identifier in association with each other (step S405).
  • the resource identifier is the resource identifier received by the policy search unit 502 in step S101.
  • the installation destination resource identifier is the installation destination resource identifier read by the policy search unit 502 in step S501.
  • the verification unit 504 stores the cluster policy verified as correct, the resource identifier, and the installation destination resource identifier in association with each other (step S506).
  • the resource identifier in step S506 is the resource identifier received by the policy search unit 502 in step S101.
  • the installation destination resource identifier is the installation destination resource identifier read by the policy search unit 502 in step S501.
  • the policy distribution unit 512 distributes at least one of the software policy and the cluster policy verified by the verification unit 504 to be correct to a predetermined resource (step S507).
  • the predetermined resource is specified as follows.
  • the policy distribution unit 512 specifies the resource identifier stored in the policy storage unit 501 in association with the above-described software policy or cluster policy.
  • the policy distribution unit 512 distributes at least one of the aforementioned software policy and cluster policy to the resource.
  • the delivery destination may be a reference monitor.
  • the policy management system 50 according to the fifth embodiment has the same effects as at least one of the policy update apparatuses according to the first to fourth embodiments.
  • the policy management system 50 according to the fifth embodiment can collectively set software policies for resource groups obtained by clustering virtual servers having the same software configuration by introducing the concept of cluster. That is, the policy management system 50 can easily change the settings of individual computers with respect to the increase / decrease of computers constituting the system that occur in a cloud environment.
  • the policy update device in each embodiment can appropriately update a software policy in accordance with a change in the configuration of resources.
  • the present invention has been described with reference to each embodiment and example, the present invention is not limited to the above embodiment. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.
  • each component in each embodiment of the present invention can be realized by a computer and a program as well as its function in hardware.
  • the program is provided by being recorded on a computer-readable recording medium such as a magnetic disk or a semiconductor memory, and is read by the computer when the computer is started up.
  • the read program causes the computer to function as a component in each of the embodiments described above by controlling the operation of the computer.
  • the policy update device and policy management system according to the present invention can be applied to an integrated management technology for system settings in a multi-vendor or multi-platform environment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本発明は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新できるポリシー更新装置を提供する。そのポリシー更新装置は、リソース識別子を受け取り、リソース識別子と、当該リソース識別子で識別されるリソースがインストールされている、リソースを示すインストール先リソース識別子と、を対応付けて記憶するリソース管理手段から、そのリソース識別子に対応するインストール先リソース識別子を読み出し、そのリソース識別子とそのインストール先リソース識別子とに対応するソフトウェアポリシーを読み出すポリシー検索手段と、そのソフトウェアポリシーを更新し、その更新したソフトウェアポリシーを、そのリソース識別子とそのインストール先リソース識別子とに対応付けて、ポリシー記憶手段に記憶するポリシー更新手段と、を備える。

Description

ポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法
　本発明は、リソースに対する設定情報であるソフトウェアポリシーを管理する技術に関する。
　リソースに対する設定情報であるソフトウェアポリシーを管理する技術が知られている。
　例えば、特許文献１に記載された技術は、操作者による環境定義パラメータ値入力をもとに計算機に対して環境定義ファイルを配布、適用する。この環境定義ファイルはシステム設定ファイルとして一括して管理される。
特開２００４−４６４４５号公報
　しかし、特許文献１に記載された技術は、構成変化に対応する手段を備えていない。したがって、その技術を用いたシステムや方法においては、環境定義ファイルが適用された計算機に対して、その構成が変化した場合であっても、システムによって管理される、以前のシステム設定ファイルに基づいて更新が行われてしまう。すると操作者は、システムの構成の変化に応じて、その構成の変化以前に適用されているシステム設定ファイルに基づいて、システム設定ファイルを更新しなければならない。このため、構成が変化した場合のシステム設定ファイルの更新作業は、煩雑な作業となる。特に、クラウドのような環境では、仮想化されたサーバの増減、ストレージの増減、仮想サーバの物理的移動（マイグレーション）、それに伴うリソースアクセス権限の変更などが頻繁に起こりうる。したがって、仮想サーバ上のソフトウェアに対し、構成の変化に応じた設定更新を行うことは、操作者にとって大きな負担となる。
　したがって特許文献１に記載された技術は、リソースの構成変化に応じて、システムの設定ファイル（ソフトウェアポリシー）を、適切に更新することができない。
　本発明の目的の一つは、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新するポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法を提供することにある。
　本発明の一形態における第一のポリシー更新装置は、リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けて記憶するポリシー記憶手段と、リソース識別子を受け取り、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けて記憶するリソース管理手段から、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出すポリシー検索手段と、前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶するポリシー更新手段と、を備える。
　本発明の一形態における第一のポリシー管理システムは、リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けて記憶するポリシー記憶手段と、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けて記憶するリソース管理手段と、リソース識別子を受け取り、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を前記リソース管理手段から読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出すポリシー検索手段と、前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶するポリシー更新手段と、を備える。
　本発明の一形態における第一のポリシー更新方法は、リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けてポリシー記憶手段に記憶し、リソース識別子を受け取り、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けて記憶するリソース管理手段から、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出し、前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶する。
　本発明の一形態における第一のポリシー管理方法は、リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けてポリシー記憶手段に記憶し、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けてリソース管理手段に記憶し、リソース識別子を受け取り、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を前記リソース管理手段から読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出し、前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶する。
　本発明の一形態における不揮発性媒体に記録された第一のポリシー更新プログラムは、コンピュータに、リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けてポリシー記憶手段に記憶する処理と、リソース識別子を受け取り、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けて記憶するリソース管理手段から、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出す処理と、前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶する処理とを実行させる。
　本発明の効果の一例は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新できることである。
図１は、第一の実施の形態におけるポリシー更新装置の構成を示すブロック図である。 図２は、ポリシー記憶部が記憶する情報の一例を示す図である。 図３は、ソフトウェアポリシーの一例を示す図である。 図４は、第一の実施の形態におけるポリシー更新装置の構成の他の例を示すブロック図である。 図５は、第一の実施の形態におけるポリシー更新装置とその周辺装置のハードウェア構成を示す図である。 図６は、第一の実施の形態におけるポリシー更新装置の動作の概要を示すフローチャートである。 図７は、第二の実施の形態におけるポリシー記憶部が記憶する情報の一例を示す図である。 図８は、第三の実施の形態におけるポリシー記憶部が記憶する情報の一例を示す図である。 図９は、第三の実施の形態におけるポリシー更新装置の動作の概要を示すフローチャートである。 図１０は、第四の実施の形態におけるポリシー更新装置の構成を示すブロック図である。 図１１は、ポリシー記憶部が記憶する情報の一例を示す図である。 図１２は、ポリシー更新部が出力する情報の一例を示す図である。 図１３は、ポリシー更新部が出力する情報の一例を示す図である。 図１４は、第四の実施の形態におけるポリシー更新装置の動作の概要を示すフローチャートである。 図１５は、第五の実施の形態におけるポリシー管理システムの構成を示すブロック図である。 図１６は、ポリシー記憶部が記憶する情報の一例を示す図である。 図１７は、クラスターポリシーの一例を示す図である。 図１８は、ポリシー更新部が出力するクラスターポリシーの一例を示す図である。 図１９は、リソース管理部が記憶する情報の一例を示す図である。 図２０は、第五の実施の形態におけるポリシー管理システムの動作の概要を示すフローチャートである。
　本発明を実施するための形態について図面を参照して詳細に説明する。なお、各図面および明細書記載の各実施の形態において、同様の機能を備える構成要素には同様の符号が与えられている。
　［第一の実施の形態］
　図１は、本発明の第一の実施の形態におけるポリシー更新装置１００の構成を示すブロック図である。図１を参照すると、ポリシー更新装置１００は、ポリシー記憶部１０１とポリシー検索部１０２とポリシー更新部１０３とを備える。
　ポリシー更新装置１００は、例えばネットワークシステムにおける資源（リソース）を管理するリソース管理部に接続され、リソースが備えるソフトウェアの設定を制御するためのポリシーを生成、設定または更新する。ネットワークシステムは、例えば大規模コンピューティングシステムであってもよい。
　後述するが、リソースは、例えばネットワークシステム内の仮想計算機、仮想計算機上で動作するアプリケーションソフトウェア、オペレーティングシステム、データベースシステム、それらのソフトウェアが参照するファイル、データベースのテーブルなどである。また、リソースが備えるソフトウェアの設定情報は、ソフトウェアポリシーと呼ばれる。
　例えば、ソフトウェアポリシーは、ソフトウェア動作に必須である環境設定情報、ソフトウェアの管理者情報、リソースに対するアクセスの許可（Ａｌｌｏｗ）、拒否（Ｄｅｎｙ）を含む設定情報であってもよい。ソフトウェアポリシーは、それ自体がファイルとして管理されてもよい。
　第一の実施の形態におけるポリシー更新装置１００は、リソースを示すリソース識別子を受け取ると、そのリソース識別子とそのリソースがインストールされている他のリソースを示すインストール先リソース識別子とを特定する。ここで、そのリソースがインストールされている他のリソースは、例えば、アプリケーションソフトウェアがインストールされているオペレーティングシステムである。
　そしてポリシー更新装置１００は、リソース識別子とインストール先リソース識別子とに対応付けられている、ソフトウェアポリシーを特定する。そしてポリシー更新装置１００は、特定したソフトウェアポリシーを更新する。そしてポリシー更新装置１００は、更新したソフトウェアポリシーを前述のリソース識別子とインストール先リソース識別子とに対応付けて記憶する。
　つまり、第一の実施の形態におけるポリシー更新装置１００は、システムの少なくとも一部の構成が変化した場合、構成変化が生じたリソースのリソース識別子、およびインストール先リソース識別子を特定する。そうすることにより、ポリシー更新装置１００は、対応付けられているソフトウェアポリシーを特定できる。
　ここで、ポリシー更新装置１００は、リソースとインストール先リソースの組を特定する。そうすることで、ポリシー更新装置１００は、例えば同じアプリケーションソフトウェアであっても、インストール先のＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）によって設定情報（ソフトウェアポリシー）が異なる、という場合にも正しいソフトウェアポリシーを選択できる。
　よって第一の実施の形態におけるポリシー更新装置１００は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新できる。
　以下、第一の実施の形態におけるポリシー更新装置１００が備える各構成要素について説明する。
　＝＝＝ポリシー記憶部１０１＝＝＝
　ポリシー記憶部１０１は、ソフトウェアポリシーとリソース識別子とインストール先リソース識別子とを対応付けて記憶する。図２は、ポリシー記憶部１０１が記憶する情報の一例を示す図である。図２を参照すると、ポリシー記憶部１０１は、ソフトウェアポリシーＡ１と、リソース識別子Ａ２と、インストール先リソース識別子Ａ３とを対応付けて記憶している。
　ソフトウェアポリシーとは、リソースに対する設定情報である。例えば、リソースに対するＡＣＬ（Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ　Ｌｉｓｔ：アクセス制御リスト）、リソースに対する環境情報、などが挙げられる。
　図３は、ソフトウェアポリシーの一例を示す図である。図３に示すソフトウェアポリシーは、例えば、以下のような情報を含む。
　「ｖｅｒｓｉｏｎ　３．０；
　ａｃｌ“ｄｅｆａｕｌｔ；
　Ａｕｔｈｅｎｔｉｃａｔｅ（ｕｓｅｒ，ｇｒｏｕｐ）｛ｐｒｏｍｐｔ＝“ＸＸＸ　Ｗｅｂ　Ｓｅｒｖｅｒ”；｝；
　Ａｌｌｏｗ（ｒｅａｄ，ｅｘｅｃｕｔｅ，ｉｎｆｏ）ｕｓｅｒ＝“ａｎｙｏｎｅ”；
　Ａｌｌｏｗ（ｌｉｓｔ，ｗｒｉｔｅ，ｄｅｌｅｔｅ）ｕｓｅｒ＝“ａｌｌ”；
　ａｃｌ“ｅｓ−ｉｎｔｅｒｎａｌ”；
　Ａｌｌｏｗ（ｒｅａｄ，ｅｘｅｃｕｔｅ，ｉｎｆｏ）ｕｓｅｒ＝“ａｎｙｏｎｅ”；
　Ｄｅｎｙ（ｌｉｓｔ，ｗｒｉｔｅ，ｄｅｌｅｔｅ）ｕｓｅｒ＝“ａｎｙｏｎｅ”；」
　なお、図２のソフトウェアポリシーＡ１は、例えばソフトウェアポリシーを格納する参照アドレス、あるいはファイル名である。
　リソースとは、計算機を動作させるための各種の資源である。例えばリソースとは、ＶＭ（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ：仮想計算機）、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ：オペレーティングシステム）、ミドルウェア、リファレンスモニターなどが挙げられる。リファレンスモニターとは、特定リソースへのアクセスを監視し、アクセス制御を実施するソフトウェアである。
　リソース識別子は、リソースを識別するための識別子である。またインストール先リソース識別子は、対応リソースがインストールされているリソースを、識別するための識別子である。その対応リソースは、そのインストール先リソース識別子に対応するリソース識別子で、識別されるリソースである。
　＝＝＝ポリシー検索部１０２＝＝＝
　ポリシー検索部１０２は、リソース識別子を受け取り、後述するリソース管理部からそのリソース識別子に対応付けられているインストール先リソース識別子を読み出す。そしてポリシー検索部１０２は、読み出したインストール先リソース識別子と受け取ったリソース識別子とに対応付けられているソフトウェアポリシーをポリシー記憶部１０１から読み出す。
　ポリシー検索部１０２は、リソース識別子を、図示しない外部装置から受け取ってもよい。または、当該ポリシー更新装置１００の管理者が、リソース識別子を入力してもよい。このリソース識別子は、ソフトウェアポリシーを変更するソフトウェアを示す識別子である。
　リソース管理部は、リソース識別子と、そのリソース識別子で識別されるリソースがインストールされている、リソースを示すインストール先リソース識別子と、を対応付けて記憶する。
　例えばリソース管理部は、図４に示されるようにポリシー更新装置１００に接続されてもよい。
　＝＝＝ポリシー更新部１０３＝＝＝
　ポリシー更新部１０３は、ポリシー検索部１０２が読み出したソフトウェアポリシーを更新する。そして、ポリシー更新部１０３は、このソフトウェアポリシーとリソース識別子とインストール先リソース識別子とを対応付けてポリシー記憶部１０１に記憶する。このリソース識別子は、ポリシー検索部１０２が受け取ったリソース識別子である。また、このインストール先リソース識別子は、ポリシー検索部１０２がリソース管理部から読み出したインストール先リソース識別子である。
　図５は、本発明の第一の実施の形態におけるポリシー更新装置１００とその周辺装置のハードウェア構成を示す図である。図５に示されるように、ポリシー更新装置１００は、ＣＰＵ１９１（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ：中央演算処理装置）、ネットワーク接続用の通信Ｉ／Ｆ１９２（通信インターフェース１９２）、メモリ１９３、およびプログラムを格納するハードディスク等の記憶装置１９４を含む。また、ポリシー更新装置１００は、バス１９７を介して入力装置１９５および出力装置１９６に接続されている。
　ＣＰＵ１９１は、オペレーティングシステムを動作させて本発明の第一の実施の形態に係るポリシー更新装置１００の全体を制御する。また、ＣＰＵ１９１は、例えばドライブ装置などに装着された記録媒体１９８からメモリ１９３にプログラムやデータを読み出す。そして、ＣＰＵ１９１は、それらの読み出したプログラムやデータにしたがって、第一の実施の形態におけるポリシー記憶部１０１、ポリシー検索部１０２およびポリシー更新部１０３として各種の処理を実行する。
　記憶装置１９４は、例えば光ディスク、フレキシブルディスク、磁気光ディスク、外付けハードディスク、または半導体メモリ等であって、コンピュータプログラムをコンピュータ読み取り可能に記録する。また、コンピュータプログラムは、通信網に接続されている図示しない外部コンピュータからダウンロードされてもよい。
　ポリシー記憶部１０１は、記憶装置１９４によって実現されてもよい。
　入力装置１９５は、例えばマウスやキーボード、内蔵のキーボタンなどで実現され、入力操作に用いられる。入力装置１９５は、マウスやキーボード、内蔵のキーボタンに限らず、例えばタッチパネル、加速度計、ジャイロセンサ、カメラなどでもよい。
　出力装置１９６は、例えばディスプレイで実現され、出力を確認するために用いられる。
　なお、第一の実施の形態の説明において利用されるブロック図（図１）には、ハードウェア単位の構成ではなく、機能単位のブロックが示されている。これらの機能ブロックは図５に示されるハードウェア構成によって実現される。ただし、ポリシー更新装置１００が備える各部の実現手段は特に限定されない。すなわち、ポリシー更新装置１００は、物理的に結合した一つの装置により実現されてもよいし、物理的に分離した二つ以上の装置を有線または無線で接続し、これら複数の装置により実現されてもよい。
　また、ＣＰＵ１９１は、記憶装置１９４に記録されているコンピュータプログラムを読み込み、そのプログラムにしたがって、ポリシー記憶部１０１、ポリシー検索部１０２およびポリシー更新部１０３として動作してもよい。
　また、前述のプログラムのコードを記録した記録媒体（または記憶媒体）が、ポリシー更新装置１００に供給され、ポリシー更新装置１００が記録媒体に格納されたプログラムのコードを読み出し実行してもよい。すなわち、本発明は、第一の実施の形態におけるポリシー更新装置１００が実行するためのソフトウェア（情報処理プログラム）を一時的に記憶するまたは非一時的に記憶する記録媒体１９８も含む。
　図６は、第一の実施の形態におけるポリシー更新装置１００の動作の概要を示すフローチャートである。
　ポリシー検索部１０２は、リソース管理部から、リソース識別子を受け取る（ステップＳ１０１）。
　次に、ポリシー検索部１０２は、ステップＳ１０１において受け取ったリソース識別子に対応付けられている、インストール先リソース識別子を読み出す（ステップＳ１０２）。
　次に、ポリシー検索部１０２は、ステップＳ１０１において受け取ったリソース識別子とステップＳ１０２において読み出したインストール先リソース識別子とに対応付けられている、ソフトウェアポリシーをポリシー記憶部１０１から読み出す（ステップＳ１０３）。
　次に、ポリシー更新部１０３は、ポリシー検索部１０２が読み出したソフトウェアポリシーを更新する（ステップＳ１０４）。
　次に、ポリシー更新部１０３は、リソース識別子とインストール先リソース識別子とソフトウェアポリシーとを対応付けてポリシー記憶部１０１に記憶する（ステップＳ１０５）。
　ステップＳ１０５において、リソース識別子は、ステップＳ１０１においてポリシー検索部１０２が受け取ったリソース識別子である。また、インストール先リソース識別子は、ステップＳ１０２においてポリシー検索部１０２が読み出したインストール先リソース識別子である。また、ソフトウェアポリシーは、ステップＳ１０４において、ポリシー更新部１０３が更新したソフトウェアポリシーである。
　第一の実施の形態におけるポリシー更新装置１００は、リソースを示すリソース識別子を受け取ると、そのリソース識別子と、そのリソースがインストールされているリソースを示す、インストール先リソース識別子と、を特定する。そしてポリシー更新装置１００は、そのリソース識別子とそのインストール先リソース識別子とに対応付けられているソフトウェアポリシーを特定する。そしてポリシー更新装置１００は、特定したソフトウェアポリシーを更新し、更新したソフトウェアポリシーを前述のリソース識別子とインストール先リソース識別子とに対応付けて記憶する。
　つまり、第一の実施の形態におけるポリシー更新装置１００は、システムの少なくとも一部の構成が変化する場合でも、その変化に応じたリソース識別子およびインストール先リソース識別子に対応付けられているソフトウェアポリシーを適切に特定することができる。したがって、第一の実施の形態におけるポリシー更新装置１００は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新することができる。
　クラウドコンピューティング（Ｃｌｏｕｄ　Ｃｏｍｐｕｔｉｎｇ）環境下において、マイグレーション（Ｍｉｇｒａｔｉｏｎ）やスケールアウト（Ｓｃａｌｅ　Ｏｕｔ）などによりシステムの構成が変更される。したがってこのような環境下において、システムを構成する各サーバなどにソフトウェアポリシーが一括配信されても、システムが正しく動作しない可能性がある。
　例えば、仮想サーバが増設された場合、その仮想サーバ内のＯＳやミドルウェアを動作させるために、システム管理者は特権アカウントを用いることによってソフトウェアポリシーを設定する必要がある。この設定作業は、ＯＳまたはミドルウェアに応じた環境（仮想サーバが配置されるハードウェア・ネットワーク構成や管理者権限など）に依存する設定である。したがってシステム管理者は、ソフトウェアポリシーの一部分について手作業によって修正しなければならない。
　クラウド環境において、システム管理者は異種のミドルウェアまたはＯＳに応じてそれぞれ個別の設定をする必要がある。しかしシステムが大規模である場合、その設定に掛かる作業負荷が増大し、手作業により生じる修正不備などによって正しい設定が行われない可能性が生じてしまう。
　第一の実施の形態におけるポリシー更新装置１００は、ソフトウェアポリシー更新の際、変更されたリソースの構成に応じたソフトウェアポリシーが読み出される。すなわち、仮想サーバが増設され、ミドルウェアの初期設定が行われる場合、ポリシー更新装置１００は、初期設定したいミドルウェアのリソース識別子を指定する。クラウド環境で、ミドルウェアがインストールされる先のＯＳの種類が一つである場合、対応するソフトウェアポリシーがただちに特定される。インストール先のＯＳの種類が複数ある場合、複数のソフトウェアポリシーが検索されるが、初期設定したいミドルウェアのＯＳに対応するソフトウェアポリシーを管理者が選択してもよい。
　なお、ソフトウェアリソースの識別については、同じソフトウェアでもバージョンが異なる場合、それぞれのリソース識別子は異なっていてもよい。この場合、バージョンの異なるソフトウェアに同じ設定が適用される、という不都合が避けられる。
　また、ＯＳの初期設定についても、「ＯＳの識別子、インストール先の仮想サーバ（ＶＭ）識別子」の組に、ＯＳのソフトウェアポリシーが対応付けられる。このことにより、ポリシー更新装置１００は、インストール先の環境に適した、ソフトウェアポリシーの更新をすることができる。
　システム管理者はこのように、異種のミドルウェアまたはＯＳに応じてそれぞれ個別の設定をする場合の修正不備の可能性を低減できる。
　さらに、仮想サーバ（ＶＭ）の設定についても、「仮想サーバの識別子、インストール先の物理サーバの識別子」の組と仮想サーバの設定ファイルとが対応付けられ、それらと仮想サーバのソフトウェアポリシーとが対応付けられていてもよい。尚、仮想サーバのソフトウェアポリシーは、例えば、ストレージやＩ／Ｏの環境設定、管理者のＤＯＭ０操作権等である。
　したがって第一の実施の形態におけるポリシー更新装置１００は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新することができる。
　［第二の実施の形態］
　第一の実施の形態において、ポリシー記憶部１０１は、リソース識別子と、対応ソフトウェアを識別するための識別子であるソフトウェア識別子と、ソフトウェアポリシーとを対応付けて記憶してもよい。ここで、その対応ソフトウェアは、そのリソース識別子で識別されるリソースに適用されているソフトウェアである。
　図７は、第二の実施の形態におけるポリシー記憶部１０１が記憶する情報の一例を示す図である。図７を参照すると、ポリシー記憶部１０１は、ソフトウェアポリシーＢ１と、リソース識別子Ｂ２と、ソフトウェア識別子Ｂ３と、インストール先リソース識別子Ｂ４と、を対応付けて記憶している。
　第二の実施の形態において、ポリシー検索部１０２は、以下のように動作してもよい。すなわちポリシー検索部１０２は、第一の実施の形態におけるポリシー更新装置１００の動作のステップＳ１０１およびステップＳ１０３の処理の代わりに以下の処理を行ってもよい。
　ポリシー検索部１０２は、リソース管理部から、リソース識別子とソフトウェア識別子とを受け取る（ステップＳ１０１−２）。
　次に、ポリシー検索部１０２は、受け取ったリソース識別子に対応付けられている、インストール先リソース識別子を読み出す（ステップＳ１０２）。
　次に、ポリシー検索部１０２は、受け取ったリソース識別子とソフトウェア識別子と読み出したインストール先リソース識別子とに対応付けられているソフトウェアポリシーを、ポリシー記憶部１０１から読み出す（ステップＳ１０３−２）。
　第二の実施の形態におけるポリシー更新装置１００は、リソースに適用されるソフトウェアごとにソフトウェアポリシーを記憶する。したがって、ポリシー更新装置１００は、リソースに適用されるソフトウェアが変化しても、その変化に応じたソフトウェアポリシーを特定し、特定されたソフトウェアポリシーを更新することができる。すなわち第二の実施の形態におけるポリシー更新装置１００は、リソースに適用されるソフトウェアの変化に応じて、ソフトウェアポリシーを適切に更新することができる。
　なお、第二の実施の形態において、同じソフトウェアでもバージョンが異なる場合、それぞれのソフトウェア識別子が異なる。したがってバージョンの異なるソフトウェアに対して同一のリソース識別子が対応付けられてもよい。
　［第二の実施の形態の第一の変形例］
　第二の実施の形態において、ポリシー更新装置１００は、ソフトウェア識別子を受け取る代わりに、リソース管理部からソフトウェア識別子を受け取ってもよい。この場合、リソース管理部は、リソース識別子とソフトウェア識別子と、インストール先リソース識別子とを対応付けて記憶している。なお、そのソフトウェア識別子は、そのリソース識別子で識別されるリソースに適用されているソフトウェアを示す、ソフトウェア識別子である。また、そのインストール先リソース識別子は、そのリソース識別子で識別されるリソースがインストールされているリソースを示す、インストール先リソース識別子である。
　第二の実施の形態の第一の変形例において、ポリシー検索部１０２は、以下のように動作してもよい。すなわちポリシー検索部１０２は、第一の実施の形態におけるポリシー更新装置１００の動作のステップＳ１０２およびステップＳ１０３の処理の代わりに以下の処理を行ってもよい。
　ポリシー検索部１０２は、リソース管理部から、リソース識別子を受け取る（ステップＳ１０１）。
　そしてポリシー検索部１０２は、受け取ったリソース識別子に対応付けられているソフトウェア識別子とインストール先リソース識別子とを読み出す（ステップＳ１０２−２）。
　次に、ポリシー検索部１０２は、受け取ったリソース識別子と読み出したソフトウェア識別子およびインストール先リソース識別子とに対応付けられているソフトウェアポリシーをポリシー記憶部１０１から読み出す（ステップＳ１０３−３）。
　第二の実施の形態の第一の変形例におけるポリシー更新装置１００は、第二の実施の形態におけるポリシー更新装置１００と同様の効果を奏する。
　［第三の実施の形態］
　第二の実施の形態において、ポリシー記憶部１０１は、デフォルトポリシーとしてソフトウェアポリシーをソフトウェア識別子と対応付けて記憶してもよい。
　図８は、第三の実施の形態におけるポリシー記憶部１０１が記憶する情報の一例を示す図である。図８を参照すると、ポリシー記憶部１０１は、ソフトウェアポリシーＣ１と、ソフトウェア識別子Ｃ２とを対応付けて記憶している。
　図９は、第三の実施の形態におけるポリシー更新装置１００の動作の概要を示すフローチャートである。
　ポリシー検索部１０２は、リソース管理部から、リソース識別子とソフトウェア識別子とを受け取る（ステップＳ１０１−２）。
　そしてポリシー検索部１０２は、ステップＳ１０１−２において受け取ったリソース識別子に対応付けられている、インストール先リソース識別子を読み出す（ステップＳ１０２）。
　ポリシー検索部１０２は、そのリソース識別子とそのインストール先リソース識別子とに対応付けられているソフトウェアポリシーが、ポリシー記憶部１０１に記憶されているか否か判定する（ステップＳ３０１）。なお、そのリソース識別子は、ステップＳ１０１−２において受け取ったリソース識別子である。また、そのインストール先リソース識別子は、ステップＳ１０２において読み出したインストール先リソース識別子である。
　該当するソフトウェアポリシーがポリシー記憶部１０１に記憶されている場合（ステップＳ３０１の“Ｙｅｓ”）、ポリシー検索部１０２は、その該当するソフトウェアポリシーをポリシー記憶部１０１から読み出す（ステップＳ１０３−２）。なお、その該当するソフトウェアポリシーは、ステップＳ１０１において受け取られたリソース識別子とソフトウェア識別子とステップＳ１０２において読み出されたインストール先リソース識別子とに対応付けられているソフトウェアポリシーである。そして、ポリシー更新装置１００の動作は、ステップＳ１０４に進む。
　一方、該当するソフトウェアポリシーがポリシー記憶部１０１に記憶されていない場合（ステップＳ３０１の“Ｎｏ”）、ポリシー検索部１０２は、デフォルトポリシーを読み出す（ステップＳ３０２）。なお、そのデフォルトポリシーは、ステップＳ１０１−２において受け取られたソフトウェア識別子に対応付けられているデフォルトポリシーである。そしてポリシー更新装置１００の動作は、ステップＳ１０４に進む。
　ポリシー更新部１０３は、ポリシー検索部１０２が読み出したソフトウェアポリシーを更新する（ステップＳ１０４）。
　次に、ポリシー更新部１０３は、リソース識別子とインストール先リソース識別子とソフトウェアポリシーとを対応付けてポリシー記憶部１０１に記憶する（ステップＳ１０５）。
　なお、ステップＳ１０５において、リソース識別子は、ステップＳ１０１−２においてポリシー検索部１０２が受け取ったリソース識別子である。また、インストール先リソース識別子は、ステップＳ１０２においてポリシー検索部１０２が読み出したインストール先リソース識別子である。また、ソフトウェアポリシーは、ステップＳ１０４において、ポリシー更新部１０３が更新したソフトウェアポリシーである。
　第三の実施の形態におけるポリシー更新装置１００は、以前のソフトウェアポリシーが現在のリソースの構成に適合しなくなった場合であっても、デフォルトの（カスタマイズがなされていない）ソフトウェアポリシーが読み出される。例えば、ＯＳのバージョンアップ、新しいミドルウェアのインストールなど、リソースの構成変化によって、以前のソフトウェアポリシーが現在のリソースの構成に適合しなくなる。したがって、第三の実施の形態におけるポリシー更新装置１００は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新することができる。
　［第四の実施の形態］
　図１０は、第四の実施の形態におけるポリシー更新装置４００の構成を示すブロック図である。図１０を参照すると、ポリシー更新装置４００は、ポリシー記憶部４０１とポリシー検索部４０２とポリシー更新部４０３と検証部４０４とを備える。
　＝＝＝ポリシー記憶部４０１＝＝＝
　ポリシー記憶部４０１は、ソフトウェアポリシーとリソース識別子とインストール先リソース識別子とそのソフトウェアポリシーの更新履歴とを対応付けて記憶する。図１１は、ポリシー記憶部４０１が記憶する情報の一例を示す図である。図１１を参照すると、ポリシー記憶部４０１は、ソフトウェアポリシーＤ１と、リソース識別子Ｄ２と、インストール先リソース識別子Ｄ３と、ソフトウェアポリシーの更新履歴Ｄ４とを対応付けて記憶している。
　＝＝＝ポリシー検索部４０２＝＝＝
　ポリシー検索部４０２は、少なくとも第一の実施の形態ないし第三の実施の形態におけるポリシー検索部１０２と同様の機能を備える。
　またポリシー検索部４０２は、ポリシー記憶部４０１から読み出したソフトウェアポリシーに対応付けられている更新履歴を、後述のポリシー更新部４０３と検証部４０４とに渡す。
　＝＝＝ポリシー更新部４０３＝＝＝
　ポリシー更新部４０３は、ポリシー検索部４０２が読み出したソフトウェアポリシーを更新する。この際、ポリシー更新部４０３は、ポリシー検索部４０２が読み出したソフトウェアポリシーと、ポリシー検索部４０２から受け取る更新履歴とを対応付けて出力する。図１２および図１３は、ポリシー更新部４０３が出力する情報の一例を示す図である。
　図１２に示されるように、ポリシー更新部４０３は、更新履歴で示されるソフトウェアポリシーが変更された部分の情報（差分）を出力してもよい。例えば、更新履歴として、ユーザ名が“ａａａａ＠ｌｏｃａｌｈｏｓｔ”に変更され、パス名が“／ｈｏｍｅ／＊／ｐｕｂｌｉｃ＿ｈｔｍｌ”に変更されたことを示す情報を含む場合、図１２に示されるように、ユーザ名、およびパス名が以前に変更されたことを示す情報を出力してもよい。
　ポリシー更新部４０３は、図１２で示されるように、更新履歴で示される、変更された部分の出現頻度（例えば、“ユーザ名（２回更新）”、“パス名（４回更新））を示す情報を、合わせて出力してもよい。またポリシー更新部４０３は、最新の更新結果だけでなく、過去の更新履歴を出力してもよい。
　図１３に示されるように、ポリシー更新部４０３は、ポリシー検索部４０２が読み出したソフトウェアポリシーと更新履歴とをあわせて出力してもよい。図１３を参照すると、下線部で示されている箇所が、その更新履歴によって示されている、ソフトウェアポリシーが変更された部分の情報（差分）である。
　ポリシー更新部４０３は、その出力した情報に基づいて、ソフトウェアポリシーの更新処理を示す情報の入力を受ける。そして、ポリシー更新部４０３は、その更新処理を示す情報に基づいて更新したソフトウェアポリシーを、後述の検証部４０４に渡す。
　＝＝＝検証部４０４＝＝＝
　検証部４０４は、ポリシー検索部４０２から更新履歴を受け取る。また検証部４０４は、ポリシー更新部４０３から、更新されたソフトウェアポリシーを受け取る。そして検証部４０４は、そのソフトウェアポリシーとその更新履歴との一致度に基づいて、受け取ったソフトウェアポリシーの更新が正しいか否かを検証する。
　検証部４０４は、例えば更新履歴で示される更新箇所と受け取ったソフトウェアポリシーが更新された箇所とが少なくとも一部重複するか否か、または一致するか否かに基づいてそのソフトウェアポリシーが正しいか否かを検証してもよい。例えば、過去に更新されていない箇所が今回更新された場合、検証部４０４は、正しくない可能性があると判定し、ポリシー更新部４０３を介して該当箇所の再確認を促す情報を出力してもよい。
　また検証部４０４は、更新履歴で示される過去のユーザ名と受け取ったソフトウェアポリシーに含まれるユーザ名とが一致するか否かに基づいてそのソフトウェアポリシーが正しいか否かを検証してもよい。
　ここで、更新履歴で示される過去のユーザ名と受け取ったソフトウェアポリシーに含まれるユーザ名とが一致しない場合に、検証部４０４は、ユーザの権限を、そのユーザの権限を管理するサーバなどに問い合せてもよい。なお、そのユーザの権限は、そのソフトウェアポリシーに含まれるユーザ名で識別されるユーザの権限である。そして検証部４０４はそのユーザが有する権限に基づいて、そのソフトウェアポリシーが正しいか否かを検証してもよい。例えば、そのユーザが管理ロールを有している場合に、そのソフトウェアポリシーが正しいと検証してもよい。
　検証部４０４は、正しいと検証されたソフトウェアポリシーと、新たに更新された差分情報が追加された更新履歴と、リソース識別子と、インストール先リソース識別子とを対応付けてポリシー記憶部４０１に記憶する。このリソース識別子とは、ポリシー検索部４０２が受け取ったリソース識別子である。また、このインストール先リソース識別子とは、ポリシー検索部４０２がリソース管理部から読み出したインストール先リソース識別子である。
　図１４は、第四の実施の形態におけるポリシー更新装置４００の動作の概要を示すフローチャートである。
　ポリシー検索部４０２は、リソース管理部から、リソース識別子を受け取る（ステップＳ１０１）。
　次に、ポリシー検索部４０２は、ステップＳ１０１において受け取ったリソース識別子に対応付けられている、インストール先リソース識別子を読み出す（ステップＳ１０２）。
　次に、ポリシー検索部４０２は、リソース識別子とインストール先リソース識別子とに対応付けられている、ソフトウェアポリシーと更新履歴とをポリシー記憶部４０１から読み出す（ステップＳ４０１）。なお、そのリソース識別子は、ステップＳ１０１において受け取ったリソース識別子である。また、インストール先リソース識別子は、そのステップＳ１０２において読み出したインストール先リソース識別子である。ポリシー検索部４０２は、読み出した更新履歴を、ポリシー更新部４０３と検証部４０４とに渡す。
　次に、ポリシー更新部４０３は、ポリシー検索部４０２が読み出したソフトウェアポリシーと更新履歴とに基づいた情報を出力する（ステップＳ４０２）。
　次に、ポリシー更新部４０３は、その出力した情報に基づいて入力されるソフトウェアポリシーの更新処理を示す情報に基づいて、そのソフトウェアポリシーを更新する（ステップＳ４０３）。そしてポリシー更新部４０３は、更新されたソフトウェアポリシー、および新たに更新された箇所の情報（差分情報）を検証部４０４に渡す。
　次に、検証部４０４は、ポリシー更新部４０３から受け取るソフトウェアポリシーとポリシー検索部４０２から受け取る更新履歴との一致度に基づいて、そのソフトウェアポリシーが正しいか否かを検証する（ステップＳ４０４）。
　そして検証部４０４は、正しいと検証したソフトウェアポリシーと、新たに更新された箇所の情報が追加された更新履歴と、リソース識別子と、インストール先リソース識別子とを対応付けて記憶する（ステップＳ４０５）。
　ステップＳ４０５においてリソース識別子は、ステップＳ１０１においてポリシー検索部４０２が受け取ったリソース識別子である。また、インストール先リソース識別子は、ステップＳ１０２においてポリシー検索部４０２が読み出したインストール先リソース識別子である。
　第四の実施の形態におけるポリシー更新装置４００は、検証部４０４によって正しいと検証されたソフトウェアポリシーを記憶する。したがって、ソフトウェアポリシー更新の際、変更されたリソースの構成に応じた、正しいソフトウェアポリシーが読み出される。システム管理者は、そのソフトウェアポリシーに基づいて更新作業を行う。したがって、システム管理者が異種のミドルウェアまたはＯＳに応じてそれぞれ個別の設定をする場合の、修正不備の可能性を低減することができる。
　したがって第四の実施の形態におけるポリシー更新装置４００は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新することができる。
　［第四の実施の形態の第一の変形例］
　第四の実施の形態において、検証部４０４はポリシー検索部４０２から受け取る検証ルールに基づいて、ソフトウェアポリシーが正しいか否か検証してもよい。この場合、ポリシー検索部４０２は、検証ルールを検証部４０４に渡す。なお、その検証ルールは、ポリシー記憶部４０１から読み出したソフトウェアポリシー、そのソフトウェアポリシーに対応付けられているリソース識別子またはインストール先リソース識別子の少なくともいずれかに基づいて特定される検証ルールである。
　検証ルールは、ソフトウェアポリシーの構文規則であってもよい。または検証ルールは、そのソフトウェアポリシーに記載可能な管理者としてのユーザ名や、そのソフトウェアポリシーに記載可能なパス名であってもよい。または、検証ルールは、そのソフトウェアポリシーによって設定される値の範囲を示す情報であってもよい。この情報は、例えばソフトウェア動作に必要な資源量（ディスク容量、メモリ使用量など）であってもよい。この資源量は、クラウドコンピューティングのソフトウェア利用条件に含まれるＳＬＡ（Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ａｇｒｅｅｍｅｎｔ）によって定められた値であってもよい。
　第四の実施の形態の第一の変形例におけるポリシー更新装置４００は、第四の実施の形態におけるポリシー更新装置と同様の効果を奏する。
　［第五の実施の形態］
　図１５は、第五の実施の形態におけるポリシー管理システム５０の構成を示すブロック図である。図１５を参照すると、第五の実施の形態におけるポリシー管理システム５０は、ポリシー更新装置５００とリソース管理部５１１とポリシー配信部５１２とを備える。
　第五の実施の形態におけるポリシー管理システム５０は、クラスターの概念が導入されることにより、同様のソフトウェア構成の仮想サーバをクラスター化したリソース群に対する、ソフトウェアポリシーをまとめて設定できる。すなわちポリシー管理システム５０は、クラウド環境下で発生する、システムを構成する計算機の増減に対し、個別の計算機の設定の変更を容易に行うことができる。
　以下、第五の実施の形態におけるポリシー管理システム５０が備える各構成要素について説明する。
　＜ポリシー更新装置５００＞
　ポリシー更新装置５００は、ポリシー記憶部５０１とポリシー検索部５０２とポリシー更新部５０３と検証部５０４とを備える。
　＝＝＝ポリシー記憶部５０１＝＝＝
　ポリシー記憶部５０１は、クラスターポリシーとリソース識別子とインストール先リソース識別子とクラスターグループ識別子とクラスター内サーバ識別子とを対応付けて記憶している。図１６は、ポリシー記憶部５０１が記憶する情報の一例を示す図である。図１６を参照すると、ポリシー記憶部５０１は、クラスターポリシーＥ１と、リソース識別子Ｅ２と、インストール先リソース識別子Ｅ３と、クラスターグループ識別子Ｅ４と、クラスター内サーバ識別子Ｅ５とを対応付けて記憶している。
　クラスターポリシーとは、クラスターに属する計算機に対する設定情報である。クラスターを構成する仮想サーバは、ハードウェア・ソフトウェアの構成、その変更の形態が共通であるため、サーバ内のソフトウェアの設定情報・更新箇所も非常に似ている。そこでクラスターポリシーは、クラスター内の仮想サーバに共通する環境情報（共通設定）と、各仮想サーバにそれぞれ固有の環境情報（個別設定）とを含むものとする。例えば、同種のオペレーティングシステム、同種のデータベースを含む仮想サーバクラスターを仮定すると、例えば以下に挙げる項目の情報を含むクラスターポリシーの構成が考えられる。
　＜クラスターポリシー＞
　・共通設定（管理者ユーザ名、格納パス名等）、例えば、
“ａａａａ＠ｌｏｃａｌｈｏｓｔ／ｕｓｒ／ｌｏｃａｌ／ｘｘｘｘ／ｃｏｎｆ”
　・個別設定（ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｃｏｌ）アドレス等）、例えば、
”１９２．１６８．１０．１０”、”１９２１．１６８．１０．２５”、”１９２．１６８．１０．１００”
　・クラスター内ＯＳのソフトウェアポリシー識別子のリスト、例えば、
”ＯＳＸＸ１ｃｏｎｆｉｇ１，ＯＳＸＸ１ｃｏｎｆｉｇ２”
　・クラスター内ＤＢのソフトウェアポリシー識別子のリスト、例えば、
”ＤＢＸＸ１ｃｏｎｆｉｇ１，ＤＢｘｘ１ｃｏｎｆｉｇ２”
　ソフトウェアポリシー識別子は、クラスター内のＯＳまたはＤＢにそれぞれ対応するソフトウェアポリシーの識別子である。
　図１７は、クラスターポリシーの一例を示す図である。図１７を参照すると、クラスターポリシーは、共通設定Ｅ１０１、個別設定Ｅ１０２、クラスター内ＯＳのソフトウェアポリシー識別子のリストＥ１０３およびクラスター内ＤＢのソフトウェアポリシー識別子のリストＥ１０４を含む。
　クラスターグループ識別子は、クラスターを識別するための識別子である。クラスター内サーバ識別子は、クラスターに含まれる計算機のそれぞれを識別するための識別子である。
　＝＝＝ポリシー検索部５０２＝＝＝
　ポリシー検索部５０２は、少なくとも第一の実施の形態ないし第四の実施の形態におけるポリシー検索部１０２またはポリシー検索部４０２のいずれかと同様の機能を備える。
　またポリシー検索部５０２は、後述のリソース管理部５１１から読み出されたインストール先リソース識別子と受け取ったリソース識別子とに対応付けられている、クラスターポリシーをポリシー記憶部５０１から読み出す。
　＝＝＝ポリシー更新部５０３＝＝＝
　ポリシー更新部５０３は、少なくとも第一の実施の形態ないし第四の実施の形態におけるポリシー更新部１０３または４０３のいずれか一方と同様の機能を備える。
　また、ポリシー更新部５０３は、ポリシー検索部５０２が読み出したクラスターポリシーを更新する。この際、ポリシー更新部５０３は、ポリシー検索部５０２が読み出したクラスターポリシーを出力する。図１８は、ポリシー更新部５０３が出力するクラスターポリシーの一例を示す図である。図１８を参照すると、ポリシー更新部５０３は、共通設定（例えば、「ユーザ名」、「パス名」など）と個別設定（例えば、ＩＰアドレスなど）とをそれぞれ出力している。
　ポリシー更新部５０３は、出力した情報に基づいて、ソフトウェアポリシーおよびクラスターポリシーの少なくともいずれかの更新処理を示す情報の入力を受ける。そして、ポリシー更新部５０３は、その更新処理を示す情報に基づいて更新されたソフトウェアポリシーおよびクラスターポリシーの少なくともいずれかを後述の検証部５０４に渡す。
　例えば、共通設定情報である管理者名が更新される場合、ポリシー更新部５０３は、関係するクラスター内のソフトウェアポリシーすべてに、この更新を反映させる。また例えば、複数の仮想サーバが増設され、一括設定を行う場合、ポリシー更新部５０３は以下のように動作してもよい。ここで、追加リソースのリソース識別子はすでにあるものとする。すなわちポリシー更新部５０３は、追加リソースに対応する個別設定情報を追加し、既存のソフトウェアポリシーをひな形として、個別設定情報を上書きしたソフトウェアポリシーを新規に作成する。また、ポリシー更新部５０３は、作成したソフトウェアポリシーの識別子（ソフトウェアポリシー識別子）をクラスターポリシーに追記する。
　以上のように更新されたクラスターポリシーおよびソフトウェアポリシーは、検証部５０４に出力される。
　＝＝＝検証部５０４＝＝＝
　検証部５０４は、少なくとも第四の実施の形態または第四の実施の形態の第一の変形例における検証部４０４と同様の機能を備える。
　検証部５０４は、ソフトウェアポリシーの検証と同様の方法によってクラスターポリシーの検証を行ってもよい。
　＝＝＝リソース管理部５１１＝＝＝
　リソース管理部５１１は、複数のリソース識別子に対応付けられるリソースグループ識別子とその複数のリソース識別子とソフトウェア識別子とを対応付けて記憶する。リソースグループは、任意のリソース集合に対する論理的なグループとして定義されてもよい。例えば、ある仮想サーバに搭載されるリソース集合がリソースグループとして定義されてもよいし、同一クラスターを構成するリソース集合がリソースグループとして定義されてもよい。
　図１９は、リソース管理部５１１が記憶する情報の一例を示す図である。図１９を参照すると、リソース管理部５１１は、リソースグループ識別子Ｆ１と、複数のリソース識別子Ｆ２とが記憶されている。
　またリソース管理部５１１は、リソースグループ識別子Ｆ１に対応付けられているリソース識別子をメンバ情報Ｆ１０１として記憶している。すなわちメンバ情報Ｆ１０１として「ＲＩＤ１、ＲＩＤ２、Ｍｏｎ１、Ｍｏｎ２」がリソースグループ識別子Ｆ１と対応付けられてリソース管理部５１１に記憶されている。ここで、ＲＩＤ１、ＲＩＤ２、Ｍｏｎ１およびＭｏｎ２は、それぞれリソースグループ識別子Ｆ１に対応付けられているリソース識別子Ｆ２である。
　またリソース管理部５１１は、リソース識別子Ｆ２に、ソフトウェア識別子Ｆ２０１、リファレンスモニター識別子Ｆ２０２、およびインストール先リソース識別子Ｆ２０３を対応付けて記憶している。
　ソフトウェア識別子Ｆ２０１は、対応付けられているリソース識別子が示すリソース（以下、対応リソースと呼ぶ）に適用されているソフトウェアを示す情報である。リファレンスモニター識別子Ｆ２０２は、対応リソースを監視する、リファレンスモニターを示す。リファレンスモニターとは、監視対象のリソース（ＶＭ、ファイル、データベースのテーブルなど）へのアクセス制御を実行するソフトウェアである。インストール先リソース識別子Ｆ２０３は、対応リソースがインストールされているリソースを示す情報である。
　図１９の例は、ＯＳであるリソースＲＩＤ１にデータベース（ＲＩＤ２）、リファレンスモニター（Ｍｏｎ１、Ｍｏｎ２）がインストールされ、Ｍｏｎ１がＲＩＤ１、Ｍｏｎ２がＲＩＤ２のアクセス制御をそれぞれ行う、という関係を示している。
　なお、リソース管理部５１１は、リソース識別子Ｆ２がリファレンスモニターを示す場合に、ソフトウェア識別子Ｆ２０１、監視先リソース識別子Ｆ２０４、およびインストール先リソース識別子Ｆ２０３を対応付けて記憶してもよい。
　第五の実施の形態において、リソースはリファレンスモニターを含む。当該事項は、他の実施の形態においても同様である。
　リソース管理部５１１は、リソースグループとしてクラスターを管理してもよい。この場合、リソースグループ識別子が、クラスターグループ識別子と同一になる。ポリシー検索部５０２は、リソース管理部５１１からクラスターグループ識別子を受け取った場合、そのクラスターグループ識別子に対応するクラスターポリシーを読み出してもよい。
　＝＝＝ポリシー配信部５１２＝＝＝
　ポリシー配信部５１２は、検証部５０４が正しいと検証したソフトウェアポリシーまたはクラスターポリシーの少なくともいずれかを所定のリソースに対して配信する。
　具体的には、ポリシー配信部５１２は、前述のソフトウェアポリシーまたはクラスターポリシーに対応付けてポリシー記憶部５０１に記憶されていたリソース識別子を特定する。そしてポリシー配信部５１２は、特定されたリソースに対して、前述のソフトウェアポリシー、またはクラスターポリシーの少なくともいずれかを配信する。
　後者の場合、以下の場合を想定する。クラスターポリシーを受け取ったリソースは、クラスターポリシー情報をもとに、クラスター内の関連ソフトウェアのソフトウェアポリシーを上書き更新する機能を備えている（すなわちクラスターマネージャ機能を持つ）。
　また、ソフトウェアポリシーの配信先リソースは、アクセス制御ソフトウェアであるリファレンスモニターを含んでもよい。
　ポリシー記憶部５０１は、リソース識別子と、そのリソース識別子が示すリソースを備える、計算機を示す識別子（クラスター内サーバ識別子）と、を対応付けて記憶してもよい。この場合、ポリシー検索部５０２は、クラスターポリシーをポリシー記憶部５０１から読み出す。そのクラスターポリシーは、リソース管理部５１１から読み出されたインストール先リソース識別子と、受け取ったリソース識別子と、そのリソース識別子に対応付けられているクラスター内サーバ識別子と、に対応付けられているクラスターポリシーである。
　図２０は、第五の実施の形態におけるポリシー管理システム５０の動作の概要を示すフローチャートである。
　ポリシー検索部５０２は、リソース管理部５１１から、リソース識別子を受け取る（ステップＳ１０１）。
　次に、ポリシー検索部５０２は、ステップＳ１０１において受け取ったリソース識別子に対応付けられている、インストール先リソース識別子を読み出す（ステップＳ５０１）。
　次に、ポリシー検索部５０２は、ステップＳ１０１において受け取ったリソース識別子とステップＳ５０１において読み出したインストール先リソース識別子とに対応付けられている、クラスターポリシーと更新履歴とをポリシー記憶部５０１から読み出す（ステップＳ５０２）。ポリシー検索部５０２は、読み出された更新履歴をポリシー更新部５０３と検証部４０４に渡す。
　次に、ポリシー検索部５０２は、リソース識別子とインストール先リソース識別子とに対応付けられている、ソフトウェアポリシーと更新履歴とをポリシー記憶部５０１から読み出す（ステップＳ５０３）。なお、そのリソース識別子は、ステップＳ１０１において受け取ったリソース識別子である。また、そのインストール先リソース識別子は、ステップＳ５０１において読み出したインストール先リソース識別子である。
　なお、ポリシー検索部５０２は、ステップＳ５０３の処理において、ステップＳ５０２において読み出したクラスターポリシーに対応付けられている、ソフトウェアポリシーとその更新履歴とをポリシー記憶部５０１から読み出してもよい。具体的には、ポリシー検索部５０２は、前述のクラスターポリシーに含まれているソフトウェアポリシー識別子で示されるソフトウェアポリシーをポリシー記憶部５０１から読み出してもよい。
　次に、ポリシー更新部５０３は、ポリシー検索部５０２が読み出したソフトウェアポリシーと更新履歴とに基づいた情報を出力する（ステップＳ４０２）。
　次に、ポリシー更新部５０３は、ポリシー検索部５０２が読み出したクラスターポリシーに基づいた情報を出力する（ステップＳ５０４）。
　次に、ポリシー更新部５０３は、更新処理を示す情報に基づいて、そのソフトウェアポリシーおよびクラスターポリシーの少なくともいずれかを更新する（ステップＳ４０３）。その更新処理を示す情報は、その出力した情報に基づいて入力されるソフトウェアポリシーおよびクラスターポリシーの少なくともいずれかの情報である。
　すなわち、ポリシー更新部５０３は、ソフトウェアポリシーについて更新処理を示す情報の入力を受けた場合、そのソフトウェアポリシーを更新する。また、ポリシー更新部５０３は、クラスターポリシーについて更新処理を示す情報の入力を受けた場合、そのクラスターウェアポリシーを更新する。ポリシー更新部５０３は、ソフトウェアポリシーとクラスターポリシーとのそれぞれについて更新処理を示す情報の入力を受けた場合、そのソフトウェアポリシーとクラスターポリシーとを更新する。
　ポリシー更新部５０３は、更新されたソフトウェアポリシーまたはクラスターポリシーの少なくともいずれかを検証部５０４に渡す。
　次に、検証部５０４は、ポリシー更新部５０３から受け取るソフトウェアポリシーとポリシー検索部５０２から受け取る更新履歴との一致度に基づいて、そのソフトウェアポリシーが正しいか否かを検証する（ステップＳ４０４）。
　次に、検証部５０４は、ポリシー更新部５０３から受け取るクラスターポリシーとポリシー検索部５０２から受け取る検証ルールとに基づいて、そのクラスターポリシーが正しいか否かを検証する（ステップＳ５０５）。
　次に、検証部５０４は、正しいと検証されたソフトウェアポリシーと、リソース識別子とインストール先リソース識別子とを対応付けて記憶する（ステップＳ４０５）。
　ステップＳ４０５においてリソース識別子は、ステップＳ１０１においてポリシー検索部５０２が受け取ったリソース識別子である。また、インストール先リソース識別子は、ステップＳ５０１においてポリシー検索部５０２が読み出したインストール先リソース識別子である。
　次に、検証部５０４は、正しいと検証されたクラスターポリシーと、リソース識別子とインストール先リソース識別子とを対応付けて記憶する（ステップＳ５０６）。
　ステップＳ５０６においてリソース識別子は、ステップＳ１０１においてポリシー検索部５０２が受け取ったリソース識別子である。また、インストール先リソース識別子は、ステップＳ５０１においてポリシー検索部５０２が読み出したインストール先リソース識別子である。
　次に、ポリシー配信部５１２は、検証部５０４が正しいと検証したソフトウェアポリシーおよびクラスターポリシーの少なくともいずれかを、所定のリソースに対して配信する（ステップＳ５０７）。
　所定のリソースとは、以下のように特定される。すなわちポリシー配信部５１２は、前述のソフトウェアポリシーまたはクラスターポリシーに対応付けてポリシー記憶部５０１に記憶されていたリソース識別子を特定する。ポリシー配信部５１２は、リソースに対して、前述のソフトウェアポリシーまたはクラスターポリシーの少なくともいずれかを配信する。配信先がリファレンスモニターであってもよい。
　第五の実施の形態におけるポリシー管理システム５０は、第一の実施の形態ないし第四の実施の形態における少なくともいずれかのポリシー更新装置と同様の効果を奏する。
　更に第五の実施の形態におけるポリシー管理システム５０は、クラスターの概念が導入されることにより同様のソフトウェア構成の仮想サーバをクラスター化したリソース群に対するソフトウェアポリシーをまとめて設定できる。すなわちポリシー管理システム５０は、クラウド環境下で発生する、システムを構成する計算機の増減に対し、個別の計算機の設定の変更を容易に行うことができる。
　本発明によれば、各実施の形態におけるポリシー更新装置は、リソースの構成変化に応じて、ソフトウェアポリシーを適切に更新できる。
　以上、各実施の形態および実施例を参照して本発明を説明したが、本発明は上記実施の形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解しえる様々な変更をすることができる。
　また、本発明の各実施の形態における各構成要素は、その機能をハードウェア的に実現することはもちろん、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリなどのコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られる。この読み取られたプログラムは、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態における構成要素として機能させる。
　以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施の形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しえる様々な変更をすることができる。
　この出願は、２０１１年６月２０日に出願された日本出願特願２０１１−１３６４８７を基礎とする優先権を主張し、その開示のすべてをここに取り込む。
　本発明におけるポリシー更新装置、ポリシー管理システムは、マルチベンダまたはマルチプラットフォーム環境下におけるシステムの設定の統合管理技術に適用されうる。
　５０　ポリシー管理システム
　１００、４００、５００　ポリシー更新装置
　１０１、４０１、５０１　ポリシー記憶部
　１０２、４０２、５０２　ポリシー検索部
　１０３、４０３、５０３　ポリシー更新部
　４０４、５０４　検証部
　１９１　ＣＰＵ
　１９２　通信Ｉ／Ｆ
　１９３　メモリ
　１９４　記憶装置
　１９５　入力装置
　１９６　出力装置
　１９７　バス
　１９８　記録媒体
　５１１　リソース管理部
　５１２　ポリシー配信部
　Ａ１、Ｂ１、Ｃ１、Ｄ１　ソフトウェアポリシー
　Ａ２、Ｂ２、Ｄ２、Ｅ２、Ｆ２　リソース識別子
　Ａ３、Ｂ４、Ｄ３、Ｅ３、Ｆ２０３　インストール先リソース識別子
　Ｂ３、Ｃ２、Ｆ２０１　ソフトウェア識別子
　Ｄ４　更新履歴
　Ｅ１　クラスターポリシー
　Ｅ４　クラスターグループ識別子
　Ｅ５　クラスター内サーバ識別子
　Ｅ１０１　共通設定
　Ｅ１０２　個別設定
　Ｅ１０３　クラスター内ＯＳのソフトウェアポリシー識別子のリスト
　Ｅ１０４　クラスター内ＤＢのソフトウェアポリシー識別子のリスト
　Ｆ１　リソースグループ識別子
　Ｆ１０１　メンバ情報
　Ｆ２０２　リファレンスモニター識別子
　Ｆ２０４　監視先リソース識別子

Claims (11)

  1. 　リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けて記憶するポリシー記憶手段と、
    　リソース識別子を受け取り、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けて記憶するリソース管理手段から、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出すポリシー検索手段と、
    　前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶するポリシー更新手段と、
    　を備えるポリシー更新装置。
  2. 　前記ポリシー記憶手段は、リソース識別子と当該リソース識別子で識別されるリソースに適用されているソフトウェアを示すソフトウェア識別子とインストール先リソース識別子とソフトウェアポリシーとを対応付けて記憶し、
    　前記ポリシー検索手段は、リソース識別子とソフトウェア識別子とを受け取り、前記リソース管理手段から、当該リソース識別子に対応付けられているインストール先リソース識別子を読み出し、当該リソース識別子と前記インストール先リソース識別子と前記ソフトウェア識別子とに対応付けられている前記ソフトウェアポリシーを前記ポリシー記憶手段から読み出す、
    　請求項１記載のポリシー更新装置。
  3. 　前記ポリシー記憶手段は、デフォルトポリシーとしてソフトウェアポリシーをソフトウェア識別子と対応付けて記憶し、
    　前記ポリシー検索手段は、当該リソース識別子と前記インストール先リソース識別子と前記ソフトウェア識別子とに対応付けられている前記ソフトウェアポリシーが前記ポリシー記憶手段に存在しない場合に、前記デフォルトポリシーを読み出す、
    　請求項２記載のポリシー更新装置。
  4. 　前記ポリシー記憶手段は、リソース識別子とインストール先リソース識別子とソフトウェアポリシーと当該ソフトウェアポリシーの更新履歴とを対応付けて記憶し、
    　前記ポリシー更新装置は、検証手段を備え、
    　前記ポリシー検索手段は、読み出したソフトウェアポリシーに対応付けられている更新履歴を前記検証手段に渡し、
    　前記検証手段は、前記ポリシー更新手段が更新したソフトウェアポリシーと、前記ポリシー検索手段から受け取る更新履歴との一致度に基づいて、当該ソフトウェアポリシーが正しいか否かを検証する、
    　請求項１ないし３のいずれか１項に記載のポリシー更新装置。
  5. 　検証手段を備え、
    　前記ポリシー検索手段は、前記ポリシー記憶手段から読み出したソフトウェアポリシーに対応する検証ルールを前記検証手段に渡し、
    　前記検証手段は前記ポリシー検索手段から受け取る検証ルールに基づいて前記ポリシー更新手段によって更新されたソフトウェアポリシーを検証する、
    　請求項１ないし３のいずれか１項に記載のポリシー更新装置。
  6. 　請求項１ないし５のいずれか１項に記載のポリシー更新装置と、
    　前記リソース管理手段と、
    　を備えるポリシー管理システム。
  7. 　ソフトウェアポリシーを配信するポリシー配信手段を備え、
    　前記リソース管理手段は、複数のリソース識別子を一つのリソースグループ識別子に対応付けて記憶し、
    　前記ポリシー配信手段は、前記ポリシー更新手段が更新したソフトウェアポリシーを、当該ソフトウェアポリシーに対応付けられて前記ポリシー記憶手段に記憶されているリソース識別子が対応付けられているリソースグループ識別子を前記リソース管理手段から読み出し、読み出された前記リソースグループ識別子に対応付けられている所定のリソース識別子で示されるリソースに対して配信する、
    　請求項６記載のポリシー管理システム。
  8. 　前記ポリシー記憶手段は、クラスターを示すクラスターグループ識別子と、当該クラスターに属する計算機を示すクラスター内サーバ識別子と、リソース識別子とインストール先リソース識別子と、当該計算機の設定情報であるクラスターポリシーとを対応付けて記憶し、
    　前記ポリシー記憶手段は、リソース識別子と当該リソース識別子が示すリソースが備えられる計算機を示すクラスター内サーバ識別子とを対応付けて記憶し、
    　前記ポリシー検索手段は、前記リソース管理手段から読み出されたインストール先リソース識別子と前記ポリシー検索手段が受け取ったリソース識別子と当該リソース識別子に対応付けられて前記ポリシー記憶手段に記憶されているクラスター内サーバ識別子とに対応付けられているクラスターポリシーを前記ポリシー記憶手段から読み出し、
    　前記ポリシー更新手段は、前記ポリシー検索手段が読み出したクラスターポリシーを更新し、更新されたクラスターポリシーと前記リソース識別子と前記インストール先リソース識別子とを対応付けて前記ポリシー記憶手段に記憶する、
    　請求項６または７記載のポリシー管理システム。
  9. 　リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けてポリシー記憶手段に記憶し、
    　リソース識別子を受け取り、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けて記憶するリソース管理手段から、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出し、
    　前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶する、
    　ポリシー更新方法。
  10. 　リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けてポリシー記憶手段に記憶し、
    　リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けてリソース管理手段に記憶し、
    　リソース識別子を受け取り、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を前記リソース管理手段から読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出し、
    　前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶する、
    　ポリシー管理方法。
  11. 　コンピュータに、
    　リソースの設定情報であるソフトウェアポリシーを、当該リソースを示すリソース識別子と当該リソースがインストールされているリソースを示すインストール先リソース識別子とに対応付けてポリシー記憶手段に記憶する処理と、
    　リソース識別子を受け取り、リソース識別子と当該リソース識別子で識別されるリソースがインストールされているリソースを示すインストール先リソース識別子とを対応付けて記憶するリソース管理手段から、前記受け取られたリソース識別子に対応付けられているインストール先リソース識別子を読み出し、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けられている前記ソフトウェアポリシーを読み出す処理と、
    　前記読み出されたソフトウェアポリシーを更新し、当該更新されたソフトウェアポリシーを、前記受け取られたリソース識別子と前記読み出されたインストール先リソース識別子とに対応付けて、前記ポリシー記憶手段に記憶する処理と、を実行させる
    　不揮発性媒体に記録されたポリシー更新プログラム。
PCT/JP2012/066304 2011-06-20 2012-06-20 ポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法 WO2012176922A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/819,641 US9183009B2 (en) 2011-06-20 2012-06-20 Policy update apparatus, policy management system, policy update method, policy management method and recording medium
JP2013508708A JP5273327B2 (ja) 2011-06-20 2012-06-20 ポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011136487 2011-06-20
JP2011-136487 2011-06-20

Publications (1)

Publication Number Publication Date
WO2012176922A1 true WO2012176922A1 (ja) 2012-12-27

Family

ID=47422748

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/066304 WO2012176922A1 (ja) 2011-06-20 2012-06-20 ポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法

Country Status (3)

Country Link
US (1) US9183009B2 (ja)
JP (1) JP5273327B2 (ja)
WO (1) WO2012176922A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014170517A (ja) * 2013-02-06 2014-09-18 Ntt Comware Corp 管理装置、通信システム、管理方法及びプログラム
JP2015037260A (ja) * 2013-08-14 2015-02-23 日本電信電話株式会社 通信ポリシルール変更システムおよび通信ポリシルール変更方法
EP2851835A1 (en) * 2013-09-24 2015-03-25 Canon Kabushiki Kaisha Information processing apparatus and method for controlling the same, and program
US20170339189A1 (en) * 2016-05-19 2017-11-23 Google Inc. Wireless peripheral administration

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2580425C1 (ru) * 2014-11-28 2016-04-10 Общество С Ограниченной Ответственностью "Яндекс" Способ структуризации хранящихся объектов в связи с пользователем на сервере и сервер
US10341203B2 (en) 2015-01-02 2019-07-02 Gigamon Inc. Policy tracking in a network that includes virtual devices
WO2017126480A1 (ja) * 2016-01-18 2017-07-27 日本電気株式会社 手順生成システム、手順生成方法および手順生成プログラムを格納した記憶媒体
CN108874416B (zh) * 2018-05-04 2022-10-28 天津猎鹰网络技术有限公司 策略处理方法、装置、存储介质、处理器
US20220244935A1 (en) * 2021-01-29 2022-08-04 PeerStreet, Inc. Configurable rules application platform
KR102560230B1 (ko) * 2023-02-16 2023-07-27 나무기술 주식회사 클라우드 기반의 클라이언트 운영 분석 결과를 기반으로 하는 모니터링 정책의 자동 처리 및 배포 방법

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006058938A (ja) * 2004-08-17 2006-03-02 Hitachi Ltd ポリシルール管理支援方法およびポリシルール管理支援装置
JP2006126914A (ja) * 2004-10-26 2006-05-18 Nec Corp セキュリティ設定サービスシステム、セキュリティ設定システム、セキュリティ設定サービス用データベース

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4546020B2 (ja) 2002-07-10 2010-09-15 日本電気株式会社 大規模分散コンピューティングシステムにおける環境定義情報管理システム及び方法
US7437441B1 (en) * 2003-02-28 2008-10-14 Microsoft Corporation Using deltas for efficient policy distribution
US8312454B2 (en) * 2006-08-29 2012-11-13 Dot Hill Systems Corporation System administration method and apparatus
US7971232B2 (en) * 2006-10-30 2011-06-28 Microsoft Corporation Setting group policy by device ownership
WO2011073976A1 (en) * 2009-12-14 2011-06-23 Daj Asparna Ltd. Revision control system and method

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006058938A (ja) * 2004-08-17 2006-03-02 Hitachi Ltd ポリシルール管理支援方法およびポリシルール管理支援装置
JP2006126914A (ja) * 2004-10-26 2006-05-18 Nec Corp セキュリティ設定サービスシステム、セキュリティ設定システム、セキュリティ設定サービス用データベース

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
RYUICHI OGAWA: "Access policy management architecture for virtual server consolidation systems", IPSJ SIG NOTES HEISEI 22 NENDO, 15 August 2010 (2010-08-15) *
RYUICHI OGAWA: "Shorai no Cloud Kiban Gijutsu o Sasaeru Kenkyu Kaihatsu", NEC TECHNICAL JOURNAL, vol. 63, no. 2, 23 April 2010 (2010-04-23), pages 129 - 133 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014170517A (ja) * 2013-02-06 2014-09-18 Ntt Comware Corp 管理装置、通信システム、管理方法及びプログラム
JP2015037260A (ja) * 2013-08-14 2015-02-23 日本電信電話株式会社 通信ポリシルール変更システムおよび通信ポリシルール変更方法
EP2851835A1 (en) * 2013-09-24 2015-03-25 Canon Kabushiki Kaisha Information processing apparatus and method for controlling the same, and program
US20170339189A1 (en) * 2016-05-19 2017-11-23 Google Inc. Wireless peripheral administration
US10264024B2 (en) * 2016-05-19 2019-04-16 Google Llc Wireless peripheral administration

Also Published As

Publication number Publication date
JP5273327B2 (ja) 2013-08-28
US20130290695A1 (en) 2013-10-31
US9183009B2 (en) 2015-11-10
JPWO2012176922A1 (ja) 2015-02-23

Similar Documents

Publication Publication Date Title
JP5273327B2 (ja) ポリシー更新装置、ポリシー管理システム、ポリシー更新方法およびポリシー管理方法
US9389791B2 (en) Enhanced software application platform
JP6329547B2 (ja) クラウドコンピューティング環境で使用するサービス管理エンジンを提供するためのシステムおよび方法
JP5572409B2 (ja) 電子装置と仮想マシン提供装置及びそれを利用した仮想マシンサービス利用方法
US8949831B2 (en) Dynamic virtual machine domain configuration and virtual machine relocation management
US11070541B2 (en) Certificate management method and apparatus in network functions virtualization architecture
US9170806B2 (en) Software discovery by an installer controller
US9727352B2 (en) Utilizing history of changes associated with software packages to manage computing systems
US9032394B1 (en) Deploying drivers for an operating system on a computing device
US20140325514A1 (en) Maintenance of Offline Virtual Machines Based on a Maintenance Register
US11243793B2 (en) Virtual machine management
US20230131898A1 (en) Techniques for building and validating database software in a shared management environment
US8838790B2 (en) Configuration value management apparatus and management method
JP2013077220A (ja) コンピュータシステム及びアプリケーションのマルチバージョン管理装置
US20220350629A1 (en) Update management for managed virtual machines
US20220350628A1 (en) Managed virtual machines
US9348849B1 (en) Backup client zero-management
US11966880B2 (en) Policies and controls for building and validating database software in a shared management environment
JP4866433B2 (ja) 認証情報を変更するためコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
JP2003008575A (ja) ネットワーク管理システム
US20220350630A1 (en) Just-in-time assembly for managed virtual machines
US20220350631A1 (en) Transition to modern management using managed virtual machines
US12001828B2 (en) Automatic self-adjusting software image recommendation
US20220188091A1 (en) Automatic self-adjusting software image recommendation
US20230125904A1 (en) Recommendation system for building and validating database software in a shared management environment

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2013508708

Country of ref document: JP

Kind code of ref document: A

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

Ref document number: 12802698

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13819641

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12802698

Country of ref document: EP

Kind code of ref document: A1