JP4866433B2 - Computer system for changing authentication information, method and computer program therefor - Google Patents

Description

  The present invention relates to a computer system for changing authentication information, a method thereof, and a computer program.

  In recent years, the number of user identities (hereinafter referred to as IDs) to be managed by the system is increasing due to frequent corporate acquisitions, mergers, business unit reorganizations, or corporate alliances. In addition, changes in authentication information such as IDs and passwords are increasing due to the temporary recruitment of contract employees or the transfer or transfer of employees. Under such a business environment, as the number of user IDs to be managed increases, it becomes difficult to perform distributed management systematically, strategically and geographically.

  ID management is a method of distributing a user ID and password for a user to a plurality of systems when one user uses or manages the plurality of systems. An example product for identity management is Tivoli ™ Identity Manager (hereinafter TIM) sold by International Business Machines Corporation (hereinafter IBM). TIM aggregates user ID and password information distributed to multiple systems and integrates and manages them, and with a provisioning function, a life cycle management of user IDs and user attributes, that is, a series of processes from registration to change and revocation. A solution that automatically handles process management. For example, in the case of personnel changes, the TIM simply changes the user ID based on a policy set in advance by changing the organization information by simply moving the transfer target person to the new organization on the GUI. Deletion processing or access authority setting change can be automatically performed.

  The following Patent Document 1 describes a method for updating a password of a user management file provided in each system in which a user ID and a password are registered (Claim 1). In this update method, when there is a request for changing the password registered in the user management file of one system, the password registered in the user management file is updated and the user of the updated password is updated. The password registered in the user management file of another system for the user ID that matches the ID is updated.

  The following Patent Document 2 describes an information management apparatus that manages information of a plurality of systems connected to a network (claim 1). The information management device automatically reflects the network information and user information of all applicable systems (servers) in synchronization when there is an instruction to register, change, or delete from the user or administrator. The configuration is adopted (paragraph 0068). Therefore, in Patent Document 2, a change instruction is issued to all systems.

  The following Patent Document 3 describes an information management apparatus that searches a system (server) connected to a network and automatically collects a system (server) that needs to transmit information (paragraph 0014). In this information management apparatus, when a plurality of systems (servers) are connected to a network to constitute a single system as a whole, it is automatically detected when there is an instruction from a user or administrator for registration / change / deletion. In general, network information and user information of all systems (servers) that are applicable are synchronized and reflected. Therefore, in Patent Document 3, a change instruction is issued to all systems.

  By the way, ITIL (Information Technology Infrastructure Library) (a trademark of the British government) is a collection of best practices (best practices) for realizing IT service management. The heart of ITIL is service support and service delivery. One service support is configuration management. Configuration management refers to the component that is the management target of IT service management (configuration item, also referred to as configuration item, hereinafter abbreviated as CI), maintains and updates information about the component, confirms, And an auditing process. The component is a resource (resource) that is a target of configuration management. The components are not only system resources including hardware and software, but also the equipment necessary for providing IT services, rules for operating IT services, documents such as work procedures and configuration diagrams, maintenance of hardware or software Includes services such as work, processes, and human resources. In the ITIL framework, in order to manage the constituent elements, it is recommended that management be performed in a unified manner using a database called a configuration management database (hereinafter sometimes abbreviated as CMDB). The CMDB is a database that records at least one predetermined attribute of a component and a relationship with another component. The most important ability provided by implementing the CMDB is an ability to automatically discover information about components (also called discovery or automatic detection) and an ability to automatically update (also called tracking). In the CMDB, it is important to accurately reflect information on the constituent elements in the CMDB.

  IBM provides "Tivoli Change and Configuration Management Database" (hereinafter Tivoli CCMDB) as software for supporting the construction of the CMDB and controlling operation processes based on the CMDB. For more information on discovery and tracking in Tivoli CCMDB, see IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1, pp. 41-64, November 2006. In Tivoli CCMDB, operation management software is implemented to execute discovery and tracking.

  Tivoli (trademark) CCMDB is a component on a distributed network environment, server, client, operating system (OS), middleware (Web / AP / DBMS / LDAP, etc.), package software, management tools, network equipment and storage 300 types of devices are identified, and information about each component, for example, information about the configuration of the computer, information about application software that runs on each computer, network attached storage (NAS) connected to each computer And configuration information such as a storage area network (SAN) directly connected to the network can be automatically discovered and updated. The method of collecting information about each component varies depending on the management target, but basically, the computer system that manages the CMDB periodically accesses the management remote interface using SSH (Secure SHell). The setting file or configuration information on the OS is read, or the computer system that manages the CMDB executes a setting confirmation command. For this reason, it is not necessary to install an agent program in the managed component. Based on the data model “Common Data Model” (hereinafter referred to as “CDM”) for configuration management database proposed by IBM, the information discovered and updated in the above-mentioned manner is composed of 31 sections ( Category such as Computer System, Database, Application, Process), 636 types of classes (basic unit of data model, belonging to one or more sections), 2609 types of attributes (data attribute information, belonging to one class ), 7 types of interfaces (groups of frequently used attributes, belonging to multiple sections), 57 types of relationships (relationships), and 49 types of data (data types). For details on CDM, see IBM REDPAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices (IBM Form Number REDP-4389-00), pages 2-7, November 2007. Information about each component and the relationship between the component and other components is passed to a GUI display tool, for example, a TADDM (Tivoli ™ Application Dependency Discovery Manager) console. Each component and the relationship between the component and another component are visually displayed on the display device using individual blocks and links between the blocks.

JP-A-5-189288 JP 2000-194630 A JP 2004-54941 A

IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1, pp. 41-64, November 2006 IBM RED PAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices (IBM Form Number REDP-4389-00), pages 2-7, November 2007

  Authentication information of an account of a server system such as a database (DB) server system or a mail server system is used for connection from a client system. When the authentication information is changed, there is a possibility that the client system cannot connect to the server system and a connection error occurs due to the change of the authentication information of the server system. Therefore, the authentication information used by the client system connected to the server system must be changed. However, as the number of client systems increases, the change work becomes enormous. Therefore, in ID management, it is required to automatically specify hardware or software to which the changed password should be distributed in response to the change of authentication information.

According to the present invention, in order for the second component to connect to the first component, the first information from the authentication information (first authentication information) about the first component and the first component Provided is a computer system for changing second authentication information in an environment that requires authentication by matching with authentication information (second authentication information) transmitted to a component. The computer system
A repository storing at least one predetermined attribute of a component and a relationship between the component and another component, wherein at least one of the attribute and the relationship is updated by a discovery that detects information about the component The above repository,
In response to the change request for the first authentication information, based on the relationship, a specifying unit that specifies the second component that is affected by the change of the first authentication information;
An instruction unit for instructing change of the second authentication information transmitted from the identified second component.

The terms used in the computer system of the present invention will be described below.
The “first component” may be a server, for example. The server is an authenticating side and means a client-server server in authentication. The “first component” may be, for example, application software that performs authentication in response to an authentication request from another system, or a system that runs the application software. The “first component” requests, for example, authentication information from the second component in order to connect to the first component. The first component may be, for example, a DB server system, a mail server system, DB application software, or mail application software, but is not limited thereto. For example, in response to a connection request from the second component, the “first component” transmits a command for instructing to transmit authentication information to the second component.
The “second component” may be, for example, a client. A client is a side that requests authentication and receives authentication, and means a client-server client in authentication. The “second component” may correspond to, for example, application software that requests authentication from another system or a system that runs the application software. The “second component” transmits, for example, authentication information requested from the first component to the first component when connecting to the first component.
A combination of the “first component” and the “second component” may be, for example, the following, but is not limited thereto.
First component Second component-Server system-Client system-Server system-Client system
Application software-Server system-Client system Application software-Server system-Client system application software Application software Note that "first component" and "second component" are For example, it may be two application software in the same system. In this case, one application software functions as a client, and the other application software functions as a server.
“Authentication information” may be, for example, an ID, a password, a digital certificate, or a combination thereof, but is not limited thereto. Authentication information is transmitted from the second component to the first component in order for the second component to connect to the first component. Then, by matching (matching) the authentication information about the second component stored in the first component with the authentication information transmitted from the second component to the first component, The first component allows the second component to connect to the first component.

The present invention also provides authentication information about the first component (first authentication information) and the first component from the first component so that the second component is connected to the first component. A method for changing the second authentication information in an environment that requires authentication by matching with authentication information (second authentication information) transmitted to the component is provided. The method includes causing a computer system to perform the following steps. The step is
Storing at least one predetermined attribute of the component and a relationship between the component and another component in the repository, wherein at least one of the attribute and the relationship is detected by discovery for detecting information about the component The storing step, which can be updated;
Identifying a second component affected by the change of the first authentication information based on the relationship in response to the change request of the first authentication information;
Instructing to change the second authentication information transmitted from the identified second component.

  In one embodiment of the present invention, the instructing step further includes a step of instructing a change of the first authentication information.

  In one embodiment of the present invention, the identifying step identifies at least one operation schedule of the identified second component and first component based on the attribute.

  In one embodiment of the present invention, the identifying step includes a second component managed by the identified second component and each operation schedule of the first component, or a job schedule system. Based on the operation schedule of the component and the first component, the time when the first authentication information or the second and first authentication information can be changed is determined.

  In one embodiment of the present invention, the instructing step stops the second component and instructs to change the second authentication information at the determined time.

  In one embodiment of the present invention, the instruction unit further instructs the change of the first authentication information in response to the change of the second authentication information.

  In one embodiment of the present invention, the identifying step includes a second component managed by the identified second component and each operation schedule of the first component, or a job schedule system. The user is allowed to determine when the first authentication information or the second and first authentication information can be changed based on the operation schedule of the component and the first component.

  In one embodiment of the present invention, the instructing step stops the second component and instructs to change the second authentication information at the determined time.

  Further instructing the change of the first authentication information in response to the step of instructing and the change of the second authentication information.

  In one embodiment of the present invention, the specifying step uses the information for specifying the first component in the change request in response to the change request for the first authentication information. The attribute or relationship data for the first component stored in is specified.

  In one embodiment of the present invention, the relationship includes a relationship between the first authentication information and the second authentication information.

  In one embodiment of the present invention, the step of specifying includes the step of specifying the second component based on a relationship between the first authentication information and the second authentication information.

  In one embodiment of the present invention, the identifying step is based on at least one of the identified second component and the first component based on the operation schedule file or the attribute of the operation schedule. Including a step of identifying an operation schedule.

  In one embodiment of the invention, the step of identifying further includes the step of identifying the second component based on a relationship for the first component.

  In one embodiment of the present invention, the step of specifying further includes the step of specifying the operation schedule based on an attribute for the second component.

The present invention further includes authentication information about the first component (hereinafter referred to as first authentication information) and the second component to connect the second component to the first component. Provided is a method for changing second authentication information in an environment that requires authentication by matching with authentication information (hereinafter, second authentication information) transmitted to a first component. The method includes causing a computer system to perform the following steps. The step is
Storing at least one predetermined attribute of the component and a relationship between the component and another component in the repository, wherein at least one of the attribute and the relationship is detected by discovery for detecting information about the component The storing step, which can be updated;
Identifying a second component affected by the change of the first authentication information based on the relationship in response to the change request of the first authentication information;
Identifying an operation schedule of the identified second component and first component based on the attribute;
Determining when the second and first authentication information can be changed based on the identified second component and each operation schedule of the first component;
Instructing the change of the second authentication information transmitted from the identified second component at the determined time;
Instructing to change the first authentication information.

  The present invention further includes authentication information about the first component (hereinafter referred to as first authentication information) and the second component to connect the second component to the first component. A computer program for changing second authentication information in an environment that requires authentication by matching with authentication information (hereinafter referred to as second authentication information) transmitted to the first component provide. The computer program causes a computer system to execute each step of the method described in any one of the above.

  According to the embodiment of the present invention, a client system connected to the server system is identified and transmitted from the identified client system in response to a request for changing authentication information for connecting to the server system. It is possible to change authentication information.

The example of the ID management system which is a prior art is shown. The example of the connection failure accompanying the change of authentication information in the ID management system of FIG. 1A is shown. 2 illustrates an example of a computer system including a CMDB for managing a CI. It shows the creation of a CI, a CI instance, and a relationship (usedBy) instance. A data model, a discovery instance, a CI instance, and a relation model are shown. The outline | summary of the tool for the structure management in CMDB is shown. 3 shows an example of a configuration information management screen in the CMDB. 1 shows an example of the entire system for changing authentication information using a CMDB, which is an embodiment of the present invention. FIG. 4B is a functional block diagram illustrating functions of a system for changing authentication information described in FIG. 4A. FIG. 4 shows a block diagram of computer hardware of each system shown in FIGS. 4A and 4B. FIG. 4 shows the relationships “AuthenticatedBy” and “Authenticates” on the CMDB between the client system and the server system, which is an embodiment of the present invention. FIG. 5B illustrates an example of a CI instance, data model, and relationship model for a client system including the relationship “AuthenticatedBy” of FIG. 5A. FIG. 5B shows an example of a CI instance, data model, and relationship model for a server system that includes the relationship “Authenticates” of FIG. 5A. FIG. 5C shows an example of the relationship model “Authenticates” and its relationship instances. FIG. 6 shows a sensor used for discovery of authentication dependency in CMDB, which is an embodiment of the present invention. FIG. An authentication-related discovery method using the sensor described in FIG. 6A is shown. FIG. 6B is a conceptual diagram of signatures and knowledge used in the authentication-related discovery method of FIG. 6B. The system configuration | structure for the change of the authentication method which is the 1st scenario of embodiment of this invention, and the data associated with it are shown. An example of a CI instance, a data model, and a relation model of the application software A1 shown in FIG. 7A is shown. 7B shows knowledge used for changing authentication information in FIG. 7A. The flowchart of the change process of authentication information which is the 1st scenario of embodiment of this invention demonstrated in FIG. 7A is shown. An application example of a system in which authentication information change processing is performed, which is a second scenario of the embodiment of the present invention, will be described. The processing flow created from the search result of the relationship of the authentication information demonstrated in FIG. 8A is shown. An example of a CI instance, a data model, and a relation model of the server system S shown in FIG. 8A is shown. The flowchart of the change process of authentication information which is the 2nd scenario of embodiment of this invention demonstrated in FIG. 8A is shown. An application example of a system in which authentication information change processing is performed when the server system S is also used in a batch job, which is a third scenario of the embodiment of the present invention, will be described. FIG. 9B shows a CI instance, a data model, and a relation model for a server system, which is the third scenario of the embodiment of the present invention described in FIG. 9A. The flowchart of the change process of authentication information which is the 3rd scenario of embodiment of this invention demonstrated in FIG. 9A is shown.

Hereinafter, terms relating to the CMDB in the embodiment for carrying out the present invention will be described below.
-Repository A repository stores at least one set of data. The one set of data is data indicating a relationship between at least one predetermined attribute of the component and another component. The set of data includes, for example, data indicating at least one predetermined attribute of a component including a hardware component or a software component and a relationship between the component and another component. The repository is, for example, CMDB. The component and the relationship between the component and other components may be implemented, for example, with an instance of static data or an instance of a class of Java (a trademark of Sun Microsystems). The repository is not particularly limited as long as it holds the one set of data, but one preferred embodiment is a CMDB recording unit that records CMDB.
・ Component (CI)
CI is data corresponding to components belonging to the scope of IT service management, and is a basic unit of management object in IT service management. CI includes, for example, system resources including hardware and software, equipment necessary for providing IT services, rules for operating IT services, documents such as work procedure manuals and configuration diagrams, hardware or software maintenance work, etc. Includes services, processes, and human resources. In the future, various types of CI will be managed by CMDB. Each CI is represented on the CMDB as an instance of a data model.
・ Configuration management database (CMDB)
The CMDB is a database that performs integrated storage and management of information regarding all components of the information system. The CMDB records at least one predetermined attribute of each CI and a relationship with another CI. The CMDB assists the organization in understanding the relationships between components and allows its configuration to be managed. CMDB is the core of the configuration management process of the ITIL framework. The CMDB is conceptually a database, but can physically take the form of a spreadsheet of a database system or spreadsheet software. By using CMDB, the administrator can easily understand the relationship between CIs.
-Component instance (CI instance)
The CI instance is data corresponding to the CI. Each CI instance is represented on the CMDB as an instance of the data model. Examples of instances are instances of static data or Java (trademark of Sun Microsystems) class instances. The installed Java class instance is stored in the CMDB by a mechanism called Java Data Objects (JDO), for example, that persists the Java class instance and saves it on the hard disk. Therefore, even if the computer system is turned off, the created Java class instance will not be lost. When the computer is turned on next time, it is read from a storage device, for example, a hard disk, and the main memory. Expanded above, it becomes an instance of a Java class that can be changed or deleted by a Java program. In the following description, there is a case where the CI is implemented in the CMDB as an instance, and the description may proceed.
Data Model The data model is a schema for defining CIs and is an information model that provides a consistent definition of managed CIs and the relationships between those CIs. Specifically, the data model defines a relationship between predetermined attributes of the CI and other CIs (manufacturing equipment, processes, etc.). As an example of the data model, there is a data model “CDM” for a configuration management database proposed by IBM. The CDM is implemented based on, for example, Unified Modeling Language (UML).
・ Attributes
The attribute specifies each CI when managing the CI, and describes the CI. Examples of the attributes include, but are not limited to: CI name (CI general name such as server, client, firewall), product number (ID) (a number for individually identifying a specific entity of CI, serial number, serial number, etc.), category ( CI classification (eg, hardware, software, document), type (description of CI further detailing classification in category), model number (CI model number of CI named by supplier), warranty period (by CI supplier) Warranty period), version number (CI version number), location (where the CI exists, eg PC installation location, software archive, media storage location, site providing services), owner responsible (CI The name of the person responsible for management), the date of commencement of responsibility (the date on which the responsible person became responsible for the CI), the supplier (the CI developer or (Provider), license (license number, number of licenses, etc.), provision date (date when CI was provided to the organization), acceptance date (date when CI was accepted by the organization), use start date (CI was activated) Date), CI status (current status, eg running, testing, faulty, or future status, eg planned CI status), CI instance status (CI instance enabled or disabled). Attributes required for IT service management will continue to be defined.
・ Relation
The relationship represents a relationship between CIs. Relationships can be defined in the data model in the same way as CI. Examples of relationships include assigns, canConnect, canUse, connectAt, connections, controls, deployedOn, Located, Managed, Owned, provides, runAt, uses, and usedBy in Common Data Model. Relationships necessary for IT service management will continue to be defined. In the embodiment of the present invention, “AuthenticatedBy” and “Authenticates” indicating the dependency relationship between the authentication information of the client system and the server system are used.

In the following, according to the drawings, a conventional ID management system (FIGS. 1A to 1B), a basic concept of CMDB (FIGS. 2A to 2C), configuration management in CMDB (FIGS. 3A to 3B), and an embodiment of the present invention The system and method (FIG. 4A and later) will be described in order. Since the system and method according to the embodiment of the present invention uses CMDB, the basic concept of CMDB and the configuration management of CMDB will be described with reference to FIGS.
It should be understood that this embodiment is for the purpose of illustrating a preferred aspect of the present invention and is not intended to limit the scope of the invention to what is shown here. Further, throughout the following drawings, the same reference numerals refer to the same objects unless otherwise specified.

FIG. 1A shows an example of a conventional ID management system.
The client system (101) can be connected to the server system (102) via a network such as an intranet or the Internet.
On the client system (101), for example, application software that runs on a WebSphere Application Server (hereinafter referred to as WAS) is installed.
Hereinafter, the term “client system” may refer to not only the client system but also application software running on the client system.
For example, DB application software or mail server application software is installed on the server system (102).
Hereinafter, the term “server system” may refer to not only the server system but also application software running on the server system.
In order to connect to the server system (102), the client system (101) transmits authentication information such as an ID and a password to the server system (102) (111).
The server system (102) verifies authentication information such as an ID and a password transmitted from the client system (101) in order to allow the client system (101) to connect to the server system (102). Do.
In response to the confirmation of the authentication, the server system (102) provides the client system (101) with data or updates the data, or the client system (101) Allow reference (112).
Thereby, the client system (101) accesses the server system (102) and acquires data from the server system (102), or provides data to the server system (102), or It becomes possible to refer to the data of the server system (102).
The ID management system (103) manages IDs and passwords used in the server system (102). The ID management system (103) can also distribute the ID and password to the client system (101) (114).

FIG. 1B shows an example of a connection failure accompanying a change in authentication information in the ID management system of FIG. 1A.
In step 121, the client system (101) sends authentication information to the server system (102) and requests connection. The authentication information is, for example, an ID for accessing the server system (102), a password or a digital certificate, or a combination thereof.
In step 122, the server system (102) verifies the authentication information transmitted from the client system (101). The server system (102) establishes a connection between the client system (101) and the server system (102) in response to confirmation of the authentication information. As one embodiment, for example, in a DB connection, application software on the client system (101) pools and holds a plurality of connections with the DB application software on the server system (102), and You may make it connect.
In step 123, the ID management system (103) changes the authentication information stored in the server system (102). The change of the authentication information is, for example, a password change. When the password is changed, since a connection is established between the client system (101) and the server system (102), a connection error does not occur immediately on the client system (101). For example, in the above DB connection, since the client system (101) pools and holds a plurality of connection routes with the server system (102), no error occurs in the connection when the password is changed. . Therefore, at the time when the authentication information of the server system (102) is changed, the administrator cannot always check whether there is an influence on the application software on the client system (101).
In step 124, the client system (101) is restarted (in the case of application software on the client system (101), the application software is re-executed), and the client system (101 ) Re-sends authentication information to the server system (102) and requests connection. However, since the authentication information on the server system (102) has been changed, the connection between the client system (101) and the server system (102) is not established (connection failure).
In step 125, since the connection is not established, a connection failure message is issued on the client system (101). Alternatively, the client system (101) stops its operation.

  2A to 2C show the basic concept of CMDB used in the system and method according to the embodiment of the present invention.

FIG. 2A shows an example of a computer system (200) including CMDB for managing CI.
FIG. 2A describes component A and component B as examples of CI. Each of the components A and B may be a software component or a hardware component. The software components are, for example, DB2 (trademark), WebSphere (trademark), Notes Domino (trademark), Linux, Tomcat, Apache, but are not limited thereto. The hardware component is, for example, a client computer or a server computer, but is not limited thereto.
The computer system (200) includes a discovery unit (201), a CI identification unit (202), a CI instance creation unit (203), an attribute and relationship update unit (204), and a CMDB (205). The discovery unit, the CI identification unit, the CI instance creation unit, the attribute and relationship update unit, and the CMDB may be implemented on a single computer, or may be implemented in a distributed manner on a plurality of computers. The computer system (200) further includes a discovery table (206), a model table (207), and a relationship table (208). These tables may be implemented on a single computer, or may be distributed and implemented on a plurality of computers.

FIG. 2A shows an example of a TADDM console screen (209). The screen shows the relationship between CIs and CIs. The relationship between CIs and CIs displayed on the screen is an example, and does not display all the relationships between CIs and CIs that are the management targets of the computer system (200).
The computer system (200) manages components that are its own management targets. The management target of the computer system (200) is a component that can be discovered by the computer system (200), a component that can be managed by manually inputting information even if it is not a discovery target, Or a combination thereof.

  The discovery unit (201) executes detection of information about the CI that is a CMDB management target (also referred to as a discover). A part of the CI is displayed on the screen (209) of the TADDM console. The computer system (200) may have a plurality of discovery units (201). Preferably, the management target is connected to a computer system via a network. It does not matter whether the network is a wired connection or a wireless connection. The administrator of the computer system can arbitrarily set the detection target. The detection range can be specified by, for example, a domain name, an IP address, a MAC address, a device identifier, a database name, or a combination thereof. When the CI to be managed is, for example, hardware or software, information about the hardware or software is detected. The detected information can be information about a new CI or an updated attribute or relationship value of an existing CI. The new CI is a CI that is detected by the discovery unit (201) and is not registered in the CMDB (205). An existing CI is a CI in which an instance of the CI is already registered in the CMDB (205). The discovery unit (201) detects information about the CI according to a discovery instance (for example, A-Discovery) (FIG. 2C, 212) stored in the discovery table (206). Which discovery instance is used may be specified in the discovery method in the data model (FIG. 2C, 211). The discovery unit (201) passes the detected information about the CI to the CI identification unit (202).

  The CI identification unit (202) receives information about the CI from the discovery unit (201) and processes the detection result. The CI identifying unit (202) refers to the CMDB (205) to determine whether the information on the CI is information on a new CI or an updated attribute or relationship value of an existing CI. For example, the determination can be performed by comparing the CI instance name stored in the CMDB with the information about the CI. When the information about the CI is related to a new CI, the CI identifying unit (202) passes the information to the CI instance creating unit (203). On the other hand, when the information about the CI is an updated attribute or relationship value of the existing CI, the CI identifying unit (202) passes the information to the attribute and relationship updating unit (204).

  The creation of the relationship between the two CI instances is performed, for example, by identifying the CI instances of the components A and B, which are known to have a relationship between the component A and the component B.

  The CI instance creation unit (203) executes the CI according to the data model (FIGS. 2C and 211) stored in the model table (207) and the relationship model (FIGS. 2C and 214) stored in the relationship table (208). A set of data indicating a predetermined attribute of the CI and a relationship with another CI is created from the information on the CI. The set of data may be implemented, for example, with an instance of static data or an instance of a class of Java (a trademark of Sun Microsystems). An example of the set of data is a CI instance. An example of a CI instance is shown in FIG. 2C (213). The one set of data is stored in the CMDB (205). Note that one set of data may have attributes and relationships in the CI instance (see FIGS. 2C and 213), or may have attributes in the CI instance, and separately as a relation instance, CMDB (205) may be stored. In the latter case, the CI instance has a link to identify the related relationship instance.

  The attribute and relationship update unit (204) realizes tracking together with the discovery unit (201). The attribute and relationship update unit (204) reflects the updated attribute or relationship value of the CI in the CI instance of the CI stored in the CMDB. That is, the attribute value or relationship value of the CI instance of the CI is updated. The update is performed by replacing the value with information about the CI detected by the discovery unit (201). In the replacement, all of the attributes or relationship values of the CI instance may be replaced with information about the CI detected by the discovery unit (201), or only different values may be replaced.

  The CMDB (205) stores CI instances (FIGS. 2C and 213) of the CI.

  The discovery table (206) stores discovery instances (212 in FIG. 2C). The discovery instance (212) is used when information about the CI is detected by the discovery unit (201). The discovery instance (212) can be implemented, for example, with an instance of static data or an instance of a class of Java (trademark of Sun Microsystems). The discovery instance (212) is also called a discovery policy. The discovery instance (212) includes a range to be searched by the discovery unit (201), that is, a collection target (scope) that is a CI search range, an attribute to be collected, and a relationship to be collected. The collection target can be specified using, for example, a subnet IP address, an IP address range, an individual IP address, a MAC address, a device identifier, a host name or a database name, or a combination thereof. As another aspect, the collection target may be a schedule management database (not shown) connected to the computer system (200) via a network. The schedule management database stores, for example, data related to process management that uses devices. As yet another aspect, the collection target may be a database (not shown) that stores a batch process definition file. When the collection target is a database storing a batch process definition file, the discovery unit (201) performs detection by reading the contents of the batch process definition file. In the batch processing definition file, for example, data indicating in which order the devices are used is stored.

  The model table (207) stores the data model (FIG. 2C, 211). The data model (211) is used when a set of data indicating a predetermined attribute of the CI and a relationship with another CI is created by the CI instance creating unit (203).

  The relationship table (208) stores the relationship model (FIG. 2B, 214). The relationship model (214) is used when a set of data indicating a predetermined attribute of the CI and a relationship with another CI is created by the CI instance creation unit (203).

In FIG. 2A, the discovery unit (201) detects information about the CI to be managed connected to the computer system (200) via the network, and the component A, the component B, and the relationship between these components Indicates that information has been detected. Next, the CI identifying unit (202) determines whether the detected information is about a new CI with reference to the CMDB (205). In response to the determination, the CI instance creation unit (203) creates a CI instance of the component A, a CI instance of the component B, and an instance of a relationship (usedBy) between these components. The CI instance creation unit (203) stores the created instances in the CMDB (205). FIG. 2A shows that the CI instance of the component B is in a usedBy relationship with the CI instance of the component A.
Based on the information about the detected CI, the discovery unit (201) creates the CI and the relationship between the CIs according to the data model (FIG. 2C, 211) and registers them in the CMDB (205). The CMDB (205) stores CI attributes and relationships with other CIs. Therefore, the system administrator can extract a real dependency relationship between CIs using the CMDB (205).

  The component includes a hardware component or a software component, and a combination thereof is arbitrary.

FIG. 2B illustrates creation of a CI, a CI instance, and a relationship (usedBy) instance.
The CI instance of the component A is created by the CI instance creation unit (FIGS. 2A and 203) using the data model of the component A from the information about the component A detected by the discovery unit (FIGS. 2A and 201) Is done. Similarly, the CI instance of the component B is created by the CI instance creating unit (203) from the information about the component B detected by the discovery unit (201) using the data model of the component B. Each data model of the component A and the component B is stored in a model table (FIG. 2A, 207). An instance of the relationship between CIs, that is, the relationship (usedBy) between the component A and the component B is obtained from the information about the component A detected by the discovery unit (201) according to the relationship model. Created by. The relationship model is stored in a relationship table (FIG. 2A, 208).
Also, when the constituent elements are, for example, constituent elements B1, B2, and B3, each piece of information about the constituent elements B1, B2, and B3 is instantiated using the data model of the constituent element B, and the CI of the constituent element B1 An instance, a CI instance of component B2, and a CI instance of component B3 are created. Each CI instance of components B1, B2, and B3 is also stored in the CMDB (FIG. 2A, 205).

  2C shows a data model (211) stored in the model table (FIG. 2A, 207), a discovery instance (212) stored in the discovery table (FIG. 2A, 206), and a CMDB (FIG. 2A). 205), the CI instance (213) stored in (component A), and the relationship model (214) stored in the relationship table (FIG. 2A, 208).

  The data model (211) is a schema for defining the CI. The data model (211) includes, for example, a “model name” indicating which CI model, a “model attribute” indicating an attribute of the CI specified in the model name, and a CI specified in the model name and other CIs. Includes descriptions of possible “relationships”. The data model (211) may also include a “discovery method” description that identifies a discovery instance for detecting the CI specified in the model name. The discovery method can be specified by a discovery instance name. In the case of FIG. 2C, it is A-Discovery. For example, the model attribute is defined according to the attribute defined in the data model “CDM” for the configuration management database proposed by IBM, but is not limited thereto. In CDM, as of 2006, 2609 types of attributes are defined. The manager of the CMDB can arbitrarily specify the attribute in the data model (211). The relationship is defined according to the relationship defined in the CDM, for example, but is not limited thereto. In the CDM, as of 2006, 57 types of relationships are defined.

  The discovery instance (212) is the “name” of the discovery instance, the “collection target (scope)” of the management target (CI) collected by the discovery unit (FIG. 2A, 201), and the management collected by the discovery unit (201). Each description includes “collecting attributes” and “collecting relations” of a target (CI), and “status” indicating whether the discovery instance is active or inactive. In the discovery method, a sensor that performs discovery normally grasps CIs and relationships to be created from discovery means and information obtained by the discovery. The discovery unit (201) performs discovery using, for example, the discovery instance (212). Through discovery, a CI instance and a relationship can be created, or a CI instance or relationship can be updated. When the sensor that performs discovery knows the CI or relationship that should be created using the discovered information, the description of the discovery method is not required in the definition of the data model (211). On the other hand, when there is no sensor that performs discovery, discovery may be performed by providing a description of the discovery method in the definition of the data model (211).

  The CI instance (213) is an “instance name” for specifying which CI the instance belongs to, a “model name” indicating which data model the instance was created using, and data “Attribute value” of each attribute specified by the model, description (value) of each “relation” specified by the data model, “status” indicating whether the instance is active or inactive, and Each description of “creation date” when the CI instance was created is included. The CI instance preferably further includes a CI instance identifier specific to the CI instance. The CI instance identifier is not particularly limited as long as the CI instance can be distinguished from other CI instances. For example, a host name, a serial number, or a combination of other attributes that are constant values can be used. CI instance (213) in FIG. 2C is a CI instance of component A; instantiated using data model A; includes attributes S, T, and U, each of which has a value Relations: being used by M (usedBy: M), being connected to E (connectAt: E), and running in H (runAt: H); that the CI instance is active, and The creation date data of the CI instance is shown.

  The relationship model (214) is a schema for defining the relationship specified by the data model (211). The relationship model (214) includes descriptions of “relation name” such as usedBy, “target data model” for specifying the target data model, and “description” of the relationship.

  3A to 3B show examples of configuration management in the CMDB used in the system and method according to the embodiment of the present invention.

FIG. 3A shows an overview of a tool for configuration management in the CMDB.
A tool (301) for configuration management includes a function (discovery) for automatically collecting information about configuration elements (hereinafter sometimes simply referred to as configuration information), a function for displaying configuration information graphically (topology), and a change history. And a function (analytics) for performing analysis such as a configuration comparison. For example, the TADDM server acquires configuration information about the information system using ssh, SNMP, WMI, or the like. The configuration information is, for example, the type of operating system of each information system or its configuration, the type of application software, or its configuration value. The TADDM server stores the acquired information as a CI instance in the CMDB (305). The TADDM server sends configuration information and change history information to the administrator's computer based on the CI instance stored in the CMDB (305). The administrator's computer uses the information to display configuration information and change history.

FIG. 3B shows an example of a configuration information management screen in the CMDB.
The configuration information management screen (309) is displayed using a GUI. The display is performed using, for example, TADDM. In FIG. 3B, the component is application software. The relationship between application software is indicated by a solid line. Note that the application software names (trademarks of the respective companies) displayed on the screen are examples.

  4A to 4C show an example of a system for changing authentication information and components in the system according to an embodiment of the present invention.

FIG. 4A shows an example of the entire system for changing authentication information using CMDB, which is an embodiment of the present invention.
The administrator (401) requests the ID management system (402) to change the authentication information on the server system (409).
The ID management system (402) requests the change synchronization system (403) to identify the client system (408) affected by the change of the authentication information.
The change synchronization system (403) uses the attributes or relationships of the CI instances in the CMDB (404), or a combination thereof to identify the client system (408) that is affected by the change in authentication information. The dependency between the authentication information of the client system (408) and the server system (409) is indicated by the relationship “AuthenticatedBy” in the CI instance of the client system (408), and the CI instance of the server system (409). Is indicated by the relationship "Authenticates". The change synchronization system (403) may be implemented in the ID management system (402) as an extension of the ID management system (402). The attributes and relationships of CI instances are collected using the discovery unit (405). Also, the attributes and relationships of the CI instances are updated using the attribute / relationship update unit (204).
The CMDB (404) stores the attributes and relationships of CI instances. The CMDB (404) also has a dependency relationship between authentication information, for example, passwords between systems, as a component relationship. The dependency may be collected automatically by discovery or manually entered by an administrator. The dependency between the authentication information of the client system (408) and the server system (409) is indicated by the relationship “AuthenticatedBy” in the CI instance of the client system (408), and in the CI instance of the server system (409). Shown with the relationship "Authenticates". FIG. 4A shows that the CMDB stores the CI instances and relationships of the application software (APPL1 to APPL1) and the database (DB) system, respectively.
The discovery unit (405) includes CIs managed by the CMDB, such as a client system (408) and an application running on the client system (408), and a server system (409) and the server system. (409) The information about the application running on is detected. The discovery unit (405) may also detect information about the scheduling system (406).
The scheduling system (406) manages the job operation schedule of the client system (408). The operation schedule is, for example, “the service provision time of the client system (408) is from 8:00 on Monday to 21:00 on Friday”. The operation schedule may be stored in the CMDB (404) as a CI instance attribute of the client system (408). Therefore, the scheduling system (406) is an optional component in the system for changing authentication information.
The ID management system (402) changes the authentication information from the operation schedule managed in the scheduling system (406) or the attribute of the CI instance of the client system (408) stored in the CMDB (404). A possible time zone is presented to the administrator (401).
The administrator (401) can determine the change time of the authentication information with reference to the presented time zone. The change time of the authentication information includes, for example, a time zone in which the authentication information can be changed next time, or an urgent change even if service interruption occurs due to leakage of the authentication information. The administrator (401) inputs the determined change time to the ID management system (402).
The ID management system (402) notifies the change synchronization system (403) of the determined change time.
The change synchronization system (403) creates an authentication information change request based on the notified change time and passes the created change request to the provisioning system (407).
The provisioning system (407) stops the application software on the client system (408) at the change time described in the change request, and changes the authentication information stored on the client system (408). Change to the authentication information described in the request. Stopping the application software on the client system (408) includes, for example, closing the application software. Instead of the provisioning system (407), the ID management system (402) may change the authentication information stored on the client system (408) to the authentication information described in the change request.
The provisioning system (407) also changes the authentication information stored on the server system (409) after changing the authentication information stored on the client system (408). Instead of the provisioning system (407), the ID management system (402) may change the authentication information stored on the server system (409).
The provisioning system (407) restarts the client system (408) or re-executes the stopped application software on the client system (408) after changing the authentication information of the client system (408) .
The client system (408) sends the changed authentication information to the server system (409) and requests connection.

FIG. 4B is a functional block diagram illustrating functions of the system for changing the authentication information described in FIG. 4A.
The system (411) for changing authentication information shown in FIG. 4A includes a repository (412), a specifying unit (413), and an instruction unit (414) to enable an instruction to change authentication information. The repository (412) is realized by the CMDB (404) shown in FIG. 4A. The specifying unit (413) is realized by the change synchronization system (403) illustrated in FIG. 4A. The instruction unit (414) is realized by the ID management system (402) shown in FIG. 4A. The discovery unit (415) is the same as the discovery unit (405) shown in FIG. 4A.
The system (411) includes a server system (40
9) or application software (hereinafter referred to as the first component) running on the server system (409) and client software (408) or application software running on the client system (408) (hereinafter referred to as the first component) , The second component) to connect, the authentication information (first authentication information) about the first component and the authentication information (the second component) transmitted from the second component to the first component It is arranged in an environment that requires authentication by matching with (authentication information).
The repository (412) is prepared in a recording medium accessible by the system (411). The accessible recording medium includes, for example, a recording medium externally connected to the system (411) or a recording medium connected to the system (411) via a network. The repository (412) stores the CI instance and relationship instance of the component. The CI instance and the relation instance can be updated by discovery by the discovery unit (415). The update of each instance is preferably performed immediately before changing authentication information, for example.
The identification unit (413) is affected by the change of the first authentication information based on the relationship in the CMDB in response to the request for changing the authentication information (first authentication information) about the first component. A second component is identified. The identification of the second component is performed based on, for example, a relationship instance between the first authentication information and the second authentication information. Alternatively, the identification of the second component is performed based on, for example, the relationship instance for the first component.
The specifying unit (413) also determines at least one of the specified second component (eg, client system) and first component (eg, server system) based on the attribute of the CI instance in the CMDB. Specify the operation schedule for. The specifying unit (413) includes the specified second component and each operation schedule of the first component, or each of the second component and the first component managed by the job schedule system. A time when the first authentication information or the second and first authentication information can be changed is determined based on the operation schedule.
The specifying unit (413) also includes the operation schedule of the specified second component and the first component, or the second component and the first component managed by the job schedule system. The user is allowed to determine when the first authentication information or the second and first authentication information can be changed based on each operation schedule.
The instructing unit (414) instructs to change the authentication information (second authentication information) transmitted from the second component specified by the specifying unit (413). The change instruction is given at a time determined by the specifying unit (413). The instructing unit (414) further instructs to change the first authentication information.

FIG. 4C shows a block diagram of computer hardware of each system shown in FIGS. 4A and 4B.
The computer system (421) according to the embodiment of the present invention includes a CPU (422) and a main memory (423), which are connected to a bus (424). The CPU (422) is preferably based on a 32-bit or 64-bit architecture, such as Intel's Xeon (TM) series, Core (TM) series, Atom (TM) series, Pentium (TM) series, The Celeron (TM) series, the AMD Phenom (TM) series, the Athlon (TM) series, the Turion (TM) series, and the Empron (TM) can be used. A display (426) such as an LCD monitor is connected to the bus (424) via a display controller (425). Display (426) is used to display information about the software running on the computer system (421) with a suitable graphic interface. A hard disk or silicon disk (428) and a CD-ROM, DVD or Blu-ray drive (429) are also connected to the bus (424) via an IDE or SATA controller (427). The CD-ROM, DVD or BD drive (429) is used to introduce a program from the CD-ROM, DVD-ROM or BD to a hard disk or silicon disk (428) as required. Further, a keyboard (431) and a mouse (432) are connected to the bus (424) via a keyboard / mouse controller (430) or a USB controller (not shown).

  The hard disk or silicon disk (428) can be loaded into the main memory (423) with an operating system, a program that provides a Java processing environment such as J2EE, an operation management program for the CMDB, and other programs and data. Is remembered. The operations management program preferably includes TADDM provided by International Business Machines Corporation.

  The communication interface (434) conforms to, for example, the Ethernet (trademark) protocol, and is connected to the bus (424) via the communication controller (433). The communication interface (434) plays a role of physically connecting the computer system (421) and the communication line (435) to the TCP / IP communication protocol of the communication function of the operating system of the computer system (421). Providing a network interface layer. The communication line may be a wired LAN environment or a wireless LAN environment based on a wireless LAN connection standard such as IEEE 802.11a / b / g / n.

  In addition to the above-described network switch, devices that can be used as a network connection device for connecting hardware such as a computer include a router and a hardware management console. In short, a function capable of returning configuration information such as the IP address and MAC address of a computer connected to an inquiry by a predetermined command from a computer in which a network operation management program is installed. It is. The network switch and router include an ARP table for the address resolution protocol (ARP), which includes a list of IP addresses of computers connected to the router and a corresponding pair of MAC addresses, and can be used to query by a predetermined command. On the other hand, it has a function of returning the contents of the ARP table. The hardware management console can return computer configuration information that is more detailed than the ARP table.

  The hardware management console described above is connected to the computer. This is a computer that logically divides one computer into multiple partitions by LPAR (virtual logical partition), and in each partition, runs different OS such as Windows (trademark), Linux (trademark) by VMware. It has a function to make it. By inquiring systematically to the hardware management console, it is possible to obtain detailed information on each logical partition of the computer operating in the LPAR / VMware.

  5A-5D illustrate the relationships between components used in embodiments of the present invention and stored in the CMDB, as well as the data model, CI instance, and relationship model that contain the relationships.

FIG. 5A shows the relationship “AuthenticatedBy” and “Authenticates” on the CMDB between the client system and the server system, which is an embodiment of the present invention.
I. The relationship of the CI instance of the client system (501) includes the relationship “AuthenticatedBy” with the server system (502).
II. The relationship of the CI instance of the server system (504) includes the relationship “Authenticates” with the client system (503).

FIG. 5B shows an example of a CI instance, data model, and relationship model for a client system that includes the relationship “AuthenticatedBy” of FIG. 5A.
The data model (421) includes an attribute “PasswordChangeInformation” for changing the password when the authentication information is, for example, a password. The attribute “PasswordChangeInformation” is an attribute for changing a password that is presented when the client system connects to the server system. The data model (411) also includes the relationship “AuthenticatedBy”. The relationship “AuthenticatedBy” indicates a relationship indicating that the client system requests authentication from the server system.
When the authentication information is, for example, a password, the CI instance (423) includes an attribute value “Knowledge file name” for the attribute “PasswordChangeInformation”. The attribute value “Knowledge” is a pointer to a method for changing authentication information in Knowledge. See FIG. 6B for knowledge.
The relationship model (414) defines the relationship “AuthenticatedBy”. The relational model (414) also defines that the data models of interest are A, C and D.
In FIG. 5B, the CI instance itself contains the relationship. Although the CI instances themselves may include relationships, as shown in FIG. 5D, as many relationship instances as the number of relationships may be created separately from the CI instances.

FIG. 5C shows an example of a CI instance, data model, and relationship model for a server system that includes the relationship “Authenticates” of FIG. 5A.
The data model (431) includes an attribute “PasswordChangeInformation” for changing the password when the authentication information is, for example, a password. The attribute “PasswordChangeInformation” is an attribute for changing a password for the server system. The data model (431) also includes the relationship “Authenticates”. The relationship “Authenticates” indicates a relationship indicating that authentication is permitted to the client system.
When the authentication information is, for example, a password, the CI instance (433) includes an attribute value “Knowledge file name” for the attribute “PasswordChangeInformation”. The attribute value “Knowledge” is a pointer to a method for changing authentication information in Knowledge. See FIG. 6B for knowledge.
The relationship model (434) defines the relationship “Authenticates”. Relational model (434) also defines that the data model of interest is B.
In FIG. 5C, the CI instance itself contains the relationship. Although the CI instances themselves may include relationships, as shown in FIG. 5D, as many relationship instances as the number of relationships may be created separately from the CI instances.

FIG. 5D shows an example of the relationship model “Authenticates” of FIG. 5C and its relationship instances.
The relationship model (441) is a model for the relationship “Authenticates”. When using a relationship instance, it is possible to express a relationship in the opposite direction by switching the base point and the destination, so it is possible to show a relationship in both directions using one relationship model and relationship instance. is there.
The relationship model (441) includes definitions of “a model serving as a base point” and “a model serving as a destination” of the relationship of “Authenticates”. The model that is the base point of the relationship model “Authenticates” is a data model for the server system to be authenticated, and the destination model is a data model for the client system to be authenticated.
The relationship model (441) also determines whether the relationship is a one-to-one relationship, a one-to-many relationship, a many-to-one relationship, or a many-to-many relationship. To illustrate, it includes definitions for each number on the base side and destination side.
The relation instance (443) also has a "relation model name" indicating what kind of relation it is, and a value indicating each CI instance that is the base point and destination of the relation. Since the relationship model name in the forward direction and the relationship model name in the reverse direction have a one-to-one correspondence, it is desirable that the instance has only the model name in the forward direction.

  6A-6C illustrate the method used to perform authentication-related discovery and the sensors, knowledge and signatures used in the method, which is an embodiment of the present invention.

FIG. 6A shows a sensor used for discovery of authentication dependency in CMDB, which is an embodiment of the present invention.
Application software A (602) is installed and operating on the application server system C (601).
The application software A (602) transmits authentication information such as an ID and a password to the server system S (603) in order to connect to the server system S (603).
The server system S (603) verifies the authentication information transmitted from the application software A (602) in response to the authentication information verification request from the application software A (602).
The authentication dependency sensor (604) acquires the property file of the application software A (602) based on the knowledge (see FIG. 6C), and acquires the DB name from the key.

FIG. 6B shows an authentication-related discovery method using the sensor described in FIG. 6A.
By defining the knowledge of the authentication method of the application software, it is possible to automatically find the dependency between the authentication information of the application software and the server system.
The discovery process includes three steps.
Step 611. Discovery of application server system C (601) and server system S (603). Note that this step can be appropriately performed by those skilled in the art using a known discovery technique, and will not be described in detail here.
Step 612. Discovery of application software A (602). Note that this step can be appropriately performed by those skilled in the art using a known discovery technique, and will not be described in detail here.
Step 613. Discovery of authentication relationships by applying knowledge according to embodiments of the present invention.
The knowledge necessary for the discovery in step 3 is information on what kind of server system an application software authenticates and where the name of the server system is recorded.

Step 611
The presence of the application server system C (601) and the server system S (603) is detected by the discovery technique, and each CI instance of the application server system C (601) and the server system S (603) is detected. Is registered in the CMDB. Similarly, the discovery technique detects that the application server system C (601) and the server system S (603) are related from the state of network connection, and the relationship is also registered in the CMDB. The As the discovery technology, for example, a technology implemented in IBM Tivoli Application Dependency Discovery Manager (trademark) is used.
Step 612
Next, an inventory using a signature is performed on a system in which the application server system C (601) is installed. The inventory of installed application software by signature is implemented as, for example, the software inventory function of IBM Tivoli Provisioning Manager (trademark) V5. The application software A (602) is detected by the application software inventory process. Here, a CI instance of the application software A (602) is created, and the relationship between the running application server system C (601) and the application software A (602) is registered in the CMDB. The relationship between the application server system C (601) and the application software A (602) is, for example, “C has A”.
Step 613
Next, when the authentication knowledge is applied to the detected application software A (602), the authentication dependency sensor (604) acquires the property file bbb of the application software A (602) based on the knowledge. Then, the DB name can be acquired from the key aaa. The authentication dependency sensor (604) confirms that the acquired DB name exists on the server system S (603), whereby the application software A (602) is transferred to the server system S (603). It is possible to register a related instance of performing authentication for the CMDB. The relation instance is, for example, “S authenticates A”.

FIG. 6C shows a conceptual diagram of signatures and knowledge used in the authentication-related discovery method of FIG. 6B.
1. The signature (621) includes, for example, an application software name and a signature.
A signature (622) is an example of a signature used in an inventory using a signature.
The signature (622) for the product A in the upper row can determine whether or not the product A provided by the vendor IBM is installed based on whether or not the directory yyyy exists in the server zzzz and the file xxxx exists thereunder. It shows that there is.
The signature (623) for the product B in the lower row indicates whether or not the product B provided by the vendor YY is installed depending on whether or not the registry www \ YY key exists and the value vvv of the type DWORD exists below it. This indicates that it can be determined.
2. The knowledge (621) includes, for example, an application software name, pair authentication, an authentication method, and an authentication target. The authentication target is information necessary for changing authentication information, for example, a password.
The knowledge (625) about the product A is that the product A provided by the vendor IBM authenticates to the DB server in the first record (verification), and the authentication to the DB in the next record (authentication method). To use the password, and in the last record (authentication target), obtain the property file bbb and read the value of the DB name key aaa in it to determine the DB name to be authenticated Yes.
Knowledge (626) about the product B is that the product B provided by the vendor YY authenticates to the DB server in the first record (authentication), and the authentication to the DB in the next record (authentication method). Is performed using a password, and the DB name recorded in the registry can be determined in the last record (authentication target).

FIG. 7A shows a system configuration for changing the authentication method and data associated therewith, which is the first scenario of the embodiment of the present invention.
The client system (701) executes application software A1. The application software A1 sends authentication information to the server system S (702) in order to use data in the server system S (702).
The authentication relationship between the client system (701) and the server system S (502) is defined in the CMDB by the relationship “AuthenticatedBy” regarding the CI of the application software A1 as described in the description of FIGS. 5A and 5B above. Is done.
The application software A1 is, for example, application software for an operation unit such as an inventory management system. When the application software A1 is realized by using, for example, a product called vendor: IBM product: A (703), the CI instance of the application software A1 is realized by using the product A as the application software A1. Including the relationship. The relationship is defined by “runsAt” and “runsOn”, for example. The relationship is used in a procedure for stopping or starting the WAS, for example, for changing authentication information.
The CI instance of the application software A1 may have as attributes the time required to start the application software A1 (startup) and the time required to end the application software A1 (shutdown). In FIG. 7B below, the attribute value of the attribute “startup” is “20 minutes”, and the attribute value of the attribute “shutdown” is “10 minutes”. These attribute values may be manually input by an administrator, for example.
The operating time table (705) is used to automatically search for a time zone in which authentication information can be changed. The operating time table (705) includes, for example, data on the operating time of each day of the week.

FIG. 7B shows an example of the CI instance, data model, and relation model of the application software A1 shown in FIG. 7A.
The data model (711) includes “StartUp” and “ShutDown” in addition to the attributes in the model attributes of the data model (421) of FIG. 5B. The attribute “StartUp” defines a time (startup) required for starting the application software A1. The attribute “ShutDown” defines the time (shutdown) required to terminate the application software A1.
The CI instance (713) includes attribute values of “StartUp” and “ShutDown” in addition to the attribute values of the CI instance (423) of FIG. 5B. In the CI instance (713), the attribute value of the attribute “StartUp” of the application software A1 is 20 minutes, and the attribute value of the attribute “ShutDown” of the application software A1 is 10 minutes.

FIG. 7C shows the knowledge used for changing the authentication information in FIG. 7A.
Knowledge is used to change the authentication information of the client system in synchronization with the change of the authentication information of the server system.
Knowledge includes, for example, application software information, authentication method, whether application stop is necessary, application software stop processing method and start processing method, time required for changing authentication information, and authentication information (for example, password). Record the change method. In FIG. 7C, for the sake of convenience, the knowledge is shown separately from the table (721) and the table (722), but it may be a single table.
The “application information” includes the name of the application software and the name of the vendor that provides the application software.
“Authentication method” defines an authentication method used by the client system to connect to the server system. The authentication method is, for example, a password or a digital certificate.
Need to stop the application? Indicates whether or not the application software must be stopped when changing the authentication information on the client system side. If the application does not need to be stopped, it is necessary to describe the stop processing method and the start processing method. There is no. “Whether the application needs to be stopped is indicated by Yes or No, for example.
“Application software stop processing method” describes a method of stopping the application software before changing the authentication information. Note that the stop method may be performed automatically, semi-automatically, or manually. In the description of the stopping method, only the part that is automatically performed may be described.
“Application software activation processing method” describes a method of activating the application software after changing authentication information. The starting method can be performed automatically, semi-automatically or manually. In the description of the starting method, only the part that is automatically performed may be described.
“Required time for changing authentication information” describes the time required to change the password on the client side in order to automatically search for a changeable time zone. The reason why the time required to change the authentication information of the client system is necessary is that the time required for the change on the client system side is calculated by adding up the time required for the above application termination and startup, and the time required to change the authentication information. This is to search for a time that does not affect the provided time zone.
Knowledge can be stored as metadata in the CMDB (FIGS. 4A, 404) or as knowledge in the change synchronization system (FIGS. 4A, 403). When the knowledge is stored as metadata in the CMDB (404), the CI instance attribute for the client system indicates a pointer to a specific location in the knowledge (eg, knowledge about IBM product A). . Knowledge metadata may be provided in the CMDB (404) as a sub-CI instance of the CI instance for the client system.
For general application software, knowledge can be provided by an application software provider, for example, IBM. In addition to knowledge, the application software provider can operate the application software stop processing method and activation processing method, and the authentication information changing method and the authentication information changing method data in a format that can be read by the user. It may also be provided in a format that can be used by operational automation products such as IBM's Tivoli Provisioning Manager ™.
For application software (in-house developed product) uniquely developed without using general application software, the developer of the unique application software needs to provide knowledge to the administrator.
Note that the server system authentication information can be changed using, for example, an existing TIM.

FIG. 7D shows a flowchart of authentication information change processing, which is the first scenario of the embodiment of the present invention described in FIG. 7A.
In step 731, the administrator (401) requests the ID management system (402) to change the password for the server system S (702).
In step 732, the discovery unit (FIG. 2A, 201) may perform discovery in response to a password change request. Through discovery, the attributes or relationships of the components can be updated.
In step 733, the change synchronization system (403) identifies the CI instance of the server system S (702) in the information from the ID management system (402). As a result, the server system S (702) is specified.
In step 734, the client system or application software on the client system is identified using the relationship between the CI instances of the server system S (802).
In step 735, the change synchronization system (403) identifies a schedule for changing the authentication information. The schedule refers to the operation time table (705) of the application software A1, and is a time other than the operation time, that is, a time required for starting the application software A1 (startup) and a time required for the end (shutdown). In consideration, it is selected from the time other than the operation time.
In step 736, the provisioning system (407) changes the authentication information of the client system or the application software on the client system according to the specified schedule.
In step 737, the provisioning system (407) changes the authentication information of the server system or application software on the server system according to the specified schedule.
Note that step 736 and step 737 may be performed in the order of step 737 and step 736, or may be performed simultaneously.
In step 738, the client system is started or application software on the client system is started.

FIG. 8A shows an application example of a system to which authentication information change processing is performed, which is a second scenario of the embodiment of the present invention.
Reference numerals 801 to 805 in FIG. 8A correspond to 701 to 705 in FIG. 7A, respectively.
A case will be described in which the administrator (FIG. 4, 401) requests the ID management system (FIG. 4, 402) to change the password for the server system S (802).
The change synchronization system (FIG. 4, 403) uses the attribute that can identify the CI instance of the server system S (802) in the information from the ID management system (402), for example, the host name (S), and the CMDB ( The CI instance for server system S (802) in FIGS. 4 and 404) is identified. The change synchronization system (403) further searches the CMDB (404) for the CI instances associated with the server system S (802) by the relationship “Authenticates”. In the example of FIG. 8A, application software A1 (801) and application software A2 (806) are specified from the CMDB (404) as search results.

FIG. 8B shows a processing flow created from the search result of the authentication information relationship described in FIG. 8A.
The change synchronization system (403) internally creates the processing flow shown in FIG. 8B from the search result of the relationship “Authenticates”, and calculates the total time required for changing the authentication information.
Here, it is assumed that the time required to change the authentication information of the server system S (or an application running on the server system, the same applies hereinafter) (802) is 5 minutes (see 815).
When the provisioning system (407) can simultaneously execute the processing for the application software A1 and A2, the time required for changing the authentication information is 75 (50 + 5 + 20) minutes for the application software A1 (811, 812). , 815 and 816), and 60 (35 + 5 + 20) minutes for application software A2 (see 813, 814, 815 and 817).
When the provisioning system (FIG. 4, 406) cannot execute the processing for the application software A1 and A2 in parallel, the time required for changing the authentication information is 130 (50 + 35 + 5 + 20 + 20) (811, 812, 813, 814, 815, 816 and 817).
In the following, a case where the processing for the application software A1 and A2 can be performed in parallel will be described as an example.
In the change synchronization system (403), 75 minutes (application software A1) and 60 minutes (application software A2), which are times required for changing authentication information, are the same as the operation time (805) and application of application software A1. Search for a range that falls within a common time zone other than the operating time (809) of the software A2. As a result of the search, the change synchronization system (403) determines that the change process can be started from 9 pm Friday to 6:45 am on Monday for the application software A1, and the application software A 2 Is determined that the change process can be started from 3 pm on Saturday to 6 am on Monday. Change synchronization system (403), from the result of the determination enables the, between Saturday 3 pm Monday 6:00 AM, change of the authentication information of the application software A1 and A2, as well as server system S (802) It is determined that the process can be started. By this determination, a common time zone other than the operation time (805) of the application software A1 and the operation time (809) of the application software A2 can be determined.
The result of the determination is displayed on the display device of the administrator (401).
The determination result is stored in the change synchronization system (403), or the CI instance of the application software A1 and the CI instance of the application software A2, and the CI instance of the server system S (802). These attribute values may be stored in the CMDB.
The change synchronization system (403) creates a change request including the following steps. The change synchronization system (403) passes the following authentication information change request to the provisioning system (407) together with the time to start changing the authentication information. The change system may pass the change request to the provisioning system (407) after the change request is approved by the change management process. The change management process is a process performed according to ITIL. As the change management process, for example, a change request approval process is executed by a change management process management server (not shown). Approval is approved by the change manager (who is human) and the change advisory board.
1. 1. Stop application software A1 and A2. 2. Change of authentication information of application software A1 and A2. 3. Change of authentication information of server system S Activation of the application software A1 and A2 If the processing for the application software A1 and A2 cannot be performed simultaneously, the following series of authentication information change requests is the time when the authentication information change should be started Passed with.
1. 1. Stop application software A1 2. Stop application software A2. 3. Change of authentication information of application software A1 4. Change of authentication information of application software A2. 5. Change of authentication information of server system S 6. Start application software A1. Start application software A2

8B shows a processing flow for changing the authentication information of the server system S (802) after changing the authentication information of the application software A1 and A2, the authentication of the server system S (802). After changing the information, each authentication information of the application software A1 and A2 may be changed. The authentication information of the server system S (802) can be changed without stopping the application software A1 and A2 without causing an error. The application software A1 and A2 can change the authentication information of the server system S (802). This is the case with a connection pool. In this case, the change synchronization system (403) passes a series of authentication information change requests shown below to the provisioning system (407) together with the time to start the change of the authentication information. The change system may pass the change request to the provisioning system (407) after the change request is approved by the change management process.
When the processing for the application software A1 and A2 can be performed simultaneously in parallel. 1. Change of authentication information of server system S 2. Stop application software A1 and A2. 3. Change of authentication information of application software A1 and A2. Activation of application software A1 and A2 When processing for application software A1 and A2 cannot be performed concurrently 1. 1. Change of authentication information of server system S 2. Stop application software A1. 3. Stop application software A2. 4. Change of authentication information of application software A1 5. Change of authentication information of application software A2. 6. Start application software A1. Start application software A2

FIG. 8C shows an example of the CI instance, data model, and relationship model of the server system S shown in FIG. 8A.
The data model (821) corresponds to the model of the data model (431) of FIG. 5C.
The CI instance (823) corresponds to the CI instance (433) in FIG. 5C. The attribute “Authenticates” of the CI instance (823) has “A1” indicating that the application software A1 is authenticated and “A2” indicating that the application software A2 is authenticated as attribute values.
The relationship model (824) corresponds to the relationship model (432) of FIG. 5C.

FIG. 8D shows a flowchart of authentication information change processing, which is the second scenario of the embodiment of the present invention described in FIG. 8A.
In step 831, the administrator (401) requests the ID management system (402) to change the password for the server system S (802).
In step 832, the discovery unit (201 in FIG. 2A) may perform discovery in response to a password change request. Through discovery, the attributes or relationships of the components can be updated.
In step 833 , the change synchronization system (403) identifies the CI instance of the server system S (802) in the information from the ID management system (402). As a result, the server system S (802) is specified.
In step 834, the application software A1 and A2 on the client system are identified using the relationship between the CI instances of the server system S (802).
In step 835, the change synchronization system (403) identifies a schedule for changing the authentication information.
In step 836, the provisioning system (407) changes the authentication information of the client system or the application software on the client system according to the specified schedule.
In step 837, the provisioning system (407) changes the authentication information of the server system or application software on the server system according to the specified schedule.
Note that step 836 and step 837 may be performed in the order of step 837 and step 836, or may be performed simultaneously.
In step 838, the client system is started or application software on the client system is started.

FIG. 9A shows an application example of a system in which authentication information change processing is performed when the server system S is also used in a batch job, which is the third scenario of the embodiment of the present invention.
9A correspond to 801 to 809 in FIG. 8A, respectively.
When the server system S (902) is also used in a batch job, the job schedule is recorded in the job scheduling system (910) and the relationship from the batch job to the server system S (902), for example, “ Store “Uses”. The relationship “Uses” may be recorded as an attribute of the CI instance of the job in the CMDB. The relationship is as follows: a batch job that uses the server system S (902) among jobs scheduled to be executed, a batch job that requires a change in authentication information, and a job from a time zone in which the authentication information can be changed. Can be used to exclude execution time zones.
When the server system S (902) is not used in a batch job, as described in the description of FIG. 7D, the application software A1 and A2 and the server are installed between 3 pm on Saturday and 6 am on Monday. -The administrator is informed that the process of changing the authentication information of the system S can be started.
For example, when the batch job is not linked with the CMDB, or when the batch job schedule is not linked with another system, the administrator determines the common time zone in FIG. 7D considering the batch job. Based on the result, it is possible to instruct the execution timing of the change of the authentication information.

FIG. 9B shows the CI instance, data model, and relation model for the server system, which is the third scenario of the embodiment of the present invention described in FIG. 9A.
The data model (911) corresponds to the data model (431) of FIG. 5C. The data model (911) further includes an attribute “BatchJobInformation” for the batch job.
The CI instance (913) corresponds to the CI instance (433) in FIG. 5C. The CI instance (913) further includes an attribute value “batch job file name” for the attribute “BatchJobInformation”.

FIG. 9C shows a flowchart of authentication information change processing, which is the third scenario of the embodiment of the present invention described in FIG. 9A.
In step 921, the administrator (401) requests the ID management system (402) to change the password for the server system S (902).
In step 922, the discovery unit (FIG. 2A, 201) may perform discovery in response to a password change request. Through discovery, the attributes or relationships of the components can be updated.
In step 923, the change synchronization system (403) identifies the CI instance of the server system S (902) in the information from the ID management system (402). As a result, the server system S (902) is specified.
In step 924, the application software A1 and A2 on the client system are identified using the relationship between the CI instances of the server system S (902).
In step 925, the change synchronization system (403) identifies a schedule for changing the authentication information. For this change, the job schedule recorded in the scheduling system (910) is used.
In step 926, the provisioning system (407) changes the authentication information of the client system or the application software on the client system according to the specified schedule.
In step 927, the provisioning system (407) changes the authentication information of the server system or application software on the server system according to the specified schedule.
Note that step 926 and step 927 may be performed in the order of step 927 and step 926, or may be performed simultaneously.
In step 928, the client system is started or application software on the client system is started.

  As described above, the present invention has been described based on the embodiment. However, the content described in the present embodiment is an example of the present invention, and a person skilled in the art can make various changes without departing from the technical scope of the present invention. It will be clear that variations can be conceived. For example, instead of the CMDB and the CI stored in the CMDB, a database of a different format and a CI format can be used. In addition to Java, any computer development environment that can call an API having a network management function, such as C ++ or C #, can be used.

Claims (23)

In order for the second component to connect to the first component, the first component from the authentication information about the first component (hereinafter referred to as first authentication information) and the second component A computer system for changing the second authentication information in an environment that requires authentication by matching with authentication information (hereinafter referred to as second authentication information) transmitted to
A repository that stores at least one predetermined attribute of a component and a relationship between the component and another component, wherein at least one of the attribute and relationship is updated by a discovery that detects information about the component The repository,
In response to the change request for the first authentication information, based on the relationship, a specifying unit that specifies a second component that is affected by the change in the first authentication information;
An instruction unit for instructing change of second authentication information transmitted from the identified second component.   The computer system according to claim 1, wherein the instruction unit further instructs to change the first authentication information. The specifying unit specifies a job operation schedule of the specified second component and the first component based on the attribute, and specifies the specified second component and the first configuration. The computer system according to claim 1 , wherein a time when the first authentication information or the second and first authentication information can be changed is determined based on an operation schedule of each job of the element . Based on the operation schedule of the second component and the first component managed by the job schedule system , the specifying unit is configured to use the first authentication information or the second and first The computer system according to claim 1, wherein a time when the authentication information can be changed is determined.   The computer system according to claim 4, wherein the instruction unit stops the second component and instructs to change the second authentication information at the determined time.   The computer system according to claim 5, wherein the instruction unit further instructs the change of the first authentication information in response to the change of the second authentication information.   The specifying unit includes the second component and the first component managed by the operation schedule of the specified second component and the first component, or the job schedule system. The computer system according to claim 1, wherein a user is allowed to determine when the first authentication information or the second and first authentication information can be changed based on each operation schedule.   The computer system according to claim 7, wherein the instruction unit stops the second component and instructs the change of the second authentication information at the determined time.   The computer system according to claim 8, wherein the instruction unit further instructs the change of the first authentication information in response to the change of the second authentication information.   In response to the change request for the first authentication information, the specifying unit uses the information for specifying the first component in the change request to store the first component stored in the repository. The computer system of claim 1, wherein the computer system identifies attribute or relationship data for the.   The computer system of claim 1, wherein the relationship includes a relationship between the first authentication information and the second authentication information.   The computer system according to claim 11, wherein the specifying unit specifies the second component based on a relationship between the first authentication information and the second authentication information.   The computer system according to claim 3, wherein the attribute includes a pointer to an operation schedule file that defines an operation schedule, or includes an attribute for the operation schedule.   The specifying unit specifies at least one operation schedule of the specified second component and the first component based on the operation schedule file or the attribute of the operation schedule. The computer system described.   The computer system according to claim 14, wherein the operation schedule file or the operation schedule attribute includes a service provision time of the application software and a time required to start and stop the application software.   The attribute of the operation schedule file or the operation schedule further includes an application software authentication method, a method for changing the first or second authentication information, and a time required for password change. Computer system.   The computer system according to claim 1, wherein the specifying unit specifies the second component based on a relationship with respect to the first component.   The computer system according to claim 3, wherein the specifying unit specifies the operation schedule based on attributes of the second component and the first component.   The computer system of claim 1, wherein each of the first component and the second component is either a computer system or software. In order for the second component to connect to the first component, the first component from the authentication information about the first component (hereinafter referred to as first authentication information) and the second component A method for changing the second authentication information in an environment that requires authentication by matching with authentication information (hereinafter referred to as second authentication information) transmitted to
Storing at least one predetermined attribute of the component and a relationship between the component and the other component in the repository, wherein at least one of the attribute and the relationship is detected by discovery for detecting information about the component The storing step, which can be updated;
Identifying a second component affected by the change of the first authentication information based on the relationship in response to the change request of the first authentication information;
Instructing a change in second authentication information transmitted from the identified second component.   21. The method of claim 20, wherein the instructing step further comprises instructing a change of the first authentication information. In order for the second component to connect to the first component, the first component from the authentication information about the first component (hereinafter referred to as first authentication information) and the second component A method for changing the second authentication information in an environment that requires authentication by matching with authentication information (hereinafter referred to as second authentication information) transmitted to
Storing at least one predetermined attribute of the component and a relationship between the component and the other component in the repository, wherein at least one of the attribute and the relationship is detected by discovery for detecting information about the component The storing step, which can be updated;
Identifying a second component affected by the change of the first authentication information based on the relationship in response to the change request of the first authentication information;
Identifying an operation schedule of the job of the identified second component and first component based on the attribute;
Determining when the second and first authentication information can be changed based on an operation schedule of each job of the specified second component and the first component;
Instructing the change of the second authentication information transmitted from the identified second component at the determined time;
Instructing a change of the first authentication information. In order for the second component to connect to the first component, the first component from the authentication information about the first component (hereinafter referred to as first authentication information) and the second component A computer program for changing the second authentication information in an environment that requires authentication by matching with authentication information (hereinafter referred to as second authentication information) transmitted to the computer, A computer program for causing a system to execute the steps of the method according to any one of claims 20 to 22.

Images